From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 01:37:02 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2D22106566C; Sun, 27 Nov 2011 01:37:02 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8F3818FC0A; Sun, 27 Nov 2011 01:37:02 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 35326617F; Sat, 26 Nov 2011 20:37:01 -0500 (EST) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=l3u5IP+oauRdnVSP2R0jmDlijmiIynSRJeXyBg9uqfnyN/hr87MMboxCIniwNAibr mtKSQZQ7ChvChrTWgEzXnPZei3GMRYBSWvZU8h1nMngpIYj9soOs6uf2QHRCaV8 Message-ID: <4ED1943A.90707@protected-networks.net> Date: Sat, 26 Nov 2011 20:36:58 -0500 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111111 Thunderbird/8.0 MIME-Version: 1.0 To: Gleb Kurtsou References: <4ECF7440.4070300@entel.upc.edu> <4ECF8F05.8000007@protected-networks.net> <4ED0C40D.5010307@entel.upc.edu> <4ED0D963.1030702@entel.upc.edu> <4ED0DF1F.6090901@FreeBSD.org> <20111126163343.GA9150@reks> In-Reply-To: <20111126163343.GA9150@reks> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD current , freebsd-emulation@FreeBSD.org, =?UTF-8?B?R3VzdGF1IFDDqXJleg==?= , Andriy Gapon Subject: Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464} 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, 27 Nov 2011 01:37:02 -0000 On 11/26/11 11:33, Gleb Kurtsou wrote: > On (26/11/2011 14:44), Andriy Gapon wrote: >> vm_phys_alloc_contig implementation has been recently changed and now it seems >> to require that vm_page_queue_free_mtx is held. > > Using new vm_page_alloc_contig() may be a better option here. Can't help > with patch, stuck with pre Nov 15 CURRENT myself. If I understand the change in locking semantics (post SVN r227568?), a good number of chunks of src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c need updating to follow this :-(. It is now insufficient to hold only the queue lock when calling vm_page_unwire or vm_page_free (and maybe others). The page itself must now also be locked, imb From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 03:16:31 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AA9D106566B; Sun, 27 Nov 2011 03:16:31 +0000 (UTC) (envelope-from brde@optusnet.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 E2BF48FC0C; Sun, 27 Nov 2011 03:16:30 +0000 (UTC) Received: from c211-28-227-231.carlnfd1.nsw.optusnet.com.au (c211-28-227-231.carlnfd1.nsw.optusnet.com.au [211.28.227.231]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id pAR3GKwE021619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Nov 2011 14:16:21 +1100 Date: Sun, 27 Nov 2011 14:16:20 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Robert Millan In-Reply-To: <20111126200749.GA72056@thorin> Message-ID: <20111127131422.D802@besplex.bde.org> References: <20111123070036.GA29952@thorin> <20111124141821.O932@besplex.bde.org> <20111125150324.G1018@besplex.bde.org> <20111126200749.GA72056@thorin> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Sun, 27 Nov 2011 04:26:06 +0000 Cc: Adrian Chadd , freebsd-current@freebsd.org, Bruce Evans , freebsd-arch@freebsd.org, Kostik Belousov , Warner Losh Subject: Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers (v2) 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, 27 Nov 2011 03:16:31 -0000 On Sat, 26 Nov 2011, Robert Millan wrote: > On Fri, Nov 25, 2011 at 11:16:15AM -0700, Warner Losh wrote: >> Hey Bruce, >> >> These sound like good suggestions, but I'd hoped to actually go through all these files with a fine-toothed comb to see which ones were still relevant. You've found a bunch of good areas to clean up, but I'd like to humbly suggest they be done in a follow-on commit. > > Hi, > > I'm sending a new patch. Thanks Bruce for your input. TTBOMK this corrects > all the problems you spotted that were introduced by my patch. It doesn't > fix pre-existing problems in the files however, except in cases where I had > to modify that line anyway. > > I think it's a good compromise between my initial patch and an exhaustive > cleanup of those headers (which I'm probably not the most indicate for). It fixes most style bugs, but not some-pre-existing problems, even in cases where you had to modify the line anyway. % Index: sys/cam/scsi/scsi_low.h % =================================================================== % --- sys/cam/scsi/scsi_low.h (revision 227956) % +++ sys/cam/scsi/scsi_low.h (working copy) % @@ -53,10 +53,10 @@ % #define SCSI_LOW_INTERFACE_XS % #endif /* __NetBSD__ */ % % -#ifdef __FreeBSD__ % +#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) % #define SCSI_LOW_INTERFACE_CAM % #define CAM % -#endif /* __FreeBSD__ */ % +#endif /* __FreeBSD__ || __FreeBSD_kernel__ */ It still has the whitespace-after tab style change for cam. % Index: sys/dev/firewire/firewirereg.h % =================================================================== % --- sys/dev/firewire/firewirereg.h (revision 227956) % +++ sys/dev/firewire/firewirereg.h (working copy) % @@ -75,7 +75,8 @@ % }; % % struct firewire_softc { % -#if defined(__FreeBSD__) && __FreeBSD_version >= 500000 % +#if (defined(__FreeBSD__) || defined(__FreeBSD_kernel__)) && \ % + __FreeBSD_version >= 500000 % struct cdev *dev; % #endif % struct firewire_comm *fc; Here is a pre-existing problem that you didn't fix on a line that you changed. The __FreeBSD__ ifdef is nonsense here, since __FreeBSD__ being defined has nothing to do with either whether __FreeBSD_version is defined or whether there is a struct cdev * in the data structure. Previously: - defined(__FreeBSD__) means that the compiler is for FreeBSD - __FreeBSD_version >= 500000 means that FreeBSD has been included and has defined __FreeBSD_version to a value that satisifes this. It would be a bug for anything else to define __FreeBSD_version. Unfortunately, there is a bogus #undef of __FreeBSD_version that breaks detection of other things defining it. - the __FreeBSD__ part of the test has no effect except to break compiling this file with a non-gcc compiler. In particular, it doesn't prevent errors for -Wundef -Werror. But other ifdefs in this file use an unguarded __FreeBSD_version. Thus this file never worked with -Wundef -Werror, and the __FreeBSD__ part has no effect except the breakage. Now: as above, except: - defined(__FreeBSD_kernel__) means that FreeBSD been included and that this header is new enough to define __FreeBSD_kernel__. This has the same bug with the #undef, which I pointed out before (I noticed it for this but not for __FreeBSD_version). And it has a style bug in its name which I pointed out before -- 2 underscores in its name. __FreeBSD_version doesn't have this style bug. The definition of __FreeBSD_kernel__ has already been committed. Is it too late to fix its name? - when is new enough to define __FreeBSD_kernel__, it must be new enough to define __FreeBSD_version >= 500000. Thus there is now no -Wundef error. - the __FreeBSD__ ifdef remains nonsense. If you just removed it, then you wouldn't need the __FreeBSD_kernel__ ifdef (modulo the -Wundef error). You didn't add the __FreeBSD_kernel__ ifdef to any of the other lines with the __FreeBSD_kernel__ ifdef in this file, apparently because the others don't have the nonsensical __FreeBSD__ ifdef. The nonsense and changes to work around it make the logic for this ifdef even more convoluted and broken than might first appear. In a previous patchset, you included to ensure that __FreeBSD_kernel__ is defined for newer kernel sources (instead of testing if it is defined). Ifdefs like the above make a prerequsite for this file anyway, since without knowing __FreeBSD_version it is impossible to determine if the data structure has new fields like the cdev in it. is a prerequisite for almost all kernel .c files, so this prerequisite should be satisfied automatically for them, but it isn't clear what happens for user .c files. I think the ifdef should be something like the following to enforce the prerequisite: #ifndef _SYS_PARAM_H_ /* * Here I don't support __FreeBSD_version__ to be set outside of * to hack around a missing include of . * The case where the kernel is so old that __FreeBSD_version__ is * not defined should be handled by including to see * if __FreeBSD_version__ is in fact not defined. */ #error " is a prerequisite for this file" #endif #if __FreeBSD_version >= 500000 /* * Add defined(__FreeBSD_version) to the ifdef if you want to fully * support -Wundef. This is unlikely to have any effect here, since * has been included, and it defines __FreeBSD_version * except under very old versions of FreeBSD where -Wundef was even * more unusable than now. */ struct cdev *dev; #endif Similarly in most places that test __FreeBSD__ and __FreeBSD_version, or __FreeBSD__ and DEVICE_POLLING (the latter might need to ensure that opt_device_polling.h instead of is included, so in userland it reduces to an unconditional #error or hacks since opt_device_polling.h is a kernel-only non-module-only header). Bruce From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 04:58:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBC191065673 for ; Sun, 27 Nov 2011 04:58:49 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by mx1.freebsd.org (Postfix) with ESMTP id 782B08FC0A for ; Sun, 27 Nov 2011 04:58:49 +0000 (UTC) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta15.westchester.pa.mail.comcast.net with comcast id 24rV1i0021ap0As5F4ypdL; Sun, 27 Nov 2011 04:58:49 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta22.westchester.pa.mail.comcast.net with comcast id 24yn1i00d1t3BNj3i4yovM; Sun, 27 Nov 2011 04:58:49 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 6BC60102C19; Sat, 26 Nov 2011 20:58:46 -0800 (PST) Date: Sat, 26 Nov 2011 20:58:46 -0800 From: Jeremy Chadwick To: Mark Felder Message-ID: <20111127045846.GA54467@icarus.home.lan> References: <95d00c1b714837aa32e7da72bc4afd03@feld.me> <20111126104840.GA8794@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Sun, 27 Nov 2011 05:41:14 +0000 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: zfs i/o hangs on 9-PRERELEASE 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, 27 Nov 2011 04:58:49 -0000 On Sat, Nov 26, 2011 at 04:47:35PM -0600, Mark Felder wrote: > It appears that I'm mistaken about those messages then . However this does both happen on my AMD x6 and Intel Atom machines with different hard drives, controllers, etc. I feel it would be unlikely to be hardware. > > Unfortunately the procstat command is probably of no use because I can't interact with the console or ssh for the periods of time when it is hanging (sometimes in excess of a minute). Zpool scrubs come up clean and I never see any errors reported. I've been running this hardware for 2 years and v28 for quite some time. It doesn't seem like it started happening until I upgraded to a build past RC1. I don't know where to find RC1 media and I don't know the svn revision of RC1 so I haven't tried. The kernel backtrace you provided indicates a problem in pf(4), not ZFS. What piece am I missing? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 08:41:31 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DC0B1065670; Sun, 27 Nov 2011 08:41:31 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A62ED8FC0C; Sun, 27 Nov 2011 08:41:30 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA13238; Sun, 27 Nov 2011 10:41:20 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RUaIa-000K99-9P; Sun, 27 Nov 2011 10:41:20 +0200 Message-ID: <4ED1F7AE.3030105@FreeBSD.org> Date: Sun, 27 Nov 2011 10:41:18 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Michael Butler References: <4ECF7440.4070300@entel.upc.edu> <4ECF8F05.8000007@protected-networks.net> <4ED0C40D.5010307@entel.upc.edu> <4ED0D963.1030702@entel.upc.edu> <4ED0DF1F.6090901@FreeBSD.org> <20111126163343.GA9150@reks> <4ED1943A.90707@protected-networks.net> In-Reply-To: <4ED1943A.90707@protected-networks.net> X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-emulation@FreeBSD.org, FreeBSD current Subject: Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464} 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, 27 Nov 2011 08:41:31 -0000 on 27/11/2011 03:36 Michael Butler said the following: > On 11/26/11 11:33, Gleb Kurtsou wrote: >> On (26/11/2011 14:44), Andriy Gapon wrote: >>> vm_phys_alloc_contig implementation has been recently changed and now it seems >>> to require that vm_page_queue_free_mtx is held. >> >> Using new vm_page_alloc_contig() may be a better option here. Can't help >> with patch, stuck with pre Nov 15 CURRENT myself. > > If I understand the change in locking semantics (post SVN r227568?), a good > number of chunks of src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c need > updating to follow this :-(. > It is now insufficient to hold only the queue lock when calling vm_page_unwire > or vm_page_free (and maybe others). The page itself must now also be locked, Not "also", but instead. And only for managed pages. For unmanaged pages a caller doesn't have to acquire anything. The relevant change in head has happened much much earlier than r227568. And this is a totally different issue from the vm_phys_alloc_contig issue. Let's not mix them. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 10:01:15 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 270821065672; Sun, 27 Nov 2011 10:01:15 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id D455F8FC1D; Sun, 27 Nov 2011 10:01:14 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1RUbXt-0002ez-KW>; Sun, 27 Nov 2011 11:01:13 +0100 Received: from e178025092.adsl.alicedsl.de ([85.178.25.92] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RUbXt-00014K-FX>; Sun, 27 Nov 2011 11:01:13 +0100 Message-ID: <4ED20A68.90102@zedat.fu-berlin.de> Date: Sun, 27 Nov 2011 11:01:12 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: Current FreeBSD , freebsd-questions@freebsd.org X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig684D912CB72D5F639ABCF49A" X-Originating-IP: 85.178.25.92 Cc: Subject: port astro/stellarium: /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/AngleMeasure/src/AngleMeasure.hpp, : File name too long,*** Error code 1 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, 27 Nov 2011 10:01:15 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig684D912CB72D5F639ABCF49A Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hello, since a couple of days for now I have on FreeBSD 10.0-CURRENT/amd64, clang compiled, the following error updating or reinstalling or installing the port astro/stellarium: =3D=3D=3D> Vulnerability check disabled, database not found =3D=3D=3D> License GPLv2 accepted by the user =3D=3D=3D> Found saved configuration for stellarium-0.11.1 =3D=3D=3D> Extracting for stellarium-0.11.1 =3D> SHA256 Checksum OK for stellarium-0.11.1.tar.gz. =3D=3D=3D> Patching for stellarium-0.11.1 sed: /usr/ports/astro/stellarium/work/stellarium-0.11.1/src/core/external/fixx= 11h.h /usr/ports/astro/stellarium/work/stellarium-0.11.1/src/CMakeLists.txt /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/TelescopeContr= ol/src/TelescopeControl.hpp /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/Oculars/src/Oc= ulars.hpp /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/CompassMarks/s= rc/CompassMarks.hpp /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/TextUserInterf= ace/src/TextUserInterface.hpp /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/Supernovae/src= /Supernovae.hpp /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/SolarSystemEdi= tor/src/SolarSystemEditor.hpp /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/Satellites/src= /Satellites.hpp /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/HelloStelModul= e/src/HelloStelModule.hpp /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/TimeZoneConfig= uration/src/TimeZoneConfiguration.hpp /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/AngleMeasure/s= rc/AngleMeasure.hpp : File name too long *** Error code 1 Stop in /usr/ports/astro/stellarium. *** Error code 1 I have no idea what the error cuases. I tried to delete everything and reinstall, but the error seems to be very sticky. I checked the /usr/ports partition (UFS2, UFS-Journaling on) several time for errors, but it seems to be clean. Any ideas what's going on? Regards, Oliver --------------enig684D912CB72D5F639ABCF49A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO0gpoAAoJEOgBcD7A/5N8ibAH/35VhAnb2v9jlXpiT8DpUbve lv32Wz3lNfk/V0Y27Sb9U+c2VKnpmRYO78uA/jgokntaopxEVljJzhWdKMUplRjf 4iw9BVjDgMCZXgkLCirG6hP2D7ILMxq4SHTaAQ82hYXFSTcEcSPRw95j9XvoY6oy a6KSLw7qdXpa92ZLJ2sDSYP5IGxnB+ypft2D7Ge7my03Op0WX6DimJzGdSJspBq0 HuuMrOme032r6wXli8BgABffjVqMz/rYBWdwa7H+UdcRDO8WEHzw0oN/O+0+iAO1 AODNZ5Sj9zxSrtCu0PbSCwE9E66zUlSgzrUGLHNkIZKmuqgEAc6cJKqpJkisMds= =GOgw -----END PGP SIGNATURE----- --------------enig684D912CB72D5F639ABCF49A-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 10:25:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 646AB106566C for ; Sun, 27 Nov 2011 10:25:44 +0000 (UTC) (envelope-from jbeich@tormail.net) Received: from server2.hudsonvalleyhost.com (server2.hudsonvalleyhost.com [66.7.195.77]) by mx1.freebsd.org (Postfix) with ESMTP id 1A2CE8FC0C for ; Sun, 27 Nov 2011 10:25:43 +0000 (UTC) Received: from tor-exit-router37-readme.formlessnetworking.net ([199.48.147.37]:8624 helo=internal.tormail.net) by server2.hudsonvalleyhost.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.69) (envelope-from ) id 1RUbvY-002OBk-Ar; Sun, 27 Nov 2011 05:25:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tormail.net; s=tm; h=Message-Id:X-TorMail-User:Content-Type:MIME-Version:Date:References:In-Reply-To:Subject:Cc:To:From; bh=jQZ8nOuf815TrrP6wqGzGSthbqcberAH0tYH9E2nZrQ=; b=q24cVDfIhklN+TUYmJD/xiHNezHhrlUUVnGlKpQXF5+y9G/fwxFgkdE7MZBd+LZu56877DFcf04XkuKJG9rd3wYRGGnPNb4Si1xKGTkk4hT89Cy2/Md+EFmu0KKavpdffgc/u1ABsUguJbW5nZe6mgKJUmSimcFG8HzL4+AvJrU=; Received: from jbeich by internal.tormail.net with local (Exim 4.63) (envelope-from ) id 1RUbug-000P7m-2d; Sun, 27 Nov 2011 10:24:47 +0000 From: Jan Beich To: "O. Hartmann" In-Reply-To: <4ED20A68.90102@zedat.fu-berlin.de> (O. Hartmann's message of "Sun, 27 Nov 2011 11:01:12 +0100") References: <4ED20A68.90102@zedat.fu-berlin.de> Date: Sun, 27 Nov 2011 09:24:15 -0100 MIME-Version: 1.0 Content-Type: text/plain X-TorMail-User: jbeich Message-Id: <1RUbug-000P7m-2d@internal.tormail.net> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server2.hudsonvalleyhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tormail.net X-Source: X-Source-Args: X-Source-Dir: Cc: Current, FreeBSD , =?utf-8?B?R8OhYm9yIEvDtnZlc2TDoW4=?= Subject: bsdgrep --null has no effect (Was: port astro/stellarium: /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/AngleMeasure/src/AngleMeasure.hpp, : File name too long, *** Error code 1) 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, 27 Nov 2011 10:25:44 -0000 (add gabor@ to CC, drop questions@) "O. Hartmann" writes: > ===> Patching for stellarium-0.11.1 > sed: > /usr/ports/astro/stellarium/work/stellarium-0.11.1/src/core/external/fixx11h.h > /usr/ports/astro/stellarium/work/stellarium-0.11.1/src/CMakeLists.txt > /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/TelescopeControl/src/TelescopeControl.hpp > /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/Oculars/src/Oculars.hpp > /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/CompassMarks/src/CompassMarks.hpp > /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/TextUserInterface/src/TextUserInterface.hpp > /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/Supernovae/src/Supernovae.hpp > /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/SolarSystemEditor/src/SolarSystemEditor.hpp > /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/Satellites/src/Satellites.hpp > /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/HelloStelModule/src/HelloStelModule.hpp > /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/TimeZoneConfiguration/src/TimeZoneConfiguration.hpp > /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/AngleMeasure/src/AngleMeasure.hpp > : File name too long > *** Error code 1 Do you use bsdgrep? ${GREP} -Rl --null ... | ${XARGS} -0 ... won't work. $ gnugrep -l --null . /usr/include/md*.h | vis /usr/include/md2.h\^@/usr/include/md4.h\^@/usr/include/md5.h\^@ $ bsdgrep -l --null . /usr/include/md*.h | vis /usr/include/md2.h /usr/include/md4.h /usr/include/md5.h From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 11:08:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5F6B106564A; Sun, 27 Nov 2011 11:08:15 +0000 (UTC) (envelope-from jbeich@tormail.net) Received: from server2.hudsonvalleyhost.com (server2.hudsonvalleyhost.com [66.7.195.77]) by mx1.freebsd.org (Postfix) with ESMTP id 907188FC0A; Sun, 27 Nov 2011 11:08:12 +0000 (UTC) Received: from c-824570d5.03-168-6b6c6d1.cust.bredbandsbolaget.se ([213.112.69.130]:35499 helo=internal.tormail.net) by server2.hudsonvalleyhost.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.69) (envelope-from ) id 1RUcaf-002V4E-CM; Sun, 27 Nov 2011 06:08:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tormail.net; s=tm; h=Message-Id:X-TorMail-User:Content-Type:MIME-Version:Date:References:In-Reply-To:Subject:Cc:To:From; bh=PiW0HveVuTliaXZBUkvUQaFjNIasHHfD9z3RFnNWHcY=; b=Hl4XxECH4Ntg3tee/FCxXnentrHgqCw8DLjvkUlKK4x06RvxVVIdgRifXZYhqeVEXwECmyojL//bTjuhQDCobRq+SGIS6MaHP+2PQLEPD4aTAbI42RSjfe5LnHtFFbTKxDuDoU53dHCIPpIZfczqT0kPw5fOjEKVTDrRRdC0hNE=; Received: from jbeich by internal.tormail.net with local (Exim 4.63) (envelope-from ) id 1RUcaG-000Pux-OQ; Sun, 27 Nov 2011 11:07:45 +0000 From: Jan Beich To: "O. Hartmann" In-Reply-To: <1RUbug-000P7m-2d@internal.tormail.net> (Jan Beich's message of "Sun, 27 Nov 2011 09:24:15 -0100") References: <4ED20A68.90102@zedat.fu-berlin.de> <1RUbug-000P7m-2d@internal.tormail.net> Date: Sun, 27 Nov 2011 19:07:30 +0800 MIME-Version: 1.0 Content-Type: text/plain X-TorMail-User: jbeich Message-Id: <1RUcaG-000Pux-OQ@internal.tormail.net> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server2.hudsonvalleyhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tormail.net X-Source: X-Source-Args: X-Source-Dir: Cc: FreeBSD , Current@FreeBSD.ORG, =?utf-8?B?R8OhYm9yIEvDtnZlc2TDoW4=?= Subject: Re: bsdgrep --null has no effect 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, 27 Nov 2011 11:08:16 -0000 Jan Beich writes: > "O. Hartmann" writes: > >> ===> Patching for stellarium-0.11.1 >> sed: >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/src/core/external/fixx11h.h >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/src/CMakeLists.txt >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/TelescopeControl/src/TelescopeControl.hpp >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/Oculars/src/Oculars.hpp >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/CompassMarks/src/CompassMarks.hpp >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/TextUserInterface/src/TextUserInterface.hpp >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/Supernovae/src/Supernovae.hpp >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/SolarSystemEditor/src/SolarSystemEditor.hpp >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/Satellites/src/Satellites.hpp >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/HelloStelModule/src/HelloStelModule.hpp >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/TimeZoneConfiguration/src/TimeZoneConfiguration.hpp >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/AngleMeasure/src/AngleMeasure.hpp >> : File name too long >> *** Error code 1 > > Do you use bsdgrep? ${GREP} -Rl --null ... | ${XARGS} -0 ... won't work. > > $ gnugrep -l --null . /usr/include/md*.h | vis > /usr/include/md2.h\^@/usr/include/md4.h\^@/usr/include/md5.h\^@ > > $ bsdgrep -l --null . /usr/include/md*.h | vis > /usr/include/md2.h > /usr/include/md4.h > /usr/include/md5.h Oops, here is a diff. Non -l/-L case still seems to be broken. $ echo t >a; echo t >b; echo t >c $ gnugrep --null . ? | vis a\^@t b\^@t c\^@t $ bsdgrep --null . ? | vis a\^@:t b\^@:t c\^@:t Index: usr.bin/grep/util.c =================================================================== --- usr.bin/grep/util.c (revision 228003) +++ usr.bin/grep/util.c (working copy) @@ -246,9 +246,9 @@ procfile(const char *fn) printf("%u\n", c); } if (lflag && !qflag && c != 0) - printf("%s\n", fn); + printf("%s%c", fn, nullflag ? 0 : '\n'); if (Lflag && !qflag && c == 0) - printf("%s\n", fn); + printf("%s%c", fn, nullflag ? 0 : '\n'); if (c && !cflag && !lflag && !Lflag && binbehave == BINFILE_BIN && f->binary && !qflag) printf(getstr(8), fn); From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 11:35:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 663BE106564A; Sun, 27 Nov 2011 11:35:29 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 115FF8FC0A; Sun, 27 Nov 2011 11:35:28 +0000 (UTC) Received: by iakl21 with SMTP id l21so10951011iak.13 for ; Sun, 27 Nov 2011 03:35:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+yY3N2ymx2zaISbP+f6MFMz4q+AGw5FxJe5zDUeDasI=; b=WN0QiqTyj49MGE60XTqlxiM2xxnDU1U83NMjUpEUyvRziGLB1cDIJdvwdyexf1pawm 6BYoR0d4kMz7QTiegBKKkm2Q75mcVfaTbk9DGbq0qydjxEM5Xi4mew8Yym+jDEZ220JV 6jaIAJYTh3kzPnATd3JEZ1D01CFBtXeM/Ge+Q= MIME-Version: 1.0 Received: by 10.50.149.165 with SMTP id ub5mr45264785igb.23.1322393728440; Sun, 27 Nov 2011 03:35:28 -0800 (PST) Sender: rmh.aybabtu@gmail.com Received: by 10.42.222.200 with HTTP; Sun, 27 Nov 2011 03:35:28 -0800 (PST) In-Reply-To: <20111127131422.D802@besplex.bde.org> References: <20111123070036.GA29952@thorin> <20111124141821.O932@besplex.bde.org> <20111125150324.G1018@besplex.bde.org> <20111126200749.GA72056@thorin> <20111127131422.D802@besplex.bde.org> Date: Sun, 27 Nov 2011 12:35:28 +0100 X-Google-Sender-Auth: 9XIihjs8RyFaVJU_yXBf9-MEQiw Message-ID: From: Robert Millan To: Bruce Evans Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , Adrian Chadd , freebsd-current@freebsd.org, Warner Losh , freebsd-arch@freebsd.org Subject: Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers (v2) 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, 27 Nov 2011 11:35:29 -0000 Hi Bruce, 2011/11/27 Bruce Evans : > % Index: sys/cam/scsi/scsi_low.h > % =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > % --- sys/cam/scsi/scsi_low.h =C2=A0 (revision 227956) > % +++ sys/cam/scsi/scsi_low.h =C2=A0 (working copy) > % @@ -53,10 +53,10 @@ > % =C2=A0#define =C2=A0 =C2=A0 =C2=A0SCSI_LOW_INTERFACE_XS > % =C2=A0#endif =C2=A0 =C2=A0 =C2=A0 /* __NetBSD__ */ > % % -#ifdef =C2=A0 =C2=A0 __FreeBSD__ > % +#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) > % =C2=A0#define =C2=A0 =C2=A0 =C2=A0SCSI_LOW_INTERFACE_CAM > % =C2=A0#define =C2=A0 =C2=A0 =C2=A0CAM > % -#endif =C2=A0 =C2=A0 =C2=A0 /* __FreeBSD__ */ > % +#endif /* __FreeBSD__ || __FreeBSD_kernel__ */ > > It still has the whitespace-after tab style change for cam. My initial patch didn't have it. Precisely I thought that you requested this in your first mail. Did I missunderstand? > % Index: sys/dev/firewire/firewirereg.h > % =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > % --- sys/dev/firewire/firewirereg.h =C2=A0 =C2=A0(revision 227956) > % +++ sys/dev/firewire/firewirereg.h =C2=A0 =C2=A0(working copy) > % @@ -75,7 +75,8 @@ > % =C2=A0}; > % % =C2=A0struct firewire_softc { > % -#if defined(__FreeBSD__) && __FreeBSD_version >=3D 500000 > % +#if (defined(__FreeBSD__) || defined(__FreeBSD_kernel__)) && \ > % + =C2=A0 =C2=A0__FreeBSD_version >=3D 500000 > % =C2=A0 =C2=A0 =C2=A0 struct cdev *dev; > % =C2=A0#endif > % =C2=A0 =C2=A0 =C2=A0 struct firewire_comm *fc; > > Here is a pre-existing problem that you didn't fix on a line that you > changed. Yes. I didn't say I would fix all pre-existing problems in lines that need to be modified. In some cases I did, and in some cases I opted to preserve the status quo. > __FreeBSD_version it is impossible to determine if the data structure > has new fields like the cdev in it. =C2=A0 is a prerequisite > for almost all kernel .c files, so this prerequisite should be satisfied > automatically for them, Earlier you asked not to include . If is a prerequisite, why not just include it then? From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 12:38:27 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 296A51065670 for ; Sun, 27 Nov 2011 12:38:27 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id D057D8FC13 for ; Sun, 27 Nov 2011 12:38:26 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1RUe01-0001zt-LU>; Sun, 27 Nov 2011 13:38:25 +0100 Received: from e178025092.adsl.alicedsl.de ([85.178.25.92] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RUe01-0008Sd-Ga>; Sun, 27 Nov 2011 13:38:25 +0100 Message-ID: <4ED22F3B.6070707@zedat.fu-berlin.de> Date: Sun, 27 Nov 2011 13:38:19 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: Jan Beich References: <4ED20A68.90102@zedat.fu-berlin.de> <1RUbug-000P7m-2d@internal.tormail.net> In-Reply-To: <1RUbug-000P7m-2d@internal.tormail.net> X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9EFE780620D511E81E047DC4" X-Originating-IP: 85.178.25.92 Cc: FreeBSD , =?ISO-8859-15?Q?G=E1bor_K=F6?=, =?ISO-8859-15?Q?vesd=E1n?= Subject: Re: bsdgrep --null has no effect (Was: port astro/stellarium: /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/AngleMeasure/src/AngleMeasure.hpp, : File name too long, *** Error code 1) 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, 27 Nov 2011 12:38:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9EFE780620D511E81E047DC4 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Am 11/27/11 11:24, schrieb Jan Beich: > (add gabor@ to CC, drop questions@) >=20 > "O. Hartmann" writes: >=20 >> =3D=3D=3D> Patching for stellarium-0.11.1 >> sed: >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/src/core/external/f= ixx11h.h >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/src/CMakeLists.txt >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/TelescopeCo= ntrol/src/TelescopeControl.hpp >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/Oculars/src= /Oculars.hpp >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/CompassMark= s/src/CompassMarks.hpp >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/TextUserInt= erface/src/TextUserInterface.hpp >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/Supernovae/= src/Supernovae.hpp >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/SolarSystem= Editor/src/SolarSystemEditor.hpp >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/Satellites/= src/Satellites.hpp >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/HelloStelMo= dule/src/HelloStelModule.hpp >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/TimeZoneCon= figuration/src/TimeZoneConfiguration.hpp >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/AngleMeasur= e/src/AngleMeasure.hpp >> : File name too long >> *** Error code 1 >=20 > Do you use bsdgrep? ${GREP} -Rl --null ... | ${XARGS} -0 ... won't work= =2E >=20 > $ gnugrep -l --null . /usr/include/md*.h | vis > /usr/include/md2.h\^@/usr/include/md4.h\^@/usr/include/md5.h\^@ >=20 > $ bsdgrep -l --null . /usr/include/md*.h | vis > /usr/include/md2.h > /usr/include/md4.h > /usr/include/md5.h Yes, I use bsdgrep. The switch is set to use it via /etc/src.conf. Oliver P.S. Pretty fast, thanks ;-) --------------enig9EFE780620D511E81E047DC4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO0i9AAAoJEOgBcD7A/5N8ZzoIAIQtJdRN0Ff12Kp2KL5r5Wnw jhyOjjDtfOS0oBIyDGn2xD5cu7HsE5LZSrz5cZcUJ/VXmh8GdFMDKqOdlEfmLmc+ 8gGAhFt50h44mgg6GbnFPN/grPtbN2xPvWwvYPI122XSPpevzod0eKYm9Pritqxb Wvc607ZbQ1ESSnZMgayZPl0CXupuFv+NdFcIpU8VfOGCgBc1OAyxI5fzdR4h7BIE 5WJfnZkKYF/I+xz3p300E20pKXTDB7KkcnCa8c0OBK8+SP9OUMMUDQH3rgnWVCGI aOyi00TJnUtgLfP0EutzNA5Xd29mkHu1C2N4AUMYu6DXKdffk8dsKVxTS/VNZT4= =MdhQ -----END PGP SIGNATURE----- --------------enig9EFE780620D511E81E047DC4-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 12:43:37 2011 Return-Path: Delivered-To: Current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86C2D106566C for ; Sun, 27 Nov 2011 12:43:37 +0000 (UTC) (envelope-from jbeich@tormail.net) Received: from server2.hudsonvalleyhost.com (server2.hudsonvalleyhost.com [66.7.195.77]) by mx1.freebsd.org (Postfix) with ESMTP id 3F6218FC15 for ; Sun, 27 Nov 2011 12:43:36 +0000 (UTC) Received: from c-824570d5.03-168-6b6c6d1.cust.bredbandsbolaget.se ([213.112.69.130]:35499 helo=internal.tormail.net) by server2.hudsonvalleyhost.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.69) (envelope-from ) id 1RUcaf-002V4E-CM; Sun, 27 Nov 2011 06:08:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tormail.net; s=tm; h=Message-Id:X-TorMail-User:Content-Type:MIME-Version:Date:References:In-Reply-To:Subject:Cc:To:From; bh=PiW0HveVuTliaXZBUkvUQaFjNIasHHfD9z3RFnNWHcY=; b=Hl4XxECH4Ntg3tee/FCxXnentrHgqCw8DLjvkUlKK4x06RvxVVIdgRifXZYhqeVEXwECmyojL//bTjuhQDCobRq+SGIS6MaHP+2PQLEPD4aTAbI42RSjfe5LnHtFFbTKxDuDoU53dHCIPpIZfczqT0kPw5fOjEKVTDrRRdC0hNE=; Received: from jbeich by internal.tormail.net with local (Exim 4.63) (envelope-from ) id 1RUcaG-000Pux-OQ; Sun, 27 Nov 2011 11:07:45 +0000 From: Jan Beich To: "O. Hartmann" In-Reply-To: <1RUbug-000P7m-2d@internal.tormail.net> (Jan Beich's message of "Sun, 27 Nov 2011 09:24:15 -0100") References: <4ED20A68.90102@zedat.fu-berlin.de> <1RUbug-000P7m-2d@internal.tormail.net> Date: Sun, 27 Nov 2011 19:07:30 +0800 MIME-Version: 1.0 Content-Type: text/plain X-TorMail-User: jbeich Message-Id: <1RUcaG-000Pux-OQ@internal.tormail.net> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server2.hudsonvalleyhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tormail.net X-Source: X-Source-Args: X-Source-Dir: Cc: FreeBSD , Current@FreeBSD.ORG, =?utf-8?B?R8OhYm9yIEvDtnZlc2TDoW4=?= Subject: Re: bsdgrep --null has no effect 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, 27 Nov 2011 12:43:37 -0000 Jan Beich writes: > "O. Hartmann" writes: > >> ===> Patching for stellarium-0.11.1 >> sed: >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/src/core/external/fixx11h.h >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/src/CMakeLists.txt >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/TelescopeControl/src/TelescopeControl.hpp >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/Oculars/src/Oculars.hpp >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/CompassMarks/src/CompassMarks.hpp >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/TextUserInterface/src/TextUserInterface.hpp >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/Supernovae/src/Supernovae.hpp >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/SolarSystemEditor/src/SolarSystemEditor.hpp >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/Satellites/src/Satellites.hpp >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/HelloStelModule/src/HelloStelModule.hpp >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/TimeZoneConfiguration/src/TimeZoneConfiguration.hpp >> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/AngleMeasure/src/AngleMeasure.hpp >> : File name too long >> *** Error code 1 > > Do you use bsdgrep? ${GREP} -Rl --null ... | ${XARGS} -0 ... won't work. > > $ gnugrep -l --null . /usr/include/md*.h | vis > /usr/include/md2.h\^@/usr/include/md4.h\^@/usr/include/md5.h\^@ > > $ bsdgrep -l --null . /usr/include/md*.h | vis > /usr/include/md2.h > /usr/include/md4.h > /usr/include/md5.h Oops, here is a diff. Non -l/-L case still seems to be broken. $ echo t >a; echo t >b; echo t >c $ gnugrep --null . ? | vis a\^@t b\^@t c\^@t $ bsdgrep --null . ? | vis a\^@:t b\^@:t c\^@:t Index: usr.bin/grep/util.c =================================================================== --- usr.bin/grep/util.c (revision 228003) +++ usr.bin/grep/util.c (working copy) @@ -246,9 +246,9 @@ procfile(const char *fn) printf("%u\n", c); } if (lflag && !qflag && c != 0) - printf("%s\n", fn); + printf("%s%c", fn, nullflag ? 0 : '\n'); if (Lflag && !qflag && c == 0) - printf("%s\n", fn); + printf("%s%c", fn, nullflag ? 0 : '\n'); if (c && !cflag && !lflag && !Lflag && binbehave == BINFILE_BIN && f->binary && !qflag) printf(getstr(8), fn); From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 12:58:21 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B568106564A for ; Sun, 27 Nov 2011 12:58:21 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theravensnest.org [109.169.23.128]) by mx1.freebsd.org (Postfix) with ESMTP id DC9818FC12 for ; Sun, 27 Nov 2011 12:58:20 +0000 (UTC) Received: from [192.168.0.2] (cpc2-cwma5-0-0-cust875.7-3.cable.virginmedia.com [86.11.39.108]) (authenticated bits=0) by theravensnest.org (8.14.4/8.14.4) with ESMTP id pARCwJUV077003 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sun, 27 Nov 2011 12:58:19 GMT (envelope-from theraven@FreeBSD.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: David Chisnall In-Reply-To: <4ED1719C.4040500@gmail.com> Date: Sun, 27 Nov 2011 12:58:16 +0000 Content-Transfer-Encoding: 7bit Message-Id: <846F3BBB-53EE-4C0E-A2DB-A653A8FF13D7@FreeBSD.org> References: <55EF58C0-0E9A-4701-B309-95317913A384@FreeBSD.org> <4ED1719C.4040500@gmail.com> To: Niclas Zeising X-Mailer: Apple Mail (2.1251.1) Cc: current@FreeBSD.org Subject: Re: Heads up: New C++ stack 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, 27 Nov 2011 12:58:21 -0000 On 26 Nov 2011, at 23:09, Niclas Zeising wrote: > This is great news! Thank you very much for undertaking this work. Just > a question, is there a wiki page with these instructions, or a wiki page > related to this work where these instructions can be added? If they're > not on the wiki, I can do the work of getting them there, just point to > where they're best suited. They weren't, but they are now: http://wiki.freebsd.org/NewC++Stack Linked to from: http://wiki.freebsd.org/GPLinBase Please feel free to improve either page. David From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 13:06:05 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 772DF106566B for ; Sun, 27 Nov 2011 13:06:05 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id ADF158FC0C for ; Sun, 27 Nov 2011 13:06:04 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id pARBv0a4000589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 27 Nov 2011 12:57:00 +0100 Received: from portgus.lan ([80.31.114.86]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id pARBuvd0016100 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 27 Nov 2011 12:56:59 +0100 Message-ID: <4ED22583.4040801@entel.upc.edu> Date: Sun, 27 Nov 2011 12:56:51 +0100 From: =?UTF-8?B?R3VzdGF1IFDDqXJleg==?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111111 Thunderbird/8.0 MIME-Version: 1.0 To: Andriy Gapon References: <4ECF7440.4070300@entel.upc.edu> <4ECF8F05.8000007@protected-networks.net> <4ED0C40D.5010307@entel.upc.edu> <4ED0D963.1030702@entel.upc.edu> <4ED0DF1F.6090901@FreeBSD.org> <20111126163343.GA9150@reks> <4ED1943A.90707@protected-networks.net> <4ED1F7AE.3030105@FreeBSD.org> In-Reply-To: <4ED1F7AE.3030105@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.70 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Sun, 27 Nov 2011 12:57:01 +0100 (CET) Cc: gleb.kurtsou@gmail.com, Michael Butler , freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464} 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, 27 Nov 2011 13:06:05 -0000 >>> >>> Using new vm_page_alloc_contig() may be a better option here. Can't help >>> with patch, stuck with pre Nov 15 CURRENT myself. >> Ok. The third parameter of vm_page_alloc_contig says the caller has to specify an allocation class. Which one should we use? Also the vm_object_t and the vm_memattr_t are are beyond my knowledge. I'm checking Arch Book but I have no clue. Here I'm lost. > Not "also", but instead. And only for managed pages. For unmanaged pages a > caller doesn't have to acquire anything. > The relevant change in head has happened much much earlier than r227568. > > And this is a totally different issue from the vm_phys_alloc_contig issue. > Let's not mix them. > I changed the code hold the lock of vm_page_queue_free_mtx. The machine them panic because of a page not present. http://pastebin.com/hGHCJqEP I don't understand why the bt doesn't contain the complete trace of the vbox kmod. That would give us a complete clue of what is going on. OTOH this bt makes me think that Gleb's suggestion is correct and vm_page_alloc_contig would appear to be a better option. However I'm not sure, what do you think? From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 14:38:02 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA9571065670; Sun, 27 Nov 2011 14:38:02 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6D2AB8FC0A; Sun, 27 Nov 2011 14:38:02 +0000 (UTC) Received: by ggnk5 with SMTP id k5so6451998ggn.13 for ; Sun, 27 Nov 2011 06:38:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.193.99 with SMTP id hn3mr7950192obc.61.1322403278459; Sun, 27 Nov 2011 06:14:38 -0800 (PST) Received: by 10.182.187.8 with HTTP; Sun, 27 Nov 2011 06:14:38 -0800 (PST) X-Originating-IP: [93.221.173.183] In-Reply-To: <846F3BBB-53EE-4C0E-A2DB-A653A8FF13D7@FreeBSD.org> References: <55EF58C0-0E9A-4701-B309-95317913A384@FreeBSD.org> <4ED1719C.4040500@gmail.com> <846F3BBB-53EE-4C0E-A2DB-A653A8FF13D7@FreeBSD.org> Date: Sun, 27 Nov 2011 15:14:38 +0100 Message-ID: From: "C. P. Ghost" To: David Chisnall Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: Heads up: New C++ stack 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, 27 Nov 2011 14:38:02 -0000 On Sun, Nov 27, 2011 at 1:58 PM, David Chisnall wrot= e: > On 26 Nov 2011, at 23:09, Niclas Zeising wrote: > >> This is great news! Thank you very much for undertaking this work. =A0Ju= st >> a question, is there a wiki page with these instructions, or a wiki page >> related to this work where these instructions can be added? =A0If they'r= e >> not on the wiki, I can do the work of getting them there, just point to >> where they're best suited. > > They weren't, but they are now: > > http://wiki.freebsd.org/NewC++Stack > > Linked to from: > > http://wiki.freebsd.org/GPLinBase > > Please feel free to improve either page. Thank you! That's awesome. Do we actually have some ports of these components, so we could try them out on 8.2-STABLE and later? Also... how compatible is the new C++ stack w.r.t. the ports? Have you tried a tinderbox run? > David -cpghost. --=20 Cordula's Web. http://www.cordula.ws/ From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 15:40:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C3A5106564A; Sun, 27 Nov 2011 15:40:17 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id CAC4A8FC16; Sun, 27 Nov 2011 15:40:16 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1RUgq0-0003fq-06>; Sun, 27 Nov 2011 16:40:16 +0100 Received: from e178025092.adsl.alicedsl.de ([85.178.25.92] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RUgpz-0000GC-Rg>; Sun, 27 Nov 2011 16:40:15 +0100 Message-ID: <4ED259DF.5030008@zedat.fu-berlin.de> Date: Sun, 27 Nov 2011 16:40:15 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: Current FreeBSD , freebsd-questions@freebsd.org X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7F7346680F922ED1AB4D8D0B" X-Originating-IP: 85.178.25.92 Cc: Subject: multimedia/vlc: no graphical interface on FreeBSD 9 and 10 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, 27 Nov 2011 15:40:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7F7346680F922ED1AB4D8D0B Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Since a while, vlc on my FreeBSD 10 and FreeBSD 9 boxes do not show a graphical interface anymore. Compiling multimedia/vlc works, either with the legacy gcc or clang. But either way I compile vlc, the result is always the same: no GUI. Instead, I receive the below show message: VLC media player 1.1.12 The Luggage (revision exported) Blocked: call to unsetenv("DBUS_ACTIVATION_ADDRESS") Blocked: call to unsetenv("DBUS_ACTIVATION_BUS_TYPE") [0x802080a70] main interface error: no suitable interface module [0x8020691b0] main libvlc error: interface "globalhotkeys,none" initialization failed [0x8020691b0] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. [0x802080a70] main interface error: option qt-volume-complete does not ex= ist [0x802080a70] skins2 interface error: no suitable dialogs provider found (hint: compile the qt4 plugin, and make sure it is loaded properly) [0x802080a70] skins2 interface error: cannot instanciate qt4 dialogs provider I tried several times to recompile everything vlc depends on, but with not success. I also tried to delete every configuration file vlc created in the past and my now suffer from legzy options, but that hadn't any effect - as far as I could catch each config file. Is anybody out here having had the same or similar problem and solved it?= Regards, Oliver --------------enig7F7346680F922ED1AB4D8D0B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO0lnfAAoJEOgBcD7A/5N8+s0H+QFUTPxJEFtn1m7cuUUKcDaL IeAPg0pLq0U4dgxcgcwYYae99lh13INqZwdDQM00iKVdCm/hR7CKSeAvdk7V2QRe iC1iriM7kPclkmDZYnPb8COP71zCjXElQIuLRVR6qGfgieQ7iAINUiR4S8xqJgPc QlWB7MNKxCYomFTjtG/lEwC7QzjZXn44hEw5gSROdAmAdEQeBUYC/LS5Cm92irUv S0nMeDi/WHgWbMFKdQqhwescb/jT0wapn0ega0iJJsI7ZfN3CXTDOLI6/VK9hb9t PKKKxboC1t9oJGPUVWQJMNNVXFqcWEtpuskBbBUviMRK5FBnwExqNGosZWeL3Eg= =cVbU -----END PGP SIGNATURE----- --------------enig7F7346680F922ED1AB4D8D0B-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 15:45:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 15A471065679; Sun, 27 Nov 2011 15:45:36 +0000 (UTC) Date: Sun, 27 Nov 2011 15:45:36 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20111127154536.GA54043@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: freebsd-net@freebsd.org Subject: possible array out of bounds access in sys/netinet/sctp_output.c 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, 27 Nov 2011 15:45:36 -0000 hi there, i've been playing with clang tot and noticed the following error: /usr/local/bin/clang -c -O3 -pipe -fno-inline-functions -fno-strict-aliasing -march=core2 -std=c99 -g -fdiagnostics-show-option -fformat-extensions -Wall -Wcast-qual -Winline -Wmissing-include-dirs -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wredundant-decls -Wstrict-prototypes -Wundef -Wno-pointer-sign -nostdinc -I. -I/usr/git-freebsd-head/sys -I/usr/git-freebsd-head/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wno-error=tautological-compare -Wno-error=shift-count-negative -Wno-error=shift-count-overflow -Wno-error=shift-overflow -Wno-error=conversion -Wno-error=empty-body -Wno-error=gnu-designator -Wno-error=format -Wno-error=format-invalid-specifier -Wno-error=format-extra-args -Werror /usr/git-freebsd-head/sys/netinet/sctp_output.c clang: warning: argument unused during compilation: '-fformat-extensions' /usr/git-freebsd-head/sys/netinet/sctp_output.c:4685:2: error: array index 1 is past the end of the array (which contains 1 element) [-Werror,-Warray-bounds] sup_addr->addr_type[1] = htons(SCTP_IPV6_ADDRESS); ^ ~ /usr/git-freebsd-head/sys/netinet/sctp_header.h:84:2: note: array 'addr_type' declared here uint16_t addr_type[SCTP_ARRAY_MIN_LEN]; /* array of supported address ^ 1 error generated. *** Error code 1 Stop in /usr/obj/usr/git-freebsd-head/sys/GENERIC. *** Error code 1 Stop in /usr/git-freebsd-head. *** Error code 1 Stop in /usr/git-freebsd-head. this is from a GENERIC kernel build (so INET + INET6) for amd64. is this a false positive, or is length(sup_addr->addr_type) really == 1, thus making sup_addr->addr_type[1] an illegal access? cheers. alex From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 15:45:56 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE9971065704; Sun, 27 Nov 2011 15:45:56 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 84CFF8FC1D; Sun, 27 Nov 2011 15:45:56 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1RUgcz-0002FY-Dq>; Sun, 27 Nov 2011 16:26:49 +0100 Received: from e178025092.adsl.alicedsl.de ([85.178.25.92] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RUgcz-000815-9H>; Sun, 27 Nov 2011 16:26:49 +0100 Message-ID: <4ED256B1.3050408@zedat.fu-berlin.de> Date: Sun, 27 Nov 2011 16:26:41 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: "C. P. Ghost" References: <55EF58C0-0E9A-4701-B309-95317913A384@FreeBSD.org> <4ED1719C.4040500@gmail.com> <846F3BBB-53EE-4C0E-A2DB-A653A8FF13D7@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7CD5E9EA9A76F2BDE858FD22" X-Originating-IP: 85.178.25.92 Cc: David Chisnall , current@freebsd.org Subject: Re: Heads up: New C++ stack 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, 27 Nov 2011 15:45:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7CD5E9EA9A76F2BDE858FD22 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 11/27/11 15:14, schrieb C. P. Ghost: > On Sun, Nov 27, 2011 at 1:58 PM, David Chisnall = wrote: >> On 26 Nov 2011, at 23:09, Niclas Zeising wrote: >> >>> This is great news! Thank you very much for undertaking this work. J= ust >>> a question, is there a wiki page with these instructions, or a wiki p= age >>> related to this work where these instructions can be added? If they'= re >>> not on the wiki, I can do the work of getting them there, just point = to >>> where they're best suited. >> >> They weren't, but they are now: >> >> http://wiki.freebsd.org/NewC++Stack >> >> Linked to from: >> >> http://wiki.freebsd.org/GPLinBase >> >> Please feel free to improve either page. >=20 > Thank you! That's awesome. >=20 > Do we actually have some ports of these components, so we > could try them out on 8.2-STABLE and later? >=20 > Also... how compatible is the new C++ stack w.r.t. the ports? > Have you tried a tinderbox run? >=20 >> David >=20 > -cpghost. >=20 Why is the knob WITH_LIBCPLUSPLUS=3Dyes located in /etc/make.conf and not in /etc/src.conf? Regards, Oliver --------------enig7CD5E9EA9A76F2BDE858FD22 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO0la4AAoJEOgBcD7A/5N8u3IIAIK3FAT9L7g+JSxN1sK6UkGx y+LoiIQKtQ/rHgeWqsAH3Atv4tpUH5Bmn85arY5JYwLNWCfdNrNqzx0N/fmjj9DI t8L1IuBVjIoTvWWQL/2MMeXoe6EB3AAcedGLuwm+N1jCmNoIasvVVG4msJuzTcLj KleqUgytpMbexZtirbOnD1ojKgB/hitpeHvcHTwRg+hjGtBASzw4dr3dA+YtBQXF /KUBfjzX8JsvwEMxZ8K1aGOdVmwIdZ3an7lUaXLCmSGMBTAf6XBUzvQ1jr7tsDB+ q4NWMjxwJVhalP8Ihw+tvbtcHciKamPwgxJsgjhvs/MY9ThN25LFy6jIcQQD7y4= =Ym7Y -----END PGP SIGNATURE----- --------------enig7CD5E9EA9A76F2BDE858FD22-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 15:54:27 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A85F11065677 for ; Sun, 27 Nov 2011 15:54:27 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from theravensnest.org (theravensnest.org [109.169.23.128]) by mx1.freebsd.org (Postfix) with ESMTP id 30DBF8FC1C for ; Sun, 27 Nov 2011 15:54:26 +0000 (UTC) Received: from [192.168.0.2] (cpc2-cwma5-0-0-cust875.7-3.cable.virginmedia.com [86.11.39.108]) (authenticated bits=0) by theravensnest.org (8.14.4/8.14.4) with ESMTP id pARFsOg0078115 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sun, 27 Nov 2011 15:54:25 GMT (envelope-from theraven@freebsd.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: David Chisnall In-Reply-To: <4ED256B1.3050408@zedat.fu-berlin.de> Date: Sun, 27 Nov 2011 15:54:19 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <0C4788C6-DA78-4FD5-9BF8-6A474FA4030C@freebsd.org> References: <55EF58C0-0E9A-4701-B309-95317913A384@FreeBSD.org> <4ED1719C.4040500@gmail.com> <846F3BBB-53EE-4C0E-A2DB-A653A8FF13D7@FreeBSD.org> <4ED256B1.3050408@zedat.fu-berlin.de> To: "O. Hartmann" X-Mailer: Apple Mail (2.1251.1) Cc: "C. P. Ghost" , current@freebsd.org Subject: Re: Heads up: New C++ stack 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, 27 Nov 2011 15:54:27 -0000 On 27 Nov 2011, at 15:26, O. Hartmann wrote: > Why is the knob > WITH_LIBCPLUSPLUS=3Dyes > located in /etc/make.conf and not in /etc/src.conf? Sorry, it is in src.conf, I was thinking about enabling clang. Or = possibly not thinking at all. It's Sunday, so thinking is optional... David= From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 16:16:06 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D82221065672; Sun, 27 Nov 2011 16:16:06 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 8D4508FC1B; Sun, 27 Nov 2011 16:16:06 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1RUhOf-0007Pq-Q3>; Sun, 27 Nov 2011 17:16:05 +0100 Received: from e178025092.adsl.alicedsl.de ([85.178.25.92] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RUhOf-00024W-Lf>; Sun, 27 Nov 2011 17:16:05 +0100 Message-ID: <4ED26245.6010104@zedat.fu-berlin.de> Date: Sun, 27 Nov 2011 17:16:05 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: David Chisnall References: <55EF58C0-0E9A-4701-B309-95317913A384@FreeBSD.org> <4ED1719C.4040500@gmail.com> <846F3BBB-53EE-4C0E-A2DB-A653A8FF13D7@FreeBSD.org> <4ED256B1.3050408@zedat.fu-berlin.de> <0C4788C6-DA78-4FD5-9BF8-6A474FA4030C@freebsd.org> In-Reply-To: <0C4788C6-DA78-4FD5-9BF8-6A474FA4030C@freebsd.org> X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig16357F74103DE551594C1560" X-Originating-IP: 85.178.25.92 Cc: "C. P. Ghost" , current@freebsd.org Subject: Re: Heads up: New C++ stack 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, 27 Nov 2011 16:16:06 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig16357F74103DE551594C1560 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 11/27/11 16:54, schrieb David Chisnall: > On 27 Nov 2011, at 15:26, O. Hartmann wrote: >=20 >> Why is the knob >> WITH_LIBCPLUSPLUS=3Dyes >> located in /etc/make.conf and not in /etc/src.conf? >=20 > Sorry, it is in src.conf, I was thinking about enabling clang. Or poss= ibly not thinking at all. It's Sunday, so thinking is optional... >=20 > David All right ;-) So the logic is still intact. Oliver --------------enig16357F74103DE551594C1560 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO0mJFAAoJEOgBcD7A/5N8teYIALpxLXM6ep9vZB48FSgUvTK3 XgwcLpSr0DR1FJjUwMyYZQCzODY3+b9zA1rG5fFvKJokbSSSTXDgoUkiDYQL4PtL ISvwoqS3sJJGnhGL7s/X0ZVQaxxK5RujrKlRo8iT4+G1borTChpT7KsigMnu0AB/ Y8W7+WVvh5j5u1lgIWujyY6J5VjPk2c+yHjcu5FDoKvz7iCYNl31d1Y+jnmILq6w ULfV5ADGBedl4d5+v9uWWdJMDGCm1+aV782ryLqo3g4yzo+wu8TqPOfWH2SnkqZn nIuMfi0LaJfa6F8wmWGLotreLApXcdcu+npVMmR8VfA1TD3fLNtY4ZJ6j20R57U= =dfHm -----END PGP SIGNATURE----- --------------enig16357F74103DE551594C1560-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 16:24:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 507E01065675; Sun, 27 Nov 2011 16:24:32 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id E27F08FC15; Sun, 27 Nov 2011 16:24:31 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 405041DD627; Sun, 27 Nov 2011 17:24:31 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 1909528468; Sun, 27 Nov 2011 17:24:31 +0100 (CET) Date: Sun, 27 Nov 2011 17:24:31 +0100 From: Jilles Tjoelker To: Alexander Best Message-ID: <20111127162430.GA95971@stack.nl> References: <20111127154536.GA54043@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111127154536.GA54043@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: possible array out of bounds access in sys/netinet/sctp_output.c 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, 27 Nov 2011 16:24:32 -0000 On Sun, Nov 27, 2011 at 03:45:36PM +0000, Alexander Best wrote: > i've been playing with clang tot and noticed the following error: > /usr/local/bin/clang -c -O3 -pipe -fno-inline-functions -fno-strict-aliasing -march=core2 -std=c99 -g -fdiagnostics-show-option -fformat-extensions -Wall -Wcast-qual -Winline -Wmissing-include-dirs -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wredundant-decls -Wstrict-prototypes -Wundef -Wno-pointer-sign -nostdinc -I. -I/usr/git-freebsd-head/sys -I/usr/git-freebsd-head/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wno-error=tautological-compare -Wno-error=shift-count-negative -Wno-error=shift-count-overflow -Wno-error=shift-overflow -Wno-error=conversion -Wno-error=empty-body -Wno-error=gnu-designator -Wno-error=format -Wno-error=format-invalid-specifier -Wno-error=format-extra-args -Werror /usr/git-freebsd-head/sys/netinet/sctp_output.c > clang: warning: argument unused during compilation: '-fformat-extensions' > /usr/git-freebsd-head/sys/netinet/sctp_output.c:4685:2: error: array index 1 is past the end of the array (which contains 1 element) [-Werror,-Warray-bounds] > sup_addr->addr_type[1] = htons(SCTP_IPV6_ADDRESS); > ^ ~ > /usr/git-freebsd-head/sys/netinet/sctp_header.h:84:2: note: array 'addr_type' declared here > uint16_t addr_type[SCTP_ARRAY_MIN_LEN]; /* array of supported address > ^ > 1 error generated. > *** Error code 1 > > Stop in /usr/obj/usr/git-freebsd-head/sys/GENERIC. > *** Error code 1 > > Stop in /usr/git-freebsd-head. > *** Error code 1 > > Stop in /usr/git-freebsd-head. > this is from a GENERIC kernel build (so INET + INET6) for amd64. is this a > false positive, or is length(sup_addr->addr_type) really == 1, thus making > sup_addr->addr_type[1] an illegal access? This is the fairly common construct of a variable-length array at the end of a struct. With C89, this was not allowed but defining one element and allocating more elements worked in most implementations. C99 recognized this need and created a way to do it, which looks like uint16_t addr_type[];. This adds any necessary padding and allows access to however many elements have been allocated. Also, if it is not at the end of a struct it is an error. Using this new construct requires code changes because some code such as fairly close to the error message relies on the size of the one element already in the struct. -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 16:56:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 060F21065672 for ; Sun, 27 Nov 2011 16:56:36 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 899CD8FC1C for ; Sun, 27 Nov 2011 16:56:35 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so421769vbb.13 for ; Sun, 27 Nov 2011 08:56:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=t3W7imdStAu9sFkDVoZTG5cEDafRndLd7v4MSy2IcNs=; b=k/Bm9akvJ/OYW9OP330ML7eMiUajr5/VntIlj1yIwWzG1GU+mOiowvSC7RG0v125Zh px1flSiLfyTpFbgjXW4AaMJt7MZ4rv1PIegi1kyHZv481JEn2XfsxKk7YiclSC64WD0P QCufaMO+wyk07Rne3JeG3zYoO6/5Paj7EO50M= MIME-Version: 1.0 Received: by 10.52.92.49 with SMTP id cj17mr30705081vdb.35.1322412994421; Sun, 27 Nov 2011 08:56:34 -0800 (PST) Received: by 10.52.164.164 with HTTP; Sun, 27 Nov 2011 08:56:34 -0800 (PST) In-Reply-To: <20111127162430.GA95971@stack.nl> References: <20111127154536.GA54043@freebsd.org> <20111127162430.GA95971@stack.nl> Date: Sun, 27 Nov 2011 17:56:34 +0100 Message-ID: From: Davide Italiano To: Jilles Tjoelker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexander Best , freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: Re: possible array out of bounds access in sys/netinet/sctp_output.c 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, 27 Nov 2011 16:56:36 -0000 On Sun, Nov 27, 2011 at 5:24 PM, Jilles Tjoelker wrote: > On Sun, Nov 27, 2011 at 03:45:36PM +0000, Alexander Best wrote: >> i've been playing with clang tot and noticed the following error: > >> /usr/local/bin/clang -c -O3 -pipe -fno-inline-functions -fno-strict-alia= sing -march=3Dcore2 -std=3Dc99 -g -fdiagnostics-show-option -fformat-extens= ions -Wall =A0-Wcast-qual -Winline -Wmissing-include-dirs =A0-Wmissing-prot= otypes -Wnested-externs -Wpointer-arith =A0-Wredundant-decls -Wstrict-proto= types -Wundef =A0-Wno-pointer-sign -nostdinc =A0-I. -I/usr/git-freebsd-head= /sys -I/usr/git-freebsd-head/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTIO= N_HEADERS -include opt_global.h =A0-fno-omit-frame-pointer -mno-aes -mno-av= x -mcmodel=3Dkernel -mno-red-zone -mno-mmx -msoft-float =A0-fno-asynchronou= s-unwind-tables -ffreestanding -Wno-error=3Dtautological-compare -Wno-error= =3Dshift-count-negative =A0-Wno-error=3Dshift-count-overflow -Wno-error=3Ds= hift-overflow -Wno-error=3Dconversion =A0-Wno-error=3Dempty-body -Wno-error= =3Dgnu-designator -Wno-error=3Dformat =A0-Wno-error=3Dformat-invalid-specif= ier -Wno-error=3Dformat-extra-args -Werror =A0/usr/git-freebsd-head/sys/net= inet/sctp_output.c >> clang: warning: argument unused during compilation: '-fformat-extensions= ' >> /usr/git-freebsd-head/sys/netinet/sctp_output.c:4685:2: error: array ind= ex 1 is past the end of the array (which contains 1 element) [-Werror,-Warr= ay-bounds] >> =A0 =A0 =A0 =A0 sup_addr->addr_type[1] =3D htons(SCTP_IPV6_ADDRESS); >> =A0 =A0 =A0 =A0 ^ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ~ >> /usr/git-freebsd-head/sys/netinet/sctp_header.h:84:2: note: array 'addr_= type' declared here >> =A0 =A0 =A0 =A0 uint16_t addr_type[SCTP_ARRAY_MIN_LEN]; /* array of supp= orted address >> =A0 =A0 =A0 =A0 ^ >> 1 error generated. >> *** Error code 1 >> >> Stop in /usr/obj/usr/git-freebsd-head/sys/GENERIC. >> *** Error code 1 >> >> Stop in /usr/git-freebsd-head. >> *** Error code 1 >> >> Stop in /usr/git-freebsd-head. > >> this is from a GENERIC kernel build (so INET + INET6) for amd64. is this= a >> false positive, or is length(sup_addr->addr_type) really =3D=3D 1, thus = making >> sup_addr->addr_type[1] an illegal access? > > This is the fairly common construct of a variable-length array at the > end of a struct. With C89, this was not allowed but defining one element > and allocating more elements worked in most implementations. C99 > recognized this need and created a way to do it, which looks like > uint16_t addr_type[];. This adds any necessary padding and allows access > to however many elements have been allocated. Also, if it is not at the > end of a struct it is an error. > > Using this new construct requires code changes because some code such as > fairly close to the error message relies on the size of the one element > already in the struct. > > -- > Jilles Tjoelker > _______________________________________________ > 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= " > I looked at sctp_send_initiate() and it seems that independently from the number of types supported (IPV6/IPV4 or both) two elements are allocated in the array sup_addr->addr_type[0] . In case only a type is supported one of the elements is simply padding. (http://fxr.watson.org/fxr/source/netinet/sctp_output.c#L4670) . So, this should fix the issue, but maybe I'm wrong so feel free to correct = me. http://davit.altervista.org/sctp_header_types.diff I defined a new macro mainly because SCTP_ARRAY_MIN_LEN is used in another place, i.e. in the field name of struct sctp_host_name_param, defined in sctp_header.h). Thanks to arundel@ for testing. Regards Davide From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 16:52:38 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5466106566B; Sun, 27 Nov 2011 16:52:38 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id F1F9F8FC0A; Sun, 27 Nov 2011 16:52:37 +0000 (UTC) Received: from [192.168.1.200] (p508FA47F.dip.t-dialin.net [80.143.164.127]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id ED8F71C0B4610; Sun, 27 Nov 2011 17:52:35 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <20111127162430.GA95971@stack.nl> Date: Sun, 27 Nov 2011 17:52:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111127154536.GA54043@freebsd.org> <20111127162430.GA95971@stack.nl> To: Jilles Tjoelker X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Sun, 27 Nov 2011 16:59:27 +0000 Cc: Alexander Best , freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: Re: possible array out of bounds access in sys/netinet/sctp_output.c 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, 27 Nov 2011 16:52:39 -0000 On Nov 27, 2011, at 5:24 PM, Jilles Tjoelker wrote: > On Sun, Nov 27, 2011 at 03:45:36PM +0000, Alexander Best wrote: >> i've been playing with clang tot and noticed the following error: >=20 >> /usr/local/bin/clang -c -O3 -pipe -fno-inline-functions = -fno-strict-aliasing -march=3Dcore2 -std=3Dc99 -g = -fdiagnostics-show-option -fformat-extensions -Wall -Wcast-qual = -Winline -Wmissing-include-dirs -Wmissing-prototypes -Wnested-externs = -Wpointer-arith -Wredundant-decls -Wstrict-prototypes -Wundef = -Wno-pointer-sign -nostdinc -I. -I/usr/git-freebsd-head/sys = -I/usr/git-freebsd-head/sys/contrib/altq -D_KERNEL = -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h = -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=3Dkernel = -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables = -ffreestanding -Wno-error=3Dtautological-compare = -Wno-error=3Dshift-count-negative -Wno-error=3Dshift-count-overflow = -Wno-error=3Dshift-overflow -Wno-error=3Dconversion = -Wno-error=3Dempty-body -Wno-error=3Dgnu-designator -Wno-error=3Dformat = -Wno-error=3Dformat-invalid-specifier -Wno-error=3Dformat-extra-args = -Werror /usr/git-freebsd-head/sys/netinet/sctp_output.c >> clang: warning: argument unused during compilation: = '-fformat-extensions' >> /usr/git-freebsd-head/sys/netinet/sctp_output.c:4685:2: error: array = index 1 is past the end of the array (which contains 1 element) = [-Werror,-Warray-bounds] >> sup_addr->addr_type[1] =3D htons(SCTP_IPV6_ADDRESS); >> ^ ~ >> /usr/git-freebsd-head/sys/netinet/sctp_header.h:84:2: note: array = 'addr_type' declared here >> uint16_t addr_type[SCTP_ARRAY_MIN_LEN]; /* array of supported = address >> ^ >> 1 error generated. >> *** Error code 1 >>=20 >> Stop in /usr/obj/usr/git-freebsd-head/sys/GENERIC. >> *** Error code 1 >>=20 >> Stop in /usr/git-freebsd-head. >> *** Error code 1 >>=20 >> Stop in /usr/git-freebsd-head. >=20 >> this is from a GENERIC kernel build (so INET + INET6) for amd64. is = this a >> false positive, or is length(sup_addr->addr_type) really =3D=3D 1, = thus making >> sup_addr->addr_type[1] an illegal access? >=20 > This is the fairly common construct of a variable-length array at the > end of a struct. With C89, this was not allowed but defining one = element > and allocating more elements worked in most implementations. C99 > recognized this need and created a way to do it, which looks like > uint16_t addr_type[];. This adds any necessary padding and allows = access > to however many elements have been allocated. Also, if it is not at = the > end of a struct it is an error. >=20 > Using this new construct requires code changes because some code such = as > fairly close to the error message relies on the size of the one = element > already in the struct. Hi Jilles, you are completely right. It is a false positive. the reason why we don't use addr_type[] is that the same code is used on different plattforms and (at least at one point of time), using addr_type[] didn't work there. However, reconsidering the code right now, I guess one could change to = code in a way to avoid the warning. I'll put that on my ToDo list. But it is = only to avoid the warning, there is no real problem as said earlier. Best regards Michael >=20 > --=20 > Jilles Tjoelker > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >=20 From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 17:01:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0C01106567A for ; Sun, 27 Nov 2011 17:01:32 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 58F188FC17 for ; Sun, 27 Nov 2011 17:01:32 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1RUi6d-0003k0-J4>; Sun, 27 Nov 2011 18:01:31 +0100 Received: from e178025092.adsl.alicedsl.de ([85.178.25.92] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1RUi6d-0004Pr-29>; Sun, 27 Nov 2011 18:01:31 +0100 Message-ID: <4ED26CE9.3020107@zedat.fu-berlin.de> Date: Sun, 27 Nov 2011 18:01:29 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: Current FreeBSD X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig048107AFE6C7AB36D7DF42AB" X-Originating-IP: 85.178.25.92 Subject: Building FreeBSD 10.0-CURRENT/amd64 of today fails (with clang and WITH_LIBCPLUSPLUS=YES) 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, 27 Nov 2011 17:01:32 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig048107AFE6C7AB36D7DF42AB Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Sources of FreeBSD 10.0-CUR/amd64 as svn-ed recently: Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 228029 Node Kind: directory Schedule: normal Last Changed Author: trociny Last Changed Rev: 228029 Last Changed Date: 2011-11-27 17:56:01 +0100 (Sun, 27 Nov 2011) fail to build with the following error: clang -fpic -DPIC -O3 -fno-strict-aliasing -pipe -march=3Dnative -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DHESIOD -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c crypt_xdr.c -o crypt_xdr.So building static c library building shared library libc.so.7 ranlib libc.a building special pic c library ranlib libc_pic.a sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libc.a /usr/obj/usr/src/tmp/usr/lib sh /usr/src/tools/install.sh -o root -g wheel -m 444 be_BY.UTF-8.cat /usr/obj/usr/src/tmp/usr/share/nls/be_BY.UTF-8/libc.cat sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 -S libc.so.7 /usr/obj/usr/src/tmp/lib ln -fs /usr/obj/usr/src/tmp/lib/libc.so.7 /usr/obj/usr/src/tmp/usr/lib/libc.so sh /usr/src/tools/install.sh -o root -g wheel -m 444 ca_ES.ISO8859-1.cat /usr/obj/usr/src/tmp/usr/share/nls/ca_ES.ISO8859-1/libc.cat sh /usr/src/tools/install.sh -o root -g wheel -m 444 libc_pic.a /usr/obj/usr/src/tmp/usr/lib sh /usr/src/tools/install.sh -o root -g wheel -m 444 de_DE.ISO8859-1.cat /usr/obj/usr/src/tmp/usr/share/nls/de_DE.ISO8859-1/libc.cat sh /usr/src/tools/install.sh -o root -g wheel -m 444 el_GR.ISO8859-7.cat /usr/obj/usr/src/tmp/usr/share/nls/el_GR.ISO8859-7/libc.cat sh /usr/src/tools/install.sh -o root -g wheel -m 444 es_ES.ISO8859-1.cat /usr/obj/usr/src/tmp/usr/share/nls/es_ES.ISO8859-1/libc.cat sh /usr/src/tools/install.sh -o root -g wheel -m 444 fi_FI.ISO8859-1.cat /usr/obj/usr/src/tmp/usr/share/nls/fi_FI.ISO8859-1/libc.cat sh /usr/src/tools/install.sh -o root -g wheel -m 444 fr_FR.ISO8859-1.cat /usr/obj/usr/src/tmp/usr/share/nls/fr_FR.ISO8859-1/libc.cat sh /usr/src/tools/install.sh -o root -g wheel -m 444 gl_ES.ISO8859-1.cat /usr/obj/usr/src/tmp/usr/share/nls/gl_ES.ISO8859-1/libc.cat sh /usr/src/tools/install.sh -o root -g wheel -m 444 hu_HU.ISO8859-2.cat /usr/obj/usr/src/tmp/usr/share/nls/hu_HU.ISO8859-2/libc.cat sh /usr/src/tools/install.sh -o root -g wheel -m 444 it_IT.ISO8859-15.cat /usr/obj/usr/src/tmp/usr/share/nls/it_IT.ISO8859-15/libc.cat sh /usr/src/tools/install.sh -o root -g wheel -m 444 ja_JP.UTF-8.cat /usr/obj/usr/src/tmp/usr/share/nls/ja_JP.UTF-8/libc.cat sh /usr/src/tools/install.sh -o root -g wheel -m 444 ja_JP.eucJP.cat /usr/obj/usr/src/tmp/usr/share/nls/ja_JP.eucJP/libc.cat sh /usr/src/tools/install.sh -o root -g wheel -m 444 ko_KR.UTF-8.cat /usr/obj/usr/src/tmp/usr/share/nls/ko_KR.UTF-8/libc.cat sh /usr/src/tools/install.sh -o root -g wheel -m 444 ko_KR.eucKR.cat /usr/obj/usr/src/tmp/usr/share/nls/ko_KR.eucKR/libc.cat sh /usr/src/tools/install.sh -o root -g wheel -m 444 mn_MN.UTF-8.cat /usr/obj/usr/src/tmp/usr/share/nls/mn_MN.UTF-8/libc.cat sh /usr/src/tools/install.sh -o root -g wheel -m 444 nl_NL.ISO8859-1.cat /usr/obj/usr/src/tmp/usr/share/nls/nl_NL.ISO8859-1/libc.cat sh /usr/src/tools/install.sh -o root -g wheel -m 444 no_NO.ISO8859-1.cat /usr/obj/usr/src/tmp/usr/share/nls/no_NO.ISO8859-1/libc.cat sh /usr/src/tools/install.sh -o root -g wheel -m 444 pl_PL.ISO8859-2.cat /usr/obj/usr/src/tmp/usr/share/nls/pl_PL.ISO8859-2/libc.cat sh /usr/src/tools/install.sh -o root -g wheel -m 444 pt_BR.ISO8859-1.cat /usr/obj/usr/src/tmp/usr/share/nls/pt_BR.ISO8859-1/libc.cat sh /usr/src/tools/install.sh -o root -g wheel -m 444 ru_RU.KOI8-R.cat /usr/obj/usr/src/tmp/usr/share/nls/ru_RU.KOI8-R/libc.cat sh /usr/src/tools/install.sh -o root -g wheel -m 444 sk_SK.ISO8859-2.cat /usr/obj/usr/src/tmp/usr/share/nls/sk_SK.ISO8859-2/libc.cat sh /usr/src/tools/install.sh -o root -g wheel -m 444 sv_SE.ISO8859-1.cat /usr/obj/usr/src/tmp/usr/share/nls/sv_SE.ISO8859-1/libc.cat sh /usr/src/tools/install.sh -o root -g wheel -m 444 uk_UA.UTF-8.cat /usr/obj/usr/src/tmp/usr/share/nls/uk_UA.UTF-8/libc.cat 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error Regards, Oliver --------------enig048107AFE6C7AB36D7DF42AB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO0mzpAAoJEOgBcD7A/5N8os0H+gK2D69qyttp89BhvfOu4g6d o3bovCqUNTBz+6E69/qmVlbcD6G6mOplids3INMyrB6qGjxI33rtx2LMVTBdLDfO PN7MknCyP7dqEoq0dwYlsFOuQJWDGHMd8ECdbVF5lSoOCVYvZHfwXZWZtyrnBA1a 86a+iZs1Nbhb3m4oZy2Hrs+6TlywUMwuS2/b1jhoO/Lnndb7wtIqZk5c/OzPub8/ SSyrFRQWxFMRoMh8R2onsrxXU+vi1zfk8XUOnjExw0ZvPT5OmfVav+aL5dvpO1vy w46IM0HvgKjrq7GspdjPasytKU5sWwOgwb7xTNAR8NZFbzZ+x1Hp7gyUo2FVqO4= =7uiN -----END PGP SIGNATURE----- --------------enig048107AFE6C7AB36D7DF42AB-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 17:09:48 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E70631065670; Sun, 27 Nov 2011 17:09:48 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh4.mail.rice.edu (mh4.mail.rice.edu [128.42.199.11]) by mx1.freebsd.org (Postfix) with ESMTP id 982C78FC08; Sun, 27 Nov 2011 17:09:48 +0000 (UTC) Received: from mh4.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh4.mail.rice.edu (Postfix) with ESMTP id B3FE32919C2; Sun, 27 Nov 2011 11:09:47 -0600 (CST) Received: from mh4.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh4.mail.rice.edu (Postfix) with ESMTP id 9CD612975A3; Sun, 27 Nov 2011 11:09:47 -0600 (CST) X-Virus-Scanned: by amavis-2.6.4 at mh4.mail.rice.edu, auth channel Received: from mh4.mail.rice.edu ([127.0.0.1]) by mh4.mail.rice.edu (mh4.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id GYQt0UrT4T13; Sun, 27 Nov 2011 11:09:47 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh4.mail.rice.edu (Postfix) with ESMTPSA id EB4882919C2; Sun, 27 Nov 2011 11:09:46 -0600 (CST) Message-ID: <4ED26EDA.3010706@rice.edu> Date: Sun, 27 Nov 2011 11:09:46 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: Andriy Gapon References: <4ECF7440.4070300@entel.upc.edu> <4ECF8F05.8000007@protected-networks.net> <4ED0C40D.5010307@entel.upc.edu> <4ED0D963.1030702@entel.upc.edu> <4ED0DF1F.6090901@FreeBSD.org> In-Reply-To: <4ED0DF1F.6090901@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD current , freebsd-emulation@FreeBSD.org, =?ISO-8859-1?Q?Gustau_P=E9rez?= , Michael Butler Subject: Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464} 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, 27 Nov 2011 17:09:49 -0000 On 11/26/2011 06:44, Andriy Gapon wrote: > on 26/11/2011 14:19 Gustau Pérez said the following: >> Starting Virtualbox in the console in headless mode allows to see what happens >> and get a dump of the panic. >> >> The messages I got were not the cause problem. The panic I was able to get >> shows this: >> >> http://pastebin.com/dHnB3Xh0 >> >> I can't get any further with core although I compiled virtualbox-ose-kmod with >> debug symbols (I used make config to enable them, because I think -DWITH_DEBUG >> does not work because kmk is used in the build process). >> >> Any help will be appreciated. > vm_phys_alloc_contig implementation has been recently changed and now it seems > to require that vm_page_queue_free_mtx is held. > vm_page_alloc_contig() should be used instead. Alan From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 17:28:05 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91C4D106566B; Sun, 27 Nov 2011 17:28:05 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 22D468FC12; Sun, 27 Nov 2011 17:28:05 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id BC946E65F7; Sun, 27 Nov 2011 17:28:03 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=Ri2KfFtXfinQ f3GFtttd40edSeQ=; b=p290TGVWetcI/EcNub4q1syg9nfplskYy8JqHITkYKkD mDlFHy59xLhVb/JYAvBF7JrO9YH7AhAdnIbltsKcec7Vwtkfx2GRimU25GCwliV/ YJ3FiWGf37fIz/IB6Xl8+rpR3ybTdNiIn56MjfpNSMOCQBEzKJD55UJREiZVy70= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=EwJFvp ZtW5qP6GrdddPtnnuF3PTloB/vzYdA1H0OLCZl2w8mzAMXPQYb33tFT13C86fUlQ YRuhm4gpwrLQPBa+hsAMG9ikVnQ7pZYl1X3P8V9nSD3KAs0UITT+SMnxSLPEa8wf UoVSIOExNEER376ZD40RKIHGRngf9OT/pYMUY= Received: from [192.168.1.68] (188-220-36-32.zone11.bethere.co.uk [188.220.36.32]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 82EFDE65EF; Sun, 27 Nov 2011 17:28:03 +0000 (GMT) Message-ID: <4ED2731F.9040605@cran.org.uk> Date: Sun, 27 Nov 2011 17:27:59 +0000 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_T=FCxen?= References: <20111127154536.GA54043@freebsd.org> <20111127162430.GA95971@stack.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Alexander Best , freebsd-current@freebsd.org, Jilles Tjoelker , freebsd-net@freebsd.org Subject: Re: possible array out of bounds access in sys/netinet/sctp_output.c 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, 27 Nov 2011 17:28:05 -0000 On 27/11/2011 16:52, Michael T=FCxen wrote: > the reason why we don't use addr_type[] is that the same code is used > on different plattforms and (at least at one point of time), using > addr_type[] didn't work there. Unfortunately I don't think even the Windows 8 Driver Kit will support=20 much more than stdint.h out of C99. --=20 Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 19:22:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02BF9106566B for ; Sun, 27 Nov 2011 19:22:40 +0000 (UTC) (envelope-from zklist@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8A1098FC0C for ; Sun, 27 Nov 2011 19:22:39 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so9140446bkb.13 for ; Sun, 27 Nov 2011 11:22:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=YlvkDjFFgnSZajSOvVREZHCYwqykBypWbcmiFB8dRuk=; b=MWd4tIwVopaLNZfaZ7Qaxr6Pd9Qo4vyoyT59u358qEvWqIwkDdE8qYYv2wnXHRLTLU yAGCIMHY92ivrR/ndpu7A+3h2juGbd/tpVj0sfLoVnd9J78iITjTuvyfnWiUT4JQT6ap aGz1iYmY1PjCjmTGHTVs3poe4NOouJfonFbwE= MIME-Version: 1.0 Received: by 10.205.141.70 with SMTP id jd6mr6315352bkc.13.1322420384074; Sun, 27 Nov 2011 10:59:44 -0800 (PST) Received: by 10.204.201.142 with HTTP; Sun, 27 Nov 2011 10:59:44 -0800 (PST) Date: Sun, 27 Nov 2011 19:59:44 +0100 Message-ID: From: ZaRiuS KRiNG To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Problem compiling libs after pass to 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, 27 Nov 2011 19:22:40 -0000 Hi! is my first post here and have a little problem try to google some and don't find any of value. A week ago compile the src of current, and after that in any new port i install, if compile before any lib, don't work, i need to install pkg from repository of that lib and continue compiling the program, and work fine. Just have this problem with the libs Any solution? From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 20:08:03 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7129B1065670; Sun, 27 Nov 2011 20:08:03 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 3A5F68FC12; Sun, 27 Nov 2011 20:08:02 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pARK82qn010810; Sun, 27 Nov 2011 15:08:02 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pARK82IG010809; Sun, 27 Nov 2011 20:08:02 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 27 Nov 2011 20:08:02 GMT Message-Id: <201111272008.pARK82IG010809@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2011 20:08:03 -0000 TB --- 2011-11-27 19:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-27 19:10:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-11-27 19:10:00 - cleaning the object tree TB --- 2011-11-27 19:10:32 - cvsupping the source tree TB --- 2011-11-27 19:10:32 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-11-27 19:10:58 - building world TB --- 2011-11-27 19:10:58 - CROSS_BUILD_TESTING=YES TB --- 2011-11-27 19:10:58 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-27 19:10:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-27 19:10:58 - SRCCONF=/dev/null TB --- 2011-11-27 19:10:58 - TARGET=arm TB --- 2011-11-27 19:10:58 - TARGET_ARCH=arm TB --- 2011-11-27 19:10:58 - TZ=UTC TB --- 2011-11-27 19:10:58 - __MAKE_CONF=/dev/null TB --- 2011-11-27 19:10:58 - cd /src TB --- 2011-11-27 19:10:58 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 27 19:10:58 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Nov 27 20:06:29 UTC 2011 TB --- 2011-11-27 20:06:30 - cd /src/sys/arm/conf TB --- 2011-11-27 20:06:30 - /usr/sbin/config -m AVILA TB --- 2011-11-27 20:06:30 - building AVILA kernel TB --- 2011-11-27 20:06:30 - CROSS_BUILD_TESTING=YES TB --- 2011-11-27 20:06:30 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-27 20:06:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-27 20:06:30 - SRCCONF=/dev/null TB --- 2011-11-27 20:06:30 - TARGET=arm TB --- 2011-11-27 20:06:30 - TARGET_ARCH=arm TB --- 2011-11-27 20:06:30 - TZ=UTC TB --- 2011-11-27 20:06:30 - __MAKE_CONF=/dev/null TB --- 2011-11-27 20:06:30 - cd /src TB --- 2011-11-27 20:06:30 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Sun Nov 27 20:06:30 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -mbig-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/kern/kern_ntptime.c cc -mbig-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/kern/kern_osd.c cc -mbig-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/kern/kern_physio.c cc -mbig-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/kern/kern_pmc.c cc -mbig-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/kern/kern_poll.c cc -mbig-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/kern/kern_priv.c cc -mbig-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/kern/kern_proc.c /src/sys/kern/kern_proc.c:2589: error: 'KERN_PROC_PS_STRINGS' undeclared here (not in a function) *** Error code 1 Stop in /obj/arm.arm/src/sys/AVILA. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-27 20:08:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-27 20:08:01 - ERROR: failed to build AVILA kernel TB --- 2011-11-27 20:08:01 - 2472.07 user 738.54 system 3480.57 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 21:05:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0CB2106566B for ; Sun, 27 Nov 2011 21:05:37 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 834618FC0C for ; Sun, 27 Nov 2011 21:05:37 +0000 (UTC) Received: by ywp17 with SMTP id 17so4480865ywp.13 for ; Sun, 27 Nov 2011 13:05:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=s/m2519sOzczIUcGmdspgzQeDTflyoiw23THlFS3xfA=; b=ZU+mkJr0suL7Sgx81SghIP5M370RdI3+SJJME3N0UjIleBq/jGhQ9UOSLIhMXf3zMQ co5pfVq6bETt3E3Is2YbU0eF6FGUmJ3Q+L7e03m4AyTRok6pD6nRQnyJgfzYT7OqrxkI oWTmJLM+FUPerwNbDaQ23W1ZaF57O4/tSiblU= MIME-Version: 1.0 Received: by 10.182.40.65 with SMTP id v1mr2357129obk.72.1322427936794; Sun, 27 Nov 2011 13:05:36 -0800 (PST) Received: by 10.182.62.227 with HTTP; Sun, 27 Nov 2011 13:05:36 -0800 (PST) In-Reply-To: <4ED26CE9.3020107@zedat.fu-berlin.de> References: <4ED26CE9.3020107@zedat.fu-berlin.de> Date: Sun, 27 Nov 2011 13:05:36 -0800 Message-ID: From: Garrett Cooper To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Cc: Current FreeBSD Subject: Re: Building FreeBSD 10.0-CURRENT/amd64 of today fails (with clang and WITH_LIBCPLUSPLUS=YES) 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, 27 Nov 2011 21:05:37 -0000 On Sun, Nov 27, 2011 at 9:01 AM, O. Hartmann wrote: > Sources of FreeBSD 10.0-CUR/amd64 as svn-ed recently: > > Path: . > Working Copy Root Path: /usr/src > URL: svn://svn.freebsd.org/base/head > Repository Root: svn://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 228029 > Node Kind: directory > Schedule: normal > Last Changed Author: trociny > Last Changed Rev: 228029 > Last Changed Date: 2011-11-27 17:56:01 +0100 (Sun, 27 Nov 2011) > > fail to build with the following error: Look for the first "Error code" in your output -- the line before that is the real error. That being said, there were some additional CFLAGS that needed to be fed in to make things work with libc++ and libcxxrt IIRC. Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 21:08:07 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8537510657CC; Sun, 27 Nov 2011 21:08:07 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id C2A4A8FC1F; Sun, 27 Nov 2011 21:08:06 +0000 (UTC) Received: by ggnk5 with SMTP id k5so6637234ggn.13 for ; Sun, 27 Nov 2011 13:08:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zBtcSfiJn5qkV1t137ZilMSEtmtoHydE56KuzSVxEJw=; b=OMaPZna7a2eDq9ZnPOZQ0ET/gDidiApN6iowQcvXfj9b4In2eMT73vuMuAgSvgIYL1 eDZ8K53N1gxbM4vMnUxzB+z0NxjtuiM25BCwpCYyIzpPmo/ji6Tike7FyMDLgnSROLrE yH0cz1NwqAqlEZCWMQ+McLvuqnGkM6lXwTcrI= MIME-Version: 1.0 Received: by 10.182.5.166 with SMTP id t6mr1645903obt.2.1322428086087; Sun, 27 Nov 2011 13:08:06 -0800 (PST) Received: by 10.182.62.227 with HTTP; Sun, 27 Nov 2011 13:08:06 -0800 (PST) In-Reply-To: <4ED259DF.5030008@zedat.fu-berlin.de> References: <4ED259DF.5030008@zedat.fu-berlin.de> Date: Sun, 27 Nov 2011 13:08:06 -0800 Message-ID: From: Garrett Cooper To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Cc: Current FreeBSD , freebsd-questions@freebsd.org Subject: Re: multimedia/vlc: no graphical interface on FreeBSD 9 and 10 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, 27 Nov 2011 21:08:07 -0000 On Sun, Nov 27, 2011 at 7:40 AM, O. Hartmann wrote: > Since a while, vlc on my FreeBSD 10 and FreeBSD 9 boxes do not show a > graphical interface anymore. Compiling multimedia/vlc works, either with > the legacy gcc or clang. But either way I compile vlc, the result is > always the same: no GUI. Instead, I receive the below show message: That means one or more plugins crashed the system. vlc is lowsy when it comes to diagnostic messages and it isn't overly apparent what the root cause is when running ldd because it dl_open's a bunch of libraries. Try running vlc -vv or ktrace'ing the binary. Cheers, -Garrett PS Please don't cross-post. From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 21:15:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0DC2106564A for ; Sun, 27 Nov 2011 21:15:37 +0000 (UTC) (envelope-from sub.mesa@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8EB0B8FC12 for ; Sun, 27 Nov 2011 21:15:37 +0000 (UTC) Received: by ggnk5 with SMTP id k5so6640946ggn.13 for ; Sun, 27 Nov 2011 13:15:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Xdz8Gx3om1ZF1mIYvZy6VYR7qCtl3TCY3dH1XsdkWt8=; b=pnF7YAo21rymMiZry4sHw/4oRu6n4udeddAMFq2rB3Qv0WQ766XPg+AofyBGX5F4FD VaL0AEmBPu8Gxo+QgV5SNUODnJK/MaBmbSZ/L/owaa2BewYcsDAoo7gH2rAqCACZ6m+5 +JcN4y9g9jwQoGGetREKklfPaDPEJiX8Un9m0= MIME-Version: 1.0 Received: by 10.236.185.68 with SMTP id t44mr59083178yhm.41.1322428536968; Sun, 27 Nov 2011 13:15:36 -0800 (PST) Received: by 10.236.79.233 with HTTP; Sun, 27 Nov 2011 13:15:36 -0800 (PST) In-Reply-To: <20111123181133.GD1979@hoeg.nl> References: <5D3FFA12-BB54-4297-A098-3B85951ECEC5@lassitu.de> <3A9E50F5-03D3-4DD5-A95D-5948D4705462@lassitu.de> <20111123181133.GD1979@hoeg.nl> Date: Sun, 27 Nov 2011 22:15:36 +0100 Message-ID: From: Jason Edwards To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, Stefan Bethke Subject: Re: ee (easy editor) bugged on 9.0? 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, 27 Nov 2011 21:15:37 -0000 On Wed, Nov 23, 2011 at 7:11 PM, Ed Schouten wrote: > Hi Jason, > > * Jason Edwards , 20111122 21:56: >> I wonder: is cons25 bugged or simply obsolete? Not that I want to keep >> cons25; just being curious. > > There are two reasons why I changed the default terminal emulator to be > xterm-like, instead of conforming to cons25: Hello Ed Schouten, Thanks for the impressive list of advantages! There's just one non-critical issue I'd like to address regarding the use of xterm terminal type. When using cons25 terminal, the dialog menus (drawn using devel/cdialog and `make config` in portstree as well) are using smooth lines to draw boxes and stuff. But when using xterm terminal, those lines are replaced by 'dashed' lines like - - - - - instead of a smooth line without whitespace in between. When doing the same via SSH login, the lines are smooth with xterm type. So this issue appear to be limited to the console in combination with xterm terminal type. Is there a way to use xterm but still allow cdialog to draw smooth lines on the console? Kind regards, Jason Edwards From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 21:26:05 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08858106564A; Sun, 27 Nov 2011 21:26:05 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id CD88D8FC15; Sun, 27 Nov 2011 21:26:04 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pARLQ4qM099191; Sun, 27 Nov 2011 16:26:04 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pARLQ30k099166; Sun, 27 Nov 2011 21:26:03 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 27 Nov 2011 21:26:03 GMT Message-Id: <201111272126.pARLQ30k099166@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2011 21:26:05 -0000 TB --- 2011-11-27 19:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-27 19:10:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-11-27 19:10:00 - cleaning the object tree TB --- 2011-11-27 19:10:30 - cvsupping the source tree TB --- 2011-11-27 19:10:30 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-11-27 19:10:58 - building world TB --- 2011-11-27 19:10:58 - CROSS_BUILD_TESTING=YES TB --- 2011-11-27 19:10:58 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-27 19:10:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-27 19:10:58 - SRCCONF=/dev/null TB --- 2011-11-27 19:10:58 - TARGET=pc98 TB --- 2011-11-27 19:10:58 - TARGET_ARCH=i386 TB --- 2011-11-27 19:10:58 - TZ=UTC TB --- 2011-11-27 19:10:58 - __MAKE_CONF=/dev/null TB --- 2011-11-27 19:10:58 - cd /src TB --- 2011-11-27 19:10:58 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 27 19:10:58 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Nov 27 21:21:02 UTC 2011 TB --- 2011-11-27 21:21:02 - generating LINT kernel config TB --- 2011-11-27 21:21:02 - cd /src/sys/pc98/conf TB --- 2011-11-27 21:21:02 - /usr/bin/make -B LINT TB --- 2011-11-27 21:21:02 - cd /src/sys/pc98/conf TB --- 2011-11-27 21:21:02 - /usr/sbin/config -m GENERIC TB --- 2011-11-27 21:21:02 - building GENERIC kernel TB --- 2011-11-27 21:21:02 - CROSS_BUILD_TESTING=YES TB --- 2011-11-27 21:21:02 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-27 21:21:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-27 21:21:02 - SRCCONF=/dev/null TB --- 2011-11-27 21:21:02 - TARGET=pc98 TB --- 2011-11-27 21:21:02 - TARGET_ARCH=i386 TB --- 2011-11-27 21:21:02 - TZ=UTC TB --- 2011-11-27 21:21:02 - __MAKE_CONF=/dev/null TB --- 2011-11-27 21:21:02 - cd /src TB --- 2011-11-27 21:21:02 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Nov 27 21:21:02 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_mutex.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_ntptime.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_osd.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_physio.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_pmc.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_priv.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_proc.c /src/sys/kern/kern_proc.c:2589: error: 'KERN_PROC_PS_STRINGS' undeclared here (not in a function) *** Error code 1 Stop in /obj/pc98.i386/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-27 21:26:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-27 21:26:03 - ERROR: failed to build GENERIC kernel TB --- 2011-11-27 21:26:03 - 6511.69 user 1147.20 system 8162.57 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 21:31:35 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59B5E106564A; Sun, 27 Nov 2011 21:31:35 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id B25218FC15; Sun, 27 Nov 2011 21:31:34 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so9301285bkb.13 for ; Sun, 27 Nov 2011 13:31:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:references:x-comment-to:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=ecVMFVg34kUmk6dDS3erldVIME/N+vYHCIooaFNKmeo=; b=IUKSATcmOfTc5wyjymFOFp1cJF7MnOiQR5yN0e0qvUalfPy3nIcMRYOOXmTpuHk4V2 mpDoDgfZt6wJ3J2TJg+8eAfsABk4tSyOuu7cRUHT++gSdUM6BjPea+TVeqXlUBNJiAAp Nc1ElW68fE7d+xFxfa9dZPGw/7+g6nmPaQ2Bw= Received: by 10.204.22.14 with SMTP id l14mr11372415bkb.36.1322427977097; Sun, 27 Nov 2011 13:06:17 -0800 (PST) Received: from localhost ([95.69.173.122]) by mx.google.com with ESMTPS id z1sm4621158fad.21.2011.11.27.13.06.14 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 Nov 2011 13:06:15 -0800 (PST) From: Mikolaj Golub To: , References: <201111272008.pARK82IG010809@freebsd-current.sentex.ca> X-Comment-To: FreeBSD Tinderbox Sender: Mikolaj Golub Date: Sun, 27 Nov 2011 23:06:13 +0200 In-Reply-To: <201111272008.pARK82IG010809@freebsd-current.sentex.ca> (FreeBSD Tinderbox's message of "Sun, 27 Nov 2011 20:08:02 GMT") Message-ID: <861usti8ca.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Re: [head tinderbox] failure on arm/arm 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, 27 Nov 2011 21:31:35 -0000 On Sun, 27 Nov 2011 20:08:02 GMT FreeBSD Tinderbox wrote: FT> /src/sys/kern/kern_proc.c:2589: error: 'KERN_PROC_PS_STRINGS' undeclared here (not in a function) FT> *** Error code 1 Forgot to commit changes to sys/sysctl.h. Sorry for this. Should be fixed in r228046. -- Mikolaj Golub From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 21:39:41 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C340106564A; Sun, 27 Nov 2011 21:39:41 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0F3658FC08; Sun, 27 Nov 2011 21:39:40 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pARLdeSn029838; Sun, 27 Nov 2011 16:39:40 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pARLded9029820; Sun, 27 Nov 2011 21:39:40 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 27 Nov 2011 21:39:40 GMT Message-Id: <201111272139.pARLded9029820@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2011 21:39:41 -0000 TB --- 2011-11-27 19:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-27 19:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-11-27 19:10:00 - cleaning the object tree TB --- 2011-11-27 19:10:54 - cvsupping the source tree TB --- 2011-11-27 19:10:54 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-11-27 19:16:19 - building world TB --- 2011-11-27 19:16:19 - CROSS_BUILD_TESTING=YES TB --- 2011-11-27 19:16:19 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-27 19:16:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-27 19:16:19 - SRCCONF=/dev/null TB --- 2011-11-27 19:16:19 - TARGET=i386 TB --- 2011-11-27 19:16:19 - TARGET_ARCH=i386 TB --- 2011-11-27 19:16:19 - TZ=UTC TB --- 2011-11-27 19:16:19 - __MAKE_CONF=/dev/null TB --- 2011-11-27 19:16:19 - cd /src TB --- 2011-11-27 19:16:19 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 27 19:16:19 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Nov 27 21:27:29 UTC 2011 TB --- 2011-11-27 21:27:30 - generating LINT kernel config TB --- 2011-11-27 21:27:30 - cd /src/sys/i386/conf TB --- 2011-11-27 21:27:30 - /usr/bin/make -B LINT TB --- 2011-11-27 21:27:30 - cd /src/sys/i386/conf TB --- 2011-11-27 21:27:30 - /usr/sbin/config -m LINT-NOINET TB --- 2011-11-27 21:27:30 - building LINT-NOINET kernel TB --- 2011-11-27 21:27:30 - CROSS_BUILD_TESTING=YES TB --- 2011-11-27 21:27:30 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-27 21:27:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-27 21:27:30 - SRCCONF=/dev/null TB --- 2011-11-27 21:27:30 - TARGET=i386 TB --- 2011-11-27 21:27:30 - TARGET_ARCH=i386 TB --- 2011-11-27 21:27:30 - TZ=UTC TB --- 2011-11-27 21:27:30 - __MAKE_CONF=/dev/null TB --- 2011-11-27 21:27:30 - cd /src TB --- 2011-11-27 21:27:30 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Sun Nov 27 21:27:30 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_ntptime.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_osd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_physio.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_pmc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_poll.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_priv.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_proc.c /src/sys/kern/kern_proc.c:2589: error: 'KERN_PROC_PS_STRINGS' undeclared here (not in a function) *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT-NOINET. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-27 21:39:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-27 21:39:40 - ERROR: failed to build LINT-NOINET kernel TB --- 2011-11-27 21:39:40 - 6919.34 user 1190.80 system 8979.25 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 21:43:53 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7ECE6106564A; Sun, 27 Nov 2011 21:43:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 4C06B8FC15; Sun, 27 Nov 2011 21:43:53 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pARLhq5a047650; Sun, 27 Nov 2011 16:43:52 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pARLhqDe047647; Sun, 27 Nov 2011 21:43:52 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 27 Nov 2011 21:43:52 GMT Message-Id: <201111272143.pARLhqDe047647@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2011 21:43:53 -0000 TB --- 2011-11-27 20:08:02 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-27 20:08:02 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-11-27 20:08:02 - cleaning the object tree TB --- 2011-11-27 20:08:15 - cvsupping the source tree TB --- 2011-11-27 20:08:15 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-11-27 20:08:39 - building world TB --- 2011-11-27 20:08:39 - CROSS_BUILD_TESTING=YES TB --- 2011-11-27 20:08:39 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-27 20:08:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-27 20:08:39 - SRCCONF=/dev/null TB --- 2011-11-27 20:08:39 - TARGET=ia64 TB --- 2011-11-27 20:08:39 - TARGET_ARCH=ia64 TB --- 2011-11-27 20:08:39 - TZ=UTC TB --- 2011-11-27 20:08:39 - __MAKE_CONF=/dev/null TB --- 2011-11-27 20:08:39 - cd /src TB --- 2011-11-27 20:08:39 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 27 20:08:40 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Nov 27 21:37:11 UTC 2011 TB --- 2011-11-27 21:37:11 - generating LINT kernel config TB --- 2011-11-27 21:37:11 - cd /src/sys/ia64/conf TB --- 2011-11-27 21:37:11 - /usr/bin/make -B LINT TB --- 2011-11-27 21:37:11 - cd /src/sys/ia64/conf TB --- 2011-11-27 21:37:11 - /usr/sbin/config -m GENERIC TB --- 2011-11-27 21:37:11 - building GENERIC kernel TB --- 2011-11-27 21:37:11 - CROSS_BUILD_TESTING=YES TB --- 2011-11-27 21:37:11 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-27 21:37:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-27 21:37:11 - SRCCONF=/dev/null TB --- 2011-11-27 21:37:11 - TARGET=ia64 TB --- 2011-11-27 21:37:11 - TARGET_ARCH=ia64 TB --- 2011-11-27 21:37:11 - TZ=UTC TB --- 2011-11-27 21:37:11 - __MAKE_CONF=/dev/null TB --- 2011-11-27 21:37:11 - cd /src TB --- 2011-11-27 21:37:11 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Nov 27 21:37:11 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/kern/kern_mutex.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/kern/kern_ntptime.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/kern/kern_osd.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/kern/kern_physio.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/kern/kern_pmc.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/kern/kern_priv.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/kern/kern_proc.c /src/sys/kern/kern_proc.c:2589: error: 'KERN_PROC_PS_STRINGS' undeclared here (not in a function) *** Error code 1 Stop in /obj/ia64.ia64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-27 21:43:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-27 21:43:52 - ERROR: failed to build GENERIC kernel TB --- 2011-11-27 21:43:52 - 4515.83 user 874.84 system 5749.75 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 21:58:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D92F21065672; Sun, 27 Nov 2011 21:58:24 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 848408FC0C; Sun, 27 Nov 2011 21:58:24 +0000 (UTC) Received: by ghbg20 with SMTP id g20so5434002ghb.13 for ; Sun, 27 Nov 2011 13:58:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=p8lOCi2LZ6pilzpEPoQH8qbjFUn8714Wp1Nkho5tC+M=; b=fXM/Ndo9kDFPXVPrhv+UPxuXABM01AkQlMeGx0LIMlivyz6G390altj5VMevDzRcHW tOZGKDufhe94oaXLFCVoL7lBTGy/gWTIZJy4esmQb4Lp34ncaZ64UuT6xIOYJo0dYaK6 bo6SQ8whxmw0HH1NTFBklG/wMI8C1jhu+KfRU= MIME-Version: 1.0 Received: by 10.182.40.65 with SMTP id v1mr2381429obk.72.1322431103909; Sun, 27 Nov 2011 13:58:23 -0800 (PST) Received: by 10.182.62.227 with HTTP; Sun, 27 Nov 2011 13:58:23 -0800 (PST) In-Reply-To: <4ED20A68.90102@zedat.fu-berlin.de> References: <4ED20A68.90102@zedat.fu-berlin.de> Date: Sun, 27 Nov 2011 13:58:23 -0800 Message-ID: From: Garrett Cooper To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Current FreeBSD , freebsd-questions@freebsd.org Subject: Re: port astro/stellarium: /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/AngleMeasure/src/AngleMeasure.hpp, : File name too long,*** Error code 1 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, 27 Nov 2011 21:58:24 -0000 On Sun, Nov 27, 2011 at 2:01 AM, O. Hartmann wrote: > Hello, > > since a couple of days for now I have on FreeBSD 10.0-CURRENT/amd64, > clang compiled, the following error updating or reinstalling or > installing the port astro/stellarium: > > =3D=3D=3D> =A0Vulnerability check disabled, database not found > =3D=3D=3D> =A0License GPLv2 accepted by the user > =3D=3D=3D> =A0Found saved configuration for stellarium-0.11.1 > =3D=3D=3D> =A0Extracting for stellarium-0.11.1 > =3D> SHA256 Checksum OK for stellarium-0.11.1.tar.gz. > =3D=3D=3D> =A0Patching for stellarium-0.11.1 > sed: > /usr/ports/astro/stellarium/work/stellarium-0.11.1/src/core/external/fixx= 11h.h > /usr/ports/astro/stellarium/work/stellarium-0.11.1/src/CMakeLists.txt > /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/TelescopeContr= ol/src/TelescopeControl.hpp > /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/Oculars/src/Oc= ulars.hpp > /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/CompassMarks/s= rc/CompassMarks.hpp > /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/TextUserInterf= ace/src/TextUserInterface.hpp > /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/Supernovae/src= /Supernovae.hpp > /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/SolarSystemEdi= tor/src/SolarSystemEditor.hpp > /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/Satellites/src= /Satellites.hpp > /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/HelloStelModul= e/src/HelloStelModule.hpp > /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/TimeZoneConfig= uration/src/TimeZoneConfiguration.hpp > /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/AngleMeasure/s= rc/AngleMeasure.hpp > : File name too long > *** Error code 1 > > Stop in /usr/ports/astro/stellarium. > *** Error code 1 > > I have no idea what the error cuases. I tried to delete everything and > reinstall, but the error seems to be very sticky. I checked the > /usr/ports partition (UFS2, UFS-Journaling on) several time for errors, > but it seems to be clean. > > Any ideas what's going on? Probably this PR: kern/161481, but it wouldn't hurt to confirm via ktrace. Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 22:04:34 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5672B1065672; Sun, 27 Nov 2011 22:04:34 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 276BB8FC12; Sun, 27 Nov 2011 22:04:33 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pARM4XiW056429; Sun, 27 Nov 2011 17:04:33 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pARM4Xwd056413; Sun, 27 Nov 2011 22:04:33 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 27 Nov 2011 22:04:33 GMT Message-Id: <201111272204.pARM4Xwd056413@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2011 22:04:34 -0000 TB --- 2011-11-27 19:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-27 19:10:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-11-27 19:10:00 - cleaning the object tree TB --- 2011-11-27 19:10:54 - cvsupping the source tree TB --- 2011-11-27 19:10:54 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-11-27 19:11:06 - building world TB --- 2011-11-27 19:11:06 - CROSS_BUILD_TESTING=YES TB --- 2011-11-27 19:11:06 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-27 19:11:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-27 19:11:06 - SRCCONF=/dev/null TB --- 2011-11-27 19:11:06 - TARGET=amd64 TB --- 2011-11-27 19:11:06 - TARGET_ARCH=amd64 TB --- 2011-11-27 19:11:06 - TZ=UTC TB --- 2011-11-27 19:11:06 - __MAKE_CONF=/dev/null TB --- 2011-11-27 19:11:06 - cd /src TB --- 2011-11-27 19:11:06 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 27 19:11:07 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sun Nov 27 21:52:53 UTC 2011 TB --- 2011-11-27 21:52:53 - generating LINT kernel config TB --- 2011-11-27 21:52:53 - cd /src/sys/amd64/conf TB --- 2011-11-27 21:52:53 - /usr/bin/make -B LINT TB --- 2011-11-27 21:52:53 - cd /src/sys/amd64/conf TB --- 2011-11-27 21:52:53 - /usr/sbin/config -m LINT-NOINET TB --- 2011-11-27 21:52:53 - building LINT-NOINET kernel TB --- 2011-11-27 21:52:53 - CROSS_BUILD_TESTING=YES TB --- 2011-11-27 21:52:53 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-27 21:52:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-27 21:52:53 - SRCCONF=/dev/null TB --- 2011-11-27 21:52:53 - TARGET=amd64 TB --- 2011-11-27 21:52:53 - TARGET_ARCH=amd64 TB --- 2011-11-27 21:52:53 - TZ=UTC TB --- 2011-11-27 21:52:53 - __MAKE_CONF=/dev/null TB --- 2011-11-27 21:52:53 - cd /src TB --- 2011-11-27 21:52:53 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Sun Nov 27 21:52:53 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_ntptime.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_osd.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_physio.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_pmc.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_poll.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_priv.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_proc.c /src/sys/kern/kern_proc.c:2589: error: 'KERN_PROC_PS_STRINGS' undeclared here (not in a function) *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT-NOINET. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-27 22:04:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-27 22:04:32 - ERROR: failed to build LINT-NOINET kernel TB --- 2011-11-27 22:04:32 - 8283.38 user 1566.22 system 10471.89 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 22:20:10 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14424106566C; Sun, 27 Nov 2011 22:20:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A6ACD8FC0A; Sun, 27 Nov 2011 22:20:09 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pARMK8pd075477; Sun, 27 Nov 2011 17:20:08 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pARMK8mb075469; Sun, 27 Nov 2011 22:20:08 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 27 Nov 2011 22:20:08 GMT Message-Id: <201111272220.pARMK8mb075469@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2011 22:20:10 -0000 TB --- 2011-11-27 21:26:04 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-27 21:26:04 - starting HEAD tinderbox run for mips/mips TB --- 2011-11-27 21:26:04 - cleaning the object tree TB --- 2011-11-27 21:26:12 - cvsupping the source tree TB --- 2011-11-27 21:26:12 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2011-11-27 21:26:26 - building world TB --- 2011-11-27 21:26:26 - CROSS_BUILD_TESTING=YES TB --- 2011-11-27 21:26:26 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-27 21:26:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-27 21:26:26 - SRCCONF=/dev/null TB --- 2011-11-27 21:26:26 - TARGET=mips TB --- 2011-11-27 21:26:26 - TARGET_ARCH=mips TB --- 2011-11-27 21:26:26 - TZ=UTC TB --- 2011-11-27 21:26:26 - __MAKE_CONF=/dev/null TB --- 2011-11-27 21:26:26 - cd /src TB --- 2011-11-27 21:26:26 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 27 21:26:26 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.bin/procstat/procstat_auxv.c:123: warning: format '%ld' expects type 'long int', but argument 4 has type 'int' /src/usr.bin/procstat/procstat_auxv.c:128: warning: format '%ld' expects type 'long int', but argument 4 has type 'int' /src/usr.bin/procstat/procstat_auxv.c:133: warning: format '%ld' expects type 'long int', but argument 4 has type 'int' /src/usr.bin/procstat/procstat_auxv.c:143: warning: format '%ld' expects type 'long int', but argument 4 has type 'int' /src/usr.bin/procstat/procstat_auxv.c:146: warning: format '%ld' expects type 'long int', but argument 4 has type 'int' /src/usr.bin/procstat/procstat_auxv.c:149: warning: format '%ld' expects type 'long int', but argument 4 has type 'int' /src/usr.bin/procstat/procstat_auxv.c:155: warning: format '%ld' expects type 'long int', but argument 4 has type 'int' /src/usr.bin/procstat/procstat_auxv.c:164: warning: format '%ld' expects type 'long int', but argument 4 has type 'int' *** Error code 1 Stop in /src/usr.bin/procstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-27 22:20:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-27 22:20:08 - ERROR: failed to build world TB --- 2011-11-27 22:20:08 - 2329.81 user 651.16 system 3244.27 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 22:41:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71F48106566B for ; Sun, 27 Nov 2011 22:41:36 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by mx1.freebsd.org (Postfix) with ESMTP id 131488FC16 for ; Sun, 27 Nov 2011 22:41:35 +0000 (UTC) X-AuditID: 12074424-b7ef76d0000008dc-ff-4ed2bc9fcb3c Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 04.40.02268.F9CB2DE4; Sun, 27 Nov 2011 17:41:35 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id pARMfYBn022123; Sun, 27 Nov 2011 17:41:35 -0500 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id pARMfW5c025496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 27 Nov 2011 17:41:34 -0500 (EST) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id pARMfWqw023616; Sun, 27 Nov 2011 17:41:32 -0500 (EST) Date: Sun, 27 Nov 2011 17:41:32 -0500 (EST) From: Benjamin Kaduk To: "V. T. Mueller, Continum" In-Reply-To: <2034494367.81719.1322315467842.JavaMail.root@zimbra> Message-ID: References: <2034494367.81719.1322315467842.JavaMail.root@zimbra> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJIsWRmVeSWpSXmKPExsUixG6nojt/zyU/g4tzBSzmvPnAZLHpxn92 ByaP5Uta2TxmfJrPEsAUxWWTkpqTWZZapG+XwJVxawJrwXT2ioULmlkbGB+xdjFyckgImEis m/SEEcIWk7hwbz0biC0ksI9R4vWzLAh7A6PEpWlaXYxcQPYBJomjO3ewQiQaGCXu7U0EsVkE tCWmLGhjBrHZBFQkZr7ZCDSIg0NEwELi6YtgkDCzgLzE/yuXmUBsYSB7/btVYOWcAk4S2+5f ZgGxeQXsJfrP32SBGO8osX11A1i9qICOxOr9U6BqBCVOznzCAjHTUuLcn+tsExgFZyFJzUKS WsDItIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXXC83s0QvNaV0EyM4RF1UdjA2H1I6xCjAwajE w/ui96KfEGtiWXFl7iFGSQ4mJVHe+F2X/IT4kvJTKjMSizPii0pzUosPMUpwMCuJ8HKsB8rx piRWVqUW5cOkpDlYlMR5bXY6+AkJpCeWpGanphakFsFkZTg4lCR4eYGxKCRYlJqeWpGWmVOC kGbi4AQZzgM0/OtukOHFBYm5xZnpEPlTjIpS4ryiIM0CIImM0jy4XlgKecUoDvSKMO8fkHYe YPqB634FNJgJ5OqZF0AGlyQipKQaGFfPPMJwUFK2sFbtSRPTj/kcvtPuKyvWcjiWnVVYIPaI 5/ynzKNpCaqJTCmL3k09cqkp5ZYXl5vOsr/VT1rEGhe49kQ2uqxdFhQzLcvgrTTDRuntFQd+ rVj080fFbBf9F2kveXe/CD5wqj3jq45WoU79/PVzzmSkBE0K/NO4d+GTrl0nvhXUXVdiKc5I NNRiLipOBAA6o9He/AIAAA== Cc: freebsd-current@freebsd.org Subject: Re: infiniband anyone? 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, 27 Nov 2011 22:41:36 -0000 On Sat, 26 Nov 2011, V. T. Mueller, Continum wrote: > Hello, > > There were rumours that OFED infiniband support made its way into 9.0 . > A vanilla 9.0-RC2 install, however does not indicate detection of IB hardware. > It's in the todo-list, but svn hasn't been touched since spring. > > Does anyone know when / in which release IB support will be available? > Or does it require a custom kernel build? > > An update to the wiki page here: > http://wiki.freebsd.org/InfiniBand > > would be a nice move, since I guess there are a couple of people out > there who are interested in combining IB and ZFS. I believe the OFED support is not enabled in the default installation. Per the merge annoucement here: http://lists.freebsd.org/pipermail/freebsd-current/2011-March/023554.html "OFED will not be built by default and WITH_OFED must be defined in /etc/make.conf to enable it." -Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 23:35:39 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BB9E106566B; Sun, 27 Nov 2011 23:35:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id CD5B48FC0C; Sun, 27 Nov 2011 23:35:38 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pARNZb6H072111; Sun, 27 Nov 2011 18:35:37 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pARNZbtw072110; Sun, 27 Nov 2011 23:35:37 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 27 Nov 2011 23:35:37 GMT Message-Id: <201111272335.pARNZbtw072110@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2011 23:35:39 -0000 TB --- 2011-11-27 21:39:40 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-27 21:39:40 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-11-27 21:39:40 - cleaning the object tree TB --- 2011-11-27 21:39:56 - cvsupping the source tree TB --- 2011-11-27 21:39:56 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-11-27 21:40:08 - building world TB --- 2011-11-27 21:40:08 - CROSS_BUILD_TESTING=YES TB --- 2011-11-27 21:40:08 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-27 21:40:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-27 21:40:08 - SRCCONF=/dev/null TB --- 2011-11-27 21:40:08 - TARGET=powerpc TB --- 2011-11-27 21:40:08 - TARGET_ARCH=powerpc TB --- 2011-11-27 21:40:08 - TZ=UTC TB --- 2011-11-27 21:40:08 - __MAKE_CONF=/dev/null TB --- 2011-11-27 21:40:08 - cd /src TB --- 2011-11-27 21:40:08 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 27 21:40:09 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Nov 27 23:32:01 UTC 2011 TB --- 2011-11-27 23:32:01 - generating LINT kernel config TB --- 2011-11-27 23:32:01 - cd /src/sys/powerpc/conf TB --- 2011-11-27 23:32:01 - /usr/bin/make -B LINT TB --- 2011-11-27 23:32:01 - cd /src/sys/powerpc/conf TB --- 2011-11-27 23:32:01 - /usr/sbin/config -m GENERIC TB --- 2011-11-27 23:32:01 - building GENERIC kernel TB --- 2011-11-27 23:32:01 - CROSS_BUILD_TESTING=YES TB --- 2011-11-27 23:32:01 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-27 23:32:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-27 23:32:01 - SRCCONF=/dev/null TB --- 2011-11-27 23:32:01 - TARGET=powerpc TB --- 2011-11-27 23:32:01 - TARGET_ARCH=powerpc TB --- 2011-11-27 23:32:01 - TZ=UTC TB --- 2011-11-27 23:32:01 - __MAKE_CONF=/dev/null TB --- 2011-11-27 23:32:01 - cd /src TB --- 2011-11-27 23:32:01 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Nov 27 23:32:01 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_mutex.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_ntptime.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_osd.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_physio.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_pmc.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_priv.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_proc.c /src/sys/kern/kern_proc.c:2589: error: 'KERN_PROC_PS_STRINGS' undeclared here (not in a function) *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-27 23:35:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-27 23:35:37 - ERROR: failed to build GENERIC kernel TB --- 2011-11-27 23:35:37 - 5783.05 user 1027.30 system 6956.70 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 23:42:59 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE198106566B for ; Sun, 27 Nov 2011 23:42:59 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 20B718FC13 for ; Sun, 27 Nov 2011 23:42:58 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA20491 for ; Mon, 28 Nov 2011 01:42:57 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RUoN6-000Kb0-V1 for freebsd-current@freebsd.org; Mon, 28 Nov 2011 01:42:56 +0200 Message-ID: <4ED2CAFF.7070608@FreeBSD.org> Date: Mon, 28 Nov 2011 01:42:55 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: FreeBSD current X-Enigmail-Version: undefined Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: Subject: array index of '-16' indexes before the beginning of the array 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, 27 Nov 2011 23:42:59 -0000 Looks like clang has found a real issue here: /usr/src/sys/x86/x86/local_apic.c:311:2: warning: array index of '-16' indexes before the beginning of the array [-Warray-bounds] lapics[apic_id].la_ioint_irqs[IDT_DTRACE_RET - APIC_IO_INTS] = IRQ_DTRACE_RET; IDT_DTRACE_RET (0x20) indeed seems to be less than APIC_IO_INTS. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Nov 27 23:51:05 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37686106566B for ; Sun, 27 Nov 2011 23:51:05 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 9F8038FC18 for ; Sun, 27 Nov 2011 23:51:04 +0000 (UTC) Received: by wwe5 with SMTP id 5so7561048wwe.31 for ; Sun, 27 Nov 2011 15:51:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=blEXbJ0p8z5V+sj34v0ElUGsXRM0MgIo91KvSvBEzB4=; b=wcYCz1BdRXKJg7wHuKvhSmJIpInCS1upHB3StTjQ77O5KakNJ1KtG8m2g3ekjzcYTH v9J8OThayB8/39/J8MW6HNdZL2BzkhS3WUmiQbvHRSes9SiVX+Kr0AIlxQBjxoQ5c5Bx +o8p16WUMGLzfZ2TmBxW+9X+ru9wMgVkFE4Mo= MIME-Version: 1.0 Received: by 10.180.90.6 with SMTP id bs6mr41773126wib.63.1322437863531; Sun, 27 Nov 2011 15:51:03 -0800 (PST) Received: by 10.180.101.102 with HTTP; Sun, 27 Nov 2011 15:51:03 -0800 (PST) In-Reply-To: <4ED2CAFF.7070608@FreeBSD.org> References: <4ED2CAFF.7070608@FreeBSD.org> Date: Sun, 27 Nov 2011 18:51:03 -0500 Message-ID: From: Ryan Stone To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD current Subject: Re: array index of '-16' indexes before the beginning of the array 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, 27 Nov 2011 23:51:05 -0000 On Sun, Nov 27, 2011 at 6:42 PM, Andriy Gapon wrote: > > Looks like clang has found a real issue here: > /usr/src/sys/x86/x86/local_apic.c:311:2: warning: array index of '-16' in= dexes > before the beginning of the array [-Warray-bounds] > =A0 =A0 =A0 =A0lapics[apic_id].la_ioint_irqs[IDT_DTRACE_RET - APIC_IO_INT= S] =3D > IRQ_DTRACE_RET; > > IDT_DTRACE_RET (0x20) indeed seems to be less than APIC_IO_INTS. Uh-oh, I appear to have broken this in r227290. I'll try to figure out what's actually supposed to be done here. From owner-freebsd-current@FreeBSD.ORG Mon Nov 28 00:06:18 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7C321065670; Mon, 28 Nov 2011 00:06:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 997478FC0A; Mon, 28 Nov 2011 00:06:18 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAS06Hak062908; Sun, 27 Nov 2011 19:06:17 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAS06HZV062907; Mon, 28 Nov 2011 00:06:17 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 28 Nov 2011 00:06:17 GMT Message-Id: <201111280006.pAS06HZV062907@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 00:06:18 -0000 TB --- 2011-11-27 21:43:52 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-27 21:43:52 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-11-27 21:43:52 - cleaning the object tree TB --- 2011-11-27 21:44:10 - cvsupping the source tree TB --- 2011-11-27 21:44:10 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-11-27 21:44:22 - building world TB --- 2011-11-27 21:44:22 - CROSS_BUILD_TESTING=YES TB --- 2011-11-27 21:44:22 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-27 21:44:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-27 21:44:22 - SRCCONF=/dev/null TB --- 2011-11-27 21:44:22 - TARGET=powerpc TB --- 2011-11-27 21:44:22 - TARGET_ARCH=powerpc64 TB --- 2011-11-27 21:44:22 - TZ=UTC TB --- 2011-11-27 21:44:22 - __MAKE_CONF=/dev/null TB --- 2011-11-27 21:44:22 - cd /src TB --- 2011-11-27 21:44:22 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 27 21:44:23 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Mon Nov 28 00:02:24 UTC 2011 TB --- 2011-11-28 00:02:24 - generating LINT kernel config TB --- 2011-11-28 00:02:24 - cd /src/sys/powerpc/conf TB --- 2011-11-28 00:02:24 - /usr/bin/make -B LINT TB --- 2011-11-28 00:02:25 - cd /src/sys/powerpc/conf TB --- 2011-11-28 00:02:25 - /usr/sbin/config -m GENERIC TB --- 2011-11-28 00:02:25 - skipping GENERIC kernel TB --- 2011-11-28 00:02:25 - cd /src/sys/powerpc/conf TB --- 2011-11-28 00:02:25 - /usr/sbin/config -m GENERIC64 TB --- 2011-11-28 00:02:25 - building GENERIC64 kernel TB --- 2011-11-28 00:02:25 - CROSS_BUILD_TESTING=YES TB --- 2011-11-28 00:02:25 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-28 00:02:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-28 00:02:25 - SRCCONF=/dev/null TB --- 2011-11-28 00:02:25 - TARGET=powerpc TB --- 2011-11-28 00:02:25 - TARGET_ARCH=powerpc64 TB --- 2011-11-28 00:02:25 - TZ=UTC TB --- 2011-11-28 00:02:25 - __MAKE_CONF=/dev/null TB --- 2011-11-28 00:02:25 - cd /src TB --- 2011-11-28 00:02:25 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 >>> Kernel build for GENERIC64 started on Mon Nov 28 00:02:25 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_mutex.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_ntptime.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_osd.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_physio.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_pmc.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_priv.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_proc.c /src/sys/kern/kern_proc.c:2589: error: 'KERN_PROC_PS_STRINGS' undeclared here (not in a function) *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/GENERIC64. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-28 00:06:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-28 00:06:17 - ERROR: failed to build GENERIC64 kernel TB --- 2011-11-28 00:06:17 - 7146.45 user 1321.93 system 8544.81 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Nov 28 00:59:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAD9C106567C; Mon, 28 Nov 2011 00:59:40 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 422BF8FC1C; Mon, 28 Nov 2011 00:59:39 +0000 (UTC) Received: by wwe5 with SMTP id 5so7657943wwe.31 for ; Sun, 27 Nov 2011 16:59:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=dYCaeygb8GQUNIYCMTLYzZPCJZy72vAjmKGjn6jlkzE=; b=EwNmSnpjWq8NXqoF7I6VtAkFzuZHk1wLdDrnQkeSaxGKFAmOWI7py4g2Z6k2qsMUPa 7oWF3xYakX4WA4y+jkJjfI5Um7uM4VDnYmJmhij3xwelC5QlkAgzGpUttczVuHYaxnza EPqCzIpAqEJshwFeeR+0wAfGlPjsNR72yGpgM= MIME-Version: 1.0 Received: by 10.180.90.6 with SMTP id bs6mr41901893wib.63.1322441979133; Sun, 27 Nov 2011 16:59:39 -0800 (PST) Received: by 10.180.101.102 with HTTP; Sun, 27 Nov 2011 16:59:39 -0800 (PST) In-Reply-To: <4ED2CAFF.7070608@FreeBSD.org> References: <4ED2CAFF.7070608@FreeBSD.org> Date: Sun, 27 Nov 2011 19:59:39 -0500 Message-ID: From: Ryan Stone To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD current Subject: Re: array index of '-16' indexes before the beginning of the array 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, 28 Nov 2011 00:59:40 -0000 On Sun, Nov 27, 2011 at 6:42 PM, Andriy Gapon wrote: > > Looks like clang has found a real issue here: > /usr/src/sys/x86/x86/local_apic.c:311:2: warning: array index of '-16' in= dexes > before the beginning of the array [-Warray-bounds] > =A0 =A0 =A0 =A0lapics[apic_id].la_ioint_irqs[IDT_DTRACE_RET - APIC_IO_INT= S] =3D > IRQ_DTRACE_RET; Hm, so as far as I can tell the DTrace-related code in local_apic.c is bogus. DTrace's interrupt vectors are 32 and 33, which aren't I/O vectors, so local_apic.c shouldn't need to know anything about them. I think that the right fix is to remove all of it from local_apic.c. From owner-freebsd-current@FreeBSD.ORG Mon Nov 28 02:21:26 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A94B31065670; Mon, 28 Nov 2011 02:21:26 +0000 (UTC) (envelope-from feld@feld.me) Received: from mwi1.coffeenet.org (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5E23E8FC12; Mon, 28 Nov 2011 02:21:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=Message-Id:References:In-Reply-To:Subject:To:From:Date:Content-Type:Mime-Version; bh=nu5wCuFJB2x6UzTAvYyJpklGSW8NmseEG6Dk1u/zq+g=; b=YiLnjfIhRY3zod1avQDQ1gYGDef4XaNfrbRCuslWIOiRauxp911nqpYiqWnYHHeXLzIWClDOeOaVoJgzOYHDN+95SMDztj9QT78rpsxjzMgEL6/C3EeHmZj99DThLP0+; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by mwi1.coffeenet.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RUqqS-00086j-Ch; Sun, 27 Nov 2011 20:21:25 -0600 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpsa id 1322446878-1863-1862/5/4; Mon, 28 Nov 2011 02:21:18 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Date: Sun, 27 Nov 2011 20:21:18 -0600 From: Mark Felder To: freebsd-fs@freebsd.org, freebsd-current@freebsd.org In-Reply-To: <881f876f-6f27-49fd-b6c7-edbe6493ec75@email.android.com> References: <95d00c1b714837aa32e7da72bc4afd03@feld.me> <20111126104840.GA8794@garage.freebsd.pl> <881f876f-6f27-49fd-b6c7-edbe6493ec75@email.android.com> Message-Id: <820791346f600ea50ff9ebd68e30c059@feld.me> X-Sender: feld@feld.me User-Agent: Roundcube Webmail/0.6 X-SA-Score: -1.0 Cc: Subject: Re: zfs i/o hangs on 9-PRERELEASE 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, 28 Nov 2011 02:21:26 -0000 After many hours of testing, reproducing, and testing again I've finally been able to narrow down what the real issue is and it's not ZFS as I suspected. After completely turning off all NFS functionality and serving my files over Samba I haven't had a single issue. It seems there is something going on with the new NFS code (I serve out over v4, but reproduced it last week with v3) and my media player box, a Popcorn Hour A-200 which is running Linux. If I can cobble some hardware together and place it between so I can do some tcpdumps I will provide that data so perhaps someone can understand what's going on. If this is due to a badly behaving client this is potentially a DoS on the server. Regards, Mark From owner-freebsd-current@FreeBSD.ORG Mon Nov 28 03:02:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7830D106566C for ; Mon, 28 Nov 2011 03:02:56 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by mx1.freebsd.org (Postfix) with ESMTP id 1850F8FC12 for ; Mon, 28 Nov 2011 03:02:53 +0000 (UTC) X-AuditID: 12074425-b7f116d0000008fe-5f-4ed2f9dd48b9 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 06.15.02302.DD9F2DE4; Sun, 27 Nov 2011 22:02:53 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id pAS32rMf009322; Sun, 27 Nov 2011 22:02:53 -0500 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id pAS32oMO025934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 27 Nov 2011 22:02:53 -0500 (EST) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id pAS32oM3026151; Sun, 27 Nov 2011 22:02:50 -0500 (EST) Date: Sun, 27 Nov 2011 22:02:50 -0500 (EST) From: Benjamin Kaduk To: ZaRiuS KRiNG In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixG6nonv35yU/g+ZPShZz3nxgsui5e4rJ gcljxqf5LB47Z91lD2CK4rJJSc3JLEst0rdL4MrYcWIPW8EzlootO48xNjDeZe5i5OSQEDCR ONk3kQnCFpO4cG89WxcjF4eQwD5GiUurv7JAOBsYJdqPd7BCOAeYJPYfXcAM4TQwSuycOJ8d pJ9FQFvi65/pYLPYBFQkZr7ZyAZiiwgoS0yf8BCshllAXuL/lctgNcIClhIPjh4Di3MKBEq8 u/Af7CZeAXuJA8/ng/UKCQRINB7ZywhiiwroSKzeP4UFokZQ4uTMJywQMy0lzv25zjaBUXAW ktQsJKkFjEyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdC30cjNL9FJTSjcxgoPVRXUH44RDSocY BTgYlXh4N16+5CfEmlhWXJl7iFGSg0lJlFfhO1CILyk/pTIjsTgjvqg0J7X4EKMEB7OSCG/P UaAcb0piZVVqUT5MSpqDRUmc9/UOBz8hgfTEktTs1NSC1CKYrAwHh5IEbzUwKoUEi1LTUyvS MnNKENJMHJwgw3mAhmeD1PAWFyTmFmemQ+RPMSpKifP6gCQEQBIZpXlwvbBk8opRHOgVYd5c kCoeYCKC634FNJgJaDDHzAsgg0sSEVJSDYxWjLzWjp/SW4pC3xwu3/E/P+BGwaHeiTZtlzkn THSeVK+U7nWi7uwuVeX3PJcD8w58/L9TQmhnbunFKdfOpj2zmmA0fWuApqD/UcZ1VgpHOw9t v5/5NL1XSI6ttXhnHWeMwuzUZzEpB21fSSwKPuOwWfr8gy1Ca3/xHfmq8rE0sV3WOi7xmbYS S3FGoqEWc1FxIgBBiMdbAQMAAA== Cc: freebsd-current@freebsd.org Subject: Re: Problem compiling libs after pass to 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, 28 Nov 2011 03:02:56 -0000 On Sun, 27 Nov 2011, ZaRiuS KRiNG wrote: > Hi! is my first post here and have a little problem try to google some and > don't find any of value. > > A week ago compile the src of current, and after that in any new port i > install, if compile before any lib, don't work, i need to install pkg from > repository of that lib and continue compiling the program, and work fine. > Just have this problem with the libs I am having a hard time following this explanation. Could you make it concrete and mention which ports you were installing and in what order, and which programs failed? -Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Mon Nov 28 03:35:34 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2360E106566C; Mon, 28 Nov 2011 03:35:34 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id B91FC8FC08; Mon, 28 Nov 2011 03:35:33 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAS3ZWM2041988; Sun, 27 Nov 2011 22:35:33 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAS3ZWPc041987; Mon, 28 Nov 2011 03:35:32 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 28 Nov 2011 03:35:32 GMT Message-Id: <201111280335.pAS3ZWPc041987@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 03:35:34 -0000 TB --- 2011-11-28 02:40:42 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-28 02:40:42 - starting HEAD tinderbox run for mips/mips TB --- 2011-11-28 02:40:43 - cleaning the object tree TB --- 2011-11-28 02:40:58 - cvsupping the source tree TB --- 2011-11-28 02:40:58 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2011-11-28 02:41:16 - building world TB --- 2011-11-28 02:41:16 - CROSS_BUILD_TESTING=YES TB --- 2011-11-28 02:41:16 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-28 02:41:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-28 02:41:16 - SRCCONF=/dev/null TB --- 2011-11-28 02:41:16 - TARGET=mips TB --- 2011-11-28 02:41:16 - TARGET_ARCH=mips TB --- 2011-11-28 02:41:16 - TZ=UTC TB --- 2011-11-28 02:41:16 - __MAKE_CONF=/dev/null TB --- 2011-11-28 02:41:16 - cd /src TB --- 2011-11-28 02:41:16 - /usr/bin/make -B buildworld >>> World build started on Mon Nov 28 02:41:17 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.bin/procstat/procstat_auxv.c:123: warning: format '%ld' expects type 'long int', but argument 4 has type 'int' /src/usr.bin/procstat/procstat_auxv.c:128: warning: format '%ld' expects type 'long int', but argument 4 has type 'int' /src/usr.bin/procstat/procstat_auxv.c:133: warning: format '%ld' expects type 'long int', but argument 4 has type 'int' /src/usr.bin/procstat/procstat_auxv.c:143: warning: format '%ld' expects type 'long int', but argument 4 has type 'int' /src/usr.bin/procstat/procstat_auxv.c:146: warning: format '%ld' expects type 'long int', but argument 4 has type 'int' /src/usr.bin/procstat/procstat_auxv.c:149: warning: format '%ld' expects type 'long int', but argument 4 has type 'int' /src/usr.bin/procstat/procstat_auxv.c:155: warning: format '%ld' expects type 'long int', but argument 4 has type 'int' /src/usr.bin/procstat/procstat_auxv.c:164: warning: format '%ld' expects type 'long int', but argument 4 has type 'int' *** Error code 1 Stop in /src/usr.bin/procstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-28 03:35:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-28 03:35:32 - ERROR: failed to build world TB --- 2011-11-28 03:35:32 - 2338.33 user 643.64 system 3289.80 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Mon Nov 28 04:36:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D872C1065741 for ; Mon, 28 Nov 2011 04:36:24 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by mx1.freebsd.org (Postfix) with ESMTP id 7A6998FC1E for ; Mon, 28 Nov 2011 04:36:24 +0000 (UTC) X-AuditID: 12074424-b7ef76d0000008dc-09-4ed30fc76f7d Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 85.B7.02268.7CF03DE4; Sun, 27 Nov 2011 23:36:23 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id pAS4aNmk016825; Sun, 27 Nov 2011 23:36:23 -0500 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id pAS4aLpH006506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 27 Nov 2011 23:36:22 -0500 (EST) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id pAS4aKpb027252; Sun, 27 Nov 2011 23:36:20 -0500 (EST) Date: Sun, 27 Nov 2011 23:36:19 -0500 (EST) From: Benjamin Kaduk To: Peter In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixG6nonuc/7KfwfyJ2haXHs5jspjz5gOT A5PHjE/zWTx+/jrFHMAUxWWTkpqTWZZapG+XwJUxe9tkpoIXbBXbJzUwNjAuY+1i5OCQEDCR uHC3pouRE8gUk7hwbz1bFyMXh5DAPkaJfUseskM4Gxglvv74xgrhHGCS+LVrM5TTwChxddl+ JpB+FgFtiU+3T4DZbAIqEjPfbGQDWSEiICNxazsbSJhZQF7i/5XLTCBhYQEjiZY7XCBhTgE3 iR8Lp4KV8ArYS+w+Po0VxBYScJV48v0bmC0qoCOxev8UFogaQYmTM5+wQIy0lDj35zrbBEbB WUhSs5CkFjAyrWKUTcmt0s1NzMwpTk3WLU5OzMtLLdI118vNLNFLTSndxAgOUxeVHYzNh5QO MQpwMCrx8G64fMlPiDWxrLgy9xCjJAeTkijveb7LfkJ8SfkplRmJxRnxRaU5qcWHGCU4mJVE eHuOApXzpiRWVqUW5cOkpDlYlMR5bXY6+AkJpCeWpGanphakFsFkZTg4lCR4hYDxKCRYlJqe WpGWmVOCkGbi4AQZzgM0vIULqIa3uCAxtzgzHSJ/ilFRSpxXBqRZACSRUZoH1wtLI68YxYFe EeZ9wApUxQNMQXDdr4AGMwEN5ph5AWRwSSJCSqqBcY0/h/BUTSsn44p9cTvzPYvf1u+xnfW1 6XpXdt+PvDWz99+ZNn+CVN/piC3Pv13VZWZoOBn7Yeq8Z1YHfm796mNz4NnOfUuXfjq7R2NC x9eDztpdZY75Zvsz3y9uaNKWvbxVZlX1zgnbLr+dyHHzXiRXrsWJGVbXbzSXLRKe89/+bP6M ZL/Z+58rsRRnJBpqMRcVJwIARSQKFv4CAAA= Cc: freebsd-current@freebsd.org Subject: Re: 9.0-RC2 - bsdinstall - new user group 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, 28 Nov 2011 04:36:24 -0000 On Mon, 21 Nov 2011, Peter wrote: > Doing a fresh install of 9.0RC2 [amd64]. > > Add User Accounts -> Yes > > [stuff between '*' is my input/answers] > > Username: *peter* > Full name: *P* > UID: [default] > Login group [peter]: *admin* > Group admin does not exist! > Login group [peter]: *ENTER* > Login group is peter. Invite peter into other groups? []? > . > .. > .... > > Why can the installer create a new login group 'peter' but not a new login > group 'admin' ?. > [when adding second user, I can input Login Group of 'peter' without any > problems, or third user can create a group name of its name, but still > no 'admin' group unless I add an 'admin' user]. This looks roughly like http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/161100 so I wouldn't open a new PR for it. Thanks for the testing and bug reports. -Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Mon Nov 28 07:12:05 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E4E7106566B for ; Mon, 28 Nov 2011 07:12:05 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id C069C8FC0C for ; Mon, 28 Nov 2011 07:12:04 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so9952409bkb.13 for ; Sun, 27 Nov 2011 23:12:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:organization:references:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=QVVgcewwKTcCasL0TPcVQErHszG+FrlnNxlLMRzWW0s=; b=NXg3DBJO8GJDtt0wLS8FnwuHyxYLBRqxNnl1wWIGGP9dFH0vKY6JIDzjNnWUUHH+DM GWN6iauvBscK6Dn57ceZ1PLcSe+J92rUPEFa838ecmVwmwhyC5sPr9hkTLDxw+Lopcs3 qZUb3bLc8edVCaUXkLbeLYpiYLLehhcuR/HLs= Received: by 10.204.154.143 with SMTP id o15mr18619146bkw.17.1322464321918; Sun, 27 Nov 2011 23:12:01 -0800 (PST) Received: from localhost ([94.27.39.186]) by mx.google.com with ESMTPS id x14sm27812056bkf.10.2011.11.27.23.11.57 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 Nov 2011 23:11:58 -0800 (PST) From: Mikolaj Golub To: FreeBSD Tinderbox Organization: TOA Ukraine References: <201111280335.pAS3ZWPc041987@freebsd-current.sentex.ca> Sender: Mikolaj Golub Date: Mon, 28 Nov 2011 09:11:56 +0200 In-Reply-To: <201111280335.pAS3ZWPc041987@freebsd-current.sentex.ca> (FreeBSD Tinderbox's message of "Mon, 28 Nov 2011 03:35:32 GMT") Message-ID: <86r50swwjn.fsf@in138.ua3> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mips@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on mips/mips 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, 28 Nov 2011 07:12:05 -0000 On Mon, 28 Nov 2011 03:35:32 GMT FreeBSD Tinderbox wrote: FT> TB --- 2011-11-28 02:40:42 - tinderbox 2.8 running on freebsd-current.sentex.ca FT> TB --- 2011-11-28 02:40:42 - starting HEAD tinderbox run for mips/mips FT> TB --- 2011-11-28 02:40:43 - cleaning the object tree FT> TB --- 2011-11-28 02:40:58 - cvsupping the source tree FT> TB --- 2011-11-28 02:40:58 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile FT> TB --- 2011-11-28 02:41:16 - building world FT> TB --- 2011-11-28 02:41:16 - CROSS_BUILD_TESTING=YES FT> TB --- 2011-11-28 02:41:16 - MAKEOBJDIRPREFIX=/obj FT> TB --- 2011-11-28 02:41:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin FT> TB --- 2011-11-28 02:41:16 - SRCCONF=/dev/null FT> TB --- 2011-11-28 02:41:16 - TARGET=mips FT> TB --- 2011-11-28 02:41:16 - TARGET_ARCH=mips FT> TB --- 2011-11-28 02:41:16 - TZ=UTC FT> TB --- 2011-11-28 02:41:16 - __MAKE_CONF=/dev/null FT> TB --- 2011-11-28 02:41:16 - cd /src FT> TB --- 2011-11-28 02:41:16 - /usr/bin/make -B buildworld >>>> World build started on Mon Nov 28 02:41:17 UTC 2011 >>>> Rebuilding the temporary build tree >>>> stage 1.1: legacy release compatibility shims >>>> stage 1.2: bootstrap tools >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3: cross tools >>>> stage 4.1: building includes >>>> stage 4.2: building libraries >>>> stage 4.3: make dependencies >>>> stage 4.4: building everything FT> [...] FT> /src/usr.bin/procstat/procstat_auxv.c:123: warning: format '%ld' expects type 'long int', but argument 4 has type 'int' FT> /src/usr.bin/procstat/procstat_auxv.c:128: warning: format '%ld' expects type 'long int', but argument 4 has type 'int' FT> /src/usr.bin/procstat/procstat_auxv.c:133: warning: format '%ld' expects type 'long int', but argument 4 has type 'int' FT> /src/usr.bin/procstat/procstat_auxv.c:143: warning: format '%ld' expects type 'long int', but argument 4 has type 'int' FT> /src/usr.bin/procstat/procstat_auxv.c:146: warning: format '%ld' expects type 'long int', but argument 4 has type 'int' FT> /src/usr.bin/procstat/procstat_auxv.c:149: warning: format '%ld' expects type 'long int', but argument 4 has type 'int' FT> /src/usr.bin/procstat/procstat_auxv.c:155: warning: format '%ld' expects type 'long int', but argument 4 has type 'int' FT> /src/usr.bin/procstat/procstat_auxv.c:164: warning: format '%ld' expects type 'long int', but argument 4 has type 'int' FT> *** Error code 1 Sorry, should be fixed in r228049. -- Mikolaj Golub From owner-freebsd-current@FreeBSD.ORG Mon Nov 28 07:48:34 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE4F2106566B; Mon, 28 Nov 2011 07:48:34 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [IPv6:2a01:4f8:150:6101::4]) by mx1.freebsd.org (Postfix) with ESMTP id 6AD238FC0C; Mon, 28 Nov 2011 07:48:34 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.2]) by mail.vx.sk (Postfix) with ESMTP id 9ED3215C59; Mon, 28 Nov 2011 08:48:33 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk by core.vx.sk (amavisd-new, unix socket) with LMTP id REYqUcXXQMKW; Mon, 28 Nov 2011 08:48:31 +0100 (CET) Received: from [10.9.8.1] (188-167-78-15.dynamic.chello.sk [188.167.78.15]) by mail.vx.sk (Postfix) with ESMTPSA id 83CC615C52; Mon, 28 Nov 2011 08:48:29 +0100 (CET) Message-ID: <4ED33CCC.1050405@FreeBSD.org> Date: Mon, 28 Nov 2011 08:48:28 +0100 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Mark Felder References: <95d00c1b714837aa32e7da72bc4afd03@feld.me> <20111126104840.GA8794@garage.freebsd.pl> <881f876f-6f27-49fd-b6c7-edbe6493ec75@email.android.com> <820791346f600ea50ff9ebd68e30c059@feld.me> In-Reply-To: <820791346f600ea50ff9ebd68e30c059@feld.me> X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: zfs i/o hangs on 9-PRERELEASE 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, 28 Nov 2011 07:48:34 -0000 On 28.11.2011 3:21, Mark Felder wrote: > After many hours of testing, reproducing, and testing again I've > finally been able to narrow down what the real issue is and it's not > ZFS as I suspected. After completely turning off all NFS functionality > and serving my files over Samba I haven't had a single issue. It seems > there is something going on with the new NFS code (I serve out over > v4, but reproduced it last week with v3) and my media player box, a > Popcorn Hour A-200 which is running Linux. If I can cobble some > hardware together and place it between so I can do some tcpdumps I > will provide that data so perhaps someone can understand what's going > on. If this is due to a badly behaving client this is potentially a > DoS on the server. > > > Regards, > > > > Mark Hi Mark, as to the output you have posted this seems to be a pf problem. Could you try the same situation with with pf(4) disabled? If you are not able to reproduce this hang with pf(4) disabled, it would be very nice to have a PR submitted. -- Martin Matuska FreeBSD committer http://blog.vx.sk From owner-freebsd-current@FreeBSD.ORG Mon Nov 28 08:27:20 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0041D106566B for ; Mon, 28 Nov 2011 08:27:19 +0000 (UTC) (envelope-from milu@dat.pl) Received: from jab.dat.pl (dat.pl [80.51.155.34]) by mx1.freebsd.org (Postfix) with ESMTP id B0D428FC1E for ; Mon, 28 Nov 2011 08:27:19 +0000 (UTC) Received: from jab.dat.pl (jsrv.dat.pl [127.0.0.1]) by jab.dat.pl (Postfix) with ESMTP id E15DDC5; Mon, 28 Nov 2011 09:27:16 +0100 (CET) X-Virus-Scanned: amavisd-new at dat.pl Received: from jab.dat.pl ([127.0.0.1]) by jab.dat.pl (jab.dat.pl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id iTWP89fQxrYv; Mon, 28 Nov 2011 09:27:11 +0100 (CET) Received: from snifi.localnet (unknown [212.69.68.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jab.dat.pl (Postfix) with ESMTPSA id ED7FF63; Mon, 28 Nov 2011 09:27:10 +0100 (CET) From: Maciej Milewski To: freebsd-current@freebsd.org Date: Mon, 28 Nov 2011 09:27:38 +0100 Message-ID: <1389353.3cq8XXOFZN@snifi> User-Agent: KMail/4.7.3 (Linux/3.1.1-1-ARCH; KDE/4.7.3; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: ZaRiuS KRiNG Subject: Re: Problem compiling libs after pass to 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, 28 Nov 2011 08:27:20 -0000 Dnia niedziela, 27 listopada 2011 19:59:44 ZaRiuS KRiNG pisze: > Hi! is my first post here and have a little problem try to google some and > don't find any of value. > > A week ago compile the src of current, and after that in any new port i > install, if compile before any lib, don't work, i need to install pkg from > repository of that lib and continue compiling the program, and work fine. > Just have this problem with the libs > > Any solution? Have you updated you ports tree? Maybe you are affected by the issue mentioned in ports/UPDATING: 20110928: AFFECTS: users of 10-current AUTHOR: eadler@FreeBSD.org There are known issues installing ports on FreeBSD 10+ due to bogus assumptions by various build scripts. This will not be fixed until 9-RELEASE is released. There are two workarounds: 1) Set UNAME_r=9.9-CURRENT in your environment 2) Set REVISION="9.9" in ${SRCDIR}/sys/conf/newvers.sh -- Maciek From owner-freebsd-current@FreeBSD.ORG Mon Nov 28 09:15:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4F58106583D; Mon, 28 Nov 2011 09:15:29 +0000 (UTC) (envelope-from mueller6727@bellsouth.net) Received: from fmailhost01.isp.att.net (fmailhost01.isp.att.net [204.127.217.101]) by mx1.freebsd.org (Postfix) with ESMTP id 9B2078FC1C; Mon, 28 Nov 2011 09:15:29 +0000 (UTC) Date: Mon, 28 Nov 2011 09:15:28 +0000 (GMT) X-Comment: Sending client does not conform to RFC822 minimum requirements X-Comment: Date has been added by Maillennium Received: from localhost (adsl-68-210-130-165.sdf.bellsouth.net[68.210.130.165]) by isp.att.net (frfwmhc01) with SMTP id <20111128091528H0100gd60ne>; Mon, 28 Nov 2011 09:15:28 +0000 X-Originating-IP: [68.210.130.165] From: "Thomas Mueller" To: freebsd-questions@FreeBSD.org References: <44ehwt5r9g.fsf@lowell-desk.lan> Message-Id: <20111128091529.B4F58106583D@hub.freebsd.org> Cc: mav@freebsd.org, freebsd-current@freebsd.org, Lowell Gilbert , "b. f." Subject: Re: "options atapicam" and/or "device ATA_CAM" in kernel config? 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, 28 Nov 2011 09:15:29 -0000 > On 11/27/11, Lowell Gilbert wrote: > > "b. f." writes: > >>> > > What is the role of "options atapicam" and "device ATA_CAM" in kernel > >>> > > config file? > >>> > > Are they redundant? Kernel will build with both these options, but > >>> > > will it make things go awry? Is ATA_CAM deprecated? > >> They are redundant and incompatible. atapicam is deprecated, and > >> ATA_CAM is the new default on FreeBSD 9 and 10. Unless you have some > >> special requirements, you should use ATA_CAM on recent versions of > >> FreeBSD, because it usually performs better than the old ATA code, and > >> has added functionality. > > Ah. My apologies to anyone I confused with my incorrect comments. > > I must say that I'm thoroughly disappointed that my searches through the > > official documentation didn't turn up anything related to this. Even the > > Handbook, with extensive practical descriptions of how to use this > > functionality, doesn't mention that its advice is irrelevant to anything > > past 8.x. > The handbook does contain some oblique and scattered references to the > new code, or at least to constructs that are common to both the old > and the new code, but the addition of a brief discussion of the > differences between the new and old ATA code in the handbook -- i.e., > the kernel and userland components that are now obsolete, and their > replacements -- might be of some help to users. The primary author of > the new code did add some material to various notes and manpages, but > he has been very busy writing and debugging code, and English is not > his first language, so others will have to supplement his efforts. > Perhaps you could ask for some additions on the freebsd-doc mailing > list? > b. Now I see it's "options ATA_CAM" or "device atapicam". It looks like I inadvertently transposed "device" and "options" in subject line. Now I think I'll try to rebuild the kernel with "options ATA_CAM" and drop "device atapicam". This question needs to be better resolved in time for FreeBSD 9.0-RELEASE. I cross-post this message to freebsd-current@freebsd.org so the developers will see it. FreeBSD users want to be able to burn CDs and DVDs, and since SCSI hardware has fallen out of style, I can say very few if any FreeBSD 9.0 users will have an actual SCSI CD or DVD drive. Tom From owner-freebsd-current@FreeBSD.ORG Mon Nov 28 09:20:23 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70AA8106566B for ; Mon, 28 Nov 2011 09:20:23 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BD3778FC13 for ; Mon, 28 Nov 2011 09:20:22 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA29046; Mon, 28 Nov 2011 11:20:20 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RUxNr-000NLg-SH; Mon, 28 Nov 2011 11:20:19 +0200 Message-ID: <4ED35253.9030101@FreeBSD.org> Date: Mon, 28 Nov 2011 11:20:19 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Ryan Stone References: <4ED2CAFF.7070608@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD current Subject: Re: array index of '-16' indexes before the beginning of the array 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, 28 Nov 2011 09:20:23 -0000 on 28/11/2011 02:59 Ryan Stone said the following: > On Sun, Nov 27, 2011 at 6:42 PM, Andriy Gapon wrote: >> >> Looks like clang has found a real issue here: >> /usr/src/sys/x86/x86/local_apic.c:311:2: warning: array index of '-16' indexes >> before the beginning of the array [-Warray-bounds] >> lapics[apic_id].la_ioint_irqs[IDT_DTRACE_RET - APIC_IO_INTS] = >> IRQ_DTRACE_RET; > > Hm, so as far as I can tell the DTrace-related code in local_apic.c is > bogus. DTrace's interrupt vectors are 32 and 33, which aren't I/O > vectors, so local_apic.c shouldn't need to know anything about them. > I think that the right fix is to remove all of it from local_apic.c. I think that those vectors fall into a range designated for PIC interrupts. sys/i386/include/apicvar.h has a nice illustration. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Nov 28 11:05:01 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C5F1106566B for ; Mon, 28 Nov 2011 11:05:01 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 041BB8FC14 for ; Mon, 28 Nov 2011 11:05:00 +0000 (UTC) Received: by ggnk5 with SMTP id k5so7259250ggn.13 for ; Mon, 28 Nov 2011 03:05:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.45.6 with SMTP id i6mr12226127obm.3.1322476700056; Mon, 28 Nov 2011 02:38:20 -0800 (PST) Received: by 10.182.76.225 with HTTP; Mon, 28 Nov 2011 02:38:20 -0800 (PST) X-Originating-IP: [93.92.220.178] Date: Mon, 28 Nov 2011 17:38:20 +0700 Message-ID: From: Max Khon To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: WITHOUT_PROFILE=yes by default 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, 28 Nov 2011 11:05:01 -0000 Hello! Are there any compelling reasons for having profiled libs to be built by default? They are of no use for 100% users and 99,999% developers and just slow down world and universe builds. Here are the results of running buildworld on 1 core on AMD Athlon(tm) 64 X2 Dual Core Processor 4400+: make buildworld 8265,06 real 6400,27 user 1059,2 sys make buildworld (WITHOUT_PROFILE=yes) 7840,05 real 5379,13 user 904,61 sys I would like to disable building profiled libraries by default. Opinions? Max From owner-freebsd-current@FreeBSD.ORG Mon Nov 28 12:17:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70F59106564A; Mon, 28 Nov 2011 12:17:13 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id ACB118FC0A; Mon, 28 Nov 2011 12:17:12 +0000 (UTC) Received: by eaai12 with SMTP id i12so2634724eaa.13 for ; Mon, 28 Nov 2011 04:17:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=WFYGaYYkA2Sk1mZvTJ0XjoZhfXk8tphGoPCQGZbd6Ng=; b=qQsFxSQdyFxCWEIywzhnROcT8bwjRkQNanDJDWyI+zNwZIhd8PIW7bVFv9ni7w6q59 Mq91Xh+3tJYcZm6LE+9G9Y0TXdi78uV1WOmJZcRX9KGI5VyoMDLu6AiB8rlLD+G4/NpJ GEJG/Q/iCrdkTjzKpI0an+GLn07ossSnFmimE= MIME-Version: 1.0 Received: by 10.180.91.137 with SMTP id ce9mr34427944wib.5.1322482631598; Mon, 28 Nov 2011 04:17:11 -0800 (PST) Received: by 10.180.94.131 with HTTP; Mon, 28 Nov 2011 04:17:11 -0800 (PST) In-Reply-To: <4ed35131.661d440a.70d7.ffffa053SMTPIN_ADDED@mx.google.com> References: <44ehwt5r9g.fsf@lowell-desk.lan> <4ed35131.661d440a.70d7.ffffa053SMTPIN_ADDED@mx.google.com> Date: Mon, 28 Nov 2011 12:17:11 +0000 Message-ID: From: "b. f." To: Thomas Mueller Content-Type: text/plain; charset=ISO-8859-1 Cc: mav@freebsd.org, freebsd-current@freebsd.org, Lowell Gilbert , freebsd-questions@freebsd.org Subject: Re: "options atapicam" and/or "device ATA_CAM" in kernel config? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 12:17:13 -0000 > Now I think I'll try to rebuild the kernel with "options ATA_CAM" and drop > "device atapicam". > > This question needs to be better resolved in time for FreeBSD 9.0-RELEASE. > > I cross-post this message to freebsd-current@freebsd.org so the developers > will see it. FreeBSD users want to be able to burn CDs and DVDs, and since > SCSI hardware has fallen out of style, I can say very few if any FreeBSD 9.0 > users will have an actual SCSI CD or DVD drive. The new CAM(4) is not just for SCSI devices (and SCSI, as it is usually used now, does not deal only with the old parallel SCSI devices). Despite the fact that most CD and DVD drives will now appear as cdX devices, and cd(4) is full of references to SCSI, most CD and DVD drives should be supported. And while burncd(8) will not work with the new interface, other software in ports should -- for example, sysutils/cdrtools and sysutils/cdrtools-devel, as was mentioned before. b. From owner-freebsd-current@FreeBSD.ORG Mon Nov 28 12:24:12 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C658106566B for ; Mon, 28 Nov 2011 12:24:12 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id E86578FC16 for ; Mon, 28 Nov 2011 12:24:11 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RV0Fn-0004kt-10 for freebsd-current@freebsd.org; Mon, 28 Nov 2011 13:24:11 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 28 Nov 2011 13:24:11 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 28 Nov 2011 13:24:11 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Mon, 28 Nov 2011 13:23:58 +0100 Lines: 24 Message-ID: References: <201111240126.21470.Mark.Martinec+freebsd@ijs.si> <201111240225.48154.Mark.Martinec+freebsd@ijs.si> <201111241806.32212.Mark.Martinec+freebsd@ijs.si> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111116 Thunderbird/8.0 In-Reply-To: <201111241806.32212.Mark.Martinec+freebsd@ijs.si> Subject: Re: iSCSI initiator: iscontrol cannot be stopped or killed 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, 28 Nov 2011 12:24:12 -0000 On 24/11/2011 18:06, Mark Martinec wrote: >>> If you can get it back into this state, >> >> Sure, *every* time. >> >>> a procstat -k -k would be very helpful. >>> (the second -k is not a typo). >> >> # procstat -k -k 5896 >> PID TID COMM TDNAME KSTACK >> 5896 102364 iscontrol - mi_switch+0x174 >> sleepq_timedwait+0x42 _sleep+0x301 ic_init+0x2f1 iscsi_ioctl+0x525 >> devfs_ioctl_f+0x7b kern_ioctl+0x115 sys_ioctl+0xfd amd64_syscall+0x450 >> Xfast_syscall+0xf7 > > Additional info: the process is blocking on 'ffp', unresponsive to signals: > > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND > 0 5896 1 0 20 0 16424 1264 ffp Ds ?? 0:00.04 iscontrol -c /etc/iscsi.conf -n xxx > You should probably ask at the freebsd-scsi@ mailing list. From looking at the code it looks like "ffp" is used for LUN scan timeout. From owner-freebsd-current@FreeBSD.ORG Mon Nov 28 14:19:28 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2C52106566C; Mon, 28 Nov 2011 14:19:28 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 9553F8FC0C; Mon, 28 Nov 2011 14:19:28 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id D80C13AF; Sat, 26 Nov 2011 11:49:47 +0100 (CET) Date: Sat, 26 Nov 2011 11:48:41 +0100 From: Pawel Jakub Dawidek To: Mark Felder Message-ID: <20111126104840.GA8794@garage.freebsd.pl> References: <95d00c1b714837aa32e7da72bc4afd03@feld.me> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline In-Reply-To: <95d00c1b714837aa32e7da72bc4afd03@feld.me> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: zfs i/o hangs on 9-PRERELEASE 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, 28 Nov 2011 14:19:29 -0000 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 25, 2011 at 01:20:01PM -0600, Mark Felder wrote: > 13:14:32 nas:~ > uname -a > FreeBSD nas.feld.me 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #3 r227971M:=20 > Fri Nov 25 10:07:48 CST 2011 =20 > root@nas.feld.me:/usr/obj/tank/svn/sys/GENERIC amd64 >=20 > This seemed to start happening sometime after RC1. I tried 8-STABLE and= =20 > it's happening there too right now. I think whatever caused this was=20 > MFC'd. I've also reproduced this on completely different hardware=20 > running a single disk ZFS pool. >=20 >=20 > I'm getting this output in dmesg after these hangs I keep seeing. Mark, those backtrace are not related to ZFS, but to PF. Not sure if they are at all related to your hangs. Most cases where ZFS I/O seems to hang are hardware problems, where I/O requests are not completed. 'procstat -kk -a' output might be useful once the hang happens. > uma_zalloc_arg: zone "pfrktable" with the following non-sleepable locks= =20 > held: > exclusive sleep mutex pf task mtx (pf task mtx) r =3D 0=20 > (0xffffffff8199af20) locked @=20 > /tank/svn/sys/modules/pf/../../contrib/pf/net/pf_ioctl.c:1589 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > kdb_backtrace() at kdb_backtrace+0x37 > _witness_debugger() at _witness_debugger+0x2e > witness_warn() at witness_warn+0x2c4 > uma_zalloc_arg() at uma_zalloc_arg+0x335 > pfr_create_ktable() at pfr_create_ktable+0xd8 > pfr_ina_define() at pfr_ina_define+0x12b > pfioctl() at pfioctl+0x1c5a > devfs_ioctl_f() at devfs_ioctl_f+0x7a > kern_ioctl() at kern_ioctl+0xcd > sys_ioctl() at sys_ioctl+0xfd > amd64_syscall() at amd64_syscall+0x3ac > Xfast_syscall() at Xfast_syscall+0xf7 > --- syscall (54, FreeBSD ELF64, sys_ioctl), rip =3D 0x800da711c, rsp =3D= =20 > 0x7fffffff9d28, rbp =3D 0x7fffffffa1f0 --- --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --ikeVEW9yuYc//A+q Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk7QxAgACgkQForvXbEpPzR0VgCfR/mF7sxZOaNYoHcsvOIDTljh Re0AnR9RoDZr4yLmuwSqGrEaaLDu4B1E =pCIh -----END PGP SIGNATURE----- --ikeVEW9yuYc//A+q-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 28 14:36:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31A39106566B for ; Mon, 28 Nov 2011 14:36:43 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id AF9A28FC1E for ; Mon, 28 Nov 2011 14:36:42 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id A35CF2A28CC8; Mon, 28 Nov 2011 15:36:41 +0100 (CET) Date: Mon, 28 Nov 2011 15:36:41 +0100 From: Ed Schouten To: Jason Edwards Message-ID: <20111128143641.GJ39031@hoeg.nl> References: <5D3FFA12-BB54-4297-A098-3B85951ECEC5@lassitu.de> <3A9E50F5-03D3-4DD5-A95D-5948D4705462@lassitu.de> <20111123181133.GD1979@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u3bvv0EcKsvvYeex" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, Stefan Bethke Subject: Re: ee (easy editor) bugged on 9.0? 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, 28 Nov 2011 14:36:43 -0000 --u3bvv0EcKsvvYeex Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Jason, * Jason Edwards , 20111127 22:15: > Thanks for the impressive list of advantages! There's just one > non-critical issue I'd like to address regarding the use of xterm > terminal type. >=20 > When using cons25 terminal, the dialog menus (drawn using > devel/cdialog and `make config` in portstree as well) are using smooth > lines to draw boxes and stuff. >=20 > But when using xterm terminal, those lines are replaced by 'dashed' > lines like - - - - - instead of a smooth line without whitespace in > between. When doing the same via SSH login, the lines are smooth with > xterm type. So this issue appear to be limited to the console in > combination with xterm terminal type. >=20 > Is there a way to use xterm but still allow cdialog to draw smooth > lines on the console? Unfortunately, this is actually a workaround for a problem that existed all along, even before we switched to TERM=3Dxterm. It's not beautiful, but needed. When using TERM=3Dcons25, ncurses applications simply print certain bytes to do the box drawing, namely these ones: http://en.wikipedia.org/wiki/Code_page_437#Standard_code_page This means that if you load a different font file into the console driver that uses a different character set (e.g. ISO-8859-1), you get all sorts of math characters and diacritics instead of the box drawing characters. With TERM=3Dxterm, this is essentially solved, because box drawing can be performed using character set independent escape sequences (using ^N and ^O), but the problem is that syscons does not know which glyphs in the font file correspond with the box drawing characters. There are two ways to solve this: - Extend the font file format to include a mapping table of box drawing characters to glyph indices, - Patch syscons to just print +-| instead of the box drawing characters. The first option would fix it properly, but in my opinion it's not worth the effort, because time should be spent to just get Unicode working. The terminal emulator already supports Unicode internally and even remaps box drawing characters to Unicode. Get Unicode working and you fix the box drawing issue for free. This is why I have chosen the second option. If you really miss the box drawing characters, you can revert SVN revision 203659. Do keep in mind that it effectively breaks support for custom fonts/character sets. I think box drawing does work when you compile your kernel with TEKEN_UTF8 (poor mans UTF-8 support), but please don't attempt to load any fonts then. Best regards, --=20 Ed Schouten WWW: http://80386.nl/ --u3bvv0EcKsvvYeex Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJO05x5AAoJEG5e2P40kaK7aO4P/18ZPoVlcwSF28Ks/xQrGTPp 6cmeY6wwP5eQxKQ3Zyi5V30go34T5bTa0Hr53dTL2eIv+L9DiXEAxkGkuDfMJNmH hnAYZGB9SIx2tyiQEZaf2OAzV4dleQ7zSTEw1Fx92vqSUHMu4R+R9W1NtbHq2sod drZ6D1MnrfJ72FxyC3KhPKtZ2vMAkuXgGwYlakcM2nD9rPyL3geJu84Hi8erKE/r I1zuYil11OmHPTiVaAxLBnblesIpGh+kUhrWULDGxcoEZgKvpUCpa9g93W0h5611 SRhrKGvvBmA3Fzk2FqwFvCjinE59emcVSOIcY9zmeB84ZpL4czM+HpJi+T935iaG kubLOxGrJHaxJNbWFAOVB+rF5Ng8uj7J2nqo8ihtdr9W1B8qccLhg0xmp5NyHZ4p OBcgAV1bUVJkIxgmXvuIjsfi5o9uQkNeWwdo3itSmqJTLL8wbUJ5JYs6qVDlh/mz VoOrgPaW4r9u8ZWOok9b3IshXbFr9E+OApyZkDd540zUR4ZTd4nJDTBR6OkMrKDV sBvTBDps0QPpEfwHWRbW4zRuEnS1Qb6G2aJqjBIc3yl5vA8h333XsUbIJeYC0GzW fRZsTABv0bXczila3caOEro3IVChJmfjVFGDEMDfcW0AYRDgiPgEjixN1mUXYEFk PbwAvwg9HKILN0fIra7p =sF1Q -----END PGP SIGNATURE----- --u3bvv0EcKsvvYeex-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 28 14:39:27 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B6851065673; Mon, 28 Nov 2011 14:39:27 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 8FBAC8FC16; Mon, 28 Nov 2011 14:39:26 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAPOb006DaFvO/2dsb2JhbAA7CIUDpwCBcgEBBSMyJBsYAgINGQJZBhOtGpFXgTCCL4NSghuBFgSIIYwpkik X-IronPort-AV: E=Sophos;i="4.69,584,1315195200"; d="scan'208";a="147318916" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 28 Nov 2011 09:39:25 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 66ED0B406C; Mon, 28 Nov 2011 09:39:25 -0500 (EST) Date: Mon, 28 Nov 2011 09:39:25 -0500 (EST) From: Rick Macklem To: Pawel Jakub Dawidek Message-ID: <2111049507.479178.1322491165407.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20111126104840.GA8794@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org, Mark Felder , freebsd-current@freebsd.org Subject: Re: zfs i/o hangs on 9-PRERELEASE 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, 28 Nov 2011 14:39:27 -0000 Pawel Jakub Dawidek wrote: > On Fri, Nov 25, 2011 at 01:20:01PM -0600, Mark Felder wrote: > > 13:14:32 nas:~ > uname -a > > FreeBSD nas.feld.me 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #3 > > r227971M: > > Fri Nov 25 10:07:48 CST 2011 > > root@nas.feld.me:/usr/obj/tank/svn/sys/GENERIC amd64 > > > > This seemed to start happening sometime after RC1. I tried 8-STABLE > > and > > it's happening there too right now. I think whatever caused this was > > MFC'd. I've also reproduced this on completely different hardware > > running a single disk ZFS pool. > > > > > > I'm getting this output in dmesg after these hangs I keep seeing. > > Mark, those backtrace are not related to ZFS, but to PF. Not sure if > they are at all related to your hangs. Most cases where ZFS I/O seems > to > hang are hardware problems, where I/O requests are not completed. > He recently posted that his hangs went away when he stopped using NFS. NFS does use uma_zalloc() and there are several places in pfioctl() where uma_zalloc(...M_WAITOK...) is called (hidden under pool_get()) when a mutex (the PF_LOCK() one) is held. I've emailed bz@ related to this. I'm also not sure if they could be related to his hangs, but it seems that if uma_zalloc() decides to sleep with the mutex held, something may break and a broken uma_zalloc() would impact NFS. rick > 'procstat -kk -a' output might be useful once the hang happens. > > > uma_zalloc_arg: zone "pfrktable" with the following non-sleepable > > locks > > held: > > exclusive sleep mutex pf task mtx (pf task mtx) r = 0 > > (0xffffffff8199af20) locked @ > > /tank/svn/sys/modules/pf/../../contrib/pf/net/pf_ioctl.c:1589 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > kdb_backtrace() at kdb_backtrace+0x37 > > _witness_debugger() at _witness_debugger+0x2e > > witness_warn() at witness_warn+0x2c4 > > uma_zalloc_arg() at uma_zalloc_arg+0x335 > > pfr_create_ktable() at pfr_create_ktable+0xd8 > > pfr_ina_define() at pfr_ina_define+0x12b > > pfioctl() at pfioctl+0x1c5a > > devfs_ioctl_f() at devfs_ioctl_f+0x7a > > kern_ioctl() at kern_ioctl+0xcd > > sys_ioctl() at sys_ioctl+0xfd > > amd64_syscall() at amd64_syscall+0x3ac > > Xfast_syscall() at Xfast_syscall+0xf7 > > --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x800da711c, rsp = > > 0x7fffffff9d28, rbp = 0x7fffffffa1f0 --- > > -- > Pawel Jakub Dawidek http://www.wheelsystems.com > FreeBSD committer http://www.FreeBSD.org > Am I Evil? Yes, I Am! http://yomoli.com From owner-freebsd-current@FreeBSD.ORG Mon Nov 28 15:34:45 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB5F41065670; Mon, 28 Nov 2011 15:34:44 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9F0998FC0C; Mon, 28 Nov 2011 15:34:44 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pASFYht0091853; Mon, 28 Nov 2011 10:34:43 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pASFYhNK091839; Mon, 28 Nov 2011 15:34:43 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 28 Nov 2011 15:34:43 GMT Message-Id: <201111281534.pASFYhNK091839@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 15:34:45 -0000 TB --- 2011-11-28 13:40:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-28 13:40:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-11-28 13:40:00 - cleaning the object tree TB --- 2011-11-28 13:40:55 - cvsupping the source tree TB --- 2011-11-28 13:40:55 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-11-28 13:46:19 - building world TB --- 2011-11-28 13:46:19 - CROSS_BUILD_TESTING=YES TB --- 2011-11-28 13:46:19 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-28 13:46:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-28 13:46:19 - SRCCONF=/dev/null TB --- 2011-11-28 13:46:19 - TARGET=i386 TB --- 2011-11-28 13:46:19 - TARGET_ARCH=i386 TB --- 2011-11-28 13:46:19 - TZ=UTC TB --- 2011-11-28 13:46:19 - __MAKE_CONF=/dev/null TB --- 2011-11-28 13:46:19 - cd /src TB --- 2011-11-28 13:46:19 - /usr/bin/make -B buildworld >>> World build started on Mon Nov 28 13:46:19 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] c++ -O2 -pipe -fstack-protector -Wsystem-headers -Werror -I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc c++ -O2 -pipe -fstack-protector -Wsystem-headers -Werror -I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/version.cc c++ -O2 -pipe -fstack-protector -Wsystem-headers -Werror -I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c /src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/getline.cc c++ -O2 -pipe -fstack-protector -Wsystem-headers -Werror -I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c /src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/hash.cc c++ -O2 -pipe -fstack-protector -Wsystem-headers -Werror -I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -o gperf bool-array.o hash-table.o input.o keyword-list.o keyword.o main.o options.o output.o positions.o search.o version.o getline.o hash.o gzip -cn /src/gnu/usr.bin/gperf/../../../contrib/gperf/doc/gperf.1 > gperf.1.gz ===> gnu/usr.bin/gperf/doc (all) make: don't know how to make gperf.info. Stop *** Error code 2 Stop in /src/gnu/usr.bin/gperf. *** Error code 1 Stop in /src/gnu/usr.bin. *** Error code 1 Stop in /src/gnu. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-28 15:34:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-28 15:34:42 - ERROR: failed to build world TB --- 2011-11-28 15:34:43 - 5301.79 user 861.04 system 6882.46 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Mon Nov 28 16:25:38 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56D411065676; Mon, 28 Nov 2011 16:25:38 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 125908FC13; Mon, 28 Nov 2011 16:25:37 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pASGPb08045879; Mon, 28 Nov 2011 11:25:37 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pASGPbsK045862; Mon, 28 Nov 2011 16:25:37 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 28 Nov 2011 16:25:37 GMT Message-Id: <201111281625.pASGPbsK045862@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 16:25:38 -0000 TB --- 2011-11-28 15:42:45 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-28 15:42:45 - starting HEAD tinderbox run for mips/mips TB --- 2011-11-28 15:42:45 - cleaning the object tree TB --- 2011-11-28 15:42:55 - cvsupping the source tree TB --- 2011-11-28 15:42:55 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2011-11-28 15:43:17 - building world TB --- 2011-11-28 15:43:17 - CROSS_BUILD_TESTING=YES TB --- 2011-11-28 15:43:17 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-28 15:43:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-28 15:43:17 - SRCCONF=/dev/null TB --- 2011-11-28 15:43:17 - TARGET=mips TB --- 2011-11-28 15:43:17 - TARGET_ARCH=mips TB --- 2011-11-28 15:43:17 - TZ=UTC TB --- 2011-11-28 15:43:17 - __MAKE_CONF=/dev/null TB --- 2011-11-28 15:43:17 - cd /src TB --- 2011-11-28 15:43:17 - /usr/bin/make -B buildworld >>> World build started on Mon Nov 28 15:43:18 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] c++ -O -pipe -G0 -Wsystem-headers -Werror -I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc c++ -O -pipe -G0 -Wsystem-headers -Werror -I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/version.cc c++ -O -pipe -G0 -Wsystem-headers -Werror -I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c /src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/getline.cc c++ -O -pipe -G0 -Wsystem-headers -Werror -I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c /src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/hash.cc c++ -O -pipe -G0 -Wsystem-headers -Werror -I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -o gperf bool-array.o hash-table.o input.o keyword-list.o keyword.o main.o options.o output.o positions.o search.o version.o getline.o hash.o gzip -cn /src/gnu/usr.bin/gperf/../../../contrib/gperf/doc/gperf.1 > gperf.1.gz ===> gnu/usr.bin/gperf/doc (all) make: don't know how to make gperf.info. Stop *** Error code 2 Stop in /src/gnu/usr.bin/gperf. *** Error code 1 Stop in /src/gnu/usr.bin. *** Error code 1 Stop in /src/gnu. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-28 16:25:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-28 16:25:36 - ERROR: failed to build world TB --- 2011-11-28 16:25:36 - 1792.92 user 525.52 system 2571.67 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Mon Nov 28 16:32:25 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F7D0106564A; Mon, 28 Nov 2011 16:32:25 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 32DBD8FC1B; Mon, 28 Nov 2011 16:32:24 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pASGWOBF091628; Mon, 28 Nov 2011 11:32:24 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pASGWOx6091623; Mon, 28 Nov 2011 16:32:24 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 28 Nov 2011 16:32:24 GMT Message-Id: <201111281632.pASGWOx6091623@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 16:32:25 -0000 TB --- 2011-11-28 15:34:43 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-28 15:34:43 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-11-28 15:34:43 - cleaning the object tree TB --- 2011-11-28 15:35:01 - cvsupping the source tree TB --- 2011-11-28 15:35:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-11-28 15:35:22 - building world TB --- 2011-11-28 15:35:22 - CROSS_BUILD_TESTING=YES TB --- 2011-11-28 15:35:22 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-28 15:35:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-28 15:35:22 - SRCCONF=/dev/null TB --- 2011-11-28 15:35:22 - TARGET=ia64 TB --- 2011-11-28 15:35:22 - TARGET_ARCH=ia64 TB --- 2011-11-28 15:35:22 - TZ=UTC TB --- 2011-11-28 15:35:22 - __MAKE_CONF=/dev/null TB --- 2011-11-28 15:35:22 - cd /src TB --- 2011-11-28 15:35:22 - /usr/bin/make -B buildworld >>> World build started on Mon Nov 28 15:35:23 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] c++ -O2 -pipe -Wsystem-headers -Werror -I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc c++ -O2 -pipe -Wsystem-headers -Werror -I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/version.cc c++ -O2 -pipe -Wsystem-headers -Werror -I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c /src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/getline.cc c++ -O2 -pipe -Wsystem-headers -Werror -I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c /src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/hash.cc c++ -O2 -pipe -Wsystem-headers -Werror -I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -o gperf bool-array.o hash-table.o input.o keyword-list.o keyword.o main.o options.o output.o positions.o search.o version.o getline.o hash.o gzip -cn /src/gnu/usr.bin/gperf/../../../contrib/gperf/doc/gperf.1 > gperf.1.gz ===> gnu/usr.bin/gperf/doc (all) make: don't know how to make gperf.info. Stop *** Error code 2 Stop in /src/gnu/usr.bin/gperf. *** Error code 1 Stop in /src/gnu/usr.bin. *** Error code 1 Stop in /src/gnu. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-28 16:32:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-28 16:32:24 - ERROR: failed to build world TB --- 2011-11-28 16:32:24 - 2658.14 user 590.20 system 3460.15 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Mon Nov 28 17:55:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAB651065672 for ; Mon, 28 Nov 2011 17:55:05 +0000 (UTC) (envelope-from zklist@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 60EE98FC14 for ; Mon, 28 Nov 2011 17:55:05 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so10905423bkb.13 for ; Mon, 28 Nov 2011 09:55:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=yR1DNO3gS+BVbH/k8PGAMbQ5sgH8wjne5x4r7wq8HbI=; b=XNsFxPU9P06BV6qY7dqgI54bR1GM6xjK7UnTzTM9yAnqpdY4ZGWfXYYTJge5+ZESqU S5vtL9fbMOauaWbmclKpmmdPk38Qc67ZRhRZ2om/77OfXCexSdVeQABGELoeJ4leeu1M /LzrgfheCqAdxl2Ko3T7mPjnX14HtahL1l1tQ= MIME-Version: 1.0 Received: by 10.204.156.218 with SMTP id y26mr45715585bkw.103.1322502904180; Mon, 28 Nov 2011 09:55:04 -0800 (PST) Received: by 10.204.201.142 with HTTP; Mon, 28 Nov 2011 09:55:04 -0800 (PST) In-Reply-To: <1389353.3cq8XXOFZN@snifi> References: <1389353.3cq8XXOFZN@snifi> Date: Mon, 28 Nov 2011 18:55:04 +0100 Message-ID: From: ZaRiuS KRiNG To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Problem compiling libs after pass to 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, 28 Nov 2011 17:55:06 -0000 Ok, the second know how make, but the first no. How can set new uname -r in the environment? Sorry but in some things need a lot of experience, and for that try use current About what programs got the fail? Chromium and Abiword, with one, 2-3 with second just one. But make that, pkg_add -r and continue with compiling but want learn how solve the problem no, just evade it Thanks for all 2011/11/28 Maciej Milewski > Dnia niedziela, 27 listopada 2011 19:59:44 ZaRiuS KRiNG pisze: > > Hi! is my first post here and have a little problem try to google some > and > > don't find any of value. > > > > A week ago compile the src of current, and after that in any new port i > > install, if compile before any lib, don't work, i need to install pkg > from > > repository of that lib and continue compiling the program, and work fine. > > Just have this problem with the libs > > > > Any solution? > Have you updated you ports tree? Maybe you are affected by the issue > mentioned > in ports/UPDATING: > > 20110928: > AFFECTS: users of 10-current > AUTHOR: eadler@FreeBSD.org > > There are known issues installing ports on FreeBSD 10+ due to > bogus assumptions by various build scripts. This will not be fixed > until 9-RELEASE is released. > > There are two workarounds: > > 1) Set UNAME_r=9.9-CURRENT in your environment > 2) Set REVISION="9.9" in ${SRCDIR}/sys/conf/newvers.sh > > -- > Maciek > From owner-freebsd-current@FreeBSD.ORG Mon Nov 28 18:11:09 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEA30106566B for ; Mon, 28 Nov 2011 18:11:09 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 9492C8FC25 for ; Mon, 28 Nov 2011 18:11:09 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1RV5fY-00004t-HK>; Mon, 28 Nov 2011 19:11:08 +0100 Received: from e178031184.adsl.alicedsl.de ([85.178.31.184] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RV5fY-00053k-Cc>; Mon, 28 Nov 2011 19:11:08 +0100 Message-ID: <4ED3CEB8.6090409@zedat.fu-berlin.de> Date: Mon, 28 Nov 2011 19:11:04 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: Garrett Cooper References: <4ED26CE9.3020107@zedat.fu-berlin.de> In-Reply-To: X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig30CAF470E69873B28EEC3DC9" X-Originating-IP: 85.178.31.184 Cc: Current FreeBSD Subject: Re: Building FreeBSD 10.0-CURRENT/amd64 of today fails (with clang and WITH_LIBCPLUSPLUS=YES) 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, 28 Nov 2011 18:11:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig30CAF470E69873B28EEC3DC9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 11/27/11 22:05, schrieb Garrett Cooper: > On Sun, Nov 27, 2011 at 9:01 AM, O. Hartmann > wrote: >> Sources of FreeBSD 10.0-CUR/amd64 as svn-ed recently: >> >> Path: . >> Working Copy Root Path: /usr/src >> URL: svn://svn.freebsd.org/base/head >> Repository Root: svn://svn.freebsd.org/base >> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >> Revision: 228029 >> Node Kind: directory >> Schedule: normal >> Last Changed Author: trociny >> Last Changed Rev: 228029 >> Last Changed Date: 2011-11-27 17:56:01 +0100 (Sun, 27 Nov 2011) >> >> fail to build with the following error: >=20 > Look for the first "Error code" in your output -- the line before that > is the real error. That being said, there were some additional CFLAGS > that needed to be fed in to make things work with libc++ and libcxxrt > IIRC. > Cheers, > -Garrett =2E.. thanks for the advice. Is there any chance to find out which Flags one has to set (the WIKI seems not to mention anything)? Regards, Oliver --------------enig30CAF470E69873B28EEC3DC9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO0864AAoJEOgBcD7A/5N8NgQH/3z3Py0w+pr8yf17GAdRwck3 0A1QrUqi99CVjnOfvWG0nHrM3OASeJwUA9r8KyGfpv9YwFUKmjP/zTThJkMKVYZo Q/w4T6aXmtYr7ttV4AzDTqwYYi5U5RinTp38TUP0MnG8BmmmLU45y+44dv0UbM0z aeJfpmJWC1NLXGlb8a3QCPEQa8uHpASbKgzUCEqZOwvddZJPelAKaTdh0TFIGdyC 1molohQenAy49PQsS+i+GaE7pNdGQAUkKi15br6Y0ySrtoZcByFUlwhopIuG2mD/ MYDWR1yNEXTXgt2GypqaZkovgFSwv8NUtPsIUbL6TvqiaFrVa+kiCyt0iiawF8A= =K/Dg -----END PGP SIGNATURE----- --------------enig30CAF470E69873B28EEC3DC9-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 28 18:11:47 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11B0E106566B for ; Mon, 28 Nov 2011 18:11:47 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by mx1.freebsd.org (Postfix) with ESMTP id EE9AF8FC1A for ; Mon, 28 Nov 2011 18:11:46 +0000 (UTC) Received: from [127.0.0.1] (proxy7.corp.yahoo.com [216.145.48.98]) by mrout3.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id pASIBHHt054807; Mon, 28 Nov 2011 10:11:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1322503877; bh=Dy/qYgO36aXz9vkvb6Ws/jmznSAshaQkHeOPZVSvHzE=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=eeFxRmHDa2kcZfiweqZthlzRzC9fmWFGSrOc5YNuXSIIE9wV4XS/9TtuzNU866no1 JPhJvXCFS/kOsz3Ie5dPtqIVIFdOIBfwjPFoLtdWxbwNm56HLdFkWHfv0dXj3o75Ys +3EdQWvHwGZGZSTw5L96ZbE7dfRl1FX5+L9SNVUI= From: Sean Bruno To: Rick Macklem In-Reply-To: <1555980227.268467.1322090807813.JavaMail.root@erie.cs.uoguelph.ca> References: <1555980227.268467.1322090807813.JavaMail.root@erie.cs.uoguelph.ca> Content-Type: text/plain; charset="UTF-8" Date: Mon, 28 Nov 2011 10:11:17 -0800 Message-ID: <1322503877.3363.2.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: NFS + SVN problem? 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, 28 Nov 2011 18:11:47 -0000 > Oh, and don't hesitate to try NFSv4. It should do the locking correctly without > needing "nolockd" and the more testing it gets, the better.;-) > > rick > > > Removing soft,intr had no effect. This, I suspect will be problematic > > for clusteradm@ if we start updating hosts in the cluster. > > > > Sean Doesn't look like dumpster supports V4? [tcp] dumpster:/vol/volshscratch: NFSPROC_NULL: RPC: Program/version mismatch; low version = 2, high version = 3 mount_nfs: Cannot immediately mount dumpster:/vol/volshscratch, backgrounding From owner-freebsd-current@FreeBSD.ORG Mon Nov 28 19:06:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEDC1106566B for ; Mon, 28 Nov 2011 19:06:08 +0000 (UTC) (envelope-from milu@dat.pl) Received: from jab.dat.pl (dat.pl [80.51.155.34]) by mx1.freebsd.org (Postfix) with ESMTP id 77C4B8FC08 for ; Mon, 28 Nov 2011 19:06:08 +0000 (UTC) Received: from jab.dat.pl (jsrv.dat.pl [127.0.0.1]) by jab.dat.pl (Postfix) with ESMTP id 29287A2; Mon, 28 Nov 2011 20:06:07 +0100 (CET) X-Virus-Scanned: amavisd-new at dat.pl Received: from jab.dat.pl ([127.0.0.1]) by jab.dat.pl (jab.dat.pl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HLB8KEcIZfNI; Mon, 28 Nov 2011 20:06:02 +0100 (CET) Received: from snifi.localnet (178-36-12-88.adsl.inetia.pl [178.36.12.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jab.dat.pl (Postfix) with ESMTPSA id DE73A48; Mon, 28 Nov 2011 20:06:01 +0100 (CET) From: Maciej Milewski To: freebsd-current@freebsd.org Date: Mon, 28 Nov 2011 20:06:34 +0100 Message-ID: <20665800.1Hzq6qOPq2@snifi> User-Agent: KMail/4.7.3 (Linux/3.1.1-1-ARCH; KDE/4.7.3; x86_64; ; ) In-Reply-To: References: <1389353.3cq8XXOFZN@snifi> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Cc: ZaRiuS KRiNG Subject: Re: Problem compiling libs after pass to 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, 28 Nov 2011 19:06:08 -0000 Dnia poniedzia=C5=82ek, 28 listopada 2011 18:55:04 ZaRiuS KRiNG pisze: > Ok, the second know how make, but the first no. >=20 > How can set new uname -r in the environment? Sorry but in some things= need > a lot of experience, and for that try use current >=20 > About what programs got the fail? Chromium and Abiword, with one, 2-3= with > second just one. But make that, pkg_add -r and continue with compilin= g but > want learn how solve the problem no, just evade it >=20 > Thanks for all First: don't top post! Second: you haven't answered the question if you have lately updated yo= ur=20 ports. As for setting uname please RTFM of uname, it's there. Problem is known to be because of bad comparison done by automake/autoc= onf=20 scripts. Maciek From owner-freebsd-current@FreeBSD.ORG Mon Nov 28 19:10:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FA17106566C for ; Mon, 28 Nov 2011 19:10:53 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-qw0-f47.google.com (mail-qw0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id DD4F38FC18 for ; Mon, 28 Nov 2011 19:10:52 +0000 (UTC) Received: by qaea17 with SMTP id a17so1537415qae.13 for ; Mon, 28 Nov 2011 11:10:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0dIjeRwBjvZYtoXgtKT1voYRSJKZhc7QOooNoDd54gQ=; b=WPFhtFsMeSJ8dftAyvlnHSnQAi7efWygvJEDL7fN6B/l4kOqhQ2U76AzkQ1Q8E+dkf mw+8U0p7NezlLhbsn+7e0bH+BU1hvIAyVHKgYigdkQD6tn88kdwczhSTUqhz4jfynBEU Far9cLMnjrAnm+l3jX29/oca+ZJSzCtbIkXNQ= MIME-Version: 1.0 Received: by 10.182.149.33 with SMTP id tx1mr4816479obb.62.1322507452089; Mon, 28 Nov 2011 11:10:52 -0800 (PST) Received: by 10.182.62.227 with HTTP; Mon, 28 Nov 2011 11:10:51 -0800 (PST) In-Reply-To: <4ED3CEB8.6090409@zedat.fu-berlin.de> References: <4ED26CE9.3020107@zedat.fu-berlin.de> <4ED3CEB8.6090409@zedat.fu-berlin.de> Date: Mon, 28 Nov 2011 11:10:51 -0800 Message-ID: From: Garrett Cooper To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Cc: Current FreeBSD Subject: Re: Building FreeBSD 10.0-CURRENT/amd64 of today fails (with clang and WITH_LIBCPLUSPLUS=YES) 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, 28 Nov 2011 19:10:53 -0000 On Mon, Nov 28, 2011 at 10:11 AM, O. Hartmann wrote: > Am 11/27/11 22:05, schrieb Garrett Cooper: >> On Sun, Nov 27, 2011 at 9:01 AM, O. Hartmann >> wrote: >>> Sources of FreeBSD 10.0-CUR/amd64 as svn-ed recently: >>> >>> Path: . >>> Working Copy Root Path: /usr/src >>> URL: svn://svn.freebsd.org/base/head >>> Repository Root: svn://svn.freebsd.org/base >>> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >>> Revision: 228029 >>> Node Kind: directory >>> Schedule: normal >>> Last Changed Author: trociny >>> Last Changed Rev: 228029 >>> Last Changed Date: 2011-11-27 17:56:01 +0100 (Sun, 27 Nov 2011) >>> >>> fail to build with the following error: >> >> Look for the first "Error code" in your output -- the line before that >> is the real error. That being said, there were some additional CFLAGS >> that needed to be fed in to make things work with libc++ and libcxxrt >> IIRC. >> Cheers, >> -Garrett > > > ... thanks for the advice. > Is there any chance to find out which Flags one has to set (the WIKI > seems not to mention anything)? Should be off by default; it can be enabled via WITH_LIBCPLUSPLUS. -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Nov 28 20:42:06 2011 Return-Path: Delivered-To: Current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66943106566B for ; Mon, 28 Nov 2011 20:42:06 +0000 (UTC) (envelope-from gabor@t-hosting.hu) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 1C7E98FC15 for ; Mon, 28 Nov 2011 20:42:05 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 9EC5A14E66DE; Mon, 28 Nov 2011 21:23:04 +0100 (CET) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id h3C7sc7rvTVs; Mon, 28 Nov 2011 21:23:02 +0100 (CET) Received: from [192.168.1.117] (catv-80-98-232-12.catv.broadband.hu [80.98.232.12]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 5CB0614E66A6; Mon, 28 Nov 2011 21:23:02 +0100 (CET) Message-ID: <4ED3EDA4.3010006@t-hosting.hu> Date: Mon, 28 Nov 2011 21:23:00 +0100 From: =?ISO-8859-1?Q?G=E1bor_K=F6vesd=E1n?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a2) Gecko/20111122 Thunderbird/10.0a2 MIME-Version: 1.0 To: Jan Beich References: <4ED20A68.90102@zedat.fu-berlin.de> <1RUbug-000P7m-2d@internal.tormail.net> <1RUcaG-000Pux-OQ@internal.tormail.net> In-Reply-To: <1RUcaG-000Pux-OQ@internal.tormail.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 28 Nov 2011 21:03:31 +0000 Cc: "O. Hartmann" , Current@FreeBSD.ORG Subject: Re: bsdgrep --null has no effect 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, 28 Nov 2011 20:42:06 -0000 On 2011.11.27. 12:07, Jan Beich wrote: > Oops, here is a diff. Non -l/-L case still seems to be broken. > > $ echo t>a; echo t>b; echo t>c > $ gnugrep --null . ? | vis > a\^@t > b\^@t > c\^@t > > $ bsdgrep --null . ? | vis > a\^@:t > b\^@:t > c\^@:t Thanks Jan, I've just committed this and your other patch to HEAD and will MFC it soon. Gabor From owner-freebsd-current@FreeBSD.ORG Mon Nov 28 22:21:09 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A94851065670 for ; Mon, 28 Nov 2011 22:21:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7F0848FC19 for ; Mon, 28 Nov 2011 22:21:09 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 19EFE46B0D; Mon, 28 Nov 2011 17:21:09 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 930B7B93A; Mon, 28 Nov 2011 17:21:08 -0500 (EST) From: John Baldwin To: John Nielsen Date: Mon, 28 Nov 2011 17:20:43 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <848DEEC1-570F-43F8-B432-A34F81014CD0@jnielsen.net> <201111221026.23015.jhb@freebsd.org> <929879BF-521C-43A1-8D63-DF2B04B6D013@jnielsen.net> In-Reply-To: <929879BF-521C-43A1-8D63-DF2B04B6D013@jnielsen.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111281720.44003.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 28 Nov 2011 17:21:08 -0500 (EST) Cc: "freebsd-current@freebsd.org" Subject: Re: loader crash / BTX halted on 9.0-RC2 DVD with AMD pseudo-RAID 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, 28 Nov 2011 22:21:09 -0000 On Tuesday, November 22, 2011 10:07:52 pm John Nielsen wrote: > On Nov 22, 2011, at 10:26 AM, John Baldwin wrote: > > > On Monday, November 21, 2011 1:45:36 pm John Nielsen wrote: > >> This weekend I downloaded the Freebsd 9.0 RC2 amd64 ISO image and burned it > > to a DVD. I have a computer that currently runs Windows 7 but I plan to > > install FreeBSD on it in the near future so I booted it up from the DVD to > > check the hardware/driver status. Much to my dismay, the boot loader crashed > > right away (register dump followed by "BTX halted") and the computer > > immediately rebooted. I took a video with my phone so I could capture the > > crash message, screenshot here: > >> > >> http://picpaste.com/pics/BTXcrash.1321899682.jpg > >> > >> I then tried tweaking a few BIOS settings and found that turning off the > > built-in pseudo-RAID allowed the DVD to boot normally. I changed the SATA type > > from "RAID" to "AHCI". Fortunately I plan to use the controller in AHCI mode > > for the FreeBSD installation so this won't end up being a problem for me, but > > I still thought it was worth reporting. > > > > Hmmm, so this is odd. It died with an Invalid TSS exception on the iret > > instruction at the end of the return-from-real-mode trampoline in BTX. > > Looking at the dump I noticed that PSL_NT is set in %eflags, so for some > > reason the iret was trying to do a nested task return. We shouldn't let > > that flag leak out of any real mode code. Try this patch perhaps: > > Thanks for looking! > > I put gptboot on a USB stick and tried it with and without the patch. > Identical behavior in both cases to booting from the DVD (only faster)--BTX > dump and an instant reboot. I didn't do a screen capture yet but will be > happy to tomorrow if it will help. A screen capture would be useful. It may be that I did not fix the right copy of the flags. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Nov 28 22:59:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B85631065670 for ; Mon, 28 Nov 2011 22:59:17 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 6D0B28FC0A for ; Mon, 28 Nov 2011 22:59:17 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1RVAAO-0002dO-Cx>; Mon, 28 Nov 2011 23:59:16 +0100 Received: from e178029211.adsl.alicedsl.de ([85.178.29.211] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RVAAO-0003Kl-7u>; Mon, 28 Nov 2011 23:59:16 +0100 Message-ID: <4ED41243.4060209@zedat.fu-berlin.de> Date: Mon, 28 Nov 2011 23:59:15 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: Garrett Cooper References: <4ED26CE9.3020107@zedat.fu-berlin.de> <4ED3CEB8.6090409@zedat.fu-berlin.de> In-Reply-To: X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC7FEDA5F51E15F6EDF0E2677" X-Originating-IP: 85.178.29.211 Cc: Current FreeBSD Subject: Re: Building FreeBSD 10.0-CURRENT/amd64 of today fails (with clang and WITH_LIBCPLUSPLUS=YES) 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, 28 Nov 2011 22:59:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC7FEDA5F51E15F6EDF0E2677 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 11/28/11 20:10, schrieb Garrett Cooper: > On Mon, Nov 28, 2011 at 10:11 AM, O. Hartmann > wrote: >> Am 11/27/11 22:05, schrieb Garrett Cooper: >>> On Sun, Nov 27, 2011 at 9:01 AM, O. Hartmann >>> wrote: >>>> Sources of FreeBSD 10.0-CUR/amd64 as svn-ed recently: >>>> >>>> Path: . >>>> Working Copy Root Path: /usr/src >>>> URL: svn://svn.freebsd.org/base/head >>>> Repository Root: svn://svn.freebsd.org/base >>>> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >>>> Revision: 228029 >>>> Node Kind: directory >>>> Schedule: normal >>>> Last Changed Author: trociny >>>> Last Changed Rev: 228029 >>>> Last Changed Date: 2011-11-27 17:56:01 +0100 (Sun, 27 Nov 2011) >>>> >>>> fail to build with the following error: >>> >>> Look for the first "Error code" in your output -- the line before tha= t >>> is the real error. That being said, there were some additional CFLAGS= >>> that needed to be fed in to make things work with libc++ and libcxxrt= >>> IIRC. >>> Cheers, >>> -Garrett >> >> >> ... thanks for the advice. >> Is there any chance to find out which Flags one has to set (the WIKI >> seems not to mention anything)? >=20 > Should be off by default; it can be enabled via WITH_LIBCPLUSPLUS. > -Garrett > _______________________________________________ Hello Garrett. Yes, it is off by default and the system build well with this feature off by default. But when enabling WITH_LIBCPLUSPLUS in /etc/src.conf, I get always the error I started this thread with. Well, either this is a real error and I should PR, or it is my impatience that tries to use something still getting merged. I tried to look at the wiki for that, but it does not mention anything else apart the flag WITH_LIBCPLUSPLUS. No additional CFLAGS or something =2E.. so I'm a little bit confused. Regards, Oliver --------------enigC7FEDA5F51E15F6EDF0E2677 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO1BJDAAoJEOgBcD7A/5N8PyIH/0EnFMX54hFM6Alflsx8zL69 ctPZu7w3KQOpVDex7xMxR08JCiP3LTfa/W/DIwjJXboBv73SknaHDl+NTpLiQ6yr rERItXHAsnpkDA5Z0NqKjM9mpaP8dnwdqiGW4UnLWjQWUv5ljmqp18Zb2AEV4Exj x+X3jjHXB9ve5UrH3KwymOVhhwOX7n4+0RPaG22R5GysK50EV13Ttf7PnVtIKi1y zXoHgejyeODkC5xG8QxZlJ8KuCFdMtUcepASxCMV+FQ1SVLFfdxkXJN5AnGRb59O NSPdXU416By/4cBGUn/Ja5AO2bK2nASLZsUxTtcgPJvGDUvtIsbcISefGj2UHro= =ZmSb -----END PGP SIGNATURE----- --------------enigC7FEDA5F51E15F6EDF0E2677-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 28 23:14:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A134E1065670 for ; Mon, 28 Nov 2011 23:14:23 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 86BD68FC14 for ; Mon, 28 Nov 2011 23:14:23 +0000 (UTC) Received: from delta.delphij.net (c-76-102-50-245.hsd1.ca.comcast.net [76.102.50.245]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 4016C6620; Mon, 28 Nov 2011 15:14:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1322522063; bh=hfB6lqJS3Niwz5DeB5KCQyJjXHUWQASW7LTkzamkvk4=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=wjQ6ZLh+YoGhXImBl4Gl2a6GMcvd2JuObVzaOiEWIUduyxmxNBj3a5yNzu+wWG5V1 DvEr3xX2BW3P8ueB4iyq1Nb1y9W41nFsKDFIuVVFH+YFHAth49BYmnmUhRU1NBtSFo Hgv7cnSyRxLrbGcbXup6i1+Z4Ym+eUGKWsYC75i0= Message-ID: <4ED415CD.1080005@delphij.net> Date: Mon, 28 Nov 2011 15:14:21 -0800 From: Xin LI Organization: The FreeBSD Project MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <201111240126.21470.Mark.Martinec+freebsd@ijs.si> In-Reply-To: <201111240126.21470.Mark.Martinec+freebsd@ijs.si> OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: iSCSI initiator: iscontrol cannot be stopped or killed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 23:14:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 11/23/11 16:26, Mark Martinec wrote: > Problem: the iscontrol process starts normally and establishes a > session and brings up a device, but it cannot be stopped. It does > not react to a HUP signal, and neither to KILL. > > The /dev/da0 device is operational and the remote disk remains > normally accessible, regardless of how I try to (unsuccessfully) > shutdown the iscontrol process. The ps reports the state of the > process as "Ds", not doing anything. A ktrace does not show any > reaction to a received signal. A restart seems to be necessary to > break the iSCSI session. > > Using FreeBSD 9.0-rc2, amd64, also tried with 9.0-PRERELEASE (csup > tag=RELENG_9 as of today). This used to work normally as > documented on the same host with the same iscsi.conf config file > before upgrading from 8.2 to 9.0. > > Anybody else experiencing this problem? Suggestions welcome. Try procstat -kk to find the calling stack, as a start? This could be very useful when tracking down problems. Also the 'D' flag from ps(1) output in most times are not quite useful and ps -o wchan would tell you what exactly it was waiting for, just FYI. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJO1BXMAAoJEATO+BI/yjfBd2AIAJW1xHR93fN5eROUz9rs1YiX 8ANhcPTLmScN04YJb65ytm/BYUVKAtUN/rct2seZPosHO+REvYJhF7Tz5DKRRHJX h+LG65S3HNBR9GBLdadw5BusbvU+T18oTvrxnqPtB1vcn5pEvQk0xtw3M3R/PrIu V45mACO0f51auQl8oHfTUKzY48k06eDszyQhlrGCbY1FTydUU2e8AqJKd6GEIx31 f6kd0WGTpcIam6WdONpTR08d2HoPp/zK0gUADW+S2NiKfzDCy/PvJL+02lK2YlEy M6dvnk62X6Tfkv1SV947WZT57UMDZkXbVNgwjvxwT5tSKUUbeGGvm241ZnLN2HI= =IZ2x -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Nov 28 23:20:48 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A0841065673; Mon, 28 Nov 2011 23:20:48 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id C8C718FC14; Mon, 28 Nov 2011 23:20:47 +0000 (UTC) Received: by ywp17 with SMTP id 17so6086535ywp.13 for ; Mon, 28 Nov 2011 15:20:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8D2EoEkyGRoi5gMO/xO1a9tqS5lSg6z3bstt6mQCnEM=; b=ZUx4vAjc3D3tqpHfUs29qecnrIvm1ueLzUNSntC7eD3Zd/Gt8M+hS33HfpVJjji4i9 CT3xSmiRonIYh4I9+OqlXgri2j6sbwBNNt9EG3NvjrXzjT6iwp7R5Il280QiNGe/Lrw9 UBvinyl9GTtzVXkz7e8kysBxbFh3Cm4lj3FGw= MIME-Version: 1.0 Received: by 10.182.218.100 with SMTP id pf4mr1296924obc.12.1322522447254; Mon, 28 Nov 2011 15:20:47 -0800 (PST) Received: by 10.182.62.227 with HTTP; Mon, 28 Nov 2011 15:20:47 -0800 (PST) In-Reply-To: <4ED41243.4060209@zedat.fu-berlin.de> References: <4ED26CE9.3020107@zedat.fu-berlin.de> <4ED3CEB8.6090409@zedat.fu-berlin.de> <4ED41243.4060209@zedat.fu-berlin.de> Date: Mon, 28 Nov 2011 15:20:47 -0800 Message-ID: From: Garrett Cooper To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Cc: Current FreeBSD , David Chisnall Subject: Re: Building FreeBSD 10.0-CURRENT/amd64 of today fails (with clang and WITH_LIBCPLUSPLUS=YES) 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, 28 Nov 2011 23:20:48 -0000 On Mon, Nov 28, 2011 at 2:59 PM, O. Hartmann wrote: > Am 11/28/11 20:10, schrieb Garrett Cooper: >> On Mon, Nov 28, 2011 at 10:11 AM, O. Hartmann >> wrote: >>> Am 11/27/11 22:05, schrieb Garrett Cooper: >>>> On Sun, Nov 27, 2011 at 9:01 AM, O. Hartmann >>>> wrote: >>>>> Sources of FreeBSD 10.0-CUR/amd64 as svn-ed recently: >>>>> >>>>> Path: . >>>>> Working Copy Root Path: /usr/src >>>>> URL: svn://svn.freebsd.org/base/head >>>>> Repository Root: svn://svn.freebsd.org/base >>>>> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >>>>> Revision: 228029 >>>>> Node Kind: directory >>>>> Schedule: normal >>>>> Last Changed Author: trociny >>>>> Last Changed Rev: 228029 >>>>> Last Changed Date: 2011-11-27 17:56:01 +0100 (Sun, 27 Nov 2011) >>>>> >>>>> fail to build with the following error: >>>> >>>> Look for the first "Error code" in your output -- the line before that >>>> is the real error. That being said, there were some additional CFLAGS >>>> that needed to be fed in to make things work with libc++ and libcxxrt >>>> IIRC. >>>> Cheers, >>>> -Garrett >>> >>> >>> ... thanks for the advice. >>> Is there any chance to find out which Flags one has to set (the WIKI >>> seems not to mention anything)? >> >> Should be off by default; it can be enabled via WITH_LIBCPLUSPLUS. >> -Garrett >> _______________________________________________ > > > Hello Garrett. > Yes, it is off by default and the system build well with this feature > off by default. But when enabling WITH_LIBCPLUSPLUS in /etc/src.conf, > I get always the error I started this thread with. > > Well, either this is a real error and I should PR, or it is my > impatience that tries to use something still getting merged. > > I tried to look at the wiki for that, but it does not mention anything > else apart the flag WITH_LIBCPLUSPLUS. No additional CFLAGS or something > ... so I'm a little bit confused. Read through http://osdir.com/ml/freebsd-current/2011-11/msg00718.html -- in particular: "libcxxrt and libc++ are now in contrib and building with the base system, but are not used by anything (and are only built if you set WITH_LIBCPLUSPLUS=yes when building world, not by default). If you want to test some code with the new stack, you need to build it and then specify >> -stdlib=libc++ << to clang++ (both when compiling and linking)." That being said, if there's something else that's required I've CCed David for visibility. I would definitely include the full build log somewhere else so someone can analyze the error. Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Nov 28 23:55:48 2011 Return-Path: Delivered-To: Current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5F941065670 for ; Mon, 28 Nov 2011 23:55:48 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 6D3FE8FC1C for ; Mon, 28 Nov 2011 23:55:48 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1RVB35-0007li-0N>; Tue, 29 Nov 2011 00:55:47 +0100 Received: from e178029211.adsl.alicedsl.de ([85.178.29.211] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RVB34-0005pK-Rv>; Tue, 29 Nov 2011 00:55:46 +0100 Message-ID: <4ED41F7B.80003@zedat.fu-berlin.de> Date: Tue, 29 Nov 2011 00:55:39 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?G=E1bor_K=F6vesd=E1n?= References: <4ED20A68.90102@zedat.fu-berlin.de> <1RUbug-000P7m-2d@internal.tormail.net> <1RUcaG-000Pux-OQ@internal.tormail.net> <4ED3EDA4.3010006@t-hosting.hu> In-Reply-To: <4ED3EDA4.3010006@t-hosting.hu> X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig232EE27C6D2D2F635F8045A9" X-Originating-IP: 85.178.29.211 Cc: Jan Beich , Garrett Cooper , Current@FreeBSD.ORG Subject: Re: bsdgrep --null has no effect 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, 28 Nov 2011 23:55:48 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig232EE27C6D2D2F635F8045A9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 11/28/11 21:23, schrieb G=E1bor K=F6vesd=E1n: > On 2011.11.27. 12:07, Jan Beich wrote: >> Oops, here is a diff. Non -l/-L case still seems to be broken. >> >> $ echo t>a; echo t>b; echo t>c >> $ gnugrep --null . ? | vis >> a\^@t >> b\^@t >> c\^@t >> >> $ bsdgrep --null . ? | vis >> a\^@:t >> b\^@:t >> c\^@:t > Thanks Jan, I've just committed this and your other patch to HEAD and > will MFC it soon. >=20 > Gabor After the patch of grep the mentioned port astro/stellarium build perfectly again! Thanks a lot for fast resposne. Regards, Oliver --------------enig232EE27C6D2D2F635F8045A9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO1B+CAAoJEOgBcD7A/5N8IW8IALUn4ayqwdMc/+mr2mjn1Z+U qTffloZKoDV7c/8EGHcOFF3Ic22TTu/eG2g+I9ySdsZH75uPYq+r/lZoOPmkvuZN 5dEIzv1sN0wcc8I4+jS4XEmkBlJsA3URcOpJRcCJYdDK8fLn6YdH1NWTS2qsl1BO ERs20dSN0Zd3SU49zxtBZW2YQQM9DId8CN/KniWVRm8+ymVZ5IXSHPYbkm06P87K AhICOVNMp4fy1pZ3So9Tr/2GPZ5vOuX9X7d9UvDaAYJlnj16MS1bfmX4kLJQHQu9 SUU3IEXw1s3PZpAkwioCJubJ5McsMEXMQyoQ5qlXJwqVueZ9s+oHJYG731+2OX4= =lS1m -----END PGP SIGNATURE----- --------------enig232EE27C6D2D2F635F8045A9-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 29 00:07:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FEE1106566B; Tue, 29 Nov 2011 00:07:17 +0000 (UTC) (envelope-from Daan@vitsch.nl) Received: from VM01.VEHosting.nl (VM016.VEHosting.nl [IPv6:2001:1af8:2100:b020::140]) by mx1.freebsd.org (Postfix) with ESMTP id 7DC7D8FC08; Tue, 29 Nov 2011 00:07:16 +0000 (UTC) Received: from [2001:470:d233:2:224:8cff:fe82:66cd] ([IPv6:2001:470:d233:2:224:8cff:fe82:66cd]) (authenticated bits=0) by VM01.VEHosting.nl (8.14.3/8.13.8) with ESMTP id pAT07I3x005223; Tue, 29 Nov 2011 01:07:18 +0100 (CET) (envelope-from Daan@vitsch.nl) From: Daan Vreeken Organization: Vitsch Electronics To: Gleb Smirnoff Date: Tue, 29 Nov 2011 01:07:13 +0100 User-Agent: KMail/1.9.10 References: <201111240928.51162.Daan@vitsch.nl> <20111125131935.GP96616@FreeBSD.org> <20111125143257.GR96616@FreeBSD.org> In-Reply-To: <20111125143257.GR96616@FreeBSD.org> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_xIC1OndPncenpNF" Message-Id: <201111290107.13631.Daan@vitsch.nl> x-ve-auth-version: mi-1.1.5 2011-02-07 - Copyright (c) 2008, 2011 - Daan Vreeken - VEHosting x-ve-auth: authenticated as 'pa4dan' on VM01.VEHosting.nl Cc: FreeBSD Current Subject: Re: if_clone.c allows creating multiple interfaces with the same name 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, 29 Nov 2011 00:07:17 -0000 --Boundary-00=_xIC1OndPncenpNF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Glebius, On Friday 25 November 2011 15:32:58 Gleb Smirnoff wrote: > On Fri, Nov 25, 2011 at 05:19:35PM +0400, Gleb Smirnoff wrote: > T> On Thu, Nov 24, 2011 at 09:28:51AM +0100, Daan Vreeken wrote: > T> D> Recently I've discovered a bug in if_clone.c and if.c where the code > allows T> D> multiple interfaces to be created with exactly the same name > (which leads to T> D> all sorts of other interesting problems). > T> D> I've submitted a PR about this with patches, which can be found here > : T> D> > T> D> http://www.freebsd.org/cgi/query-pr.cgi?pr=162789 > T> D> > T> D> Could anyone take a look at it? > T> > T> I decided to simply if_clone code utilizing generic unit allocator. > Patch T> atteched. Now I'll try to merge it with your ideas. > > Here is if_cloner patched with additional ifunit() check, as you suggested. > Please review my patch and test it, and then we can commit it. Thanks for the looking into this and for your quick commit. I like your twist on the patch with the move from the unit bitmap to allocating unit numbers with alloc_unr(9). I do have two comments on the new code though. Before, in the !wildcard case, ifc_alloc_unit() would return ENOSPC when the user requested a unit number larger than ifc->ifc_maxunit. Now the function returns EEXIST in that case because alloc_unr_specific() returns -1 both when a number is already allocated and when the number exceeds it's limits. This leads to the somewhat confusing: # ifconfig bridge123456 create ifconfig: SIOCIFCREATE2: File exists Apart from that I'm a bit worried about the "/* XXXGL: yep, it's a unit leak */" part of your change. Once a unit number is leaked, there currently seems to be no way to ever get it back. In a worst case scenario, where the names of multiple interfaces in a row collides with the numbers alloc_unr() returns, an entire row of unit numbers could be leaked during the creation of a single cloned interface. We have a product where cloned interfaces come and go very frequently. I'd hate to run out of unit numbers after 'just a few' years of uptime ;-) I've created a new patch on top of your change that fixes both of these problems. Could you have a look at the attached diff? In case the attachment doesn't survive the list, it can also be found here: http://www.vitsch.nl/pub-diffs/if_clone-ENOSPC-and-unr-leak-fix-2011-11-29.diff > Considering the second part, that adds locking. Unfortunately, right now we > have numerous races in the network configuration ocde. Many SIOCSsomething > ioctls can race with each other producing unpredictable results and kernel > panics. So, running two ifconfig(8) in parallel is a bad idea today. :( > Your patch with IFNET_NAMING_LOCK() just plumbs one race case: a race > between two SIOCSIFNAME ioctls. And it doesn't plumb a race between > SIOCSIFNAME vs SIOCIFCREATE, because IFNET_NAMING_LOCK() is dropped after > unit allocation, but prior to interface attachement to global interface > list. Are you sure? With the patch in the PR, the relevant code in ifc_simple_create() would become : ... IFNET_NAMING_LOCK(); err = ifc_alloc_unit(ifc, &unit); if (err != 0) { IFNET_NAMING_UNLOCK(); return (err); } err = ifcs->ifcs_create(ifc, unit, params); IFNET_NAMING_UNLOCK(); if (err != 0) { ifc_free_unit(ifc, unit); return (err); } ... The lock is acquired before the call to ifc_alloc_unit(). In the non-error case (e.g. when creating an if_bridge interface) the call ends up calling bridge_clone_create(), which calls ether_ifattach(), which calls if_attach() -> if_attach_internal() where the ifp is added to the ifnet list. Only when that's done, the lock is dropped. Am I overlooking something obvious here? > From my point of view, we need a generic approach to ioctl() vs ioctl() > races, may be some global serializer of all re-configuration requests of > interfaces and addresses. Thanks, -- Daan Vreeken Vitsch Electronics http://Vitsch.nl tel: +31-(0)40-7113051 / +31-(0)6-46210825 KvK nr: 17174380 --Boundary-00=_xIC1OndPncenpNF Content-Type: text/x-diff; charset="iso-8859-1"; name="if_clone-ENOSPC-and-unr-leak-fix-2011-11-29.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="if_clone-ENOSPC-and-unr-leak-fix-2011-11-29.diff" Index: sys/net/if_clone.c =================================================================== --- sys/net/if_clone.c (revision 228109) +++ sys/net/if_clone.c (working copy) @@ -436,30 +436,49 @@ } int -ifc_alloc_unit(struct if_clone *ifc, int *unit) +ifc_alloc_unit(struct if_clone *ifc, int *unit_nr) { char name[IFNAMSIZ]; - int wildcard; + int ret, unit, wildcard; - wildcard = (*unit < 0); + unit = *unit_nr; + wildcard = (unit < 0); retry: - if (wildcard) { - *unit = alloc_unr(ifc->ifc_unrhdr); - if (*unit == -1) + if (unit > ifc->ifc_maxunit) + return (ENOSPC); + + if (unit < 0) { + /* first, try to allocate a unit number automatically */ + unit = alloc_unr(ifc->ifc_unrhdr); + if (unit == -1) return (ENOSPC); } else { - *unit = alloc_unr_specific(ifc->ifc_unrhdr, *unit); - if (*unit == -1) - return (EEXIST); + ret = alloc_unr_specific(ifc->ifc_unrhdr, unit); + if (ret == -1) { + if (wildcard) { + /* unit number already claimed. try next */ + unit++; + goto retry; + } else { + /* specified unit number already claimed */ + return (EEXIST); + } + } } - snprintf(name, IFNAMSIZ, "%s%d", ifc->ifc_name, *unit); + /* if we reach this point, a unit number has been allocated */ + snprintf(name, IFNAMSIZ, "%s%d", ifc->ifc_name, unit); if (ifunit(name) != NULL) { - if (wildcard) - goto retry; /* XXXGL: yep, it's a unit leak */ - else - return (EEXIST); + /* name is already taken */ + free_unr(ifc->ifc_unrhdr, unit); + if (wildcard) { + /* increment unit number and try again */ + unit++; + goto retry; + } + return (EEXIST); } + *unit_nr = unit; IF_CLONE_ADDREF(ifc); --Boundary-00=_xIC1OndPncenpNF-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 29 00:08:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 3845E1065680 for ; Tue, 29 Nov 2011 00:08:52 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 36B7C14E37B; Tue, 29 Nov 2011 00:07:15 +0000 (UTC) Message-ID: <4ED4222E.5010707@FreeBSD.org> Date: Mon, 28 Nov 2011 16:07:10 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Max Khon References: In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current Subject: Re: WITHOUT_PROFILE=yes by default 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, 29 Nov 2011 00:08:52 -0000 On 11/28/2011 02:38, Max Khon wrote: > Are there any compelling reasons for having profiled libs to be built by > default? Nope. It's been one of the first things I disable after I install a new system for at least a decade. Ideally we could do this for 9.0. Doug -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Tue Nov 29 00:33:12 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23F191065785 for ; Tue, 29 Nov 2011 00:33:11 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 8C6B48FC08 for ; Tue, 29 Nov 2011 00:33:11 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id CCF055DCF; Tue, 29 Nov 2011 00:33:09 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id pAT0X9Gh066540; Tue, 29 Nov 2011 00:33:09 GMT (envelope-from phk@phk.freebsd.dk) To: Doug Barton From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 28 Nov 2011 16:07:10 PST." <4ED4222E.5010707@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 29 Nov 2011 00:33:09 +0000 Message-ID: <66539.1322526789@critter.freebsd.dk> Cc: freebsd-current , Max Khon Subject: Re: WITHOUT_PROFILE=yes by default 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, 29 Nov 2011 00:33:12 -0000 In message <4ED4222E.5010707@FreeBSD.org>, Doug Barton writes: >On 11/28/2011 02:38, Max Khon wrote: >> Are there any compelling reasons for having profiled libs to be built by >> default? > >Nope. It's been one of the first things I disable after I install a new >system for at least a decade. > >Ideally we could do this for 9.0. Can we at least keep one (small) library compiled for profiling, so that compiling for profiling doesn't get broken by accident ? -- 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 Nov 29 00:35:14 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id AFE431065675 for ; Tue, 29 Nov 2011 00:35:14 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 6917E158CC4; Tue, 29 Nov 2011 00:35:04 +0000 (UTC) Message-ID: <4ED428B8.8040909@FreeBSD.org> Date: Mon, 28 Nov 2011 16:35:04 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Poul-Henning Kamp References: <66539.1322526789@critter.freebsd.dk> In-Reply-To: <66539.1322526789@critter.freebsd.dk> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current , Max Khon Subject: Re: WITHOUT_PROFILE=yes by default 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, 29 Nov 2011 00:35:14 -0000 On 11/28/2011 16:33, Poul-Henning Kamp wrote: > In message <4ED4222E.5010707@FreeBSD.org>, Doug Barton writes: >> On 11/28/2011 02:38, Max Khon wrote: > >>> Are there any compelling reasons for having profiled libs to be built by >>> default? >> >> Nope. It's been one of the first things I disable after I install a new >> system for at least a decade. >> >> Ideally we could do this for 9.0. > > Can we at least keep one (small) library compiled for profiling, so > that compiling for profiling doesn't get broken by accident ? I think WITH_PROFILE is probably a good idea for the tinderbox? -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Tue Nov 29 02:16:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5267106564A for ; Tue, 29 Nov 2011 02:16:32 +0000 (UTC) (envelope-from allan@stokes.ca) Received: from www6.webmail.pair.com (www6.webmail.pair.com [66.39.3.84]) by mx1.freebsd.org (Postfix) with SMTP id 826958FC13 for ; Tue, 29 Nov 2011 02:16:32 +0000 (UTC) Received: (qmail 903 invoked by uid 65534); 29 Nov 2011 01:49:50 -0000 Received: from 206.116.240.246 ([206.116.240.246]) (SquirrelMail authenticated user allan@stokes.ca) by sm.webmail.pair.com with HTTP; Mon, 28 Nov 2011 17:49:50 -0800 Message-ID: <0168ab7579589d8d866ce8ff93544f1f.squirrel@sm.webmail.pair.com> Date: Mon, 28 Nov 2011 17:49:50 -0800 From: allan@stokes.ca To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.22 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: upgrade issue 8.x to 9.0-RC2: libz.so.5 not found 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, 29 Nov 2011 02:16:32 -0000 Hello everyone, First a quick introduction, then my project, then my problem. ==My FreeBSD involvement== I've been dabbling with FreeBSD since I set up stokes.ca at pair.com over a decade ago. I liked the service at Pair, so I installed FreeBSD at home on a spare box. One of those evil Fujitsu disk drives took out my stable 4.x test system before I had a complete set of backups (Fujitsu was early into fluid dynamic bearings and I purchased on acoustics). I won't pain anyone by recalling the 5.x experience that followed. I had a 6.x system for a long time, but it never got much beyond a quasi offline backup spool. The 30GB system disk finally conked out--this was expected, so I slapped a new system disk into a box that had previously been my workstation, and performed a fresh 8 series installation. Unfortunately, I was never able to mount my PATA backup drive because of issues with the JMicron 363 PATA controller chip on the Asus P5B. These issues still exist in 9.x FWIW. Last week I finally shut down my firewall, stretched the drive cables across (to a different Core Duo mainboard not afflicted with a JMicron PATA controller) and scarfed the aging data. I had the data elsewhere in bits and pieces so there was never great urgency, the value was mainly that this was my only _organized_ backup set. ==7 men EGTB== I'm getting more serious about FreeBSD again because I'm becoming involved over the next few years in a hobby project to compute the chess seven-piece EGTB data set, which will total 60TB I think, when someday the computation completes. I'm mostly interested in compressed disk representations which permit high access speed that can be used by chess engines in real time. I might do a few pieces of the retrograde computation myself, but nowhere close to the whole thing. To perform the computation with full chess accuracy you need to begin with maximal promotion: two kings and five queens, and then work down through crazy promotions, such as two kings and five bishops, and then finally to positions that could possibly someday occur in a real chess game: many terabytes of computationally intense bootstrap to cover some very tiny corner cases (how tiny is a question I'm interested to explore, but most chess purists aren't). Even a small piece of the project would generate copious data so I've rigged up an experimental ZFS v28 box with a triple mirror on three 500GB disks I had lying around (two slightly enterprisy, one a Seagate refurb). I think of it as a two-way mirror with a pre-silvered hot spare that's better than nothing. I put 6GB of memory into the box and tried out deduplication. It ran great. I don't expect to use this feature (in hobby production) any time soon. I'll probably upgrade all the drives after the waters recede in Thailand and run fairly basic parameters. This week I'm intending to purchase a pair of Intel 311 SSD drives (20GB SLC) as a mirrored ZIL or ZIL/ARC option (Newegg.ca has them for $110). Warn me soon if I'm doing something stupid! I wish my ZFS box had chipkill ECC, but that upgrade is out of my budget at present, since it involves a whole new system board, CPU, and memory. I'm going to have to live a bit on the edge with other backups (and integrity checksums) available. I have some general interest in testing out what ZFS can do on fully configured box. I also do a lot of R programming and I'm experimenting with HDF5 for large data sets. The ZIL upgrade doesn't pertain much to my EGTB project. I'm either not brave enough or insane enough to put my FreeBSD system volume onto the ZFS mirror, as much as that seems kind of cool. Plain old UFS on a separate drive for me. Have others had success with ZFS system volumes? ==Broken upgrade problem== I was able to do a binary upgrade from 8.x to 9.0-RC2-p0. Slick. I once skimmed Colin's thesis, but the math is heavy--I understood enough to grasp that it's an excellent piece of work, and certainly much appreciated. After the binary upgrade my system runs well enough to initiate a ZFS pool and survive some ZFS pounding over the network (20GB data set with a recursive symlink deduplicated many times over until I finally killed it). However, programs such as startx and portupgrade are failing with the message "libz.so.5 not found". I know I can fix this with an evil symlink, but that doesn't seem right, and what else is broken? Is there not a facility in portupgrade to scan my live dependencies and warn me of breakage? I have not encountered such a beast in my gleanings to date. On the first pass I skipped the package build step in my haste to break everything. That didn't work well (of course), so I rolled it back (sweet) and followed instructions: including the Ruby preamble and the triple Beetlejuice freebsd-update incantation. If there's an easy way to fix the mess, I'll do so, but otherwise there's no reason not to repair the problem with the blunt tool of a fresh system installation. In the past, I've been able to install FreeBSD using PXE and a TFTP service on my firewall (mostly using em0 network cards). I use the PXE facility so rarely, it's a small struggle to recall the magic each time. Note that after my ports recompiled (flags -af), there were roughly 40 packages out of 470 in /var/db/pkg that still had the old date stamp. These could be unimportant remnants for all I know. The list includes xorg-7.5, apache-2.0.63_15, a bunch of qt4 and xfree stuff, and xz-4.999.9 which I don't think pertains to libz, but I could be wrong. Finally, I also have some comments about ZFS as pertaining to idiots running on commodity DRAM (I can't be the only one). Which is the right mailing list? Basically my sentiment is that if you don't have hardware ECC (not even available so far as I know for the SB-E platform ideal to the EGTB computation and the Xeon equivalents are pricey), some software memory scrubbing could be valuable, and obvious to implement for the in-memory ARC cache (where cached data can sit exposed to cosmic rays for an indefinite time period on a lightly loaded network)--if ZFS doesn't incorporate that trick already. Any suggestions are appreciated. Allan From owner-freebsd-current@FreeBSD.ORG Tue Nov 29 03:13:50 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CDE6106564A; Tue, 29 Nov 2011 03:13:50 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 01F8C8FC0C; Tue, 29 Nov 2011 03:13:49 +0000 (UTC) Received: by ghbg20 with SMTP id g20so7251803ghb.13 for ; Mon, 28 Nov 2011 19:13:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.41.100 with SMTP id e4mr13109287obl.63.1322536429230; Mon, 28 Nov 2011 19:13:49 -0800 (PST) Received: by 10.182.76.225 with HTTP; Mon, 28 Nov 2011 19:13:49 -0800 (PST) X-Originating-IP: [93.92.220.178] In-Reply-To: <4ED428B8.8040909@FreeBSD.org> References: <66539.1322526789@critter.freebsd.dk> <4ED428B8.8040909@FreeBSD.org> Date: Tue, 29 Nov 2011 10:13:49 +0700 Message-ID: From: Max Khon To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Poul-Henning Kamp , freebsd-current Subject: Re: WITHOUT_PROFILE=yes by default 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, 29 Nov 2011 03:13:50 -0000 Doug, On Tue, Nov 29, 2011 at 7:35 AM, Doug Barton wrote: >>> Are there any compelling reasons for having profiled libs to be built by > >>> default? > >> > >> Nope. It's been one of the first things I disable after I install a new > >> system for at least a decade. > >> > >> Ideally we could do this for 9.0. > > > > Can we at least keep one (small) library compiled for profiling, so > > that compiling for profiling doesn't get broken by accident ? > > I think WITH_PROFILE is probably a good idea for the tinderbox? Who is in charge for tinderbox these days? Max From owner-freebsd-current@FreeBSD.ORG Tue Nov 29 05:02:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70FF8106564A for ; Tue, 29 Nov 2011 05:02:24 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 342388FC0A for ; Tue, 29 Nov 2011 05:02:23 +0000 (UTC) Received: by qyg36 with SMTP id 36so5235650qyg.13 for ; Mon, 28 Nov 2011 21:02:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.43.3 with SMTP id u3mr5258267qce.210.1322542943338; Mon, 28 Nov 2011 21:02:23 -0800 (PST) Received: by 10.229.47.194 with HTTP; Mon, 28 Nov 2011 21:02:23 -0800 (PST) X-Originating-IP: [93.92.220.178] Date: Tue, 29 Nov 2011 12:02:23 +0700 Message-ID: From: Max Khon To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: removing libreadline from base system 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, 29 Nov 2011 05:02:24 -0000 Hello! It is possible to build and link our in-tree gdb & friends with libedit after r228114. The remaining question is what to do with libreadline: 1) just build & link gdb with libedit OR 2) re-import libreadline from gdb sources and build INTERNALLIB version of it that is never installed and is linked only to gdb I am inclined to go for 1) but libedit may have (and has) incompatibilities with libreadline. Max From owner-freebsd-current@FreeBSD.ORG Tue Nov 29 07:05:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 513F6106564A for ; Tue, 29 Nov 2011 07:05:36 +0000 (UTC) (envelope-from martin@sugioarto.com) Received: from mailserv.regfish.com (mailserv.regfish.com [79.140.61.33]) by mx1.freebsd.org (Postfix) with ESMTP id 9960D8FC0A for ; Tue, 29 Nov 2011 07:05:35 +0000 (UTC) Received: (qmail 3518 invoked from network); 29 Nov 2011 07:05:33 -0000 Received: from pd9ec004e.dip0.t-ipconnect.de (HELO yuni.sugioarto.com) (46959-0001@[217.236.0.78]) (envelope-sender ) by mailserv.regfish.com (qmail-ldap-1.03) with SMTP for ; 29 Nov 2011 07:05:33 -0000 Received: from zelda.sugioarto.com (zelda.sugioarto.com [192.168.0.12]) by yuni.sugioarto.com (Postfix) with ESMTP id B130C1BAC57; Tue, 29 Nov 2011 08:05:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sugioarto.com; s=mail; t=1322550330; bh=U2hJ25DPFnxnabSv8ftatmAcYcdcJjFNh8/wene0u9w=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: Mime-Version:Content-Type; b=EEYKCvR+o5UctkfWGYE/FeTPVkAVwzJNfyDSoaI1/0qwCdu9KrZXlMgA7zHCaeofe kiourAUoI6uIDAwGnpRHtti18WDhYyZEjQoFXoPmjSALWeFSzG6gFRtK+enn4M7YE0 h5FBL3XSUhzI3VqFKEOUJEwvtvE7JDs5Q/6H0X+Y= Date: Tue, 29 Nov 2011 08:05:17 +0100 From: Martin Sugioarto To: allan@stokes.ca Message-ID: <20111129080517.153d3c39@zelda.sugioarto.com> In-Reply-To: <0168ab7579589d8d866ce8ff93544f1f.squirrel@sm.webmail.pair.com> References: <0168ab7579589d8d866ce8ff93544f1f.squirrel@sm.webmail.pair.com> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/s8m7xa4e6/X6CbbmS/VzeYv"; protocol="application/pgp-signature" Cc: freebsd-current@freebsd.org Subject: Re: upgrade issue 8.x to 9.0-RC2: libz.so.5 not found 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, 29 Nov 2011 07:05:36 -0000 --Sig_/s8m7xa4e6/X6CbbmS/VzeYv Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Mon, 28 Nov 2011 17:49:50 -0800 schrieb allan@stokes.ca: > Hello everyone, Hi, (I'll shorten this a bit, because I don't have opinions on everything you wrote) =20 > I'm either not brave enough or insane enough to put my FreeBSD system > volume onto the ZFS mirror, as much as that seems kind of cool. > Plain old UFS on a separate drive for me. Have others had success > with ZFS system volumes? Since 8.2 I can confirm that ZFS was stable enough for me. But I have to admit that I'm still a bit sceptical because (even it's been long time ago) once I ended up with a broken zpool that spewed panics on zpool initialization. That was a horrible experience that I won't forget that easily. =20 > However, programs such as startx and portupgrade are failing with the > message "libz.so.5 not found". I know I can fix this with an evil > symlink, but that doesn't seem right, and what else is broken? Is > there not a facility in portupgrade to scan my live dependencies and > warn me of breakage? I have not encountered such a beast in my > gleanings to date. There is a little helper in port sysutils/bsdadminscripts called pkg_libchk. I use this tool very often like this: pkg_libchk -qo > broken.txt And then I cat it to portmaster: portmaster -d `cat broken.txt` I don't know anymore how the portmaster step works with portupgrade, you need to figure this out by yourself. =20 -- Martin --Sig_/s8m7xa4e6/X6CbbmS/VzeYv Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQIcBAEBAgAGBQJO1IQ5AAoJEF8wvLx/5p/7YIkQAJsN6yJqdcl8dbtpDHvv2Be/ wJCDhOOiy5ElKN6vE4lWOdWmhdcP5tfgDNao/KqRho30zOCRRU3ViSAfjY2SvjYT RI0Ki9VeCS98cZIc34q9EaUZnTJqzspnDOoMzif9TNzlQlf6QO6hqGtiDnwbcI3m kJbFj4yD8qZ22PNwDM+FNhM3Mg+OSA2iuc+LWAZwIqaTdlN4STKehrzNlwMf4F6o bt7JdJmxvOKTXi2c/f9GRRAwc1zi2GLHYI4vhUOj5PSs1YOuASZNi1IvJLEnJSBu 4e4ZniJ6h7RD46spsBG0eKmctd3rYa3UXeoP2eMyvq2zYWA4EjGH7MGumWIwb3EY /X/arLMpjv6VQ20YzZ6lW2RD7PkOW6Yc+7TCHIjt+IrVSvW1MNnbNEGwQAiOTXZT Q+ndwdF0fgNiW1w9nM8AjZmNm9o3jqS+frOK9cnSvzei+dkQrH6lJWggFzBFUflk BwqvGxMu6MEZcCbtkeyDj/SxIGQHsetGLeJY2r72r9jueja3buzOTUbVLexIsMCt MZsSBwJEkuFduYDTusfeeVr59LVNDw5bUHajmXHhRYODTqJeoeg3x7oYDUbSrOAv VOEfd0KMewtvBZ3m2ziM5Dzbqp4WFX3YI3B/s5XAebU6/iELqp8TYVXcAw8XMJOT bT1evQbsh7XyjCXPbPWg =RG8D -----END PGP SIGNATURE----- --Sig_/s8m7xa4e6/X6CbbmS/VzeYv-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 29 08:30:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC16F106566B for ; Tue, 29 Nov 2011 08:30:54 +0000 (UTC) (envelope-from dikshie@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id A5B568FC0C for ; Tue, 29 Nov 2011 08:30:53 +0000 (UTC) Received: by eekc13 with SMTP id c13so1361379eek.13 for ; Tue, 29 Nov 2011 00:30:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=wJPeLnYBkFie37IIHi1JPOa+ANd2+NFAEB5ydCJqZUo=; b=jieWooouf4BtiCC+LcvCsEBZa230KXI9llWJGJaaYtgFcEz5L1u79BISzR9/fv2HQB q4opWRX7Erat1mznL4kEiGGB19xl0iyBKPiBIbiGA/VfJnefxWGVWH2jw6zTBYHb5ntv 4BW9s+uC9lRyIhiHVVZLdPT7eq28waqq8fJ/k= Received: by 10.227.204.75 with SMTP id fl11mr30348326wbb.21.1322553947180; Tue, 29 Nov 2011 00:05:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.133.201 with HTTP; Tue, 29 Nov 2011 00:05:06 -0800 (PST) From: dikshie Date: Tue, 29 Nov 2011 17:05:06 +0900 Message-ID: To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: FreeBSD 9.0-PRERELEASE panic 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, 29 Nov 2011 08:30:54 -0000 Hi, can some enlighten me what's happen in my FreeBSD-9.0 box. thanks! -dikshie- sfc-monitor.ai3.net dumped core - see /var/crash/vmcore.5 Mon Nov 28 18:52:28 JST 2011 FreeBSD sfc-monitor.ai3.net 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #32: Mon Nov 28 15:59:44 JST 2011 dikshie@sfc-monitor.ai3.net:/usr/obj/usr/src/sys/MONITOR amd64 panic: page fault 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 "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 06 fault virtual address = 0x7a fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff808a0871 stack pointer = 0x28:0xffffff8344ee2870 frame pointer = 0x28:0xffffff8344ee2940 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 17 (syncer) trap number = 12 panic: page fault cpuid = 2 KDB: stack backtrace: #0 0xffffffff8067d30e at kdb_backtrace+0x5e #1 0xffffffff80647ec7 at panic+0x187 #2 0xffffffff8092bbb0 at trap_fatal+0x290 #3 0xffffffff8092bef9 at trap_pfault+0x1f9 #4 0xffffffff8092c3bf at trap+0x3df #5 0xffffffff809168ef at calltrap+0x8 #6 0xffffffff80877657 at ffs_syncvnode+0x1e7 #7 0xffffffff80871dd6 at ffs_sync+0x266 #8 0xffffffff806e94aa at sync_fsync+0x16a #9 0xffffffff806e9eee at sync_vnode+0x15e #10 0xffffffff806ea1e1 at sched_sync+0x1d1 #11 0xffffffff8061abff at fork_exit+0x11f #12 0xffffffff80916e1e at fork_trampoline+0xe Uptime: 2h37m40s Dumping 564 out of 8174 MB:..3%..12%..23%..32%..43%..52%..63%..71%..83%..91% Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/cc_cubic.ko...Reading symbols from /boot/kernel/cc_cubic.ko.symbols...done. done. Loaded symbols for /boot/kernel/cc_cubic.ko Reading symbols from /boot/kernel/cc_htcp.ko...Reading symbols from /boot/kernel/cc_htcp.ko.symbols...done. done. Loaded symbols for /boot/kernel/cc_htcp.ko #0 doadump (textdump=Variable "textdump" is not available. ) at pcpu.h:224 224 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=Variable "textdump" is not available. ) at pcpu.h:224 #1 0xffffffff80647a05 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:442 #2 0xffffffff80647eb1 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:607 #3 0xffffffff8092bbb0 in trap_fatal (frame=0xc, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:819 #4 0xffffffff8092bef9 in trap_pfault (frame=0xffffff8344ee27c0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:735 #5 0xffffffff8092c3bf in trap (frame=0xffffff8344ee27c0) at /usr/src/sys/amd64/amd64/trap.c:474 #6 0xffffffff809168ef in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #7 0xffffffff808a0871 in vm_object_pip_add (object=0x0, i=1) at /usr/src/sys/vm/vm_object.c:318 #8 0xffffffff806d4ead in cluster_wbuild (vp=0xfffffe0007921780, size=16384, start_lbn=0, len=2) at /usr/src/sys/kern/vfs_cluster.c:936 #9 0xffffffff80877657 in ffs_syncvnode (vp=0xfffffe0007921780, waitfor=3) at /usr/src/sys/ufs/ffs/ffs_vnops.c:288 #10 0xffffffff80871dd6 in ffs_sync (mp=0xfffffe00078cb600, waitfor=3) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1495 #11 0xffffffff806e94aa in sync_fsync (ap=Variable "ap" is not available. ) at /usr/src/sys/kern/vfs_subr.c:3545 #12 0xffffffff806e9eee in sync_vnode (slp=0xfffffe000705b870, bo=0xffffff8344ee2bc0, td=0xfffffe000713e460) at vnode_if.h:549 #13 0xffffffff806ea1e1 in sched_sync () at /usr/src/sys/kern/vfs_subr.c:1872 #14 0xffffffff8061abff in fork_exit (callout=0xffffffff806ea010 , arg=0x0, frame=0xffffff8344ee2c50) at /usr/src/sys/kern/kern_fork.c:995 #15 0xffffffff80916e1e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:602 #16 0x0000000000000000 in ?? () #17 0x0000000000000000 in ?? () #18 0x0000000000000001 in ?? () #19 0x0000000000000000 in ?? () #20 0x0000000000000000 in ?? () #21 0x0000000000000000 in ?? () #22 0x0000000000000000 in ?? () #23 0x0000000000000000 in ?? () #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000000 in ?? () #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000000000 in ?? () #37 0x0000000000000000 in ?? () #38 0x0000000000000000 in ?? () #39 0x0000000000000000 in ?? () #40 0xffffffff80dc8a00 in affinity () #41 0x0000000000000000 in ?? () #42 0x0000000000000000 in ?? () #43 0xfffffe000713e460 in ?? () #44 0xffffff8344ee1ba0 in ?? () #45 0xffffff8344ee1b48 in ?? () #46 0xfffffe00069838c0 in ?? () #47 0xffffffff8066fed2 in sched_switch (td=0xffffffff806ea010, newtd=0x0, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1848 Previous frame inner to this frame (corrupt stack?) (kgdb) ------------------------------------------------------------------------ ps -axl UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 0 0 0 -8 0 0 0 - DLs ?? 0:26.80 [kernel] 0 1 0 0 52 0 6280 0 wait DLs ?? 0:00.03 [init] 0 2 0 0 -8 0 0 0 tx->tx DL ?? 0:00.70 [zfskern] 0 3 0 0 -16 0 0 0 waitin DL ?? 0:00.00 [sctp_ite 0 4 0 0 -16 0 0 0 ccb_sc DL ?? 0:00.00 [xpt_thrd 0 5 0 0 -16 0 0 0 psleep DL ?? 0:00.01 [pagedaem 0 6 0 0 -16 0 0 0 psleep DL ?? 0:00.00 [vmdaemon 0 7 0 0 26 0 0 0 pollid DL ?? 0:00.01 [idlepoll 0 8 0 0 155 0 0 0 pgzero DL ?? 0:00.00 [pagezero 0 9 0 0 -16 0 0 0 - RL ?? 0:00.05 [bufdaemo 0 10 0 0 -16 0 0 0 audit_ DL ?? 0:00.00 [audit] 0 11 0 0 155 0 0 0 - RL ?? 572:52.60 [idle] 0 12 0 0 -76 0 0 0 - WL ?? 0:12.56 [intr] 0 13 0 0 -8 0 0 0 - DL ?? 0:02.96 [geom] 0 14 0 0 -16 0 0 0 - DL ?? 0:03.38 [yarrow] 0 15 0 0 -68 0 0 0 - DL ?? 0:00.18 [usb] 0 16 0 0 -16 0 0 0 vlruwt DL ?? 0:00.06 [vnlru] 0 17 0 0 16 0 0 0 - RL ?? 0:01.64 [syncer] 0 18 0 0 -16 0 0 0 sdflus DL ?? 0:00.16 [softdepf 0 976 1 0 20 0 10372 0 select Ds ?? 0:00.00 [devd] 0 1148 1 0 20 0 12184 0 select Ds ?? 0:00.29 [syslogd] 53 1237 1 0 20 0 137764 0 - Rs ?? 0:14.58 [named] 0 1349 1 0 20 0 107204 0 - Rs ?? 0:01.64 [varnishn 0 1354 1 0 20 0 107204 0 - Rs ?? 0:01.76 [varnishl 0 1365 1 0 20 0 107300 0 select Ds ?? 0:00.26 [varnishd 80 1366 1365 0 20 0 3855676 0 sbwait D ?? 0:02.22 [varnishd 0 1380 1 0 20 0 42804 0 select Ds ?? 0:00.27 [snmptrap 0 1386 1 0 20 0 40720 0 - R ?? 0:04.36 [snmpd] 0 1447 1 0 20 0 22332 0 select Ds ?? 0:00.43 [ntpd] 0 1492 1 0 52 0 10068 0 select Ds ?? 0:00.00 [rsync] 0 1500 1 0 20 0 169072 0 select Ds ?? 0:02.17 [php-fpm] 80 1501 1500 0 20 0 173168 0 select D ?? 0:00.13 [php-fpm] 80 1502 1500 0 20 0 173168 0 select D ?? 0:00.11 [php-fpm] 80 1503 1500 0 4 0 173168 0 - R ?? 0:00.14 [php-fpm] 80 1504 1500 0 20 0 173168 0 - R ?? 0:00.13 [php-fpm] 80 1505 1500 0 21 0 173168 0 - R ?? 0:00.19 [php-fpm] 80 1506 1500 0 21 0 173168 0 select D ?? 0:00.12 [php-fpm] 80 1507 1500 0 52 0 169072 0 accept D ?? 0:00.00 [php-fpm] 80 1509 1500 0 52 0 169072 0 accept D ?? 0:00.00 [php-fpm] 80 1510 1500 0 52 0 169072 0 accept D ?? 0:00.00 [php-fpm] 80 1511 1500 0 52 0 169072 0 accept D ?? 0:00.00 [php-fpm] 80 1512 1500 0 52 0 169072 0 accept D ?? 0:00.00 [php-fpm] 80 1514 1500 0 52 0 169072 0 accept D ?? 0:00.00 [php-fpm] 80 1517 1500 0 52 0 169072 0 accept D ?? 0:00.00 [php-fpm] 80 1518 1500 0 52 0 169072 0 accept D ?? 0:00.00 [php-fpm] 80 1519 1500 0 52 0 169072 0 accept D ?? 0:00.00 [php-fpm] 80 1520 1500 0 52 0 169072 0 accept D ?? 0:00.00 [php-fpm] 80 1521 1500 0 52 0 169072 0 accept D ?? 0:00.00 [php-fpm] 80 1522 1500 0 52 0 169072 0 accept D ?? 0:00.00 [php-fpm] 80 1523 1500 0 52 0 169072 0 accept D ?? 0:00.00 [php-fpm] 80 1524 1500 0 52 0 169072 0 accept D ?? 0:00.00 [php-fpm] 65534 1526 1 0 20 0 249488 0 nanslp Ds ?? 0:42.04 [ntop] 0 1531 1 0 20 0 46876 0 select Ds ?? 0:00.00 [sshd] 80 1540 1 0 20 0 30844 0 - R ?? 0:01.72 [nfcapd] 80 1542 1 0 26 0 178264 0 nanslp Ds ?? 0:13.88 [perl] 80 1543 1542 0 20 0 175928 0 accept Ds ?? 0:00.40 [perl] 88 1553 1 0 52 0 14636 0 wait Ds ?? 0:00.01 [sh] 88 1602 1553 0 20 0 159864 0 sbwait D ?? 0:40.78 [mysqld] 80 1610 1 0 20 0 43476 0 - R ?? 0:00.24 [lighttpd 0 1669 1 0 20 0 20384 0 select Ds ?? 0:00.28 [sendmail 25 1673 1 0 20 0 20384 0 pause Ds ?? 0:00.00 [sendmail 0 1680 1 0 52 0 14260 0 nanslp Ds ?? 0:00.57 [cron] 0 1763 1 0 52 0 12184 0 ttyin Ds+ ?? 0:00.01 [getty] 0 1764 1 0 52 0 12184 0 ttyin Ds+ ?? 0:00.00 [getty] 0 1765 1 0 52 0 12184 0 ttyin Ds+ ?? 0:00.00 [getty] 0 1766 1 0 52 0 12184 0 ttyin Ds+ ?? 0:00.01 [getty] 0 1767 1 0 52 0 12184 0 ttyin Ds+ ?? 0:00.00 [getty] 0 1768 1 0 52 0 12184 0 ttyin Ds+ ?? 0:00.01 [getty] 0 1769 1 0 52 0 12184 0 ttyin Ds+ ?? 0:00.00 [getty] 0 1770 1 0 52 0 12184 0 ttyin Ds+ ?? 0:00.00 [getty] ------------------------------------------------------------------------ vmstat -s 14621238 cpu context switches 3031243 device interrupts 1849771 software interrupts 6481756 traps 39588038 system calls 18 kernel threads created 16357 fork() calls 2331 vfork() calls 1 rfork() calls 0 swap pager pageins 0 swap pager pages paged in 0 swap pager pageouts 0 swap pager pages paged out 7261 vnode pager pageins 72647 vnode pager pages paged in 20687 vnode pager pageouts 23499 vnode pager pages paged out 0 page daemon wakeups 0 pages examined by the page daemon 14354 pages reactivated 1937433 copy-on-write faults 829 copy-on-write optimized faults 2239554 zero fill pages zeroed 0 zero fill pages prezeroed 4165 intransit blocking page faults 5850054 total VM faults taken 0 pages affected by kernel thread creation 6719661 pages affected by fork() 1279908 pages affected by vfork() 530 pages affected by rfork() 0 pages cached 5036244 pages freed 0 pages freed by daemon 0 pages freed by exiting processes 66947 pages active 30839 pages inactive 271 pages in VM cache 75721 pages wired down 1851296 pages free 4096 bytes per page 4526432 total name lookups cache hits (89% pos + 5% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% ------------------------------------------------------------------------ vmstat -m Type InUse MemUse HighUse Requests Size(s) loginclass 2 1K - 2182 64 UART 6 4K - 6 16,512,1024 ip6ndp 16 2K - 20 32,64,128 ip6opt 1 1K - 2346 32,256 temp 32 13K - 50492 16,32,64,128,256,512,1024,2048,4096 devbuf 18837 43165K - 18863 16,32,64,128,256,512,1024,2048,4096 kbdmux 6 18K - 6 16,512,1024,2048 module 391 49K - 391 128 LED 4 1K - 4 16,128 mtx_pool 2 16K - 2 osd 5 1K - 6 16,64 subproc 300 395K - 18938 512,4096 proc 2 16K - 2 session 30 4K - 2372 128 pgrp 30 4K - 2417 128 cred 94 15K - 838148 64,256 uidinfo 9 3K - 212 128,2048 plimit 14 4K - 28963 256 acpica 1344 129K - 38371 16,32,64,128,256,512,1024 sysctltmp 0 0K - 3504 16,32,64,128,4096 sysctloid 4137 204K - 4247 16,32,64,128 sysctl 0 0K - 12196 16,32,64 tidhash 1 16K - 1 callout 3 1536K - 3 umtx 1140 143K - 1140 128 p1003.1b 1 1K - 1 16 SWAP 2 1097K - 2 64 bus-sc 65 283K - 2825 16,32,128,256,512,1024,2048,4096 bus 976 85K - 5063 16,32,64,128,256,1024 devstat 10 21K - 10 32,4096 eventhandler 77 6K - 77 64,128 USBdev 20 7K - 20 64,128,1024 USB 35 12K - 35 16,32,128,2048 kobj 264 1056K - 324 4096 Per-cpu 1 1K - 1 32 acpitask 1 2K - 1 2048 CAM dev queue 7 1K - 7 128 rman 240 28K - 527 16,32,128 sbuf 0 0K - 910 16,32,64,128,256,512,1024,2048,4096 CAM queue 31 2K - 128 16,32,256 acpisem 20 3K - 20 128 stack 0 0K - 2 256 taskqueue 55 6K - 85 16,32,64,128,1024 Unitno 15 1K - 50051 32,64 iov 0 0K - 220097 16,64,128,256,512,1024 select 285 36K - 285 128 ioctlops 0 0K - 60417 16,32,64,128,256,512,1024 msg 4 30K - 4 2048,4096 sem 4 106K - 4 2048,4096 shm 2 22K - 2 2048 tty 19 19K - 23 1024,2048 pts 0 0K - 2 256 mbuf_tag 0 0K - 21203 32,128 ksem 1 8K - 1 shmfd 1 8K - 1 pcb 72 159K - 16368 16,32,128,1024,2048,4096 soname 7 1K - 216329 16,32,128 biobuf 4 8K - 6 2048 vfscache 1 2048K - 1 cl_savebuf 0 0K - 12 64,128 vfs_hash 1 1024K - 1 CAM SIM 7 2K - 7 256 vnodes 2 1K - 2 256 vnodemarker 1 1K - 3424 512 mount 84 4K - 167 16,32,64,128,256 BPF 14 10K - 62 16,64,128,512,4096 ether_multi 61 4K - 72 16,32,64 ifaddr 78 22K - 78 32,64,128,256,512,4096 ifnet 9 17K - 9 128,2048 clone 5 20K - 5 4096 arpcom 2 1K - 2 16 lltable 34 13K - 40 256,512 scsi_cd 0 0K - 4 16 CAM periph 12 3K - 34 16,32,64,128,256 CAM XPT 134 154K - 263 32,64,128,1024,2048 DEVFS1 110 55K - 120 512 DEVFS3 246 62K - 266 256 DEVFS2 110 2K - 110 16 routetbl 54 7K - 6872 32,64,128,256,512 igmp 8 2K - 8 256 DEVFS_RULE 54 26K - 54 64,512 DEVFS 48 1K - 49 16,128 in_multi 3 1K - 3 256 encap_export_host 2 2K - 2 1024 mroutetbl 1 1K - 1 16 sctp_iter 0 0K - 9 256 sctp_ifn 3 1K - 3 128 sctp_ifa 10 2K - 10 128 sctp_vrf 1 1K - 1 64 sctp_a_it 0 0K - 9 16 hostcache 1 28K - 1 syncache 1 96K - 1 fragment 0 0K - 12 64,128 DEVFSP 1 1K - 9 64 in6_multi 37 4K - 37 32,256 mld 8 1K - 8 128 NFS FHA 1 2K - 1 2048 rpc 2 9K - 2 256 audit_evclass 179 6K - 218 32 jblocks 6 2K - 6 128,256 savedino 0 0K - 253 256 sbdep 0 0K - 629 64 jsegdep 36 3K - 5837 64 jseg 18 3K - 1514 128 jfreefrag 0 0K - 68 128 jnewblk 0 0K - 2297 128 jremref 0 0K - 1726 128 jaddref 0 0K - 1746 128 freework 4 1K - 1871 16,128 newdirblk 0 0K - 6 64 dirrem 4 1K - 1714 128 mkdir 0 0K - 12 128 diradd 2 1K - 1734 128 freefile 0 0K - 1419 64 freeblks 3 1K - 1813 128 freefrag 2 1K - 68 128 indirdep 4 1K - 82 128 newblk 29 263K - 2298 256 bmsafemap 6 10K - 1871 256 inodedep 23 1035K - 4409 512 pagedep 6 258K - 1656 256 ufs_dirhash 84 16K - 84 16,32,64,128,256,512 ufs_mount 12 234K - 12 512,2048,4096 vm_pgdata 2 129K - 2 128 UMAHash 2 1K - 2 512 pfs_nodes 21 6K - 21 256 GEOM 100 28K - 619 16,32,64,128,256,512,1024,2048 ata_pci 1 1K - 1 64 memdesc 1 4K - 1 4096 acpidev 35 3K - 35 64 atkbddev 2 1K - 2 64 isadev 4 1K - 4 128 entropy 1024 64K - 1024 64 pci_link 16 2K - 16 32,64,128 cdev 8 2K - 8 256 sigio 1 1K - 1 64 filedesc_to_leader 1 1K - 2 64 filedesc 82 69K - 32870 16,32,64,128,512,1024,2048,4096 apmdev 1 1K - 1 128 kenv 115 13K - 131 16,32,64,128 kqueue 8 14K - 7058 64,256,512,2048 proc-args 52 4K - 19608 16,32,64,128,256 hhook 2 1K - 2 128 ithread 131 25K - 131 32,128,256 io_apic 3 6K - 3 2048 nexusdev 3 1K - 3 16 KTRACE 100 13K - 100 128 acpiintr 1 1K - 1 64 linker 140 13K - 151 16,32,64,128,512 lockf 40 5K - 52204 64,128 solaris 20930 62697K - 2438873 16,32,64,128,256,512,1024,2048,4096 kstat_data 4 1K - 4 64 ------------------------------------------------------------------------ vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 208, 0, 192, 12, 192, 0, 0 UMA Zones: 896, 0, 192, 0, 192, 0, 0 UMA Slabs: 568, 0, 2597, 14, 17538, 0, 0 UMA RCntSlabs: 568, 0, 4779, 2, 4779, 0, 0 UMA Hash: 256, 0, 79, 11, 81, 0, 0 16 Bucket: 152, 0, 144, 6, 144, 0, 0 32 Bucket: 280, 0, 162, 6, 162, 0, 0 64 Bucket: 536, 0, 139, 1, 139, 57, 0 128 Bucket: 1048, 0, 387, 0, 387,1168, 0 VM OBJECT: 216, 0, 3903, 2307, 637436, 0, 0 MAP: 232, 0, 7, 25, 7, 0, 0 KMAP ENTRY: 120, 277822, 61, 590, 49683, 0, 0 MAP ENTRY: 120, 0, 6329, 4056, 1518575, 0, 0 fakepg: 120, 0, 0, 0, 0, 0, 0 mt_zone: 4112, 0, 274, 5, 274, 0, 0 16: 16, 0, 2297, 559, 1015626, 0, 0 32: 32, 0, 2387, 542, 272151, 0, 0 64: 64, 0, 29735, 13889, 1032217, 0, 0 128: 128, 0, 4769, 741, 946694, 0, 0 256: 256, 0, 932, 4213, 786899, 0, 0 512: 512, 0, 894, 191, 51246, 0, 0 1024: 1024, 0, 80, 1232, 26502, 0, 0 2048: 2048, 0, 329, 139, 15696, 0, 0 4096: 4096, 0, 463, 286, 44550, 0, 0 Files: 80, 0, 311, 319, 524684, 0, 0 TURNSTILE: 136, 0, 571, 49, 571, 0, 0 umtx pi: 96, 0, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0, 0 PROC: 1160, 0, 69, 159, 18707, 0, 0 THREAD: 1112, 0, 476, 94, 1745, 0, 0 SLEEPQUEUE: 80, 0, 571, 96, 571, 0, 0 VMSPACE: 392, 0, 52, 158, 18691, 0, 0 cpuset: 72, 0, 2, 98, 2, 0, 0 audit_record: 960, 0, 0, 0, 0, 0, 0 mbuf_packet: 256, 0, 8224, 773, 4414695, 0, 0 mbuf: 256, 0, 64, 875, 1031219, 0, 0 mbuf_cluster: 2048, 229376, 8969, 589, 167946, 0, 0 mbuf_jumbo_page: 4096, 192000, 0, 0, 0, 0, 0 mbuf_jumbo_9k: 9216, 19200, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 12800, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 672, 2433, 0, 0 g_bio: 232, 0, 0, 432, 387914, 0, 0 ttyinq: 160, 0, 120, 120, 285, 0, 0 ttyoutq: 256, 0, 64, 56, 152, 0, 0 ata_request: 328, 0, 0, 36, 14, 0, 0 ata_composite: 336, 0, 0, 0, 0, 0, 0 taskq_zone: 48, 0, 0, 432, 342, 0, 0 VNODE: 480, 0, 2172, 132, 3602, 0, 0 VNODEPOLL: 112, 0, 0, 0, 0, 0, 0 S VFS Cache: 108, 0, 2086, 224, 211016, 0, 0 L VFS Cache: 328, 0, 114, 78, 134, 0, 0 NAMEI: 1024, 0, 0, 84, 1216120, 0, 0 DIRHASH: 1024, 0, 110, 34, 110, 0, 0 mqnode: 408, 0, 3, 15, 3, 0, 0 mqueue: 248, 0, 0, 0, 0, 0, 0 mvdata: 64, 0, 0, 0, 0, 0, 0 mqnotifier: 216, 0, 0, 0, 0, 0, 0 NFSMOUNT: 632, 0, 0, 0, 0, 0, 0 NFSNODE: 648, 0, 0, 0, 0, 0, 0 zio_cache: 880, 0, 2, 1134, 733303, 0, 0 zio_link_cache: 48, 0, 0, 2448, 179127, 0, 0 zio_buf_512: 512, 0, 0, 0, 0, 0, 0 zio_data_buf_512: 512, 0, 0, 0, 0, 0, 0 zio_buf_1024: 1024, 0, 0, 0, 0, 0, 0 zio_data_buf_1024: 1024, 0, 0, 0, 0, 0, 0 zio_buf_1536: 1536, 0, 0, 0, 0, 0, 0 zio_data_buf_1536: 1536, 0, 0, 0, 0, 0, 0 zio_buf_2048: 2048, 0, 0, 0, 0, 0, 0 zio_data_buf_2048: 2048, 0, 0, 0, 0, 0, 0 zio_buf_2560: 2560, 0, 0, 0, 0, 0, 0 zio_data_buf_2560: 2560, 0, 0, 0, 0, 0, 0 zio_buf_3072: 3072, 0, 0, 0, 0, 0, 0 zio_data_buf_3072: 3072, 0, 0, 0, 0, 0, 0 zio_buf_3584: 3584, 0, 0, 0, 0, 0, 0 zio_data_buf_3584: 3584, 0, 0, 0, 0, 0, 0 zio_buf_4096: 4096, 0, 0, 0, 0, 0, 0 zio_data_buf_4096: 4096, 0, 0, 0, 0, 0, 0 zio_buf_5120: 5120, 0, 0, 0, 0, 0, 0 zio_data_buf_5120: 5120, 0, 0, 0, 0, 0, 0 zio_buf_6144: 6144, 0, 0, 0, 0, 0, 0 zio_data_buf_6144: 6144, 0, 0, 0, 0, 0, 0 zio_buf_7168: 7168, 0, 0, 0, 0, 0, 0 zio_data_buf_7168: 7168, 0, 0, 0, 0, 0, 0 zio_buf_8192: 8192, 0, 0, 0, 0, 0, 0 zio_data_buf_8192: 8192, 0, 0, 0, 0, 0, 0 zio_buf_10240: 10240, 0, 0, 0, 0, 0, 0 zio_data_buf_10240: 10240, 0, 0, 0, 0, 0, 0 zio_buf_12288: 12288, 0, 0, 0, 0, 0, 0 zio_data_buf_12288: 12288, 0, 0, 0, 0, 0, 0 zio_buf_14336: 14336, 0, 0, 0, 0, 0, 0 zio_data_buf_14336: 14336, 0, 0, 0, 0, 0, 0 zio_buf_16384: 16384, 0, 0, 0, 0, 0, 0 zio_data_buf_16384: 16384, 0, 0, 0, 0, 0, 0 zio_buf_20480: 20480, 0, 0, 0, 0, 0, 0 zio_data_buf_20480: 20480, 0, 0, 0, 0, 0, 0 zio_buf_24576: 24576, 0, 0, 0, 0, 0, 0 zio_data_buf_24576: 24576, 0, 0, 0, 0, 0, 0 zio_buf_28672: 28672, 0, 0, 0, 0, 0, 0 zio_data_buf_28672: 28672, 0, 0, 0, 0, 0, 0 zio_buf_32768: 32768, 0, 0, 0, 0, 0, 0 zio_data_buf_32768: 32768, 0, 0, 0, 0, 0, 0 zio_buf_36864: 36864, 0, 0, 0, 0, 0, 0 zio_data_buf_36864: 36864, 0, 0, 0, 0, 0, 0 zio_buf_40960: 40960, 0, 0, 0, 0, 0, 0 zio_data_buf_40960: 40960, 0, 0, 0, 0, 0, 0 zio_buf_45056: 45056, 0, 0, 0, 0, 0, 0 zio_data_buf_45056: 45056, 0, 0, 0, 0, 0, 0 zio_buf_49152: 49152, 0, 0, 0, 0, 0, 0 zio_data_buf_49152: 49152, 0, 0, 0, 0, 0, 0 zio_buf_53248: 53248, 0, 0, 0, 0, 0, 0 zio_data_buf_53248: 53248, 0, 0, 0, 0, 0, 0 zio_buf_57344: 57344, 0, 0, 0, 0, 0, 0 zio_data_buf_57344: 57344, 0, 0, 0, 0, 0, 0 zio_buf_61440: 61440, 0, 0, 0, 0, 0, 0 zio_data_buf_61440: 61440, 0, 0, 0, 0, 0, 0 zio_buf_65536: 65536, 0, 0, 0, 0, 0, 0 zio_data_buf_65536: 65536, 0, 0, 0, 0, 0, 0 zio_buf_69632: 69632, 0, 0, 0, 0, 0, 0 zio_data_buf_69632: 69632, 0, 0, 0, 0, 0, 0 zio_buf_73728: 73728, 0, 0, 0, 0, 0, 0 zio_data_buf_73728: 73728, 0, 0, 0, 0, 0, 0 zio_buf_77824: 77824, 0, 0, 0, 0, 0, 0 zio_data_buf_77824: 77824, 0, 0, 0, 0, 0, 0 zio_buf_81920: 81920, 0, 0, 0, 0, 0, 0 zio_data_buf_81920: 81920, 0, 0, 0, 0, 0, 0 zio_buf_86016: 86016, 0, 0, 0, 0, 0, 0 zio_data_buf_86016: 86016, 0, 0, 0, 0, 0, 0 zio_buf_90112: 90112, 0, 0, 0, 0, 0, 0 zio_data_buf_90112: 90112, 0, 0, 0, 0, 0, 0 zio_buf_94208: 94208, 0, 0, 0, 0, 0, 0 zio_data_buf_94208: 94208, 0, 0, 0, 0, 0, 0 zio_buf_98304: 98304, 0, 0, 0, 0, 0, 0 zio_data_buf_98304: 98304, 0, 0, 0, 0, 0, 0 zio_buf_102400: 102400, 0, 0, 0, 0, 0, 0 zio_data_buf_102400: 102400, 0, 0, 0, 0, 0, 0 zio_buf_106496: 106496, 0, 0, 0, 0, 0, 0 zio_data_buf_106496: 106496, 0, 0, 0, 0, 0, 0 zio_buf_110592: 110592, 0, 0, 0, 0, 0, 0 zio_data_buf_110592: 110592, 0, 0, 0, 0, 0, 0 zio_buf_114688: 114688, 0, 0, 0, 0, 0, 0 zio_data_buf_114688: 114688, 0, 0, 0, 0, 0, 0 zio_buf_118784: 118784, 0, 0, 0, 0, 0, 0 zio_data_buf_118784: 118784, 0, 0, 0, 0, 0, 0 zio_buf_122880: 122880, 0, 0, 0, 0, 0, 0 zio_data_buf_122880: 122880, 0, 0, 0, 0, 0, 0 zio_buf_126976: 126976, 0, 0, 0, 0, 0, 0 zio_data_buf_126976: 126976, 0, 0, 0, 0, 0, 0 zio_buf_131072: 131072, 0, 0, 0, 0, 0, 0 zio_data_buf_131072: 131072, 0, 0, 0, 0, 0, 0 sa_cache: 80, 0, 190, 125, 193, 0, 0 dnode_t: 856, 0, 258, 30, 310, 0, 0 dmu_buf_impl_t: 224, 0, 757, 76, 2462, 0, 0 arc_buf_hdr_t: 216, 0, 1497, 87, 2277, 0, 0 arc_buf_t: 104, 0, 979, 101, 2308, 0, 0 zil_lwb_cache: 192, 0, 1, 99, 87, 0, 0 zfs_znode_cache: 400, 0, 190, 17, 193, 0, 0 pipe: 728, 0, 8, 117, 12448, 0, 0 AIO: 208, 0, 0, 0, 0, 0, 0 AIOP: 32, 0, 0, 0, 0, 0, 0 AIOCB: 480, 0, 0, 0, 0, 0, 0 AIOL: 128, 0, 0, 0, 0, 0, 0 AIOLIO: 272, 0, 0, 0, 0, 0, 0 Mountpoints: 768, 0, 7, 8, 7, 0, 0 ksiginfo: 112, 0, 218, 838, 2661, 0, 0 itimer: 344, 0, 1, 21, 1, 0, 0 KNOTE: 128, 0, 22, 239, 321460, 0, 0 socket: 680, 204804, 129, 117, 50689, 0, 0 unpcb: 240, 204800, 19, 173, 3117, 0, 0 ipq: 56, 7182, 0, 126, 124, 0, 0 udp_inpcb: 392, 204800, 21, 179, 42858, 0, 0 udpcb: 16, 204960, 21, 651, 42858, 0, 0 tcp_inpcb: 392, 204800, 118, 52, 2978, 0, 0 tcpcb: 976, 204800, 63, 65, 2978, 0, 0 tcptw: 72, 163850, 55, 245, 948, 0, 0 syncache: 152, 15375, 0, 125, 962, 0, 0 hostcache: 136, 15372, 2, 82, 8, 0, 0 tcpreass: 40, 14364, 0, 252, 54, 0, 0 sackhole: 32, 0, 0, 202, 60, 0, 0 sctp_ep: 1368, 25600, 0, 0, 0, 0, 0 sctp_asoc: 2280, 40000, 0, 0, 0, 0, 0 sctp_laddr: 48, 80064, 0, 288, 9, 0, 0 sctp_raddr: 704, 80000, 0, 0, 0, 0, 0 sctp_chunk: 136, 400008, 0, 0, 0, 0, 0 sctp_readq: 104, 400032, 0, 0, 0, 0, 0 sctp_stream_msg_out: 112, 400026, 0, 0, 0, 0, 0 sctp_asconf: 40, 400008, 0, 0, 0, 0, 0 sctp_asconf_ack: 48, 400032, 0, 0, 0, 0, 0 ripcb: 392, 204800, 0, 90, 1729, 0, 0 rtentry: 200, 0, 32, 63, 33, 0, 0 selfd: 56, 0, 349, 659, 516972, 0, 0 SWAPMETA: 288, 116519, 0, 0, 0, 0, 0 FFS inode: 168, 0, 1944, 124, 3364, 0, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 1944, 126, 3364, 0, 0 ------------------------------------------------------------------------ vmstat -i interrupt total rate irq1: atkbd0 6 0 irq15: ata1 20 0 irq16: uhci0 uhci3 118167 3029 irq32: mvs0 117893 3022 irq54: em0 159575 4091 irq55: em1 2635581 67579 cpu0:timer 10651553 273116 cpu1:timer 196594 5040 cpu3:timer 155513 3987 cpu2:timer 674606 17297 Total 14709508 377166 ------------------------------------------------------------------------ pstat -T 311/204800 files 0M/8191M swap space ------------------------------------------------------------------------ pstat -s Device 512-blocks Used Avail Capacity /dev/ada0s1b 16776960 0 16776960 0% ------------------------------------------------------------------------ iostat iostat: kvm_read(_tk_nin): invalid address (0x0) iostat: disabling TTY statistics ada0 ada1 ada2 cpu KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 17.66 1908 32.90 5.84 363 2.07 6.05 351 2.07 1 0 1 0 99 ------------------------------------------------------------------------ ipcs -a Message Queues: T ID KEY MODE OWNER GROUP CREATOR CGROUP CBYTES QNUM QBYTES LSPID LRPID STIME RTIME CTIME Shared Memory: T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME m 65536 -1949363355 --rw------- www www www www 1 64 1540 1540 16:13:03 no-entry 16:13:03 Semaphores: T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIME s 65536 -1949363354 --rw------- www www www www 1 18:50:00 16:13:03 s 65537 0 --rw------- www www www www 1 18:50:16 16:13:05 ------------------------------------------------------------------------ ipcs -T msginfo: msgmax: 16384 (max characters in a message) msgmni: 40 (# of message queues) msgmnb: 2048 (max characters in a message queue) msgtql: 40 (max # of messages in system) msgssz: 8 (size of a message segment) msgseg: 2048 (# of message segments in system) shminfo: shmmax: 536870912 (max shared memory segment size) shmmin: 1 (min shared memory segment size) shmmni: 192 (max number of shared memory identifiers) shmseg: 128 (max shared memory segments per process) shmall: 131072 (max amount of shared memory in pages) seminfo: semmni: 50 (# of semaphore identifiers) semmns: 340 (# of semaphores in system) semmnu: 150 (# of undo structures in system) semmsl: 340 (max # of semaphores per id) semopm: 100 (max # of operations per semop call) semume: 50 (max # of undo entries per process) semusz: 632 (size in bytes of undo structure) semvmx: 32767 (semaphore maximum value) semaem: 16384 (adjust on exit max value) ------------------------------------------------------------------------ nfsstat nfsstat: new client/server not loaded ------------------------------------------------------------------------ netstat -s tcp: 277739 packets sent 266944 data packets (77870226 bytes) 171 data packets (237011 bytes) retransmitted 5 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 6698 ack-only packets (734 delayed) 0 URG only packets 0 window probe packets 491 window update packets 3436 control packets 277836 packets received 266064 acks (for 77867734 bytes) 2069 duplicate acks 0 acks for unsent data 265674 packets (72569243 bytes) received in-sequence 2 completely duplicate packets (0 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 54 out-of-order packets (60804 bytes) 0 packets (0 bytes) of data after window 0 window probes 50 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 7 discarded due to memory problems 1673 connection requests 952 connection accepts 0 bad connection attempts 0 listen queue overflows 2 ignored RSTs in the windows 1836 connections established (including accepts) 2860 connections closed (including 5 drops) 1641 connections updated cached RTT on close 1641 connections updated cached RTT variance on close 7 connections updated cached ssthresh on close 789 embryonic connections dropped 266056 segments updated rtt (of 264629 attempts) 10 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 3038 correct ACK header predictions 5953 correct data packet header predictions 962 syncache entries added 11 retransmitted 3 dupsyn 0 dropped 952 completed 0 bucket overflow 0 cache overflow 8 reset 2 stale 0 aborted 0 badack 0 unreach 0 zone failures 962 cookies sent 0 cookies received 8 hostcache entries added 0 bucket overflow 48 SACK recovery episodes 158 segment rexmits in SACK recovery episodes 222544 byte rexmits in SACK recovery episodes 754 SACK options (SACK blocks) received 54 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window udp: 103073 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 85 with no checksum 280 dropped due to no socket 193 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 102600 delivered 54152 datagrams output 0 times multicast source filter matched ip: 383261 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 349 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 124 packets reassembled ok 382100 packets for this host 936 packets for unknown/unsupported protocol 0 packets forwarded (0 packets fast forwarded) 0 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 333546 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 22 output packets discarded due to no route 67 output datagrams fragmented 134 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header icmp: 276 calls to icmp_error 0 errors not generated in response to an icmp message Output histogram: echo reply: 379 destination unreachable: 276 0 messages with bad code fields 0 messages less than the minimum length 0 messages with bad checksum 0 messages with bad length 0 multicast echo requests ignored 0 multicast timestamp requests ignored Input histogram: echo reply: 2295 destination unreachable: 1161 routing redirect: 4 echo: 379 time exceeded: 25 379 message responses generated 0 invalid return addresses 0 no return routes igmp: 232 messages received 0 messages received with too few bytes 0 messages received with wrong TTL 0 messages received with bad checksum 75 V1/V2 membership queries received 157 V3 membership queries received 0 membership queries received with invalid field(s) 232 general queries received 0 group queries received 0 group-source queries received 0 group-source queries dropped 0 membership reports received 0 membership reports received with invalid field(s) 0 membership reports received for groups to which we belong 0 V3 reports received without Router Alert 0 membership reports sent pim: 0 messages received 0 bytes received 0 messages received with too few bytes 0 messages received with bad checksum 0 messages received with bad version 0 data register messages received 0 data register bytes received 0 data register messages received on wrong iif 0 bad registers received 0 data register messages sent 0 data register bytes sent arp: 31 ARP requests sent 252 ARP replies sent 1330 ARP requests received 29 ARP replies received 1359 ARP packets received 6 total packets dropped due to no ARP entry 6 ARP entrys timed out 0 Duplicate IPs seen ip6: 5911 total packets received 0 with size smaller than minimum 0 with data size < data length 0 with bad options 0 with incorrect version number 8 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 fragments that exceeded limit 4 packets reassembled ok 4947 packets for this host 0 packets forwarded 0 packets not forwardable 0 redirects sent 5880 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 1 output datagram fragmented 2 fragments created 0 datagrams that can't be fragmented 0 packets that violated scope rules 152 multicast packets which we don't join Input histogram: hop by hop: 301 TCP: 592 UDP: 1373 fragment: 8 ICMP6: 3637 Mbuf statistics: 1 one mbuf 383122 one ext mbuf 0 two or more ext mbuf 0 packets whose headers are not contiguous 0 tunneling packets that can't find gif 0 packets discarded because of too many headers 0 failures of source address selection Source addresses selection rule applied: 5596 first candidate 160 same address 6231 appropriate scope icmp6: 4 calls to icmp6_error 0 errors not generated in response to an icmp6 message 0 errors not generated because of rate limitation Output histogram: unreach: 4 echo: 2826 echo reply: 5 MLDv1 listener report: 225 router solicitation: 1 neighbor solicitation: 278 neighbor advertisement: 362 MLDv2 listener report: 3 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length Input histogram: unreach: 72 echo: 5 echo reply: 2821 multicast listener query: 150 router advertisement: 102 neighbor solicitation: 362 neighbor advertisement: 274 Histogram of error messages to be generated: 0 no route 0 administratively prohibited 0 beyond scope 0 address unreachable 4 port unreachable 0 packet too big 0 time exceed transit 0 time exceed reassembly 0 erroneous header field 0 unrecognized next header 0 unrecognized option 0 redirect 0 unknown 5 message responses generated 0 messages with too many ND options 0 messages with bad ND options 0 bad neighbor solicitation messages 0 bad neighbor advertisement messages 0 bad router solicitation messages 0 bad router advertisement messages 0 bad redirect messages 0 path MTU changes rip6: 0 messages received 0 checksum calculations on inbound 0 messages with bad checksum 0 messages dropped due to no socket 0 multicast messages dropped due to no socket 0 messages dropped due to full socket buffers 0 delivered 0 datagrams output ------------------------------------------------------------------------ netstat -m 8288/1648/9936 mbufs in use (current/cache/total) 8196/1362/9558/229376 mbuf clusters in use (current/cache/total/max) 8224/773 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/192000 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/19200 9k jumbo clusters in use (current/cache/total/max) 0/0/0/12800 16k jumbo clusters in use (current/cache/total/max) 18464K/3136K/21600K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines ------------------------------------------------------------------------ netstat -id Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop em0 1500 00:30:48:30:39:d8 116811 0 0 66211 0 0 0 em0 1500 202.249.25.0/ 202.249.25.27 67735 - - 59985 - - - em0 1500 fe80::230:48f fe80::230:48ff:fe 442 - - 865 - - - em0 1500 2001:d30:101: 2001:d30:101:1::1 4491 - - 4263 - - - em0 1500 2001:d30:101: 2001:d30:101:1:23 573 - - 745 - - - em1 1500 00:30:48:30:39:d9 4281375 0 0 1 0 0 0 em1 1500 192.168.0.10/ 192.168.0.10 0 - - 0 - - - em1 1500 fe80::230:48f fe80::230:48ff:fe 0 - - 0 - - - usbus 0 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 lo0 16384 273647 0 0 273647 0 0 0 lo0 16384 localhost ::1 0 - - 0 - - - lo0 16384 fe80::1%lo0 fe80::1 0 - - 0 - - - lo0 16384 your-net localhost 273650 - - 273644 - - - lo0 16384 202.249.24.34 202.249.24.34 41291 - - 0 - - - ------------------------------------------------------------------------ netstat -anr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 202.249.25.1 UGS 0 51188 em0 127.0.0.1 link#8 UH 0 273650 lo0 192.168.0.10 link#2 UHS 0 0 lo0 => 192.168.0.10/32 link#2 U 0 0 em1 202.249.24.34 link#8 UH 0 0 lo0 202.249.25.0/27 link#1 U 0 7734 em0 202.249.25.27 link#1 UHS 0 0 lo0 202.249.25.242 202.249.25.10 UGHD3 0 119 em0 13008 202.249.25.243 202.249.25.10 UGHD3 0 185 em0 13008 202.249.25.245 202.249.25.10 UGHD3 0 383 em0 13006 202.249.25.248 202.249.25.10 UGHD3 0 383 em0 13008 Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 => default fe80::20e:38ff:fe61:db1b%em0 UG em0 ::1 ::1 UH lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 2001:d30:101:1::/64 link#1 U em0 2001:d30:101:1::11 link#1 UHS lo0 2001:d30:101:1:230:48ff:fe30:39d8 link#1 UHS lo0 fe80::/10 ::1 UGRS lo0 fe80::%em0/64 link#1 U em0 fe80::230:48ff:fe30:39d8%em0 link#1 UHS lo0 fe80::%em1/64 link#2 U em1 fe80::230:48ff:fe30:39d9%em1 link#2 UHS lo0 fe80::%lo0/64 link#8 U lo0 fe80::1%lo0 link#8 UHS lo0 ff01::%em0/32 fe80::230:48ff:fe30:39d8%em0 U em0 ff01::%em1/32 fe80::230:48ff:fe30:39d9%em1 U em1 ff01::%lo0/32 ::1 U lo0 ff02::/16 ::1 UGRS lo0 ff02::%em0/32 fe80::230:48ff:fe30:39d8%em0 U em0 ff02::%em1/32 fe80::230:48ff:fe30:39d9%em1 U em1 ff02::%lo0/32 ::1 U lo0 ------------------------------------------------------------------------ netstat -anA Active Internet connections (including servers) Tcpcb Proto Recv-Q Send-Q Local Address Foreign Address (state) fffffe011fe463d0 tcp4 8 0 127.0.0.1.9000 127.0.0.1.35447 ESTABLISHED fffffe011f3867a0 tcp4 0 0 127.0.0.1.35447 127.0.0.1.9000 ESTABLISHED fffffe011fcd1b70 tcp4 8 0 127.0.0.1.9000 127.0.0.1.35446 ESTABLISHED fffffe011f73b3d0 tcp4 0 0 127.0.0.1.35446 127.0.0.1.9000 ESTABLISHED fffffe01a9056b70 tcp4 8 0 127.0.0.1.9000 127.0.0.1.35445 ESTABLISHED fffffe00a0071000 tcp4 0 0 127.0.0.1.35445 127.0.0.1.9000 ESTABLISHED fffffe000796c7a0 tcp4 8 0 127.0.0.1.9000 127.0.0.1.35444 ESTABLISHED fffffe011fcd17a0 tcp4 0 0 127.0.0.1.35444 127.0.0.1.9000 ESTABLISHED fffffe011f3863d0 tcp4 8 0 127.0.0.1.9000 127.0.0.1.35443 ESTABLISHED fffffe011f3847a0 tcp4 0 0 127.0.0.1.35443 127.0.0.1.9000 ESTABLISHED fffffe011f818000 tcp4 8 0 127.0.0.1.9000 127.0.0.1.35442 ESTABLISHED fffffe0048ff27a0 tcp4 0 0 127.0.0.1.35442 127.0.0.1.9000 ESTABLISHED fffffe011f9167a0 tcp4 0 0 127.0.0.1.80 127.0.0.1.35441 ESTABLISHED fffffe011f0d5000 tcp4 0 0 127.0.0.1.35441 127.0.0.1.80 ESTABLISHED fffffe011f209a68 tcp4 0 0 127.0.0.1.9000 127.0.0.1.35440 TIME_WAIT fffffe011f3873d0 tcp4 0 2151 127.0.0.1.3306 127.0.0.1.35438 ESTABLISHED fffffe011f52a3d0 tcp4 2151 0 127.0.0.1.35438 127.0.0.1.3306 ESTABLISHED fffffe011f2095a0 tcp4 0 0 127.0.0.1.9000 127.0.0.1.35437 TIME_WAIT fffffe011f387000 tcp4 0 0 127.0.0.1.80 127.0.0.1.35436 ESTABLISHED fffffe011fcd0000 tcp4 0 0 127.0.0.1.35436 127.0.0.1.80 ESTABLISHED fffffe011fcd0b70 tcp4 0 0 127.0.0.1.80 127.0.0.1.35435 ESTABLISHED fffffe011f73b7a0 tcp4 0 0 127.0.0.1.35435 127.0.0.1.80 ESTABLISHED fffffe011f387b70 tcp4 0 0 127.0.0.1.80 127.0.0.1.35434 ESTABLISHED fffffe0048ff2b70 tcp4 0 0 127.0.0.1.35434 127.0.0.1.80 ESTABLISHED fffffe01a90563d0 tcp4 0 0 127.0.0.1.3306 127.0.0.1.35433 ESTABLISHED fffffe011f3877a0 tcp4 0 0 127.0.0.1.35433 127.0.0.1.3306 ESTABLISHED fffffe011f149120 tcp4 0 0 127.0.0.1.9000 127.0.0.1.35432 TIME_WAIT fffffe011ffd2000 tcp4 0 0 127.0.0.1.3306 127.0.0.1.35431 ESTABLISHED fffffe011f8183d0 tcp4 0 0 127.0.0.1.35431 127.0.0.1.3306 ESTABLISHED fffffe011f66ca20 tcp4 0 0 127.0.0.1.9000 127.0.0.1.35430 TIME_WAIT fffffe011ffd23d0 tcp4 0 0 127.0.0.1.80 127.0.0.1.35429 ESTABLISHED fffffe011f3853d0 tcp4 0 0 127.0.0.1.35429 127.0.0.1.80 ESTABLISHED fffffe011ffd27a0 tcp6 0 0 2001:d30:101:1:2.8 2001:200:0:8801:.5 ESTABLISHED fffffe011ffd2b70 tcp6 0 0 2001:d30:101:1:2.8 2001:200:0:8801:.5 ESTABLISHED fffffe01a9251000 tcp6 0 0 2001:d30:101:1:2.8 2001:200:0:8801:.5 ESTABLISHED fffffe01a9056000 tcp4 0 0 127.0.0.1.80 127.0.0.1.35428 ESTABLISHED fffffe01a92513d0 tcp4 0 0 127.0.0.1.35428 127.0.0.1.80 ESTABLISHED fffffe01a92517a0 tcp6 0 0 2001:d30:101:1:2.8 2001:200:0:8801:.5 ESTABLISHED fffffe01a9251b70 tcp6 0 0 2001:d30:101:1:2.8 2001:200:0:8801:.5 ESTABLISHED fffffe00a006ab70 tcp4 0 114 127.0.0.1.3306 127.0.0.1.35427 ESTABLISHED fffffe011f384b70 tcp4 0 293 127.0.0.1.35427 127.0.0.1.3306 ESTABLISHED fffffe011f149678 tcp4 0 0 127.0.0.1.9000 127.0.0.1.35426 TIME_WAIT fffffe00a00723d0 tcp4 926 0 127.0.0.1.3306 127.0.0.1.35425 ESTABLISHED fffffe011f0d57a0 tcp4 0 926 127.0.0.1.35425 127.0.0.1.3306 ESTABLISHED fffffe011f209798 tcp4 0 0 127.0.0.1.9000 127.0.0.1.35424 TIME_WAIT fffffe011fcd03d0 tcp4 80 0 127.0.0.1.3306 127.0.0.1.35423 ESTABLISHED fffffe011f385000 tcp4 0 80 127.0.0.1.35423 127.0.0.1.3306 ESTABLISHED fffffe011f99fcf0 tcp4 0 0 127.0.0.1.9000 127.0.0.1.35422 TIME_WAIT fffffe011f66cd38 tcp4 0 0 127.0.0.1.9000 127.0.0.1.35421 TIME_WAIT fffffe011f66c948 tcp4 0 0 127.0.0.1.9000 127.0.0.1.35420 TIME_WAIT fffffe011f209750 tcp4 0 0 127.0.0.1.9000 127.0.0.1.35419 TIME_WAIT fffffe011f99f828 tcp4 0 0 127.0.0.1.9000 127.0.0.1.35418 TIME_WAIT fffffe011f99f7e0 tcp4 0 0 127.0.0.1.9000 127.0.0.1.35417 TIME_WAIT fffffe011f209ca8 tcp4 0 0 127.0.0.1.9000 127.0.0.1.35416 TIME_WAIT fffffe011f552168 tcp4 0 0 127.0.0.1.9000 127.0.0.1.35415 TIME_WAIT fffffe011f209c60 tcp4 0 0 127.0.0.1.9000 127.0.0.1.35414 TIME_WAIT fffffe011f99f750 tcp4 0 0 127.0.0.1.80 127.0.0.1.35413 TIME_WAIT fffffe011f66c990 tcp4 0 0 127.0.0.1.80 127.0.0.1.35412 TIME_WAIT fffffe011fd477a0 tcp6 0 0 2001:d30:101:1:2.8 2001:200:0:8801:.5 ESTABLISHED fffffe011f149288 tcp6 0 0 2001:d30:101:1:2.8 2001:200:0:8801:.5 TIME_WAIT fffffe011f14a870 tcp4 0 0 127.0.0.1.9000 127.0.0.1.35411 TIME_WAIT fffffe011f1498b8 tcp4 0 0 127.0.0.1.80 127.0.0.1.35410 TIME_WAIT fffffe011f66c2d0 tcp4 0 0 127.0.0.1.9000 127.0.0.1.35409 TIME_WAIT fffffe011f66c288 tcp4 0 0 127.0.0.1.9000 127.0.0.1.35408 TIME_WAIT fffffe011f66c240 tcp4 0 0 127.0.0.1.9000 127.0.0.1.35407 TIME_WAIT fffffe011f99f708 tcp4 0 0 127.0.0.1.80 127.0.0.1.35406 TIME_WAIT fffffe011f149630 tcp4 0 0 127.0.0.1.80 127.0.0.1.35405 TIME_WAIT fffffe011f14a4c8 tcp4 0 0 127.0.0.1.9000 127.0.0.1.35404 TIME_WAIT fffffe011f99fa20 tcp4 0 0 127.0.0.1.80 127.0.0.1.35403 TIME_WAIT fffffe011f209000 tcp4 0 0 127.0.0.1.35403 127.0.0.1.80 TIME_WAIT fffffe011f5523a8 tcp6 0 0 2001:d30:101:1:2.8 2001:200:0:8801:.5 TIME_WAIT fffffe011f14a510 tcp6 0 0 2001:d30:101:1:2.8 2001:200:0:8801:.5 TIME_WAIT fffffe011f99f1b0 tcp6 0 0 2001:d30:101:1:2.8 2001:200:0:8801:.5 TIME_WAIT fffffe011f149af8 tcp6 0 0 2001:d30:101:1:2.8 2001:200:0:8801:.5 TIME_WAIT fffffe011f209d38 tcp4 0 0 127.0.0.1.35402 127.0.0.1.3306 TIME_WAIT fffffe011f5521b0 tcp4 0 0 127.0.0.1.35401 127.0.0.1.3306 TIME_WAIT fffffe011f66c1b0 tcp4 0 0 127.0.0.1.35400 127.0.0.1.3306 TIME_WAIT fffffe011f149240 tcp4 0 0 127.0.0.1.35399 127.0.0.1.3306 TIME_WAIT fffffe011f209708 tcp4 0 0 127.0.0.1.35398 127.0.0.1.3306 TIME_WAIT fffffe011f209948 tcp4 0 0 127.0.0.1.35397 127.0.0.1.3306 TIME_WAIT fffffe011f149828 tcp4 0 0 127.0.0.1.35396 127.0.0.1.3306 TIME_WAIT fffffe011f14a9d8 tcp4 0 0 127.0.0.1.35395 127.0.0.1.3306 TIME_WAIT fffffe011f149c60 tcp4 0 0 127.0.0.1.62404 127.0.0.1.25 TIME_WAIT fffffe011f149900 tcp4 0 0 127.0.0.1.37702 127.0.0.1.3306 TIME_WAIT fffffe011f66c3f0 tcp4 0 0 127.0.0.1.17383 127.0.0.1.3306 TIME_WAIT fffffe011f1495e8 tcp4 0 0 127.0.0.1.52050 127.0.0.1.3306 TIME_WAIT fffffe011f14a5a0 tcp4 0 0 127.0.0.1.54085 127.0.0.1.3306 TIME_WAIT fffffe011f14a5e8 tcp4 0 0 127.0.0.1.19213 127.0.0.1.3306 TIME_WAIT fffffe011f66c630 tcp4 0 0 127.0.0.1.46956 127.0.0.1.3306 TIME_WAIT fffffe011f209630 tcp4 0 0 127.0.0.1.34745 127.0.0.1.3306 TIME_WAIT fffffe011f66ca68 tcp4 0 0 127.0.0.1.21425 127.0.0.1.3306 TIME_WAIT fffffe011f2091f8 tcp4 0 0 127.0.0.1.50330 127.0.0.1.3306 TIME_WAIT fffffe011f209c18 tcp4 0 0 127.0.0.1.52187 127.0.0.1.3306 TIME_WAIT fffffe011f149b88 tcp4 0 0 127.0.0.1.3306 127.0.0.1.10538 TIME_WAIT fffffe011f99f168 tcp4 0 0 127.0.0.1.10538 127.0.0.1.3306 TIME_WAIT fffffe011f149168 tcp4 0 0 127.0.0.1.3306 127.0.0.1.33281 TIME_WAIT fffffe011f66c1f8 tcp4 0 0 127.0.0.1.80 127.0.0.1.17178 TIME_WAIT fffffe00a006a7a0 tcp4 0 0 *.587 *.* LISTEN fffffe00a006a3d0 tcp6 0 0 *.25 *.* LISTEN fffffe00a006a000 tcp4 0 0 *.25 *.* LISTEN fffffe00a00727a0 tcp4 0 0 127.0.0.1.80 *.* LISTEN fffffe00a0072b70 tcp4 0 0 *.3306 *.* LISTEN fffffe00a003c3d0 tcp4 0 0 *.22 *.* LISTEN fffffe00a003c7a0 tcp6 0 0 *.22 *.* LISTEN fffffe00a0071b70 tcp6 0 0 *.3000 *.* LISTEN fffffe00a003cb70 tcp4 0 0 127.0.0.1.9000 *.* LISTEN fffffe00a014b3d0 tcp4 0 0 *.873 *.* LISTEN fffffe00a014b7a0 tcp6 0 0 *.873 *.* LISTEN fffffe00483fc000 tcp4 0 0 *.199 *.* LISTEN fffffe00483fc7a0 tcp4 0 0 *.80 *.* LISTEN fffffe00483fcb70 tcp6 0 0 *.80 *.* LISTEN fffffe000796c000 tcp4 0 0 127.0.0.1.81 *.* LISTEN fffffe000796c3d0 tcp6 0 0 ::1.81 *.* LISTEN fffffe00a003bb70 tcp4 0 0 *.953 *.* LISTEN fffffe00a003b7a0 tcp4 0 0 202.249.24.34.53 *.* LISTEN fffffe00a003b3d0 tcp4 0 0 127.0.0.1.53 *.* LISTEN fffffe00a003b000 tcp6 0 0 *.53 *.* LISTEN fffffe00a003c000 tcp6 0 0 *.82 *.* LISTEN fffffe000796a310 udp4 0 0 202.249.24.34.5980 202.249.26.50.53 fffffe000796eab8 udp4 5728 0 *.9996 *.* fffffe00a0078188 udp4 0 0 202.249.24.34.123 *.* fffffe00a0078310 udp4 0 0 127.0.0.1.123 *.* fffffe00a0078498 udp6 0 0 fe80:8::1.123 *.* fffffe000796e000 udp6 0 0 ::1.123 *.* fffffe000796e7a8 udp6 0 0 fe80:2::230:48ff.1 *.* fffffe000796e498 udp4 0 0 192.168.0.10.123 *.* fffffe00078c7c40 udp6 0 0 2001:d30:101:1:2.1 *.* fffffe000796a498 udp6 0 0 2001:d30:101:1::.1 *.* fffffe000796adc8 udp6 0 0 fe80:1::230:48ff.1 *.* fffffe0048e86930 udp4 0 0 202.249.25.27.123 *.* fffffe000796e310 udp6 0 0 *.123 *.* fffffe000796e620 udp4 0 0 *.123 *.* fffffe00078c7620 udp4 0 0 *.161 *.* fffffe00078c7310 udp4 0 0 *.162 *.* fffffe000796aab8 udp4 460 0 202.249.24.34.53 *.* fffffe000796a7a8 udp4 0 0 127.0.0.1.53 *.* fffffe000796a620 udp6 0 0 *.53 *.* fffffe00078c7ab8 udp4 0 0 *.514 *.* fffffe00078c7930 udp6 0 0 *.514 *.* Active UNIX domain sockets Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr fffffe00483fd1e0 stream 0 0 fffffe00a0e2cd20 0 0 0 /tmp/mysql.sock fffffe011f032870 stream 0 0 fffffe00a0e731e0 0 0 0 /data/nfsen/run/nfsen.comm fffffe0048de0960 stream 0 0 0 fffffe0048de0a50 0 0 fffffe0048de0a50 stream 0 0 0 fffffe0048de0960 0 0 fffffe00483fdc30 stream 0 0 fffffe00079341e0 0 0 0 /var/run/devd.pipe fffffe0048de03c0 dgram 0 0 0 fffffe0048de0d20 0 fffffe0048de04b0 fffffe00483fd000 dgram 0 0 0 fffffe0048de0e10 0 fffffe0048de0690 fffffe0048de04b0 dgram 0 0 0 fffffe0048de0d20 0 0 fffffe0048de0690 dgram 0 0 0 fffffe0048de0e10 0 fffffe00483fd2d0 fffffe00483fd2d0 dgram 0 0 0 fffffe0048de0e10 0 fffffe00079134b0 fffffe00079134b0 dgram 0 0 0 fffffe0048de0e10 0 fffffe00483fd3c0 fffffe00483fd3c0 dgram 0 0 0 fffffe0048de0e10 0 fffffe00483fd4b0 fffffe00483fd4b0 dgram 0 0 0 fffffe0048de0e10 0 fffffe00483fd690 fffffe00483fd690 dgram 0 0 0 fffffe0048de0e10 0 fffffe00483fd870 fffffe00483fd870 dgram 0 0 0 fffffe0048de0e10 0 0 fffffe0048de0c30 dgram 0 0 fffffe0048fc9780 0 0 0 /var/named/var/run/log fffffe0048de0d20 dgram 0 0 fffffe0048fc01e0 0 fffffe0048de03c0 0 /var/run/log fffffe0048de0e10 dgram 0 0 fffffe0048fc03c0 0 fffffe00483fd000 0 /var/run/logpriv fffffe0048ea6000 dgram 0 0 fffffe0048fc05a0 0 0 0 /var/run/log ------------------------------------------------------------------------ netstat -aL Current listen queue sizes (qlen/incqlen/maxqlen) Proto Listen Local Address tcp4 0/0/10 *.submission tcp6 0/0/10 *.smtp tcp4 0/0/10 *.smtp tcp4 0/0/1024 localhost.http tcp4 0/0/50 *.3306 tcp4 0/0/128 *.ssh tcp6 0/0/128 *.ssh tcp6 0/0/10 *.3000 tcp4 0/0/4096 localhost.9000 tcp4 0/0/5 *.rsync tcp6 0/0/5 *.rsync tcp4 0/0/128 *.smux tcp4 0/0/1024 *.http tcp6 0/0/1024 *.http tcp4 0/0/10 localhost.hosts2-ns tcp6 0/0/10 localhost.hosts2-ns tcp4 0/0/128 *.rndc tcp4 0/0/3 202.249.24.34.domain tcp4 0/0/3 localhost.domain tcp6 0/0/3 *.domain tcp6 0/0/128 *.xfer unix 0/0/50 /tmp/mysql.sock unix 0/0/128 /data/nfsen/run/nfsen.comm unix 0/0/4 /var/run/devd.pipe ------------------------------------------------------------------------ fstat USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root getty 1770 root / 2 drwxr-xr-x 512 r root getty 1770 wd / 2 drwxr-xr-x 512 r root getty 1770 text /usr 80383039 -r-xr-xr-x 27512 r root getty 1770 ctty /dev 57 crw------- ttyv7 rw root getty 1770 0 /dev 57 crw------- ttyv7 rw root getty 1770 1 /dev 57 crw------- ttyv7 rw root getty 1770 2 /dev 57 crw------- ttyv7 rw root getty 1769 root / 2 drwxr-xr-x 512 r root getty 1769 wd / 2 drwxr-xr-x 512 r root getty 1769 text /usr 80383039 -r-xr-xr-x 27512 r root getty 1769 ctty /dev 56 crw------- ttyv6 rw root getty 1769 0 /dev 56 crw------- ttyv6 rw root getty 1769 1 /dev 56 crw------- ttyv6 rw root getty 1769 2 /dev 56 crw------- ttyv6 rw root getty 1768 root / 2 drwxr-xr-x 512 r root getty 1768 wd / 2 drwxr-xr-x 512 r root getty 1768 text /usr 80383039 -r-xr-xr-x 27512 r root getty 1768 ctty /dev 55 crw------- ttyv5 rw root getty 1768 0 /dev 55 crw------- ttyv5 rw root getty 1768 1 /dev 55 crw------- ttyv5 rw root getty 1768 2 /dev 55 crw------- ttyv5 rw root getty 1767 root / 2 drwxr-xr-x 512 r root getty 1767 wd / 2 drwxr-xr-x 512 r root getty 1767 text /usr 80383039 -r-xr-xr-x 27512 r root getty 1767 ctty /dev 54 crw------- ttyv4 rw root getty 1767 0 /dev 54 crw------- ttyv4 rw root getty 1767 1 /dev 54 crw------- ttyv4 rw root getty 1767 2 /dev 54 crw------- ttyv4 rw root getty 1766 root / 2 drwxr-xr-x 512 r root getty 1766 wd / 2 drwxr-xr-x 512 r root getty 1766 text /usr 80383039 -r-xr-xr-x 27512 r root getty 1766 ctty /dev 53 crw------- ttyv3 rw root getty 1766 0 /dev 53 crw------- ttyv3 rw root getty 1766 1 /dev 53 crw------- ttyv3 rw root getty 1766 2 /dev 53 crw------- ttyv3 rw root getty 1765 root / 2 drwxr-xr-x 512 r root getty 1765 wd / 2 drwxr-xr-x 512 r root getty 1765 text /usr 80383039 -r-xr-xr-x 27512 r root getty 1765 ctty /dev 52 crw------- ttyv2 rw root getty 1765 0 /dev 52 crw------- ttyv2 rw root getty 1765 1 /dev 52 crw------- ttyv2 rw root getty 1765 2 /dev 52 crw------- ttyv2 rw root getty 1764 root / 2 drwxr-xr-x 512 r root getty 1764 wd / 2 drwxr-xr-x 512 r root getty 1764 text /usr 80383039 -r-xr-xr-x 27512 r root getty 1764 ctty /dev 51 crw------- ttyv1 rw root getty 1764 0 /dev 51 crw------- ttyv1 rw root getty 1764 1 /dev 51 crw------- ttyv1 rw root getty 1764 2 /dev 51 crw------- ttyv1 rw root getty 1763 root / 2 drwxr-xr-x 512 r root getty 1763 wd / 2 drwxr-xr-x 512 r root getty 1763 text /usr 80383039 -r-xr-xr-x 27512 r root getty 1763 ctty /dev 50 crw------- ttyv0 rw root getty 1763 0 /dev 50 crw------- ttyv0 rw root getty 1763 1 /dev 50 crw------- ttyv0 rw root getty 1763 2 /dev 50 crw------- ttyv0 rw root cron 1680 root / 2 drwxr-xr-x 512 r root cron 1680 wd /var 3627008 drwxr-x--- 512 r root cron 1680 text /usr 85069939 -r-xr-xr-x 41352 r root cron 1680 0 /dev 19 crw-rw-rw- null rw root cron 1680 1 /dev 19 crw-rw-rw- null rw root cron 1680 2 /dev 19 crw-rw-rw- null rw root cron 1680 3 /var 3579952 -rw------- 4 w smmsp sendmail 1673 root / 2 drwxr-xr-x 512 r smmsp sendmail 1673 wd /var 2378758 drwxrwx--- 512 r smmsp sendmail 1673 text /usr 80382986 -r-xr-sr-x 707224 r smmsp sendmail 1673 0 /dev 19 crw-rw-rw- null r smmsp sendmail 1673 1 /dev 19 crw-rw-rw- null w smmsp sendmail 1673 2 /dev 19 crw-rw-rw- null w smmsp sendmail 1673 3* local dgram fffffe0048de03c0 <-> fffffe0048de0d20 smmsp sendmail 1673 4 /var 2378782 -rw------- 50 w root sendmail 1669 root / 2 drwxr-xr-x 512 r root sendmail 1669 wd /var 2378755 drwxr-xr-x 512 r root sendmail 1669 text /usr 80382986 -r-xr-sr-x 707224 r root sendmail 1669 0 /dev 19 crw-rw-rw- null r root sendmail 1669 1 /dev 19 crw-rw-rw- null w root sendmail 1669 2 /dev 19 crw-rw-rw- null w root sendmail 1669 3* internet stream tcp fffffe00a006a000 root sendmail 1669 4* local dgram fffffe00483fd000 <-> fffffe0048de0e10 root sendmail 1669 5* internet6 stream tcp fffffe00a006a3d0 root sendmail 1669 6* internet stream tcp fffffe00a006a7a0 root sendmail 1669 7 /var 3579951 -rw------- 44 w www lighttpd 1610 root / 2 drwxr-xr-x 512 r www lighttpd 1610 wd / 2 drwxr-xr-x 512 r www lighttpd 1610 text /usr 176314434 -r-xr-xr-x 185712 r www lighttpd 1610 0 /dev 19 crw-rw-rw- null rw www lighttpd 1610 1 /dev 19 crw-rw-rw- null rw www lighttpd 1610 2 /dev 19 crw-rw-rw- null rw www lighttpd 1610 3 /var 8996899 -rw-r--r-- 9493 w www lighttpd 1610 4* internet stream tcp fffffe00a00727a0 www lighttpd 1610 5 /var 8996916 -rw-r--r-- 6130292 w www lighttpd 1610 7* internet stream tcp fffffe011f387000 www lighttpd 1610 8* internet stream tcp fffffe01a9056000 www lighttpd 1610 9* internet stream tcp fffffe011ffd23d0 www lighttpd 1610 10* internet stream tcp fffffe011f387b70 www lighttpd 1610 11* internet stream tcp fffffe011fcd0b70 www lighttpd 1610 12* internet stream tcp fffffe0048ff27a0 www lighttpd 1610 13* internet stream tcp fffffe011f3847a0 www lighttpd 1610 14* internet stream tcp fffffe011f9167a0 www lighttpd 1610 15* internet stream tcp fffffe011fcd17a0 www lighttpd 1610 16* internet stream tcp fffffe00a0071000 www lighttpd 1610 17* internet stream tcp fffffe011f73b3d0 www lighttpd 1610 18* internet stream tcp fffffe011f3867a0 mysql mysqld 1602 root / 2 drwxr-xr-x 512 r mysql mysqld 1602 wd /data 4682 ?--------- 18446744071580190873 r mysql mysqld 1602 text /usr 176288995 -r-xr-xr-x 6567128 r mysql mysqld 1602 0 /dev 19 crw-rw-rw- null r mysql mysqld 1602 1 /data 4758 ?--------- 18446744071580190873 w mysql mysqld 1602 2 /data 4758 ?--------- 18446744071580190873 w mysql mysqld 1602 3 /data 4761 ?--------- 18446744071580190873 rw mysql mysqld 1602 4 /var 4451377 -rw------- 0 rw mysql mysqld 1602 5 /var 4451378 -rw------- 0 rw mysql mysqld 1602 6 /var 4451379 -rw------- 0 rw mysql mysqld 1602 7 /var 4451380 -rw------- 0 rw mysql mysqld 1602 8 /data 4762 ?--------- 18446744071580190873 rw mysql mysqld 1602 9 /data 4763 ?--------- 18446744071580190873 rw mysql mysqld 1602 10* internet stream tcp fffffe00a0072b70 mysql mysqld 1602 11 /var 4451381 -rw------- 0 rw mysql mysqld 1602 12* local stream fffffe00483fd1e0 mysql mysqld 1602 13 /data 4691 ?--------- 18446744071580190873 rw mysql mysqld 1602 14 /data 4692 ?--------- 18446744071580190873 rw mysql mysqld 1602 15 /data 4694 ?--------- 18446744071580190873 rw mysql mysqld 1602 16 /data 4695 ?--------- 18446744071580190873 rw mysql mysqld 1602 17 /data 4688 ?--------- 18446744071580190873 rw mysql mysqld 1602 18 /data 4689 ?--------- 18446744071580190873 rw mysql mysqld 1602 19 /data 4706 ?--------- 0 rw mysql mysqld 1602 20 /data 4707 ?--------- 18446744071580190873 rw mysql mysqld 1602 21 /data 4709 ?--------- 18446744071580190873 rw mysql mysqld 1602 22 /data 4710 ?--------- 18446744071580190873 rw mysql mysqld 1602 23 /data 4742 ?--------- 18446744071580190873 rw mysql mysqld 1602 24 /data 4743 ?--------- 18446744071580190873 rw mysql mysqld 1602 25 /data 4703 ?--------- 18446744071580190873 rw mysql mysqld 1602 26 /data 4704 ?--------- 18446744071580190873 rw mysql mysqld 1602 27 /data 4751 ?--------- 18446744071580190873 rw mysql mysqld 1602 28 /data 4752 ?--------- 18446744071580190873 rw mysql mysqld 1602 29* internet stream tcp fffffe011fcd03d0 mysql mysqld 1602 30 /data 4876 ?--------- 18446744071580190873 rw mysql mysqld 1602 31 /data 4877 ?--------- 18446744071580190873 rw mysql mysqld 1602 32 /data 4858 ?--------- 18446744071580190873 rw mysql mysqld 1602 33 /data 4859 ?--------- 18446744071580190873 rw mysql mysqld 1602 34 /data 4831 ?--------- 18446744071580190873 rw mysql mysqld 1602 35 /data 4832 ?--------- 18446744071580190873 rw mysql mysqld 1602 36 /data 4861 ?--------- 18446744071580190873 rw mysql mysqld 1602 37 /data 4862 ?--------- 18446744071580190873 rw mysql mysqld 1602 38 /data 4855 ?--------- 18446744071580190873 rw mysql mysqld 1602 39 /data 4856 ?--------- 0 rw mysql mysqld 1602 40 /data 4912 ?--------- 18446744071580190873 rw mysql mysqld 1602 41 /data 4867 ?--------- 18446744071580190873 rw mysql mysqld 1602 42 /data 4868 ?--------- 18446744071580190873 rw mysql mysqld 1602 43 /data 4864 ?--------- 18446744071580190873 rw mysql mysqld 1602 44 /data 4865 ?--------- 18446744071580190873 rw mysql mysqld 1602 45 /data 4913 ?--------- 18446744071580190873 rw mysql mysqld 1602 46 /data 4859 ?--------- 18446744071580190873 rw mysql mysqld 1602 47 /data 4862 ?--------- 18446744071580190873 rw mysql mysqld 1602 48 /data 4859 ?--------- 18446744071580190873 rw mysql mysqld 1602 49* internet stream tcp fffffe00a00723d0 mysql mysqld 1602 50 /data 4900 ?--------- 18446744071580190873 rw mysql mysqld 1602 51 /data 4865 ?--------- 18446744071580190873 rw mysql mysqld 1602 52 /data 4832 ?--------- 18446744071580190873 rw mysql mysqld 1602 53 /data 4862 ?--------- 18446744071580190873 rw mysql mysqld 1602 54 /data 4901 ?--------- 18446744071580190873 rw mysql mysqld 1602 55 /data 4909 ?--------- 18446744071580190873 rw mysql mysqld 1602 56 /data 4910 ?--------- 18446744071580190873 rw mysql mysqld 1602 57 /data 4906 ?--------- 18446744071580190873 rw mysql mysqld 1602 58 /data 4907 ?--------- 18446744071580190873 rw mysql mysqld 1602 59* internet stream tcp fffffe00a006ab70 mysql mysqld 1602 60* internet stream tcp fffffe011ffd2000 mysql mysqld 1602 61 /data 4879 ?--------- 18446744071580190873 rw mysql mysqld 1602 62 /data 4880 ?--------- 18446744071580190873 rw mysql mysqld 1602 63 /data 4828 ?--------- 0 rw mysql mysqld 1602 64 /data 4829 ?--------- 18446744071580190873 rw mysql mysqld 1602 65* internet stream tcp fffffe01a90563d0 mysql mysqld 1602 66 /data 4825 ?--------- 18446744071580190873 rw mysql mysqld 1602 67 /data 4826 ?--------- 18446744071580190873 rw mysql mysqld 1602 68 /data 4903 ?--------- 18446744071580190873 rw mysql mysqld 1602 69 /data 4904 ?--------- 18446744071580190873 rw mysql mysqld 1602 70 /data 4804 ?--------- 18446744071580190873 rw mysql mysqld 1602 71 /data 4805 ?--------- 18446744071580190873 rw mysql mysqld 1602 72 /data 4819 ?--------- 18446744071580190873 rw mysql mysqld 1602 73 /data 4820 ?--------- 18446744071580190873 rw mysql mysqld 1602 74 /data 4813 ?--------- 18446744071580190873 rw mysql mysqld 1602 75 /data 4814 ?--------- 18446744071580190873 rw mysql mysqld 1602 76* internet stream tcp fffffe011f3873d0 mysql mysqld 1602 77 /data 4795 ?--------- 18446744071580190873 rw mysql mysqld 1602 78 /data 4796 ?--------- 18446744071580190873 rw mysql mysqld 1602 79 /data 4801 ?--------- 18446744071580190873 rw mysql mysqld 1602 80 /data 4802 ?--------- 18446744071580190873 rw mysql mysqld 1602 81 /data 4822 ?--------- 18446744071580190873 rw mysql mysqld 1602 82 /data 4823 ?--------- 18446744071580190873 rw mysql mysqld 1602 83 /data 4796 ?--------- 18446744071580190873 rw mysql mysqld 1602 84 /data 4802 ?--------- 18446744071580190873 rw mysql mysqld 1602 85 /data 4823 ?--------- 18446744071580190873 rw mysql mysqld 1602 86 /data 4796 ?--------- 18446744071580190873 rw mysql mysqld 1602 87 /data 4802 ?--------- 18446744071580190873 rw mysql mysqld 1602 88 /data 4823 ?--------- 18446744071580190873 rw mysql mysqld 1602 89 /data 4798 ?--------- 18446744071580190873 rw mysql mysqld 1602 90 /data 4799 ?--------- 18446744071580190873 rw mysql mysqld 1602 91 /data 4870 ?--------- 18446744071580190873 rw mysql mysqld 1602 92 /data 4871 ?--------- 18446744071580190873 rw mysql mysqld 1602 93 /data 4799 ?--------- 18446744071580190873 rw mysql mysqld 1602 94 /data 4871 ?--------- 18446744071580190873 rw mysql mysqld 1602 95 /data 4799 ?--------- 18446744071580190873 rw mysql mysqld 1602 96 /data 4871 ?--------- 18446744071580190873 rw mysql sh 1553 root / 2 drwxr-xr-x 512 r mysql sh 1553 wd / 2 drwxr-xr-x 512 r mysql sh 1553 text / 141350 -r-xr-xr-x 142856 r mysql sh 1553 0 /dev 19 crw-rw-rw- null rw mysql sh 1553 1 /dev 19 crw-rw-rw- null rw mysql sh 1553 2 /dev 19 crw-rw-rw- null rw mysql sh 1553 10 /usr 176289442 -r-xr-xr-x 16724 r www perl 1543 root / 2 drwxr-xr-x 512 r www perl 1543 wd / 2 drwxr-xr-x 512 r www perl 1543 text /usr 176287388 -rwxr-xr-x 7296 r www perl 1543 0 /dev 19 crw-rw-rw- null r www perl 1543 1 /dev 19 crw-rw-rw- null w www perl 1543 2 /dev 19 crw-rw-rw- null w www perl 1543 3* local dgram fffffe0048de04b0 <-> fffffe0048de0d20 www perl 1543 4* local stream fffffe011f032870 www perl 1542 root / 2 drwxr-xr-x 512 r www perl 1542 wd / 2 drwxr-xr-x 512 r www perl 1542 text /usr 176287388 -rwxr-xr-x 7296 r www perl 1542 0 /dev 19 crw-rw-rw- null r www perl 1542 1 /dev 19 crw-rw-rw- null w www perl 1542 2 /dev 19 crw-rw-rw- null w www perl 1542 3* local dgram fffffe0048de04b0 <-> fffffe0048de0d20 www nfcapd 1540 root / 2 drwxr-xr-x 512 r www nfcapd 1540 wd / 2 drwxr-xr-x 512 r www nfcapd 1540 text /usr 176288132 -r-xr-xr-x 171336 r www nfcapd 1540 0 /dev 19 crw-rw-rw- null r www nfcapd 1540 1 /dev 19 crw-rw-rw- null w www nfcapd 1540 2 /dev 19 crw-rw-rw- null w www nfcapd 1540 3* local dgram fffffe0048de0690 <-> fffffe0048de0e10 www nfcapd 1540 4* internet dgram udp fffffe000796eab8 www nfcapd 1540 5 /data 74213 ?--------- 18446744071580190873 rw root sshd 1531 root / 2 drwxr-xr-x 512 r root sshd 1531 wd / 2 drwxr-xr-x 512 r root sshd 1531 text /usr 85069853 -r-xr-xr-x 269552 r root sshd 1531 0 /dev 19 crw-rw-rw- null rw root sshd 1531 1 /dev 19 crw-rw-rw- null rw root sshd 1531 2 /dev 19 crw-rw-rw- null rw root sshd 1531 3* internet6 stream tcp fffffe00a003c7a0 root sshd 1531 4* internet stream tcp fffffe00a003c3d0 nobody ntop 1526 root / 2 drwxr-xr-x 512 r nobody ntop 1526 wd / 2 drwxr-xr-x 512 r nobody ntop 1526 text /usr 176290001 -r-xr-xr-x 61992 r nobody ntop 1526 0 /usr 176876704 -rw-r--r-- 43453969 r nobody ntop 1526 1 /usr 176876703 -rw-r--r-- 2204808 r nobody ntop 1526 2* internet6 stream tcp fffffe00a0071b70 nobody ntop 1526 3* local dgram fffffe00483fd2d0 <-> fffffe0048de0e10 nobody ntop 1526 4 /var 2190361 -rw-r----- 65536 rw nobody ntop 1526 5 /var 2190362 -rw-r----- 65536 rw nobody ntop 1526 6 /dev 29 crw------- bpf rw nobody ntop 1526 7 /var 2190363 -rw-r----- 2048000 rw nobody ntop 1526 8 /var 2190364 -rw-r----- 262144 rw www php-fpm 1524 root / 2 drwxr-xr-x 512 r www php-fpm 1524 wd / 2 drwxr-xr-x 512 r www php-fpm 1524 text /usr 176313699 -rwxr-xr-x 3418860 r www php-fpm 1524 0* internet stream tcp fffffe00a003cb70 www php-fpm 1524 1 /dev 19 crw-rw-rw- null rw www php-fpm 1524 2 /dev 19 crw-rw-rw- null rw www php-fpm 1523 root / 2 drwxr-xr-x 512 r www php-fpm 1523 wd / 2 drwxr-xr-x 512 r www php-fpm 1523 text /usr 176313699 -rwxr-xr-x 3418860 r www php-fpm 1523 0* internet stream tcp fffffe00a003cb70 www php-fpm 1523 1 /dev 19 crw-rw-rw- null rw www php-fpm 1523 2 /dev 19 crw-rw-rw- null rw www php-fpm 1522 root / 2 drwxr-xr-x 512 r www php-fpm 1522 wd / 2 drwxr-xr-x 512 r www php-fpm 1522 text /usr 176313699 -rwxr-xr-x 3418860 r www php-fpm 1522 0* internet stream tcp fffffe00a003cb70 www php-fpm 1522 1 /dev 19 crw-rw-rw- null rw www php-fpm 1522 2 /dev 19 crw-rw-rw- null rw www php-fpm 1521 root / 2 drwxr-xr-x 512 r www php-fpm 1521 wd / 2 drwxr-xr-x 512 r www php-fpm 1521 text /usr 176313699 -rwxr-xr-x 3418860 r www php-fpm 1521 0* internet stream tcp fffffe00a003cb70 www php-fpm 1521 1 /dev 19 crw-rw-rw- null rw www php-fpm 1521 2 /dev 19 crw-rw-rw- null rw www php-fpm 1520 root / 2 drwxr-xr-x 512 r www php-fpm 1520 wd / 2 drwxr-xr-x 512 r www php-fpm 1520 text /usr 176313699 -rwxr-xr-x 3418860 r www php-fpm 1520 0* internet stream tcp fffffe00a003cb70 www php-fpm 1520 1 /dev 19 crw-rw-rw- null rw www php-fpm 1520 2 /dev 19 crw-rw-rw- null rw www php-fpm 1519 root / 2 drwxr-xr-x 512 r www php-fpm 1519 wd / 2 drwxr-xr-x 512 r www php-fpm 1519 text /usr 176313699 -rwxr-xr-x 3418860 r www php-fpm 1519 0* internet stream tcp fffffe00a003cb70 www php-fpm 1519 1 /dev 19 crw-rw-rw- null rw www php-fpm 1519 2 /dev 19 crw-rw-rw- null rw www php-fpm 1518 root / 2 drwxr-xr-x 512 r www php-fpm 1518 wd / 2 drwxr-xr-x 512 r www php-fpm 1518 text /usr 176313699 -rwxr-xr-x 3418860 r www php-fpm 1518 0* internet stream tcp fffffe00a003cb70 www php-fpm 1518 1 /dev 19 crw-rw-rw- null rw www php-fpm 1518 2 /dev 19 crw-rw-rw- null rw www php-fpm 1517 root / 2 drwxr-xr-x 512 r www php-fpm 1517 wd / 2 drwxr-xr-x 512 r www php-fpm 1517 text /usr 176313699 -rwxr-xr-x 3418860 r www php-fpm 1517 0* internet stream tcp fffffe00a003cb70 www php-fpm 1517 1 /dev 19 crw-rw-rw- null rw www php-fpm 1517 2 /dev 19 crw-rw-rw- null rw www php-fpm 1514 root / 2 drwxr-xr-x 512 r www php-fpm 1514 wd / 2 drwxr-xr-x 512 r www php-fpm 1514 text /usr 176313699 -rwxr-xr-x 3418860 r www php-fpm 1514 0* internet stream tcp fffffe00a003cb70 www php-fpm 1514 1 /dev 19 crw-rw-rw- null rw www php-fpm 1514 2 /dev 19 crw-rw-rw- null rw www php-fpm 1512 root / 2 drwxr-xr-x 512 r www php-fpm 1512 wd / 2 drwxr-xr-x 512 r www php-fpm 1512 text /usr 176313699 -rwxr-xr-x 3418860 r www php-fpm 1512 0* internet stream tcp fffffe00a003cb70 www php-fpm 1512 1 /dev 19 crw-rw-rw- null rw www php-fpm 1512 2 /dev 19 crw-rw-rw- null rw www php-fpm 1511 root / 2 drwxr-xr-x 512 r www php-fpm 1511 wd / 2 drwxr-xr-x 512 r www php-fpm 1511 text /usr 176313699 -rwxr-xr-x 3418860 r www php-fpm 1511 0* internet stream tcp fffffe00a003cb70 www php-fpm 1511 1 /dev 19 crw-rw-rw- null rw www php-fpm 1511 2 /dev 19 crw-rw-rw- null rw www php-fpm 1510 root / 2 drwxr-xr-x 512 r www php-fpm 1510 wd / 2 drwxr-xr-x 512 r www php-fpm 1510 text /usr 176313699 -rwxr-xr-x 3418860 r www php-fpm 1510 0* internet stream tcp fffffe00a003cb70 www php-fpm 1510 1 /dev 19 crw-rw-rw- null rw www php-fpm 1510 2 /dev 19 crw-rw-rw- null rw www php-fpm 1509 root / 2 drwxr-xr-x 512 r www php-fpm 1509 wd / 2 drwxr-xr-x 512 r www php-fpm 1509 text /usr 176313699 -rwxr-xr-x 3418860 r www php-fpm 1509 0* internet stream tcp fffffe00a003cb70 www php-fpm 1509 1 /dev 19 crw-rw-rw- null rw www php-fpm 1509 2 /dev 19 crw-rw-rw- null rw www php-fpm 1507 root / 2 drwxr-xr-x 512 r www php-fpm 1507 wd / 2 drwxr-xr-x 512 r www php-fpm 1507 text /usr 176313699 -rwxr-xr-x 3418860 r www php-fpm 1507 0* internet stream tcp fffffe00a003cb70 www php-fpm 1507 1 /dev 19 crw-rw-rw- null rw www php-fpm 1507 2 /dev 19 crw-rw-rw- null rw www php-fpm 1506 root / 2 drwxr-xr-x 512 r www php-fpm 1506 wd /usr 84009984 drwxr-xr-x 1536 r www php-fpm 1506 text /usr 176313699 -rwxr-xr-x 3418860 r www php-fpm 1506 0* internet stream tcp fffffe00a003cb70 www php-fpm 1506 1 /dev 19 crw-rw-rw- null rw www php-fpm 1506 2 /dev 19 crw-rw-rw- null rw www php-fpm 1506 3* internet stream tcp fffffe000796c7a0 www php-fpm 1506 5* internet stream tcp fffffe011f8183d0 www php-fpm 1505 root / 2 drwxr-xr-x 512 r www php-fpm 1505 wd /usr 84009984 drwxr-xr-x 1536 r www php-fpm 1505 text /usr 176313699 -rwxr-xr-x 3418860 r www php-fpm 1505 0* internet stream tcp fffffe00a003cb70 www php-fpm 1505 1 /dev 19 crw-rw-rw- null rw www php-fpm 1505 2 /dev 19 crw-rw-rw- null rw www php-fpm 1505 3* internet stream tcp fffffe011fcd1b70 www php-fpm 1505 5* internet stream tcp fffffe011f385000 www php-fpm 1504 root / 2 drwxr-xr-x 512 r www php-fpm 1504 wd /usr 84009984 drwxr-xr-x 1536 r www php-fpm 1504 text /usr 176313699 -rwxr-xr-x 3418860 r www php-fpm 1504 0* internet stream tcp fffffe00a003cb70 www php-fpm 1504 1 /dev 19 crw-rw-rw- null rw www php-fpm 1504 2 /dev 19 crw-rw-rw- null rw www php-fpm 1504 3* internet stream tcp fffffe011fe463d0 www php-fpm 1504 4 /var 4451385 -rw------- 5576 rw www php-fpm 1504 5* internet stream tcp fffffe011f3877a0 www php-fpm 1503 root / 2 drwxr-xr-x 512 r www php-fpm 1503 wd /usr 84009984 drwxr-xr-x 1536 r www php-fpm 1503 text /usr 176313699 -rwxr-xr-x 3418860 r www php-fpm 1503 0* internet stream tcp fffffe00a003cb70 www php-fpm 1503 1 /dev 19 crw-rw-rw- null rw www php-fpm 1503 2 /dev 19 crw-rw-rw- null rw www php-fpm 1503 3* internet stream tcp fffffe01a9056b70 www php-fpm 1503 5* internet stream tcp fffffe011f52a3d0 www php-fpm 1502 root / 2 drwxr-xr-x 512 r www php-fpm 1502 wd /usr 84009984 drwxr-xr-x 1536 r www php-fpm 1502 text /usr 176313699 -rwxr-xr-x 3418860 r www php-fpm 1502 0* internet stream tcp fffffe00a003cb70 www php-fpm 1502 1 /dev 19 crw-rw-rw- null rw www php-fpm 1502 2 /dev 19 crw-rw-rw- null rw www php-fpm 1502 3* internet stream tcp fffffe011f3863d0 www php-fpm 1502 5* internet stream tcp fffffe011f384b70 www php-fpm 1501 root / 2 drwxr-xr-x 512 r www php-fpm 1501 wd /usr 84009984 drwxr-xr-x 1536 r www php-fpm 1501 text /usr 176313699 -rwxr-xr-x 3418860 r www php-fpm 1501 0* internet stream tcp fffffe00a003cb70 www php-fpm 1501 1 /dev 19 crw-rw-rw- null rw www php-fpm 1501 2 /dev 19 crw-rw-rw- null rw www php-fpm 1501 3* internet stream tcp fffffe011f818000 www php-fpm 1501 5* internet stream tcp fffffe011f0d57a0 root php-fpm 1500 root / 2 drwxr-xr-x 512 r root php-fpm 1500 wd / 2 drwxr-xr-x 512 r root php-fpm 1500 text /usr 176313699 -rwxr-xr-x 3418860 r root php-fpm 1500 0 /dev 19 crw-rw-rw- null rw root php-fpm 1500 1 /dev 19 crw-rw-rw- null rw root php-fpm 1500 2 /var 8996885 -rw------- 12231 w root php-fpm 1500 3 /var 8996885 -rw------- 12231 w root php-fpm 1500 4* local stream fffffe0048de0a50 <-> fffffe0048de0960 root php-fpm 1500 5* local stream fffffe0048de0960 <-> fffffe0048de0a50 root php-fpm 1500 6* internet stream tcp fffffe00a003cb70 root rsync 1492 root / 2 drwxr-xr-x 512 r root rsync 1492 wd / 2 drwxr-xr-x 512 r root rsync 1492 text /usr 176288029 -rwxr-xr-x 402128 r root rsync 1492 0 /dev 19 crw-rw-rw- null rw root rsync 1492 1 /dev 19 crw-rw-rw- null rw root rsync 1492 2 /dev 19 crw-rw-rw- null rw root rsync 1492 3* local dgram fffffe00079134b0 <-> fffffe0048de0e10 root rsync 1492 4* internet6 stream tcp fffffe00a014b7a0 root rsync 1492 5* internet stream tcp fffffe00a014b3d0 root ntpd 1447 root / 2 drwxr-xr-x 512 r root ntpd 1447 wd / 2 drwxr-xr-x 512 r root ntpd 1447 text /usr 85070737 -r-xr-xr-x 391448 r root ntpd 1447 0 /dev 19 crw-rw-rw- null rw root ntpd 1447 1 /dev 19 crw-rw-rw- null rw root ntpd 1447 2 /dev 19 crw-rw-rw- null rw root ntpd 1447 3* local dgram fffffe00483fd3c0 <-> fffffe0048de0e10 root ntpd 1447 20* internet dgram udp fffffe000796e620 root ntpd 1447 21* internet6 dgram udp fffffe000796e310 root ntpd 1447 22* internet dgram udp fffffe0048e86930 root ntpd 1447 23* internet6 dgram udp fffffe000796adc8 root ntpd 1447 24* internet6 dgram udp fffffe000796a498 root ntpd 1447 25* internet6 dgram udp fffffe00078c7c40 root ntpd 1447 26* internet dgram udp fffffe000796e498 root ntpd 1447 27* internet6 dgram udp fffffe000796e7a8 root ntpd 1447 28* internet6 dgram udp fffffe000796e000 root ntpd 1447 29* internet6 dgram udp fffffe00a0078498 root ntpd 1447 30* internet dgram udp fffffe00a0078310 root ntpd 1447 31* internet dgram udp fffffe00a0078188 root ntpd 1447 32* route raw 0 fffffe00a0260000 root snmpd 1386 root / 2 drwxr-xr-x 512 r root snmpd 1386 wd / 2 drwxr-xr-x 512 r root snmpd 1386 text /usr 176316942 -rwxr-xr-x 28720 r root snmpd 1386 0 /dev 19 crw-rw-rw- null rw root snmpd 1386 1 /dev 19 crw-rw-rw- null rw root snmpd 1386 2 /dev 19 crw-rw-rw- null rw root snmpd 1386 3 /dev 9 crw-r----- mem r root snmpd 1386 4 /dev 10 crw-r----- kmem r root snmpd 1386 5* pipe fffffe0007252888 <-> fffffe00072529e0 0 rw root snmpd 1386 6* pipe fffffe00072529e0 <-> fffffe0007252888 0 rw root snmpd 1386 7 /var 8996925 -rw-r----- 1448 r root snmpd 1386 8* internet dgram udp fffffe00078c7620 root snmpd 1386 9* internet stream tcp fffffe00483fc000 root snmptrapd 1380 root / 2 drwxr-xr-x 512 r root snmptrapd 1380 wd / 2 drwxr-xr-x 512 r root snmptrapd 1380 text /usr 176316943 -rwxr-xr-x 28912 r root snmptrapd 1380 0 /dev 19 crw-rw-rw- null rw root snmptrapd 1380 1 /dev 19 crw-rw-rw- null rw root snmptrapd 1380 2 /dev 19 crw-rw-rw- null rw root snmptrapd 1380 3 /dev 9 crw-r----- mem r root snmptrapd 1380 4 /dev 10 crw-r----- kmem r root snmptrapd 1380 5* pipe fffffe00078c3888 <-> fffffe00078c39e0 0 rw root snmptrapd 1380 6* pipe fffffe00078c39e0 <-> fffffe00078c3888 0 rw root snmptrapd 1380 7* pipe fffffe00078ed2d8 <-> fffffe00078ed430 0 rw root snmptrapd 1380 8* pipe fffffe00078ed430 <-> fffffe00078ed2d8 0 rw root snmptrapd 1380 9* local dgram fffffe00483fd4b0 <-> fffffe0048de0e10 root snmptrapd 1380 10* internet dgram udp fffffe00078c7310 www varnishd 1366 root / 2 drwxr-xr-x 512 r www varnishd 1366 wd /usr 176593812 drwxr-xr-x 512 r www varnishd 1366 text /usr 176311360 -r-xr-xr-x 386256 r www varnishd 1366 0 /dev 19 crw-rw-rw- null r www varnishd 1366 1* pipe fffffe0048f559e0 <-> fffffe0048f55888 0 rw www varnishd 1366 2* pipe fffffe0048f559e0 <-> fffffe0048f55888 0 rw www varnishd 1366 3 /tmp 91 -rw------- 3800563712 rw www varnishd 1366 4* pipe fffffe0048f555b0 <-> fffffe0048f55708 0 rw www varnishd 1366 5* pipe fffffe0048f55708 <-> fffffe0048f555b0 0 rw www varnishd 1366 7* internet6 stream tcp fffffe01a9251b70 www varnishd 1366 8* internet6 stream tcp fffffe00483fcb70 www varnishd 1366 9* internet stream tcp fffffe00483fc7a0 www varnishd 1366 10* pipe fffffe0048eb5000 <-> fffffe0048eb5158 0 rw www varnishd 1366 11* internet stream tcp fffffe011fcd0000 www varnishd 1366 12* internet6 stream tcp fffffe01a92517a0 www varnishd 1366 13* pipe fffffe0007914cb8 <-> fffffe0007914b60 0 rw www varnishd 1366 14* internet stream tcp fffffe01a92513d0 www varnishd 1366 15* internet6 stream tcp fffffe01a9251000 www varnishd 1366 16* internet6 stream tcp fffffe011ffd2b70 www varnishd 1366 17* internet6 stream tcp fffffe011ffd27a0 www varnishd 1366 18* internet stream tcp fffffe011f3853d0 www varnishd 1366 19* internet stream tcp fffffe0048ff2b70 www varnishd 1366 20* internet6 stream tcp fffffe011fd477a0 www varnishd 1366 21* internet stream tcp fffffe011f73b7a0 www varnishd 1366 22* internet stream tcp fffffe011f0d5000 root varnishd 1365 root / 2 drwxr-xr-x 512 r root varnishd 1365 wd /usr 176593812 drwxr-xr-x 512 r root varnishd 1365 text /usr 176311360 -r-xr-xr-x 386256 r root varnishd 1365 0 /dev 19 crw-rw-rw- null rw root varnishd 1365 1 /dev 19 crw-rw-rw- null rw root varnishd 1365 2 /dev 19 crw-rw-rw- null rw root varnishd 1365 3 /tmp 91 -rw------- 3800563712 rw root varnishd 1365 4 /var 3579941 -rw-r--r-- 4 w root varnishd 1365 5 /usr 176594754 -rw-r--r-- 83952816 rw root varnishd 1365 6* internet6 stream tcp fffffe000796c3d0 root varnishd 1365 7* internet stream tcp fffffe000796c000 root varnishd 1365 11* pipe fffffe0048eb5158 <-> fffffe0048eb5000 0 rw root varnishd 1365 12* pipe fffffe0007914b60 <-> fffffe0007914cb8 0 rw root varnishd 1365 14* pipe fffffe0048f55888 <-> fffffe0048f559e0 0 rw root varnishd 1365 16* local dgram fffffe00483fd690 <-> fffffe0048de0e10 root varnishlog 1354 root / 2 drwxr-xr-x 512 r root varnishlog 1354 wd / 2 drwxr-xr-x 512 r root varnishlog 1354 text /usr 176288814 -r-xr-xr-x 11864 r root varnishlog 1354 0 /dev 19 crw-rw-rw- null rw root varnishlog 1354 1 /dev 19 crw-rw-rw- null rw root varnishlog 1354 2 /dev 19 crw-rw-rw- null rw root varnishlog 1354 3 /usr 176594754 -rw-r--r-- 83952816 r root varnishlog 1354 4 /var 3579940 -rw-r--r-- 4 w root varnishlog 1354 5 /var 8996870 -rw-r--r-- 84153097 w root varnishncsa 1349 root / 2 drwxr-xr-x 512 r root varnishncsa 1349 wd / 2 drwxr-xr-x 512 r root varnishncsa 1349 text /usr 176288816 -r-xr-xr-x 13920 r root varnishncsa 1349 0 /dev 19 crw-rw-rw- null rw root varnishncsa 1349 1 /dev 19 crw-rw-rw- null rw root varnishncsa 1349 2 /dev 19 crw-rw-rw- null rw root varnishncsa 1349 3 /usr 176594754 -rw-r--r-- 83952816 r root varnishncsa 1349 4 /var 3579939 -rw-r--r-- 4 w root varnishncsa 1349 5 /var 8996895 -rw-r--r-- 7018688 w bind named 1237 root /var 10174464 drwxr-xr-x 512 r bind named 1237 wd /var 10174477 drwxr-xr-x 512 r bind named 1237 jail /var 10174464 drwxr-xr-x 512 r bind named 1237 text /usr 85069894 -r-xr-xr-x 2230616 r bind named 1237 0 /dev 19 crw-rw-rw- null rw bind named 1237 1 /dev 19 crw-rw-rw- null rw bind named 1237 2 /dev 19 crw-rw-rw- null rw bind named 1237 3* local dgram fffffe00483fd870 <-> fffffe0048de0e10 bind named 1237 4 /dev 19 crw-rw-rw- null rw bind named 1237 5 /var 10174482 -rw-r--r-- 2123216 w bind named 1237 6* pipe fffffe0048f55b60 <-> fffffe0048f55cb8 0 rw bind named 1237 8* pipe fffffe0048f55cb8 <-> fffffe0048f55b60 0 rw bind named 1237 10 /var/named/dev 24 crw-rw-rw- random r bind named 1237 20* internet6 stream tcp fffffe00a003c000 bind named 1237 21* internet6 stream tcp fffffe00a003b000 bind named 1237 22* internet stream tcp fffffe00a003b3d0 bind named 1237 23* internet stream tcp fffffe00a003b7a0 bind named 1237 24* internet stream tcp fffffe00a003bb70 bind named 1237 512* internet6 dgram udp fffffe000796a620 bind named 1237 513* internet dgram udp fffffe000796a7a8 bind named 1237 514* internet dgram udp fffffe000796aab8 bind named 1237 515* internet dgram udp fffffe000796a310 root syslogd 1148 root / 2 drwxr-xr-x 512 r root syslogd 1148 wd / 2 drwxr-xr-x 512 r root syslogd 1148 text /usr 85069949 -r-xr-xr-x 39816 r root syslogd 1148 0 /dev 19 crw-rw-rw- null rw root syslogd 1148 1 /dev 19 crw-rw-rw- null rw root syslogd 1148 2 /dev 19 crw-rw-rw- null rw root syslogd 1148 3 /var 3579932 -rw------- 4 w root syslogd 1148 4* local dgram fffffe0048ea6000 root syslogd 1148 5* local dgram fffffe0048de0e10 root syslogd 1148 6* local dgram fffffe0048de0d20 root syslogd 1148 7* local dgram fffffe0048de0c30 root syslogd 1148 8* internet6 dgram udp fffffe00078c7930 root syslogd 1148 9* internet dgram udp fffffe00078c7ab8 root syslogd 1148 10 /dev 26 crw------- klog r root syslogd 1148 12 /dev 4 crw------- console w root syslogd 1148 13 /var 8996879 -rw-r--r-- 25206 w root syslogd 1148 14 /var 8996875 -rw------- 66 w root syslogd 1148 15 /var 8996892 -rw------- 46044 w root syslogd 1148 16 /var 8996898 -rw-r----- 390188 w root syslogd 1148 17 /var 8996871 -rw-r--r-- 66 w root syslogd 1148 18 /var 8996876 -rw------- 66 w root syslogd 1148 19 /var 8996907 -rw------- 96907 w root syslogd 1148 20 /var 8996919 -rw------- 27173 w root syslogd 1148 21 /var 8996874 -rw-r----- 66 w root devd 976 root / 2 drwxr-xr-x 512 r root devd 976 wd / 2 drwxr-xr-x 512 r root devd 976 text / 965722 -r-xr-xr-x 423704 r root devd 976 0 /dev 19 crw-rw-rw- null rw root devd 976 1 /dev 19 crw-rw-rw- null rw root devd 976 2 /dev 19 crw-rw-rw- null rw root devd 976 3 /dev 5 crw------- devctl r root devd 976 4* local stream fffffe00483fdc30 root devd 976 5 /var 3579921 -rw------- 3 w root init 1 root / 2 drwxr-xr-x 512 r root init 1 wd / 2 drwxr-xr-x 512 r root init 1 text / 965728 -r-xr-xr-x 772448 r root kernel 0 root / 2 drwxr-xr-x 512 r root kernel 0 wd / 2 drwxr-xr-x 512 r ------------------------------------------------------------------------ dmesg Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-PRERELEASE #32: Mon Nov 28 15:59:44 JST 2011 dikshie@sfc-monitor.ai3.net:/usr/obj/usr/src/sys/MONITOR amd64 CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2800.16-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0xf4a Family = f Model = 4 Stepping = 10 Features=0xbfebfbff Features2=0x641d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 8589934592 (8192 MB) avail memory = 8231489536 (7850 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) x 2 HTT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP/HT): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pci0: at device 1.0 (no driver attached) pcib1: irq 16 at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 mvs0: port 0x2000-0x20ff mem 0xdd200000-0xdd2fffff irq 32 at device 2.0 on pci2 mvs0: Gen-II, 4 3Gbps ports, Port Multiplier supported mvsch0: at channel 0 on mvs0 mvsch1: at channel 1 on mvs0 mvsch2: at channel 2 on mvs0 mvsch3: at channel 3 on mvs0 pcib3: at device 0.2 on pci1 pci3: on pcib3 em0: port 0x3000-0x303f mem 0xdd300000-0xdd31ffff irq 54 at device 2.0 on pci3 em0: Ethernet address: 00:30:48:30:39:d8 em1: port 0x3040-0x307f mem 0xdd320000-0xdd33ffff irq 55 at device 2.1 on pci3 em1: Ethernet address: 00:30:48:30:39:d9 pcib4: irq 16 at device 4.0 on pci0 pci4: on pcib4 pcib5: irq 16 at device 6.0 on pci0 pci5: on pcib5 uhci0: port 0x1400-0x141f irq 16 at device 29.0 on pci0 usbus0: on uhci0 uhci1: port 0x1420-0x143f irq 19 at device 29.1 on pci0 usbus1: on uhci1 uhci2: port 0x1440-0x145f irq 18 at device 29.2 on pci0 usbus2: on uhci2 uhci3: port 0x1460-0x147f irq 16 at device 29.3 on pci0 usbus3: on uhci3 ehci0: mem 0xdd001000-0xdd0013ff irq 23 at device 29.7 on pci0 usbus4: EHCI version 1.0 usbus4: on ehci0 pcib6: at device 30.0 on pci0 pci6: on pcib6 vgapci0: port 0x4000-0x40ff mem 0xde000000-0xdeffffff,0xdd400000-0xdd400fff irq 17 at device 1.0 on pci6 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x14a0-0x14af at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x77 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range p4tcc0: on cpu0 p4tcc1: on cpu1 p4tcc2: on cpu2 p4tcc3: on cpu3 ZFS filesystem version 5 ZFS storage pool version 28 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ata1: DMA limited to UDMA33, controller found non-ATA66 cable ada0 at mvsch0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 2048bytes) ada0: Command Queueing enabled ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ada1 at mvsch1 bus 0 scbus1 target 0 lun 0 ada1: ATA-8 SATA 3.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 2048bytes) ada1: Command Queueing enabled ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad6 ada2 at mvsch2 bus 0 scbus2 target 0 lun 0 ada2: ATA-8 SATA 3.x device ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 2048bytes) ada2: Command Queueing enabled ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada2: Previously was known as ad8 ada3 at mvsch3 bus 0 scbus3 target 0 lun 0 ada3: ATA-8 SATA 3.x device ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 2048bytes) ada3: Command Queueing enabled ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada3: Previously was known as ad10 cd0 at ata1 bus 0 scbus5 target 1 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! uhub3: 2 ports with 2 removable, self powered uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered Root mount waiting for: usbus4 Root mount waiting for: usbus4 Root mount waiting for: usbus4 uhub4: 8 ports with 8 removable, self powered Trying to mount root from ufs:/dev/ada0s1a [rw]... Setting hostuuid: 64e9f180-63dc-1000-89d5-0030483039d8. Setting hostid: 0xa4ee83f0. Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: /dev/ada0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada0s1a: clean, 3756958 free (1030 frags, 469491 blocks, 0.0% fragmentation) /dev/ada0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada0s1d: clean, 4036374 free (70 frags, 504538 blocks, 0.0% fragmentation) /dev/ada0s1f: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada0s1f: clean, 673205689 free (279273 frags, 84115802 blocks, 0.0% fragmentation) /dev/ada0s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada0s1e: clean, 58780739 free (963 frags, 7347472 blocks, 0.0% fragmentation) Mounting local file systems:. Setting hostname: sfc-monitor.ai3.net. Starting Network: lo0 em0 em1. lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8 inet 127.0.0.1 netmask 0xff000000 inet 202.249.24.34 netmask 0xffffffff nd6 options=21 em0: flags=8843 metric 0 mtu 1500 options=209b ether 00:30:48:30:39:d8 inet 202.249.25.27 netmask 0xffffffe0 broadcast 202.249.25.31 inet6 fe80::230:48ff:fe30:39d8%em0 prefixlen 64 scopeid 0x1 inet6 2001:d30:101:1::11 prefixlen 64 inet6 2001:d30:101:1:230:48ff:fe30:39d8 prefixlen 64 autoconf nd6 options=23 media: Ethernet autoselect (1000baseT ) status: active em1: flags=8843 metric 0 mtu 1500 options=209b ether 00:30:48:30:39:d9 inet 192.168.0.10 netmask 0xffffffff broadcast 192.168.0.10 inet6 fe80::230:48ff:fe30:39d9%em1 prefixlen 64 tentative scopeid 0x2 nd6 options=29 media: Ethernet autoselect status: no carrier Starting devd. Starting Network: usbus0. Starting Network: usbus1. Starting Network: usbus2. Starting Network: usbus3. Starting Network: usbus4. add net default: gateway 202.249.25.1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 add net fe80::: gateway ::1 add net ff02::: gateway ::1 net.inet6.ip6.use_defaultzone: 0 -> 1 ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/kde4/lib /usr/local/lib/compat /usr/local/lib/event2 /usr/local/lib/expect5.44.1.15 /usr/local/lib/gcc46 /usr/local/lib/graphviz /usr/local/lib/mysql /usr/local/lib/qt4 32-bit compatibility ldconfig path: /usr/lib32 /usr/local/lib32/compat Creating and/or trimming log files. Starting syslogd. No core dumps found. Starting named. Clearing /tmp (X related). Recovering vi editor sessions:. Starting varnishncsa. Starting varnishlog. Starting varnishd. storage_file: filename: /tmp/varnish.c7NDZS size 3624 MB. Classic hash: 16383 buckets Using old SHMFILE Starting snmptrapd. Starting snmpd. /usr/local/share/snmp/snmpd.conf: line 141: Error: Already have an entry for this process. /usr/local/share/snmp/snmpd.conf: line 144: Error: Already have an entry for this process. /usr/local/share/snmp/snmpd.conf: line 147: Error: Already have an entry for this process. duplicate table data attempted to be entered. row exists Failed to register extend entry 'echotest' - possibly duplicate name. Starting local daemons:. Updating motd:. Starting ntpd. Starting rsyncd. Starting php_fpm. Starting ntop. Nov 28 16:13:01 sfc-monitor ntop[1525]: THREADMGMT[t34519151616]: ntop RUNSTATE: PREINIT(1) Nov 28 16:13:01 sfc-monitor ntop[1525]: THREADMGMT[t34519151616]: ntop RUNSTATE: INIT(2) Mon Nov 28 16:13:01 2011 NOTE: Interface merge enabled by default Mon Nov 28 16:13:01 2011 Initializing gdbm databases Nov 28 16:13:01 sfc-monitor ntop[1525]: Setting administrator password... Nov 28 16:13:01 sfc-monitor ntop[1525]: Admin password set... Nov 28 16:13:01 sfc-monitor ntop[1525]: ntop will be started as user nobody Nov 28 16:13:01 sfc-monitor ntop[1525]: ntop v.4.1.0 (64 bit) Nov 28 16:13:01 sfc-monitor ntop[1525]: Configured on Oct 20 2011 19:11:54, built on Oct 20 2011 19:12:11. Nov 28 16:13:01 sfc-monitor ntop[1525]: Copyright 1998-2011 by Luca Deri Nov 28 16:13:01 sfc-monitor ntop[1525]: Get the freshest ntop from http://www.ntop.org/ Nov 28 16:13:01 sfc-monitor ntop[1525]: NOTE: ntop is running from '/usr/local/bin' Nov 28 16:13:01 sfc-monitor ntop[1525]: NOTE: (but see warning on man page for the --instance parameter) Nov 28 16:13:01 sfc-monitor ntop[1525]: NOTE: ntop libraries are in '/usr/local/lib' Nov 28 16:13:01 sfc-monitor ntop[1525]: Initializing ntop em1: promiscuous mode enabled Nov 28 16:13:01 sfc-monitor ntop[1525]: Checking em1 for additional devices Nov 28 16:13:01 sfc-monitor ntop[1525]: Resetting traffic statistics for device em1 Nov 28 16:13:01 sfc-monitor ntop[1525]: Initializing device em1 (0) Nov 28 16:13:01 sfc-monitor ntop[1525]: DLT: Device 0 [em1] is 1, mtu 1514, header 14 Nov 28 16:13:01 sfc-monitor ntop[1525]: Initialized events [mask: 0][path: ] Nov 28 16:13:01 sfc-monitor ntop[1525]: Initializing gdbm databases Nov 28 16:13:02 sfc-monitor ntop[1525]: VENDOR: Loading MAC address table. Nov 28 16:13:02 sfc-monitor ntop[1525]: VENDOR: Checking for MAC address table file Nov 28 16:13:02 sfc-monitor ntop[1525]: VENDOR: File '/usr/local/etc/ntop/specialMAC.txt.gz' does not need to be reloaded Nov 28 16:13:02 sfc-monitor ntop[1525]: VENDOR: ntop continues ok Nov 28 16:13:02 sfc-monitor ntop[1525]: VENDOR: Checking for MAC address table file Nov 28 16:13:02 sfc-monitor ntop[1525]: VENDOR: File '/usr/local/etc/ntop/oui.txt.gz' does not need to be reloaded Nov 28 16:13:02 sfc-monitor ntop[1525]: VENDOR: ntop continues ok Nov 28 16:13:02 sfc-monitor ntop[1525]: Fingerprint: Loading signature file Nov 28 16:13:02 sfc-monitor ntop[1525]: Fingerprint: Checking for Fingerprint file... file Nov 28 16:13:02 sfc-monitor ntop[1525]: Fingerprint: Loading file '/usr/local/etc/ntop/etter.finger.os.gz' Nov 28 16:13:02 sfc-monitor ntop[1525]: Fingerprint: ...loaded 1765 records Nov 28 16:13:02 sfc-monitor ntop[1525]: INIT: Parent process is exiting (this is normal) Nov 28 16:13:02 sfc-monitor ntop[1526]: INIT: Bye bye: I'm becoming a daemon... Nov 28 16:13:02 sfc-monitor ntop[1526]: THREADMGMT[t34519151616]: Now running as a daemon Nov 28 16:13:02 sfc-monitor ntop[1526]: Initializing external applications Nov 28 16:13:02 sfc-monitor ntop[1526]: THREADMGMT[t34519154688]: SFP: Started thread for fingerprinting Nov 28 16:13:02 sfc-monitor ntop[1526]: THREADMGMT[t34519154688]: SFP: Fingerprint scan thread starting [p1526] Nov 28 16:13:02 sfc-monitor ntop[1526]: THREADMGMT[t34519155712]: SIH: Started thread for idle hosts detection Nov 28 16:13:02 sfc-monitor ntop[1526]: THREADMGMT[t34519156736]: DNSAR(1): Started thread for DNS address resolution Nov 28 16:13:02 sfc-monitor ntop[1526]: THREADMGMT[t34519155712]: SIH: Idle host scan thread starting [p1526] Nov 28 16:13:02 sfc-monitor ntop[1526]: THREADMGMT[t34519157760]: DNSAR(2): Started thread for DNS address resolution Nov 28 16:13:02 sfc-monitor ntop[1526]: THREADMGMT[t34519157760]: DNSAR(2): Address resolution thread running Nov 28 16:13:02 sfc-monitor ntop[1526]: THREADMGMT[t34519158784]: DNSAR(3): Started thread for DNS address resolution Nov 28 16:13:02 sfc-monitor ntop[1526]: THREADMGMT[t34519158784]: DNSAR(3): Address resolution thread running Nov 28 16:13:02 sfc-monitor ntop[1526]: THREADMGMT[t34519156736]: DNSAR(1): Address resolution thread running Nov 28 16:13:02 sfc-monitor ntop[1526]: Calling plugin start functions (if any) Starting sshd. Nov 28 16:13:02 sfc-monitor ntop[1526]: GeoIP: loaded config file /usr/local/etc/ntop/GeoLiteCity.dat Nov 28 16:13:02 sfc-monitor ntop[1526]: GeoIP: loaded ASN config file /usr/local/etc/ntop/GeoIPASNum.dat Nov 28 16:13:02 sfc-monitor ntop[1526]: SSL is present but https is disabled: use -W for enabling it Nov 28 16:13:02 sfc-monitor ntop[1526]: INITWEB: Initializing web server Nov 28 16:13:02 sfc-monitor ntop[1526]: INITWEB: Initializing TCP/IP socket connections for web server Nov 28 16:13:02 sfc-monitor ntop[1526]: INITWEB: Initialized socket, port 3000, address (any) Nov 28 16:13:02 sfc-monitor ntop[1526]: INITWEB: Waiting for HTTP connections on port 3000 Nov 28 16:13:02 sfc-monitor ntop[1526]: INITWEB: Starting web server Nov 28 16:13:02 sfc-monitor ntop[1526]: THREADMGMT[t34519159808]: INITWEB: Started thread for web server Nov 28 16:13:02 sfc-monitor ntop[1526]: Listening on [em1] Nov 28 16:13:02 sfc-monitor ntop[1526]: Loading Plugins Nov 28 16:13:02 sfc-monitor ntop[1526]: THREADMGMT[t34519159808]: WEB: Server connection thread starting [p1526] Nov 28 16:13:02 sfc-monitor ntop[1526]: Note: SIGPIPE handler set (ignore) Nov 28 16:13:02 sfc-monitor ntop[1526]: THREADMGMT[t34519159808]: WEB: Server connection thread running [p1526] Nov 28 16:13:02 sfc-monitor ntop[1526]: WEB: ntop's web server is now processing requests Nov 28 16:13:02 sfc-monitor ntop[1526]: Searching for plugins in /usr/local/lib/ntop/plugins Nov 28 16:13:02 sfc-monitor ntop[1526]: ICMP: Welcome to ICMPWatch. (C) 1999-2005 by Luca Deri Nov 28 16:13:02 sfc-monitor ntop[1526]: NETFLOW: Welcome to NetFlow.(C) 2002-11 by Luca Deri Nov 28 16:13:02 sfc-monitor ntop[1526]: CPACKET: Welcome to cPacket.(C) 2008 by Luca Deri Nov 28 16:13:02 sfc-monitor ntop[1526]: RRD: Welcome to Round-Robin Database. (C) 2002-11 by Luca Deri. Nov 28 16:13:02 sfc-monitor ntop[1526]: SFLOW: Welcome to sFlow.(C) 2002-11 by Luca Deri Nov 28 16:13:02 sfc-monitor ntop[1526]: Calling plugin start functions (if any) Nov 28 16:13:02 sfc-monitor ntop[1526]: RRD: Welcome to the RRD plugin Nov 28 16:13:02 sfc-monitor ntop[1526]: RRD: Mask for new directories is 0700 Nov 28 16:13:02 sfc-monitor ntop[1526]: RRD: Mask for new files is 0066 Nov 28 16:13:02 sfc-monitor ntop[1526]: THREADMGMT: RRD: Started thread (t34519160832) for data collection Nov 28 16:13:02 sfc-monitor ntop[1526]: THREADMGMT[t34519160832]: RRD: Data collection thread starting [p1526] Nov 28 16:13:02 sfc-monitor ntop[1526]: INIT: Created pid file (/var/run/ntop.pid) Nov 28 16:13:02 sfc-monitor ntop[1526]: THREADMGMT[t34519151616]: ntop RUNSTATE: INITNONROOT(3) Nov 28 16:13:02 sfc-monitor ntop[1526]: Now running as requested user 'nobody' (65534:65534) Nov 28 16:13:02 sfc-monitor ntop[1526]: Note: Reporting device initally set to 0 [em1] (merged) Nov 28 16:13:02 sfc-monitor ntop[1526]: THREADMGMT[t34519151616]: ntop RUNSTATE: RUN(4) Nov 28 16:13:02 sfc-monitor ntop[1526]: THREADMGMT[t34519161856]: NPS(1): Started thread for network packet sniffing [em1] Nov 28 16:13:02 sfc-monitor ntop[1526]: THREADMGMT[t34519161856]: NPS(em1): pcapDispatch thread starting [p1526] Nov 28 16:13:02 sfc-monitor ntop[1526]: THREADMGMT[t34519161856]: NPS(em1): pcapDispatch thread running [p1526] Nov 28 16:13:02 sfc-monitor ntop[1526]: THREADMGMT[t34519154688]: SFP: Fingerprint scan thread running [p1526] Nov 28 16:13:02 sfc-monitor ntop[1526]: THREADMGMT[t34519155712]: SIH: Idle host scan thread running [p1526] UNIVERSAL->import is deprecated and will be removed in a future perl at /usr/local/libexec/nfsen/Nfcomm.pm line 47 Starting nfcapd:(SFC-GATE)[1540] Starting nfsendUNIVERSAL->import is deprecated and will be removed in a future perl at /usr/local/libexec/nfsen/Nfcomm.pm line 47 . Starting mysql. Starting lighttpd. Configuring syscons: keymap blanktime. Starting sendmail. Starting cron. Nov 28 16:13:07 sfc-monitor ntop[1526]: CHKVER: Checking current ntop version at version.ntop.org/version.xml Starting background file system checks in 60 seconds. Mon Nov 28 16:13:07 JST 2011 Nov 28 16:13:08 sfc-monitor ntop[1526]: CHKVER: Version file is from 'version.ntop.org' Nov 28 16:13:08 sfc-monitor ntop[1526]: CHKVER: as of date is '2011-08-15T11:00:47' Nov 28 16:13:08 sfc-monitor ntop[1526]: CHKVER: This version of ntop is the CURRENT stable version Nov 28 16:13:12 sfc-monitor ntop[1526]: THREADMGMT[t34538466304]: RRD: Started thread for throughput data collection Nov 28 16:13:12 sfc-monitor ntop[1526]: THREADMGMT[t34538466304]: RRD: Throughput data collection: Thread starting [p1526] Nov 28 16:13:12 sfc-monitor ntop[1526]: THREADMGMT[t34519160832]: RRD: Data collection thread running [p1526] Nov 28 16:13:12 sfc-monitor ntop[1526]: THREADMGMT[t34538466304]: RRD: Throughput data collection: Thread running [p1526] Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 06 fault virtual address = 0x7a fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff808a0871 stack pointer = 0x28:0xffffff8344ee2870 frame pointer = 0x28:0xffffff8344ee2940 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 17 (syncer) trap number = 12 panic: page fault cpuid = 2 KDB: stack backtrace: #0 0xffffffff8067d30e at kdb_backtrace+0x5e #1 0xffffffff80647ec7 at panic+0x187 #2 0xffffffff8092bbb0 at trap_fatal+0x290 #3 0xffffffff8092bef9 at trap_pfault+0x1f9 #4 0xffffffff8092c3bf at trap+0x3df #5 0xffffffff809168ef at calltrap+0x8 #6 0xffffffff80877657 at ffs_syncvnode+0x1e7 #7 0xffffffff80871dd6 at ffs_sync+0x266 #8 0xffffffff806e94aa at sync_fsync+0x16a #9 0xffffffff806e9eee at sync_vnode+0x15e #10 0xffffffff806ea1e1 at sched_sync+0x1d1 #11 0xffffffff8061abff at fork_exit+0x11f #12 0xffffffff80916e1e at fork_trampoline+0xe Uptime: 2h37m40s Dumping 564 out of 8174 MB:..3%..12%..23%..32%..43%..52%..63%..71%..83%..91% ------------------------------------------------------------------------ kernel config options CONFIG_AUTOGENERATED ident MONITOR machine amd64 cpu HAMMER makeoptions DEBUG=-g options RADIX_MPATH options ZERO_COPY_SOCKETS options P1003_1B_MQUEUE options DEVICE_POLLING options VFS_AIO options MROUTING options HZ=1000 options USB_DEBUG options AHD_REG_PRETTY_PRINT options AHC_REG_PRETTY_PRINT options ATA_STATIC_ID options ATA_CAM options SMP options KDB_TRACE options KDB options INCLUDE_CONFIG_FILE options MAC options AUDIT options HWPMC_HOOKS options KBD_INSTALL_CDEV options PRINTF_BUFR_SIZE=128 options _KPOSIX_PRIORITY_SCHEDULING options P1003_1B_SEMAPHORES options SYSVSEM options SYSVMSG options SYSVSHM options STACK options KTRACE options SCSI_DELAY=5000 options COMPAT_FREEBSD7 options COMPAT_FREEBSD6 options COMPAT_FREEBSD5 options COMPAT_FREEBSD4 options COMPAT_FREEBSD32 options COMPAT_43TTY options GEOM_LABEL options GEOM_PART_GPT options PSEUDOFS options PROCFS options CD9660 options MSDOSFS options NFS_ROOT options NFSLOCKD options NFSSERVER options NFSCLIENT options MD_ROOT options UFS_GJOURNAL options UFS_DIRHASH options UFS_ACL options SOFTUPDATES options FFS options SCTP options INET6 options INET options PREEMPTION options SCHED_ULE options NEW_PCIB options GEOM_PART_MBR options GEOM_PART_EBR_COMPAT options GEOM_PART_EBR options GEOM_PART_BSD device isa device mem device io device uart_ns8250 device cpufreq device acpi device pci device fdc device ahci device ata device mvs device siis device ahc device ahd device amd device hptiop device isp device mpt device mps device sym device trm device adv device adw device aic device bt device scbus device ch device da device sa device cd device pass device ses device amr device arcmsr device ciss device dpt device hptmv device hptrr device iir device ips device mly device twa device aac device aacp device ida device mfi device mlx device twe device atkbdc device atkbd device psm device kbdmux device vga device splash device sc device agp device cbb device pccard device cardbus device uart device ppc device ppbus device lpt device plip device ppi device de device em device igb device ixgbe device le device ti device txp device vx device miibus device ae device age device alc device ale device bce device bfe device bge device dc device et device fxp device jme device lge device msk device nfe device nge device pcn device re device rl device sf device sge device sis device sk device ste device stge device tl device tx device vge device vr device wb device xl device loop device random device ether device vlan device tun device pty device md device gif device faith device firmware device bpf device uhci device ohci device ehci device usb device uhid device ukbd device ulpt device umass device ums device urio device uark device ubsa device uftdi device uipaq device uplcom device uslcom device uvisor device uvscom device aue device axe device cdce device cue device kue device rue device udav ------------------------------------------------------------------------ ddb capture buffer ddb: ddb_capture: kvm_nlist From owner-freebsd-current@FreeBSD.ORG Tue Nov 29 08:38:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5C4C106564A for ; Tue, 29 Nov 2011 08:38:16 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 89BDB8FC18 for ; Tue, 29 Nov 2011 08:38:16 +0000 (UTC) Received: by ggnk5 with SMTP id k5so8793183ggn.13 for ; Tue, 29 Nov 2011 00:38:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u55XzjsUxiORJdL0ct7aAs2gaVF4bpnqUK0YyaTeyw8=; b=LXZ1yI/vDypC1vze0iV2DAslY/M7be7XHfr1+Y6maEsF+b66xKd+BxVOJNABHN94rQ B/sj3a0i2xJz6QVyxmEDVEeLyLTukwU+Rb+KmI4paFGFQ0h5Ok/tzcRGNHpVse/XU9Mm tNktZ+RrMYIwQin6FTesnsQOuCbiyBqymhqxs= MIME-Version: 1.0 Received: by 10.182.40.65 with SMTP id v1mr3749004obk.72.1322555895749; Tue, 29 Nov 2011 00:38:15 -0800 (PST) Received: by 10.182.62.227 with HTTP; Tue, 29 Nov 2011 00:38:15 -0800 (PST) In-Reply-To: References: Date: Tue, 29 Nov 2011 00:38:15 -0800 Message-ID: From: Garrett Cooper To: dikshie Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 9.0-PRERELEASE panic 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, 29 Nov 2011 08:38:16 -0000 On Tue, Nov 29, 2011 at 12:05 AM, dikshie wrote: > Hi, > can some enlighten me what's happen in my FreeBSD-9.0 box. > > thanks! I'd check and make sure the filesystem isn't corrupt for starters. Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Nov 29 08:49:45 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE1971065672 for ; Tue, 29 Nov 2011 08:49:45 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5FB668FC15 for ; Tue, 29 Nov 2011 08:49:45 +0000 (UTC) Received: by eaai12 with SMTP id i12so4093531eaa.13 for ; Tue, 29 Nov 2011 00:49:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=FejyQgOPwPTECjaEHThRbE41QNZ93GtkGK3HTOjpl+w=; b=HPLizzke02ddX5vhcXgD9xNgOKA+2197D6WOcBWm3cOaXvhXtzrEdVGDLypyFPs8Fk jdNgjqTGvYje/GV5sYGTPd9PbE+1cFxllyo+ZztvmrIizB0HYlgyx9RobhSL5cdhvgAh dvY7GpqqGPKsD52d4nrS1O+hsfxNoyttQBzUk= Received: by 10.213.7.6 with SMTP id b6mr840024ebb.26.1322556584270; Tue, 29 Nov 2011 00:49:44 -0800 (PST) Received: from [192.168.50.101] (double-l.xs4all.nl. [80.126.205.144]) by mx.google.com with ESMTPS id q28sm103053595eea.6.2011.11.29.00.49.42 (version=SSLv3 cipher=OTHER); Tue, 29 Nov 2011 00:49:43 -0800 (PST) Message-ID: <4ED49CA4.6000502@gmail.com> Date: Tue, 29 Nov 2011 09:49:40 +0100 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: allan@stokes.ca, freebsd-current@freebsd.org References: <0168ab7579589d8d866ce8ff93544f1f.squirrel@sm.webmail.pair.com> In-Reply-To: <0168ab7579589d8d866ce8ff93544f1f.squirrel@sm.webmail.pair.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: upgrade issue 8.x to 9.0-RC2: libz.so.5 not found 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, 29 Nov 2011 08:49:45 -0000 allan@stokes.ca schreef: > However, programs such as startx and portupgrade are failing with the > message "libz.so.5 not found". I know I can fix this with an evil > symlink, but that doesn't seem right, and what else is broken? Is there > not a facility in portupgrade to scan my live dependencies and warn me of > breakage? I have not encountered such a beast in my gleanings to date. What you probably did is make delete-old-libs. This deletes the old 8.x libs that where used by your ports. What you need to do is rebuild all your ports. That way they get linked to the proper libs again. The next time when you go from one major to another major number eg from 7 to 8 or from 8 to 9 and so on, is to do the make delete-old-libs step later. Then after upgrading, rebuild all your ports, they still work with the old libs. Once the ports are rebuild against the newer libs then do the make delete-old-libs step. This is not nessacery when going from a minor number to amother minor number. eg from 8.1 to 8.2 and so on. Hope this helps. regards Johan Hendriks From owner-freebsd-current@FreeBSD.ORG Tue Nov 29 08:54:34 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEC7D106564A for ; Tue, 29 Nov 2011 08:54:34 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8FC988FC17 for ; Tue, 29 Nov 2011 08:54:34 +0000 (UTC) Received: by ywp17 with SMTP id 17so6663414ywp.13 for ; Tue, 29 Nov 2011 00:54:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=jbjZXDp4bJLKlWj2mHjWNuq8TOha8qN0onavK/hJJAg=; b=ExR+30Oq2WljV4Kzsq5T5mgNPyCtQ+mEfBHVuHYQzyalln5YoPDa3rLlCeDRxVnJlx qb0T9CSDvXCEIFtY9YaQP9O/710Z0HqWjblFaH2OO4eBY9aM0BQAdGu1bpg5NfoT9YGn P75H5674xyolceb7BxIHQRwbF/ey9os6DheEQ= MIME-Version: 1.0 Received: by 10.182.5.166 with SMTP id t6mr3047459obt.2.1322556873841; Tue, 29 Nov 2011 00:54:33 -0800 (PST) Received: by 10.182.62.227 with HTTP; Tue, 29 Nov 2011 00:54:33 -0800 (PST) In-Reply-To: <4ED49CA4.6000502@gmail.com> References: <0168ab7579589d8d866ce8ff93544f1f.squirrel@sm.webmail.pair.com> <4ED49CA4.6000502@gmail.com> Date: Tue, 29 Nov 2011 00:54:33 -0800 Message-ID: From: Garrett Cooper To: Johan Hendriks Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: allan@stokes.ca, freebsd-current@freebsd.org Subject: Re: upgrade issue 8.x to 9.0-RC2: libz.so.5 not found 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, 29 Nov 2011 08:54:34 -0000 On Tue, Nov 29, 2011 at 12:49 AM, Johan Hendriks w= rote: > allan@stokes.ca schreef: >> >> However, programs such as startx and portupgrade are failing with the >> message "libz.so.5 not found". =A0I know I can fix this with an evil >> symlink, but that doesn't seem right, and what else is broken? =A0Is the= re >> not a facility in portupgrade to scan my live dependencies and warn me o= f >> breakage? =A0I have not encountered such a beast in my gleanings to date= . > > What you probably did is make delete-old-libs. > This deletes the old 8.x libs that where used by your ports. > What you need to do is rebuild all your ports. > > That way they get linked to the proper libs again. > > The next time when you go from one major to another major number eg from = 7 > to 8 or from 8 to 9 and so on, is to do the make delete-old-libs step lat= er. > Then after upgrading, rebuild all your ports, they still work with the ol= d > libs. > Once the ports are rebuild against the newer libs then do the make > delete-old-libs step. > > This is not nessacery when going from a minor number to amother minor > number. eg from 8.1 to 8.2 and so on. In general yes.. but there have been occasions when this was required with libz... Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Nov 29 08:59:50 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D70D1065677 for ; Tue, 29 Nov 2011 08:59:50 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5586A8FC08; Tue, 29 Nov 2011 08:59:50 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pAT8xoQE072424; Tue, 29 Nov 2011 08:59:50 GMT (envelope-from bapt@FreeBSD.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pAT8xo6D072423; Tue, 29 Nov 2011 08:59:50 GMT (envelope-from bapt@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@FreeBSD.org using -f Date: Tue, 29 Nov 2011 09:59:46 +0100 From: Baptiste Daroussin To: Max Khon Message-ID: <20111129085946.GD6680@azathoth.lan> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hxkXGo8AKqTJ+9QI" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current Subject: Re: removing libreadline from base system 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, 29 Nov 2011 08:59:50 -0000 --hxkXGo8AKqTJ+9QI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 29, 2011 at 12:02:23PM +0700, Max Khon wrote: > Hello! >=20 > It is possible to build and link our in-tree gdb & friends with libedit > after r228114. >=20 > The remaining question is what to do with libreadline: >=20 > 1) just build & link gdb with libedit >=20 > OR >=20 > 2) re-import libreadline from gdb sources and build INTERNALLIB version of > it that is never installed and is linked only to gdb >=20 > I am inclined to go for 1) but libedit may have (and has) incompatibiliti= es > with libreadline. >=20 > Max Back when I sent a libedit upgrade patch, before obrien update libedit on h= is own, I managed to build the whole tree with libedit, gdb, ntpc and others w= ere fully functionnal with it, (at that time I totally removed libreadline) The only "problem" I see is from the ports lots of them relies on base libreadline, so we need to first run an exp-run without libreadline, to determine the impact and fix the related ports, before we can fully dropped libreadline. regards, Bapt --hxkXGo8AKqTJ+9QI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7UnwIACgkQ8kTtMUmk6EyeRwCdHDHZJLO4fKOV0ahmK75q9X+i 8y0AoJpMf/helBFWj6P0aRHBwk2471m0 =A5xZ -----END PGP SIGNATURE----- --hxkXGo8AKqTJ+9QI-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 29 09:08:10 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A560A1065670 for ; Tue, 29 Nov 2011 09:08:10 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id 5B73C8FC08 for ; Tue, 29 Nov 2011 09:08:10 +0000 (UTC) Received: from ncsc.bris.ac.uk ([137.222.10.41]) by dirg.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1RVJfC-00015F-Bb; Tue, 29 Nov 2011 09:07:52 +0000 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncsc.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RVJeY-000273-Gn; Tue, 29 Nov 2011 09:07:02 +0000 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5) with ESMTP id pAT972bW069592; Tue, 29 Nov 2011 09:07:02 GMT (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5/Submit) id pAT972Rr069591; Tue, 29 Nov 2011 09:07:02 GMT (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Tue, 29 Nov 2011 09:07:02 +0000 From: Anton Shterenlikht To: Garrett Cooper Message-ID: <20111129090702.GA69561@mech-cluster241.men.bris.ac.uk> Mail-Followup-To: Garrett Cooper , Johan Hendriks , allan@stokes.ca, freebsd-current@freebsd.org References: <0168ab7579589d8d866ce8ff93544f1f.squirrel@sm.webmail.pair.com> <4ED49CA4.6000502@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Johan Hendriks , allan@stokes.ca, freebsd-current@freebsd.org Subject: Re: upgrade issue 8.x to 9.0-RC2: libz.so.5 not found 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, 29 Nov 2011 09:08:10 -0000 On Tue, Nov 29, 2011 at 12:54:33AM -0800, Garrett Cooper wrote: > On Tue, Nov 29, 2011 at 12:49 AM, Johan Hendriks wrote: > > allan@stokes.ca schreef: > >> > >> However, programs such as startx and portupgrade are failing with the > >> message "libz.so.5 not found".  I know I can fix this with an evil > >> symlink, but that doesn't seem right, and what else is broken?  Is there > >> not a facility in portupgrade to scan my live dependencies and warn me of > >> breakage?  I have not encountered such a beast in my gleanings to date. > > > > What you probably did is make delete-old-libs. > > This deletes the old 8.x libs that where used by your ports. > > What you need to do is rebuild all your ports. > > > > That way they get linked to the proper libs again. > > > > The next time when you go from one major to another major number eg from 7 > > to 8 or from 8 to 9 and so on, is to do the make delete-old-libs step later. > > Then after upgrading, rebuild all your ports, they still work with the old > > libs. > > Once the ports are rebuild against the newer libs then do the make > > delete-old-libs step. > > > > This is not nessacery when going from a minor number to amother minor > > number. eg from 8.1 to 8.2 and so on. > > In general yes.. but there have been occasions when this was > required with libz... I use sisutils/libchk: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/make-delete-old.html -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Tue Nov 29 09:16:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9176E10656D7 for ; Tue, 29 Nov 2011 09:16:52 +0000 (UTC) (envelope-from dikshie@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0E11F8FC16 for ; Tue, 29 Nov 2011 09:16:51 +0000 (UTC) Received: by ggnk5 with SMTP id k5so8839934ggn.13 for ; Tue, 29 Nov 2011 01:16:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=Puh6c7Xw6reskt13VN6Fba4qBC2Tk1kqNEdVhWHF65o=; b=vCaGYyal5sQKONy+KAJjUgHqAS439J+82Xovy32+GIH9XiQf+rArpIDbXV8xgR65iM tajZcl3qNjwbBzWCgy9yDbF/xpur/t2jEE9575/1TnVsap5oiaVHLLVUaqX9vzBelRln ZDMAJ8mE3Iq3pdyl7wdPjuTc7olikWLn/EGhA= Received: by 10.182.73.71 with SMTP id j7mr13235846obv.55.1322558211506; Tue, 29 Nov 2011 01:16:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.47.193 with HTTP; Tue, 29 Nov 2011 01:10:08 -0800 (PST) In-Reply-To: References: From: dikshie Date: Tue, 29 Nov 2011 18:10:09 +0900 Message-ID: To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: FreeBSD 9.0-PRERELEASE panic 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, 29 Nov 2011 09:16:52 -0000 On Tue, Nov 29, 2011 at 5:38 PM, Garrett Cooper wrote: > I'd check and make sure the filesystem isn't corrupt for starters. > Cheers, well, I did fsck -fy in single user before copy paste /var/crash/core.txt.5 to this mailing list. -dikshie- From owner-freebsd-current@FreeBSD.ORG Tue Nov 29 09:37:09 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 530291065673 for ; Tue, 29 Nov 2011 09:37:09 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 82A318FC1E for ; Tue, 29 Nov 2011 09:37:08 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA24908; Tue, 29 Nov 2011 11:37:04 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RVK7c-0000im-DY; Tue, 29 Nov 2011 11:37:04 +0200 Message-ID: <4ED4A7BF.4090508@FreeBSD.org> Date: Tue, 29 Nov 2011 11:37:03 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Johan Hendriks , allan@stokes.ca References: <0168ab7579589d8d866ce8ff93544f1f.squirrel@sm.webmail.pair.com> <4ED49CA4.6000502@gmail.com> In-Reply-To: <4ED49CA4.6000502@gmail.com> X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: upgrade issue 8.x to 9.0-RC2: libz.so.5 not found 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, 29 Nov 2011 09:37:09 -0000 on 29/11/2011 10:49 Johan Hendriks said the following: > What you probably did is make delete-old-libs. > This deletes the old 8.x libs that where used by your ports. > What you need to do is rebuild all your ports. In my experience installing misc/compat8x was sufficient. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Nov 29 09:46:31 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EB22106564A; Tue, 29 Nov 2011 09:46:31 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id D55AA8FC08; Tue, 29 Nov 2011 09:46:30 +0000 (UTC) Received: by ywp17 with SMTP id 17so6732066ywp.13 for ; Tue, 29 Nov 2011 01:46:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.89.39 with SMTP id bl7mr2397467obb.43.1322559990126; Tue, 29 Nov 2011 01:46:30 -0800 (PST) Received: by 10.182.76.225 with HTTP; Tue, 29 Nov 2011 01:46:30 -0800 (PST) X-Originating-IP: [93.92.220.178] In-Reply-To: <20111129085946.GD6680@azathoth.lan> References: <20111129085946.GD6680@azathoth.lan> Date: Tue, 29 Nov 2011 16:46:30 +0700 Message-ID: From: Max Khon To: Baptiste Daroussin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current Subject: Re: removing libreadline from base system 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, 29 Nov 2011 09:46:31 -0000 Baptiste, On Tue, Nov 29, 2011 at 3:59 PM, Baptiste Daroussin wrote: > It is possible to build and link our in-tree gdb & friends with libedit > > after r228114. > > > > The remaining question is what to do with libreadline: > > > > 1) just build & link gdb with libedit > > > > OR > > > > 2) re-import libreadline from gdb sources and build INTERNALLIB version > of > > it that is never installed and is linked only to gdb > > > > I am inclined to go for 1) but libedit may have (and has) > incompatibilities > > with libreadline. > > Back when I sent a libedit upgrade patch, before obrien update libedit on > his > own, I managed to build the whole tree with libedit, gdb, ntpc and others > were > fully functionnal with it, (at that time I totally removed libreadline) > The whole src tree now builds without libreadline. > The only "problem" I see is from the ports lots of them relies on base > libreadline, so we need to first run an exp-run without libreadline, to > determine the impact and fix the related ports, before we can fully dropped > libreadline. > This is a separate issue that I want to handle separately. The question is what to do with gdb & friends. Link it with libedit or re-import bundled readline (that is shipped with gdb) and build/link it only to gdb. I am inclined to do the former. Max From owner-freebsd-current@FreeBSD.ORG Tue Nov 29 10:34:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 476121065670 for ; Tue, 29 Nov 2011 10:34:17 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1411F8FC13; Tue, 29 Nov 2011 10:34:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pATAYGdp069562; Tue, 29 Nov 2011 10:34:16 GMT (envelope-from bapt@freebsd.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pATAYGlR069560; Tue, 29 Nov 2011 10:34:16 GMT (envelope-from bapt@freebsd.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@freebsd.org using -f Date: Tue, 29 Nov 2011 11:34:13 +0100 From: Baptiste Daroussin To: Max Khon Message-ID: <20111129103413.GF6680@azathoth.lan> References: <20111129085946.GD6680@azathoth.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TU+u6i6jrDPzmlWF" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current Subject: Re: removing libreadline from base system 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, 29 Nov 2011 10:34:17 -0000 --TU+u6i6jrDPzmlWF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 29, 2011 at 04:46:30PM +0700, Max Khon wrote: > Baptiste, >=20 > On Tue, Nov 29, 2011 at 3:59 PM, Baptiste Daroussin wro= te: >=20 > > It is possible to build and link our in-tree gdb & friends with libedit > > > after r228114. > > > > > > The remaining question is what to do with libreadline: > > > > > > 1) just build & link gdb with libedit > > > > > > OR > > > > > > 2) re-import libreadline from gdb sources and build INTERNALLIB versi= on > > of > > > it that is never installed and is linked only to gdb > > > > > > I am inclined to go for 1) but libedit may have (and has) > > incompatibilities > > > with libreadline. > > > > Back when I sent a libedit upgrade patch, before obrien update libedit = on > > his > > own, I managed to build the whole tree with libedit, gdb, ntpc and othe= rs > > were > > fully functionnal with it, (at that time I totally removed libreadline) > > >=20 > The whole src tree now builds without libreadline. >=20 >=20 > > The only "problem" I see is from the ports lots of them relies on base > > libreadline, so we need to first run an exp-run without libreadline, to > > determine the impact and fix the related ports, before we can fully dro= pped > > libreadline. > > >=20 > This is a separate issue that I want to handle separately. >=20 > The question is what to do with gdb & friends. Link it with libedit or > re-import bundled readline (that is shipped with gdb) and build/link it > only to gdb. >=20 > I am inclined to do the former. >=20 > Max linking to libedit is the right way imho. regards, Bapt --TU+u6i6jrDPzmlWF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7UtSUACgkQ8kTtMUmk6EziYQCgvSvYG8LXwhJEGcXibTrJ1A/E zDkAmQEHku2QGaehVXcDzyp5AMt8jQK7 =a0DF -----END PGP SIGNATURE----- --TU+u6i6jrDPzmlWF-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 29 10:12:25 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E3EC106564A for ; Tue, 29 Nov 2011 10:12:25 +0000 (UTC) (envelope-from talon@lpthe.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 1F80E8FC16 for ; Tue, 29 Nov 2011 10:12:24 +0000 (UTC) Received: from parthe.lpthe.jussieu.fr (parthe.lpthe.jussieu.fr [134.157.10.1]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id pAT9jld6050040 for ; Tue, 29 Nov 2011 10:45:47 +0100 (CET) X-Ids: 164 Received: from [192.168.1.10] (niobe.lpthe.jussieu.fr [134.157.10.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by parthe.lpthe.jussieu.fr (Postfix) with ESMTPSA id 427EB20355 for ; Tue, 29 Nov 2011 10:45:46 +0100 (CET) From: Michel Talon Date: Tue, 29 Nov 2011 10:45:41 +0100 Message-Id: <11D0FEA5-53E1-4EAA-B94B-F58282A073E3@lpthe.jussieu.fr> To: freebsd-current Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) X-Miltered: at jchkmail.jussieu.fr with ID 4ED4A9CB.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4ED4A9CB.001/134.157.10.1/parthe.lpthe.jussieu.fr/parthe.lpthe.jussieu.fr/ X-Mailman-Approved-At: Tue, 29 Nov 2011 12:17:57 +0000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: removing libreadline from base system 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, 29 Nov 2011 10:12:25 -0000 >The only "problem" I see is from the ports lots of them relies on base >libreadline, so we need to first run an exp-run without libreadline, to >determine the impact and fix the related ports, before we can fully = drop >libreadline. One of the first port to consider, i think, is rlwrap. Some time ago i = had to compile it on a mac (which is equipped with libedit in place of = libreadline) and it had problems since it calls functions in libreadline = not in libedit . So i was forced to also compile libreadline.=20 -- Michel Talon talon@lpthe.jussieu.fr From owner-freebsd-current@FreeBSD.ORG Tue Nov 29 14:28:44 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C3581065675 for ; Tue, 29 Nov 2011 14:28:44 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 997D48FC12 for ; Tue, 29 Nov 2011 14:28:43 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pATESgtX077233; Tue, 29 Nov 2011 18:28:42 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pATESgUm077232; Tue, 29 Nov 2011 18:28:42 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 29 Nov 2011 18:28:42 +0400 From: Gleb Smirnoff To: Daan Vreeken Message-ID: <20111129142842.GC44498@glebius.int.ru> References: <201111240928.51162.Daan@vitsch.nl> <20111125131935.GP96616@FreeBSD.org> <20111125143257.GR96616@FreeBSD.org> <201111290107.13631.Daan@vitsch.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <201111290107.13631.Daan@vitsch.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Current Subject: Re: if_clone.c allows creating multiple interfaces with the same name 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, 29 Nov 2011 14:28:44 -0000 Daan, On Tue, Nov 29, 2011 at 01:07:13AM +0100, Daan Vreeken wrote: D> Thanks for the looking into this and for your quick commit. I like your twist D> on the patch with the move from the unit bitmap to allocating unit numbers D> with alloc_unr(9). D> D> I do have two comments on the new code though. D> Before, in the !wildcard case, ifc_alloc_unit() would return ENOSPC when the D> user requested a unit number larger than ifc->ifc_maxunit. Now the function D> returns EEXIST in that case because alloc_unr_specific() returns -1 both D> when a number is already allocated and when the number exceeds it's limits. D> This leads to the somewhat confusing: D> D> # ifconfig bridge123456 create D> ifconfig: SIOCIFCREATE2: File exists D> D> Apart from that I'm a bit worried about the "/* XXXGL: yep, it's a unit leak D> */" part of your change. Once a unit number is leaked, there currently seems D> to be no way to ever get it back. In a worst case scenario, where the names of D> multiple interfaces in a row collides with the numbers alloc_unr() returns, an D> entire row of unit numbers could be leaked during the creation of a single D> cloned interface. D> We have a product where cloned interfaces come and go very frequently. I'd D> hate to run out of unit numbers after 'just a few' years of uptime ;-) D> D> I've created a new patch on top of your change that fixes both of these D> problems. Could you have a look at the attached diff? Thanks, I will work on applying it. D> > Considering the second part, that adds locking. Unfortunately, right now we D> > have numerous races in the network configuration ocde. Many SIOCSsomething D> > ioctls can race with each other producing unpredictable results and kernel D> > panics. So, running two ifconfig(8) in parallel is a bad idea today. :( D> > Your patch with IFNET_NAMING_LOCK() just plumbs one race case: a race D> > between two SIOCSIFNAME ioctls. And it doesn't plumb a race between D> > SIOCSIFNAME vs SIOCIFCREATE, because IFNET_NAMING_LOCK() is dropped after D> > unit allocation, but prior to interface attachement to global interface D> > list. D> D> Are you sure? With the patch in the PR, the relevant code in D> ifc_simple_create() would become : D> D> ... D> IFNET_NAMING_LOCK(); D> err = ifc_alloc_unit(ifc, &unit); D> if (err != 0) { D> IFNET_NAMING_UNLOCK(); D> return (err); D> } D> D> err = ifcs->ifcs_create(ifc, unit, params); D> IFNET_NAMING_UNLOCK(); D> if (err != 0) { D> ifc_free_unit(ifc, unit); D> return (err); D> } D> ... D> D> The lock is acquired before the call to ifc_alloc_unit(). D> In the non-error case (e.g. when creating an if_bridge interface) the call D> ends up calling bridge_clone_create(), which calls ether_ifattach(), which D> calls if_attach() -> if_attach_internal() where the ifp is added to the ifnet D> list. D> Only when that's done, the lock is dropped. D> D> Am I overlooking something obvious here? The code above isn't correct since it holds mutex when calling ifcs->ifcs_create(). These methods may (they actually do) call malloc() with M_WAITOK. In general FreeBSD uses M_WAITOK on the configuration code paths, like any SIOCSsomething ioctl. So to do correct protection, you first need to allocate every kind of memory needed, then lock mutex, then run through configuration sequence, then release mutex and in case of error free all allocated memory. Sounds easy, but isn't in practice, especially when several network modules are involved. So I'm still thinking about... D> > From my point of view, we need a generic approach to ioctl() vs ioctl() D> > races, may be some global serializer of all re-configuration requests of D> > interfaces and addresses. ... but several developers have noted that this approach may have some hidden problems. When experimenting with new CARP, I have tried it on the carp_ioctl() without any problems. The idea is simple: static int serializer = 0; static struct mtx serializer_mtx; MTX_SYSINIT("sermtx", &serializer_mtx, "ioctl serializer mutex", MTX_DEF); int foo_ioctl() { mtx_lock(&serializer_mtx); if (serializer != 0) msleep(&serializer, &serializer_mtx, 0, "ioctl", 0); serializer = 1; mtx_unlock(&serializer_mtx); ... any code here, uncluding calls to different lower layers... mtx_lock(&serializer_mtx); serializer = 0; wakeup(&serializer); mtx_unlock(&serializer_mtx); return (error); } I have tried this for carp_ioctl() and it worked fine. You can try it for entire ifioctl() and all its descendants, but be aware of hidden problems :) -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Tue Nov 29 15:18:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1FE8106566B for ; Tue, 29 Nov 2011 15:18:08 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 4109C8FC15 for ; Tue, 29 Nov 2011 15:18:08 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RVPRc-0002o2-CT for freebsd-current@freebsd.org; Tue, 29 Nov 2011 16:18:04 +0100 Received: from office-nat.spylog.net ([193.169.234.6]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 29 Nov 2011 16:18:04 +0100 Received: from citrin by office-nat.spylog.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 29 Nov 2011 16:18:04 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Anton Yuzhaninov Date: Tue, 29 Nov 2011 15:17:47 +0000 (UTC) Organization: Vega Lines: 35 Sender: Anton Yuzhaninov Message-ID: X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: office-nat.spylog.net User-Agent: tin/1.9.6-20101126 ("Burnside") (UNIX) (FreeBSD/10.0-CURRENT (i386)) Subject: panic on reboot (geli+glabel) 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, 29 Nov 2011 15:18:08 -0000 After upgrade to r228059 my system panics on each reboot. (kgdb) bt #0 doadump (textdump=0) at pcpu.h:244 #1 0xc04a5c31 in db_dump (dummy=-1067276850, dummy2=0, dummy3=-1, dummy4=0xc4a0996c "") at /usr/src/sys/ddb/db_command.c:537 #2 0xc04a5713 in db_command (last_cmdp=0xc094b2bc, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:448 #3 0xc04a5842 in db_command_loop () at /usr/src/sys/ddb/db_command.c:501 #4 0xc04a765f in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229 #5 0xc066fcab in kdb_trap (type=12, code=0, tf=0xc4a09bec) at /usr/src/sys/kern/subr_kdb.c:625 #6 0xc084561e in trap_fatal (frame=0xc4a09bec, eva=4026593588) at /usr/src/sys/i386/i386/trap.c:966 #7 0xc0845980 in trap_pfault (frame=0xc4a09bec, usermode=0, eva=4026593588) at /usr/src/sys/i386/i386/trap.c:888 #8 0xc084686f in trap (frame=0xc4a09bec) at /usr/src/sys/i386/i386/trap.c:558 #9 0xc083012c in calltrap () at /usr/src/sys/i386/i386/exception.s:168 #10 0xc062a5ce in _mtx_lock_sleep (m=0x0, tid=3302765280, opts=Variable "opts" is not available. ) at /usr/src/sys/kern/kern_mutex.c:370 #11 0xc05d65f3 in g_vfs_orphan (cp=0xc5152900) at /usr/src/sys/geom/geom_vfs.c:174 #12 0xc05d15eb in g_run_events () at /usr/src/sys/geom/geom_event.c:211 #13 0xc05d2a7e in g_event_procbody (arg=0x0) at /usr/src/sys/geom/geom_kern.c:122 #14 0xc060dc49 in fork_exit (callout=0xc05d2a14 , arg=0x0, frame=0xc4a09d28) at /usr/src/sys/kern/kern_fork.c:995 #15 0xc08301d4 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:275 (kgdb) f 11 #11 0xc05d65f3 in g_vfs_orphan (cp=0xc5152900) at /usr/src/sys/geom/geom_vfs.c:174 174 mtx_lock(&sc->sc_mtx); (kgdb) p *cp->geom $8 = {name = 0xc50f2b60 "ffs.label/spool2.eli", class = 0xc0912880, geom = {le_next = 0xc518a980, le_prev = 0xc09128d0}, consumer = {lh_first = 0xc5152900}, provider = { lh_first = 0x0}, geoms = {tqe_next = 0x0, tqe_prev = 0xc5269d98}, rank = 5, start = 0, spoiled = 0, attrchanged = 0, dumpconf = 0, access = 0, orphan = 0xc05d6588 , ioctl = 0, spare0 = 0x0, spare1 = 0x0, softc = 0x0, flags = 1} crashinfo: http://dl.dropbox.com/u/8798217/tmp/core.txt.0.gz -- Anton Yuzhaninov From owner-freebsd-current@FreeBSD.ORG Tue Nov 29 15:58:55 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3990E106564A for ; Tue, 29 Nov 2011 15:58:55 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id EA67D8FC14 for ; Tue, 29 Nov 2011 15:58:54 +0000 (UTC) Received: by qyg36 with SMTP id 36so5782656qyg.13 for ; Tue, 29 Nov 2011 07:58:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DbrHMGAsab+1laym+ItOTnzlAJEGDmPrN3eqRR/1PvI=; b=wvooA12MyRijgpZUl9+U8nJGM5qd1wmytPaO1sIw3qnT0SsT+3AuCU1vQSlBW9wVtZ TgsYbFJT6b9QG9PGXGuDCTlr5f182L8TjGN0KI206dIFTroSa72MyUh0ca4rQZFQJlMr Rb72gKI1364I2eoovZATPtyzDnk8IXyzTVNU0= MIME-Version: 1.0 Received: by 10.182.31.68 with SMTP id y4mr10034607obh.66.1322580603936; Tue, 29 Nov 2011 07:30:03 -0800 (PST) Received: by 10.182.142.101 with HTTP; Tue, 29 Nov 2011 07:30:03 -0800 (PST) In-Reply-To: <20111126084402.1afbfc16@atom.dino.sk> References: <20111126084402.1afbfc16@atom.dino.sk> Date: Tue, 29 Nov 2011 18:30:03 +0300 Message-ID: From: Sergey Kandaurov To: Milan Obuch Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Incorrect tag= in /usr/src/share/examples/cvsup/sta(ble|ndard) in 9.0-PRERELEASE? 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, 29 Nov 2011 15:58:55 -0000 On 26 November 2011 11:44, Milan Obuch wrote: > Hi, > > I am playing a bit with 9.0-PRERELEASE compiling it from source updated > via csup. In both example files there is line specifying what to csup > > *default release=cvs tag=RELENG_8 > > which is incorrect, I think. It is convenient for me to issue just > > csup -h cvsup.freebsd.sk /usr/share/examples/cvsup/stable-supfile > > to update full sources without need to create any cvsup config file, > however in system installed from 9.0 snapshot (maybe two weeks old) > this file points to version 8 files, so I need to correct it for > 9.0-PRERELEASE to not accidentally download older version sources. > > The same is also true after upgrade from source - make installworld > install example files pointing to older version... > > Is it something I do not know about or is it an oversight? I think this > line should already be changed to new tag... > > *default release=cvs tag=RELENG_9 Hi. Fixed. Thanks for your report. Now cvs tag points to RELENG_9 in 9.x sources. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Tue Nov 29 16:22:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A58CE106564A for ; Tue, 29 Nov 2011 16:22:40 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 579C48FC27 for ; Tue, 29 Nov 2011 16:22:40 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so2864886vbb.13 for ; Tue, 29 Nov 2011 08:22:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LwOo9pBfNfHz64TDyRUAHZWxe/aKzXh8Dnzl4N5KkLA=; b=gqLvpgdNa/+Eb0UDi2hlSVEEyP+jz1jkXG0wcQ4ejZ0MQqcFijrgPOLwSFoK3JUTds tHjnSOT0vvCPBdizqxuc+kN2DB4kSU036efo4jj5HxO6i3D6zdrmjXa36K4q4WdUMdpQ R1H8j5Dxs4UNGKoYZ5Ej/xTwCX8lUPx7JBzOk= MIME-Version: 1.0 Received: by 10.182.31.68 with SMTP id y4mr10086842obh.66.1322583759468; Tue, 29 Nov 2011 08:22:39 -0800 (PST) Received: by 10.182.142.101 with HTTP; Tue, 29 Nov 2011 08:22:39 -0800 (PST) In-Reply-To: References: <20111126084402.1afbfc16@atom.dino.sk> Date: Tue, 29 Nov 2011 19:22:39 +0300 Message-ID: From: Sergey Kandaurov To: Maxim Khitrov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, Milan Obuch Subject: Re: Incorrect tag= in /usr/src/share/examples/cvsup/sta(ble|ndard) in 9.0-PRERELEASE? 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, 29 Nov 2011 16:22:40 -0000 On 29 November 2011 20:16, Maxim Khitrov wrote: > On Tue, Nov 29, 2011 at 10:30 AM, Sergey Kandaurov wrote: >> On 26 November 2011 11:44, Milan Obuch wrote: >>> Hi, >>> >>> I am playing a bit with 9.0-PRERELEASE compiling it from source updated >>> via csup. In both example files there is line specifying what to csup >>> >>> *default release=cvs tag=RELENG_8 >>> >>> which is incorrect, I think. It is convenient for me to issue just >>> >>> csup -h cvsup.freebsd.sk /usr/share/examples/cvsup/stable-supfile >>> >>> to update full sources without need to create any cvsup config file, >>> however in system installed from 9.0 snapshot (maybe two weeks old) >>> this file points to version 8 files, so I need to correct it for >>> 9.0-PRERELEASE to not accidentally download older version sources. >>> >>> The same is also true after upgrade from source - make installworld >>> install example files pointing to older version... >>> >>> Is it something I do not know about or is it an oversight? I think this >>> line should already be changed to new tag... >>> >>> *default release=cvs tag=RELENG_9 >> >> Hi. >> >> Fixed. Thanks for your report. >> Now cvs tag points to RELENG_9 in 9.x sources. > > Should standard-supfile also be updated to point to RELENG_9_0? I'm > using csup with "tag=RELENG_9_0" and standard-supfile still points to > HEAD. Yep, sure. I just sent a request to the Release Engineering Team. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Tue Nov 29 16:44:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22A011065670 for ; Tue, 29 Nov 2011 16:44:23 +0000 (UTC) (envelope-from max@mxcrypt.com) Received: from mail-qw0-f47.google.com (mail-qw0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id DC5178FC0A for ; Tue, 29 Nov 2011 16:44:22 +0000 (UTC) Received: by qaea17 with SMTP id a17so2407316qae.13 for ; Tue, 29 Nov 2011 08:44:22 -0800 (PST) Received: by 10.224.181.141 with SMTP id by13mr22680477qab.1.1322583398462; Tue, 29 Nov 2011 08:16:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.98.74 with HTTP; Tue, 29 Nov 2011 08:16:07 -0800 (PST) In-Reply-To: References: <20111126084402.1afbfc16@atom.dino.sk> From: Maxim Khitrov Date: Tue, 29 Nov 2011 11:16:07 -0500 Message-ID: To: Sergey Kandaurov Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org, Milan Obuch Subject: Re: Incorrect tag= in /usr/src/share/examples/cvsup/sta(ble|ndard) in 9.0-PRERELEASE? 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, 29 Nov 2011 16:44:23 -0000 On Tue, Nov 29, 2011 at 10:30 AM, Sergey Kandaurov wrote: > On 26 November 2011 11:44, Milan Obuch wrote: >> Hi, >> >> I am playing a bit with 9.0-PRERELEASE compiling it from source updated >> via csup. In both example files there is line specifying what to csup >> >> *default release=cvs tag=RELENG_8 >> >> which is incorrect, I think. It is convenient for me to issue just >> >> csup -h cvsup.freebsd.sk /usr/share/examples/cvsup/stable-supfile >> >> to update full sources without need to create any cvsup config file, >> however in system installed from 9.0 snapshot (maybe two weeks old) >> this file points to version 8 files, so I need to correct it for >> 9.0-PRERELEASE to not accidentally download older version sources. >> >> The same is also true after upgrade from source - make installworld >> install example files pointing to older version... >> >> Is it something I do not know about or is it an oversight? I think this >> line should already be changed to new tag... >> >> *default release=cvs tag=RELENG_9 > > Hi. > > Fixed. Thanks for your report. > Now cvs tag points to RELENG_9 in 9.x sources. Should standard-supfile also be updated to point to RELENG_9_0? I'm using csup with "tag=RELENG_9_0" and standard-supfile still points to HEAD. - Max From owner-freebsd-current@FreeBSD.ORG Tue Nov 29 21:07:27 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E824F106566C; Tue, 29 Nov 2011 21:07:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C2E118FC14; Tue, 29 Nov 2011 21:07:27 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 7900B46B0D; Tue, 29 Nov 2011 16:07:27 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 06863B963; Tue, 29 Nov 2011 16:07:27 -0500 (EST) From: John Baldwin To: current@freebsd.org Date: Tue, 29 Nov 2011 16:07:26 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201111291607.26546.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 29 Nov 2011 16:07:27 -0500 (EST) Cc: Doug Barton , Warner Losh Subject: Remove debug echo 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, 29 Nov 2011 21:07:28 -0000 Any objections to this? It removes a weird line during 'make -s buildworld' output and I think it was debugging accidentally left in in 213077 by Warner: Index: newvers.sh =================================================================== --- newvers.sh (revision 228074) +++ newvers.sh (working copy) @@ -99,7 +99,6 @@ for dir in /bin /usr/bin /usr/local/bin; do done if [ -n "$svnversion" ] ; then - echo "$svnversion" svn=`cd ${SYSDIR} && $svnversion` case "$svn" in [0-9]*) svn=" r${svn}" ;; -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Nov 29 21:22:56 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 315061065672; Tue, 29 Nov 2011 21:22:56 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id D35FF14E36E; Tue, 29 Nov 2011 21:22:55 +0000 (UTC) Message-ID: <4ED54D2F.5080908@FreeBSD.org> Date: Tue, 29 Nov 2011 13:22:55 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: John Baldwin References: <201111291607.26546.jhb@freebsd.org> In-Reply-To: <201111291607.26546.jhb@freebsd.org> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Warner Losh , current@freebsd.org Subject: Re: Remove debug echo 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, 29 Nov 2011 21:22:56 -0000 On 11/29/2011 13:07, John Baldwin wrote: > Any objections to this? Nope. I wondered why it was there myself, but didn't care enough to ask. :) > It removes a weird line during 'make -s buildworld' > output and I think it was debugging accidentally left in in 213077 by Warner: > > Index: newvers.sh > =================================================================== > --- newvers.sh (revision 228074) > +++ newvers.sh (working copy) > @@ -99,7 +99,6 @@ for dir in /bin /usr/bin /usr/local/bin; do > done > > if [ -n "$svnversion" ] ; then > - echo "$svnversion" > svn=`cd ${SYSDIR} && $svnversion` > case "$svn" in > [0-9]*) svn=" r${svn}" ;; > -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Tue Nov 29 21:34:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7A1E106566B for ; Tue, 29 Nov 2011 21:34:14 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 75E7A8FC12 for ; Tue, 29 Nov 2011 21:34:14 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 68CF01DE0DC; Tue, 29 Nov 2011 22:34:13 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 4F9D528468; Tue, 29 Nov 2011 22:34:13 +0100 (CET) Date: Tue, 29 Nov 2011 22:34:13 +0100 From: Jilles Tjoelker To: Max Khon Message-ID: <20111129213413.GB14357@stack.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current Subject: Re: WITHOUT_PROFILE=yes by default 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, 29 Nov 2011 21:34:14 -0000 On Mon, Nov 28, 2011 at 05:38:20PM +0700, Max Khon wrote: > I would like to disable building profiled libraries by default. > Opinions? Agreed. There are better profiling tools available now that do not require recompiling the program with special options and statically linking it. Examples are pmcstat and callgrind/cachegrind. -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Tue Nov 29 22:09:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DE87106566C for ; Tue, 29 Nov 2011 22:09:06 +0000 (UTC) (envelope-from venture37@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 950978FC16 for ; Tue, 29 Nov 2011 22:09:04 +0000 (UTC) Received: by faak28 with SMTP id k28so254107faa.13 for ; Tue, 29 Nov 2011 14:09:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Z5ZJlyJHA6hNx/Iu96QkFFTVJZfYiopWVtgqB2tDJYY=; b=rwI3WpURW51XfPTxmccuCC5T7AWXsJHa4d0FWMDjdusvYMne3nTuYzlw2LxHHhZ31F hhuDSu7eILwEdTw/rWL1ay0PdByAm+o1FxtbSgQENjhn/bgWSoj35Q5fX4w9wqpB6Wxx CNdionlMq/t5n4Jr3H+GQelPMMElrekOyMkSw= Received: by 10.180.103.131 with SMTP id fw3mr49678375wib.57.1322602936441; Tue, 29 Nov 2011 13:42:16 -0800 (PST) Received: from Sevans-MacBook-Pro.local (cpc2-brig17-2-0-cust527.3-3.cable.virginmedia.com. [81.101.198.16]) by mx.google.com with ESMTPS id ep13sm44038260wbb.8.2011.11.29.13.42.14 (version=SSLv3 cipher=OTHER); Tue, 29 Nov 2011 13:42:15 -0800 (PST) Message-ID: <4ED551B5.8090809@gmail.com> Date: Tue, 29 Nov 2011 21:42:13 +0000 From: Sevan / Venture37 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20111129213413.GB14357@stack.nl> In-Reply-To: <20111129213413.GB14357@stack.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: WITHOUT_PROFILE=yes by default 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, 29 Nov 2011 22:09:06 -0000 I assume every who responded so far doesn't use dtrace? Sevan From owner-freebsd-current@FreeBSD.ORG Wed Nov 30 00:20:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3C7D106566B; Wed, 30 Nov 2011 00:20:40 +0000 (UTC) (envelope-from Daan@vitsch.nl) Received: from VM01.VEHosting.nl (VM016.VEHosting.nl [IPv6:2001:1af8:2100:b020::140]) by mx1.freebsd.org (Postfix) with ESMTP id 1812A8FC14; Wed, 30 Nov 2011 00:20:39 +0000 (UTC) Received: from [2001:470:d233:2:224:8cff:fe82:66cd] ([IPv6:2001:470:d233:2:224:8cff:fe82:66cd]) (authenticated bits=0) by VM01.VEHosting.nl (8.14.3/8.13.8) with ESMTP id pAU0KgAJ016913; Wed, 30 Nov 2011 01:20:42 +0100 (CET) (envelope-from Daan@vitsch.nl) From: Daan Vreeken Organization: Vitsch Electronics To: Gleb Smirnoff Date: Wed, 30 Nov 2011 01:20:37 +0100 User-Agent: KMail/1.9.10 References: <201111240928.51162.Daan@vitsch.nl> <201111290107.13631.Daan@vitsch.nl> <20111129142842.GC44498@glebius.int.ru> In-Reply-To: <20111129142842.GC44498@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201111300120.37501.Daan@vitsch.nl> x-ve-auth-version: mi-1.1.5 2011-02-07 - Copyright (c) 2008, 2011 - Daan Vreeken - VEHosting x-ve-auth: authenticated as 'pa4dan' on VM01.VEHosting.nl Cc: FreeBSD Current Subject: Re: if_clone.c allows creating multiple interfaces with the same name 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, 30 Nov 2011 00:20:40 -0000 Hi Glebius, On Tuesday 29 November 2011 15:28:42 Gleb Smirnoff wrote: > Daan, > > On Tue, Nov 29, 2011 at 01:07:13AM +0100, Daan Vreeken wrote: > D> Thanks for the looking into this and for your quick commit. I like your > D> twist on the patch with the move from the unit bitmap to allocating unit > D> numbers with alloc_unr(9). > D> > D> I do have two comments on the new code though. > D> Before, in the !wildcard case, ifc_alloc_unit() would return ENOSPC when > D> the user requested a unit number larger than ifc->ifc_maxunit. Now the > D> function returns EEXIST in that case because alloc_unr_specific() > D> returns -1 both when a number is already allocated and when the number > D> exceeds it's limits. This leads to the somewhat confusing: > D> > D> # ifconfig bridge123456 create > D> ifconfig: SIOCIFCREATE2: File exists > D> > D> Apart from that I'm a bit worried about the "/* XXXGL: yep, it's a unit > D> leak */" part of your change. Once a unit number is leaked, there > D> currently seems to be no way to ever get it back. In a worst case > D> scenario, where the names of multiple interfaces in a row collides with > D> the numbers alloc_unr() returns, an entire row of unit numbers could be > D> leaked during the creation of a single cloned interface. > D> We have a product where cloned interfaces come and go very frequently. > D> I'd hate to run out of unit numbers after 'just a few' years of uptime > D> ;-) > D> I've created a new patch on top of your change that fixes both of these > D> problems. Could you have a look at the attached diff? > > Thanks, I will work on applying it. Great! > D> > Considering the second part, that adds locking. Unfortunately, right > D> > now we have numerous races in the network configuration ocde. Many > D> > SIOCSsomething ioctls can race with each other producing unpredictable > D> > results and kernel panics. So, running two ifconfig(8) in parallel is > D> > a bad idea today. :( > D> > Your patch with IFNET_NAMING_LOCK() just plumbs one race case: a race > D> > between two SIOCSIFNAME ioctls. And it doesn't plumb a race between > D> > SIOCSIFNAME vs SIOCIFCREATE, because IFNET_NAMING_LOCK() is dropped > D> > after unit allocation, but prior to interface attachement to global > D> > interface list. > D> > D> Are you sure? With the patch in the PR, the relevant code in > D> ifc_simple_create() would become : > D> > D> ... > D> IFNET_NAMING_LOCK(); > D> err = ifc_alloc_unit(ifc, &unit); > D> if (err != 0) { > D> IFNET_NAMING_UNLOCK(); > D> return (err); > D> } > D> > D> err = ifcs->ifcs_create(ifc, unit, params); > D> IFNET_NAMING_UNLOCK(); > D> if (err != 0) { > D> ifc_free_unit(ifc, unit); > D> return (err); > D> } > D> ... > D> > D> The lock is acquired before the call to ifc_alloc_unit(). > D> In the non-error case (e.g. when creating an if_bridge interface) the > D> call ends up calling bridge_clone_create(), which calls > D> ether_ifattach(), which calls if_attach() -> if_attach_internal() where > D> the ifp is added to the ifnet list. > D> Only when that's done, the lock is dropped. > D> > D> Am I overlooking something obvious here? > > The code above isn't correct since it holds mutex when calling > ifcs->ifcs_create(). These methods may (they actually do) call malloc() > with M_WAITOK. I'd noticed the malloc() too (see my comment in the PR: "We can't use IFNET_WLOCK() here since the code paths may sleep.") The IFNET_WLOCK() macro is defined as: #define IFNET_WLOCK() do { \ sx_xlock(&ifnet_sxlock); \ rw_wlock(&ifnet_rwlock); \ } while (0) Since rwlocks cannot be held while sleeping, I've added the IFNET_NAMING_ macros in the patch, defining them as : #define IFNET_NAMING_LOCK() sx_xlock(&ifnet_sxlock); #define IFNET_NAMING_UNLOCK() sx_unlock(&ifnet_sxlock); This only does the first half of the work IFNET_WLOCK() normally does. My understanding from reading the sx(9) manual is that holding an sx lock while sleeping should be allowed. (WITNESS and INVARIANTS didn't seem to disagree with me. :) After acquiring the ifnet_sxlock, malloc() should be allowed to sleep while allocating memory for the new interface. When it's done sleeping, the interface can be added to the ifnet list in if_attach(). if_attach() will IFNET_WLOCK() which should recurse on the ifnet_sxlock and acquire a lock on the ifnet_rwlock. (I'm still confused as to why this wouldn't work.) > In general FreeBSD uses M_WAITOK on the configuration code paths, like > any SIOCSsomething ioctl. So to do correct protection, you first need to > allocate every kind of memory needed, then lock mutex, then run through > configuration sequence, then release mutex and in case of error free all > allocated memory. Sounds easy, but isn't in practice, especially when > several network modules are involved. > > So I'm still thinking about... > > D> > From my point of view, we need a generic approach to ioctl() vs > D> > ioctl() races, may be some global serializer of all re-configuration > D> > requests of interfaces and addresses. > > ... but several developers have noted that this approach may have some > hidden problems. When experimenting with new CARP, I have tried it on the > carp_ioctl() without any problems. The idea is simple: > > static int serializer = 0; > static struct mtx serializer_mtx; > MTX_SYSINIT("sermtx", &serializer_mtx, "ioctl serializer mutex", MTX_DEF); > > int > foo_ioctl() > { > mtx_lock(&serializer_mtx); > if (serializer != 0) > msleep(&serializer, &serializer_mtx, 0, "ioctl", 0); > serializer = 1; > mtx_unlock(&serializer_mtx); > > ... any code here, uncluding calls to different lower layers... > > mtx_lock(&serializer_mtx); > serializer = 0; > wakeup(&serializer); > mtx_unlock(&serializer_mtx); > > return (error); > } > > I have tried this for carp_ioctl() and it worked fine. You can try it for > entire ifioctl() and all its descendants, but be aware of hidden problems > :) That reminds me of sem_wait() and sem_post(). I'm going to remember that construction. It could come in handy some time. :) Regards, -- Daan Vreeken Vitsch Electronics http://Vitsch.nl tel: +31-(0)40-7113051 / +31-(0)6-46210825 KvK nr: 17174380 From owner-freebsd-current@FreeBSD.ORG Wed Nov 30 00:34:29 2011 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BD96106566C; Wed, 30 Nov 2011 00:34:29 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 914B98FC18; Wed, 30 Nov 2011 00:34:25 +0000 (UTC) Received: from [22.166.79.178] (mcc0536d0.tmodns.net [208.54.5.204]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pAU0UquH065764 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Tue, 29 Nov 2011 17:31:27 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <201111291607.26546.jhb@freebsd.org> Date: Tue, 29 Nov 2011 17:31:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201111291607.26546.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Tue, 29 Nov 2011 17:31:29 -0700 (MST) Cc: Doug Barton , Warner Losh , current@FreeBSD.ORG Subject: Re: Remove debug echo 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, 30 Nov 2011 00:34:29 -0000 kill it. Warner On Nov 29, 2011, at 2:07 PM, John Baldwin wrote: > Any objections to this? It removes a weird line during 'make -s = buildworld'=20 > output and I think it was debugging accidentally left in in 213077 by = Warner: >=20 > Index: newvers.sh > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- newvers.sh (revision 228074) > +++ newvers.sh (working copy) > @@ -99,7 +99,6 @@ for dir in /bin /usr/bin /usr/local/bin; do > done >=20 > if [ -n "$svnversion" ] ; then > - echo "$svnversion" > svn=3D`cd ${SYSDIR} && $svnversion` > case "$svn" in > [0-9]*) svn=3D" r${svn}" ;; >=20 > --=20 > John Baldwin >=20 >=20 From owner-freebsd-current@FreeBSD.ORG Wed Nov 30 01:14:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16A0A106564A for ; Wed, 30 Nov 2011 01:14:29 +0000 (UTC) (envelope-from ambrosehua@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id A09058FC08 for ; Wed, 30 Nov 2011 01:14:28 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so126078bkb.13 for ; Tue, 29 Nov 2011 17:14:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=HNupIAQpYgwLCV0HKqLA/8hpK6dC314Zxi84vEpGJJc=; b=AvYbrMHhKmoxj6i2uTcBiL1ftMHGLKhmfh89NrxuOliOQegbjJjtdICbxwr/Vi3zqw TvJ+3D5yVt7CTwOqUvrnXCpAd2FIDu0RvSsBTTVAkvkaeii0LdXZTDZD3D/M7YZApUsn XSPXPDM+5mLgeahtwHvDy5UZcmvtIm+kiR9H8= MIME-Version: 1.0 Received: by 10.204.156.133 with SMTP id x5mr51709097bkw.87.1322615667124; Tue, 29 Nov 2011 17:14:27 -0800 (PST) Received: by 10.223.159.193 with HTTP; Tue, 29 Nov 2011 17:14:27 -0800 (PST) In-Reply-To: <4ED551B5.8090809@gmail.com> References: <20111129213413.GB14357@stack.nl> <4ED551B5.8090809@gmail.com> Date: Wed, 30 Nov 2011 09:14:27 +0800 Message-ID: From: Paul Ambrose To: "Sevan / Venture37" Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_PROFILE=yes by default 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, 30 Nov 2011 01:14:29 -0000 I think dtrace for freebsd userland is close to complete( after r227290, at least no more kernel panic). but is not suitable for a daily use now. =D4=DA 2011=C4=EA11=D4=C230=C8=D5 =C9=CF=CE=E75:42=A3=ACSevan / Venture37 <= venture37@gmail.com> =D0=B4=B5=C0=A3=BA > I assume every who responded so far doesn't use dtrace? > > > Sevan > _______________________________________________ > 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 Wed Nov 30 01:18:01 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 107B0106566C for ; Wed, 30 Nov 2011 01:18:01 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id E5A40155BF1; Wed, 30 Nov 2011 01:16:00 +0000 (UTC) Message-ID: <4ED583D0.6030403@FreeBSD.org> Date: Tue, 29 Nov 2011 17:16:00 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Paul Ambrose References: <20111129213413.GB14357@stack.nl> <4ED551B5.8090809@gmail.com> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Sevan / Venture37 , freebsd-current@freebsd.org Subject: Re: WITHOUT_PROFILE=yes by default 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, 30 Nov 2011 01:18:01 -0000 What does dtrace have to do with profiled libs? On 11/29/2011 17:14, Paul Ambrose wrote: > I think dtrace for freebsd userland is close to complete( after > r227290, at least no more kernel panic). but is not suitable for a > daily use now. > > 在 2011ĺą´11ćś30ć—Ą 上ĺŤ5:42，Sevan / Venture37 写é“： >> I assume every who responded so far doesn't use dtrace? -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Wed Nov 30 10:24:39 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E770E1065672 for ; Wed, 30 Nov 2011 10:24:39 +0000 (UTC) (envelope-from mueller6727@bellsouth.net) Received: from fmailhost01.isp.att.net (fmailhost01.isp.att.net [204.127.217.101]) by mx1.freebsd.org (Postfix) with ESMTP id D86818FC0A for ; Wed, 30 Nov 2011 10:24:39 +0000 (UTC) Date: Wed, 30 Nov 2011 10:24:39 +0000 (GMT) X-Comment: Sending client does not conform to RFC822 minimum requirements X-Comment: Date has been added by Maillennium Received: from localhost (adsl-68-210-130-165.sdf.bellsouth.net[68.210.130.165]) by isp.att.net (frfwmhc01) with SMTP id <20111130102438H0100gcvv7e>; Wed, 30 Nov 2011 10:24:39 +0000 X-Originating-IP: [68.210.130.165] From: "Thomas Mueller" To: freebsd-current@FreeBSD.org Message-Id: <20111130102439.E770E1065672@hub.freebsd.org> Cc: Subject: man ugen error 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, 30 Nov 2011 10:24:40 -0000 According to ugen man page, ugen can be compiled into the kernel with device ugen in config file. I tried that in the kernel config when upgrading from FreeBSD 9.0-RC1 to RC2, but the kernel build stopped quickly with the message that ugen was not valid. After removing that line from kernel config, "make kernel" was successful. I didn't find "device ugen" anywhere in the conf/NOTES or conf/GENERIC files. I hope this man page error can be fixed in time for FreeBSD 9.0-RELEASE. Tom From owner-freebsd-current@FreeBSD.ORG Wed Nov 30 10:29:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4EE5106566B for ; Wed, 30 Nov 2011 10:29:43 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm3-vm3.bullet.mail.ne1.yahoo.com (nm3-vm3.bullet.mail.ne1.yahoo.com [98.138.91.133]) by mx1.freebsd.org (Postfix) with SMTP id 87D618FC0A for ; Wed, 30 Nov 2011 10:29:43 +0000 (UTC) Received: from [98.138.90.48] by nm3.bullet.mail.ne1.yahoo.com with NNFMP; 30 Nov 2011 10:16:26 -0000 Received: from [98.138.226.59] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 30 Nov 2011 10:16:26 -0000 Received: from [127.0.0.1] by smtp210.mail.ne1.yahoo.com with NNFMP; 30 Nov 2011 10:16:26 -0000 X-Yahoo-Newman-Id: 91462.79141.bm@smtp210.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 7yaM4tkVM1moWLEnbclsBAz8O5cD6NDONLuftxRZ.jQS.G8 Ub4UOmOqzM1epSkGZ8EhoE0mXmqb8CPmSfKkRLxH4tbbTWLu0mahI4BMwMNh xQOJTYbiNF8jUq3C1iaty5tqVzq0F8I1pgJvxlWtvViZ0NEcl5FZ6huG57fj jbsOhvkAMNxzOUwmEqZHn48M7n3MXVAcfbOEho4zttK60k7MnRptZ94yLev0 cB4r0R6EnK5zc4.dPv7WatTtYCrjoWyWIhMLRXV55fRPw0aqfuhHB4fl8v9o h0NddxsW47XopUCXo05gN24CE0sTE7QYpPepyILh5rz8Gqwg5uV2Q6JSevLg hO5bFnIb16Crjh6eRa5SMgXFEe3dOmfqyUmmEQl2moz14h14dkqkYJkRDYP8 mITAVS7fyPl9cog-- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.20] (se@81.173.147.13 with plain) by smtp210.mail.ne1.yahoo.com with SMTP; 30 Nov 2011 02:16:25 -0800 PST Message-ID: <4ED60279.10901@freebsd.org> Date: Wed, 30 Nov 2011 11:16:25 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: John Baldwin References: <4EBB885E.9060908@freebsd.org> <201111161116.24855.jhb@freebsd.org> <4EC4CCFF.8040704@freebsd.org> <201111171133.34108.jhb@freebsd.org> In-Reply-To: <201111171133.34108.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Attilio Rao , freebsd-current@freebsd.org Subject: [SOLVED]: HW defect (was: Re: [amd64] Reproducible cold boot failure (reboot succeeds) in -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: Wed, 30 Nov 2011 10:29:43 -0000 Am 17.11.2011 17:33, schrieb John Baldwin: > On Thursday, November 17, 2011 3:59:43 am Stefan Esser wrote: >> Am 16.11.2011 17:16, schrieb John Baldwin: [...] >>> That isn't unusual. Those are the addresses of the metadata provided by the >>> loader, not the base address of the kernel or zfs.ko object themselves. The >>> unexpected relocation type is interesting however. That value in hex is >>> 0x400000b. 0xb is the R_X86_64_32S relocation type which is normal for the >>> kernel. I think you just have a single-bit memory error due to a failing >>> DIMM. >> >> Thanks for the information about the load address semantics. The other >> unexpected relocation type I observed was 268435457 == 0x10000001, which >> also hints at a single bit error. But today the system failed with a >> different error: >> >> ath0: ... >> ioapic0: routing interrupt 18 to ... >> panic: vm_page_insert: page already inserted >> >> This could of course also be caused by a single bit error ... > > Yes, very likely. > >> Hmmm, perhaps there is a problem with components at room temperature >> and the system is still significantly warmer after 3 hours? > > Yes, I strongly suspect it is a thermal effect that the RAM "works" once it > is warmed up. If you have data you care about on the machine, I would just > go ahead and replace the RAM now before waiting for the RAM's failure to > become worse. Thanks a lot, John! I should have checked the hardware before, but since the system was perfectly stable, once it had been up and running, I had been suspecting an initialization bug instead of defective RAM. In fact, one of the 4GB DIMMs in the system returns bogus data (0x10000000 or 0x04000000 instead of 0) for some 40 to 50 seconds after power-on. Once warmed up, memtest86+ runs for days without a single extra data error (I wanted to have an estimate for the defect having led to damaged data in disk files). When I was still doing hardware work, I always had a freezer aerosol on my desk, which allowed me to quickly cool down a DUT by a few tens of degrees, but without such a tool I had to wait for the components to cool down over night between test. Best regards, STefan From owner-freebsd-current@FreeBSD.ORG Wed Nov 30 12:43:24 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40231106564A for ; Wed, 30 Nov 2011 12:43:24 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 29F268FC17 for ; Wed, 30 Nov 2011 12:43:24 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pAUChOIY055506 for ; Wed, 30 Nov 2011 12:43:24 GMT (envelope-from bapt@FreeBSD.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pAUChNL5055505 for freebsd-current@freebsd.org; Wed, 30 Nov 2011 12:43:23 GMT (envelope-from bapt@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@FreeBSD.org using -f Date: Wed, 30 Nov 2011 13:43:20 +0100 From: Baptiste Daroussin To: freebsd-current@FreeBSD.org Message-ID: <20111130124320.GA1449@azathoth.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: [patch] turning devctl into a "multiple openable" device 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, 30 Nov 2011 12:43:24 -0000 --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, With the help of cognet, I wrote a patch to turn devctl into a multiple ope= nable device, that mean that it will allow to open /dev/devctl in multiple progra= ms, for example hald and everythings that want to receive notification from the device won't need to depend on haveing devd running. here is the patch:=20 http://people.freebsd.org/~bapt/devctl_multi_open.diff regards, bapt --a8Wt8u1KmwUX3Y2C Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7WJOgACgkQ8kTtMUmk6EwPvwCdHgzdU94/XEZNc9cMlwGP8BJB XEsAnRvCX7tcquEY19n7FMU+lXzlmk0R =TA5L -----END PGP SIGNATURE----- --a8Wt8u1KmwUX3Y2C-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 30 14:52:02 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2C5D106564A for ; Wed, 30 Nov 2011 14:52:02 +0000 (UTC) (envelope-from fw@f-ws.de) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8CBA38FC08 for ; Wed, 30 Nov 2011 14:52:02 +0000 (UTC) Received: by bkat2 with SMTP id t2so680093bka.13 for ; Wed, 30 Nov 2011 06:52:01 -0800 (PST) Received: by 10.204.154.201 with SMTP id p9mr2691431bkw.33.1322662946124; Wed, 30 Nov 2011 06:22:26 -0800 (PST) Received: from [172.16.5.135] ([212.48.107.10]) by mx.google.com with ESMTPS id e8sm4306095bkd.7.2011.11.30.06.22.23 (version=SSLv3 cipher=OTHER); Wed, 30 Nov 2011 06:22:24 -0800 (PST) Message-ID: <4ED63C2D.8020209@f-ws.de> Date: Wed, 30 Nov 2011 15:22:37 +0100 From: Florian Wilkemeyer User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110802 Thunderbird/5.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: if_bce tx / rx tick limits 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, 30 Nov 2011 14:52:03 -0000 Hi, i wonder about the bce driver's tx / rx tick limits (ticks and ticks_int are limited to 100; otherwise default value (80) gets used) (if_bce.c line 921 / 933 .. ) On DragonFly BSD the values can be set much higher (such as 1000 ..) which would be great in a high-traffic setup. (On linux there's no limit too as far as i remember) Is there any reason why its limited down to 100? Thanks Florian P.S. I'm sorry if this was the wrong mailing list for it; i don't know whats the right list for this (probably net or driver ?) From owner-freebsd-current@FreeBSD.ORG Wed Nov 30 15:00:34 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89AB81065672; Wed, 30 Nov 2011 15:00:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4FC548FC17; Wed, 30 Nov 2011 15:00:34 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id DFE4246B09; Wed, 30 Nov 2011 10:00:33 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6AA67B945; Wed, 30 Nov 2011 10:00:33 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 30 Nov 2011 10:00:32 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201111240928.51162.Daan@vitsch.nl> <201111290107.13631.Daan@vitsch.nl> <20111129142842.GC44498@glebius.int.ru> In-Reply-To: <20111129142842.GC44498@glebius.int.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Message-Id: <201111301000.32787.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 30 Nov 2011 10:00:33 -0500 (EST) Cc: Daan Vreeken , Gleb Smirnoff Subject: Re: if_clone.c allows creating multiple interfaces with the same name 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, 30 Nov 2011 15:00:34 -0000 On Tuesday, November 29, 2011 9:28:42 am Gleb Smirnoff wrote: > Daan, > > On Tue, Nov 29, 2011 at 01:07:13AM +0100, Daan Vreeken wrote: > D> Thanks for the looking into this and for your quick commit. I like your twist > D> on the patch with the move from the unit bitmap to allocating unit numbers > D> with alloc_unr(9). > D> > D> I do have two comments on the new code though. > D> Before, in the !wildcard case, ifc_alloc_unit() would return ENOSPC when the > D> user requested a unit number larger than ifc->ifc_maxunit. Now the function > D> returns EEXIST in that case because alloc_unr_specific() returns -1 both > D> when a number is already allocated and when the number exceeds it's limits. > D> This leads to the somewhat confusing: > D> > D> # ifconfig bridge123456 create > D> ifconfig: SIOCIFCREATE2: File exists > D> > D> Apart from that I'm a bit worried about the "/* XXXGL: yep, it's a unit leak > D> */" part of your change. Once a unit number is leaked, there currently seems > D> to be no way to ever get it back. In a worst case scenario, where the names of > D> multiple interfaces in a row collides with the numbers alloc_unr() returns, an > D> entire row of unit numbers could be leaked during the creation of a single > D> cloned interface. > D> We have a product where cloned interfaces come and go very frequently. I'd > D> hate to run out of unit numbers after 'just a few' years of uptime ;-) > D> > D> I've created a new patch on top of your change that fixes both of these > D> problems. Could you have a look at the attached diff? > > Thanks, I will work on applying it. > > D> > Considering the second part, that adds locking. Unfortunately, right now we > D> > have numerous races in the network configuration ocde. Many SIOCSsomething > D> > ioctls can race with each other producing unpredictable results and kernel > D> > panics. So, running two ifconfig(8) in parallel is a bad idea today. :( > D> > Your patch with IFNET_NAMING_LOCK() just plumbs one race case: a race > D> > between two SIOCSIFNAME ioctls. And it doesn't plumb a race between > D> > SIOCSIFNAME vs SIOCIFCREATE, because IFNET_NAMING_LOCK() is dropped after > D> > unit allocation, but prior to interface attachement to global interface > D> > list. > D> > D> Are you sure? With the patch in the PR, the relevant code in > D> ifc_simple_create() would become : > D> > D> ... > D> IFNET_NAMING_LOCK(); > D> err = ifc_alloc_unit(ifc, &unit); > D> if (err != 0) { > D> IFNET_NAMING_UNLOCK(); > D> return (err); > D> } > D> > D> err = ifcs->ifcs_create(ifc, unit, params); > D> IFNET_NAMING_UNLOCK(); > D> if (err != 0) { > D> ifc_free_unit(ifc, unit); > D> return (err); > D> } > D> ... > D> > D> The lock is acquired before the call to ifc_alloc_unit(). > D> In the non-error case (e.g. when creating an if_bridge interface) the call > D> ends up calling bridge_clone_create(), which calls ether_ifattach(), which > D> calls if_attach() -> if_attach_internal() where the ifp is added to the ifnet > D> list. > D> Only when that's done, the lock is dropped. > D> > D> Am I overlooking something obvious here? > > The code above isn't correct since it holds mutex when calling ifcs->ifcs_create(). > These methods may (they actually do) call malloc() with M_WAITOK. > > In general FreeBSD uses M_WAITOK on the configuration code paths, like > any SIOCSsomething ioctl. So to do correct protection, you first need to > allocate every kind of memory needed, then lock mutex, then run through configuration > sequence, then release mutex and in case of error free all allocated memory. > Sounds easy, but isn't in practice, especially when several network modules > are involved. > > So I'm still thinking about... > > D> > From my point of view, we need a generic approach to ioctl() vs ioctl() > D> > races, may be some global serializer of all re-configuration requests of > D> > interfaces and addresses. > > ... but several developers have noted that this approach may have some hidden > problems. When experimenting with new CARP, I have tried it on the carp_ioctl() > without any problems. The idea is simple: > > static int serializer = 0; > static struct mtx serializer_mtx; > MTX_SYSINIT("sermtx", &serializer_mtx, "ioctl serializer mutex", MTX_DEF); > > int > foo_ioctl() > { > mtx_lock(&serializer_mtx); > if (serializer != 0) > msleep(&serializer, &serializer_mtx, 0, "ioctl", 0); > serializer = 1; > mtx_unlock(&serializer_mtx); > > ... any code here, uncluding calls to different lower layers... > > mtx_lock(&serializer_mtx); > serializer = 0; > wakeup(&serializer); > mtx_unlock(&serializer_mtx); > > return (error); > } > > I have tried this for carp_ioctl() and it worked fine. You can try it for > entire ifioctl() and all its descendants, but be aware of hidden problems :) Hmm, is this much different in effect than: static struct sx serializer_sx; SX_SYSINIT(...); int foo_ioctl() { sx_xlock(&serializer_sx); ... any code here sx_xunlock(&serializer_sx); } ? Using an sx lock is shorter and also allows WITNESS to catch possible cycles that can be otherwise missed with home-rolled locks. Also, you should really use 'while (serializer)', not if. Currently this doesn't really serialize since you can have this: - three threads all try to run foo_ioctl() - first thread doesn't block and sets serializer 1 - next two threads both block - first thread finishes and does a wakeup - both threads resume and run the 'any code here' bits in parallel (not serialized) If that is not the desired behavior then you need to use a while(). Also, if this really is a bug and not the desired behavior it's even more reason to use existing primitives like sx(9) rather than trying to roll your own locks. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Nov 30 15:05:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B104106566C; Wed, 30 Nov 2011 15:05:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 445508FC15; Wed, 30 Nov 2011 15:05:13 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id F07A246B0A; Wed, 30 Nov 2011 10:05:12 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 824F9B945; Wed, 30 Nov 2011 10:05:12 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 30 Nov 2011 10:05:11 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <20111130124320.GA1449@azathoth.lan> In-Reply-To: <20111130124320.GA1449@azathoth.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201111301005.11938.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 30 Nov 2011 10:05:12 -0500 (EST) Cc: Baptiste Daroussin Subject: Re: [patch] turning devctl into a "multiple openable" device 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, 30 Nov 2011 15:05:13 -0000 On Wednesday, November 30, 2011 7:43:20 am Baptiste Daroussin wrote: > Hi all, > > With the help of cognet, I wrote a patch to turn devctl into a multiple openable > device, that mean that it will allow to open /dev/devctl in multiple programs, > for example hald and everythings that want to receive notification from the > device won't need to depend on haveing devd running. > > here is the patch: > http://people.freebsd.org/~bapt/devctl_multi_open.diff Shouldn't devctl_queue_data_f() use the requested malloc() flags instead of hardcoding M_NOWAIT? Also, I know that it was an intentional design decisison by Warner to have the multiplexing of devctl data done in userland via devd rather than in the kernel. (I think he envisioned devd providing a UNIX domain socket or some such for other daemons to use to listen to events.) Have you asked him about this change? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Nov 30 15:46:03 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40E26106566B; Wed, 30 Nov 2011 15:46:03 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0F89D8FC16; Wed, 30 Nov 2011 15:46:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pAUFk2ja019082; Wed, 30 Nov 2011 15:46:02 GMT (envelope-from bapt@freebsd.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pAUFk28J019081; Wed, 30 Nov 2011 15:46:02 GMT (envelope-from bapt@freebsd.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@freebsd.org using -f Date: Wed, 30 Nov 2011 16:45:58 +0100 From: Baptiste Daroussin To: John Baldwin Message-ID: <20111130154558.GA1621@azathoth.lan> References: <20111130124320.GA1449@azathoth.lan> <201111301005.11938.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline In-Reply-To: <201111301005.11938.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, imp@freebsd.org Subject: Re: [patch] turning devctl into a "multiple openable" device 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, 30 Nov 2011 15:46:03 -0000 --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 30, 2011 at 10:05:11AM -0500, John Baldwin wrote: > On Wednesday, November 30, 2011 7:43:20 am Baptiste Daroussin wrote: > > Hi all, > >=20 > > With the help of cognet, I wrote a patch to turn devctl into a multiple= openable > > device, that mean that it will allow to open /dev/devctl in multiple pr= ograms, > > for example hald and everythings that want to receive notification from= the > > device won't need to depend on haveing devd running. > >=20 > > here is the patch:=20 > > http://people.freebsd.org/~bapt/devctl_multi_open.diff >=20 > Shouldn't devctl_queue_data_f() use the requested malloc() flags instead = of > hardcoding M_NOWAIT? you are right, I'll fix that. >=20 > Also, I know that it was an intentional design decisison by Warner to have > the multiplexing of devctl data done in userland via devd rather than in = the > kernel. (I think he envisioned devd providing a UNIX domain socket or so= me > such for other daemons to use to listen to events.) Have you asked him a= bout > this change? I haven't discussed this with him, I just CC him now to have his opinion. In fact for somecase I find useful to have useland application able to get notification from device without having devd running at all plus the devctl= (4) manpage says:=20 " This design allows only one reader for /dev/devctl. This is not desirabl= e in the long run, but will get a lot of hair out of this implementation. Maybe= we should make this device a clonable device." that's why I didn't first spoke to Warner about this, which has been a mist= ake sorry about that. regards, Bapt --UlVJffcvxoiEqYs2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7WT7YACgkQ8kTtMUmk6EyHnwCfW2HegLplMqZg+jXgCd8BzEIl azMAnj1f6SZEzzZCONTDQy6KwggUPOSF =1sck -----END PGP SIGNATURE----- --UlVJffcvxoiEqYs2-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 30 15:46:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 708E41065680; Wed, 30 Nov 2011 15:46:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 49BE28FC17; Wed, 30 Nov 2011 15:46:42 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pAUFkblQ010783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Nov 2011 17:46:37 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pAUFkbsm078718; Wed, 30 Nov 2011 17:46:37 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pAUFka0f078717; Wed, 30 Nov 2011 17:46:36 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 30 Nov 2011 17:46:36 +0200 From: Kostik Belousov To: John Baldwin Message-ID: <20111130154636.GX50300@deviant.kiev.zoral.com.ua> References: <20111130124320.GA1449@azathoth.lan> <201111301005.11938.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jwac3nLilAlTsrBW" Content-Disposition: inline In-Reply-To: <201111301005.11938.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Baptiste Daroussin , freebsd-current@freebsd.org Subject: Re: [patch] turning devctl into a "multiple openable" device 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, 30 Nov 2011 15:46:43 -0000 --jwac3nLilAlTsrBW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 30, 2011 at 10:05:11AM -0500, John Baldwin wrote: > On Wednesday, November 30, 2011 7:43:20 am Baptiste Daroussin wrote: > > Hi all, > >=20 > > With the help of cognet, I wrote a patch to turn devctl into a multiple= openable > > device, that mean that it will allow to open /dev/devctl in multiple pr= ograms, > > for example hald and everythings that want to receive notification from= the > > device won't need to depend on haveing devd running. > >=20 > > here is the patch:=20 > > http://people.freebsd.org/~bapt/devctl_multi_open.diff >=20 > Shouldn't devctl_queue_data_f() use the requested malloc() flags instead = of > hardcoding M_NOWAIT? This is an obvious fallback of holding mutex around the call to per_devctl_queue_data_f(), which caused the author a trouble to use M_WAITOK. Having n readers causes the patch to queue each message n times, that looks like a waste. I wonder why the waiting_threads stuff is needed at all. The cv could be woken up unconditionally everytime. What is the reason for the cv_wait call in cdevpriv data destructor ? You cannot have a thread doing e.g. read on the file descriptor while destructor is run. >=20 > Also, I know that it was an intentional design decisison by Warner to have > the multiplexing of devctl data done in userland via devd rather than in = the > kernel. (I think he envisioned devd providing a UNIX domain socket or so= me > such for other daemons to use to listen to events.) Have you asked him a= bout > this change? And I fully agree that doing multiplexing in user mode is the right approac= h. Not least because you could apply some advanced access control and provide filtering for the consumers. --jwac3nLilAlTsrBW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7WT9wACgkQC3+MBN1Mb4g5zwCg3MjdQJIZB4pmbmruWX2OEZnc tHcAmQH6vh5NvQ3TGOTDZASNPdkDq73l =TCaE -----END PGP SIGNATURE----- --jwac3nLilAlTsrBW-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 30 15:59:10 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C78C106566C; Wed, 30 Nov 2011 15:59:10 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E6D528FC13; Wed, 30 Nov 2011 15:59:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pAUFx9hD027734; Wed, 30 Nov 2011 15:59:09 GMT (envelope-from bapt@freebsd.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pAUFx9R8027733; Wed, 30 Nov 2011 15:59:09 GMT (envelope-from bapt@freebsd.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@freebsd.org using -f Date: Wed, 30 Nov 2011 16:59:06 +0100 From: Baptiste Daroussin To: Kostik Belousov Message-ID: <20111130155906.GB1621@azathoth.lan> References: <20111130124320.GA1449@azathoth.lan> <201111301005.11938.jhb@freebsd.org> <20111130154636.GX50300@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KFztAG8eRSV9hGtP" Content-Disposition: inline In-Reply-To: <20111130154636.GX50300@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: [patch] turning devctl into a "multiple openable" device 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, 30 Nov 2011 15:59:10 -0000 --KFztAG8eRSV9hGtP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 30, 2011 at 05:46:36PM +0200, Kostik Belousov wrote: > On Wed, Nov 30, 2011 at 10:05:11AM -0500, John Baldwin wrote: > > On Wednesday, November 30, 2011 7:43:20 am Baptiste Daroussin wrote: > > > Hi all, > > >=20 > > > With the help of cognet, I wrote a patch to turn devctl into a multip= le openable > > > device, that mean that it will allow to open /dev/devctl in multiple = programs, > > > for example hald and everythings that want to receive notification fr= om the > > > device won't need to depend on haveing devd running. > > >=20 > > > here is the patch:=20 > > > http://people.freebsd.org/~bapt/devctl_multi_open.diff > >=20 > > Shouldn't devctl_queue_data_f() use the requested malloc() flags instea= d of > > hardcoding M_NOWAIT? > This is an obvious fallback of holding mutex around the call to > per_devctl_queue_data_f(), which caused the author a trouble to use > M_WAITOK. >=20 > Having n readers causes the patch to queue each message n times, that loo= ks > like a waste. >=20 > I wonder why the waiting_threads stuff is needed at all. The cv could > be woken up unconditionally everytime. What is the reason for the cv_wait > call in cdevpriv data destructor ? You cannot have a thread doing e.g. > read on the file descriptor while destructor is run. >=20 > >=20 > > Also, I know that it was an intentional design decisison by Warner to h= ave > > the multiplexing of devctl data done in userland via devd rather than i= n the > > kernel. (I think he envisioned devd providing a UNIX domain socket or = some > > such for other daemons to use to listen to events.) Have you asked him= about > > this change? > And I fully agree that doing multiplexing in user mode is the right appro= ach. > Not least because you could apply some advanced access control and provide > filtering for the consumers. I agree that in most cases this is better, but being able to have multiple readers is anyway useful, having the futur libudev or alike not depends on = devd running would be great imho. I have boxes that do not have devd and won't have it would be useless but r= un programs that needs to get notification for some hardware. I would love to remove devd on those boxes (they are boxes where the FS size is limited) regards, Bapt --KFztAG8eRSV9hGtP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7WUsoACgkQ8kTtMUmk6EzkwACfUTu9h2FY/9WFnxMH1wk4iKrm 9ecAnReKgkHD10fwKhd6EvDsUOguuIl7 =e8tO -----END PGP SIGNATURE----- --KFztAG8eRSV9hGtP-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 30 16:03:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C0F51065672 for ; Wed, 30 Nov 2011 16:03:14 +0000 (UTC) (envelope-from venture37@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id E50148FC08 for ; Wed, 30 Nov 2011 16:03:13 +0000 (UTC) Received: by eaai12 with SMTP id i12so1243157eaa.13 for ; Wed, 30 Nov 2011 08:03:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=jyptyxa1UcXYbYTKTCpE4RbInR9BMxJg7MVEXqgwmYs=; b=ibX2s9WdLoSisWhe1jmrzxWCyDe1f5fsMx/52Ye1n4l8LIJmU6z4y2vAj8PpwVQkxA AC8sLD+2hjyvDxnVRNsfXI1eA4o8eMmDx0lkiESk9VzVRJlvSdmd54Q1shQ9AOnkFucO dhqrIUz1mWwyQnvZkD5smYHUdqgqyGvxKc93Q= Received: by 10.216.50.199 with SMTP id z49mr325517web.84.1322668992893; Wed, 30 Nov 2011 08:03:12 -0800 (PST) Received: from Sevans-Mac-mini.local (n3.venture37.net. [91.103.132.218]) by mx.google.com with ESMTPS id dw6sm649483wib.12.2011.11.30.08.03.10 (version=SSLv3 cipher=OTHER); Wed, 30 Nov 2011 08:03:11 -0800 (PST) Message-ID: <4ED653B6.1010607@gmail.com> Date: Wed, 30 Nov 2011 16:03:02 +0000 From: Sevan / Venture37 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20111129213413.GB14357@stack.nl> <4ED551B5.8090809@gmail.com> <4ED583D0.6030403@FreeBSD.org> In-Reply-To: <4ED583D0.6030403@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: WITHOUT_PROFILE=yes by default 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, 30 Nov 2011 16:03:14 -0000 On 30/11/2011 01:16, Doug Barton wrote: > What does dtrace have to do with profiled libs? system breaks if you try to add dtrace support to a system built with profile support. on the other hand it could be argued that the system currently needs to be rebuilt anyway. Sevan From owner-freebsd-current@FreeBSD.ORG Wed Nov 30 16:04:55 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92B371065672; Wed, 30 Nov 2011 16:04:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 5D4DC8FC17; Wed, 30 Nov 2011 16:04:53 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pAUG4ofa013554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Nov 2011 18:04:50 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pAUG4orF079025; Wed, 30 Nov 2011 18:04:50 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pAUG4oXR079024; Wed, 30 Nov 2011 18:04:50 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 30 Nov 2011 18:04:50 +0200 From: Kostik Belousov To: Olivier Houchard Message-ID: <20111130160450.GY50300@deviant.kiev.zoral.com.ua> References: <20111130124320.GA1449@azathoth.lan> <201111301005.11938.jhb@freebsd.org> <20111130154636.GX50300@deviant.kiev.zoral.com.ua> <20111130155521.GA52567@ci0.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3810kwpuvNap/nrH" Content-Disposition: inline In-Reply-To: <20111130155521.GA52567@ci0.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Baptiste Daroussin , freebsd-current@freebsd.org Subject: Re: [patch] turning devctl into a "multiple openable" device 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, 30 Nov 2011 16:04:55 -0000 --3810kwpuvNap/nrH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 30, 2011 at 04:55:21PM +0100, Olivier Houchard wrote: > On Wed, Nov 30, 2011 at 05:46:36PM +0200, Kostik Belousov wrote: > > On Wed, Nov 30, 2011 at 10:05:11AM -0500, John Baldwin wrote: > > > On Wednesday, November 30, 2011 7:43:20 am Baptiste Daroussin wrote: > > > > Hi all, > > > >=20 > > > > With the help of cognet, I wrote a patch to turn devctl into a mult= iple openable > > > > device, that mean that it will allow to open /dev/devctl in multipl= e programs, > > > > for example hald and everythings that want to receive notification = from the > > > > device won't need to depend on haveing devd running. > > > >=20 > > > > here is the patch:=20 > > > > http://people.freebsd.org/~bapt/devctl_multi_open.diff > > >=20 > > > Shouldn't devctl_queue_data_f() use the requested malloc() flags inst= ead of > > > hardcoding M_NOWAIT? > > This is an obvious fallback of holding mutex around the call to > > per_devctl_queue_data_f(), which caused the author a trouble to use > > M_WAITOK. > >=20 > > Having n readers causes the patch to queue each message n times, that l= ooks > > like a waste. > >=20 >=20 > Queuing the message only one time would require to somehow keep a state, = to > know which thread read which message, and figuring out when to free a mes= sage > can be an headache. Given I don't think they'll be a lot of readers, I'm = not > sure it's worth the trouble. >=20 > > I wonder why the waiting_threads stuff is needed at all. The cv could > > be woken up unconditionally everytime. What is the reason for the cv_wa= it > > call in cdevpriv data destructor ? You cannot have a thread doing e.g. > > read on the file descriptor while destructor is run. > >=20 >=20 > What will prevent you from having a thread stuck in read(), while an anot= her=20 > one close() the fd ? >=20 Nothing, but file reference count goes to zero only after the thread stuck in read is unstuck. Cdevpriv destructor is run only when file reference count becomes zero, i.e. there can be no any accessing threads, and new accesses are impossible since file descriptors also own references on the file. --3810kwpuvNap/nrH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7WVCIACgkQC3+MBN1Mb4hToQCfVnR31uzSGbFP/jkmlKYJgtHX VJIAn12lAKr282i53O91iADdoWoeUW7l =WyJx -----END PGP SIGNATURE----- --3810kwpuvNap/nrH-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 30 15:55:11 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D66F01065673; Wed, 30 Nov 2011 15:55:11 +0000 (UTC) (envelope-from mlfbsd@kanar.ci0.org) Received: from kanar.ci0.org (unknown [IPv6:2a01:e0b:1:50:40:63ff:feea:93a]) by mx1.freebsd.org (Postfix) with ESMTP id 65CF78FC19; Wed, 30 Nov 2011 15:55:11 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.2/8.14.3) with ESMTP id pAUFtLZv053095; Wed, 30 Nov 2011 16:55:21 +0100 (CET) (envelope-from mlfbsd@kanar.ci0.org) Received: (from mlfbsd@localhost) by kanar.ci0.org (8.14.2/8.14.3/Submit) id pAUFtLG4053094; Wed, 30 Nov 2011 16:55:21 +0100 (CET) (envelope-from mlfbsd) Date: Wed, 30 Nov 2011 16:55:21 +0100 From: Olivier Houchard To: Kostik Belousov Message-ID: <20111130155521.GA52567@ci0.org> References: <20111130124320.GA1449@azathoth.lan> <201111301005.11938.jhb@freebsd.org> <20111130154636.GX50300@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111130154636.GX50300@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Wed, 30 Nov 2011 16:35:53 +0000 Cc: Baptiste Daroussin , freebsd-current@freebsd.org Subject: Re: [patch] turning devctl into a "multiple openable" device 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, 30 Nov 2011 15:55:12 -0000 On Wed, Nov 30, 2011 at 05:46:36PM +0200, Kostik Belousov wrote: > On Wed, Nov 30, 2011 at 10:05:11AM -0500, John Baldwin wrote: > > On Wednesday, November 30, 2011 7:43:20 am Baptiste Daroussin wrote: > > > Hi all, > > > > > > With the help of cognet, I wrote a patch to turn devctl into a multiple openable > > > device, that mean that it will allow to open /dev/devctl in multiple programs, > > > for example hald and everythings that want to receive notification from the > > > device won't need to depend on haveing devd running. > > > > > > here is the patch: > > > http://people.freebsd.org/~bapt/devctl_multi_open.diff > > > > Shouldn't devctl_queue_data_f() use the requested malloc() flags instead of > > hardcoding M_NOWAIT? > This is an obvious fallback of holding mutex around the call to > per_devctl_queue_data_f(), which caused the author a trouble to use > M_WAITOK. > > Having n readers causes the patch to queue each message n times, that looks > like a waste. > Queuing the message only one time would require to somehow keep a state, to know which thread read which message, and figuring out when to free a message can be an headache. Given I don't think they'll be a lot of readers, I'm not sure it's worth the trouble. > I wonder why the waiting_threads stuff is needed at all. The cv could > be woken up unconditionally everytime. What is the reason for the cv_wait > call in cdevpriv data destructor ? You cannot have a thread doing e.g. > read on the file descriptor while destructor is run. > What will prevent you from having a thread stuck in read(), while an another one close() the fd ? Regards, Olivier From owner-freebsd-current@FreeBSD.ORG Wed Nov 30 16:42:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 613B01065673 for ; Wed, 30 Nov 2011 16:42:37 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.c2i.net [212.247.154.66]) by mx1.freebsd.org (Postfix) with ESMTP id E87A78FC14 for ; Wed, 30 Nov 2011 16:42:36 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 42985844; Wed, 30 Nov 2011 17:42:34 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Wed, 30 Nov 2011 17:39:58 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <20111130102439.E770E1065672@hub.freebsd.org> In-Reply-To: <20111130102439.E770E1065672@hub.freebsd.org> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201111301739.58889.hselasky@c2i.net> Cc: Thomas Mueller Subject: Re: man ugen error 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, 30 Nov 2011 16:42:37 -0000 On Wednesday 30 November 2011 11:24:39 Thomas Mueller wrote: > According to ugen man page, ugen can be compiled into the kernel with > device ugen > in config file. > > I tried that in the kernel config when upgrading from FreeBSD 9.0-RC1 to > RC2, but the kernel build stopped quickly with the message that ugen was > not valid. After removing that line from kernel config, "make kernel" was > successful. > > I didn't find "device ugen" anywhere in the conf/NOTES or conf/GENERIC > files. > > I hope this man page error can be fixed in time for FreeBSD 9.0-RELEASE. FYI: "device ugen" is now part of "device usb" Could you send me a manpage diff? --HPS From owner-freebsd-current@FreeBSD.ORG Wed Nov 30 16:44:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 690941065670; Wed, 30 Nov 2011 16:44:04 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.c2i.net [212.247.154.66]) by mx1.freebsd.org (Postfix) with ESMTP id B6B7B8FC12; Wed, 30 Nov 2011 16:44:03 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 42986322; Wed, 30 Nov 2011 17:44:01 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Wed, 30 Nov 2011 17:41:25 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <20111130124320.GA1449@azathoth.lan> In-Reply-To: <20111130124320.GA1449@azathoth.lan> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201111301741.25734.hselasky@c2i.net> Cc: Baptiste Daroussin Subject: Re: [patch] turning devctl into a "multiple openable" device 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, 30 Nov 2011 16:44:04 -0000 On Wednesday 30 November 2011 13:43:20 Baptiste Daroussin wrote: > Hi all, > > With the help of cognet, I wrote a patch to turn devctl into a multiple > openable device, that mean that it will allow to open /dev/devctl in > multiple programs, for example hald and everythings that want to receive > notification from the device won't need to depend on haveing devd running. > > here is the patch: > http://people.freebsd.org/~bapt/devctl_multi_open.diff > > regards, > bapt Comment: Is the track-close flag set for the devfs sw? --HPS From owner-freebsd-current@FreeBSD.ORG Wed Nov 30 16:20:07 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 308A6106564A; Wed, 30 Nov 2011 16:20:07 +0000 (UTC) (envelope-from mlfbsd@kanar.ci0.org) Received: from kanar.ci0.org (unknown [IPv6:2a01:e0b:1:50:40:63ff:feea:93a]) by mx1.freebsd.org (Postfix) with ESMTP id B5FDC8FC14; Wed, 30 Nov 2011 16:20:06 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.2/8.14.3) with ESMTP id pAUGKH95053575; Wed, 30 Nov 2011 17:20:17 +0100 (CET) (envelope-from mlfbsd@kanar.ci0.org) Received: (from mlfbsd@localhost) by kanar.ci0.org (8.14.2/8.14.3/Submit) id pAUGKH0R053574; Wed, 30 Nov 2011 17:20:17 +0100 (CET) (envelope-from mlfbsd) Date: Wed, 30 Nov 2011 17:20:17 +0100 From: Olivier Houchard To: Kostik Belousov Message-ID: <20111130162017.GA53362@ci0.org> References: <20111130124320.GA1449@azathoth.lan> <201111301005.11938.jhb@freebsd.org> <20111130154636.GX50300@deviant.kiev.zoral.com.ua> <20111130155521.GA52567@ci0.org> <20111130160450.GY50300@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111130160450.GY50300@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Wed, 30 Nov 2011 16:51:06 +0000 Cc: Baptiste Daroussin , freebsd-current@freebsd.org, Olivier Houchard Subject: Re: [patch] turning devctl into a "multiple openable" device 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, 30 Nov 2011 16:20:07 -0000 On Wed, Nov 30, 2011 at 06:04:50PM +0200, Kostik Belousov wrote: > > > I wonder why the waiting_threads stuff is needed at all. The cv could > > > be woken up unconditionally everytime. What is the reason for the cv_wait > > > call in cdevpriv data destructor ? You cannot have a thread doing e.g. > > > read on the file descriptor while destructor is run. > > > > > > > What will prevent you from having a thread stuck in read(), while an another > > one close() the fd ? > > > Nothing, but file reference count goes to zero only after the thread > stuck in read is unstuck. Cdevpriv destructor is run only when file > reference count becomes zero, i.e. there can be no any accessing threads, > and new accesses are impossible since file descriptors also own references > on the file. Right, I was a bit confused, this part can be removed. Regards, Olivier From owner-freebsd-current@FreeBSD.ORG Wed Nov 30 18:01:30 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59846106566C for ; Wed, 30 Nov 2011 18:01:30 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 162C08FC15 for ; Wed, 30 Nov 2011 18:01:29 +0000 (UTC) Received: by iakl21 with SMTP id l21so1727060iak.13 for ; Wed, 30 Nov 2011 10:01:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=pfi/C7BCe3M5JJeaVQwtRNoAqtIu/61CkoRmmAePr2s=; b=D9hRZM7vVm/TZ9dfdBQ+ZeyQlIDsaXCD/2I6vdQtPifjHM4GUffR3GpiEo2ITsE9zp 5SoLzfKd1R+IZKKNC8d/aZkGb59IBIWwjduixKlj5LBvBX1ciIW9z3AxCr1jsP4F5VVO Kv9ddEu03vCiguxkAJ9LG3o1ReBL/X+Wl+F+8= Received: by 10.42.117.193 with SMTP id u1mr4384431icq.24.1322676089490; Wed, 30 Nov 2011 10:01:29 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id v18sm10612728ibh.4.2011.11.30.10.01.26 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Nov 2011 10:01:28 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 30 Nov 2011 10:00:00 -0800 From: YongHyeon PYUN Date: Wed, 30 Nov 2011 10:00:00 -0800 To: Florian Wilkemeyer Message-ID: <20111130180000.GA9323@michelle.cdnetworks.com> References: <4ED63C2D.8020209@f-ws.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ED63C2D.8020209@f-ws.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, davidch@freebsd.org Subject: Re: if_bce tx / rx tick limits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 18:01:30 -0000 On Wed, Nov 30, 2011 at 03:22:37PM +0100, Florian Wilkemeyer wrote: > Hi, > > i wonder about the bce driver's tx / rx tick limits > (ticks and ticks_int are limited to 100; otherwise default value (80) > gets used) > > (if_bce.c line 921 / 933 .. ) > I think this highly depends on firmware of controller. David may be able to answer(CCed). > On DragonFly BSD the values can be set much higher (such as 1000 ..) > which would be great in a high-traffic setup. > (On linux there's no limit too as far as i remember) > No, the value should be represented with 10bits so having no limit looks like a bug in Linux. > > > Is there any reason why its limited down to 100? > > > Thanks > Florian > > > P.S. > I'm sorry if this was the wrong mailing list for it; i don't know whats > the right list for this (probably net or driver ?) From owner-freebsd-current@FreeBSD.ORG Wed Nov 30 21:01:57 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6ECC41065672; Wed, 30 Nov 2011 21:01:57 +0000 (UTC) (envelope-from jlaffaye.freebsd@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9D9AF8FC17; Wed, 30 Nov 2011 21:01:56 +0000 (UTC) Received: by eekc13 with SMTP id c13so916259eek.13 for ; Wed, 30 Nov 2011 13:01:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=iUxmg1gjKbtwEzIuS42SXpKR+dWUJslWKbxCzqb2ay8=; b=WwGQbr+7sDiWl77lwC0KhH2/yTvDrm7aBFABxWFVcUNVs2YKCziDSYZDqjZjgyqaNK jZwOI/xAjyeAIA/OIpjfaF++/RXmQhpfLs0eXVsOHxzXLhE+Yb9npSh7DhgXdqevqWor 171q8ZtoWVEivCtAz85MaECjwwxkzt097CQNM= Received: by 10.216.55.137 with SMTP id k9mr69296wec.32.1322685137940; Wed, 30 Nov 2011 12:32:17 -0800 (PST) Received: from chulak.jlaffaye.net (lantea.jlaffaye.net. [109.190.125.169]) by mx.google.com with ESMTPS id em4sm3297525wbb.20.2011.11.30.12.32.16 (version=SSLv3 cipher=OTHER); Wed, 30 Nov 2011 12:32:17 -0800 (PST) Sender: Julien Laffaye Message-ID: <4ED692D2.5060407@FreeBSD.org> Date: Wed, 30 Nov 2011 21:32:18 +0100 From: Julien Laffaye User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110922 Thunderbird/6.0.2 MIME-Version: 1.0 To: ports@freebsd.org, current@freebsd.org, hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Baptiste Daroussin Subject: [CFT] pkgng alpha2 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, 30 Nov 2011 21:01:57 -0000 Hi all, We are releasing pkgng (the next pkg_install) alpha2 to the world and we want you to test it! There is no "good" method to test it: use it as you would in the real world. Of course, you are encouraged to backup your data or test it in some kind of virtualized environment. After using it for some time, you will certainly find bugs. You can report them on the issues tracker [1]. If you find missing features, that is things you can't do with pkgng but can with pkg_install, you can also report them. New features are not the expected outcome of this call, as we want to release a final version ASAP. FYI, an alpha3 should follow shortly to fix issues in alpha3 and test additional features. After that, there will be a feature freeze with beta1. Getting started: You can download or git clone the source code of pkgng on the github page [2]. Then, a boring `make' followed by `make install' will do it. If you have some packages installed by pkg_add, you can convert the old database to the pkgng database with the 'pkg2ng' shell script in the ports/ folder. You can also add packages from the ports tree (with bsd.pkgng.mk) or with a pkgng repository. All is documented in the README and manpages. If you are a newcomer to pkgng, this doc reading step is also valuable to us. Indeed, if you fight to get the right infos, or if some things feel counter intuitive, we should improve it! Which brings me to the topic of contributing to pkgng. The best thing you can do is to write down the documentation you would have loved to read while testing pkgng! And of course, if you have a patch with your bug report, it is much appreciated. If you read this entire mail and wonder what is this pkgng thing, you can read the wiki page [3], bapt's presentation from BSDCan [4], EuroBSDCon [5] [6] and browse the source code. Regards, Julien, on behalf of the pkgng team. And remember, we _do_ want to hear back from you! Please also note that it is still alpha code and it can kill kitten and puppies. You are warned ;-) [1] : https://github.com/pkgng/pkgng/issues [2] : https://github.com/pkgng/pkgng [3] : http://wiki.freebsd.org/pkgng [4] : http://people.freebsd.org/~bapt/pkgng-bsdcan2011.pdf [5] : http://wiki.freebsd.org/201110DevSummit/Ports?action=AttachFile&do=get&target=pkgng-devsummit.pdf [6] : http://wiki.freebsd.org/201110DevSummit?action=AttachFile&do=get&target=pkgng-devsummit-track.pdf From owner-freebsd-current@FreeBSD.ORG Wed Nov 30 22:32:48 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8C06106566B; Wed, 30 Nov 2011 22:32:48 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id CE6F68FC16; Wed, 30 Nov 2011 22:32:44 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA27772; Thu, 01 Dec 2011 00:32:32 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RVshc-0004Yw-HQ; Thu, 01 Dec 2011 00:32:32 +0200 Message-ID: <4ED6AEFE.4010106@FreeBSD.org> Date: Thu, 01 Dec 2011 00:32:30 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Gleb Kurtsou , =?UTF-8?B?R3VzdGF1IFDDqXJleg==?= , Michael Butler , Alan Cox References: <4ECF7440.4070300@entel.upc.edu> <4ECF8F05.8000007@protected-networks.net> <4ED0C40D.5010307@entel.upc.edu> <4ED0D963.1030702@entel.upc.edu> <4ED0DF1F.6090901@FreeBSD.org> <20111126163343.GA9150@reks> In-Reply-To: <20111126163343.GA9150@reks> X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-emulation@FreeBSD.org, FreeBSD current Subject: Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464} 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, 30 Nov 2011 22:32:49 -0000 on 26/11/2011 18:33 Gleb Kurtsou said the following: > Using new vm_page_alloc_contig() may be a better option here. Can't help > with patch, stuck with pre Nov 15 CURRENT myself. on 27/11/2011 19:09 Alan Cox said the following: > vm_page_alloc_contig() should be used instead. My take on the patch: http://people.freebsd.org/~avg/vbox-10.patch This is for head only, no check for FreeBSD version. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Nov 30 23:07:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 066D1106564A; Wed, 30 Nov 2011 23:07:35 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-emulation@FreeBSD.org Date: Wed, 30 Nov 2011 18:07:18 -0500 User-Agent: KMail/1.6.2 References: <4ECF7440.4070300@entel.upc.edu> <20111126163343.GA9150@reks> <4ED6AEFE.4010106@FreeBSD.org> In-Reply-To: <4ED6AEFE.4010106@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111301807.21351.jkim@FreeBSD.org> Cc: Gleb Kurtsou , Gustau =?iso-8859-1?q?P=E9rez?= , FreeBSD current , Alan Cox , Andriy Gapon , Michael Butler Subject: Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464} 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, 30 Nov 2011 23:07:35 -0000 On Wednesday 30 November 2011 05:32 pm, Andriy Gapon wrote: > on 26/11/2011 18:33 Gleb Kurtsou said the following: > > Using new vm_page_alloc_contig() may be a better option here. > > Can't help with patch, stuck with pre Nov 15 CURRENT myself. > > on 27/11/2011 19:09 Alan Cox said the following: > > vm_page_alloc_contig() should be used instead. > > My take on the patch: > http://people.freebsd.org/~avg/vbox-10.patch > This is for head only, no check for FreeBSD version. Actually, I did the same thing last night: http://people.freebsd.org/~jkim/patch-src-VBox-Runtime-r0drv-freebsd-memobj-r0drv-freebsd.c This is a drop-in replacement for the patch. The only practical difference I see from yours is I used VM_ALLOC_INTERRUPT instead of VM_ALLOC_NORMAL. I believe this function may be used in interrupt context. FYI, I tried FreeBSD 9 and Fedora 10 without problem. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Wed Nov 30 23:23:02 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2A6D106566C for ; Wed, 30 Nov 2011 23:23:02 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id ADFD68FC0A for ; Wed, 30 Nov 2011 23:23:02 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id pAUNMjRe094482 for ; Wed, 30 Nov 2011 15:22:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1322695365; bh=W/I2NPc+NpmROlERN7TbuY7lm2ncxfMC/ZEnDVDh3ks=; h=Subject:From:Reply-To:To:Content-Type:Date:Message-ID: Mime-Version:Content-Transfer-Encoding; b=Y77unI/kKQY46WTn0zt6VvGrJyo6nTOgN3R+uQmsAl1M+NCIIEuQE4yPF8M4lLN1q 4Y8OenluIY+scLA+IgJc1X18Q1v7RaeGXJ/p8/b9Lmpbl6RWGiN7GLPziVfskqb+eE q0LX374ziKw6+Tw8ApOzL4J5Vzg+RAXuYs16x9zk= From: Sean Bruno To: "freebsd-current@freebsd.org" Content-Type: text/plain; charset="UTF-8" Date: Wed, 30 Nov 2011 15:22:45 -0800 Message-ID: <1322695365.2764.9.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Subject: Console Spam: acpi_tz0: _TMP value is absurd, ignored (-73.0C) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@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: Wed, 30 Nov 2011 23:23:03 -0000 I have a Shuttle based intel box that appears to have some pretty bad ACPI implementation. Is there a good way to quiesce this spam? The console fills up with repeated warnings that never cease. FreeBSD testbox 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r228164S: Wed Nov 30 16:19:16 PST 2011 sbruno@testbox:/tmp/foo/bsd/head/sys/GENERIC_NO_1394 amd64 [sbruno@testbox ~]$ sysctl -a |grep thermal "Giant","ACPI thermal zone" hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: -273.2C hw.acpi.thermal.tz0.active: -2 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 50.0C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 60.0C hw.acpi.thermal.tz0._ACx: 50.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: 4 hw.acpi.thermal.tz0._TC2: 3 hw.acpi.thermal.tz0._TSP: 60 ... dev.acpi_tz.0.%desc: Thermal Zone dev.acpi_tz.0.%driver: acpi_tz dev.acpi_tz.0.%location: handle=\_TZ_.THRM dev.acpi_tz.0.%pnpinfo: _HID=none _UID=0 dev.acpi_tz.0.%parent: acpi0 Sean From owner-freebsd-current@FreeBSD.ORG Wed Nov 30 23:27:57 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 91DE9106566B; Wed, 30 Nov 2011 23:27:55 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-emulation@FreeBSD.org Date: Wed, 30 Nov 2011 18:27:43 -0500 User-Agent: KMail/1.6.2 References: <4ECF7440.4070300@entel.upc.edu> <4ED6AEFE.4010106@FreeBSD.org> <201111301807.21351.jkim@FreeBSD.org> In-Reply-To: <201111301807.21351.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111301827.46079.jkim@FreeBSD.org> Cc: Alan Cox , Gleb Kurtsou , FreeBSD current , Andriy Gapon Subject: Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464} 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, 30 Nov 2011 23:27:57 -0000 On Wednesday 30 November 2011 06:07 pm, Jung-uk Kim wrote: > On Wednesday 30 November 2011 05:32 pm, Andriy Gapon wrote: > > on 26/11/2011 18:33 Gleb Kurtsou said the following: > > > Using new vm_page_alloc_contig() may be a better option here. > > > Can't help with patch, stuck with pre Nov 15 CURRENT myself. > > > > on 27/11/2011 19:09 Alan Cox said the following: > > > vm_page_alloc_contig() should be used instead. > > > > My take on the patch: > > http://people.freebsd.org/~avg/vbox-10.patch > > This is for head only, no check for FreeBSD version. > > Actually, I did the same thing last night: > > http://people.freebsd.org/~jkim/patch-src-VBox-Runtime-r0drv-freebs >d-memobj-r0drv-freebsd.c > > This is a drop-in replacement for the patch. The only practical > difference I see from yours is I used VM_ALLOC_INTERRUPT instead of > VM_ALLOC_NORMAL. I believe this function may be used in interrupt > context. FYI, I tried FreeBSD 9 and Fedora 10 without problem. BTW, I needed another patch to build virtual-ose-kmod on head: http://people.freebsd.org/~jkim/patch-src-VBox-HostDrivers-Support-freebsd-SUPDrv-freebsd.c FYI... Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Wed Nov 30 23:35:35 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFEC2106564A; Wed, 30 Nov 2011 23:35:35 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5C58A8FC08; Wed, 30 Nov 2011 23:35:33 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA28505; Thu, 01 Dec 2011 01:35:31 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RVtgZ-0004bm-77; Thu, 01 Dec 2011 01:35:31 +0200 Message-ID: <4ED6BDC1.8020600@FreeBSD.org> Date: Thu, 01 Dec 2011 01:35:29 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Jung-uk Kim References: <4ECF7440.4070300@entel.upc.edu> <4ED6AEFE.4010106@FreeBSD.org> <201111301807.21351.jkim@FreeBSD.org> <201111301827.46079.jkim@FreeBSD.org> In-Reply-To: <201111301827.46079.jkim@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alan Cox , freebsd-emulation@FreeBSD.org, FreeBSD current , Gleb Kurtsou Subject: Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464} 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, 30 Nov 2011 23:35:35 -0000 on 01/12/2011 01:27 Jung-uk Kim said the following: > On Wednesday 30 November 2011 06:07 pm, Jung-uk Kim wrote: >> On Wednesday 30 November 2011 05:32 pm, Andriy Gapon wrote: >>> on 26/11/2011 18:33 Gleb Kurtsou said the following: >>>> Using new vm_page_alloc_contig() may be a better option here. >>>> Can't help with patch, stuck with pre Nov 15 CURRENT myself. >>> >>> on 27/11/2011 19:09 Alan Cox said the following: >>>> vm_page_alloc_contig() should be used instead. >>> >>> My take on the patch: >>> http://people.freebsd.org/~avg/vbox-10.patch >>> This is for head only, no check for FreeBSD version. >> >> Actually, I did the same thing last night: >> >> http://people.freebsd.org/~jkim/patch-src-VBox-Runtime-r0drv-freebs >> d-memobj-r0drv-freebsd.c >> >> This is a drop-in replacement for the patch. The only practical >> difference I see from yours is I used VM_ALLOC_INTERRUPT instead of >> VM_ALLOC_NORMAL. I believe this function may be used in interrupt >> context. FYI, I tried FreeBSD 9 and Fedora 10 without problem. > > BTW, I needed another patch to build virtual-ose-kmod on head: > > http://people.freebsd.org/~jkim/patch-src-VBox-HostDrivers-Support-freebsd-SUPDrv-freebsd.c > > FYI... Yep, me too, obviously :-) Thank you for the complete vm_page_alloc_contig patch! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Nov 30 23:40:53 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2261F106564A; Wed, 30 Nov 2011 23:40:53 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 37D128FC0C; Wed, 30 Nov 2011 23:40:52 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA28554; Thu, 01 Dec 2011 01:40:50 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RVtli-0004bz-DZ; Thu, 01 Dec 2011 01:40:50 +0200 Message-ID: <4ED6BF01.2080602@FreeBSD.org> Date: Thu, 01 Dec 2011 01:40:49 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: sbruno@FreeBSD.org References: <1322695365.2764.9.camel@hitfishpass-lx.corp.yahoo.com> In-Reply-To: <1322695365.2764.9.camel@hitfishpass-lx.corp.yahoo.com> X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" , Sean Bruno Subject: Re: Console Spam: acpi_tz0: _TMP value is absurd, ignored (-73.0C) 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, 30 Nov 2011 23:40:53 -0000 on 01/12/2011 01:22 Sean Bruno said the following: > I have a Shuttle based intel box that appears to have some pretty bad > ACPI implementation. Is there a good way to quiesce this spam? Ask on acpi@ list. Kidding :-) or not. Try hw.acpi.thermal.polling_rate=0. > The console fills up with repeated warnings that never cease. > FreeBSD testbox 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r228164S: Wed Nov > 30 16:19:16 PST 2011 > sbruno@testbox:/tmp/foo/bsd/head/sys/GENERIC_NO_1394 amd64 > > [sbruno@testbox ~]$ sysctl -a |grep thermal > "Giant","ACPI thermal zone" > hw.acpi.thermal.min_runtime: 0 > hw.acpi.thermal.polling_rate: 10 > hw.acpi.thermal.user_override: 0 > hw.acpi.thermal.tz0.temperature: -273.2C > hw.acpi.thermal.tz0.active: -2 > hw.acpi.thermal.tz0.passive_cooling: 1 > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.thermal.tz0._PSV: 50.0C > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._CRT: 60.0C > hw.acpi.thermal.tz0._ACx: 50.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 > hw.acpi.thermal.tz0._TC1: 4 > hw.acpi.thermal.tz0._TC2: 3 > hw.acpi.thermal.tz0._TSP: 60 > ... > dev.acpi_tz.0.%desc: Thermal Zone > dev.acpi_tz.0.%driver: acpi_tz > dev.acpi_tz.0.%location: handle=\_TZ_.THRM > dev.acpi_tz.0.%pnpinfo: _HID=none _UID=0 > dev.acpi_tz.0.%parent: acpi0 -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Nov 30 23:55:35 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 76587106564A; Wed, 30 Nov 2011 23:55:35 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Wed, 30 Nov 2011 18:55:24 -0500 User-Agent: KMail/1.6.2 References: <1322695365.2764.9.camel@hitfishpass-lx.corp.yahoo.com> <4ED6BF01.2080602@FreeBSD.org> In-Reply-To: <4ED6BF01.2080602@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111301855.27646.jkim@FreeBSD.org> Cc: Sean Bruno , Andriy Gapon Subject: Re: Console Spam: acpi_tz0: _TMP value is absurd, ignored (-73.0C) 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, 30 Nov 2011 23:55:35 -0000 On Wednesday 30 November 2011 06:40 pm, Andriy Gapon wrote: > on 01/12/2011 01:22 Sean Bruno said the following: > > I have a Shuttle based intel box that appears to have some pretty > > bad ACPI implementation. Is there a good way to quiesce this > > spam? > > Ask on acpi@ list. > Kidding :-) or not. > Try hw.acpi.thermal.polling_rate=0. Adding the following line in /boot/loader.conf will disable acpi_thermal(4) completely: debug.acpi.disabled="thermal" Jung-uk Kim > > The console fills up with repeated warnings that never cease. > > FreeBSD testbox 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r228164S: > > Wed Nov 30 16:19:16 PST 2011 > > sbruno@testbox:/tmp/foo/bsd/head/sys/GENERIC_NO_1394 amd64 > > > > [sbruno@testbox ~]$ sysctl -a |grep thermal > > "Giant","ACPI thermal zone" > > hw.acpi.thermal.min_runtime: 0 > > hw.acpi.thermal.polling_rate: 10 > > hw.acpi.thermal.user_override: 0 > > hw.acpi.thermal.tz0.temperature: -273.2C > > hw.acpi.thermal.tz0.active: -2 > > hw.acpi.thermal.tz0.passive_cooling: 1 > > hw.acpi.thermal.tz0.thermal_flags: 0 > > hw.acpi.thermal.tz0._PSV: 50.0C > > hw.acpi.thermal.tz0._HOT: -1 > > hw.acpi.thermal.tz0._CRT: 60.0C > > hw.acpi.thermal.tz0._ACx: 50.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 > > hw.acpi.thermal.tz0._TC1: 4 > > hw.acpi.thermal.tz0._TC2: 3 > > hw.acpi.thermal.tz0._TSP: 60 > > ... > > dev.acpi_tz.0.%desc: Thermal Zone > > dev.acpi_tz.0.%driver: acpi_tz > > dev.acpi_tz.0.%location: handle=\_TZ_.THRM > > dev.acpi_tz.0.%pnpinfo: _HID=none _UID=0 > > dev.acpi_tz.0.%parent: acpi0 From owner-freebsd-current@FreeBSD.ORG Wed Nov 30 23:56:57 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21F161065673 for ; Wed, 30 Nov 2011 23:56:57 +0000 (UTC) (envelope-from venture37@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 906E98FC08 for ; Wed, 30 Nov 2011 23:56:56 +0000 (UTC) Received: by eaai12 with SMTP id i12so1966625eaa.13 for ; Wed, 30 Nov 2011 15:56:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=q1CUACWaCsFVTXpZ7OHQ2qrlnMPdDpPHH16orpzEG6Y=; b=bAeLWog44cVwbGnoHi4f27Gn4mfMic+xYKvgXpA77QQ89QEk8bevd2awwIgBqU410y tAXHOKir8s/rV6rE2Mdfc8rETxrJzzGlQZf+sdLA95u4kmF6k/FkkNK8d2H2Yeu25H8l dzDfP1nkEh4a33ScM1gB2EvI8ct9MrrNXV7xw= Received: by 10.180.103.131 with SMTP id fw3mr3150616wib.57.1322697415443; Wed, 30 Nov 2011 15:56:55 -0800 (PST) Received: from Sevans-MacBook-Pro.local (cpc2-brig17-2-0-cust527.3-3.cable.virginmedia.com. [81.101.198.16]) by mx.google.com with ESMTPS id fk3sm3849643wbb.10.2011.11.30.15.56.53 (version=SSLv3 cipher=OTHER); Wed, 30 Nov 2011 15:56:53 -0800 (PST) Message-ID: <4ED6C2C3.4050007@gmail.com> Date: Wed, 30 Nov 2011 23:56:51 +0000 From: Sevan / Venture37 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20111129213413.GB14357@stack.nl> <4ED551B5.8090809@gmail.com> <4ED583D0.6030403@FreeBSD.org> <4ED653B6.1010607@gmail.com> In-Reply-To: <4ED653B6.1010607@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: WITHOUT_PROFILE=yes by default 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, 30 Nov 2011 23:56:57 -0000 On 30/11/2011 16:03, Sevan / Venture37 wrote: > system breaks if you try to add dtrace support to a system built with > profile support. sorry, I meant *without* profile support. Sevan From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 00:25:15 2011 Return-Path: Delivered-To: current@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 1233) id 9880F1065673; Thu, 1 Dec 2011 00:25:15 +0000 (UTC) Date: Thu, 1 Dec 2011 00:25:15 +0000 From: Alexander Best To: Warner Losh Message-ID: <20111201002515.GA50028@freebsd.org> References: <201111291607.26546.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: Doug Barton , Warner Losh , current@FreeBSD.ORG, John Baldwin Subject: Re: Remove debug echo 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, 01 Dec 2011 00:25:15 -0000 On Tue Nov 29 11, Warner Losh wrote: > kill it. > > Warner > On Nov 29, 2011, at 2:07 PM, John Baldwin wrote: > > > Any objections to this? It removes a weird line during 'make -s buildworld' > > output and I think it was debugging accidentally left in in 213077 by Warner: > > > > Index: newvers.sh > > =================================================================== > > --- newvers.sh (revision 228074) > > +++ newvers.sh (working copy) > > @@ -99,7 +99,6 @@ for dir in /bin /usr/bin /usr/local/bin; do > > done > > > > if [ -n "$svnversion" ] ; then > > - echo "$svnversion" > > svn=`cd ${SYSDIR} && $svnversion` > > case "$svn" in > > [0-9]*) svn=" r${svn}" ;; also... when running buildkernel via 'make -s', do we really need all those module printfs? i see messages for "cleandir", "obj", "depend" and "all". i think for 'make -s', that's pure overkill! for a GENERIC kernel, 'make' enters ~ 670 module dirs. take that times 4 and you'll get 2680 lines of output. not really *silent*, is it? ;) cheers. alex > > > > -- > > John Baldwin > > > > > From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 01:21:39 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52A17106566C; Thu, 1 Dec 2011 01:21:39 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id D02338FC12; Thu, 1 Dec 2011 01:21:38 +0000 (UTC) Received: by ywp17 with SMTP id 17so2015763ywp.13 for ; Wed, 30 Nov 2011 17:21:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=yG0BVYqicCJVLxOUIgutgs7NXtj145hCWf22HHc7Cy4=; b=CntwAULpFIhyJKLVJB3ogEdBlBU/xpH4giSsUTbftyMcuuGPL5l2nCSNkT4tyXJ8Xi flvXSNTYKubly3y+qfILhcqMm2oOgNTkznmZBf+2Mcrtb0MMczoMPhYoHbNxXNf7TUjZ MgQqKx4toeynzjTUhMxCzPXTOLtcgWkx4AVmI= MIME-Version: 1.0 Received: by 10.182.40.65 with SMTP id v1mr979867obk.72.1322702498107; Wed, 30 Nov 2011 17:21:38 -0800 (PST) Received: by 10.182.62.227 with HTTP; Wed, 30 Nov 2011 17:21:37 -0800 (PST) In-Reply-To: <20111201002515.GA50028@freebsd.org> References: <201111291607.26546.jhb@freebsd.org> <20111201002515.GA50028@freebsd.org> Date: Wed, 30 Nov 2011 17:21:37 -0800 Message-ID: From: Garrett Cooper To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Doug Barton , Warner Losh , current@freebsd.org, Warner Losh Subject: Re: Remove debug echo 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, 01 Dec 2011 01:21:39 -0000 On Wed, Nov 30, 2011 at 4:25 PM, Alexander Best wrote= : > On Tue Nov 29 11, Warner Losh wrote: >> kill it. >> >> Warner >> On Nov 29, 2011, at 2:07 PM, John Baldwin wrote: >> >> > Any objections to this? =A0It removes a weird line during 'make -s bui= ldworld' >> > output and I think it was debugging accidentally left in in 213077 by = Warner: >> > >> > Index: newvers.sh >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > --- newvers.sh =A0 =A0 =A0(revision 228074) >> > +++ newvers.sh =A0 =A0 =A0(working copy) >> > @@ -99,7 +99,6 @@ for dir in /bin /usr/bin /usr/local/bin; do >> > done >> > >> > if [ -n "$svnversion" ] ; then >> > - =A0 echo "$svnversion" >> > =A0 =A0 svn=3D`cd ${SYSDIR} && $svnversion` >> > =A0 =A0 case "$svn" in >> > =A0 =A0 [0-9]*) svn=3D" r${svn}" ;; > > also... > > when running buildkernel via 'make -s', do we really need all those modul= e > printfs? i see messages for "cleandir", "obj", "depend" and "all". i thin= k for > 'make -s', that's pure overkill! > > for a GENERIC kernel, 'make' enters ~ 670 module dirs. take that times 4 = and > you'll get 2680 lines of output. not really *silent*, is it? ;) pmake sucks as far as diagnostic output is concerned when compared with gmake. I'd rather not have to fish through with -j1 (if I'm lucky and it's not a race) to determine what directory created the "Error Code" output. With the printouts discussed here, at least you have a chance at determining what the issue was. Maybe it's just me, but I like noisy builds -- otherwise the amount of time I have to spend root-causing the issue becomes expensive. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 01:43:49 2011 Return-Path: Delivered-To: current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 1D0AC1065670; Thu, 1 Dec 2011 01:43:49 +0000 (UTC) Date: Thu, 1 Dec 2011 01:43:49 +0000 From: Alexander Best To: Garrett Cooper Message-ID: <20111201014349.GA61475@freebsd.org> References: <201111291607.26546.jhb@freebsd.org> <20111201002515.GA50028@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Cc: Doug Barton , Warner Losh , current@freebsd.org, Warner Losh Subject: Re: Remove debug echo 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, 01 Dec 2011 01:43:49 -0000 On Wed Nov 30 11, Garrett Cooper wrote: > On Wed, Nov 30, 2011 at 4:25 PM, Alexander Best wrote: > > On Tue Nov 29 11, Warner Losh wrote: > >> kill it. > >> > >> Warner > >> On Nov 29, 2011, at 2:07 PM, John Baldwin wrote: > >> > >> > Any objections to this?  It removes a weird line during 'make -s buildworld' > >> > output and I think it was debugging accidentally left in in 213077 by Warner: > >> > > >> > Index: newvers.sh > >> > =================================================================== > >> > --- newvers.sh      (revision 228074) > >> > +++ newvers.sh      (working copy) > >> > @@ -99,7 +99,6 @@ for dir in /bin /usr/bin /usr/local/bin; do > >> > done > >> > > >> > if [ -n "$svnversion" ] ; then > >> > -   echo "$svnversion" > >> >     svn=`cd ${SYSDIR} && $svnversion` > >> >     case "$svn" in > >> >     [0-9]*) svn=" r${svn}" ;; > > > > also... > > > > when running buildkernel via 'make -s', do we really need all those module > > printfs? i see messages for "cleandir", "obj", "depend" and "all". i think for > > 'make -s', that's pure overkill! > > > > for a GENERIC kernel, 'make' enters ~ 670 module dirs. take that times 4 and > > you'll get 2680 lines of output. not really *silent*, is it? ;) > > pmake sucks as far as diagnostic output is concerned when compared > with gmake. I'd rather not have to fish through with -j1 (if I'm lucky > and it's not a race) to determine what directory created the "Error > Code" output. With the printouts discussed here, at least you have a > chance at determining what the issue was. > Maybe it's just me, but I like noisy builds -- otherwise the > amount of time I have to spend root-causing the issue becomes > expensive. ehmmm...a noisy silent flag? i totally agree, if we're talking about 'make' in its default mode, but what's the point of a silent flag, if it produces > 2500 lines of output? nobody uses the -s flag for diagnostics. its purpose is to build a kernel without producing a lot of output and also not fiddling with stdout/stderr to achieve that goal. cheers. alex > Thanks, > -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 01:59:35 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23F4A106564A; Thu, 1 Dec 2011 01:59:35 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8B9CA8FC12; Thu, 1 Dec 2011 01:59:34 +0000 (UTC) Received: by ggnk5 with SMTP id k5so2055553ggn.13 for ; Wed, 30 Nov 2011 17:59:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=KLEcYTMtxM/BKFeGmaXLYB59WT1XWn5fyt/saa2XVoc=; b=qK2TKxikgcpJxxFyohN7WK/oXQs16W2fad/fBXNXn/FDjfDAiSgS5WbdjFip6+A8zC YPqhVM6RVjkObkwVCEs4dhO3nxzSMZCQvcJqQnD6ZS6aIrFs9rguYoxFGMmJmN+Ol4jT BT0H3HliDf7bLSLPndbzMPGrr/BFdIs0CwM+Y= MIME-Version: 1.0 Received: by 10.182.154.66 with SMTP id vm2mr1036095obb.52.1322704773881; Wed, 30 Nov 2011 17:59:33 -0800 (PST) Received: by 10.182.62.227 with HTTP; Wed, 30 Nov 2011 17:59:33 -0800 (PST) In-Reply-To: <20111201014349.GA61475@freebsd.org> References: <201111291607.26546.jhb@freebsd.org> <20111201002515.GA50028@freebsd.org> <20111201014349.GA61475@freebsd.org> Date: Wed, 30 Nov 2011 17:59:33 -0800 Message-ID: From: Garrett Cooper To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Doug Barton , Warner Losh , current@freebsd.org, Warner Losh Subject: Re: Remove debug echo 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, 01 Dec 2011 01:59:35 -0000 On Wed, Nov 30, 2011 at 5:43 PM, Alexander Best wrote= : > On Wed Nov 30 11, Garrett Cooper wrote: >> On Wed, Nov 30, 2011 at 4:25 PM, Alexander Best wr= ote: >> > On Tue Nov 29 11, Warner Losh wrote: >> >> kill it. >> >> >> >> Warner >> >> On Nov 29, 2011, at 2:07 PM, John Baldwin wrote: >> >> >> >> > Any objections to this? =A0It removes a weird line during 'make -s = buildworld' >> >> > output and I think it was debugging accidentally left in in 213077 = by Warner: >> >> > >> >> > Index: newvers.sh >> >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> > --- newvers.sh =A0 =A0 =A0(revision 228074) >> >> > +++ newvers.sh =A0 =A0 =A0(working copy) >> >> > @@ -99,7 +99,6 @@ for dir in /bin /usr/bin /usr/local/bin; do >> >> > done >> >> > >> >> > if [ -n "$svnversion" ] ; then >> >> > - =A0 echo "$svnversion" >> >> > =A0 =A0 svn=3D`cd ${SYSDIR} && $svnversion` >> >> > =A0 =A0 case "$svn" in >> >> > =A0 =A0 [0-9]*) svn=3D" r${svn}" ;; >> > >> > also... >> > >> > when running buildkernel via 'make -s', do we really need all those mo= dule >> > printfs? i see messages for "cleandir", "obj", "depend" and "all". i t= hink for >> > 'make -s', that's pure overkill! >> > >> > for a GENERIC kernel, 'make' enters ~ 670 module dirs. take that times= 4 and >> > you'll get 2680 lines of output. not really *silent*, is it? ;) >> >> =A0 =A0 pmake sucks as far as diagnostic output is concerned when compar= ed >> with gmake. I'd rather not have to fish through with -j1 (if I'm lucky >> and it's not a race) to determine what directory created the "Error >> Code" output. With the printouts discussed here, at least you have a >> chance at determining what the issue was. >> =A0 =A0 Maybe it's just me, but I like noisy builds -- otherwise the >> amount of time I have to spend root-causing the issue becomes >> expensive. > > ehmmm...a noisy silent flag? i totally agree, if we're talking about 'mak= e' in > its default mode, but what's the point of a silent flag, if it produces >= 2500 > lines of output? nobody uses the -s flag for diagnostics. its purpose is = to > build a kernel without producing a lot of output and also not fiddling wi= th > stdout/stderr to achieve that goal. What I really want is this: $ cat Makefile all: foo bar baz yadda foo bar yadda: baz: false $ gmake false gmake: *** [baz] Error 1 ^^^^ $ make all false *** Error code 1 Stop in /tmp. Otherwise diagnosing issues becomes a PITA with -j > 1 (with pmake I have to start using some serious grep'ing, and if I'm lucky I can find the source of error). If I get a few spare cycles I might just implement it and post a patch somewhere (the entering and leaving directory feature of gmake is really nice too, but it's less important.. unless you have the same target in multiple directories).. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 06:21:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EF011065670 for ; Thu, 1 Dec 2011 06:21:08 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Received: from loki.netlab.sk (loki.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 856D78FC1A for ; Thu, 1 Dec 2011 06:21:07 +0000 (UTC) Received: from atom.dino.sk (ttxa118.ttx-net.sk [193.110.186.118]) (AUTH: LOGIN milan, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by loki.netlab.sk with ESMTPSA; Thu, 01 Dec 2011 07:17:20 +0100 id 00033CB1.4ED71BF0.0000C8BA Date: Thu, 1 Dec 2011 07:20:40 +0100 From: Milan Obuch To: Sergey Kandaurov Message-ID: <20111201072040.7c76ba2d@atom.dino.sk> In-Reply-To: References: <20111126084402.1afbfc16@atom.dino.sk> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd8.2) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEX+/v7++v6YOTrq8PCcuIX989UvOSj++v0BNCbpAAAAB3RJTUUHsQwfFzs7RBhzUQAAAhJJREFUOI1dU8GOqzAMNKIoV1bvwD1i0ysqrHplIdBrVSX7ATSbd03VVvn9tQNtQy0hjAdn7LED4AAcPtWm9RV+MPSfxhBLx9ajd6X/ngB6/mTwnRSZua7i7Ca+0ctZKo4Qmz+JY13X6I3nFZBxIYW1PbgfQ5RP8g0XlltEWGf3cV03joYpRnFbvYDKbXjZlXyyhEZA4lI+cN3NaVXE4VKjSwTExO10eTEkkJVqIAD5z0nUBQJluQDRSQjcrBiHAJxZlAH5CUMBMC7OcJ4LMQNnxhZ1HYPscMc6J4UlWRMNwzOpCcAHKSICd1EDn83abdREIbXsHkD1OinP1aCUCOEVRaa1lMcvywUWdYgk13JQUpYNKmvXQ8Kw5ML9YI5h8SakctBc7E/IYuLhYd/zZIk+1gM1vNweQBvHE0j+oYah3sMqAytQYlZk6+ANaaawJdu3OFzYGMZ3iGpa3qMlq9ZH0VZTgrCtw/ngdYkEIIpSbP1bWQAdFdX9vocBdkH2qVjVmuMu3gI5rjs814EUdrCZgWlPaxZZ3RiLFUtr+ud0PXwp2dnQSNXgePt6AZpBj6UMJ7VQkzN4utVeaSW1Dhn/kblGrKeMvNGnzwX4zuEDarYz1KdPtR60Gul0Gued+515SJXhCsl+Tx/3kY/UDvicPll9mfu50t3tvQ/thZpJYgeuwdSKNJ6tCD98MCgoxLDaPxbwqqwPWaWiAAAAAElFTkSuQmCC X-Face: ak5rwz4-aUa>hPFZlcg,bXxn.(TN}e9DGFrKU\.i_'B[&5=pAd9o"j)5VSUYW:BRQG#^42Ev$Il|; Ztn=,C X-Operating-System: FreeBSD/amd64 8.2-STABLE Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Maxim Khitrov , freebsd-current@freebsd.org Subject: Re: Incorrect tag= in /usr/src/share/examples/cvsup/sta(ble|ndard) in 9.0-PRERELEASE? 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, 01 Dec 2011 06:21:08 -0000 On Tue, 29 Nov 2011 19:22:39 +0300 Sergey Kandaurov wrote: > On 29 November 2011 20:16, Maxim Khitrov wrote: > > On Tue, Nov 29, 2011 at 10:30 AM, Sergey Kandaurov > > wrote: > >> On 26 November 2011 11:44, Milan Obuch > >> wrote: > >>> Hi, > >>> > >>> I am playing a bit with 9.0-PRERELEASE compiling it from source > >>> updated via csup. In both example files there is line specifying > >>> what to csup > >>> > >>> *default release=cvs tag=RELENG_8 > >>> > >>> which is incorrect, I think. It is convenient for me to issue just > >>> > >>> csup -h cvsup.freebsd.sk /usr/share/examples/cvsup/stable-supfile > >>> > >>> to update full sources without need to create any cvsup config > >>> file, however in system installed from 9.0 snapshot (maybe two > >>> weeks old) this file points to version 8 files, so I need to > >>> correct it for 9.0-PRERELEASE to not accidentally download older > >>> version sources. > >>> > >>> The same is also true after upgrade from source - make > >>> installworld install example files pointing to older version... > >>> > >>> Is it something I do not know about or is it an oversight? I > >>> think this line should already be changed to new tag... > >>> > >>> *default release=cvs tag=RELENG_9 > >> > >> Hi. > >> > >> Fixed. Thanks for your report. > >> Now cvs tag points to RELENG_9 in 9.x sources. > > > > Should standard-supfile also be updated to point to RELENG_9_0? I'm > > using csup with "tag=RELENG_9_0" and standard-supfile still points > > to HEAD. > > Yep, sure. > I just sent a request to the Release Engineering Team. > It works for me now as expected, thanks. Anyway, there is a question what the difference between stable-supfile and standard-supfile should be. I looked in my local csupped sources, they are the same in 6-STABLE (OK, some history here), 7-STABLE, 8-STABLE and 9-STABLE. Are they expected to be used differently? And, second one - what about CURRENT? In stable-supfile I see tag=RELENG_9 which is not quite clear, but just for some pedantry... I use standard-supfile for CURRENT, so this is not an issue for me either. Regards, Milan From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 07:15:13 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 409451065688; Thu, 1 Dec 2011 07:15:13 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2451B8FC27; Thu, 1 Dec 2011 07:15:11 +0000 (UTC) Received: by yenq9 with SMTP id q9so2220183yen.13 for ; Wed, 30 Nov 2011 23:15:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mb3REwJ9Ar5gyZvQwElp6xkDQFheBt7jA1188hZxwvc=; b=LWP7hXDWnxIIDUukHZXynShyvMKkll7DaE3spxGat3u1XTqUnxu2mUOjnHpdqzoNoU Q4ug+x3WiWbgU+QamxxOdQ1x3rgKdEhkyG0jZDMKks+1FIWD9ug26V5oBF1pjo2aP3yw rox/AEME17oRgwh5t6OF2sSEVcOLKOsZJQtzc= MIME-Version: 1.0 Received: by 10.182.172.41 with SMTP id az9mr1202333obc.42.1322723711429; Wed, 30 Nov 2011 23:15:11 -0800 (PST) Received: by 10.182.62.227 with HTTP; Wed, 30 Nov 2011 23:15:11 -0800 (PST) In-Reply-To: References: <201111291607.26546.jhb@freebsd.org> <20111201002515.GA50028@freebsd.org> <20111201014349.GA61475@freebsd.org> Date: Wed, 30 Nov 2011 23:15:11 -0800 Message-ID: From: Garrett Cooper To: Alexander Best Content-Type: multipart/mixed; boundary=e89a8f83a729f4ab1e04b3029cdd Cc: Doug Barton , current@freebsd.org, Warner Losh Subject: Re: Remove debug echo 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, 01 Dec 2011 07:15:13 -0000 --e89a8f83a729f4ab1e04b3029cdd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Nov 30, 2011 at 5:59 PM, Garrett Cooper wrote: > On Wed, Nov 30, 2011 at 5:43 PM, Alexander Best wro= te: >> On Wed Nov 30 11, Garrett Cooper wrote: >>> On Wed, Nov 30, 2011 at 4:25 PM, Alexander Best w= rote: >>> > On Tue Nov 29 11, Warner Losh wrote: >>> >> kill it. >>> >> >>> >> Warner >>> >> On Nov 29, 2011, at 2:07 PM, John Baldwin wrote: >>> >> >>> >> > Any objections to this? =A0It removes a weird line during 'make -s= buildworld' >>> >> > output and I think it was debugging accidentally left in in 213077= by Warner: >>> >> > >>> >> > Index: newvers.sh >>> >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >> > --- newvers.sh =A0 =A0 =A0(revision 228074) >>> >> > +++ newvers.sh =A0 =A0 =A0(working copy) >>> >> > @@ -99,7 +99,6 @@ for dir in /bin /usr/bin /usr/local/bin; do >>> >> > done >>> >> > >>> >> > if [ -n "$svnversion" ] ; then >>> >> > - =A0 echo "$svnversion" >>> >> > =A0 =A0 svn=3D`cd ${SYSDIR} && $svnversion` >>> >> > =A0 =A0 case "$svn" in >>> >> > =A0 =A0 [0-9]*) svn=3D" r${svn}" ;; >>> > >>> > also... >>> > >>> > when running buildkernel via 'make -s', do we really need all those m= odule >>> > printfs? i see messages for "cleandir", "obj", "depend" and "all". i = think for >>> > 'make -s', that's pure overkill! >>> > >>> > for a GENERIC kernel, 'make' enters ~ 670 module dirs. take that time= s 4 and >>> > you'll get 2680 lines of output. not really *silent*, is it? ;) >>> >>> =A0 =A0 pmake sucks as far as diagnostic output is concerned when compa= red >>> with gmake. I'd rather not have to fish through with -j1 (if I'm lucky >>> and it's not a race) to determine what directory created the "Error >>> Code" output. With the printouts discussed here, at least you have a >>> chance at determining what the issue was. >>> =A0 =A0 Maybe it's just me, but I like noisy builds -- otherwise the >>> amount of time I have to spend root-causing the issue becomes >>> expensive. >> >> ehmmm...a noisy silent flag? i totally agree, if we're talking about 'ma= ke' in >> its default mode, but what's the point of a silent flag, if it produces = > 2500 >> lines of output? nobody uses the -s flag for diagnostics. its purpose is= to >> build a kernel without producing a lot of output and also not fiddling w= ith >> stdout/stderr to achieve that goal. > > What I really want is this: > > $ cat Makefile > all: foo bar baz yadda > > foo bar yadda: > > baz: > =A0 =A0 =A0 =A0false > $ gmake > false > gmake: *** [baz] Error 1 > =A0 =A0 =A0 =A0 =A0 =A0 ^^^^ > $ make all > false > *** Error code 1 > > Stop in /tmp. > > Otherwise diagnosing issues becomes a PITA with -j > 1 (with pmake I > have to start using some serious grep'ing, and if I'm lucky I can find > the source of error). If I get a few spare cycles I might just > implement it and post a patch somewhere (the entering and leaving > directory feature of gmake is really nice too, but it's less > important.. unless you have the same target in multiple directories).. I've attached a patch that makes make do what I would like it to do; there are some other items that require cleanup to achieve the `argv0' prefixing that's available in gmake, but this is good enough for a meaningful traceback when things fail. Pastebin available here, just in case the mailing list eats my patch: http://pastebin.com/dFqcDRfv $ cat ~/Makefile all: cd $$HOME/foo; ${MAKE} $@ $ cat ~/foo/Makefile all: foo bar barf yadda foo bar yadda: @true baz: @false barf: baz $ $PWD/make -j4 -f ~/Makefile all cd $HOME/foo; /usr/src/usr.bin/make/make all *** [baz] Error code 1 1 error *** [all] Error code 2 1 error $ If someone would please, PLEASE commit this.. I will give you beer, or wine, or a copy of Skyrim, or a few months subscription to WoW, or something else of value to you that we could negotiate :)... I'm quite frankly tired of having to playing guessing games fishing through logs trying to determine build errors on FreeBSD if and when they do occur with pmake, and I'm sure that a number of developers and build/release engineers out there are in the same boat as I am. Thanks, -Garrett --e89a8f83a729f4ab1e04b3029cdd Content-Type: application/octet-stream; name="more-meaningful-make-errors.patch" Content-Disposition: attachment; filename="more-meaningful-make-errors.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gvnf5kb40 SW5kZXg6IHVzci5iaW4vbWFrZS9qb2IuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB1c3IuYmluL21ha2Uvam9i LmMJKHJldmlzaW9uIDIyODEwNykKKysrIHVzci5iaW4vbWFrZS9qb2IuYwkod29ya2luZyBjb3B5 KQpAQCAtOTU0LDE3ICs5NTQsMTggQEAKIAkJCQkJCWxhc3ROb2RlID0gam9iLT5ub2RlOwogCQkJ CQl9CiAJCQkJCWZwcmludGYob3V0LAotCQkJCQkgICAgIioqKiBDb21wbGV0ZWQgc3VjY2Vzc2Z1 bGx5XG4iKTsKKwkJCQkJICAgICIqKiogWyVzXSBDb21wbGV0ZWQgc3VjY2Vzc2Z1bGx5XG4iLAor CQkJCQkgICAgam9iLT5ub2RlLT5uYW1lKTsKIAkJCQl9CiAJCQl9IGVsc2UgewogCQkJCWlmICh1 c2VQaXBlcyAmJiBqb2ItPm5vZGUgIT0gbGFzdE5vZGUpIHsKLQkJCQkJTUVTU0FHRShvdXQsIGpv Yi0+bm9kZSk7CiAJCQkJCWxhc3ROb2RlID0gam9iLT5ub2RlOwogCQkJCX0KLQkJCQlmcHJpbnRm KG91dCwgIioqKiBFcnJvciBjb2RlICVkJXNcbiIsCisJCQkJZnByaW50ZihvdXQsICIqKiogWyVz XSBFcnJvciBjb2RlICVkJXNcbiIsCisJCQkJCWpvYi0+bm9kZS0+bmFtZSwKIAkJCQkJV0VYSVRT VEFUVVMoKnN0YXR1cyksCiAJCQkJCShqb2ItPmZsYWdzICYgSk9CX0lHTkVSUikgPwotCQkJCQki KGlnbm9yZWQpIiA6ICIiKTsKKwkJCQkJIiAoaWdub3JlZCkiIDogIiIpOwogCiAJCQkJaWYgKGpv Yi0+ZmxhZ3MgJiBKT0JfSUdORVJSKSB7CiAJCQkJCSpzdGF0dXMgPSAwOwpAQCAtMTAwMiwxMCAr MTAwMywxMCBAQAogCQkJCSAqLwogCQkJCWlmIChqb2ItPmZsYWdzICYgKEpPQl9SRVNVTUUgfCBK T0JfUkVTVEFSVCkpIHsKIAkJCQkJaWYgKHVzZVBpcGVzICYmIGpvYi0+bm9kZSAhPSBsYXN0Tm9k ZSkgewotCQkJCQkJTUVTU0FHRShvdXQsIGpvYi0+bm9kZSk7CiAJCQkJCQlsYXN0Tm9kZSA9IGpv Yi0+bm9kZTsKIAkJCQkJfQotCQkJCQlmcHJpbnRmKG91dCwgIioqKiBDb250aW51ZWRcbiIpOwor CQkJCQlmcHJpbnRmKG91dCwgIioqKiBbJXNdIENvbnRpbnVlZFxuIiwKKwkJCQkJICAgIGpvYi0+ bm9kZS0+bmFtZSk7CiAJCQkJfQogCQkJCWlmICghKGpvYi0+ZmxhZ3MgJiBKT0JfQ09OVElOVUlO RykpIHsKIAkJCQkJREVCVUdGKEpPQiwgKCJXYXJuaW5nOiBwcm9jZXNzICVqZCB3YXMgbm90ICIK QEAgLTEwMjUsMTEgKzEwMjYsMTEgQEAKIAogCQkJfSBlbHNlIHsKIAkJCQlpZiAodXNlUGlwZXMg JiYgam9iLT5ub2RlICE9IGxhc3ROb2RlKSB7Ci0JCQkJCU1FU1NBR0Uob3V0LCBqb2ItPm5vZGUp OwogCQkJCQlsYXN0Tm9kZSA9IGpvYi0+bm9kZTsKIAkJCQl9CiAJCQkJZnByaW50ZihvdXQsCi0J CQkJICAgICIqKiogU2lnbmFsICVkXG4iLCBXVEVSTVNJRygqc3RhdHVzKSk7CisJCQkJICAgICIq KiogWyVzXSBTaWduYWwgJWRcbiIsIGpvYi0+bm9kZS0+bmFtZSwKKwkJCQkgICAgV1RFUk1TSUco KnN0YXR1cykpOwogCQkJCWZmbHVzaChvdXQpOwogCQkJfQogCQl9CkBAIC0xMDUzLDEwICsxMDU0 LDEwIEBACiAKIAkJREVCVUdGKEpPQiwgKCJQcm9jZXNzICVqZCBzdG9wcGVkLlxuIiwgKGludG1h eF90KSBqb2ItPnBpZCkpOwogCQlpZiAodXNlUGlwZXMgJiYgam9iLT5ub2RlICE9IGxhc3ROb2Rl KSB7Ci0JCQlNRVNTQUdFKG91dCwgam9iLT5ub2RlKTsKIAkJCWxhc3ROb2RlID0gam9iLT5ub2Rl OwogCQl9Ci0JCWZwcmludGYob3V0LCAiKioqIFN0b3BwZWQgLS0gc2lnbmFsICVkXG4iLCBXU1RP UFNJRygqc3RhdHVzKSk7CisJCWZwcmludGYob3V0LCAiKioqIFslc10gU3RvcHBlZCAtLSBzaWdu YWwgJWRcbiIsCisJCSAgICBqb2ItPm5vZGUtPm5hbWUsIFdTVE9QU0lHKCpzdGF0dXMpKTsKIAkJ am9iLT5mbGFncyB8PSBKT0JfUkVTVU1FOwogCQlUQUlMUV9JTlNFUlRfVEFJTCgmc3RvcHBlZEpv YnMsIGpvYiwgbGluayk7CiAJCWZmbHVzaChvdXQpOwpAQCAtMzA0MiwxMyArMzA0MywxNSBAQAog CQkJaWYgKHN0YXR1cyA9PSAwKSB7CiAJCQkJcmV0dXJuICgwKTsKICAgCQkJfSBlbHNlIHsKLQkJ CQlwcmludGYoIioqKiBFcnJvciBjb2RlICVkIiwgc3RhdHVzKTsKKwkJCQlwcmludGYoIioqKiBb JXNdIEVycm9yIGNvZGUgJWQiLAorCQkJCSAgICBnbi0+bmFtZSwgc3RhdHVzKTsKICAgCQkJfQog CQl9IGVsc2UgaWYgKFdJRlNUT1BQRUQocmVhc29uKSkgewogCQkJc3RhdHVzID0gV1NUT1BTSUco cmVhc29uKTsKIAkJfSBlbHNlIHsKIAkJCXN0YXR1cyA9IFdURVJNU0lHKHJlYXNvbik7Ci0JCQlw cmludGYoIioqKiBTaWduYWwgJWQiLCBzdGF0dXMpOworCQkJcHJpbnRmKCIqKiogWyVzXSBTaWdu YWwgJWQiLAorCQkJICAgIGduLT5uYW1lLCBzdGF0dXMpOwogICAJCX0KICAgCiAJCWlmIChwcy5l cnJDaGVjaykgewo= --e89a8f83a729f4ab1e04b3029cdd-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 08:22:05 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4ACD6106564A; Thu, 1 Dec 2011 08:22:05 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by mx1.freebsd.org (Postfix) with ESMTP id B735C8FC12; Thu, 1 Dec 2011 08:22:04 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id pB18M19p030137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 1 Dec 2011 09:22:01 +0100 Received: from portgus.lan ([147.83.40.234]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id pB18Lwch012042 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 1 Dec 2011 09:22:01 +0100 Message-ID: <4ED73921.8060906@entel.upc.edu> Date: Thu, 01 Dec 2011 09:21:53 +0100 From: =?ISO-8859-1?Q?Gustau_P=E9rez?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111111 Thunderbird/8.0 MIME-Version: 1.0 To: Andriy Gapon References: <4ECF7440.4070300@entel.upc.edu> <4ED6AEFE.4010106@FreeBSD.org> <201111301807.21351.jkim@FreeBSD.org> <201111301827.46079.jkim@FreeBSD.org> <4ED6BDC1.8020600@FreeBSD.org> In-Reply-To: <4ED6BDC1.8020600@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.70 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Thu, 01 Dec 2011 09:22:02 +0100 (CET) Cc: Alan Cox , freebsd-emulation@freebsd.org, FreeBSD current , Gleb Kurtsou , Jung-uk Kim Subject: Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464} 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, 01 Dec 2011 08:22:05 -0000 On 01/12/2011 00:35, Andriy Gapon wrote: > on 01/12/2011 01:27 Jung-uk Kim said the following: >> On Wednesday 30 November 2011 06:07 pm, Jung-uk Kim wrote: >>> On Wednesday 30 November 2011 05:32 pm, Andriy Gapon wrote: >>>> on 26/11/2011 18:33 Gleb Kurtsou said the following: >>>>> Using new vm_page_alloc_contig() may be a better option here. >>>>> Can't help with patch, stuck with pre Nov 15 CURRENT myself. >>>> on 27/11/2011 19:09 Alan Cox said the following: >>>>> vm_page_alloc_contig() should be used instead. >>>> My take on the patch: >>>> http://people.freebsd.org/~avg/vbox-10.patch >>>> This is for head only, no check for FreeBSD version. >>> Actually, I did the same thing last night: >>> >>> http://people.freebsd.org/~jkim/patch-src-VBox-Runtime-r0drv-freebs >>> d-memobj-r0drv-freebsd.c >>> >>> This is a drop-in replacement for the patch. The only practical >>> difference I see from yours is I used VM_ALLOC_INTERRUPT instead of >>> VM_ALLOC_NORMAL. I believe this function may be used in interrupt >>> context. FYI, I tried FreeBSD 9 and Fedora 10 without problem. >> BTW, I needed another patch to build virtual-ose-kmod on head: >> >> http://people.freebsd.org/~jkim/patch-src-VBox-HostDrivers-Support-freebsd-SUPDrv-freebsd.c >> >> FYI... > Yep, me too, obviously :-) > Thank you for the complete vm_page_alloc_contig patch! > Thanks for the patch. I'll give it a try. OTOH yesterday I was trying to use vm_page_alloc_contig and trying to understand the allocation classes. I was able to panic the system or in the best case VBoxHeadless was getting a sig11. I was planning to ask the mailing list about them, because even I read vm-design article in the doc section there are things I don't yet understand: First question is, if you set NULL for the vm_object_t (and then VM_ALLOC_NOOBJ must be given or the kernel will panic with INVARIANTS set) how this memory is assigned to the VirtualBox process logical space? Second set of related questions are: why should the pages be wired? and why should the VM_ALLOC_INTERRUPT alloc class be given? Third question is: I see in the patch that rtR0MemObjFreeBSDPhysPageInit is not called if the veersion is less that 1000000, is this because vm_phys_alloc_contig doesn't set the flags on the pages and vm_page_alloc_contig does? Thanks, Gus From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 08:52:20 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32889106566B; Thu, 1 Dec 2011 08:52:20 +0000 (UTC) (envelope-from decke@FreeBSD.org) Received: from groupware.itac.at (groupware.itac.at [91.205.172.99]) by mx1.freebsd.org (Postfix) with ESMTP id B344F8FC0A; Thu, 1 Dec 2011 08:52:18 +0000 (UTC) Received: from home.bluelife.at (93.104.210.95) by groupware.itac.at (Axigen) with (AES256-SHA encrypted) ESMTPSA id 19862E; Thu, 1 Dec 2011 09:37:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 01 Dec 2011 09:37:12 +0100 From: Bernhard Froehlich To: Jung-uk Kim In-Reply-To: <201111301807.21351.jkim@FreeBSD.org> References: <4ECF7440.4070300@entel.upc.edu> <20111126163343.GA9150@reks> <4ED6AEFE.4010106@FreeBSD.org> <201111301807.21351.jkim@FreeBSD.org> Message-ID: <60ea779052f025798cf65e18c24b7b31@bluelife.at> X-Sender: decke@FreeBSD.org User-Agent: Roundcube Webmail/0.6 X-AxigenSpam-Level: 1 X-CTCH-RefID: str=0001.0A0B0202.4ED73CB7.0179,ss=1,fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown Cc: Alan Cox , freebsd-emulation@freebsd.org, FreeBSD current , Gleb Kurtsou , Andriy Gapon Subject: Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464} 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, 01 Dec 2011 08:52:20 -0000 On 01.12.2011 00:07, Jung-uk Kim wrote: > On Wednesday 30 November 2011 05:32 pm, Andriy Gapon wrote: >> on 26/11/2011 18:33 Gleb Kurtsou said the following: >> > Using new vm_page_alloc_contig() may be a better option here. >> > Can't help with patch, stuck with pre Nov 15 CURRENT myself. >> >> on 27/11/2011 19:09 Alan Cox said the following: >> > vm_page_alloc_contig() should be used instead. >> >> My take on the patch: >> http://people.freebsd.org/~avg/vbox-10.patch >> This is for head only, no check for FreeBSD version. > > Actually, I did the same thing last night: > > > http://people.freebsd.org/~jkim/patch-src-VBox-Runtime-r0drv-freebsd-memobj-r0drv-freebsd.c > > This is a drop-in replacement for the patch. The only practical > difference I see from yours is I used VM_ALLOC_INTERRUPT instead of > VM_ALLOC_NORMAL. I believe this function may be used in interrupt > context. FYI, I tried FreeBSD 9 and Fedora 10 without problem. Thanks a lot for both patches! Could you please as usual reply and tell me if it is okay to send this patch upstream under MIT license? Once there is some positive feedback I will commit both patches to the ports tree. -- Bernhard Froehlich http://www.bluelife.at/ From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 09:12:20 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4900106566C for ; Thu, 1 Dec 2011 09:12:20 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 492A58FC17 for ; Thu, 1 Dec 2011 09:12:19 +0000 (UTC) Received: by faak28 with SMTP id k28so1500507faa.13 for ; Thu, 01 Dec 2011 01:12:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fyBoV8+SnCZhsh5UJV10S0UVecZKIMmrg1dt/6xRpDU=; b=PWrvxvQ0S09M05grPVr5qYsWu24lYQ97i1SMzBMo+uRDaYUgafpq7vSYxQY1GtkP0D W/lJE1rhiUecghlpMUbkwsSUzzhpPh3C0648kPm4BeTnMBBcmMCHN6K4y0N2/Dth32qj rFISRIrU1OhdBobBxk7E5HzG+w7qeXuYblrnk= MIME-Version: 1.0 Received: by 10.180.95.230 with SMTP id dn6mr4198412wib.41.1322730738374; Thu, 01 Dec 2011 01:12:18 -0800 (PST) Received: by 10.180.95.98 with HTTP; Thu, 1 Dec 2011 01:12:18 -0800 (PST) In-Reply-To: <20111201072040.7c76ba2d@atom.dino.sk> References: <20111126084402.1afbfc16@atom.dino.sk> <20111201072040.7c76ba2d@atom.dino.sk> Date: Thu, 1 Dec 2011 12:12:18 +0300 Message-ID: From: Sergey Kandaurov To: Milan Obuch Content-Type: text/plain; charset=ISO-8859-1 Cc: Maxim Khitrov , freebsd-current@freebsd.org Subject: Re: Incorrect tag= in /usr/src/share/examples/cvsup/sta(ble|ndard) in 9.0-PRERELEASE? 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, 01 Dec 2011 09:12:20 -0000 On 1 December 2011 10:20, Milan Obuch wrote: > On Tue, 29 Nov 2011 19:22:39 +0300 > Sergey Kandaurov wrote: > >> On 29 November 2011 20:16, Maxim Khitrov wrote: >> > On Tue, Nov 29, 2011 at 10:30 AM, Sergey Kandaurov >> > wrote: >> >> On 26 November 2011 11:44, Milan Obuch >> >> wrote: >> >>> Hi, >> >>> >> >>> I am playing a bit with 9.0-PRERELEASE compiling it from source >> >>> updated via csup. In both example files there is line specifying >> >>> what to csup >> >>> >> >>> *default release=cvs tag=RELENG_8 >> >>> >> >>> which is incorrect, I think. It is convenient for me to issue just >> >>> >> >>> csup -h cvsup.freebsd.sk /usr/share/examples/cvsup/stable-supfile >> >>> >> >>> to update full sources without need to create any cvsup config >> >>> file, however in system installed from 9.0 snapshot (maybe two >> >>> weeks old) this file points to version 8 files, so I need to >> >>> correct it for 9.0-PRERELEASE to not accidentally download older >> >>> version sources. >> >>> >> >>> The same is also true after upgrade from source - make >> >>> installworld install example files pointing to older version... >> >>> >> >>> Is it something I do not know about or is it an oversight? I >> >>> think this line should already be changed to new tag... >> >>> >> >>> *default release=cvs tag=RELENG_9 >> >> >> >> Hi. >> >> >> >> Fixed. Thanks for your report. >> >> Now cvs tag points to RELENG_9 in 9.x sources. >> > >> > Should standard-supfile also be updated to point to RELENG_9_0? I'm >> > using csup with "tag=RELENG_9_0" and standard-supfile still points >> > to HEAD. >> >> Yep, sure. >> I just sent a request to the Release Engineering Team. >> > > It works for me now as expected, thanks. > > Anyway, there is a question what the difference between stable-supfile > and standard-supfile should be. I looked in my local csupped sources, > they are the same in 6-STABLE (OK, some history here), 7-STABLE, > 8-STABLE and 9-STABLE. Are they expected to be used differently? In STABLE branches standard-supfile and stable-supfile are used to have the same cvs tag. FYI, compare how it is done in RELEASE branches. > And, second one - what about CURRENT? In stable-supfile I see > tag=RELENG_9 which is not quite clear, but just for some pedantry... I > use standard-supfile for CURRENT, so this is not an issue for me either. To my knowledge, in CURRENT a standard-supfile's cvs tag should be read as "the latest (i.e. the most recently created) stable branch". -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 09:17:31 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B04DB106564A for ; Thu, 1 Dec 2011 09:17:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 493D08FC13 for ; Thu, 1 Dec 2011 09:17:30 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pB19HLpN063621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Dec 2011 11:17:22 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pB19HLls082269; Thu, 1 Dec 2011 11:17:21 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pB19HL2q082268; Thu, 1 Dec 2011 11:17:21 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 1 Dec 2011 11:17:21 +0200 From: Kostik Belousov To: Sergey Kandaurov Message-ID: <20111201091721.GH50300@deviant.kiev.zoral.com.ua> References: <20111126084402.1afbfc16@atom.dino.sk> <20111201072040.7c76ba2d@atom.dino.sk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cxhlVrkHblhtPc7U" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Maxim Khitrov , freebsd-current@freebsd.org, Milan Obuch Subject: Re: Incorrect tag= in /usr/src/share/examples/cvsup/sta(ble|ndard) in 9.0-PRERELEASE? 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, 01 Dec 2011 09:17:31 -0000 --cxhlVrkHblhtPc7U Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 01, 2011 at 12:12:18PM +0300, Sergey Kandaurov wrote: > On 1 December 2011 10:20, Milan Obuch wrote: > > On Tue, 29 Nov 2011 19:22:39 +0300 > > Sergey Kandaurov wrote: > > > >> On 29 November 2011 20:16, Maxim Khitrov wrote: > >> > On Tue, Nov 29, 2011 at 10:30 AM, Sergey Kandaurov > >> > wrote: > >> >> On 26 November 2011 11:44, Milan Obuch > >> >> wrote: > >> >>> Hi, > >> >>> > >> >>> I am playing a bit with 9.0-PRERELEASE compiling it from source > >> >>> updated via csup. In both example files there is line specifying > >> >>> what to csup > >> >>> > >> >>> *default release=3Dcvs tag=3DRELENG_8 > >> >>> > >> >>> which is incorrect, I think. It is convenient for me to issue just > >> >>> > >> >>> csup -h cvsup.freebsd.sk /usr/share/examples/cvsup/stable-supfile > >> >>> > >> >>> to update full sources without need to create any cvsup config > >> >>> file, however in system installed from 9.0 snapshot (maybe two > >> >>> weeks old) this file points to version 8 files, so I need to > >> >>> correct it for 9.0-PRERELEASE to not accidentally download older > >> >>> version sources. > >> >>> > >> >>> The same is also true after upgrade from source - make > >> >>> installworld install example files pointing to older version... > >> >>> > >> >>> Is it something I do not know about or is it an oversight? I > >> >>> think this line should already be changed to new tag... > >> >>> > >> >>> *default release=3Dcvs tag=3DRELENG_9 > >> >> > >> >> Hi. > >> >> > >> >> Fixed. Thanks for your report. > >> >> Now cvs tag points to RELENG_9 in 9.x sources. > >> > > >> > Should standard-supfile also be updated to point to RELENG_9_0? I'm > >> > using csup with "tag=3DRELENG_9_0" and standard-supfile still points > >> > to HEAD. > >> > >> Yep, sure. > >> I just sent a request to the Release Engineering Team. > >> > > > > It works for me now as expected, thanks. > > > > Anyway, there is a question what the difference between stable-supfile > > and standard-supfile should be. I looked in my local csupped sources, > > they are the same in 6-STABLE (OK, some history here), 7-STABLE, > > 8-STABLE and 9-STABLE. Are they expected to be used differently? >=20 > In STABLE branches standard-supfile and stable-supfile are used to have > the same cvs tag. FYI, compare how it is done in RELEASE branches. >=20 > > And, second one - what about CURRENT? In stable-supfile I see > > tag=3DRELENG_9 which is not quite clear, but just for some pedantry... I > > use standard-supfile for CURRENT, so this is not an issue for me either. >=20 > To my knowledge, in CURRENT a standard-supfile's cvs tag should be > read as "the latest (i.e. the most recently created) stable branch". Could the supfiles be generated from some value in newvers.sh ? --cxhlVrkHblhtPc7U Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7XRiEACgkQC3+MBN1Mb4h6rgCfV5BMEGAATpOltIPjLysWELJx iNQAoIsbTCuEH/I5xJfAHE82pznIkmfQ =nr9V -----END PGP SIGNATURE----- --cxhlVrkHblhtPc7U-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 10:10:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95117106566B for ; Thu, 1 Dec 2011 10:10:14 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1923D8FC14 for ; Thu, 1 Dec 2011 10:10:13 +0000 (UTC) Received: by eekc13 with SMTP id c13so1508781eek.13 for ; Thu, 01 Dec 2011 02:10:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=923eEsipSqOBbec6OWYwdNX0+ekFNAv1SOkvkNtjG/Y=; b=tD5+mpffZRrA/1XZboDB5aQR5EpjIrYJ96MXuJDmRKYOJlnOo8qIHBWj3Kzg59QlKW zBRUrj8CoknMehEFDscwM5LNSGYx5zADcjgBpipHqZyCGLAbUI0WiFlcj+7ItcIFhmd0 0UqaT1ZkBTW6iIibTDWy4KFSRBZIMWl++1i08= MIME-Version: 1.0 Received: by 10.180.95.230 with SMTP id dn6mr4343802wib.41.1322734212838; Thu, 01 Dec 2011 02:10:12 -0800 (PST) Received: by 10.180.95.98 with HTTP; Thu, 1 Dec 2011 02:10:12 -0800 (PST) In-Reply-To: <20111201091721.GH50300@deviant.kiev.zoral.com.ua> References: <20111126084402.1afbfc16@atom.dino.sk> <20111201072040.7c76ba2d@atom.dino.sk> <20111201091721.GH50300@deviant.kiev.zoral.com.ua> Date: Thu, 1 Dec 2011 13:10:12 +0300 Message-ID: From: Sergey Kandaurov To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: Maxim Khitrov , freebsd-current@freebsd.org, Milan Obuch Subject: Re: Incorrect tag= in /usr/src/share/examples/cvsup/sta(ble|ndard) in 9.0-PRERELEASE? 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, 01 Dec 2011 10:10:14 -0000 On 1 December 2011 13:17, Kostik Belousov wrote: > On Thu, Dec 01, 2011 at 12:12:18PM +0300, Sergey Kandaurov wrote: >> On 1 December 2011 10:20, Milan Obuch wrote: >> > On Tue, 29 Nov 2011 19:22:39 +0300 >> > Sergey Kandaurov wrote: >> > >> >> On 29 November 2011 20:16, Maxim Khitrov wrote: >> >> > On Tue, Nov 29, 2011 at 10:30 AM, Sergey Kandaurov >> >> > wrote: >> >> >> On 26 November 2011 11:44, Milan Obuch >> >> >> wrote: >> >> >>> Hi, >> >> >>> >> >> >>> I am playing a bit with 9.0-PRERELEASE compiling it from source >> >> >>> updated via csup. In both example files there is line specifying >> >> >>> what to csup >> >> >>> >> >> >>> *default release=cvs tag=RELENG_8 >> >> >>> >> >> >>> which is incorrect, I think. It is convenient for me to issue just >> >> >>> >> >> >>> csup -h cvsup.freebsd.sk /usr/share/examples/cvsup/stable-supfile >> >> >>> >> >> >>> to update full sources without need to create any cvsup config >> >> >>> file, however in system installed from 9.0 snapshot (maybe two >> >> >>> weeks old) this file points to version 8 files, so I need to >> >> >>> correct it for 9.0-PRERELEASE to not accidentally download older >> >> >>> version sources. >> >> >>> >> >> >>> The same is also true after upgrade from source - make >> >> >>> installworld install example files pointing to older version... >> >> >>> >> >> >>> Is it something I do not know about or is it an oversight? I >> >> >>> think this line should already be changed to new tag... >> >> >>> >> >> >>> *default release=cvs tag=RELENG_9 >> >> >> >> >> >> Hi. >> >> >> >> >> >> Fixed. Thanks for your report. >> >> >> Now cvs tag points to RELENG_9 in 9.x sources. >> >> > >> >> > Should standard-supfile also be updated to point to RELENG_9_0? I'm >> >> > using csup with "tag=RELENG_9_0" and standard-supfile still points >> >> > to HEAD. >> >> >> >> Yep, sure. >> >> I just sent a request to the Release Engineering Team. >> >> >> > >> > It works for me now as expected, thanks. >> > >> > Anyway, there is a question what the difference between stable-supfile >> > and standard-supfile should be. I looked in my local csupped sources, >> > they are the same in 6-STABLE (OK, some history here), 7-STABLE, >> > 8-STABLE and 9-STABLE. Are they expected to be used differently? >> >> In STABLE branches standard-supfile and stable-supfile are used to have >> the same cvs tag. FYI, compare how it is done in RELEASE branches. >> >> > And, second one - what about CURRENT? In stable-supfile I see >> > tag=RELENG_9 which is not quite clear, but just for some pedantry... I >> > use standard-supfile for CURRENT, so this is not an issue for me either. >> >> To my knowledge, in CURRENT a standard-supfile's cvs tag should be >> read as "the latest (i.e. the most recently created) stable branch". > Could the supfiles be generated from some value in newvers.sh ? I have no idea how it could be done gracefully, sorry. But I like how it is done in www/. Here are several defined entities used elsewhere in doc&www. and so on. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 10:44:31 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AF94106566C for ; Thu, 1 Dec 2011 10:44:31 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id D07EE8FC08 for ; Thu, 1 Dec 2011 10:44:30 +0000 (UTC) Received: by mail-yx0-f182.google.com with SMTP id q9so2424129yen.13 for ; Thu, 01 Dec 2011 02:44:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.141.68 with SMTP id rm4mr1320806obb.23.1322736270600; Thu, 01 Dec 2011 02:44:30 -0800 (PST) Received: by 10.182.76.225 with HTTP; Thu, 1 Dec 2011 02:44:30 -0800 (PST) X-Originating-IP: [93.92.220.178] In-Reply-To: <4ED6C2C3.4050007@gmail.com> References: <20111129213413.GB14357@stack.nl> <4ED551B5.8090809@gmail.com> <4ED583D0.6030403@FreeBSD.org> <4ED653B6.1010607@gmail.com> <4ED6C2C3.4050007@gmail.com> Date: Thu, 1 Dec 2011 17:44:30 +0700 Message-ID: From: Max Khon To: "Sevan / Venture37" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_PROFILE=yes by default 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, 01 Dec 2011 10:44:31 -0000 Sevan, On Thu, Dec 1, 2011 at 6:56 AM, Sevan / Venture37 wrote: On 30/11/2011 16:03, Sevan / Venture37 wrote: > >> system breaks if you try to add dtrace support to a system built with >> profile support. >> > > sorry, I meant *without* profile support. Are you sure you mean profile support and not CTF data? Max From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 10:47:48 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D98FA106566C for ; Thu, 1 Dec 2011 10:47:48 +0000 (UTC) (envelope-from dan@sunsaturn.com) Received: from sunsaturn.com (mail1.sunsaturn.com [IPv6:2001:49f0:4004::2]) by mx1.freebsd.org (Postfix) with ESMTP id A64C98FC0A for ; Thu, 1 Dec 2011 10:47:48 +0000 (UTC) Received: by sunsaturn.com (Postfix, from userid 1001) id 73EC2119C6D; Thu, 1 Dec 2011 04:47:47 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sunsaturn.com; s=gamma; t=1322736467; bh=f0a7G96gcoCF8R817aG4+x6vlSUkTakcFRTqQiQM7oc=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; b=KoXZ8NANg4CyRJ9BpiXwaqXZUOja+KjZnWt0jJyX4dsz2rr3gFTjZxsd7TW1K6Bd4 cBFqi25ppyl7wWSHHyg4C4OUzuWfLmRCgnfOKl4nCGGNRAB3G8etkldaMu9VHXd3Se MuIZobg06Uitey2OB11mMx6GFUFWCiEirqqFitns= Received: from localhost (localhost [127.0.0.1]) by sunsaturn.com (Postfix) with ESMTP id 6EB61119C62 for ; Thu, 1 Dec 2011 04:47:47 -0600 (CST) Date: Thu, 1 Dec 2011 04:47:47 -0600 (CST) From: Dan The Man To: freebsd-current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: pf.conf + IPV6 to IPV4 port rdr 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, 01 Dec 2011 10:47:48 -0000 pfctl -v -s nat rdr inet6 proto tcp from any to 2001:49f0:4004::/48 port = 9191 -> ::ffff:67.159.46.238 [ Evaluations: 512 Packets: 3 Bytes: 228 States: 1 ] [ Inserted: uid 0 pid 80940 State Creations: 2 ] I can see here that after i tried on another host to telnet to 2001:49f0:4004::2 9191 , that a state was in fact created for the rdr, but it doesn't appear to be actually forwarding: My rule: rdr inet6 proto tcp to 2001:49f0:4004::/48 port 9191 -> ::ffff:67.159.46.238 Am I missing something here? I have checked on ipv6 forwarding and redirects set to 1, net.inet6.ip6.v6only=0 to allow the mapping... I can even telnet to ::ffff:67.159.46.238 9191 from any host yet it will not forward the 2001:49f0:4004:: addresses, and yes inet6 is allowing the port to pass, so this makes no sense to me.... Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: Dan@SunSaturn.com From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 10:49:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B99B3106564A for ; Thu, 1 Dec 2011 10:49:37 +0000 (UTC) (envelope-from mueller6727@bellsouth.net) Received: from fmailhost06.isp.att.net (fmailhost06.isp.att.net [207.115.11.56]) by mx1.freebsd.org (Postfix) with ESMTP id A7B338FC13 for ; Thu, 1 Dec 2011 10:49:37 +0000 (UTC) Date: Thu, 1 Dec 2011 10:44:13 +0000 (GMT) X-Comment: Sending client does not conform to RFC822 minimum requirements X-Comment: Date has been added by Maillennium Received: from localhost (adsl-68-210-130-165.sdf.bellsouth.net[68.210.130.165]) by isp.att.net (frfwmhc06) with SMTP id <20111201104413H0600a7rg7e>; Thu, 1 Dec 2011 10:44:13 +0000 X-Originating-IP: [68.210.130.165] From: "Thomas Mueller" To: freebsd-current@FreeBSD.org References: <20111130102439.E770E1065672@hub.freebsd.org> <201111301739.58889.hselasky@c2i.net> Message-Id: <20111201104937.B99B3106564A@hub.freebsd.org> Cc: Hans Petter Selasky Subject: Re: man ugen error 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, 01 Dec 2011 10:49:37 -0000 > On Wednesday 30 November 2011 11:24:39 Thomas Mueller wrote: > > According to ugen man page, ugen can be compiled into the kernel with > > device ugen > > in config file. > > I tried that in the kernel config when upgrading from FreeBSD 9.0-RC1 to > > RC2, but the kernel build stopped quickly with the message that ugen was > > not valid. After removing that line from kernel config, "make kernel" was > > successful. > > I didn't find "device ugen" anywhere in the conf/NOTES or conf/GENERIC > > files. > > I hope this man page error can be fixed in time for FreeBSD 9.0-RELEASE. > FYI: "device ugen" is now part of "device usb" > Could you send me a manpage diff? --HPS What version of FreeBSD do you run? Do you not have a ugen manpage? Can you run "man ugen"? I have the manpages for ugen, and "man usb", also "man 4 usb", but no diff as such. I guess ugen manpage failed to reflect becoming part of usb. Tom From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 11:28:38 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 0876F1065673; Thu, 1 Dec 2011 11:28:38 +0000 (UTC) Date: Thu, 1 Dec 2011 11:28:38 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20111201112838.GA62127@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: stupid cp(1) behaviour 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, 01 Dec 2011 11:28:38 -0000 is there a chance to change cp's behaviour in connection with the -R switch, so that it stops after the first error? i just ran into the following situation: 1) cp -ai bla /mnt/umass 2) i got a lot of warnings that /mnt/umass was full 3) cp -an bla /mnt/umass 4) ...that didn't work, since cp created 0 byte files for all files it couldn't copy in 1. 5) what i had to do is 'find /mnt/umass/bla -type f - size 0 -delete' and then try 3 again of course, if cp would have bailed out after the first error, there still would be one file with < actual file size. maybe the available filesize could be checked before crating the file, or another possibility: implement a new -N switch or so which isn't based on a file's existance, but a file's checksum. cheers. alex From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 13:24:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7BAD1065677 for ; Thu, 1 Dec 2011 13:24:47 +0000 (UTC) (envelope-from venture37@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 644688FC19 for ; Thu, 1 Dec 2011 13:24:47 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so2150957vbb.13 for ; Thu, 01 Dec 2011 05:24:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k5UjwJgtxgvYkcv1D7pNTRkYSXpp13oERHfx7VTVeGk=; b=Ibeyk3GxTiCBHSwZX8TGKu6vAs9saKl5SaEDVRUv6si3VF7AZuPK7FGy3+9jjK0Pix i7fz7IF7M40yz8zgQi37UUkOlplU9kSHEWeRnallMMpJRd74Uad4ON1ch26xWdn0eA/u WGMtXUYxFWiRXNNHsVizCkt8SmK5j8YznPFFI= MIME-Version: 1.0 Received: by 10.52.68.232 with SMTP id z8mr5984051vdt.64.1322745886675; Thu, 01 Dec 2011 05:24:46 -0800 (PST) Received: by 10.220.184.67 with HTTP; Thu, 1 Dec 2011 05:24:46 -0800 (PST) In-Reply-To: References: <20111129213413.GB14357@stack.nl> <4ED551B5.8090809@gmail.com> <4ED583D0.6030403@FreeBSD.org> <4ED653B6.1010607@gmail.com> <4ED6C2C3.4050007@gmail.com> Date: Thu, 1 Dec 2011 13:24:46 +0000 Message-ID: From: "Sevan / Venture37" To: Max Khon Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_PROFILE=yes by default 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, 01 Dec 2011 13:24:47 -0000 On 1 December 2011 10:44, Max Khon wrote: > Are you sure you mean profile support and not CTF data? Hi Max, I mean profile support. Havent tested on 9.0, but definitely the case with prior versions. Will try & repeat the process & report back if this is not a common occurrence which has been reported. Sevan From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 14:53:01 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22964106564A; Thu, 1 Dec 2011 14:53:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id EE9C68FC25; Thu, 1 Dec 2011 14:53:00 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id A692C46B0A; Thu, 1 Dec 2011 09:53:00 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3D61CB943; Thu, 1 Dec 2011 09:53:00 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 1 Dec 2011 09:52:59 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <20111130124320.GA1449@azathoth.lan> <201111301741.25734.hselasky@c2i.net> In-Reply-To: <201111301741.25734.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201112010952.59680.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 01 Dec 2011 09:53:00 -0500 (EST) Cc: Baptiste Daroussin , Hans Petter Selasky Subject: Re: [patch] turning devctl into a "multiple openable" device 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, 01 Dec 2011 14:53:01 -0000 On Wednesday, November 30, 2011 11:41:25 am Hans Petter Selasky wrote: > On Wednesday 30 November 2011 13:43:20 Baptiste Daroussin wrote: > > Hi all, > > > > With the help of cognet, I wrote a patch to turn devctl into a multiple > > openable device, that mean that it will allow to open /dev/devctl in > > multiple programs, for example hald and everythings that want to receive > > notification from the device won't need to depend on haveing devd running. > > > > here is the patch: > > http://people.freebsd.org/~bapt/devctl_multi_open.diff > > > > regards, > > bapt > > Comment: > > Is the track-close flag set for the devfs sw? Not, it uses the far-superior devfs_set_cdevpriv(). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 15:04:10 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AA42106564A; Thu, 1 Dec 2011 15:04:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3B3058FC12; Thu, 1 Dec 2011 15:04:10 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id BF95046B09; Thu, 1 Dec 2011 10:04:09 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4304CB914; Thu, 1 Dec 2011 10:04:09 -0500 (EST) From: John Baldwin To: Garrett Cooper Date: Thu, 1 Dec 2011 10:04:08 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201111291607.26546.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201112011004.08762.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 01 Dec 2011 10:04:09 -0500 (EST) Cc: Alexander Best , Doug Barton , current@freebsd.org, Warner Losh Subject: Re: Remove debug echo 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, 01 Dec 2011 15:04:10 -0000 On Thursday, December 01, 2011 2:15:11 am Garrett Cooper wrote: > On Wed, Nov 30, 2011 at 5:59 PM, Garrett Cooper wrote: > > On Wed, Nov 30, 2011 at 5:43 PM, Alexander Best wrote: > >> On Wed Nov 30 11, Garrett Cooper wrote: > >>> On Wed, Nov 30, 2011 at 4:25 PM, Alexander Best wrote: > >>> > On Tue Nov 29 11, Warner Losh wrote: > >>> >> kill it. > >>> >> > >>> >> Warner > >>> >> On Nov 29, 2011, at 2:07 PM, John Baldwin wrote: > >>> >> > >>> >> > Any objections to this? It removes a weird line during 'make -s buildworld' > >>> >> > output and I think it was debugging accidentally left in in 213077 by Warner: > >>> >> > > >>> >> > Index: newvers.sh > >>> >> > =================================================================== > >>> >> > --- newvers.sh (revision 228074) > >>> >> > +++ newvers.sh (working copy) > >>> >> > @@ -99,7 +99,6 @@ for dir in /bin /usr/bin /usr/local/bin; do > >>> >> > done > >>> >> > > >>> >> > if [ -n "$svnversion" ] ; then > >>> >> > - echo "$svnversion" > >>> >> > svn=`cd ${SYSDIR} && $svnversion` > >>> >> > case "$svn" in > >>> >> > [0-9]*) svn=" r${svn}" ;; > >>> > > >>> > also... > >>> > > >>> > when running buildkernel via 'make -s', do we really need all those module > >>> > printfs? i see messages for "cleandir", "obj", "depend" and "all". i think for > >>> > 'make -s', that's pure overkill! > >>> > > >>> > for a GENERIC kernel, 'make' enters ~ 670 module dirs. take that times 4 and > >>> > you'll get 2680 lines of output. not really *silent*, is it? ;) > >>> > >>> pmake sucks as far as diagnostic output is concerned when compared > >>> with gmake. I'd rather not have to fish through with -j1 (if I'm lucky > >>> and it's not a race) to determine what directory created the "Error > >>> Code" output. With the printouts discussed here, at least you have a > >>> chance at determining what the issue was. > >>> Maybe it's just me, but I like noisy builds -- otherwise the > >>> amount of time I have to spend root-causing the issue becomes > >>> expensive. > >> > >> ehmmm...a noisy silent flag? i totally agree, if we're talking about 'make' in > >> its default mode, but what's the point of a silent flag, if it produces > 2500 > >> lines of output? nobody uses the -s flag for diagnostics. its purpose is to > >> build a kernel without producing a lot of output and also not fiddling with > >> stdout/stderr to achieve that goal. > > > > What I really want is this: > > > > $ cat Makefile > > all: foo bar baz yadda > > > > foo bar yadda: > > > > baz: > > false > > $ gmake > > false > > gmake: *** [baz] Error 1 > > ^^^^ > > $ make all > > false > > *** Error code 1 > > > > Stop in /tmp. > > > > Otherwise diagnosing issues becomes a PITA with -j > 1 (with pmake I > > have to start using some serious grep'ing, and if I'm lucky I can find > > the source of error). If I get a few spare cycles I might just > > implement it and post a patch somewhere (the entering and leaving > > directory feature of gmake is really nice too, but it's less > > important.. unless you have the same target in multiple directories).. > > I've attached a patch that makes make do what I would like it to do; > there are some other items that require cleanup to achieve the `argv0' > prefixing that's available in gmake, but this is good enough for a > meaningful traceback when things fail. Pastebin available here, just > in case the mailing list eats my patch: http://pastebin.com/dFqcDRfv I think this is useful, perhaps send it to harti@ or jilles@ for review? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 16:16:21 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DED1C1065676 for ; Thu, 1 Dec 2011 16:16:21 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6E7968FC17 for ; Thu, 1 Dec 2011 16:16:21 +0000 (UTC) Received: by eaai12 with SMTP id i12so3303925eaa.13 for ; Thu, 01 Dec 2011 08:16:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :subject:x-enigmail-version:content-type; bh=42/KcZZH9qGKSLlOg1RD1quK2/7Ks1JW4QhGxTISJuo=; b=nyIAzZTspmOkruA6RF4C0IYM6Eq2GyNXXuQejEJiAeF1tnRNt6RhxQcA4+ltRQbX0D bpz0bcgfkEpkyY334KmXZWQ1ZBgKuD3DYHSvMcWv1l64gK7I5pOqO0aFaJNsA22BKpn4 Mhab6Ba/jZKq2Ozxgynzx3Dib60t2LXB4xcO0= Received: by 10.213.108.70 with SMTP id e6mr24722ebp.51.1322754282607; Thu, 01 Dec 2011 07:44:42 -0800 (PST) Received: from [10.20.6.26] (seven.iphion.nl. [217.149.136.129]) by mx.google.com with ESMTPS id 8sm18739898ees.2.2011.12.01.07.44.41 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Dec 2011 07:44:42 -0800 (PST) Sender: =?UTF-8?Q?Ren=C3=A9_Ladan?= Message-ID: <4ED7A0D8.90801@freebsd.org> Date: Thu, 01 Dec 2011 16:44:24 +0100 From: Rene Ladan Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111115 Thunderbird/8.0 MIME-Version: 1.0 To: current@FreeBSD.ORG X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA96EF098D339257E340AB9F6" Cc: Subject: lock order reversals with netmap 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, 01 Dec 2011 16:16:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA96EF098D339257E340AB9F6 Content-Type: multipart/mixed; boundary="------------090809090106060906060408" This is a multi-part message in MIME format. --------------090809090106060906060408 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, on FreeBSD 10.0-CURRENT #7 r228176M: Thu Dec 1 13:56:02 CET 2011 (GENERIC + CAPABILITIES + netmap with head.diff and bge patches applied) I get these lock order reversals when running a netmap-enabled program (details in the attachment) with syscall (54, FreeBSD ELF64, sys_ioctl): Dec 1 16:23:09 acer kernel: exclusive sleep mutex netmap memory allocator lock (netmap memory allocator lock) r =3D 0 (0xfffffe00027d1880= ) locked @ /usr/src/sys/dev/netmap/netmap.c:1484 Dec 1 16:23:09 acer kernel: exclusive sleep mutex bge0 (network driver) r =3D 0 (0xffffff8000768010) locked @ /usr/src/sys/dev/netmap/if_bge_netmap.h:60 The application does not invoke the offending function (netmap_malloc()) itself. Regards, Ren=E9 --=20 http://www.rene-ladan.nl:8080/ GPG fingerprint =3D ADBC ECCD EB5F A6B4 549F 600D 8C9E 647A E564 2BFC (subkeys.pgp.net) --------------090809090106060906060408 Content-Type: text/plain; name="netmap-messages" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="netmap-messages" Dec 1 15:41:20 acer kernel: FreeBSD 10.0-CURRENT #7 r228176M: Thu Dec 1= 13:56:02 CET 2011 Dec 1 15:41:20 acer kernel: real memory =3D 4294967296 (4096 MB) Dec 1 15:41:20 acer kernel: avail memory =3D 4080091136 (3891 MB) Dec 1 15:41:20 acer kernel: 001.000005 netmap_memory_init [1627] netmap_= buffer_base 0xffffff8117eaa000 (offset 679936) Dec 1 15:41:20 acer kernel: 001.000006 netmap_memory_init [1636] Have 12= 9 MB, use 661KB for rings, 65862 buffers at 0xffffff8117eaa000 Dec 1 15:41:20 acer kernel: netmap: loaded module with 129 Mbytes Dec 1 15:41:20 acer kernel: bge0: mem 0xf5100000-0xf510ffff irq 16 at dev= ice 0.0 on pci2 Dec 1 15:41:20 acer kernel: bge0: CHIP ID 0x05784100; ASIC REV 0x5784; C= HIP REV 0x57841; PCI-E Dec 1 15:41:20 acer kernel: miibus0: on bge0 Dec 1 15:41:20 acer kernel: brgphy0: PHY = 1 on miibus0 Dec 1 15:41:20 acer kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 1= 00baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-m= aster, auto, auto-flow Dec 1 15:41:20 acer kernel: bge0: Ethernet address: 00:26:2d:5e:d8:ee Dec 1 15:41:20 acer kernel: 001.000009 netmap_attach [1243] ok for bge0 Dec 1 16:23:09 acer kernel: 989.882634 netmap_set_ringid [779] ringid bg= e0 set to SW RING Dec 1 16:23:09 acer kernel: uma_zalloc_arg: zone "64" with the following= non-sleepable locks held: Dec 1 16:23:09 acer kernel: exclusive sleep mutex netmap memory allocato= r lock (netmap memory allocator lock) r =3D 0 (0xfffffe00027d1880) locked= @ /usr/src/sys/dev/netmap/netmap.c:1484 Dec 1 16:23:09 acer kernel: exclusive sleep mutex bge0 (network driver) = r =3D 0 (0xffffff8000768010) locked @ /usr/src/sys/dev/netmap/if_bge_netm= ap.h:60 Dec 1 16:23:09 acer kernel: KDB: stack backtrace: Dec 1 16:23:09 acer kernel: db_trace_self_wrapper() at db_trace_self_wra= pper+0x2a Dec 1 16:23:10 acer kernel: kdb_backtrace() at kdb_backtrace+0x37 Dec 1 16:23:10 acer kernel: _witness_debugger() at _witness_debugger+0x2= c Dec 1 16:23:10 acer kernel: witness_warn() at witness_warn+0x2c2 Dec 1 16:23:10 acer kernel: uma_zalloc_arg() at uma_zalloc_arg+0x335 Dec 1 16:23:10 acer kernel: malloc() at malloc+0xbe Dec 1 16:23:10 acer kernel: netmap_malloc() at netmap_malloc+0x86 Dec 1 16:23:10 acer kernel: netmap_ioctl() at netmap_ioctl+0x5bd Dec 1 16:23:10 acer kernel: devfs_ioctl_f() at devfs_ioctl_f+0x7a Dec 1 16:23:10 acer kernel: kern_ioctl() at kern_ioctl+0xcd Dec 1 16:23:10 acer kernel: sys_ioctl() at sys_ioctl+0xfd Dec 1 16:23:10 acer kernel: amd64_syscall() at amd64_syscall+0x3ac Dec 1 16:23:10 acer kernel: Xfast_syscall() at Xfast_syscall+0xf7 Dec 1 16:23:10 acer kernel: --- syscall (54, FreeBSD ELF64, sys_ioctl), = rip =3D 0x8022aef0c, rsp =3D 0x7fffffffd4b8, rbp =3D 0x802bfb100 --- Dec 1 16:23:10 acer kernel: uma_zalloc_arg: zone "64" with the following= non-sleepable locks held: Dec 1 16:23:10 acer kernel: exclusive sleep mutex netmap memory allocato= r lock (netmap memory allocator lock) r =3D 0 (0xfffffe00027d1880) locked= @ /usr/src/sys/dev/netmap/netmap.c:1484 Dec 1 16:23:10 acer kernel: exclusive sleep mutex bge0 (network driver) = r =3D 0 (0xffffff8000768010) locked @ /usr/src/sys/dev/netmap/if_bge_netm= ap.h:60 Dec 1 16:23:10 acer kernel: KDB: stack backtrace: Dec 1 16:23:10 acer kernel: db_trace_self_wrapper() at db_trace_self_wra= pper+0x2a Dec 1 16:23:10 acer kernel: kdb_backtrace() at kdb_backtrace+0x37 Dec 1 16:23:10 acer kernel: _witness_debugger() at _witness_debugger+0x2= c Dec 1 16:23:10 acer kernel: witness_warn() at witness_warn+0x2c2 Dec 1 16:23:10 acer kernel: uma_zalloc_arg() at uma_zalloc_arg+0x335 Dec 1 16:23:10 acer kernel: malloc() at malloc+0xbe Dec 1 16:23:10 acer kernel: netmap_malloc() at netmap_malloc+0x86 Dec 1 16:23:10 acer kernel: netmap_ioctl() at netmap_ioctl+0x817 Dec 1 16:23:10 acer kernel: devfs_ioctl_f() at devfs_ioctl_f+0x7a Dec 1 16:23:10 acer kernel: kern_ioctl() at kern_ioctl+0xcd Dec 1 16:23:10 acer kernel: sys_ioctl() at sys_ioctl+0xfd Dec 1 16:23:10 acer kernel: amd64_syscall() at amd64_syscall+0x3ac Dec 1 16:23:10 acer kernel: Xfast_syscall() at Xfast_syscall+0xf7 Dec 1 16:23:10 acer kernel: --- syscall (54, FreeBSD ELF64, sys_ioctl), = rip =3D 0x8022aef0c, rsp =3D 0x7fffffffd4b8, rbp =3D 0x802bfb100 --- Dec 1 16:23:10 acer kernel: 990.041760 netmap_reset [1403] +++ NR_REINIT= ok on bge0 RX[0] Dec 1 16:23:10 acer kernel: 990.041948 netmap_reset [1384] +++ NR_REINIT= ok on bge0 TX[0] Dec 1 16:23:10 acer kernel: bge0: link state changed to DOWN Dec 1 16:23:10 acer kernel: 990.051589 netmap_dtor [352] deleting last n= etmap instance for bge0 Dec 1 16:23:12 acer kernel: bge0: link state changed to UP --------------090809090106060906060408-- --------------enigA96EF098D339257E340AB9F6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7XoOkACgkQjJ5keuVkK/yfigCgsO5wQ/1y9D5L7dgBoDLzJB+N Hc8AniBuVaHsf10p+5pqq0sTkiPkKx3p =bNYi -----END PGP SIGNATURE----- --------------enigA96EF098D339257E340AB9F6-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 16:27:27 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 390871065670; Thu, 1 Dec 2011 16:27:27 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Bernhard Froehlich Date: Thu, 1 Dec 2011 11:27:14 -0500 User-Agent: KMail/1.6.2 References: <4ECF7440.4070300@entel.upc.edu> <201111301807.21351.jkim@FreeBSD.org> <60ea779052f025798cf65e18c24b7b31@bluelife.at> In-Reply-To: <60ea779052f025798cf65e18c24b7b31@bluelife.at> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112011127.18517.jkim@FreeBSD.org> Cc: Alan Cox , freebsd-emulation@freebsd.org, FreeBSD current , Gleb Kurtsou , Andriy Gapon Subject: Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464} 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, 01 Dec 2011 16:27:27 -0000 On Thursday 01 December 2011 03:37 am, Bernhard Froehlich wrote: > On 01.12.2011 00:07, Jung-uk Kim wrote: > > On Wednesday 30 November 2011 05:32 pm, Andriy Gapon wrote: > >> on 26/11/2011 18:33 Gleb Kurtsou said the following: > >> > Using new vm_page_alloc_contig() may be a better option here. > >> > Can't help with patch, stuck with pre Nov 15 CURRENT myself. > >> > >> on 27/11/2011 19:09 Alan Cox said the following: > >> > vm_page_alloc_contig() should be used instead. > >> > >> My take on the patch: > >> http://people.freebsd.org/~avg/vbox-10.patch > >> This is for head only, no check for FreeBSD version. > > > > Actually, I did the same thing last night: > > > > > > http://people.freebsd.org/~jkim/patch-src-VBox-Runtime-r0drv-free > >bsd-memobj-r0drv-freebsd.c > > > > This is a drop-in replacement for the patch. The only practical > > difference I see from yours is I used VM_ALLOC_INTERRUPT instead > > of VM_ALLOC_NORMAL. I believe this function may be used in > > interrupt context. FYI, I tried FreeBSD 9 and Fedora 10 without > > problem. > > Thanks a lot for both patches! Could you please as usual reply and > tell me if it is okay to send this patch upstream under MIT > license? Yes, as usual. :-) > Once there is some positive feedback I will commit both patches to > the ports tree. Thanks! Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 16:55:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60462106566B for ; Thu, 1 Dec 2011 16:55:52 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.c2i.net [212.247.154.226]) by mx1.freebsd.org (Postfix) with ESMTP id E10D88FC15 for ; Thu, 1 Dec 2011 16:55:51 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 211847988; Thu, 01 Dec 2011 17:55:40 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Thu, 1 Dec 2011 17:53:05 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <20111130102439.E770E1065672@hub.freebsd.org> <201111301739.58889.hselasky@c2i.net> <20111201104937.B99B3106564A@hub.freebsd.org> In-Reply-To: <20111201104937.B99B3106564A@hub.freebsd.org> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201112011753.05629.hselasky@c2i.net> Cc: Thomas Mueller Subject: Re: man ugen error 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, 01 Dec 2011 16:55:52 -0000 On Thursday 01 December 2011 11:44:13 Thomas Mueller wrote: > > On Wednesday 30 November 2011 11:24:39 Thomas Mueller wrote: > > > According to ugen man page, ugen can be compiled into the kernel with > > > device ugen > > > in config file. > > > > > > I tried that in the kernel config when upgrading from FreeBSD 9.0-RC1 > > > to RC2, but the kernel build stopped quickly with the message that > > > ugen was not valid. After removing that line from kernel config, > > > "make kernel" was successful. > > > > > > I didn't find "device ugen" anywhere in the conf/NOTES or conf/GENERIC > > > files. > > > > > > I hope this man page error can be fixed in time for FreeBSD > > > 9.0-RELEASE. > > > > FYI: "device ugen" is now part of "device usb" > > > > Could you send me a manpage diff? > > --HPS > > What version of FreeBSD do you run? Do you not have a ugen manpage? Can > you run "man ugen"? > > I have the manpages for ugen, and "man usb", also "man 4 usb", but no diff > as such. > > I guess ugen manpage failed to reflect becoming part of usb. There is: share/man/man4/ugen.4 in FreeBSD 10-current. It should be removed and added to old files. Could you make a patch for that? --HPS From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 16:57:37 2011 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05BE41065689; Thu, 1 Dec 2011 16:57:37 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 754A28FC15; Thu, 1 Dec 2011 16:57:36 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id D35697300A; Thu, 1 Dec 2011 17:54:44 +0100 (CET) Date: Thu, 1 Dec 2011 17:54:44 +0100 From: Luigi Rizzo To: Rene Ladan Message-ID: <20111201165444.GA97698@onelab2.iet.unipi.it> References: <4ED7A0D8.90801@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ED7A0D8.90801@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: current@FreeBSD.ORG Subject: Re: lock order reversals with netmap 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, 01 Dec 2011 16:57:37 -0000 On Thu, Dec 01, 2011 at 04:44:24PM +0100, Rene Ladan wrote: > Hi, > > on FreeBSD 10.0-CURRENT #7 r228176M: Thu Dec 1 13:56:02 CET 2011 > (GENERIC + CAPABILITIES + netmap with head.diff and bge patches applied) > I get these lock order reversals when running a netmap-enabled program > (details in the attachment) with syscall (54, FreeBSD ELF64, sys_ioctl): Rene, thanks for the report. As i mentioned earlier to Rene, the 'bge' driver is neither complete nor tested so i am even surprised that it does not crash right away. I'll keep his report in mind when we will complete the support for bge. BTW is someone is familiar with the architecture of the 'bge' NICs please can she/he contact me. I am unclear on why there are two lists of rx buffers (std and jumbo) and one ring -- perhaps the NIC first receives the frame in its fifo and then decides which type of buffer to use to store it ? cheers luigi > Dec 1 16:23:09 acer kernel: exclusive sleep mutex netmap memory > allocator lock (netmap memory allocator lock) r = 0 (0xfffffe00027d1880) > locked @ /usr/src/sys/dev/netmap/netmap.c:1484 > > Dec 1 16:23:09 acer kernel: exclusive sleep mutex bge0 (network driver) > r = 0 (0xffffff8000768010) locked @ > /usr/src/sys/dev/netmap/if_bge_netmap.h:60 > > The application does not invoke the offending function (netmap_malloc()) > itself. > > Regards, > Ren? > -- > http://www.rene-ladan.nl:8080/ > > GPG fingerprint = ADBC ECCD EB5F A6B4 549F 600D 8C9E 647A E564 2BFC > (subkeys.pgp.net) > Dec 1 15:41:20 acer kernel: FreeBSD 10.0-CURRENT #7 r228176M: Thu Dec 1 13:56:02 CET 2011 > Dec 1 15:41:20 acer kernel: real memory = 4294967296 (4096 MB) > Dec 1 15:41:20 acer kernel: avail memory = 4080091136 (3891 MB) > Dec 1 15:41:20 acer kernel: 001.000005 netmap_memory_init [1627] netmap_buffer_base 0xffffff8117eaa000 (offset 679936) > Dec 1 15:41:20 acer kernel: 001.000006 netmap_memory_init [1636] Have 129 MB, use 661KB for rings, 65862 buffers at 0xffffff8117eaa000 > Dec 1 15:41:20 acer kernel: netmap: loaded module with 129 Mbytes > Dec 1 15:41:20 acer kernel: bge0: mem 0xf5100000-0xf510ffff irq 16 at device 0.0 on pci2 > Dec 1 15:41:20 acer kernel: bge0: CHIP ID 0x05784100; ASIC REV 0x5784; CHIP REV 0x57841; PCI-E > Dec 1 15:41:20 acer kernel: miibus0: on bge0 > Dec 1 15:41:20 acer kernel: brgphy0: PHY 1 on miibus0 > Dec 1 15:41:20 acer kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > Dec 1 15:41:20 acer kernel: bge0: Ethernet address: 00:26:2d:5e:d8:ee > Dec 1 15:41:20 acer kernel: 001.000009 netmap_attach [1243] ok for bge0 > Dec 1 16:23:09 acer kernel: 989.882634 netmap_set_ringid [779] ringid bge0 set to SW RING > Dec 1 16:23:09 acer kernel: uma_zalloc_arg: zone "64" with the following non-sleepable locks held: > Dec 1 16:23:09 acer kernel: exclusive sleep mutex netmap memory allocator lock (netmap memory allocator lock) r = 0 (0xfffffe00027d1880) locked @ /usr/src/sys/dev/netmap/netmap.c:1484 > Dec 1 16:23:09 acer kernel: exclusive sleep mutex bge0 (network driver) r = 0 (0xffffff8000768010) locked @ /usr/src/sys/dev/netmap/if_bge_netmap.h:60 > Dec 1 16:23:09 acer kernel: KDB: stack backtrace: > Dec 1 16:23:09 acer kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > Dec 1 16:23:10 acer kernel: kdb_backtrace() at kdb_backtrace+0x37 > Dec 1 16:23:10 acer kernel: _witness_debugger() at _witness_debugger+0x2c > Dec 1 16:23:10 acer kernel: witness_warn() at witness_warn+0x2c2 > Dec 1 16:23:10 acer kernel: uma_zalloc_arg() at uma_zalloc_arg+0x335 > Dec 1 16:23:10 acer kernel: malloc() at malloc+0xbe > Dec 1 16:23:10 acer kernel: netmap_malloc() at netmap_malloc+0x86 > Dec 1 16:23:10 acer kernel: netmap_ioctl() at netmap_ioctl+0x5bd > Dec 1 16:23:10 acer kernel: devfs_ioctl_f() at devfs_ioctl_f+0x7a > Dec 1 16:23:10 acer kernel: kern_ioctl() at kern_ioctl+0xcd > Dec 1 16:23:10 acer kernel: sys_ioctl() at sys_ioctl+0xfd > Dec 1 16:23:10 acer kernel: amd64_syscall() at amd64_syscall+0x3ac > Dec 1 16:23:10 acer kernel: Xfast_syscall() at Xfast_syscall+0xf7 > Dec 1 16:23:10 acer kernel: --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8022aef0c, rsp = 0x7fffffffd4b8, rbp = 0x802bfb100 --- > Dec 1 16:23:10 acer kernel: uma_zalloc_arg: zone "64" with the following non-sleepable locks held: > Dec 1 16:23:10 acer kernel: exclusive sleep mutex netmap memory allocator lock (netmap memory allocator lock) r = 0 (0xfffffe00027d1880) locked @ /usr/src/sys/dev/netmap/netmap.c:1484 > Dec 1 16:23:10 acer kernel: exclusive sleep mutex bge0 (network driver) r = 0 (0xffffff8000768010) locked @ /usr/src/sys/dev/netmap/if_bge_netmap.h:60 > Dec 1 16:23:10 acer kernel: KDB: stack backtrace: > Dec 1 16:23:10 acer kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > Dec 1 16:23:10 acer kernel: kdb_backtrace() at kdb_backtrace+0x37 > Dec 1 16:23:10 acer kernel: _witness_debugger() at _witness_debugger+0x2c > Dec 1 16:23:10 acer kernel: witness_warn() at witness_warn+0x2c2 > Dec 1 16:23:10 acer kernel: uma_zalloc_arg() at uma_zalloc_arg+0x335 > Dec 1 16:23:10 acer kernel: malloc() at malloc+0xbe > Dec 1 16:23:10 acer kernel: netmap_malloc() at netmap_malloc+0x86 > Dec 1 16:23:10 acer kernel: netmap_ioctl() at netmap_ioctl+0x817 > Dec 1 16:23:10 acer kernel: devfs_ioctl_f() at devfs_ioctl_f+0x7a > Dec 1 16:23:10 acer kernel: kern_ioctl() at kern_ioctl+0xcd > Dec 1 16:23:10 acer kernel: sys_ioctl() at sys_ioctl+0xfd > Dec 1 16:23:10 acer kernel: amd64_syscall() at amd64_syscall+0x3ac > Dec 1 16:23:10 acer kernel: Xfast_syscall() at Xfast_syscall+0xf7 > Dec 1 16:23:10 acer kernel: --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8022aef0c, rsp = 0x7fffffffd4b8, rbp = 0x802bfb100 --- > Dec 1 16:23:10 acer kernel: 990.041760 netmap_reset [1403] +++ NR_REINIT ok on bge0 RX[0] > Dec 1 16:23:10 acer kernel: 990.041948 netmap_reset [1384] +++ NR_REINIT ok on bge0 TX[0] > Dec 1 16:23:10 acer kernel: bge0: link state changed to DOWN > Dec 1 16:23:10 acer kernel: 990.051589 netmap_dtor [352] deleting last netmap instance for bge0 > Dec 1 16:23:12 acer kernel: bge0: link state changed to UP From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 16:59:13 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C082106567B; Thu, 1 Dec 2011 16:59:13 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C94DE8FC14; Thu, 1 Dec 2011 16:59:12 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA16172; Thu, 01 Dec 2011 18:59:11 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4ED7B25E.8070002@FreeBSD.org> Date: Thu, 01 Dec 2011 18:59:10 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: John Baldwin References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201111171638.03208.jhb@freebsd.org> <4EC6D544.5040803@FreeBSD.org> <201111211132.42119.jhb@freebsd.org> In-Reply-To: <201111211132.42119.jhb@freebsd.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Stop scheduler on panic 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, 01 Dec 2011 16:59:13 -0000 [cc list trimmed] on 21/11/2011 18:32 John Baldwin said the following: > On Friday, November 18, 2011 4:59:32 pm Andriy Gapon wrote: >> on 17/11/2011 23:38 John Baldwin said the following: >>> On Thursday, November 17, 2011 4:35:07 pm John Baldwin wrote: >>>> Hmmm, you could also make critical_exit() not perform deferred preemptions >>>> if SCHEDULER_STOPPED? That would fix the recursion and still let the >>>> preemption "work" when resuming from the debugger? Just to clarify, probably you are actually suggesting to not perform deferred preemptions if kdb_active == TRUE. Because that's where we get the recursion (via kdb_switch). I think that if we get into the mi_switch in a state where !kdb_active && SCHEDULER_STOPPED(), then we probably should just - I don't know - panic again? [the following is preserved for context] >> Yes, that's a good solution, I think. I just didn't want to touch such a "low >> level" code, but I guess there is no rational reason for that. >> >>> Or you could let the debugger run in a permament critical section (though >>> perhaps that breaks too many other things like debugger routines that try >>> to use locks like the 'kill' command (which is useful!)). Effectively what you >>> are trying to do is having the debugger run in a critical section until the >>> debugger is exited. It would be cleanest to let it run that way explicitly >>> if possible since then you don't have to catch as many edge cases. >> >> I like this idea, but likely it would take some effort to get done. > > Yes, it would take some effort, so checking SCHEDULER_STOPPED in > critical_exit() is probably good for the short term. Would be nice to fix > it properly some day. > >> Related to this is something that I attempted to discuss before. I think that >> because the debugger acts on a frozen system image (the debugger is a sole actor >> and observer), the debugger should try to minimize its interaction with the >> debugged system. In this vein I think that the debugger should also bypass any >> locks just like with SCHEDULER_STOPPED. The debugger should also be careful to >> note a state of any subsystems that it uses (e.g. the keyboard) and return them >> to the initial state if it had to be changed. But that's a bit different story. >> And I really get beyond my knowledge zone when I try to think about things like >> handling 'call func_xxxx' in the debugger where func_xxxx may want to acquire >> some locks or noticeably change some state within a system. > > I think to some extent, I think if a user calls a function from the debugger > they better know what they are doing. However, I think it can also be useful > to have the debugger modify the system in some cases if it can safely do so > (e.g. the 'kill' command from DDB can be very useful, and IIRC, it is careful > to only use try locks and just fail if it can't acquire the needed locks). > >> But to continue about the locks... I have this idea to re-implement >> SCHEDULER_STOPPED as some more general check that could be abstractly denoted as >> LOCKING_POLICY_CHECK(context). Where the context could be defined by flags like >> normal, in-panic, in-debugger, etc. And the locking policies could be: normal, >> bypass, warn, panic, etc. >> >> However, I am not sure if this could be useful (and doable properly) in >> practice. I am just concerned with the interaction between the debugger and the >> locks. It still seems to me inconsistent that we are going with >> SCHEDULER_STOPPED for panic, but we are continuing to use "if (!kdb_active)" >> around some locks that could be problematic under kdb (e.g. in USB). In my >> opinion the amount of code shared between normal context and kdb context is >> about the same as amount of code shared between normal context and panic >> context. But I haven't really quantified those. > > I think you need to keep the 'kill' case in mind. In that case you don't want > to ignore locks, but the code is carefully written to use try locks instead (or > should be). > -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 17:44:56 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80F98106564A; Thu, 1 Dec 2011 17:44:56 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 04F3A8FC13; Thu, 1 Dec 2011 17:44:55 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so2589088vbb.13 for ; Thu, 01 Dec 2011 09:44:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=re+3oZTSU+Te79Wq05hgiqFU5D87C0exUbldvQWIldI=; b=BrPtRoLXgA3PT1HheY8MVzQkiP9Szk9iSFipta2kXh/TjxOfxO0IZ0e5lmpXZvawha 3usVZZOk0A5JxXFep7tcXJexHB9wBVa4DvrVnFKveDh/z+rpKaFqq9zaN4Qask8wGYoM CxkMmX3qniCt5mGkJ1TMcc9ipxNqnHyabLXjA= MIME-Version: 1.0 Received: by 10.52.35.147 with SMTP id h19mr7016696vdj.38.1322759871101; Thu, 01 Dec 2011 09:17:51 -0800 (PST) Received: by 10.220.231.10 with HTTP; Thu, 1 Dec 2011 09:17:51 -0800 (PST) In-Reply-To: References: <201111291607.26546.jhb@freebsd.org> <20111201002515.GA50028@freebsd.org> <20111201014349.GA61475@freebsd.org> Date: Thu, 1 Dec 2011 09:17:51 -0800 Message-ID: From: Freddie Cash To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Alexander Best , Doug Barton , current@freebsd.org, Warner Losh Subject: Re: Remove debug echo 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, 01 Dec 2011 17:44:56 -0000 So, now that you've improved the default diagnostic output of make, how about the OP's original request: make -s truly silent by removing unnecessary diagnostic messages when -s is used? :) [Thought I'd bring the thread back around to it's original purpose.] -- Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 18:03:04 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 038DE106564A; Thu, 1 Dec 2011 18:03:04 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id AD50C8FC08; Thu, 1 Dec 2011 18:03:03 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id pB1I2dp4073729; Thu, 1 Dec 2011 10:02:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1322762560; bh=Y9iFb2V/nbk0W3VvGC2XeNz/WKm3oFMyEQovjV65XC8=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=miV6AZlxU3wbAmG8Ic7TW7NI68+/tw0gOFnliG70NeCfwIYNeHB9vCcIVdUU+B1oN r1dymzvCKvy7HbTfEgXPd27HloiJ337blirJ2Y7ri3F9fcI8STqFNyr6x1N/ufU8mu SJfNZJsQYb5ddy4xap2Ypt1F4tmuD2VhWw47iA4w= From: Sean Bruno To: Jung-uk Kim In-Reply-To: <201111301855.27646.jkim@FreeBSD.org> References: <1322695365.2764.9.camel@hitfishpass-lx.corp.yahoo.com> <4ED6BF01.2080602@FreeBSD.org> <201111301855.27646.jkim@FreeBSD.org> Content-Type: text/plain; charset="UTF-8" Date: Thu, 01 Dec 2011 10:02:39 -0800 Message-ID: <1322762559.2776.0.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: "sbruno@FreeBSD.org" , "freebsd-current@FreeBSD.org" , Gapon , Andriy Subject: Re: Console Spam: acpi_tz0: _TMP value is absurd, ignored (-73.0C) [solved] 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, 01 Dec 2011 18:03:04 -0000 On Wed, 2011-11-30 at 15:55 -0800, Jung-uk Kim wrote: > On Wednesday 30 November 2011 06:40 pm, Andriy Gapon wrote: > > on 01/12/2011 01:22 Sean Bruno said the following: > > > I have a Shuttle based intel box that appears to have some pretty > > > bad ACPI implementation. Is there a good way to quiesce this > > > spam? > > > > Ask on acpi@ list. > > Kidding :-) or not. > > Try hw.acpi.thermal.polling_rate=0. > > Adding the following line in /boot/loader.conf will disable > acpi_thermal(4) completely: > > debug.acpi.disabled="thermal" > > Jung-uk Kim Aye, both are my "huckleberry". Thanks! Sean From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 18:27:23 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0E61106564A for ; Thu, 1 Dec 2011 18:27:23 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: from mail-qw0-f47.google.com (mail-qw0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id 81C708FC17 for ; Thu, 1 Dec 2011 18:27:23 +0000 (UTC) Received: by qaea17 with SMTP id a17so5085712qae.13 for ; Thu, 01 Dec 2011 10:27:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.16.101 with SMTP id f5mr1608826obd.33.1322762393491; Thu, 01 Dec 2011 09:59:53 -0800 (PST) Received: by 10.182.76.225 with HTTP; Thu, 1 Dec 2011 09:59:53 -0800 (PST) X-Originating-IP: [80.89.199.122] In-Reply-To: References: <201111291607.26546.jhb@freebsd.org> <20111201002515.GA50028@freebsd.org> <20111201014349.GA61475@freebsd.org> Date: Thu, 1 Dec 2011 23:59:53 +0600 Message-ID: From: Max Khon To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Alexander Best , Doug Barton , current@freebsd.org, Warner Losh Subject: Re: Remove debug echo 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, 01 Dec 2011 18:27:23 -0000 Garrett, On Thu, Dec 1, 2011 at 2:15 PM, Garrett Cooper wrote: > What I really want is this: > > > > $ cat Makefile > > all: foo bar baz yadda > > > > foo bar yadda: > > > > baz: > > false > > $ gmake > > false > > gmake: *** [baz] Error 1 > > ^^^^ > > $ make all > > false > > *** Error code 1 > > > > Stop in /tmp. > > > > Otherwise diagnosing issues becomes a PITA with -j > 1 (with pmake I > > have to start using some serious grep'ing, and if I'm lucky I can find > > the source of error). If I get a few spare cycles I might just > > implement it and post a patch somewhere (the entering and leaving > > directory feature of gmake is really nice too, but it's less > > important.. unless you have the same target in multiple directories).. > > I've attached a patch that makes make do what I would like it to do; > there are some other items that require cleanup to achieve the `argv0' > prefixing that's available in gmake, but this is good enough for a > meaningful traceback when things fail. Pastebin available here, just > in case the mailing list eats my patch: http://pastebin.com/dFqcDRfv > > $ cat ~/Makefile > all: > cd $$HOME/foo; ${MAKE} $@ > $ cat ~/foo/Makefile > all: foo bar barf yadda > > foo bar yadda: > @true > > baz: > @false > > barf: baz > $ $PWD/make -j4 -f ~/Makefile all > cd $HOME/foo; /usr/src/usr.bin/make/make all > *** [baz] Error code 1 > 1 error > *** [all] Error code 2 > 1 error > $ > > If someone would please, PLEASE commit this.. I will give you beer, or > wine, or a copy of Skyrim, or a few months subscription to WoW, or > something else of value to you that we could negotiate :)... I'm quite > frankly tired of having to playing guessing games fishing through logs > trying to determine build errors on FreeBSD if and when they do occur > with pmake, and I'm sure that a number of developers and build/release > engineers out there are in the same boat as I am. > I hit the same problem regularly. The patch looks good to me as well. Max From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 18:31:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 413D8106564A for ; Thu, 1 Dec 2011 18:31:37 +0000 (UTC) (envelope-from list@sprymed.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id CE3E28FC13 for ; Thu, 1 Dec 2011 18:31:36 +0000 (UTC) Received: by bkat2 with SMTP id t2so3056380bka.13 for ; Thu, 01 Dec 2011 10:31:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.157.27 with SMTP id z27mr8357153bkw.37.1322762501991; Thu, 01 Dec 2011 10:01:41 -0800 (PST) Received: by 10.204.225.141 with HTTP; Thu, 1 Dec 2011 10:01:41 -0800 (PST) Date: Thu, 1 Dec 2011 13:01:41 -0500 Message-ID: From: "list, mailing" To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Looking to start Testing 10-current on Vbox 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, 01 Dec 2011 18:31:37 -0000 I'm looking to start testing 10 on my own. I went to: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ Last update was 201107 Where do I get the Current snapshot of 10. (Or do I upgrade from 9.0-RC2)? Thanks -- Ben Adams http://www.SpryMed.com/ From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 18:36:50 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50FEF1065672; Thu, 1 Dec 2011 18:36:50 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id EDAAF8FC0A; Thu, 1 Dec 2011 18:36:49 +0000 (UTC) Received: by ggnk5 with SMTP id k5so3257903ggn.13 for ; Thu, 01 Dec 2011 10:36:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=D/XKkmjhtv3z1kxTU+FV3Kf0oGQUGEMQx4tKZwNxNJk=; b=D5pADUlac3NRPsufKFUSwqAlK2xY5Alvk0waTOEmIM7gXs94EBu3SfiGpmH77yG1Wn DECvvVQRaG+T2hWdNDlpLHgkZb3OsckIiBaS6zTM8A3PTb11gn8bgHUPKQ7KU82vvXKI Zy6cd/ATcF3pxP+RzVp5+GO2gC878eQ0Lk5IQ= Received: by 10.50.6.202 with SMTP id d10mr9389697iga.31.1322762777488; Thu, 01 Dec 2011 10:06:17 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id l28sm23994451ibc.3.2011.12.01.10.06.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Dec 2011 10:06:13 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 01 Dec 2011 10:04:45 -0800 From: YongHyeon PYUN Date: Thu, 1 Dec 2011 10:04:45 -0800 To: Luigi Rizzo Message-ID: <20111201180445.GA12942@michelle.cdnetworks.com> References: <4ED7A0D8.90801@freebsd.org> <20111201165444.GA97698@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111201165444.GA97698@onelab2.iet.unipi.it> User-Agent: Mutt/1.4.2.3i Cc: Rene Ladan , current@freebsd.org Subject: Re: lock order reversals with netmap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 18:36:50 -0000 On Thu, Dec 01, 2011 at 05:54:44PM +0100, Luigi Rizzo wrote: > On Thu, Dec 01, 2011 at 04:44:24PM +0100, Rene Ladan wrote: > > Hi, > > > > on FreeBSD 10.0-CURRENT #7 r228176M: Thu Dec 1 13:56:02 CET 2011 > > (GENERIC + CAPABILITIES + netmap with head.diff and bge patches applied) > > I get these lock order reversals when running a netmap-enabled program > > (details in the attachment) with syscall (54, FreeBSD ELF64, sys_ioctl): > > Rene, > thanks for the report. > > As i mentioned earlier to Rene, the 'bge' driver > is neither complete nor tested so i am even surprised > that it does not crash right away. I'll keep his report > in mind when we will complete the support for bge. > > BTW is someone is familiar with the architecture of the 'bge' NICs > please can she/he contact me. I am unclear on why there are two > lists of rx buffers (std and jumbo) and one ring -- perhaps the > NIC first receives the frame in its fifo and then decides which > type of buffer to use to store it ? > Actually there are three rings but the additional mini ring is only available for BCM5700. Controller determines which ring(mini, standard and jumbo) would be used to receive the frame based on the frame size. For example, if jumbo frame is enabled and controller receives a pure TCP ACK, controller will use standard RX ring, mini RX ring on BCM5700, which in turn can save system resources. Controller maintains pool of TX/RX buffers in NIC's internal memory space(2 MIPS processors in NIC) and all these decision is made by firmware of the NIC with the help of driver. Broadcom provides publicly available data sheet for open source developers. See the following URL. http://www.broadcom.com/support/ethernet_nic/open_source.php Having two RX buffers are common for controllers that support header splitting. igb(4) and ti(4) have the feature but I think that feature was disabled in igb(4) due to bugs or incomplete implementation in driver. > cheers > luigi > > > Dec 1 16:23:09 acer kernel: exclusive sleep mutex netmap memory > > allocator lock (netmap memory allocator lock) r = 0 (0xfffffe00027d1880) > > locked @ /usr/src/sys/dev/netmap/netmap.c:1484 > > > > Dec 1 16:23:09 acer kernel: exclusive sleep mutex bge0 (network driver) > > r = 0 (0xffffff8000768010) locked @ > > /usr/src/sys/dev/netmap/if_bge_netmap.h:60 > > > > The application does not invoke the offending function (netmap_malloc()) > > itself. > > > > Regards, > > Ren? > > -- > > http://www.rene-ladan.nl:8080/ > > > > GPG fingerprint = ADBC ECCD EB5F A6B4 549F 600D 8C9E 647A E564 2BFC > > (subkeys.pgp.net) > > > Dec 1 15:41:20 acer kernel: FreeBSD 10.0-CURRENT #7 r228176M: Thu Dec 1 13:56:02 CET 2011 > > Dec 1 15:41:20 acer kernel: real memory = 4294967296 (4096 MB) > > Dec 1 15:41:20 acer kernel: avail memory = 4080091136 (3891 MB) > > Dec 1 15:41:20 acer kernel: 001.000005 netmap_memory_init [1627] netmap_buffer_base 0xffffff8117eaa000 (offset 679936) > > Dec 1 15:41:20 acer kernel: 001.000006 netmap_memory_init [1636] Have 129 MB, use 661KB for rings, 65862 buffers at 0xffffff8117eaa000 > > Dec 1 15:41:20 acer kernel: netmap: loaded module with 129 Mbytes > > Dec 1 15:41:20 acer kernel: bge0: mem 0xf5100000-0xf510ffff irq 16 at device 0.0 on pci2 > > Dec 1 15:41:20 acer kernel: bge0: CHIP ID 0x05784100; ASIC REV 0x5784; CHIP REV 0x57841; PCI-E > > Dec 1 15:41:20 acer kernel: miibus0: on bge0 > > Dec 1 15:41:20 acer kernel: brgphy0: PHY 1 on miibus0 > > Dec 1 15:41:20 acer kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > > Dec 1 15:41:20 acer kernel: bge0: Ethernet address: 00:26:2d:5e:d8:ee > > Dec 1 15:41:20 acer kernel: 001.000009 netmap_attach [1243] ok for bge0 > > Dec 1 16:23:09 acer kernel: 989.882634 netmap_set_ringid [779] ringid bge0 set to SW RING > > Dec 1 16:23:09 acer kernel: uma_zalloc_arg: zone "64" with the following non-sleepable locks held: > > Dec 1 16:23:09 acer kernel: exclusive sleep mutex netmap memory allocator lock (netmap memory allocator lock) r = 0 (0xfffffe00027d1880) locked @ /usr/src/sys/dev/netmap/netmap.c:1484 > > Dec 1 16:23:09 acer kernel: exclusive sleep mutex bge0 (network driver) r = 0 (0xffffff8000768010) locked @ /usr/src/sys/dev/netmap/if_bge_netmap.h:60 > > Dec 1 16:23:09 acer kernel: KDB: stack backtrace: > > Dec 1 16:23:09 acer kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > Dec 1 16:23:10 acer kernel: kdb_backtrace() at kdb_backtrace+0x37 > > Dec 1 16:23:10 acer kernel: _witness_debugger() at _witness_debugger+0x2c > > Dec 1 16:23:10 acer kernel: witness_warn() at witness_warn+0x2c2 > > Dec 1 16:23:10 acer kernel: uma_zalloc_arg() at uma_zalloc_arg+0x335 > > Dec 1 16:23:10 acer kernel: malloc() at malloc+0xbe > > Dec 1 16:23:10 acer kernel: netmap_malloc() at netmap_malloc+0x86 > > Dec 1 16:23:10 acer kernel: netmap_ioctl() at netmap_ioctl+0x5bd > > Dec 1 16:23:10 acer kernel: devfs_ioctl_f() at devfs_ioctl_f+0x7a > > Dec 1 16:23:10 acer kernel: kern_ioctl() at kern_ioctl+0xcd > > Dec 1 16:23:10 acer kernel: sys_ioctl() at sys_ioctl+0xfd > > Dec 1 16:23:10 acer kernel: amd64_syscall() at amd64_syscall+0x3ac > > Dec 1 16:23:10 acer kernel: Xfast_syscall() at Xfast_syscall+0xf7 > > Dec 1 16:23:10 acer kernel: --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8022aef0c, rsp = 0x7fffffffd4b8, rbp = 0x802bfb100 --- > > Dec 1 16:23:10 acer kernel: uma_zalloc_arg: zone "64" with the following non-sleepable locks held: > > Dec 1 16:23:10 acer kernel: exclusive sleep mutex netmap memory allocator lock (netmap memory allocator lock) r = 0 (0xfffffe00027d1880) locked @ /usr/src/sys/dev/netmap/netmap.c:1484 > > Dec 1 16:23:10 acer kernel: exclusive sleep mutex bge0 (network driver) r = 0 (0xffffff8000768010) locked @ /usr/src/sys/dev/netmap/if_bge_netmap.h:60 > > Dec 1 16:23:10 acer kernel: KDB: stack backtrace: > > Dec 1 16:23:10 acer kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > Dec 1 16:23:10 acer kernel: kdb_backtrace() at kdb_backtrace+0x37 > > Dec 1 16:23:10 acer kernel: _witness_debugger() at _witness_debugger+0x2c > > Dec 1 16:23:10 acer kernel: witness_warn() at witness_warn+0x2c2 > > Dec 1 16:23:10 acer kernel: uma_zalloc_arg() at uma_zalloc_arg+0x335 > > Dec 1 16:23:10 acer kernel: malloc() at malloc+0xbe > > Dec 1 16:23:10 acer kernel: netmap_malloc() at netmap_malloc+0x86 > > Dec 1 16:23:10 acer kernel: netmap_ioctl() at netmap_ioctl+0x817 > > Dec 1 16:23:10 acer kernel: devfs_ioctl_f() at devfs_ioctl_f+0x7a > > Dec 1 16:23:10 acer kernel: kern_ioctl() at kern_ioctl+0xcd > > Dec 1 16:23:10 acer kernel: sys_ioctl() at sys_ioctl+0xfd > > Dec 1 16:23:10 acer kernel: amd64_syscall() at amd64_syscall+0x3ac > > Dec 1 16:23:10 acer kernel: Xfast_syscall() at Xfast_syscall+0xf7 > > Dec 1 16:23:10 acer kernel: --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8022aef0c, rsp = 0x7fffffffd4b8, rbp = 0x802bfb100 --- > > Dec 1 16:23:10 acer kernel: 990.041760 netmap_reset [1403] +++ NR_REINIT ok on bge0 RX[0] > > Dec 1 16:23:10 acer kernel: 990.041948 netmap_reset [1384] +++ NR_REINIT ok on bge0 TX[0] > > Dec 1 16:23:10 acer kernel: bge0: link state changed to DOWN > > Dec 1 16:23:10 acer kernel: 990.051589 netmap_dtor [352] deleting last netmap instance for bge0 > > Dec 1 16:23:12 acer kernel: bge0: link state changed to UP > > > > _______________________________________________ > 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 Dec 1 18:46:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70CC9106564A for ; Thu, 1 Dec 2011 18:46:41 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 203A28FC08 for ; Thu, 1 Dec 2011 18:46:40 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id pB1Ik36a090947 for ; Thu, 1 Dec 2011 10:46:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1322765163; bh=mzUQHDwNM6eopFJg0ykO7WKi/jw5J0xn4MWPQyVwll4=; h=Subject:From:Reply-To:To:Content-Type:Date:Message-ID: Mime-Version:Content-Transfer-Encoding; b=Rg7lcwxSxts1FtrL9ySmv++Q9QRPkX2uf3p/L4V/dWHe/1bglFcaqwLGAvoN1+D/U rMPuI4/m8JhlZatORdRKihifW8kiiI6knELSAgkkv7rVuqKakwt0NCt4rVwSUHI9Cj jyR88KGSRI2/TelvFLEl4pWf7sbv7bftud7kmPak= From: Sean Bruno To: "freebsd-current@freebsd.org" Content-Type: text/plain; charset="UTF-8" Date: Thu, 01 Dec 2011 10:46:03 -0800 Message-ID: <1322765163.2776.3.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Subject: Malformed conditional (${MK_CTF} != "no") X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@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, 01 Dec 2011 18:46:41 -0000 I've noted that this morning's svn update seems to be breaking pretty badly. Is this related to the DTRACE conf changes? [seanb@sbpi386 ~/head/sys/modules/firewire]$ make ===> firewire (all) "/usr/home/seanb/head/sys/modules/firewire/firewire/../../../conf/kmod.mk", line 204: Malformed conditional (${MK_CTF} != "no") "/usr/home/seanb/head/sys/modules/firewire/firewire/../../../conf/kmod.mk", line 206: if-less endif make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /usr/home/seanb/head/sys/modules/firewire. From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 18:49:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42A0A106566C; Thu, 1 Dec 2011 18:49:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1B48F8FC0C; Thu, 1 Dec 2011 18:49:52 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id AEFDD46B0C; Thu, 1 Dec 2011 13:49:51 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 34123B941; Thu, 1 Dec 2011 13:49:51 -0500 (EST) From: John Baldwin To: Andriy Gapon Date: Thu, 1 Dec 2011 13:49:50 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201111211132.42119.jhb@freebsd.org> <4ED7B25E.8070002@FreeBSD.org> In-Reply-To: <4ED7B25E.8070002@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112011349.50502.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 01 Dec 2011 13:49:51 -0500 (EST) Cc: freebsd-current@freebsd.org Subject: Re: Stop scheduler on panic 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, 01 Dec 2011 18:49:52 -0000 On Thursday, December 01, 2011 11:59:10 am Andriy Gapon wrote: > > [cc list trimmed] > > on 21/11/2011 18:32 John Baldwin said the following: > > On Friday, November 18, 2011 4:59:32 pm Andriy Gapon wrote: > >> on 17/11/2011 23:38 John Baldwin said the following: > >>> On Thursday, November 17, 2011 4:35:07 pm John Baldwin wrote: > >>>> Hmmm, you could also make critical_exit() not perform deferred preemptions > >>>> if SCHEDULER_STOPPED? That would fix the recursion and still let the > >>>> preemption "work" when resuming from the debugger? > > > Just to clarify, probably you are actually suggesting to not perform deferred > preemptions if kdb_active == TRUE. Because that's where we get the recursion (via > kdb_switch). > > I think that if we get into the mi_switch in a state where !kdb_active && > SCHEDULER_STOPPED(), then we probably should just - I don't know - panic again? > > [the following is preserved for context] Hmmm. I'd be tempted to just ignore pending preemptions anytime SCHEDULER_STOPPED() is true. If it's stopped for a reason other than being in the debugger (e.g. panic), I'd rather make a best effort at getting a dump than panic again. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 18:56:10 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79C67106564A for ; Thu, 1 Dec 2011 18:56:10 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 442BD8FC0A for ; Thu, 1 Dec 2011 18:56:09 +0000 (UTC) Received: by iakl21 with SMTP id l21so4494394iak.13 for ; Thu, 01 Dec 2011 10:56:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=87f1jqDevbxJx7UmiPpKBN5m2cH6NDfpgGRXxxhX2i8=; b=isRwLtOVxS6gKej4N3BDNz03joSTWHkz0W+XHSnyZdBe/zch8EbttzGzvUpdliFCla G2qJ+/teNpj1cQ1drnr5p5W7MG8NhIkbgdgbguQ1UNtEGOS7VJlb+6hiJrXcDSDpoJEi C0yZ15svcln5PnGJS0LspEpwx0UqJzNqgexHw= Received: by 10.42.154.7 with SMTP id o7mr10075314icw.48.1322765769590; Thu, 01 Dec 2011 10:56:09 -0800 (PST) Received: from kruse-180.4.ixsystems.com (drawbridge.ixsystems.com. [206.40.55.65]) by mx.google.com with ESMTPS id z10sm24346332ibv.9.2011.12.01.10.56.05 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Dec 2011 10:56:05 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <1322765163.2776.3.camel@hitfishpass-lx.corp.yahoo.com> Date: Thu, 1 Dec 2011 10:56:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <782F304A-CC5C-4DFE-9277-42946A80D84D@gmail.com> References: <1322765163.2776.3.camel@hitfishpass-lx.corp.yahoo.com> To: sbruno@freebsd.org X-Mailer: Apple Mail (2.1084) Cc: "freebsd-current@freebsd.org" Subject: Re: Malformed conditional (${MK_CTF} != "no") 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, 01 Dec 2011 18:56:10 -0000 On Dec 1, 2011, at 10:46 AM, Sean Bruno wrote: > I've noted that this morning's svn update seems to be breaking pretty > badly. Is this related to the DTRACE conf changes? >=20 > [seanb@sbpi386 ~/head/sys/modules/firewire]$ make > =3D=3D=3D> firewire (all) > = "/usr/home/seanb/head/sys/modules/firewire/firewire/../../../conf/kmod.mk"= , line 204: Malformed conditional (${MK_CTF} !=3D "no") > = "/usr/home/seanb/head/sys/modules/firewire/firewire/../../../conf/kmod.mk"= , line 206: if-less endif > make: fatal errors encountered -- cannot continue > *** Error code 1 >=20 > Stop in /usr/home/seanb/head/sys/modules/firewire. You'll need to use the updated share/mk/bsd.own.mk in order to build on = trunk, which is obscured by the toolchain target IIRC. You could invoke = make like so in the meantime: make -m $HOME/head/share/mk all to workaround this issue -- or just install all of the include Makefiles = there, via (cd ~/head/share/mk; make -m `pwd` install) HTH! -Garrett= From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 19:24:15 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3552106566B; Thu, 1 Dec 2011 19:24:15 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 88D128FC17; Thu, 1 Dec 2011 19:24:15 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id pB1JNrow004866; Thu, 1 Dec 2011 11:23:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1322767434; bh=F8NFHEleCNRNrrKthpOVcpnBiL9m+5n4SCoEAgGtJqk=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=VszJQsrZKkCNONrd+V9mJmWXpSxyYE3L6XQS/eXNpJF1FDWARIcABvfWq4v4zB6E0 pTajzrl8wwuHep83VMaGVikS21T+/D8A+5NVjwq46LHNrJi5+bSSrVKcgYh/dFqIJc v5ELfZCnvhGnPt1zoqPDX1FYDLDVntq1Y0qdy7O8= From: Sean Bruno To: Garrett Cooper In-Reply-To: <782F304A-CC5C-4DFE-9277-42946A80D84D@gmail.com> References: <1322765163.2776.3.camel@hitfishpass-lx.corp.yahoo.com> <782F304A-CC5C-4DFE-9277-42946A80D84D@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 01 Dec 2011 11:23:53 -0800 Message-ID: <1322767433.2776.9.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" Subject: Re: Malformed conditional (${MK_CTF} != "no") [solved] 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, 01 Dec 2011 19:24:15 -0000 On Thu, 2011-12-01 at 10:56 -0800, Garrett Cooper wrote: > to workaround this issue -- or just install all of the include > Makefiles there, via (cd ~/head/share/mk; make -m `pwd` install) Thanks amigo. sean From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 19:31:19 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9A39106564A for ; Thu, 1 Dec 2011 19:31:19 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6F7508FC15 for ; Thu, 1 Dec 2011 19:31:19 +0000 (UTC) Received: by yenq9 with SMTP id q9so3160751yen.13 for ; Thu, 01 Dec 2011 11:31:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=Ig2lL286t6nYy2D29pbhnzEEzB9twJGsJoXsH9seX8U=; b=lj6v3mB9YuPNMi4XIQKBR/nD//CZWM+Gsjpl3Ek61few+MFKSq76D3PcvM6a3P0SAS V8DYz1yHsrjMexNIqI7Ea0F+wurl/Pcy0EKelZXg4wAMmWwos9UEnM8pEye7X7OaIVeT dp88DyJsiDGfZ+KDIdlkFRbRKwp7JxXTSk1Fw= MIME-Version: 1.0 Received: by 10.50.6.202 with SMTP id d10mr9792030iga.31.1322767878709; Thu, 01 Dec 2011 11:31:18 -0800 (PST) Received: by 10.231.15.7 with HTTP; Thu, 1 Dec 2011 11:31:18 -0800 (PST) Date: Thu, 1 Dec 2011 21:31:18 +0200 Message-ID: From: George Kontostanos To: FreeBSD-Current Content-Type: text/plain; charset=ISO-8859-1 Subject: ahci in FreeBSD 9 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, 01 Dec 2011 19:31:19 -0000 Hi everyone, >From my understanding as of 20110424 revision device ahci has been integrated into kernel: ---------------- It is possible to load devices ahci, ata, siis and mvs as modules, but option ATA_CAM should remain in kernel configuration to make ata module work as CAM driver supporting legacy ATA controllers. Device ata still can be used in modular fashion ....... No kernel config options or code have been removed, so if a problem arises, please report it and optionally revert to the old ATA stack. In order to do it you can remove from the kernel config: options ATA_CAM device ahci ---------------- Does this mean that loading ahci in loader.conf is useless ? Thanks -- George Kontostanos Aicom telecoms ltd http://www.barebsd.com From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 19:35:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3ECE1065675 for ; Thu, 1 Dec 2011 19:35:52 +0000 (UTC) (envelope-from mokomull@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4177E8FC1C for ; Thu, 1 Dec 2011 19:35:51 +0000 (UTC) Received: by lahv2 with SMTP id v2so1277122lah.13 for ; Thu, 01 Dec 2011 11:35:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7sSJuq2dCHsQclHJQsCX/UkaOieR1DxUjyQbRbok6Qk=; b=f1sjS1VJstRFv6l/tVCoyLTqi5sEEOGObck1Dz0LkTpoggi6eoF6qFfSbG4ZbjWRPa ThA7dOjcBV9AE/P4Knm2lfBXxZI4ZDeKfDbpfQEDWJ6E4W7bGbn8uXiJZqUy2IfAuWui dw5q3JcHcMcRpNbHdwGsF58eSeFbNbUy71jlo= MIME-Version: 1.0 Received: by 10.205.117.14 with SMTP id fk14mr8697508bkc.116.1322768150927; Thu, 01 Dec 2011 11:35:50 -0800 (PST) Received: by 10.223.72.196 with HTTP; Thu, 1 Dec 2011 11:35:50 -0800 (PST) In-Reply-To: <20111201112838.GA62127@freebsd.org> References: <20111201112838.GA62127@freebsd.org> Date: Thu, 1 Dec 2011 11:35:50 -0800 Message-ID: From: Matt Mullins To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: stupid cp(1) behaviour 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, 01 Dec 2011 19:35:53 -0000 On Thu, Dec 1, 2011 at 3:28 AM, Alexander Best wrote: > implement a new -N switch or so which isn't based on a file's existance, but a > file's checksum. You can always use net/rsync, which does by default compare checksums. -- Matt Mullins From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 20:35:10 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D312E1065675 for ; Thu, 1 Dec 2011 20:35:10 +0000 (UTC) (envelope-from geo.liaskos@gmail.com) Received: from mail-qw0-f47.google.com (mail-qw0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id 953FA8FC08 for ; Thu, 1 Dec 2011 20:35:10 +0000 (UTC) Received: by qaea17 with SMTP id a17so5267831qae.13 for ; Thu, 01 Dec 2011 12:35:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=eUSq+HYQVs049m2c0wLJ/0uoV962aOk22xZPauLGeZo=; b=HuyeW2FkTLZR1ffcuQNHpOPN1DAQf2JulJZb/BbeMQEXTuvqspmETpG8k5rrelrngK Q4ECk0mw1yju50D2jVbPA7YcSopsk9IP/yCbYigEK1FOrtceElHPwqkco7jTwu5iC0C3 vmrG7tGfxVsZe6py9TvdCPa3mykT2TRi/o7tU= MIME-Version: 1.0 Received: by 10.229.101.72 with SMTP id b8mr1751821qco.209.1322770088036; Thu, 01 Dec 2011 12:08:08 -0800 (PST) Received: by 10.224.189.135 with HTTP; Thu, 1 Dec 2011 12:08:08 -0800 (PST) Date: Thu, 1 Dec 2011 22:08:08 +0200 Message-ID: From: George Liaskos To: freebsd-current Content-Type: text/plain; charset=UTF-8 Subject: r227487 breaks C++ programs that use __isthreaded 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, 01 Dec 2011 20:35:10 -0000 Hello One example is Google's tcmalloc [1], is this behaviour intended? [1] http://code.google.com/p/google-perftools/source/browse/trunk/src/maybe_threads.cc Regards, George From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 20:42:27 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECD5D1065680; Thu, 1 Dec 2011 20:42:27 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0A9738FC18; Thu, 1 Dec 2011 20:42:26 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA18409; Thu, 01 Dec 2011 22:42:25 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RWDSb-0007kV-80; Thu, 01 Dec 2011 22:42:25 +0200 Message-ID: <4ED7E6B0.30400@FreeBSD.org> Date: Thu, 01 Dec 2011 22:42:24 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: John Baldwin References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201111211132.42119.jhb@freebsd.org> <4ED7B25E.8070002@FreeBSD.org> <201112011349.50502.jhb@freebsd.org> In-Reply-To: <201112011349.50502.jhb@freebsd.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Stop scheduler on panic 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, 01 Dec 2011 20:42:28 -0000 on 01/12/2011 20:49 John Baldwin said the following: > On Thursday, December 01, 2011 11:59:10 am Andriy Gapon wrote: >> >> [cc list trimmed] >> >> on 21/11/2011 18:32 John Baldwin said the following: >>> On Friday, November 18, 2011 4:59:32 pm Andriy Gapon wrote: >>>> on 17/11/2011 23:38 John Baldwin said the following: >>>>> On Thursday, November 17, 2011 4:35:07 pm John Baldwin wrote: >>>>>> Hmmm, you could also make critical_exit() not perform deferred preemptions >>>>>> if SCHEDULER_STOPPED? That would fix the recursion and still let the >>>>>> preemption "work" when resuming from the debugger? >> >> >> Just to clarify, probably you are actually suggesting to not perform deferred >> preemptions if kdb_active == TRUE. Because that's where we get the recursion (via >> kdb_switch). >> >> I think that if we get into the mi_switch in a state where !kdb_active && >> SCHEDULER_STOPPED(), then we probably should just - I don't know - panic again? >> >> [the following is preserved for context] > > Hmmm. I'd be tempted to just ignore pending preemptions anytime > SCHEDULER_STOPPED() is true. If it's stopped for a reason other than being > in the debugger (e.g. panic), I'd rather make a best effort at getting a dump > than panic again. Yep, me too. It's just that I assumed that ending up at mi_switch in the panic thread/context meant that something had gone very wrong already. But I am not sure if this was a valid assumption. Returning to critical_exit, what do you think about the following patch? I guess that it could be committed independently of / before the SCHEDULER_STOPPED thing. commit ee3d1a04985e86911a68d854439ae8c5429b7bd5 Author: Andriy Gapon Date: Thu Dec 1 18:53:36 2011 +0200 critical_exit: ignore td_owepreempt if kdb_active calling mi_switch in such a context result in a recursion via kdb_switch diff --git a/sys/kern/kern_switch.c b/sys/kern/kern_switch.c index 93cbf7b..885dc22 100644 --- a/sys/kern/kern_switch.c +++ b/sys/kern/kern_switch.c @@ -200,7 +200,7 @@ critical_exit(void) if (td->td_critnest == 1) { td->td_critnest = 0; - if (td->td_owepreempt) { + if (td->td_owepreempt && !kdb_active) { td->td_critnest = 1; thread_lock(td); td->td_critnest--; Would it make sense wrap kdb_active check with __predict_false? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 21:27:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20D44106564A; Thu, 1 Dec 2011 21:27:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id ECDD78FC08; Thu, 1 Dec 2011 21:27:46 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 8785A46B0D; Thu, 1 Dec 2011 16:27:46 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 16472B94B; Thu, 1 Dec 2011 16:27:46 -0500 (EST) From: John Baldwin To: Andriy Gapon Date: Thu, 1 Dec 2011 15:53:34 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201112011349.50502.jhb@freebsd.org> <4ED7E6B0.30400@FreeBSD.org> In-Reply-To: <4ED7E6B0.30400@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112011553.34432.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 01 Dec 2011 16:27:46 -0500 (EST) Cc: freebsd-current@freebsd.org Subject: Re: Stop scheduler on panic 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, 01 Dec 2011 21:27:47 -0000 On Thursday, December 01, 2011 3:42:24 pm Andriy Gapon wrote: > on 01/12/2011 20:49 John Baldwin said the following: > > On Thursday, December 01, 2011 11:59:10 am Andriy Gapon wrote: > >> > >> [cc list trimmed] > >> > >> on 21/11/2011 18:32 John Baldwin said the following: > >>> On Friday, November 18, 2011 4:59:32 pm Andriy Gapon wrote: > >>>> on 17/11/2011 23:38 John Baldwin said the following: > >>>>> On Thursday, November 17, 2011 4:35:07 pm John Baldwin wrote: > >>>>>> Hmmm, you could also make critical_exit() not perform deferred preemptions > >>>>>> if SCHEDULER_STOPPED? That would fix the recursion and still let the > >>>>>> preemption "work" when resuming from the debugger? > >> > >> > >> Just to clarify, probably you are actually suggesting to not perform deferred > >> preemptions if kdb_active == TRUE. Because that's where we get the recursion (via > >> kdb_switch). > >> > >> I think that if we get into the mi_switch in a state where !kdb_active && > >> SCHEDULER_STOPPED(), then we probably should just - I don't know - panic again? > >> > >> [the following is preserved for context] > > > > Hmmm. I'd be tempted to just ignore pending preemptions anytime > > SCHEDULER_STOPPED() is true. If it's stopped for a reason other than being > > in the debugger (e.g. panic), I'd rather make a best effort at getting a dump > > than panic again. > > Yep, me too. It's just that I assumed that ending up at mi_switch in the panic > thread/context meant that something had gone very wrong already. But I am not > sure if this was a valid assumption. > > Returning to critical_exit, what do you think about the following patch? > I guess that it could be committed independently of / before the > SCHEDULER_STOPPED thing. > > commit ee3d1a04985e86911a68d854439ae8c5429b7bd5 > Author: Andriy Gapon > Date: Thu Dec 1 18:53:36 2011 +0200 > > critical_exit: ignore td_owepreempt if kdb_active > > calling mi_switch in such a context result in a recursion via > kdb_switch > > diff --git a/sys/kern/kern_switch.c b/sys/kern/kern_switch.c > index 93cbf7b..885dc22 100644 > --- a/sys/kern/kern_switch.c > +++ b/sys/kern/kern_switch.c > @@ -200,7 +200,7 @@ critical_exit(void) > > if (td->td_critnest == 1) { > td->td_critnest = 0; > - if (td->td_owepreempt) { > + if (td->td_owepreempt && !kdb_active) { > td->td_critnest = 1; > thread_lock(td); > td->td_critnest--; I think this is fine, but I'd probably change this to SCHEDULER_STOPPED() in the SCHEDULER_STOPPED() patch. > Would it make sense wrap kdb_active check with __predict_false? I don't think so. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 21:38:47 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 059E6106564A for ; Thu, 1 Dec 2011 21:38:47 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id C0AD48FC12 for ; Thu, 1 Dec 2011 21:38:46 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.5/8.14.2) with ESMTP id pB1LNBQN083465; Thu, 1 Dec 2011 16:23:11 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.5/8.14.2/Submit) id pB1LNBEn083464; Thu, 1 Dec 2011 16:23:11 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Thu, 1 Dec 2011 16:23:11 -0500 From: David Schultz To: George Liaskos Message-ID: <20111201212311.GA83353@zim.MIT.EDU> Mail-Followup-To: George Liaskos , freebsd-current References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-current Subject: Re: r227487 breaks C++ programs that use __isthreaded 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, 01 Dec 2011 21:38:47 -0000 On Thu, Dec 01, 2011, George Liaskos wrote: > Hello > > One example is Google's tcmalloc [1], is this behaviour intended? > > [1] http://code.google.com/p/google-perftools/source/browse/trunk/src/maybe_threads.cc This code uses an unportable workaround for a bug that I believe was fixed in r227999. Using internal names starting with a double underscore isn't supported. Separately, I'm still hoping that the namespace polution introduced in r227487 gets fixed... From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 21:42:36 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42653106566C; Thu, 1 Dec 2011 21:42:36 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id AACB68FC0A; Thu, 1 Dec 2011 21:42:27 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA19075; Thu, 01 Dec 2011 23:42:23 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RWEOc-0007mF-I1; Thu, 01 Dec 2011 23:42:22 +0200 Message-ID: <4ED7F4BC.3080206@FreeBSD.org> Date: Thu, 01 Dec 2011 23:42:20 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: John Baldwin References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201112011349.50502.jhb@freebsd.org> <4ED7E6B0.30400@FreeBSD.org> <201112011553.34432.jhb@freebsd.org> In-Reply-To: <201112011553.34432.jhb@freebsd.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Stop scheduler on panic 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, 01 Dec 2011 21:42:36 -0000 on 01/12/2011 22:53 John Baldwin said the following: > On Thursday, December 01, 2011 3:42:24 pm Andriy Gapon wrote: >> Returning to critical_exit, what do you think about the following patch? >> I guess that it could be committed independently of / before the >> SCHEDULER_STOPPED thing. >> >> commit ee3d1a04985e86911a68d854439ae8c5429b7bd5 >> Author: Andriy Gapon >> Date: Thu Dec 1 18:53:36 2011 +0200 >> >> critical_exit: ignore td_owepreempt if kdb_active >> >> calling mi_switch in such a context result in a recursion via >> kdb_switch >> >> diff --git a/sys/kern/kern_switch.c b/sys/kern/kern_switch.c >> index 93cbf7b..885dc22 100644 >> --- a/sys/kern/kern_switch.c >> +++ b/sys/kern/kern_switch.c >> @@ -200,7 +200,7 @@ critical_exit(void) >> >> if (td->td_critnest == 1) { >> td->td_critnest = 0; >> - if (td->td_owepreempt) { >> + if (td->td_owepreempt && !kdb_active) { >> td->td_critnest = 1; >> thread_lock(td); >> td->td_critnest--; > > I think this is fine, but I'd probably change this to SCHEDULER_STOPPED() > in the SCHEDULER_STOPPED() patch. I don't understand why... What if kdb is entered for some other reason, not because of panic? In that case SCHEDULER_STOPPED() would be false, but it is still possible to find a way into mi_switch. The SCHEDULER_STOPPED patch adds this: @@ -428,6 +428,8 @@ mi_switch(int flags, struct thread *newtd) */ if (kdb_active) kdb_switch(); + if (SCHEDULER_STOPPED()) + return; if (flags & SW_VOL) { td->td_ru.ru_nvcsw++; td->td_swvoltick = ticks; -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 22:34:29 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 119F3106564A; Thu, 1 Dec 2011 22:34:29 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 986328FC15; Thu, 1 Dec 2011 22:34:28 +0000 (UTC) Received: by yenq9 with SMTP id q9so3396491yen.13 for ; Thu, 01 Dec 2011 14:34:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=uS6eKvuO06NCaIERX5fLYE2qInloGwFssLa6H97raI8=; b=CpxEJOFbMLct51gDI0JwVBsRehrb0cS6WcMDBzGHK9iJFmb/8bUFO4Q6tBRKoPUHjx PCZ8iFp5hPRCqjGbYyTTuRp6hbSgnS/sb28rjCVnbOhbnGQJvVX6LkGIHi2/yONBxn6F Oc5bLfxTT6m2zeqTLtrIrtn3KgsKVisvisSrQ= MIME-Version: 1.0 Received: by 10.182.74.37 with SMTP id q5mr1819588obv.32.1322778868037; Thu, 01 Dec 2011 14:34:28 -0800 (PST) Received: by 10.182.62.227 with HTTP; Thu, 1 Dec 2011 14:34:27 -0800 (PST) In-Reply-To: References: <201111291607.26546.jhb@freebsd.org> <20111201002515.GA50028@freebsd.org> <20111201014349.GA61475@freebsd.org> Date: Thu, 1 Dec 2011 14:34:27 -0800 Message-ID: From: Garrett Cooper To: Freddie Cash Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexander Best , Doug Barton , current@freebsd.org, Warner Losh Subject: Re: Remove debug echo 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, 01 Dec 2011 22:34:29 -0000 On Thu, Dec 1, 2011 at 9:17 AM, Freddie Cash wrote: > So, now that you've improved the default diagnostic output of make, how > about the OP's original request: > =A0 =A0make -s truly silent by removing unnecessary diagnostic messages w= hen -s > is used? =A0:) > > [Thought I'd bring the thread back around to it's original purpose.] Sure. I'd be more than happy if someone would review and commit my proposed patches as well :). Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Dec 1 23:17:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34FE5106566B; Thu, 1 Dec 2011 23:17:25 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 000FA8FC08; Thu, 1 Dec 2011 23:17:24 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pB1NHOCZ090417; Thu, 1 Dec 2011 23:17:24 GMT (envelope-from bapt@freebsd.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pB1NHOgJ090416; Thu, 1 Dec 2011 23:17:24 GMT (envelope-from bapt@freebsd.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@freebsd.org using -f Date: Fri, 2 Dec 2011 00:17:21 +0100 From: Baptiste Daroussin To: Olivier Houchard Message-ID: <20111201231721.GA1669@azathoth.lan> References: <20111130124320.GA1449@azathoth.lan> <201111301005.11938.jhb@freebsd.org> <20111130154636.GX50300@deviant.kiev.zoral.com.ua> <20111130155521.GA52567@ci0.org> <20111130160450.GY50300@deviant.kiev.zoral.com.ua> <20111130162017.GA53362@ci0.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline In-Reply-To: <20111130162017.GA53362@ci0.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Kostik Belousov , freebsd-current@freebsd.org, imp@freebsd.org Subject: Re: [patch] turning devctl into a "multiple openable" device 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, 01 Dec 2011 23:17:25 -0000 --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 30, 2011 at 05:20:17PM +0100, Olivier Houchard wrote: > On Wed, Nov 30, 2011 at 06:04:50PM +0200, Kostik Belousov wrote: > > > > I wonder why the waiting_threads stuff is needed at all. The cv cou= ld > > > > be woken up unconditionally everytime. What is the reason for the c= v_wait > > > > call in cdevpriv data destructor ? You cannot have a thread doing e= =2Eg. > > > > read on the file descriptor while destructor is run. > > > >=20 > > >=20 > > > What will prevent you from having a thread stuck in read(), while an = another=20 > > > one close() the fd ? > > >=20 > > Nothing, but file reference count goes to zero only after the thread > > stuck in read is unstuck. Cdevpriv destructor is run only when file > > reference count becomes zero, i.e. there can be no any accessing thread= s, > > and new accesses are impossible since file descriptors also own referen= ces > > on the file. >=20 > Right, I was a bit confused, this part can be removed. >=20 > Regards, >=20 > Olivier Here is a new version of the patch mostly reworked by Olivier, It doesn't duplicate anymore the devq, and fix all that have been spotted here previously. http://people.freebsd.org/~bapt/devctl_multi_open.diff bonus, it removes the needless giant lock regards, Bapt --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7YCwEACgkQ8kTtMUmk6ExLuACgttivMDuC+ZsXNQ2Kd4kPAPhm wiUAn1uXcrEk2gIZCW2ZH98/LUFexh2l =wL+Q -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 00:50:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F20101065673 for ; Fri, 2 Dec 2011 00:50:23 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 765388FC0A for ; Fri, 2 Dec 2011 00:50:22 +0000 (UTC) Received: by bkat2 with SMTP id t2so3554214bka.13 for ; Thu, 01 Dec 2011 16:50:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; bh=f4I5pEakn/PLF1jDETb3+JPj8OTDqA+ZFRLDhalynmI=; b=qfApGi4HnQqgxuH4ATS3wW2YGAAdy8OFHeDNNUyAsX8C16dehi6/vueEFWHa8W1qmp CV6CHWNw993s64L2lJpzSD5FE9vwOUvaYcm9uGkvKHYutwdPC820KguGD78EsmL+Yj8I c0aBJAeghzUgK68dEZ7yqiS62oowP/wohEMxE= Received: by 10.204.12.68 with SMTP id w4mr9726352bkw.31.1322787022104; Thu, 01 Dec 2011 16:50:22 -0800 (PST) Received: from ernst.jennejohn.org (p578E1F5F.dip.t-dialin.net. [87.142.31.95]) by mx.google.com with ESMTPS id iu9sm15264207bkc.0.2011.12.01.16.50.20 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Dec 2011 16:50:21 -0800 (PST) Date: Fri, 2 Dec 2011 01:50:19 +0100 From: Gary Jennejohn To: George Kontostanos Message-ID: <20111202015019.43f4e2a0@ernst.jennejohn.org> In-Reply-To: References: X-Mailer: Claws Mail 3.7.10 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: ahci in FreeBSD 9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 00:50:24 -0000 On Thu, 1 Dec 2011 21:31:18 +0200 George Kontostanos wrote: > Hi everyone, > > From my understanding as of 20110424 revision device ahci has been > integrated into kernel: > > ---------------- > It is possible to load devices ahci, ata, siis and mvs as modules, but > option ATA_CAM should remain in kernel configuration to make ata > module work as CAM driver supporting legacy ATA controllers. Device > ata still can be used in modular fashion > ....... > No kernel config options or code have been removed, so if a problem > arises, please report it and optionally revert to the old ATA stack. > In order to do it you can remove from the kernel config: > options ATA_CAM > device ahci > ---------------- > > Does this mean that loading ahci in loader.conf is useless ? > No, I load mine from there. It's not necessary to have "device ahci" in your kernel config file since the module will be generated and installed by default. This is what I have makeoptions MODULES_OVERRIDE="ahci linux linprocfs msdosfs pseudofs" ... #device ahci so it's obvious that I'm using only the module. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 01:04:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1B5F106566B; Fri, 2 Dec 2011 01:04:43 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1098E8FC08; Fri, 2 Dec 2011 01:04:42 +0000 (UTC) Received: by eaai12 with SMTP id i12so4072382eaa.13 for ; Thu, 01 Dec 2011 17:04:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JsFVwj2EcE1+1HeY2gSlE60cTEMAqlfJWH6CM2NMjWw=; b=AR//o1X3+c0YUtfjTeADu2D0w4tIuDKKWiZv7gJPVQK0hnmY+4T9n+sdew9ovHo1oN 8YDjfEvRchHMJcGil22j4mxRIciEkIBWsEUCdA58J3hAdMKla/vZICbjCqF/c9cZs65d gEZzKnyZclj2rLwflneUMhfxCqCqb7qeU8kWo= MIME-Version: 1.0 Received: by 10.227.206.129 with SMTP id fu1mr3851101wbb.22.1322787882030; Thu, 01 Dec 2011 17:04:42 -0800 (PST) Received: by 10.180.94.2 with HTTP; Thu, 1 Dec 2011 17:04:41 -0800 (PST) In-Reply-To: <4EC0EA00.8030608@FreeBSD.org> References: <4EB9C469.9070208@freebsd.org> <4EB9E6FE.3060102@freebsd.org> <4EBABAC1.2090003@freebsd.org> <4EC0EA00.8030608@FreeBSD.org> Date: Thu, 1 Dec 2011 20:04:41 -0500 Message-ID: From: Arnaud Lacombe To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]] 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, 02 Dec 2011 01:04:43 -0000 Hi, On Mon, Nov 14, 2011 at 5:14 AM, Andriy Gapon wrote: > on 14/11/2011 02:38 Arnaud Lacombe said the following: >> you (committers) > > I wonder how it would work out if you were made a committer and couldn't say > "you (committers)" any more... :-) > The real question is rather whether or not I would accept such a role, or better, would I ever be proposed such a role ? I doubt someone praising the Bazaar, openly challenging core and historical members, would fit in the Cathedral, even if my work is only ever gonna be in the `projects/' subdirectory. - Arnaud From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 02:05:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B40D6106564A for ; Fri, 2 Dec 2011 02:05:54 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 906D08FC1D for ; Fri, 2 Dec 2011 02:05:54 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.5/8.14.5) with ESMTP id pB225sNF004521; Thu, 1 Dec 2011 18:05:54 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.5/8.14.4/Submit) id pB225rsN004520; Thu, 1 Dec 2011 18:05:53 -0800 (PST) (envelope-from obrien) Date: Thu, 1 Dec 2011 18:05:53 -0800 From: "David O'Brien" To: Garrett Cooper Message-ID: <20111202020553.GA4444@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Garrett Cooper , freebsd-current@freebsd.org References: <201111291607.26546.jhb@freebsd.org> <20111201002515.GA50028@freebsd.org> <20111201014349.GA61475@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 9.99-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: Remove debug echo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@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: Fri, 02 Dec 2011 02:05:54 -0000 On Wed, Nov 30, 2011 at 05:59:33PM -0800, Garrett Cooper wrote: > On Wed, Nov 30, 2011 at 5:43 PM, Alexander Best wrote: > > On Wed Nov 30 11, Garrett Cooper wrote: > >> On Wed, Nov 30, 2011 at 4:25 PM, Alexander Best wrote: > >>     pmake sucks as far as diagnostic output is concerned when compared > >> with gmake. I'd rather not have to fish through with -j1 (if I'm lucky > >> and it's not a race) to determine what directory created the "Error > >> Code" output. With the printouts discussed here, at least you have a > >> chance at determining what the issue was. > >>     Maybe it's just me, but I like noisy builds -- otherwise the > >> amount of time I have to spend root-causing the issue becomes > >> expensive. [...] > Otherwise diagnosing issues becomes a PITA with -j > 1 (with pmake I > have to start using some serious grep'ing, and if I'm lucky I can find > the source of error). Well its a PITA mostly because we disabled Pmake's -j "job-markers" back in 1998 (r41151). If you build with 'make -v -j>1' you get much more debugable output. bmake (NetBSD's make) is even nicer in this regard. I was *amazed* when I joined $WORK and a '-j16' build was debugable. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 02:08:20 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80487106564A for ; Fri, 2 Dec 2011 02:08:20 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 5ACE48FC0A for ; Fri, 2 Dec 2011 02:08:20 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.5/8.14.5) with ESMTP id pB228CxO004569; Thu, 1 Dec 2011 18:08:12 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.5/8.14.4/Submit) id pB228BUj004568; Thu, 1 Dec 2011 18:08:11 -0800 (PST) (envelope-from obrien) Date: Thu, 1 Dec 2011 18:08:11 -0800 From: "David O'Brien" To: John Baldwin Message-ID: <20111202020811.GB4444@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, John Baldwin , Garrett Cooper , Alexander Best , Doug Barton , freebsd-current@freebsd.org, Warner Losh References: <201111291607.26546.jhb@freebsd.org> <201112011004.08762.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201112011004.08762.jhb@freebsd.org> X-Operating-System: FreeBSD 9.99-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Garrett Cooper , Alexander Best , Doug Barton , Warner Losh , freebsd-current@freebsd.org Subject: Re: Remove debug echo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@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: Fri, 02 Dec 2011 02:08:20 -0000 On Thu, Dec 01, 2011 at 10:04:08AM -0500, John Baldwin wrote: > I think this is useful, perhaps send it to harti@ or jilles@ for review? I'd like to get some NetBSD bmake maintainers POV too. We should reduce the needless diversion between the two makes. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 02:13:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2D6E106566C for ; Fri, 2 Dec 2011 02:13:52 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id BEB058FC12 for ; Fri, 2 Dec 2011 02:13:52 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.5/8.14.5) with ESMTP id pB22Dp24004666; Thu, 1 Dec 2011 18:13:52 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.5/8.14.4/Submit) id pB22DpJW004665; Thu, 1 Dec 2011 18:13:51 -0800 (PST) (envelope-from obrien) Date: Thu, 1 Dec 2011 18:13:51 -0800 From: "David O'Brien" To: Matt Mullins Message-ID: <20111202021351.GC4444@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Matt Mullins , Alexander Best , freebsd-current@freebsd.org References: <20111201112838.GA62127@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 9.99-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Alexander Best , freebsd-current@freebsd.org Subject: Re: stupid cp(1) behaviour X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@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: Fri, 02 Dec 2011 02:13:53 -0000 On Thu, Dec 01, 2011 at 11:35:50AM -0800, Matt Mullins wrote: > On Thu, Dec 1, 2011 at 3:28 AM, Alexander Best wrote: > > implement a new -N switch or so which isn't based on a file's > > existance, but a file's checksum. > > You can always use net/rsync, which does by default compare checksums. I don't believe that is true [anymore]: $ rsync --help rsync version 3.0.9 protocol version 30 Copyright (C) 1996-2011 by Andrew Tridgell, Wayne Davison, and others. [...] -c, --checksum skip based on checksum, not mod-time & size ... -I, --ignore-times don't skip files that match in size and mod-time --size-only skip files that match in size --modify-window=NUM compare mod-times with reduced accuracy -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 02:18:51 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E4F9106564A; Fri, 2 Dec 2011 02:18:51 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 805C28FC1C; Fri, 2 Dec 2011 02:18:50 +0000 (UTC) Received: by ggnk5 with SMTP id k5so3768769ggn.13 for ; Thu, 01 Dec 2011 18:18:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=drHO4nyOqE6kVVTIcXtp21pJMR+UGfI/IIkRLti2qhk=; b=snu6OP6mkuXaIT51aBznyL9VY9jtoIz9LJ6+pSIeVqkEu+Y2Sveitisr+/ROlnayyc xWcbeHkNCoxriMq/vIiNc5aVZMZ+ICNUg3umnYScMqIz8hwd2I1WdwjmvXXcELvkvmRP vtUgO5QMoQr4g0DY+oDtowqK1iFeqgKsaRMe0= MIME-Version: 1.0 Received: by 10.182.154.66 with SMTP id vm2mr1970039obb.52.1322792329811; Thu, 01 Dec 2011 18:18:49 -0800 (PST) Received: by 10.182.62.227 with HTTP; Thu, 1 Dec 2011 18:18:49 -0800 (PST) In-Reply-To: <20111202020811.GB4444@dragon.NUXI.org> References: <201111291607.26546.jhb@freebsd.org> <201112011004.08762.jhb@freebsd.org> <20111202020811.GB4444@dragon.NUXI.org> Date: Thu, 1 Dec 2011 18:18:49 -0800 Message-ID: From: Garrett Cooper To: obrien@freebsd.org, John Baldwin , Garrett Cooper , Alexander Best , Doug Barton , freebsd-current@freebsd.org, Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: Remove debug echo 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, 02 Dec 2011 02:18:51 -0000 On Thu, Dec 1, 2011 at 6:08 PM, David O'Brien wrote: > On Thu, Dec 01, 2011 at 10:04:08AM -0500, John Baldwin wrote: >> I think this is useful, perhaps send it to harti@ or jilles@ for review? > > I'd like to get some NetBSD bmake maintainers POV too. > We should reduce the needless diversion between the two makes. Agreed, but this is also a more extensive project. I just implemented the patch shown above because it makes pmake in FreeBSD match GNU make's behavior with printouts, which is a plus for people like me who have scripts that parse for errors messages like that. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 02:28:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 929DC106564A for ; Fri, 2 Dec 2011 02:28:22 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 5B4028FC15 for ; Fri, 2 Dec 2011 02:28:22 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.5/8.14.5) with ESMTP id pB21x2f1004365; Thu, 1 Dec 2011 17:59:02 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.5/8.14.4/Submit) id pB21x2AK004364; Thu, 1 Dec 2011 17:59:02 -0800 (PST) (envelope-from obrien) Date: Thu, 1 Dec 2011 17:59:02 -0800 From: "David O'Brien" To: Max Khon Message-ID: <20111202015902.GC4111@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Max Khon , Baptiste Daroussin , freebsd-current References: <20111129085946.GD6680@azathoth.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 9.99-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Baptiste Daroussin , freebsd-current Subject: Re: removing libreadline from base system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@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: Fri, 02 Dec 2011 02:28:22 -0000 On Tue, Nov 29, 2011 at 04:46:30PM +0700, Max Khon wrote: > This is a separate issue that I want to handle separately. I see no value in handling it separately. I either have a libreadline on my system or I don't. Again, "what problem are you trying to solve"? > The question is what to do with gdb & friends. Link it with libedit or > re-import bundled readline (that is shipped with gdb) and build/link it > only to gdb. > > I am inclined to do the former. Consider this an explicit request to do nothing to the base libreadline. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 02:28:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F31EE106566C for ; Fri, 2 Dec 2011 02:28:22 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id D2D328FC18 for ; Fri, 2 Dec 2011 02:28:22 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.5/8.14.5) with ESMTP id pB21pYaj004215; Thu, 1 Dec 2011 17:51:34 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.5/8.14.4/Submit) id pB21pXJ4004214; Thu, 1 Dec 2011 17:51:33 -0800 (PST) (envelope-from obrien) Date: Thu, 1 Dec 2011 17:51:33 -0800 From: "David O'Brien" To: Max Khon Message-ID: <20111202015133.GA4111@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Max Khon , freebsd-current References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 9.99-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current Subject: Re: WITHOUT_PROFILE=yes by default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@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: Fri, 02 Dec 2011 02:28:23 -0000 On Mon, Nov 28, 2011 at 05:38:20PM +0700, Max Khon wrote: > I would like to disable building profiled libraries by default. Opinions? On Tue, Nov 29, 2011 at 07:46:17PM +0000, Max Khon wrote: > Author: fjoe > Date: Tue Nov 29 19:46:17 2011 > New Revision: 228143 > URL: http://svn.freebsd.org/changeset/base/228143 > > Log: > Turn off profiled libs build by default. > Can be enabled back using WITH_PROFILE=yes in /etc/src.conf Wow, a single day of discussion in freebsd-current@ was sufficient to invert a 17 year default. I'd like to see the profile libs remain built by default in -CURRENT. If you like, add it to the list of things to disable on -STABLE creation. -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 02:28:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B5991065672 for ; Fri, 2 Dec 2011 02:28:23 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 0B2798FC19 for ; Fri, 2 Dec 2011 02:28:23 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.5/8.14.5) with ESMTP id pB21tcM8004292; Thu, 1 Dec 2011 17:55:38 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.5/8.14.4/Submit) id pB21tbv1004291; Thu, 1 Dec 2011 17:55:37 -0800 (PST) (envelope-from obrien) Date: Thu, 1 Dec 2011 17:55:37 -0800 From: "David O'Brien" To: Max Khon Message-ID: <20111202015537.GB4111@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Max Khon , freebsd-current References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 9.99-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current Subject: Re: removing libreadline from base system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@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: Fri, 02 Dec 2011 02:28:23 -0000 On Tue, Nov 29, 2011 at 12:02:23PM +0700, Max Khon wrote: > It is possible to build and link our in-tree gdb & friends with libedit > after r228114. > The remaining question is what to do with libreadline: > 1) just build & link gdb with libedit > OR > 2) re-import libreadline from gdb sources and build INTERNALLIB version of > it that is never installed and is linked only to gdb Max, What is the value in doing either? libreadline isn't infecting any non-GPL code turning into GPLv2. Some of use have fancy .input files, and quite frankly the vi mode of libedit still doesn't work quite the same as libreadline. If you go with (2) above, we'll still have *tons* of ports that want a libreadline, so we'll just end up growing a port of it and we'll wind up with a libreadline on the system anyway. > I am inclined to go for 1) but libedit may have (and has) incompatibilities > with libreadline. I'm inclined to DO NOTHING. -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 02:42:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D854B106564A for ; Fri, 2 Dec 2011 02:42:22 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 744DB8FC08 for ; Fri, 2 Dec 2011 02:42:21 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.4/8.14.4) with ESMTP id pB22fCKQ095529; Thu, 1 Dec 2011 20:41:13 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.4/8.14.4/Submit) id pB22fCNH095528; Thu, 1 Dec 2011 20:41:12 -0600 (CST) (envelope-from brooks) Date: Thu, 1 Dec 2011 20:41:12 -0600 From: Brooks Davis To: obrien@freebsd.org, Max Khon , freebsd-current Message-ID: <20111202024112.GC95365@lor.one-eyed-alien.net> References: <20111202015537.GB4111@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BQPnanjtCNWHyqYD" Content-Disposition: inline In-Reply-To: <20111202015537.GB4111@dragon.NUXI.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: removing libreadline from base system 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, 02 Dec 2011 02:42:22 -0000 --BQPnanjtCNWHyqYD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 01, 2011 at 05:55:37PM -0800, David O'Brien wrote: > On Tue, Nov 29, 2011 at 12:02:23PM +0700, Max Khon wrote: > > It is possible to build and link our in-tree gdb & friends with libedit > > after r228114. > > The remaining question is what to do with libreadline: > > 1) just build & link gdb with libedit > > OR > > 2) re-import libreadline from gdb sources and build INTERNALLIB version= of > > it that is never installed and is linked only to gdb >=20 > Max, > What is the value in doing either? >=20 > libreadline isn't infecting any non-GPL code turning into GPLv2. >=20 > Some of use have fancy .input files, and quite frankly the vi mode of > libedit still doesn't work quite the same as libreadline. >=20 > If you go with (2) above, we'll still have *tons* of ports that want a > libreadline, so we'll just end up growing a port of it and we'll wind up > with a libreadline on the system anyway. We are rapidly approaching the point where it will be practical to remove all GPL code from the base system (assuming we are willing to require external toolchains for some architectures) and a number of us are pushing to make this a reality for 10.0. If we have people willing to do the work now--as Max seems to be--then we might as well deal with the ports fallout from the removal of libreadline sooner rather than later. The existence of incompatibilities between libedit and libreadline probably does argue for option (2). -- Brooks --BQPnanjtCNWHyqYD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFO2DrIXY6L6fI4GtQRAtDEAKCuIh8SrQjTo+B6ONcniD+GTl5uugCguAaz pEvTJk240GcouZazejec2AE= =dPQu -----END PGP SIGNATURE----- --BQPnanjtCNWHyqYD-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 02:52:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED2A5106566B; Fri, 2 Dec 2011 02:52:40 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 54A708FC0C; Fri, 2 Dec 2011 02:52:39 +0000 (UTC) Received: by bkat2 with SMTP id t2so3694327bka.13 for ; Thu, 01 Dec 2011 18:52:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=bjsIwqi0n+ajdrBzS/FVIiy3gEuglUXznMmTaClzZJU=; b=krO+5Kiv//aL0ThD5+qU3nGvFdHb9hYBElOgANHrNLqSX9weSaBIQXJUGqyxvnxZOQ Kpt2PLbxr2yhziVRTvrLGuR8c+EBY4D2AoAjtCKv+EpUBq4X4cMQO5s0Z+5HHpobgaOo KgsdAPbmF1tSuidveomS2mfrVgywLhZ3u0IAs= Received: by 10.180.85.162 with SMTP id i2mr6666544wiz.22.1322792587152; Thu, 01 Dec 2011 18:23:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.70.196 with HTTP; Thu, 1 Dec 2011 18:22:36 -0800 (PST) In-Reply-To: References: <20111201112838.GA62127@freebsd.org> From: Eitan Adler Date: Thu, 1 Dec 2011 21:22:36 -0500 Message-ID: To: Matt Mullins Content-Type: text/plain; charset=UTF-8 Cc: Alexander Best , freebsd-current@freebsd.org Subject: Re: stupid cp(1) behaviour 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, 02 Dec 2011 02:52:41 -0000 On Thu, Dec 1, 2011 at 2:35 PM, Matt Mullins wrote: > On Thu, Dec 1, 2011 at 3:28 AM, Alexander Best wrote: >> implement a new -N switch or so which isn't based on a file's existance, but a >> file's checksum. > > You can always use net/rsync, which does by default compare checksums. sysutils/cpdup also does this. -- Eitan Adler From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 04:36:46 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D88A106564A; Fri, 2 Dec 2011 04:36:46 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9DA978FC15; Fri, 2 Dec 2011 04:36:45 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 53E2846B09; Thu, 1 Dec 2011 23:36:45 -0500 (EST) Received: from John-Baldwins-MacBook-Air.local (c-68-36-150-83.hsd1.nj.comcast.net [68.36.150.83]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D03B6B925; Thu, 1 Dec 2011 23:36:44 -0500 (EST) Message-ID: <4ED855E6.20207@FreeBSD.org> Date: Thu, 01 Dec 2011 23:36:54 -0500 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Andriy Gapon References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201112011349.50502.jhb@freebsd.org> <4ED7E6B0.30400@FreeBSD.org> <201112011553.34432.jhb@freebsd.org> <4ED7F4BC.3080206@FreeBSD.org> In-Reply-To: <4ED7F4BC.3080206@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 01 Dec 2011 23:36:44 -0500 (EST) Cc: freebsd-current@FreeBSD.org Subject: Re: Stop scheduler on panic 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, 02 Dec 2011 04:36:46 -0000 On 12/1/11 4:42 PM, Andriy Gapon wrote: > on 01/12/2011 22:53 John Baldwin said the following: >> On Thursday, December 01, 2011 3:42:24 pm Andriy Gapon wrote: >>> Returning to critical_exit, what do you think about the following patch? >>> I guess that it could be committed independently of / before the >>> SCHEDULER_STOPPED thing. >>> >>> commit ee3d1a04985e86911a68d854439ae8c5429b7bd5 >>> Author: Andriy Gapon >>> Date: Thu Dec 1 18:53:36 2011 +0200 >>> >>> critical_exit: ignore td_owepreempt if kdb_active >>> >>> calling mi_switch in such a context result in a recursion via >>> kdb_switch >>> >>> diff --git a/sys/kern/kern_switch.c b/sys/kern/kern_switch.c >>> index 93cbf7b..885dc22 100644 >>> --- a/sys/kern/kern_switch.c >>> +++ b/sys/kern/kern_switch.c >>> @@ -200,7 +200,7 @@ critical_exit(void) >>> >>> if (td->td_critnest == 1) { >>> td->td_critnest = 0; >>> - if (td->td_owepreempt) { >>> + if (td->td_owepreempt&& !kdb_active) { >>> td->td_critnest = 1; >>> thread_lock(td); >>> td->td_critnest--; >> >> I think this is fine, but I'd probably change this to SCHEDULER_STOPPED() >> in the SCHEDULER_STOPPED() patch. > > I don't understand why... What if kdb is entered for some other reason, not > because of panic? In that case SCHEDULER_STOPPED() would be false, but it is > still possible to find a way into mi_switch. > > The SCHEDULER_STOPPED patch adds this: > @@ -428,6 +428,8 @@ mi_switch(int flags, struct thread *newtd) > */ > if (kdb_active) > kdb_switch(); > + if (SCHEDULER_STOPPED()) > + return; > if (flags& SW_VOL) { > td->td_ru.ru_nvcsw++; > td->td_swvoltick = ticks; Ah, ok (I had thought SCHEDULER_STOPPED was going to always be true when kdb was active). But I think these two changes should cover critical_exit() ok. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 04:38:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A28C1065670 for ; Fri, 2 Dec 2011 04:38:23 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id BAC298FC25 for ; Fri, 2 Dec 2011 04:38:22 +0000 (UTC) Received: by ggnk5 with SMTP id k5so3890373ggn.13 for ; Thu, 01 Dec 2011 20:38:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.88.99 with SMTP id bf3mr1973325obb.73.1322800701941; Thu, 01 Dec 2011 20:38:21 -0800 (PST) Received: by 10.182.76.225 with HTTP; Thu, 1 Dec 2011 20:38:21 -0800 (PST) X-Originating-IP: [93.92.220.178] In-Reply-To: <20111202024112.GC95365@lor.one-eyed-alien.net> References: <20111202015537.GB4111@dragon.NUXI.org> <20111202024112.GC95365@lor.one-eyed-alien.net> Date: Fri, 2 Dec 2011 11:38:21 +0700 Message-ID: From: Max Khon To: Brooks Davis Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current Subject: Re: removing libreadline from base system 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, 02 Dec 2011 04:38:23 -0000 Brooks, On Fri, Dec 2, 2011 at 9:41 AM, Brooks Davis wrote: > What is the value in doing either? > > > > libreadline isn't infecting any non-GPL code turning into GPLv2. > > > > Some of use have fancy .input files, and quite frankly the vi mode of > > libedit still doesn't work quite the same as libreadline. > > > > If you go with (2) above, we'll still have *tons* of ports that want a > > libreadline, so we'll just end up growing a port of it and we'll wind up > > with a libreadline on the system anyway. > > We are rapidly approaching the point where it will be practical to > remove all GPL code from the base system (assuming we are willing to > require external toolchains for some architectures) and a number of us > are pushing to make this a reality for 10.0. If we have people willing > to do the work now--as Max seems to be--then we might as well deal with > the ports fallout from the removal of libreadline sooner rather than > later. > > The existence of incompatibilities between libedit and libreadline > probably does argue for option (2). Agree. I submitted the patch w/ INTERNALLIB for libreadline for 10.0 exp-run. Max From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 04:41:02 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F7CC1065688; Fri, 2 Dec 2011 04:41:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id A9A608FC16; Fri, 2 Dec 2011 04:41:01 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so3243994vcb.13 for ; Thu, 01 Dec 2011 20:41:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=DAqqoLUWjrEbybxOJiuXQMUgnFV+wf8DJ6i8EcgkIE8=; b=CJjVZfd9HDMj4IJnr2jaXPfBf1mzpge38+6VzYRGnVgzRk+pAaZfKcQE6FScrzQG0v z/Vch/dJGzJQNETjFmJtdQIxmLPS/wr1Jl7WHXSN83Fk7wOC8Qm3imAH0PKUVWekwScS 0lthRBUFJhfZ3LHCZ301G9fMY2UKTe7GQaP2g= MIME-Version: 1.0 Received: by 10.220.228.200 with SMTP id jf8mr1778641vcb.105.1322800860943; Thu, 01 Dec 2011 20:41:00 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.109.10 with HTTP; Thu, 1 Dec 2011 20:41:00 -0800 (PST) In-Reply-To: <20111202015133.GA4111@dragon.NUXI.org> References: <20111202015133.GA4111@dragon.NUXI.org> Date: Fri, 2 Dec 2011 12:41:00 +0800 X-Google-Sender-Auth: uYMvFLlqnDGd4GlPeyjueTZQ7Uo Message-ID: From: Adrian Chadd To: obrien@freebsd.org, Max Khon , freebsd-current Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: WITHOUT_PROFILE=yes by default 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, 02 Dec 2011 04:41:02 -0000 On 2 December 2011 09:51, David O'Brien wrote: > Wow, a single day of discussion in freebsd-current@ was sufficient to > invert a 17 year default. > > I'd like to see the profile libs remain built by default in -CURRENT. > > If you like, add it to the list of things to disable on -STABLE creation. It's easier to do that than go review/re-engineer bloated code. :) Adrian From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 04:53:12 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE6AB106564A; Fri, 2 Dec 2011 04:53:12 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 65C068FC0A; Fri, 2 Dec 2011 04:53:12 +0000 (UTC) Received: by ggnk5 with SMTP id k5so3903411ggn.13 for ; Thu, 01 Dec 2011 20:53:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.222.106 with SMTP id ql10mr2020527obc.53.1322801591795; Thu, 01 Dec 2011 20:53:11 -0800 (PST) Received: by 10.182.76.225 with HTTP; Thu, 1 Dec 2011 20:53:11 -0800 (PST) X-Originating-IP: [93.92.220.178] In-Reply-To: <20111202015902.GC4111@dragon.NUXI.org> References: <20111129085946.GD6680@azathoth.lan> <20111202015902.GC4111@dragon.NUXI.org> Date: Fri, 2 Dec 2011 11:53:11 +0700 Message-ID: From: Max Khon To: obrien@freebsd.org, Max Khon , Baptiste Daroussin , freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: removing libreadline from base system 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, 02 Dec 2011 04:53:12 -0000 David, On Fri, Dec 2, 2011 at 8:59 AM, David O'Brien wrote: > This is a separate issue that I want to handle separately. > > I see no value in handling it separately. I either have a libreadline on > my system or I don't. > What I meant is that this problem is not related to the original question but it will be analyzed/resolved before the commit (if it will ever happen). I am not saying that my sole intention is to remove libreadline from base system. I just picked an item from here http://wiki.freebsd.org/GPLinBase and will come up with the analysis. If it turns out that libreadline removal is impractical it will not be removed. Max From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 04:56:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA6C4106566B; Fri, 2 Dec 2011 04:56:32 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7C1A58FC0A; Fri, 2 Dec 2011 04:56:32 +0000 (UTC) Received: by ggnk5 with SMTP id k5so3906675ggn.13 for ; Thu, 01 Dec 2011 20:56:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.45.6 with SMTP id i6mr2033480obm.3.1322801791808; Thu, 01 Dec 2011 20:56:31 -0800 (PST) Received: by 10.182.76.225 with HTTP; Thu, 1 Dec 2011 20:56:31 -0800 (PST) X-Originating-IP: [93.92.220.178] In-Reply-To: <20111202015133.GA4111@dragon.NUXI.org> References: <20111202015133.GA4111@dragon.NUXI.org> Date: Fri, 2 Dec 2011 11:56:31 +0700 Message-ID: From: Max Khon To: obrien@freebsd.org, Max Khon , freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: WITHOUT_PROFILE=yes by default 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, 02 Dec 2011 04:56:33 -0000 David, On Fri, Dec 2, 2011 at 8:51 AM, David O'Brien wrote: On Mon, Nov 28, 2011 at 05:38:20PM +0700, Max Khon wrote: > > I would like to disable building profiled libraries by default. Opinions? > > On Tue, Nov 29, 2011 at 07:46:17PM +0000, Max Khon wrote: > > Author: fjoe > > Date: Tue Nov 29 19:46:17 2011 > > New Revision: 228143 > > URL: http://svn.freebsd.org/changeset/base/228143 > > > > Log: > > Turn off profiled libs build by default. > > Can be enabled back using WITH_PROFILE=yes in /etc/src.conf > > Wow, a single day of discussion in freebsd-current@ was sufficient to > invert a 17 year default. > You still failed to name a single compelling reason to leave profiled libs even in -CURRENT. And it sounds like we should not fix 17-year old bugs or things that are no longer of any practical use because they were implemented 17 years ago. I'd like to see the profile libs remain built by default in -CURRENT. > > If you like, add it to the list of things to disable on -STABLE creation. Max From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 05:32:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A0D41065688 for ; Fri, 2 Dec 2011 05:32:36 +0000 (UTC) (envelope-from grog@lemis.com) Received: from w3.lemis.com (w3.lemis.com [208.86.224.149]) by mx1.freebsd.org (Postfix) with ESMTP id EC5AE8FC0A for ; Fri, 2 Dec 2011 05:32:35 +0000 (UTC) Received: from dereel.lemis.com (1032.x.rootbsd.net [208.86.224.149]) by w3.lemis.com (Postfix) with ESMTP id 4ED393BB88; Fri, 2 Dec 2011 05:24:52 +0000 (UTC) Received: by dereel.lemis.com (Postfix, from userid 1004) id 05CE5DADEC; Fri, 2 Dec 2011 16:24:51 +1100 (EST) Date: Fri, 2 Dec 2011 16:24:51 +1100 From: Greg 'groggy' Lehey To: Matt Mullins Message-ID: <20111202052451.GA33231@dereel.lemis.com> References: <20111201112838.GA62127@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Organization: The FreeBSD Project Phone: +61-3-5346-1370 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: Alexander Best , freebsd-current@freebsd.org Subject: Re: stupid cp(1) behaviour 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, 02 Dec 2011 05:32:36 -0000 --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thursday, 1 December 2011 at 11:35:50 -0800, Matt Mullins wrote: > On Thu, Dec 1, 2011 at 3:28 AM, Alexander Best wrote: >> implement a new -N switch or so which isn't based on a file's >> existance, but a file's checksum. > > You can always use net/rsync, which does by default compare > checksums. FWIW, by default rsync only compares checksums by default if the file size or modification timestamps are different. If you want to always go by checksum, you need the -c (--checksum) option. Greg -- Sent from my desktop computer Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk7YYSIACgkQIubykFB6QiO7SQCgpwYyH8j4cdfDaK0NHQkgkOr+ MhQAn1xQ22O0Jw4Vku7qriJ4PgZ79t5o =K0Xe -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 05:37:51 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE2D61065670 for ; Fri, 2 Dec 2011 05:37:51 +0000 (UTC) (envelope-from grog@lemis.com) Received: from w3.lemis.com (w3.lemis.com [208.86.224.149]) by mx1.freebsd.org (Postfix) with ESMTP id 7F0EB8FC08 for ; Fri, 2 Dec 2011 05:37:51 +0000 (UTC) Received: from dereel.lemis.com (1032.x.rootbsd.net [208.86.224.149]) by w3.lemis.com (Postfix) with ESMTP id CD4EA3BB1B; Fri, 2 Dec 2011 05:22:11 +0000 (UTC) Received: by dereel.lemis.com (Postfix, from userid 1004) id 4D532DADFC; Fri, 2 Dec 2011 16:22:10 +1100 (EST) Date: Fri, 2 Dec 2011 16:22:10 +1100 From: Greg 'groggy' Lehey To: Gary Jennejohn Message-ID: <20111202052209.GA81424@dereel.lemis.com> References: <20111202015019.43f4e2a0@ernst.jennejohn.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline In-Reply-To: <20111202015019.43f4e2a0@ernst.jennejohn.org> User-Agent: Mutt/1.4.2.3i Organization: The FreeBSD Project Phone: +61-3-5346-1370 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: FreeBSD-Current , George Kontostanos Subject: Re: ahci in FreeBSD 9 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, 02 Dec 2011 05:37:51 -0000 --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Friday, 2 December 2011 at 1:50:19 +0100, Gary Jennejohn wrote: > On Thu, 1 Dec 2011 21:31:18 +0200 > George Kontostanos wrote: >> >> Does this mean that loading ahci in loader.conf is useless ? > > No, I load mine from there. It's not necessary to have "device ahci" > in your kernel config file since the module will be generated and > installed by default. JOOI, why? Greg -- Sent from my desktop computer Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk7YYIEACgkQIubykFB6QiMjMwCfW5rlfARnbAfXk22cWsY1YC3D S4UAoK+aEJ82txzLxPowJ4LIX/hiIqIO =Euz4 -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 05:57:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4365106566B; Fri, 2 Dec 2011 05:57:21 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 58D2A8FC12; Fri, 2 Dec 2011 05:57:21 +0000 (UTC) Received: by ggnk5 with SMTP id k5so3960632ggn.13 for ; Thu, 01 Dec 2011 21:57:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.45.6 with SMTP id i6mr2064052obm.3.1322805440806; Thu, 01 Dec 2011 21:57:20 -0800 (PST) Received: by 10.182.76.225 with HTTP; Thu, 1 Dec 2011 21:57:20 -0800 (PST) X-Originating-IP: [93.92.220.178] In-Reply-To: <20111202015537.GB4111@dragon.NUXI.org> References: <20111202015537.GB4111@dragon.NUXI.org> Date: Fri, 2 Dec 2011 12:57:20 +0700 Message-ID: From: Max Khon To: obrien@freebsd.org, Max Khon , freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: removing libreadline from base system 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, 02 Dec 2011 05:57:21 -0000 David, On Fri, Dec 2, 2011 at 8:55 AM, David O'Brien wrote: If you go with (2) above, we'll still have *tons* of ports that want a > libreadline, so we'll just end up growing a port of it and we'll wind up > with a libreadline on the system anyway. Then you need to define what base system is. We have much more ports that depend on libintl or libglib2 than libreadline. Should we add these libs to the base system too? Also, almost all ports require gmake and autotools to be built. Should we add them to the base system too? Max From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 06:33:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD8FE106566C; Fri, 2 Dec 2011 06:33:41 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 9ECEA8FC0C; Fri, 2 Dec 2011 06:33:41 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id pB26XfJ4088931; Thu, 1 Dec 2011 22:33:41 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id pB26Xf91088930; Thu, 1 Dec 2011 22:33:41 -0800 (PST) (envelope-from sgk) Date: Thu, 1 Dec 2011 22:33:41 -0800 From: Steve Kargl To: obrien@freebsd.org, Max Khon , freebsd-current Message-ID: <20111202063341.GA88903@troutmask.apl.washington.edu> References: <20111202015133.GA4111@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111202015133.GA4111@dragon.NUXI.org> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: WITHOUT_PROFILE=yes by default 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, 02 Dec 2011 06:33:41 -0000 On Thu, Dec 01, 2011 at 05:51:33PM -0800, David O'Brien wrote: > On Mon, Nov 28, 2011 at 05:38:20PM +0700, Max Khon wrote: > > I would like to disable building profiled libraries by default. Opinions? > > On Tue, Nov 29, 2011 at 07:46:17PM +0000, Max Khon wrote: > > Author: fjoe > > Date: Tue Nov 29 19:46:17 2011 > > New Revision: 228143 > > URL: http://svn.freebsd.org/changeset/base/228143 > > > > Log: > > Turn off profiled libs build by default. > > Can be enabled back using WITH_PROFILE=yes in /etc/src.conf > > Wow, a single day of discussion in freebsd-current@ was sufficient to > invert a 17 year default. > > I'd like to see the profile libs remain built by default in -CURRENT. > +1 In particular, many (most, all?) people running -current will have profiled libaries installed. These libraries will become stale/out-of-sync with the static and shared libraries as (if) changes are made to libc. -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 06:35:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85121106566C; Fri, 2 Dec 2011 06:35:13 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 643E98FC0C; Fri, 2 Dec 2011 06:35:13 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id pB26ZDVk088953; Thu, 1 Dec 2011 22:35:13 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id pB26ZDkk088952; Thu, 1 Dec 2011 22:35:13 -0800 (PST) (envelope-from sgk) Date: Thu, 1 Dec 2011 22:35:13 -0800 From: Steve Kargl To: Adrian Chadd Message-ID: <20111202063513.GB88903@troutmask.apl.washington.edu> References: <20111202015133.GA4111@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-current , Max Khon Subject: Re: WITHOUT_PROFILE=yes by default 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, 02 Dec 2011 06:35:13 -0000 On Fri, Dec 02, 2011 at 12:41:00PM +0800, Adrian Chadd wrote: > On 2 December 2011 09:51, David O'Brien wrote: > > > Wow, a single day of discussion in freebsd-current@ was sufficient to > > invert a 17 year default. > > > > I'd like to see the profile libs remain built by default in -CURRENT. > > > > If you like, add it to the list of things to disable on -STABLE creation. > > It's easier to do that than go review/re-engineer bloated code. :) > To what does "that" refer? -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 06:38:58 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 947691065670; Fri, 2 Dec 2011 06:38:58 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 35EA98FC0A; Fri, 2 Dec 2011 06:38:57 +0000 (UTC) Received: by ggnk5 with SMTP id k5so3998837ggn.13 for ; Thu, 01 Dec 2011 22:38:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.88.99 with SMTP id bf3mr2034186obb.73.1322807937474; Thu, 01 Dec 2011 22:38:57 -0800 (PST) Received: by 10.182.76.225 with HTTP; Thu, 1 Dec 2011 22:38:57 -0800 (PST) X-Originating-IP: [93.92.220.178] In-Reply-To: <20111202063341.GA88903@troutmask.apl.washington.edu> References: <20111202015133.GA4111@dragon.NUXI.org> <20111202063341.GA88903@troutmask.apl.washington.edu> Date: Fri, 2 Dec 2011 13:38:57 +0700 Message-ID: From: Max Khon To: Steve Kargl Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current Subject: Re: WITHOUT_PROFILE=yes by default 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, 02 Dec 2011 06:38:58 -0000 Steve, On Fri, Dec 2, 2011 at 1:33 PM, Steve Kargl < sgk@troutmask.apl.washington.edu> wrote: On Thu, Dec 01, 2011 at 05:51:33PM -0800, David O'Brien wrote: > > On Mon, Nov 28, 2011 at 05:38:20PM +0700, Max Khon wrote: > > > I would like to disable building profiled libraries by default. > Opinions? > > > > On Tue, Nov 29, 2011 at 07:46:17PM +0000, Max Khon wrote: > > > Author: fjoe > > > Date: Tue Nov 29 19:46:17 2011 > > > New Revision: 228143 > > > URL: http://svn.freebsd.org/changeset/base/228143 > > > > > > Log: > > > Turn off profiled libs build by default. > > > Can be enabled back using WITH_PROFILE=yes in /etc/src.conf > > > > Wow, a single day of discussion in freebsd-current@ was sufficient to > > invert a 17 year default. > > > > I'd like to see the profile libs remain built by default in -CURRENT. > > > > +1 > > In particular, many (most, all?) people running -current > will have profiled libaries installed. These libraries > will become stale/out-of-sync with the static and shared > libraries as (if) changes are made to libc. This is a completely different thing and is actually what ObsoleteFilesInc/OptionalObsoleteFiles.inc mechanism is for. Max From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 06:41:33 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 633EF106566B; Fri, 2 Dec 2011 06:41:33 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 42F448FC14; Fri, 2 Dec 2011 06:41:33 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id pB26fXxg088986; Thu, 1 Dec 2011 22:41:33 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id pB26fXKH088985; Thu, 1 Dec 2011 22:41:33 -0800 (PST) (envelope-from sgk) Date: Thu, 1 Dec 2011 22:41:33 -0800 From: Steve Kargl To: Max Khon Message-ID: <20111202064132.GC88903@troutmask.apl.washington.edu> References: <20111202015133.GA4111@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-current Subject: Re: WITHOUT_PROFILE=yes by default 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, 02 Dec 2011 06:41:33 -0000 On Fri, Dec 02, 2011 at 11:56:31AM +0700, Max Khon wrote: > David, > > On Fri, Dec 2, 2011 at 8:51 AM, David O'Brien wrote: > > On Mon, Nov 28, 2011 at 05:38:20PM +0700, Max Khon wrote: > > > I would like to disable building profiled libraries by default. Opinions? > > > > On Tue, Nov 29, 2011 at 07:46:17PM +0000, Max Khon wrote: > > > Author: fjoe > > > Date: Tue Nov 29 19:46:17 2011 > > > New Revision: 228143 > > > URL: http://svn.freebsd.org/changeset/base/228143 > > > > > > Log: > > > Turn off profiled libs build by default. > > > Can be enabled back using WITH_PROFILE=yes in /etc/src.conf > > > > Wow, a single day of discussion in freebsd-current@ was sufficient to > > invert a 17 year default. > > > > You still failed to name a single compelling reason to leave profiled libs > even in -CURRENT. > Having a set of profiled libraries in-sync with the static and shared libraries allows one to run the profiler on their code when someone changes a library and that change causes a dramatic change in the performance of one's code. PS: David was not complaining about "fixing a 17 year old bug". He was stating that a single day of discussion changing a 17 year old practice seems a little too brief. PPS: I was on work-related travel for the last 4 days, and only saw this discussion after you pulled the trigger. -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 07:00:03 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 56FA1106564A for ; Fri, 2 Dec 2011 07:00:03 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 5738714F825; Fri, 2 Dec 2011 06:59:59 +0000 (UTC) Message-ID: <4ED8776F.9060301@FreeBSD.org> Date: Thu, 01 Dec 2011 22:59:59 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Steve Kargl References: <20111202015133.GA4111@dragon.NUXI.org> <20111202064132.GC88903@troutmask.apl.washington.edu> In-Reply-To: <20111202064132.GC88903@troutmask.apl.washington.edu> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current , Max Khon Subject: Re: WITHOUT_PROFILE=yes by default 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, 02 Dec 2011 07:00:03 -0000 On 12/01/2011 22:41, Steve Kargl wrote: > Having a set of profiled libraries in-sync with the static > and shared libraries allows one to run the profiler on their > code when someone changes a library and that change causes > a dramatic change in the performance of one's code. And as Max pointed out in his OP, that only applies to a tiny fraction of our users, or even our developers. If you want to use them, turn the knob. > PS: David was not complaining about "fixing a 17 year old bug". > He was stating that a single day of discussion changing > a 17 year old practice seems a little too brief. If it's a good idea, it's a good idea no matter how many different ways we flog it. :) Doug -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 07:16:34 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AEE21065672; Fri, 2 Dec 2011 07:16:34 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 0976F8FC08; Fri, 2 Dec 2011 07:16:34 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.5/8.14.5) with ESMTP id pB27GXMv009890; Thu, 1 Dec 2011 23:16:33 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.5/8.14.4/Submit) id pB27GXxD009889; Thu, 1 Dec 2011 23:16:33 -0800 (PST) (envelope-from obrien) Date: Thu, 1 Dec 2011 23:16:33 -0800 From: "David O'Brien" To: Baptiste Daroussin Message-ID: <20111202071633.GD4444@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Baptiste Daroussin , freebsd-current@FreeBSD.org References: <20111125190137.GA4420@azathoth.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111125190137.GA4420@azathoth.lan> X-Operating-System: FreeBSD 9.99-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@FreeBSD.org Subject: Re: Upgrade contributed gperf, m4 and flex X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@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: Fri, 02 Dec 2011 07:16:34 -0000 On Fri, Nov 25, 2011 at 08:01:37PM +0100, Baptiste Daroussin wrote: > and last: upgrade flex to the latest upstream version (it will need the m4 > upgrade) while here I'll move back flex to contrib/ > patches can be found there: > http://people.freebsd.org/~bapt/flex-update.diff Hi Baptiste, I cannot tell from this what you are really doing. It would likely be best to keep the old history, so that would involve a 'svn move usr.bin/lex contrib/flex'. Additionally if flex is now considered to be 3rd-party code (signified by living in contrib/) it should be imported we into '$REPO/base/vendor'. These actions would give a different diff than that above. Do you have a diff that shows what the real changes to FreeBSD are? > I also plan to upgrade m4 syncing code from openbsd, taking code from netbsd > (improve gnu m4 compatibility). > http://people.freebsd.org/~bapt/update_m4_from_openbsd_and_netbsd.diff We don't seen to have '$REPO/base/vendor/OpenBSD/m4' as we likely should. How different is our usr.bin/m4 from OpenBSD's? > http://people.freebsd.org/~bapt/upgrade-gperf-to-3.0.3.diff I assume an import into '$REPO/base/vendor/gperf/' will happen first? ['$REPO/base/vendor/gperf/' needs to be "flattend out" first] thanks, -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 07:23:49 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A70DD1065670; Fri, 2 Dec 2011 07:23:49 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 859A08FC12; Fri, 2 Dec 2011 07:23:49 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id pB27NnXK089212; Thu, 1 Dec 2011 23:23:49 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id pB27NnLl089211; Thu, 1 Dec 2011 23:23:49 -0800 (PST) (envelope-from sgk) Date: Thu, 1 Dec 2011 23:23:49 -0800 From: Steve Kargl To: Doug Barton Message-ID: <20111202072349.GA89183@troutmask.apl.washington.edu> References: <20111202015133.GA4111@dragon.NUXI.org> <20111202064132.GC88903@troutmask.apl.washington.edu> <4ED8776F.9060301@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ED8776F.9060301@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current , Max Khon Subject: Re: WITHOUT_PROFILE=yes by default 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, 02 Dec 2011 07:23:49 -0000 On Thu, Dec 01, 2011 at 10:59:59PM -0800, Doug Barton wrote: > On 12/01/2011 22:41, Steve Kargl wrote: > > > Having a set of profiled libraries in-sync with the static > > and shared libraries allows one to run the profiler on their > > code when someone changes a library and that change causes > > a dramatic change in the performance of one's code. > > And as Max pointed out in his OP, that only applies to a tiny fraction > of our users, or even our developers. If you want to use them, turn the > knob. Not only do I want to use them, I do use use profiled libraries. All those changes to libm that I've submitted over the years have been run through the profile. More importantly, we are discussion freebsd-current. I would hope that the other developers profile their changes to system before committing. > > > PS: David was not complaining about "fixing a 17 year old bug". > > He was stating that a single day of discussion changing > > a 17 year old practice seems a little too brief. > > If it's a good idea, it's a good idea no matter how many different ways > we flog it. :) > I think it is a horrible idea. Perhaps, we should discuss the technical issues before you start yet another bikeshed (see your recent posts concerning the ports repo for your hypocricy). -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 07:33:41 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id A68BD1065675 for ; Fri, 2 Dec 2011 07:33:41 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id E372E1551F8; Fri, 2 Dec 2011 07:32:18 +0000 (UTC) Message-ID: <4ED87F02.3060601@FreeBSD.org> Date: Thu, 01 Dec 2011 23:32:18 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Steve Kargl References: <20111202015133.GA4111@dragon.NUXI.org> <20111202064132.GC88903@troutmask.apl.washington.edu> <4ED8776F.9060301@FreeBSD.org> <20111202072349.GA89183@troutmask.apl.washington.edu> In-Reply-To: <20111202072349.GA89183@troutmask.apl.washington.edu> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current , Max Khon Subject: Re: WITHOUT_PROFILE=yes by default 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, 02 Dec 2011 07:33:41 -0000 On 12/01/2011 23:23, Steve Kargl wrote: > On Thu, Dec 01, 2011 at 10:59:59PM -0800, Doug Barton wrote: >> On 12/01/2011 22:41, Steve Kargl wrote: >> >>> Having a set of profiled libraries in-sync with the static >>> and shared libraries allows one to run the profiler on their >>> code when someone changes a library and that change causes >>> a dramatic change in the performance of one's code. >> >> And as Max pointed out in his OP, that only applies to a tiny fraction >> of our users, or even our developers. If you want to use them, turn the >> knob. > > Not only do I want to use them, I do use use profiled libraries. > All those changes to libm that I've submitted over the years > have been run through the profile. I'm glad that you find them useful. How does changing the default affect your ability to do that? > More importantly, we are > discussion freebsd-current. I would hope that the other developers > profile their changes to system before committing. I'd be happy if our developers would stop breaking the build. >>> PS: David was not complaining about "fixing a 17 year old bug". >>> He was stating that a single day of discussion changing >>> a 17 year old practice seems a little too brief. >> >> If it's a good idea, it's a good idea no matter how many different ways >> we flog it. :) >> > > I think it is a horrible idea. Perhaps, we should discuss the > technical issues before you start yet another bikeshed (see > your recent posts concerning the ports repo for your hypocricy). Um, you did see the smiley, right? -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 07:34:34 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51F471065676; Fri, 2 Dec 2011 07:34:34 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id E30278FC19; Fri, 2 Dec 2011 07:34:33 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so3367105vbb.13 for ; Thu, 01 Dec 2011 23:34:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=YupGt/ChbrdgoUO9KzoLg6iIBURkgg8m8A17+ODBCGs=; b=HxGiNL6gmZRXoi4zvIqmSRAP4JMRzIxA7HEKhzknHs64+Nn527VWld5p63t3B2MUtw llApAbyYShVsEcD0zi6vczHrRCGTWaYGb3pehXSAXOBJwUDBcX8gGjbrxymORtmSKrSm rgy6/XD3x4oL1LDDi4o+sZN+HxkdpaJQkdNwM= MIME-Version: 1.0 Received: by 10.52.94.227 with SMTP id df3mr9084159vdb.51.1322811273112; Thu, 01 Dec 2011 23:34:33 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.109.10 with HTTP; Thu, 1 Dec 2011 23:34:33 -0800 (PST) In-Reply-To: <4ED87F02.3060601@FreeBSD.org> References: <20111202015133.GA4111@dragon.NUXI.org> <20111202064132.GC88903@troutmask.apl.washington.edu> <4ED8776F.9060301@FreeBSD.org> <20111202072349.GA89183@troutmask.apl.washington.edu> <4ED87F02.3060601@FreeBSD.org> Date: Fri, 2 Dec 2011 15:34:33 +0800 X-Google-Sender-Auth: NEXTqgyHTw5D9zT1dIx8cSvA1-Q Message-ID: From: Adrian Chadd To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current , Steve Kargl , Max Khon Subject: Re: WITHOUT_PROFILE=yes by default 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, 02 Dec 2011 07:34:34 -0000 Quick! Martinis for all conversation participants, stat! Adrian From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 08:17:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACAC7106564A for ; Fri, 2 Dec 2011 08:17:17 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 603288FC17 for ; Fri, 2 Dec 2011 08:17:17 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.5/8.14.5) with ESMTP id pB28HG4V072694; Fri, 2 Dec 2011 00:17:16 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.5/8.14.4/Submit) id pB28HGd0072592; Fri, 2 Dec 2011 00:17:16 -0800 (PST) (envelope-from obrien) Date: Fri, 2 Dec 2011 00:17:16 -0800 From: "David O'Brien" To: Brooks Davis Message-ID: <20111202081716.GA23789@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Brooks Davis , Max Khon , freebsd-current References: <20111202015537.GB4111@dragon.NUXI.org> <20111202024112.GC95365@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111202024112.GC95365@lor.one-eyed-alien.net> X-Operating-System: FreeBSD 9.99-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current , Max Khon Subject: Re: removing libreadline from base system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@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: Fri, 02 Dec 2011 08:17:17 -0000 On Thu, Dec 01, 2011 at 08:41:12PM -0600, Brooks Davis wrote: > On Thu, Dec 01, 2011 at 05:55:37PM -0800, David O'Brien wrote: > > On Tue, Nov 29, 2011 at 12:02:23PM +0700, Max Khon wrote: > > > It is possible to build and link our in-tree gdb & friends with libedit > > > after r228114. > > > The remaining question is what to do with libreadline: > > > 1) just build & link gdb with libedit > > > OR > > > 2) re-import libreadline from gdb sources and build INTERNALLIB version of > > > it that is never installed and is linked only to gdb > > > > Max, > > What is the value in doing either? > > > > libreadline isn't infecting any non-GPL code turning into GPLv2. > > > > Some of use have fancy .input files, and quite frankly the vi mode of > > libedit still doesn't work quite the same as libreadline. > > > > If you go with (2) above, we'll still have *tons* of ports that want a > > libreadline, so we'll just end up growing a port of it and we'll wind up > > with a libreadline on the system anyway. > > We are rapidly approaching the point where it will be practical to > remove all GPL code from the base system (assuming we are willing to > require external toolchains for some architectures) and a number of us > are pushing to make this a reality for 10.0. Agreed and known. If the application(s) using libreadline weren't already GPL I wouldn't have spoken up. When I added the libreadline compatibility to libedit, I changed all the non-GPL libreadline uses to libedit. > If we have people willing > to do the work now--as Max seems to be--then we might as well deal with > the ports fallout from the removal of libreadline sooner rather than > later. I guess this is the real agenda? To get ports to depend on an /usr/ports' version of libreadline? If so, can it please wait 6 months until we've gotten thru the current nightmare that /usr/ports is on FreeBSD-CURRENT? Until this November that most ports would not build on -current, one still cannot 'pkg_add -r' anything, etc... Right now, I don't think we need another thing different between FreeBSD pre-10 and 10 that will be a /usr/ports headache. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 08:26:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EACC106566C; Fri, 2 Dec 2011 08:26:49 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id C08088FC0C; Fri, 2 Dec 2011 08:26:48 +0000 (UTC) Received: by ggnk5 with SMTP id k5so4095060ggn.13 for ; Fri, 02 Dec 2011 00:26:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.139.4 with SMTP id qu4mr2155956obb.13.1322814408040; Fri, 02 Dec 2011 00:26:48 -0800 (PST) Received: by 10.182.76.225 with HTTP; Fri, 2 Dec 2011 00:26:48 -0800 (PST) X-Originating-IP: [93.92.220.178] In-Reply-To: <20111202081716.GA23789@dragon.NUXI.org> References: <20111202015537.GB4111@dragon.NUXI.org> <20111202024112.GC95365@lor.one-eyed-alien.net> <20111202081716.GA23789@dragon.NUXI.org> Date: Fri, 2 Dec 2011 15:26:48 +0700 Message-ID: From: Max Khon To: obrien@freebsd.org, Brooks Davis , Max Khon , freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: removing libreadline from base system 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, 02 Dec 2011 08:26:49 -0000 David, On Fri, Dec 2, 2011 at 3:17 PM, David O'Brien wrote: Agreed and known. If the application(s) using libreadline weren't > already GPL I wouldn't have spoken up. > > When I added the libreadline compatibility to libedit, I changed all the > non-GPL libreadline uses to libedit. Nope. You forgot heimdal stuff. > If we have people willing > > to do the work now--as Max seems to be--then we might as well deal with > > the ports fallout from the removal of libreadline sooner rather than > > later. > > I guess this is the real agenda? To get ports to depend on an > /usr/ports' version of libreadline? > Agenda is available here: http://wiki.freebsd.org/GPLinBase > If so, can it please wait 6 months until we've gotten thru the current > nightmare that /usr/ports is on FreeBSD-CURRENT? > > Until this November that most ports would not build on -current, one > still cannot 'pkg_add -r' anything, etc... > > Right now, I don't think we need another thing different between FreeBSD > pre-10 and 10 that will be a /usr/ports headache. I would let portmgr and others decide on how long will the transition take. There is a PR about libreadline removal from base. It is being worked on. Max From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 08:35:03 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52C42106564A; Fri, 2 Dec 2011 08:35:03 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 0DAE68FC14; Fri, 2 Dec 2011 08:35:02 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.5/8.14.5) with ESMTP id pB28Z2ce085825; Fri, 2 Dec 2011 00:35:02 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.5/8.14.4/Submit) id pB28Z2kb085824; Fri, 2 Dec 2011 00:35:02 -0800 (PST) (envelope-from obrien) Date: Fri, 2 Dec 2011 00:35:02 -0800 From: "David O'Brien" To: Max Khon Message-ID: <20111202083501.GA73959@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Max Khon , Doug Barton , Steve Kargl , freebsd-current@FreeBSD.org References: <20111202015133.GA4111@dragon.NUXI.org> <20111202064132.GC88903@troutmask.apl.washington.edu> <4ED8776F.9060301@FreeBSD.org> <20111202072349.GA89183@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111202072349.GA89183@troutmask.apl.washington.edu> X-Operating-System: FreeBSD 9.99-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@FreeBSD.org, Doug Barton , Steve Kargl Subject: Re: WITHOUT_PROFILE=yes by default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@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: Fri, 02 Dec 2011 08:35:03 -0000 On Fri, Dec 02, 2011 at 11:56:31AM +0700, Max Khon wrote: > You still failed to name a single compelling reason to leave profiled > libs even in -CURRENT. Sorry Joe, I don't think your reasoning is compelling. I'm sure you know how to stick "NO_PROFILE=true" in your /etc/src.conf. How far do you want to take this? By this reasoning we should set all the knobs to "NO" to speed up the build. I mean we're all competent code builders running FreeBSD-current and know how to enable knobs in /etc/src.conf. Is speeding up the build import important to you then the default base system being an comfortable featureful development environment? On Thu, Dec 01, 2011 at 11:23:49PM -0800, Steve Kargl wrote: > On Thu, Dec 01, 2011 at 10:59:59PM -0800, Doug Barton wrote: > > On 12/01/2011 22:41, Steve Kargl wrote: > > > > > Having a set of profiled libraries in-sync with the static > > > and shared libraries allows one to run the profiler on their > > > code when someone changes a library and that change causes > > > a dramatic change in the performance of one's code. > > > > And as Max pointed out in his OP, that only applies to a tiny fraction > > of our users, or even our developers. If you want to use them, turn the > > knob. > > Not only do I want to use them, I do use use profiled libraries. > All those changes to libm that I've submitted over the years > have been run through the profile. More importantly, we are > discussion freebsd-current. I would hope that the other developers > profile their changes to system before committing. Exactly! We want to *encourage* the use of profiling in development. Not make it harder. With out the profiled libs being readily available, it becomes yet another step to go thru and an impediment to quick performance checking. -- -- David (obrien@FreeBSD.org) P.S. Max, would you please turn off HTML mail when sending to FreeBSD mailing lists? Many of us use that as an indication of SPAM on these lists. I've missed your responses to me due to that. From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 08:43:58 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B5D9106564A for ; Fri, 2 Dec 2011 08:43:58 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 091088FC18 for ; Fri, 2 Dec 2011 08:43:57 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.5/8.14.5) with ESMTP id pB28hv49085915; Fri, 2 Dec 2011 00:43:57 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.5/8.14.4/Submit) id pB28hvKB085914; Fri, 2 Dec 2011 00:43:57 -0800 (PST) (envelope-from obrien) Date: Fri, 2 Dec 2011 00:43:57 -0800 From: "David O'Brien" To: Max Khon Message-ID: <20111202084357.GB85770@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Max Khon , freebsd-current References: <20111202015537.GB4111@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 9.99-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current Subject: Re: removing libreadline from base system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@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: Fri, 02 Dec 2011 08:43:58 -0000 On Fri, Dec 02, 2011 at 12:57:20PM +0700, Max Khon wrote: > On Fri, Dec 2, 2011 at 8:55 AM, David O'Brien wrote: > If you go with (2) above, we'll still have *tons* of ports that want a > > libreadline, so we'll just end up growing a port of it and we'll wind up > > with a libreadline on the system anyway. > > Then you need to define what base system is. Eh? Its the same definition has been for the past 17 years -- that which is in /usr/src. As long as there is a GPL consumer of libreadline in /usr/src, there is no benefit to kicking libreadline out of /usr/src. I understand the anti-GPL sentiment -- I've done my share over the years to help achieve a GPL-free FreeBSD. But until there is a debugger that is anywhere near as capable (and mature) as GDB, we'll have a few GPL bits in /usr/src. I see that as OK -- its is small and contained. Show me a non-GPL consumer of libreadline in /usr/src and I'll do everything I can to have it work with libedit. When I added the libreadline compatibility to libedit, I changed all the non-GPL libreadline uses I knew of to libedit. > We have much more ports that depend on libintl or libglib2 than > libreadline. Should we add these libs to the base system too? Please tell me what consumer of libintl or libglib2 we have in /usr/src. > Also, almost all ports require gmake and autotools to be built. Should we > add them to the base system too? You're now being quite ridiculous. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 08:59:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F5AD106564A; Fri, 2 Dec 2011 08:59:08 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id E299E8FC08; Fri, 2 Dec 2011 08:59:07 +0000 (UTC) Received: by ggnk5 with SMTP id k5so4129358ggn.13 for ; Fri, 02 Dec 2011 00:59:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.88.99 with SMTP id bf3mr2114136obb.73.1322816346671; Fri, 02 Dec 2011 00:59:06 -0800 (PST) Received: by 10.182.76.225 with HTTP; Fri, 2 Dec 2011 00:59:06 -0800 (PST) X-Originating-IP: [93.92.220.178] In-Reply-To: <20111202084357.GB85770@dragon.NUXI.org> References: <20111202015537.GB4111@dragon.NUXI.org> <20111202084357.GB85770@dragon.NUXI.org> Date: Fri, 2 Dec 2011 15:59:06 +0700 Message-ID: From: Max Khon To: obrien@freebsd.org, Max Khon , freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: removing libreadline from base system 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, 02 Dec 2011 08:59:08 -0000 David, On Fri, Dec 2, 2011 at 3:43 PM, David O'Brien wrote: > On Fri, Dec 02, 2011 at 12:57:20PM +0700, Max Khon wrote: > > On Fri, Dec 2, 2011 at 8:55 AM, David O'Brien > wrote: > > If you go with (2) above, we'll still have *tons* of ports that want a > > > libreadline, so we'll just end up growing a port of it and we'll wind > up > > > with a libreadline on the system anyway. > > > > Then you need to define what base system is. > > Eh? Its the same definition has been for the past 17 years -- that which > is in /usr/src. > > As long as there is a GPL consumer of libreadline in /usr/src, there is > no benefit to kicking libreadline out of /usr/src. > > I understand the anti-GPL sentiment -- I've done my share over the years > to help achieve a GPL-free FreeBSD. But until there is a debugger that > is anywhere near as capable (and mature) as GDB, we'll have a few GPL > bits in /usr/src. > > I see that as OK -- its is small and contained. > One of the suggested alternatives (that looks more viable to me now because of incompatibilities between libedit and libreadline) is to have libreadline as INTERNALLIB. So that it is not exposed outside of gdb build. So that if we ever decide to replace gdb with something else in the base all we have to do is to svn rm gdb and friends. In other words, I suggest to reduce the number of dependencies on base system libreadline to just base system gdb. E.g. we do not expose expat from our base system to the outside world because we do not want to have unnecessary dependencies between base and ports. Show me a non-GPL consumer of libreadline in /usr/src and I'll do > everything I can to have it work with libedit. > > When I added the libreadline compatibility to libedit, I changed all the > non-GPL libreadline uses I knew of to libedit. > > > > We have much more ports that depend on libintl or libglib2 than > > libreadline. Should we add these libs to the base system too? > > Please tell me what consumer of libintl or libglib2 we have in /usr/src. Your sentiment was about having libreadline port/package to be installed on almost every system. We already have such packages (libintl and libglib2) so there is nothing wrong with having libreadline as a port/package and it does not imply that we should have it installed with the base system. Max From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 09:21:15 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8757E106566B; Fri, 2 Dec 2011 09:21:15 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 25C0E8FC13; Fri, 2 Dec 2011 09:21:14 +0000 (UTC) Received: by ggnk5 with SMTP id k5so4156566ggn.13 for ; Fri, 02 Dec 2011 01:21:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.88.99 with SMTP id bf3mr2128880obb.73.1322817674193; Fri, 02 Dec 2011 01:21:14 -0800 (PST) Received: by 10.182.76.225 with HTTP; Fri, 2 Dec 2011 01:21:14 -0800 (PST) X-Originating-IP: [93.92.220.178] In-Reply-To: <20111202083501.GA73959@dragon.NUXI.org> References: <20111202015133.GA4111@dragon.NUXI.org> <20111202064132.GC88903@troutmask.apl.washington.edu> <4ED8776F.9060301@FreeBSD.org> <20111202072349.GA89183@troutmask.apl.washington.edu> <20111202083501.GA73959@dragon.NUXI.org> Date: Fri, 2 Dec 2011 16:21:14 +0700 Message-ID: From: Max Khon To: obrien@freebsd.org, Max Khon , Doug Barton , Steve Kargl , freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: WITHOUT_PROFILE=yes by default 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, 02 Dec 2011 09:21:15 -0000 David, On Fri, Dec 2, 2011 at 3:35 PM, David O'Brien wrote: > On Fri, Dec 02, 2011 at 11:56:31AM +0700, Max Khon wrote: >> You still failed to name a single compelling reason to leave profiled >> libs even in -CURRENT. > > Sorry Joe, I don't think your reasoning is compelling. > I'm sure you know how to stick "NO_PROFILE=3Dtrue" in your /etc/src.conf. > > How far do you want to take this? =C2=A0By this reasoning we should set a= ll > the knobs to "NO" to speed up the build. =C2=A0I mean we're all competent > code builders running FreeBSD-current and know how to enable knobs in > /etc/src.conf. > > Is speeding up the build import important to you then the default > base system being an comfortable featureful development environment? The most important thing is to have reasonable defaults. Having WITH_PROFILE by default does not seem to be a reasonable default to = me. Max From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 09:27:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F400106566C for ; Fri, 2 Dec 2011 09:27:36 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id DEEFE8FC0C for ; Fri, 2 Dec 2011 09:27:35 +0000 (UTC) Received: by ggnk5 with SMTP id k5so4164268ggn.13 for ; Fri, 02 Dec 2011 01:27:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.41.100 with SMTP id e4mr2190671obl.63.1322818054610; Fri, 02 Dec 2011 01:27:34 -0800 (PST) Received: by 10.182.76.225 with HTTP; Fri, 2 Dec 2011 01:27:34 -0800 (PST) X-Originating-IP: [93.92.220.178] Date: Fri, 2 Dec 2011 16:27:34 +0700 Message-ID: From: Max Khon To: freebsd-current Content-Type: text/plain; charset=UTF-8 Subject: CVS removal from the 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: Fri, 02 Dec 2011 09:27:36 -0000 Hello! I know that it is too early to speak about this, but I would like the dust in the mailing lists to settle down before real actions can be taken. As soon as ports/ (and doc/) are moved to SVN I do not see any compelling reasons for keeping CVS in the base system. Those who still use it for development can install ports/devel/opencvs (like all the src/ developers do for ports/devel/subversion/). In my opinion it is just another piece of bitrot that resides in the base system for no real reasons. Max From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 10:03:02 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3027F10657EA for ; Fri, 2 Dec 2011 10:03:02 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 757058FC18 for ; Fri, 2 Dec 2011 10:03:01 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA28545; Fri, 02 Dec 2011 12:02:58 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RWPxK-000AcN-BZ; Fri, 02 Dec 2011 12:02:58 +0200 Message-ID: <4ED8A251.3090609@FreeBSD.org> Date: Fri, 02 Dec 2011 12:02:57 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Arnaud Lacombe References: <4EB9C469.9070208@freebsd.org> <4EB9E6FE.3060102@freebsd.org> <4EBABAC1.2090003@freebsd.org> <4EC0EA00.8030608@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]] 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, 02 Dec 2011 10:03:02 -0000 on 02/12/2011 03:04 Arnaud Lacombe said the following: > Hi, > > On Mon, Nov 14, 2011 at 5:14 AM, Andriy Gapon wrote: >> on 14/11/2011 02:38 Arnaud Lacombe said the following: >>> you (committers) >> >> I wonder how it would work out if you were made a committer and couldn't say >> "you (committers)" any more... :-) >> > The real question is rather whether or not I would accept such a role, [*] That would be solely up to you. > or better, would I ever be proposed such a role ? That's up to you, current committers and core. > I doubt someone praising the Bazaar, openly challenging core and > historical members, would fit in the Cathedral, even if my work is > only ever gonna be in the `projects/' subdirectory. Your ideals are not that important if you are useful to the project, follow its policies and can get along with other developers. And challenging is a healthy thing as long as it stays constructive and focused on the code, not on the persons/personalities. [*] - I still think that what I asked was _the_ real question. If you want just to show off and keep pointing out how them committers are not worthy instead of nicely cooperating with them, then "you" and "committers" will always be apart, I'd guess. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 10:06:01 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E339106566B; Fri, 2 Dec 2011 10:06:01 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A811B8FC08; Fri, 2 Dec 2011 10:06:00 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA28589; Fri, 02 Dec 2011 12:05:59 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RWQ0E-000Acb-Rl; Fri, 02 Dec 2011 12:05:58 +0200 Message-ID: <4ED8A306.9020801@FreeBSD.org> Date: Fri, 02 Dec 2011 12:05:58 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: John Baldwin References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201112011349.50502.jhb@freebsd.org> <4ED7E6B0.30400@FreeBSD.org> <201112011553.34432.jhb@freebsd.org> <4ED7F4BC.3080206@FreeBSD.org> <4ED855E6.20207@FreeBSD.org> In-Reply-To: <4ED855E6.20207@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Stop scheduler on panic 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, 02 Dec 2011 10:06:01 -0000 on 02/12/2011 06:36 John Baldwin said the following: > Ah, ok (I had thought SCHEDULER_STOPPED was going to always be true when kdb was > active). But I think these two changes should cover critical_exit() ok. > I attempted to start a discussion about this a few times already :-) Should we treat kdb context the same as SCHEDULER_STOPPED context (in the current definition) ? That is, skip all locks in the same fashion? There are pros and contras. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 10:33:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 706FC106566B for ; Fri, 2 Dec 2011 10:33:29 +0000 (UTC) (envelope-from rik@inse.ru) Received: from ns.rikbsd.org (ns.rikbsd.org [95.143.215.27]) by mx1.freebsd.org (Postfix) with ESMTP id 2428E8FC12 for ; Fri, 2 Dec 2011 10:33:28 +0000 (UTC) Received: from [127.0.0.1] (wn.rikbsd.org [192.168.1.254]) by ns.rikbsd.org (Postfix) with ESMTPA id 6F6F45CE1D; Fri, 2 Dec 2011 11:17:33 +0000 (UTC) Message-ID: <4ED8A76E.2040401@inse.ru> Date: Fri, 02 Dec 2011 14:24:46 +0400 From: Roman Kurakin User-Agent: Thunderbird 2.0.0.24 (X11/20110906) MIME-Version: 1.0 To: Max Khon References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current Subject: Re: CVS removal from the 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: Fri, 02 Dec 2011 10:33:29 -0000 Max Khon wrote: > Hello! > > I know that it is too early to speak about this, but I would like the > dust in the mailing lists to settle down before real actions can be > taken. > > As soon as ports/ (and doc/) are moved to SVN I do not see any > compelling reasons for keeping CVS in the base system. > Those who still use it for development can install ports/devel/opencvs > (like all the src/ developers do for ports/devel/subversion/). > > In my opinion it is just another piece of bitrot that resides in the > base system for no real reasons. > By the way, there is one other use case of cvs. Personally I use cvs instead of cvsup to checkout whatever version I need to compile. It is very useful to have such ability out of the box without any extra ports. rik > Max > _______________________________________________ > 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 Fri Dec 2 10:54:26 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B2CC106566B for ; Fri, 2 Dec 2011 10:54:26 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id EF5EB8FC12 for ; Fri, 2 Dec 2011 10:54:25 +0000 (UTC) Received: by iakl21 with SMTP id l21so6338308iak.13 for ; Fri, 02 Dec 2011 02:54:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Fw70P037wGL58OCYh8N61n2vkLceIzXmDdFc0jqiXd0=; b=DJAzkOeRK3qOblZcglFwBe3w3k6Vq6YAZxBlFY0hA6J7JwOaZGnfGeKjKMl6SEavu0 pNhCRSlT2Ls3CHELL4wLlj6m6+1pjnaupiqyIsM5O2GwdKLqV3pjFBDgbrJNqx/vhKKn cAZUYS7G7MAd4m4RyeBU+zptXu2nXYcSouW1E= MIME-Version: 1.0 Received: by 10.231.46.136 with SMTP id j8mr2895047ibf.43.1322823265291; Fri, 02 Dec 2011 02:54:25 -0800 (PST) Received: by 10.231.15.7 with HTTP; Fri, 2 Dec 2011 02:54:25 -0800 (PST) In-Reply-To: <20111202052209.GA81424@dereel.lemis.com> References: <20111202015019.43f4e2a0@ernst.jennejohn.org> <20111202052209.GA81424@dereel.lemis.com> Date: Fri, 2 Dec 2011 12:54:25 +0200 Message-ID: From: George Kontostanos To: "Greg 'groggy' Lehey" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-Current Subject: Re: ahci in FreeBSD 9 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, 02 Dec 2011 10:54:26 -0000 On Fri, Dec 2, 2011 at 7:22 AM, Greg 'groggy' Lehey wrot= e: > On Friday, =A02 December 2011 at =A01:50:19 +0100, Gary Jennejohn wrote: >> On Thu, 1 Dec 2011 21:31:18 +0200 >> George Kontostanos wrote: >>> >>> Does this mean that loading ahci in loader.conf is useless ? >> >> No, I load mine from there. =A0It's not necessary to have "device ahci" >> in your kernel config file since the module will be generated and >> installed by default. > > JOOI, why? > > Greg > -- > Sent from my desktop computer > Finger grog@FreeBSD.org for PGP public key. > See complete headers for address and phone numbers. > This message is digitally signed. =A0If your Microsoft MUA reports > problems, please read http://tinyurl.com/broken-mua I was referring to GENERIC. Thanks --=20 George Kontostanos Aicom telecoms ltd http://www.barebsd.com From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 11:20:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E60451065670 for ; Fri, 2 Dec 2011 11:20:53 +0000 (UTC) (envelope-from mueller6727@bellsouth.net) Received: from fmailhost05.isp.att.net (fmailhost05.isp.att.net [207.115.11.55]) by mx1.freebsd.org (Postfix) with ESMTP id D35888FC0C for ; Fri, 2 Dec 2011 11:20:53 +0000 (UTC) Date: Fri, 2 Dec 2011 11:07:40 +0000 (GMT) X-Comment: Sending client does not conform to RFC822 minimum requirements X-Comment: Date has been added by Maillennium Received: from localhost (adsl-68-210-130-165.sdf.bellsouth.net[68.210.130.165]) by isp.att.net (frfwmhc05) with SMTP id <20111202110739H0500dtv65e>; Fri, 2 Dec 2011 11:07:40 +0000 X-Originating-IP: [68.210.130.165] From: "Thomas Mueller" To: freebsd-current@FreeBSD.org References: <20111130102439.E770E1065672@hub.freebsd.org> <201111301739.58889.hselasky@c2i.net> <20111201104937.B99B3106564A@hub.freebsd.org> <201112011753.05629.hselasky@c2i.net> Message-Id: <20111202112053.E60451065670@hub.freebsd.org> Cc: Hans Petter Selasky Subject: Re: man ugen error 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, 02 Dec 2011 11:20:54 -0000 ^ What version of FreeBSD do you run? Do you not have a ugen manpage? Can you run "man ugen"? ^ I have the manpages for ugen, and "man usb", also "man 4 usb", but no diff as such. ^ I guess ugen manpage failed to reflect becoming part of usb. ^ Tom > There is: > share/man/man4/ugen.4 > in FreeBSD 10-current. > It should be removed and added to old files. Could you make a patch for that? > --HPS I found /usr/share/man/man4/ugen.4.gz in FreeBSD 9.0-RC2. What needs to be patched? What file, where? Might it be /usr/src/ObsoleteFiles.inc ? I have extremely limited experience applying patches, no experience writing a patch. Where do I learn what and how to do? I might need to see some examples to get me started. Tom From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 11:24:33 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 837951065675 for ; Fri, 2 Dec 2011 11:24:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 0228C8FC14 for ; Fri, 2 Dec 2011 11:24:32 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pB2BOP4R040919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Dec 2011 13:24:25 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pB2BOPK3087114; Fri, 2 Dec 2011 13:24:25 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pB2BOPmt087113; Fri, 2 Dec 2011 13:24:25 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 2 Dec 2011 13:24:25 +0200 From: Kostik Belousov To: George Liaskos , freebsd-current Message-ID: <20111202112425.GQ50300@deviant.kiev.zoral.com.ua> References: <20111201212311.GA83353@zim.MIT.EDU> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cFl62NrZ2OkwVNR5" Content-Disposition: inline In-Reply-To: <20111201212311.GA83353@zim.MIT.EDU> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Subject: Re: r227487 breaks C++ programs that use __isthreaded 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, 02 Dec 2011 11:24:33 -0000 --cFl62NrZ2OkwVNR5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 01, 2011 at 04:23:11PM -0500, David Schultz wrote: > On Thu, Dec 01, 2011, George Liaskos wrote: > > Hello > >=20 > > One example is Google's tcmalloc [1], is this behaviour intended? > >=20 > > [1] http://code.google.com/p/google-perftools/source/browse/trunk/src/m= aybe_threads.cc >=20 > This code uses an unportable workaround for a bug that I believe > was fixed in r227999. Using internal names starting with a double > underscore isn't supported. >=20 > Separately, I'm still hoping that the namespace polution > introduced in r227487 gets fixed... I handled the pthread_once mess in libunwind without relying on __isthreaded, but I indeed only needed once working. http://git.savannah.gnu.org/cgit/libunwind.git/commit/?id=3D08077a4962c4e60= 6598f9f0e54b515b3c882be10 --cFl62NrZ2OkwVNR5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7YtWkACgkQC3+MBN1Mb4jWyACfQ84MixkR5i4LtCHXO2bNatRs kAIAoKAqibh+6WTLgQyXHVOZlTYqwe6l =nM1F -----END PGP SIGNATURE----- --cFl62NrZ2OkwVNR5-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 11:24:50 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F1081065702 for ; Fri, 2 Dec 2011 11:24:50 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id DD5F58FC0C for ; Fri, 2 Dec 2011 11:24:49 +0000 (UTC) Received: by bkat2 with SMTP id t2so4299313bka.13 for ; Fri, 02 Dec 2011 03:24:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; bh=YSkswqWuMJcHOr52Nke/WTcf9HLvtNcH2ai7iEpHoO4=; b=MuY7fL3fNTUspAVukkxEAex1zIBzCvdX97WsWPjV2kl0Ad6Dt4iw8Y39BTyMvlttbM yNpn6B/X9OqYa6Us6eWYBzEr242xXehvMx5AP95P8nynXFVhdJfFxVJqGFseDcTWhJGZ Q6UqcfYzTXwy6+h+pmFaRAKG/ERi9uFNHN+bU= Received: by 10.205.122.139 with SMTP id gg11mr10567176bkc.67.1322825088376; Fri, 02 Dec 2011 03:24:48 -0800 (PST) Received: from ernst.jennejohn.org (p578E1CB3.dip.t-dialin.net. [87.142.28.179]) by mx.google.com with ESMTPS id p13sm17016443bkd.4.2011.12.02.03.24.46 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Dec 2011 03:24:47 -0800 (PST) Date: Fri, 2 Dec 2011 12:24:45 +0100 From: Gary Jennejohn To: Greg 'groggy' Lehey Message-ID: <20111202122445.63feb786@ernst.jennejohn.org> In-Reply-To: <20111202052209.GA81424@dereel.lemis.com> References: <20111202015019.43f4e2a0@ernst.jennejohn.org> <20111202052209.GA81424@dereel.lemis.com> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , George Kontostanos Subject: Re: ahci in FreeBSD 9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 11:24:50 -0000 On Fri, 2 Dec 2011 16:22:10 +1100 Greg 'groggy' Lehey wrote: > On Friday, 2 December 2011 at 1:50:19 +0100, Gary Jennejohn wrote: > > On Thu, 1 Dec 2011 21:31:18 +0200 > > George Kontostanos wrote: > >> > >> Does this mean that loading ahci in loader.conf is useless ? > > > > No, I load mine from there. It's not necessary to have "device ahci" > > in your kernel config file since the module will be generated and > > installed by default. > > JOOI, why? > Habit. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 11:54:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35082106566B for ; Fri, 2 Dec 2011 11:54:53 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.freebsd.org (Postfix) with ESMTP id A6ABA8FC0A for ; Fri, 2 Dec 2011 11:54:52 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail11.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id pB2BsmIp020771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Dec 2011 22:54:49 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.5/8.14.4) with ESMTP id pB2BslYP027038; Fri, 2 Dec 2011 22:54:47 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.4/Submit) id pB2BskiP027037; Fri, 2 Dec 2011 22:54:47 +1100 (EST) (envelope-from peter) Date: Fri, 2 Dec 2011 22:54:46 +1100 From: Peter Jeremy To: Max Khon Message-ID: <20111202115446.GB25963@server.vk2pj.dyndns.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current Subject: Re: CVS removal from the 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: Fri, 02 Dec 2011 11:54:53 -0000 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Dec-02 16:27:34 +0700, Max Khon wrote: >I know that it is too early to speak about this, but I would like the >dust in the mailing lists to settle down before real actions can be >taken. I'd agree that it's still too early. >As soon as ports/ (and doc/) are moved to SVN I do not see any >compelling reasons for keeping CVS in the base system. There's more to it than just converting the repo from CVS to SVN - the "official" distribution and build systems have to be converted as well. The official build system for RELENG_8 remains CVS and (AFAIK) the "official" repo distribution system remains CVS-based (csup/cvsup) because there's no suitable SVN-based equivalent. IMHO, if those issues can be resolved in the near future then it might be possible to deprecate CVS before 9.1 and remove it in 10 but I suspect removal in 11 is a more realistic timeframe. >Those who still use it for development can install ports/devel/opencvs >(like all the src/ developers do for ports/devel/subversion/). Agreed. >In my opinion it is just another piece of bitrot that resides in the >base system for no real reasons. You are, of course, welcome to your opinion. I=20 --=20 Peter Jeremy --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7YvIYACgkQ/opHv/APuIeSsACfU8sVimNPgt4Mk7+Dbs7R44Yc fyQAnRaOMgJnJYE3f/h+xepFODA3dWBu =9bsS -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 11:55:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC27410656D1; Fri, 2 Dec 2011 11:55:35 +0000 (UTC) (envelope-from decke@FreeBSD.org) Received: from groupware.itac.at (groupware.itac.at [91.205.172.99]) by mx1.freebsd.org (Postfix) with ESMTP id 579948FC1A; Fri, 2 Dec 2011 11:55:35 +0000 (UTC) Received: from home.bluelife.at (93.104.210.95) by groupware.itac.at (Axigen) with (AES256-SHA encrypted) ESMTPSA id 396105; Fri, 2 Dec 2011 12:55:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 02 Dec 2011 12:55:35 +0100 From: Bernhard Froehlich To: Bernhard Froehlich In-Reply-To: <60ea779052f025798cf65e18c24b7b31@bluelife.at> References: <4ECF7440.4070300@entel.upc.edu> <20111126163343.GA9150@reks> <4ED6AEFE.4010106@FreeBSD.org> <201111301807.21351.jkim@FreeBSD.org> <60ea779052f025798cf65e18c24b7b31@bluelife.at> Message-ID: <47eb9f9b139dd8c59b050f1670a5f18d@bluelife.at> X-Sender: decke@FreeBSD.org User-Agent: Roundcube Webmail/0.6 X-AxigenSpam-Level: 1 X-CTCH-RefID: str=0001.0A0B0206.4ED8BCB6.013F,ss=1,fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown Cc: Gleb Kurtsou , Alan Cox , Gapon , freebsd-emulation@freebsd.org, FreeBSD current , Andriy, Jung-uk Kim Subject: Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464} 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, 02 Dec 2011 11:55:35 -0000 On 01.12.2011 09:37, Bernhard Froehlich wrote: > On 01.12.2011 00:07, Jung-uk Kim wrote: >> On Wednesday 30 November 2011 05:32 pm, Andriy Gapon wrote: >>> on 26/11/2011 18:33 Gleb Kurtsou said the following: >>> > Using new vm_page_alloc_contig() may be a better option here. >>> > Can't help with patch, stuck with pre Nov 15 CURRENT myself. >>> >>> on 27/11/2011 19:09 Alan Cox said the following: >>> > vm_page_alloc_contig() should be used instead. >>> >>> My take on the patch: >>> http://people.freebsd.org/~avg/vbox-10.patch >>> This is for head only, no check for FreeBSD version. >> >> Actually, I did the same thing last night: >> >> >> http://people.freebsd.org/~jkim/patch-src-VBox-Runtime-r0drv-freebsd-memobj-r0drv-freebsd.c >> >> This is a drop-in replacement for the patch. The only practical >> difference I see from yours is I used VM_ALLOC_INTERRUPT instead of >> VM_ALLOC_NORMAL. I believe this function may be used in interrupt >> context. FYI, I tried FreeBSD 9 and Fedora 10 without problem. > > Thanks a lot for both patches! Could you please as usual reply and > tell > me if it is okay to send this patch upstream under MIT license? > > Once there is some positive feedback I will commit both patches to > the ports tree. Patch has been send upstream: https://www.virtualbox.org/pipermail/vbox-dev/2011-December/004842.html -- Bernhard Froehlich http://www.bluelife.at/ From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 12:16:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0A011065678; Fri, 2 Dec 2011 12:16:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 4E22C8FC16; Fri, 2 Dec 2011 12:16:55 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pB2CGqav046935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Dec 2011 14:16:52 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pB2CGpKJ087380; Fri, 2 Dec 2011 14:16:51 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pB2CGpKn087379; Fri, 2 Dec 2011 14:16:51 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 2 Dec 2011 14:16:51 +0200 From: Kostik Belousov To: Baptiste Daroussin Message-ID: <20111202121651.GT50300@deviant.kiev.zoral.com.ua> References: <20111130124320.GA1449@azathoth.lan> <201111301005.11938.jhb@freebsd.org> <20111130154636.GX50300@deviant.kiev.zoral.com.ua> <20111130155521.GA52567@ci0.org> <20111130160450.GY50300@deviant.kiev.zoral.com.ua> <20111130162017.GA53362@ci0.org> <20111201231721.GA1669@azathoth.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="g/Ej6EIvgQPzAS7S" Content-Disposition: inline In-Reply-To: <20111201231721.GA1669@azathoth.lan> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org, imp@freebsd.org, Olivier Houchard Subject: Re: [patch] turning devctl into a "multiple openable" device 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, 02 Dec 2011 12:16:56 -0000 --g/Ej6EIvgQPzAS7S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 02, 2011 at 12:17:21AM +0100, Baptiste Daroussin wrote: > On Wed, Nov 30, 2011 at 05:20:17PM +0100, Olivier Houchard wrote: > > On Wed, Nov 30, 2011 at 06:04:50PM +0200, Kostik Belousov wrote: > > > > > I wonder why the waiting_threads stuff is needed at all. The cv c= ould > > > > > be woken up unconditionally everytime. What is the reason for the= cv_wait > > > > > call in cdevpriv data destructor ? You cannot have a thread doing= e.g. > > > > > read on the file descriptor while destructor is run. > > > > >=20 > > > >=20 > > > > What will prevent you from having a thread stuck in read(), while a= n another=20 > > > > one close() the fd ? > > > >=20 > > > Nothing, but file reference count goes to zero only after the thread > > > stuck in read is unstuck. Cdevpriv destructor is run only when file > > > reference count becomes zero, i.e. there can be no any accessing thre= ads, > > > and new accesses are impossible since file descriptors also own refer= ences > > > on the file. > >=20 > > Right, I was a bit confused, this part can be removed. > >=20 > > Regards, > >=20 > > Olivier >=20 > Here is a new version of the patch mostly reworked by Olivier, > It doesn't duplicate anymore the devq, and fix all that have been > spotted here previously. >=20 > http://people.freebsd.org/~bapt/devctl_multi_open.diff >=20 > bonus, it removes the needless giant lock I do not see a need in the use of refcount KPI, since it seems that all manipulations of n->refcount happen under global_devctl.mtx. Am I missed the place ? Releasing refcount on dev_event_info before using it in devread() allows other thread to free the memory while current thread still uses it. Stylish notes: mtx member in struct global_devctl has weird indentation; please move declaration of n2 into the declaration block of devdtor(); devread():should_free is initialized at the declaration site; devctl_queue_data_f() has stray empty line ater the while { loop line, while need blank line at the start of devctl_queue_data() is removed. --g/Ej6EIvgQPzAS7S Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7YwbMACgkQC3+MBN1Mb4jhcgCgusZFXAgV/4wimRsgTFNE2TPW NBMAnA/j975qxzQ2jOemnxsLe0RyEom/ =aMaX -----END PGP SIGNATURE----- --g/Ej6EIvgQPzAS7S-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 12:31:51 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68BE3106566B for ; Fri, 2 Dec 2011 12:31:51 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3050D8FC12 for ; Fri, 2 Dec 2011 12:31:50 +0000 (UTC) Received: by ggnp1 with SMTP id p1so78523ggn.13 for ; Fri, 02 Dec 2011 04:31:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.141.68 with SMTP id rm4mr2320196obb.23.1322829110438; Fri, 02 Dec 2011 04:31:50 -0800 (PST) Received: by 10.182.76.225 with HTTP; Fri, 2 Dec 2011 04:31:50 -0800 (PST) X-Originating-IP: [93.92.220.178] In-Reply-To: <20111202115446.GB25963@server.vk2pj.dyndns.org> References: <20111202115446.GB25963@server.vk2pj.dyndns.org> Date: Fri, 2 Dec 2011 19:31:50 +0700 Message-ID: From: Max Khon To: Peter Jeremy Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current Subject: Re: CVS removal from the 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: Fri, 02 Dec 2011 12:31:51 -0000 Peter, On Fri, Dec 2, 2011 at 6:54 PM, Peter Jeremy wrote: > On 2011-Dec-02 16:27:34 +0700, Max Khon wrote: >>I know that it is too early to speak about this, but I would like the >>dust in the mailing lists to settle down before real actions can be >>taken. > > I'd agree that it's still too early. > >>As soon as ports/ (and doc/) are moved to SVN I do not see any >>compelling reasons for keeping CVS in the base system. > > There's more to it than just converting the repo from CVS to SVN - > the "official" distribution and build systems have to be converted > as well. I presumed that "make release" will use svn for doing ports/doc checkouts after repos are converted. > The official build system for RELENG_8 remains CVS and > (AFAIK) the "official" repo distribution system remains CVS-based > (csup/cvsup) because there's no suitable SVN-based equivalent. I am not suggesting to change anything in RELENG_9 or even RELENG_8. And csup/cvsup != cvs. > IMHO, if those issues can be resolved in the near future then it > might be possible to deprecate CVS before 9.1 and remove it in 10 but > I suspect removal in 11 is a more realistic timeframe. Max From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 12:35:02 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6A821065673 for ; Fri, 2 Dec 2011 12:35:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5A5D68FC0C for ; Fri, 2 Dec 2011 12:35:02 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so3612944vcb.13 for ; Fri, 02 Dec 2011 04:35:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=c/XOfwq00ohBrflTty2wFuRvLPD8nyodRvIO+g9YlmI=; b=Ef654YWWKGlEHfRMHUyFtl88eeD7MS4uAl0xogNaRljZ36FjZXTlagNGPQBydyGzys epqan8jscabglxEfoCiGpZLCGvSHXUSKl3Gf7P4wjemPUxAv5z4BDDcamWKPq1ShyErg RH8PLvlY0euKW/3gyUqejywWfZ26XWPEFrLMM= MIME-Version: 1.0 Received: by 10.52.177.34 with SMTP id cn2mr9522256vdc.34.1322829301742; Fri, 02 Dec 2011 04:35:01 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.109.10 with HTTP; Fri, 2 Dec 2011 04:35:01 -0800 (PST) In-Reply-To: References: <20111202115446.GB25963@server.vk2pj.dyndns.org> Date: Fri, 2 Dec 2011 20:35:01 +0800 X-Google-Sender-Auth: HcnJ0ziY3eifCq2ee6Go3qzuq5Y Message-ID: From: Adrian Chadd To: Max Khon Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current , Peter Jeremy Subject: Re: CVS removal from the 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: Fri, 02 Dec 2011 12:35:02 -0000 I think you're missing the point a little. The point is, you have to keep in mind how comfortable people feel about things, and progress sometimes makes people uncomfortable. I think you should leave these changes bake for a while and let people get comfortable with the changing status quo. Adrian From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 13:54:05 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DC5D106566C for ; Fri, 2 Dec 2011 13:54:05 +0000 (UTC) (envelope-from db@db.net) Received: from diana.db.net (diana.db.net [66.113.102.10]) by mx1.freebsd.org (Postfix) with ESMTP id 57DAA8FC19 for ; Fri, 2 Dec 2011 13:54:05 +0000 (UTC) Received: from night.db.net (localhost [127.0.0.1]) by diana.db.net (Postfix) with ESMTP id 2C1F82282A; Fri, 2 Dec 2011 06:32:09 -0700 (MST) Received: by night.db.net (Postfix, from userid 1000) id 6BD5F5C5B; Fri, 2 Dec 2011 08:36:18 -0500 (EST) Date: Fri, 2 Dec 2011 08:36:18 -0500 From: Diane Bruce To: Max Khon Message-ID: <20111202133618.GA51215@night.db.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-current Subject: Re: CVS removal from the 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: Fri, 02 Dec 2011 13:54:05 -0000 On Fri, Dec 02, 2011 at 04:27:34PM +0700, Max Khon wrote: > Hello! ... > As soon as ports/ (and doc/) are moved to SVN I do not see any > compelling reasons for keeping CVS in the base system. Well. We _could_ replace it with SCCS. -- - db@FreeBSD.org db@db.net http://www.db.net/~db Why leave money to our children if we don't leave them the Earth? From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 14:21:11 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7D4B1065675 for ; Fri, 2 Dec 2011 14:21:11 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7356D8FC15 for ; Fri, 2 Dec 2011 14:21:11 +0000 (UTC) Received: by iakl21 with SMTP id l21so6738208iak.13 for ; Fri, 02 Dec 2011 06:21:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LMIQNTFQa9eYoEXG19sSS5ENXqhZvy7ND+Cby1SkemY=; b=mGnsmafGhv9gke/8H9VaeXH5pFodaa3mGm6Fa0ZoSRten7wzkCWLVCprrtTm8f3i/K FtmNYMnz53qtKzhlBAyUmQ9PH52wznz6baGjshnH5IJG0f1s2aBleTuQepmMijBDiVO4 EvJ71NFThFaw0DYWFaKgdlkd18Lm6W2T4s7ac= MIME-Version: 1.0 Received: by 10.231.8.143 with SMTP id h15mr3188896ibh.94.1322835670742; Fri, 02 Dec 2011 06:21:10 -0800 (PST) Received: by 10.42.48.7 with HTTP; Fri, 2 Dec 2011 06:21:10 -0800 (PST) In-Reply-To: <20111202133618.GA51215@night.db.net> References: <20111202133618.GA51215@night.db.net> Date: Fri, 2 Dec 2011 09:21:10 -0500 Message-ID: From: Mehmet Erol Sanliturk To: Diane Bruce Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current , Max Khon Subject: Re: CVS removal from the 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: Fri, 02 Dec 2011 14:21:11 -0000 On Fri, Dec 2, 2011 at 8:36 AM, Diane Bruce wrote: > On Fri, Dec 02, 2011 at 04:27:34PM +0700, Max Khon wrote: > > Hello! > ... > > As soon as ports/ (and doc/) are moved to SVN I do not see any > > compelling reasons for keeping CVS in the base system. > > Well. We _could_ replace it with SCCS. > > -- > - db@FreeBSD.org db@db.net http://www.db.net/~db > Why leave money to our children if we don't leave them the Earth? > http://en.wikipedia.org/wiki/Source_Code_Control_System Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 15:30:28 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF88D106564A; Fri, 2 Dec 2011 15:30:28 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4A9518FC0C; Fri, 2 Dec 2011 15:30:28 +0000 (UTC) Received: by dafa1 with SMTP id a1so2290085daf.13 for ; Fri, 02 Dec 2011 07:30:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yASxpo0EcjhZBU4pKPeuHn+g8rezAfnCzPx78tge2Rs=; b=r5iOJd5VcQbFZTD1tLwK3cPxUAWJQEdXKLNR6za0PwiDvJMlJlxgKdWI3oIvkKz69t UsBt3j3cf5QlVnGEM+VderHQhXDcro+rqNXi6NfWWJoqkO0lz0I3lnZH8Df0mSOWVkic 8VFCe9VYsi9e2rBL7mS9pWGKouaLZ2t8Iccfs= MIME-Version: 1.0 Received: by 10.68.21.68 with SMTP id t4mr3082498pbe.42.1322839827915; Fri, 02 Dec 2011 07:30:27 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.68.56.97 with HTTP; Fri, 2 Dec 2011 07:30:27 -0800 (PST) In-Reply-To: <4ED8A306.9020801@FreeBSD.org> References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201112011349.50502.jhb@freebsd.org> <4ED7E6B0.30400@FreeBSD.org> <201112011553.34432.jhb@freebsd.org> <4ED7F4BC.3080206@FreeBSD.org> <4ED855E6.20207@FreeBSD.org> <4ED8A306.9020801@FreeBSD.org> Date: Fri, 2 Dec 2011 07:30:27 -0800 X-Google-Sender-Auth: MCPjHI8l5gLHsOMM-3H_iLUOVwc Message-ID: From: mdf@FreeBSD.org To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Stop scheduler on panic 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, 02 Dec 2011 15:30:28 -0000 On Fri, Dec 2, 2011 at 2:05 AM, Andriy Gapon wrote: > on 02/12/2011 06:36 John Baldwin said the following: >> Ah, ok (I had thought SCHEDULER_STOPPED was going to always be true when= kdb was >> active). =A0But I think these two changes should cover critical_exit() o= k. >> > > I attempted to start a discussion about this a few times already :-) > Should we treat kdb context the same as SCHEDULER_STOPPED context (in the > current definition) ? =A0That is, skip all locks in the same fashion? > There are pros and contras. Does kdb pause all CPUs with an interrupt (NMI or regular interrupt, I can no longer remember...) when it enters? If so, then I'd say whether it enters via sysctl or panic doesn't matter. It's in a special environment where nothing else is running, which is what is needed for proper exploration of the machine (via breakpoint, for debugging a hang, etc). Maybe the question is, why wouldn't SCHEDULER_STOPPED be true regardless of how kdb is entered? Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 15:41:54 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E273E1065670; Fri, 2 Dec 2011 15:41:54 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B83CB8FC15; Fri, 2 Dec 2011 15:41:54 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 6D8B046B09; Fri, 2 Dec 2011 10:41:54 -0500 (EST) Received: from John-Baldwins-MacBook-Air.local (c-68-36-150-83.hsd1.nj.comcast.net [68.36.150.83]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D8A2CB91E; Fri, 2 Dec 2011 10:41:53 -0500 (EST) Message-ID: <4ED8F1C1.7010206@FreeBSD.org> Date: Fri, 02 Dec 2011 10:41:53 -0500 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Andriy Gapon References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201112011349.50502.jhb@freebsd.org> <4ED7E6B0.30400@FreeBSD.org> <201112011553.34432.jhb@freebsd.org> <4ED7F4BC.3080206@FreeBSD.org> <4ED855E6.20207@FreeBSD.org> <4ED8A306.9020801@FreeBSD.org> In-Reply-To: <4ED8A306.9020801@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 02 Dec 2011 10:41:54 -0500 (EST) Cc: freebsd-current@FreeBSD.org Subject: Re: Stop scheduler on panic 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, 02 Dec 2011 15:41:55 -0000 On 12/2/11 5:05 AM, Andriy Gapon wrote: > on 02/12/2011 06:36 John Baldwin said the following: >> Ah, ok (I had thought SCHEDULER_STOPPED was going to always be true when kdb was >> active). But I think these two changes should cover critical_exit() ok. >> > > I attempted to start a discussion about this a few times already :-) > Should we treat kdb context the same as SCHEDULER_STOPPED context (in the > current definition) ? That is, skip all locks in the same fashion? > There are pros and contras. kdb should not block on locks, no. Most debugger commands should not go near locks anyway unless they are intended to carefully modify the existing system in a safe manner (such as the 'kill' command which should only be using try locks and fail if it cannot safely post the signal). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 15:56:15 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D583106564A for ; Fri, 2 Dec 2011 15:56:15 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [IPv6:2607:fc50:1000:8200:216:3eff:fe2c:dc8f]) by mx1.freebsd.org (Postfix) with ESMTP id 6FF828FC12 for ; Fri, 2 Dec 2011 15:56:15 +0000 (UTC) Received: from [172.25.0.9] ([96.54.172.165]) (authenticated bits=0) by orthanc.ca (8.14.4/8.14.4) with ESMTP id pB2FuDLY069611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Dec 2011 07:56:14 -0800 (PST) (envelope-from lyndon@orthanc.ca) Date: Fri, 2 Dec 2011 07:56:13 -0800 (PST) From: Lyndon Nerenberg To: Max Khon In-Reply-To: Message-ID: References: <20111202015133.GA4111@dragon.NUXI.org> <20111202064132.GC88903@troutmask.apl.washington.edu> <4ED8776F.9060301@FreeBSD.org> <20111202072349.GA89183@troutmask.apl.washington.edu> <20111202083501.GA73959@dragon.NUXI.org> User-Agent: Alpine 1.10 (OSX 962 2008-03-14) Organization: The Frobozz Magic Homing Pigeon Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_PROFILE=yes by default 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, 02 Dec 2011 15:56:15 -0000 Max, I think a reasonable default is to continue building and shipping profiled libraries. This keeps FreeBSD consistent with every other UNIX variant released in the last (at least) 30 years. If you personally find profiled library builds slow you down too much, a one line addition to your /etc/src.conf solves the problem for you. Personally, I find building kernel modules to be intolerably slow, since I tend to run static linked kernels. I dealt with my preference by adding one line to my /etc/src.conf, not by submitting a patch request to disable the functionality in the builds. If you choose not to profile your code, that's entirely your choice. Breaking this functionality for everyone else who *does* make the effort to profile their code is a non-starter. --lyndon From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 16:23:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD687106564A for ; Fri, 2 Dec 2011 16:23:41 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8446C8FC13 for ; Fri, 2 Dec 2011 16:23:41 +0000 (UTC) Received: by ghbg20 with SMTP id g20so4547947ghb.13 for ; Fri, 02 Dec 2011 08:23:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=JHT1Y97S9pk2/EuxCuckMBVhMVEwWj6HLKNAUMvEYqY=; b=moK6BzNV0CX3Yot+LW3rqE/YBwsUxcp9VN0hS5a6ILIRVLXTybg1rrU2csa33FvC4W BsqpELxL+XIBQwqiP0OZuMso++B5M3rhcBFZuNyQuiwGwy2l1rg5dYZqm1AmhBlfAzDV Xg+jE4s/Nrjh9lVNnEo+4zYo8KALN4cBGilQo= MIME-Version: 1.0 Received: by 10.50.40.198 with SMTP id z6mr13710872igk.39.1322843020762; Fri, 02 Dec 2011 08:23:40 -0800 (PST) Sender: utisoft@gmail.com Received: by 10.231.12.139 with HTTP; Fri, 2 Dec 2011 08:23:40 -0800 (PST) Received: by 10.231.12.139 with HTTP; Fri, 2 Dec 2011 08:23:40 -0800 (PST) In-Reply-To: References: <20111202015133.GA4111@dragon.NUXI.org> <20111202064132.GC88903@troutmask.apl.washington.edu> <4ED8776F.9060301@FreeBSD.org> <20111202072349.GA89183@troutmask.apl.washington.edu> <20111202083501.GA73959@dragon.NUXI.org> Date: Fri, 2 Dec 2011 16:23:40 +0000 X-Google-Sender-Auth: JQov4V-E3osGlMGqP_chL-gHWIs Message-ID: From: Chris Rees To: Lyndon Nerenberg Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Max Khon Subject: Re: WITHOUT_PROFILE=yes by default 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, 02 Dec 2011 16:23:42 -0000 On 2 Dec 2011 15:57, "Lyndon Nerenberg" wrote: > > Max, I think a reasonable default is to continue building and shipping profiled libraries. This keeps FreeBSD consistent with every other UNIX variant released in the last (at least) 30 years. > > If you personally find profiled library builds slow you down too much, a one line addition to your /etc/src.conf solves the problem for you. > > Personally, I find building kernel modules to be intolerably slow, since I tend to run static linked kernels. I dealt with my preference by adding one line to my /etc/src.conf, not by submitting a patch request to disable the functionality in the builds. > > If you choose not to profile your code, that's entirely your choice. Breaking this functionality for everyone else who *does* make the effort to profile their code is a non-starter. Nothing is being broken here, just a default being changed. Users make up a greater proportion of our userbase than developers, so sensible defaults for them are more appropriate, right? Chris From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 16:33:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EE32106564A; Fri, 2 Dec 2011 16:33:06 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id D310D8FC14; Fri, 2 Dec 2011 16:33:05 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id pB2GX5i6074144; Fri, 2 Dec 2011 08:33:05 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id pB2GX4Hs074139; Fri, 2 Dec 2011 08:33:04 -0800 (PST) (envelope-from sgk) Date: Fri, 2 Dec 2011 08:33:04 -0800 From: Steve Kargl To: Chris Rees Message-ID: <20111202163304.GA43138@troutmask.apl.washington.edu> References: <20111202015133.GA4111@dragon.NUXI.org> <20111202064132.GC88903@troutmask.apl.washington.edu> <4ED8776F.9060301@FreeBSD.org> <20111202072349.GA89183@troutmask.apl.washington.edu> <20111202083501.GA73959@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, Lyndon Nerenberg , Max Khon Subject: Re: WITHOUT_PROFILE=yes by default 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, 02 Dec 2011 16:33:06 -0000 On Fri, Dec 02, 2011 at 04:23:40PM +0000, Chris Rees wrote: > On 2 Dec 2011 15:57, "Lyndon Nerenberg" wrote: >> >> >> If you choose not to profile your code, that's entirely your choice. >> Breaking this functionality for everyone else who *does* make the effort to >> profile their code is a non-starter. > > Nothing is being broken here, just a default being changed. > > Users make up a greater proportion of our userbase than developers, so > sensible defaults for them are more appropriate, right? Users don't run freebsd-current (unless they are willing to accept the inherit risks/warts associated with it). -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 16:34:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A15E31065673; Fri, 2 Dec 2011 16:34:59 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [IPv6:2607:fc50:1000:8200:216:3eff:fe2c:dc8f]) by mx1.freebsd.org (Postfix) with ESMTP id 7235F8FC16; Fri, 2 Dec 2011 16:34:59 +0000 (UTC) Received: from [172.25.0.9] ([96.54.172.165]) (authenticated bits=0) by orthanc.ca (8.14.4/8.14.4) with ESMTP id pB2GYvEF069770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Dec 2011 08:34:58 -0800 (PST) (envelope-from lyndon@orthanc.ca) Date: Fri, 2 Dec 2011 08:34:57 -0800 (PST) From: Lyndon Nerenberg To: Chris Rees In-Reply-To: Message-ID: References: <20111202015133.GA4111@dragon.NUXI.org> <20111202064132.GC88903@troutmask.apl.washington.edu> <4ED8776F.9060301@FreeBSD.org> <20111202072349.GA89183@troutmask.apl.washington.edu> <20111202083501.GA73959@dragon.NUXI.org> User-Agent: Alpine 1.10 (OSX 962 2008-03-14) Organization: The Frobozz Magic Homing Pigeon Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_PROFILE=yes by default 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, 02 Dec 2011 16:34:59 -0000 > Nothing is being broken here, just a default being changed. > > Users make up a greater proportion of our userbase than developers, so > sensible defaults for them are more appropriate, right? This has no impact on non-developer end-users. For "developer" end-users, this has a huge impact. You are forcing each and every developer who wants to profile their code to modify their /etc/src.conf and then 'make buildworld' solely because Max can't be bothered to add one line to his own /etc/src.conf. Developers who profile their code makes up a greater proportion of our userbase than 'Max', so sensible defaults for them are more appropriate, right? --lyndon From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 15:42:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57520106564A for ; Fri, 2 Dec 2011 15:42:44 +0000 (UTC) (envelope-from decke@bluelife.at) Received: from groupware.itac.at (groupware.itac.at [91.205.172.99]) by mx1.freebsd.org (Postfix) with ESMTP id DFC918FC08 for ; Fri, 2 Dec 2011 15:42:43 +0000 (UTC) Received: from home.bluelife.at (93.104.210.95) by groupware.itac.at (Axigen) with (AES256-SHA encrypted) ESMTPSA id 16FFF4; Fri, 2 Dec 2011 16:42:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 02 Dec 2011 16:42:43 +0100 From: Bernhard Froehlich To: Aryeh Friedman In-Reply-To: References: Message-ID: X-Sender: decke@bluelife.at User-Agent: Roundcube Webmail/0.6 X-AxigenSpam-Level: 1 X-CTCH-RefID: str=0001.0A0B020B.4ED8F1F2.0213,ss=1,fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-Mailman-Approved-At: Fri, 02 Dec 2011 16:41:37 +0000 Cc: FreeBSD Current Subject: Re: emulators/vitrualbox-ose fails on 9.0-PRERELEASE 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, 02 Dec 2011 15:42:44 -0000 On 26.11.2011 07:29, Aryeh Friedman wrote: > On Fri, Nov 25, 2011 at 3:39 AM, Bernhard Froehlich wrote: > >> On 25.11.2011 08:02, Aryeh Friedman wrote: >> >>> With the following installed and all the prerequest ports for vbox >>> when I >>> attempt to boot a default machine setup for freebsd guest OS >>> install it >>> fails immediately with: >>> >>>  Result Code: >>> >>> NS_ERROR_FAILURE (0x80004005) >>> >>> Component: >>> >>> Console >>> >>> Interface: >>> >>> IConsole {515e8e8d-f932-4d8e-9f32-79a52aead882} >>> >>> flosoft# uname -a >>> FreeBSD flosoft.no-ip.biz [1] 9.0-PRERELEASE FreeBSD >>> 9.0-PRERELEASE #4: Thu Nov >>> 24 22:45:48 EST 2011     >>> root@flosoft.no-ip.biz:/usr/obj/usr/src/sys/GENERIC >>> i386 >>> flosoft# kldstat >>> Id Refs Address    Size     Name >>>  1   27 0xc0400000 e59bd8   kernel >>>  2    1 0xc125a000 97a4     linprocfs.ko >>>  3    3 0xc1264000 2fcf4    linux.ko >>>  4    1 0xc1294000 ad87d0   nvidia.ko >>>  5    3 0xc7f12000 2d000    vboxdrv.ko >>>  6    1 0xc7f4b000 2000     vboxnetadp.ko >>>  7    1 0xc7f4d000 5000     vboxnetflt.ko >>>  8    2 0xc7f52000 b000     netgraph.ko >>>  9    1 0xc7f89000 4000     ng_ether.ko >> >> Sorry, but this information is not enough to have a clue what is >> going wrong. Please look at ~/Virtualbox VMs//logs/VBox.log (or kind >> of) and send the logfile. If that doesnt help please recompile the >> ports with the DEBUG option enabled. Thanks for the logfile and sorry that it took me so long to get back to you. I've found the following: 00:00:00.410 rtldrNativeLoad: dlopen('/usr/local/lib/virtualbox/VBoxREM32.so', RTLD_NOW | RTLD_LOCAL) failed: /usr/local/lib/virtualbox/VBoxREM32.so: Undefined symbol "atan2l" This tells that we have an undefined symbol in one of the shared objects but you are the first one to report this and 4.0.12 is used quite a lot so I guess that there is something strange going on in your system. Could you please try recompiling the virtualbox-ose port and see if this fixes it? -- Bernhard Fröhlich http://www.bluelife.at/ From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 16:42:31 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93D431065696 for ; Fri, 2 Dec 2011 16:42:31 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 26A2C8FC1A for ; Fri, 2 Dec 2011 16:42:30 +0000 (UTC) Received: by faak28 with SMTP id k28so3162725faa.13 for ; Fri, 02 Dec 2011 08:42:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ck/VAT2ccbKcRR10m/f63Y4n5I4Iw1VI1iVTxfuuL/g=; b=wigqukpF/dNm31yVjRs4E2hI4iC+9NtmfQlGx13hppcY8DLWqNfL4iuaQ92DUnxxiD pxWm9nF0j3bT3PpxnzZ9/6zNNE+eLF7SE057cddYIBi6sQkTOI7D6oR04A2dfUcoa7nv 7VaulN/GhXI1BwBYLjPSMX4jdkDUljJcLu9gQ= MIME-Version: 1.0 Received: by 10.180.90.6 with SMTP id bs6mr10447548wib.63.1322844150027; Fri, 02 Dec 2011 08:42:30 -0800 (PST) Received: by 10.180.101.102 with HTTP; Fri, 2 Dec 2011 08:42:29 -0800 (PST) In-Reply-To: References: <20111202015133.GA4111@dragon.NUXI.org> <20111202064132.GC88903@troutmask.apl.washington.edu> <4ED8776F.9060301@FreeBSD.org> <20111202072349.GA89183@troutmask.apl.washington.edu> <20111202083501.GA73959@dragon.NUXI.org> Date: Fri, 2 Dec 2011 11:42:29 -0500 Message-ID: From: Ryan Stone To: Lyndon Nerenberg Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, Max Khon Subject: Re: WITHOUT_PROFILE=yes by default 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, 02 Dec 2011 16:42:31 -0000 On Fri, Dec 2, 2011 at 10:56 AM, Lyndon Nerenberg wrote: > If you choose not to profile your code, that's entirely your choice. > Breaking this functionality for everyone else who *does* make the effort to > profile their code is a non-starter. Using profiled libs and gprof to profile your code has been obsolete in FreeBSD on i386 and amd64 for over six years now. From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 16:51:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78F3D1065670 for ; Fri, 2 Dec 2011 16:51:14 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [IPv6:2607:fc50:1000:8200:216:3eff:fe2c:dc8f]) by mx1.freebsd.org (Postfix) with ESMTP id 4C4DE8FC13 for ; Fri, 2 Dec 2011 16:51:14 +0000 (UTC) Received: from [172.25.0.9] ([96.54.172.165]) (authenticated bits=0) by orthanc.ca (8.14.4/8.14.4) with ESMTP id pB2GpCXM069827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 2 Dec 2011 08:51:13 -0800 (PST) (envelope-from lyndon@orthanc.ca) Date: Fri, 2 Dec 2011 08:51:12 -0800 (PST) From: Lyndon Nerenberg To: freebsd-current@freebsd.org In-Reply-To: <20111202083501.GA73959@dragon.NUXI.org> Message-ID: References: <20111202015133.GA4111@dragon.NUXI.org> <20111202064132.GC88903@troutmask.apl.washington.edu> <4ED8776F.9060301@FreeBSD.org> <20111202072349.GA89183@troutmask.apl.washington.edu> <20111202083501.GA73959@dragon.NUXI.org> User-Agent: Alpine 1.10 (OSX 962 2008-03-14) Organization: The Frobozz Magic Homing Pigeon Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: WITHOUT_PROFILE=yes by default 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, 02 Dec 2011 16:51:14 -0000 Something else I forgot to mention ... The point of -CURRENT is to make sure everything works before it becomes -STABLE and -RELEASE. Not building significant components of the system ensures those components don't get tested. This includes the actual build process, as well as the underlying profiling functionality. As a FreeBSD developer, you eat the cost of compiling everything. As a FreeBSD developer, if you are concentrating on a specific area at a particular time, turning off un-related parts of the build might speed things up for you. As a FreeBSD developer, you know how to do that. --lyndon From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 16:52:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5231B1065679 for ; Fri, 2 Dec 2011 16:52:49 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [IPv6:2607:fc50:1000:8200:216:3eff:fe2c:dc8f]) by mx1.freebsd.org (Postfix) with ESMTP id 22DE18FC20 for ; Fri, 2 Dec 2011 16:52:49 +0000 (UTC) Received: from [172.25.0.9] ([96.54.172.165]) (authenticated bits=0) by orthanc.ca (8.14.4/8.14.4) with ESMTP id pB2Gqljk069834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Dec 2011 08:52:48 -0800 (PST) (envelope-from lyndon@orthanc.ca) Date: Fri, 2 Dec 2011 08:52:47 -0800 (PST) From: Lyndon Nerenberg To: Ryan Stone In-Reply-To: Message-ID: References: <20111202015133.GA4111@dragon.NUXI.org> <20111202064132.GC88903@troutmask.apl.washington.edu> <4ED8776F.9060301@FreeBSD.org> <20111202072349.GA89183@troutmask.apl.washington.edu> <20111202083501.GA73959@dragon.NUXI.org> User-Agent: Alpine 1.10 (OSX 962 2008-03-14) Organization: The Frobozz Magic Homing Pigeon Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_PROFILE=yes by default 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, 02 Dec 2011 16:52:49 -0000 > Using profiled libs and gprof to profile your code has been obsolete > in FreeBSD on i386 and amd64 for over six years now. Funny, it still seems to work on my systems. From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 16:56:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D2F8106566C for ; Fri, 2 Dec 2011 16:56:23 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id D3DE78FC18 for ; Fri, 2 Dec 2011 16:56:22 +0000 (UTC) Received: by iakl21 with SMTP id l21so7028250iak.13 for ; Fri, 02 Dec 2011 08:56:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hmO1DXjFcXWv4/Dw4Y7htBiVDE1ZYABHDMLIyxhHFBI=; b=g4h7UY09So0MRn5hI92WCpinMh/9RQnF0eIsVaE0MFkq0ykYPLOG0neSPAQrpWilR/ /CDkSQ4n+5Xc7DbwImiVgxWW0Wiftl+V9ZeasXVxw+HJIFK/lGcnErCTFjXB3GDP6439 k/CSzgpPaZBYudyJFB24F+gx1NB/yb2UF+PE4= MIME-Version: 1.0 Received: by 10.231.28.28 with SMTP id k28mr3184593ibc.61.1322844982271; Fri, 02 Dec 2011 08:56:22 -0800 (PST) Received: by 10.231.12.139 with HTTP; Fri, 2 Dec 2011 08:56:22 -0800 (PST) Received: by 10.231.12.139 with HTTP; Fri, 2 Dec 2011 08:56:22 -0800 (PST) In-Reply-To: References: <20111202015133.GA4111@dragon.NUXI.org> <20111202064132.GC88903@troutmask.apl.washington.edu> <4ED8776F.9060301@FreeBSD.org> <20111202072349.GA89183@troutmask.apl.washington.edu> <20111202083501.GA73959@dragon.NUXI.org> Date: Fri, 2 Dec 2011 16:56:22 +0000 Message-ID: From: Chris Rees To: Lyndon Nerenberg Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Ryan Stone Subject: Re: WITHOUT_PROFILE=yes by default 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, 02 Dec 2011 16:56:23 -0000 On 2 Dec 2011 16:54, "Lyndon Nerenberg" wrote: >> >> Using profiled libs and gprof to profile your code has been obsolete >> in FreeBSD on i386 and amd64 for over six years now. > > > Funny, it still seems to work on my systems. > > I wonder if you're either not reading these emails properly or deliberately misrepresenting what people have said. Obsolete does not mean it doesn't work. Chris From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 17:07:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 655161065675 for ; Fri, 2 Dec 2011 17:07:04 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [IPv6:2607:fc50:1000:8200:216:3eff:fe2c:dc8f]) by mx1.freebsd.org (Postfix) with ESMTP id 33C2F8FC12 for ; Fri, 2 Dec 2011 17:07:04 +0000 (UTC) Received: from [172.25.0.9] ([96.54.172.165]) (authenticated bits=0) by orthanc.ca (8.14.4/8.14.4) with ESMTP id pB2H72PT069892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Dec 2011 09:07:03 -0800 (PST) (envelope-from lyndon@orthanc.ca) Date: Fri, 2 Dec 2011 09:07:02 -0800 (PST) From: Lyndon Nerenberg To: Chris Rees In-Reply-To: Message-ID: References: <20111202015133.GA4111@dragon.NUXI.org> <20111202064132.GC88903@troutmask.apl.washington.edu> <4ED8776F.9060301@FreeBSD.org> <20111202072349.GA89183@troutmask.apl.washington.edu> <20111202083501.GA73959@dragon.NUXI.org> User-Agent: Alpine 1.10 (OSX 962 2008-03-14) Organization: The Frobozz Magic Homing Pigeon Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_PROFILE=yes by default 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, 02 Dec 2011 17:07:04 -0000 > Obsolete does not mean it doesn't work. No, these days 'obsolete' seems to mean 'it does not have a sexy Flash-driven web GUI.' Profiling is a simple basic tool that makes it easy to quickly find code execution hot-spots. It's not dtrace, or any other plethora of tools that do a more extensive job of profiling. But it's also a tool that is universally available to developers. Or was ... If you don't like it, don't use it. But don't turn that into an excuse to remove the functionality from the rest of us. If you really think profiling is truly useless in this day and age, the proposal should be to eradicate it from the system entirely. --lyndon From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 17:18:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01698106566B; Fri, 2 Dec 2011 17:18:37 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0078C8FC1C; Fri, 2 Dec 2011 17:18:35 +0000 (UTC) Received: by wgbdr11 with SMTP id dr11so1547657wgb.31 for ; Fri, 02 Dec 2011 09:18:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=viFy2skkGPD1cV+TX+utZX7Gs6sNbqsQj113vHLUSkw=; b=hyJU6y16Mpuc/mTi4rToTi8yz8WqYk93r9JdfsYHOKU9DKQ7OoZhxffB12dEmY1B5T iZsilSDXFR7jW3e0dNeFUFxP3I9HOEBTd2f1nYzHSTStLYbcHWfHaM/EgM1to6M58mEf hdALNi2GNKWFT0BhJYB311bbg+GTNoUXhpnlY= MIME-Version: 1.0 Received: by 10.227.58.17 with SMTP id e17mr1901153wbh.12.1322846314982; Fri, 02 Dec 2011 09:18:34 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.47.211 with HTTP; Fri, 2 Dec 2011 09:18:34 -0800 (PST) In-Reply-To: <4ED8F1C1.7010206@FreeBSD.org> References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201112011349.50502.jhb@freebsd.org> <4ED7E6B0.30400@FreeBSD.org> <201112011553.34432.jhb@freebsd.org> <4ED7F4BC.3080206@FreeBSD.org> <4ED855E6.20207@FreeBSD.org> <4ED8A306.9020801@FreeBSD.org> <4ED8F1C1.7010206@FreeBSD.org> Date: Fri, 2 Dec 2011 18:18:34 +0100 X-Google-Sender-Auth: joRi79j2-FJAqkOXVNWfbFg6nlo Message-ID: From: Attilio Rao To: John Baldwin , Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: Stop scheduler on panic 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, 02 Dec 2011 17:18:37 -0000 2011/12/2 John Baldwin : > On 12/2/11 5:05 AM, Andriy Gapon wrote: >> >> on 02/12/2011 06:36 John Baldwin said the following: >>> >>> Ah, ok (I had thought SCHEDULER_STOPPED was going to always be true whe= n >>> kdb was >>> active). =C2=A0But I think these two changes should cover critical_exit= () ok. >>> >> >> I attempted to start a discussion about this a few times already :-) >> Should we treat kdb context the same as SCHEDULER_STOPPED context (in th= e >> current definition) ? =C2=A0That is, skip all locks in the same fashion? >> There are pros and contras. > > > kdb should not block on locks, no. =C2=A0Most debugger commands should no= t go > near locks anyway unless they are intended to carefully modify the existi= ng > system in a safe manner (such as the 'kill' command which should only be > using try locks and fail if it cannot safely post the signal). The biggest problem to KDB as the same as panic is that doing proper 'continue' is impossible. One of the features of the 'skip-locking' path is that it doesn't take into account fast locking paths, where sometimes the lock can succeed and other fails and you don't know about them. Also the restarted CPUs can find corrupted datas (as they can be arbitrarely updated), I'm sure it is too much panic prone. BTW, I'm waiting for the details to settle (including the patch we have been discussing internally about binding to CPU0 during ACPI shutdown) before to read the whole thread and start a proper review, would it be possible to have an almost-final version of the patch? Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 18:12:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42270106564A for ; Fri, 2 Dec 2011 18:12:44 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id C33CE8FC18 for ; Fri, 2 Dec 2011 18:12:43 +0000 (UTC) Received: by faak28 with SMTP id k28so3306033faa.13 for ; Fri, 02 Dec 2011 10:12:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BRjB+/xi54q1WDMP2rlYQt9/KCwdQwVkvJwvnhRhG+A=; b=q1q68lYLb24roWa2Rdo/GKSP107Kt0LyjNl1H9jD2GoGH5pUWlx+ztE+y8ROj8Muud KKwA+cIkxtsOpEOK7BBKves2fW6v31lmPLxOV9ehlCaM28w8biky0j3D3ub9imF8jeny gPgeuTw4yvQg/KaMapjEey3voOgTIJAcIVm08= MIME-Version: 1.0 Received: by 10.180.88.66 with SMTP id be2mr10880353wib.54.1322849562783; Fri, 02 Dec 2011 10:12:42 -0800 (PST) Received: by 10.180.101.102 with HTTP; Fri, 2 Dec 2011 10:12:42 -0800 (PST) In-Reply-To: References: <20111202015133.GA4111@dragon.NUXI.org> <20111202064132.GC88903@troutmask.apl.washington.edu> <4ED8776F.9060301@FreeBSD.org> <20111202072349.GA89183@troutmask.apl.washington.edu> <20111202083501.GA73959@dragon.NUXI.org> Date: Fri, 2 Dec 2011 13:12:42 -0500 Message-ID: From: Ryan Stone To: Lyndon Nerenberg Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, Chris Rees Subject: Re: WITHOUT_PROFILE=yes by default 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, 02 Dec 2011 18:12:44 -0000 On Fri, Dec 2, 2011 at 12:07 PM, Lyndon Nerenberg wrote: > No, these days 'obsolete' seems to mean 'it does not have a sexy > Flash-driven web GUI.' In this case, 'obsolete' means it's a difficult-to-use tool that requires recompiling your application, can't be used in production, doesn't work when shared libraries are in the picture, offers limited-to-no visibility into the underlying reasons why a particular code path is a hotspot and introduces large measurement errors From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 18:27:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01C45106566B for ; Fri, 2 Dec 2011 18:27:24 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [IPv6:2607:fc50:1000:8200:216:3eff:fe2c:dc8f]) by mx1.freebsd.org (Postfix) with ESMTP id C270D8FC12 for ; Fri, 2 Dec 2011 18:27:23 +0000 (UTC) Received: from [172.25.0.9] ([96.54.172.165]) (authenticated bits=0) by orthanc.ca (8.14.4/8.14.4) with ESMTP id pB2IRMMq070266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Dec 2011 10:27:23 -0800 (PST) (envelope-from lyndon@orthanc.ca) Date: Fri, 2 Dec 2011 10:27:21 -0800 (PST) From: Lyndon Nerenberg To: Ryan Stone In-Reply-To: Message-ID: References: <20111202015133.GA4111@dragon.NUXI.org> <20111202064132.GC88903@troutmask.apl.washington.edu> <4ED8776F.9060301@FreeBSD.org> <20111202072349.GA89183@troutmask.apl.washington.edu> <20111202083501.GA73959@dragon.NUXI.org> User-Agent: Alpine 1.10 (OSX 962 2008-03-14) Organization: The Frobozz Magic Homing Pigeon Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_PROFILE=yes by default 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, 02 Dec 2011 18:27:24 -0000 > In this case, 'obsolete' means it's a difficult-to-use tool that > requires recompiling your application, can't be used in production, > doesn't work when shared libraries are in the picture, offers > limited-to-no visibility into the underlying reasons why a particular > code path is a hotspot and introduces large measurement errors No, it just means it doesn't work for you. It does work for me, though. And for many others. Many a time I have shipped a profiled binary off to a customer site to determine where they are having performance problems. This works because they don't need to install any third-party tools or jump through other hoops. It's not perfect, but it is a useful debugging tool. The arguments I keep hearing here are "I don't (understand how to effectively) use this tool, therefore it should be removed." Collectively that argument can be applied to each and every component of FreeBSD when taken across the entire user base. Thus we can infinately optimize the builds though 'rm -rf /usr/src'. Now can we please just leave WITHOUT_PROFILE alone and go fix real bugs? If it will help, I will toss in a few hundred bucks to help Max buy a faster build machine. --lyndon From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 18:33:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9888106566B for ; Fri, 2 Dec 2011 18:33:04 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8964B8FC13 for ; Fri, 2 Dec 2011 18:33:04 +0000 (UTC) Received: by iakl21 with SMTP id l21so7210649iak.13 for ; Fri, 02 Dec 2011 10:33:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Wvgk+6zpf3Uuhf+UkkeYk1rK/Jn9K3DBQLjNpMVlS6c=; b=J2+CQHT7NZ0+yMAWdJcmXcf3orL/OZ9ZA5V0rWfJ9AAWf9jCSS4pwRBamww2qBk9+U 9S4QtmSK5vcl2OEN4dMqwZMh+muDJLocJFv/inQhtgMwvGfxoPh0hdzJ+d/f7YwPqTKg HBUrJOv/6RMtnv1tCpeGng9v41aUvas3XbgxI= MIME-Version: 1.0 Received: by 10.231.82.131 with SMTP id b3mr3352748ibl.74.1322850784000; Fri, 02 Dec 2011 10:33:04 -0800 (PST) Received: by 10.231.12.139 with HTTP; Fri, 2 Dec 2011 10:33:03 -0800 (PST) Received: by 10.231.12.139 with HTTP; Fri, 2 Dec 2011 10:33:03 -0800 (PST) In-Reply-To: References: <20111202015133.GA4111@dragon.NUXI.org> <20111202064132.GC88903@troutmask.apl.washington.edu> <4ED8776F.9060301@FreeBSD.org> <20111202072349.GA89183@troutmask.apl.washington.edu> <20111202083501.GA73959@dragon.NUXI.org> Date: Fri, 2 Dec 2011 18:33:03 +0000 Message-ID: From: Chris Rees To: Lyndon Nerenberg Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_PROFILE=yes by default 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, 02 Dec 2011 18:33:05 -0000 On 2 Dec 2011 17:07, "Lyndon Nerenberg" wrote: >> >> Obsolete does not mean it doesn't work. > > > No, these days 'obsolete' seems to mean 'it does not have a sexy Flash-driven web GUI.' Straw man argument. This is irrelevant. > Profiling is a simple basic tool that makes it easy to quickly find code execution hot-spots. It's not dtrace, or any other plethora of tools that do a more extensive job of profiling. But it's also a tool that is universally available to developers. Or was ... Still is if you choose it. > If you don't like it, don't use it. But don't turn that into an excuse to remove the functionality from the rest of us. Straw man argument. Nothing has been removed. > If you really think profiling is truly useless in this day and age, the proposal should be to eradicate it from the system entirely. Isn't this about user choice, and making sensible defaults? No-one is removing anything. Please stick to facts. Chris From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 18:39:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8067D1065670 for ; Fri, 2 Dec 2011 18:39:04 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [IPv6:2607:fc50:1000:8200:216:3eff:fe2c:dc8f]) by mx1.freebsd.org (Postfix) with ESMTP id 4CD138FC08 for ; Fri, 2 Dec 2011 18:39:04 +0000 (UTC) Received: from [172.25.0.9] ([96.54.172.165]) (authenticated bits=0) by orthanc.ca (8.14.4/8.14.4) with ESMTP id pB2Id2H3070329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Dec 2011 10:39:03 -0800 (PST) (envelope-from lyndon@orthanc.ca) Date: Fri, 2 Dec 2011 10:39:02 -0800 (PST) From: Lyndon Nerenberg To: Chris Rees In-Reply-To: Message-ID: References: <20111202015133.GA4111@dragon.NUXI.org> <20111202064132.GC88903@troutmask.apl.washington.edu> <4ED8776F.9060301@FreeBSD.org> <20111202072349.GA89183@troutmask.apl.washington.edu> <20111202083501.GA73959@dragon.NUXI.org> User-Agent: Alpine 1.10 (OSX 962 2008-03-14) Organization: The Frobozz Magic Homing Pigeon Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_PROFILE=yes by default 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, 02 Dec 2011 18:39:04 -0000 > Isn't this about user choice, and making sensible defaults? There are two or three "users" out of thousands complaining about the default. If the extra build time bugs you that much, I'll contribute towards buying you better build hardware, too. From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 18:40:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B820210656B8; Fri, 2 Dec 2011 18:40:14 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8A3338FC20; Fri, 2 Dec 2011 18:40:14 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 2809E46B0A; Fri, 2 Dec 2011 13:40:14 -0500 (EST) Received: from John-Baldwins-MacBook-Air.local (c-68-36-150-83.hsd1.nj.comcast.net [68.36.150.83]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 983A7B926; Fri, 2 Dec 2011 13:40:13 -0500 (EST) Message-ID: <4ED91B8D.2080808@FreeBSD.org> Date: Fri, 02 Dec 2011 13:40:13 -0500 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Attilio Rao References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201112011349.50502.jhb@freebsd.org> <4ED7E6B0.30400@FreeBSD.org> <201112011553.34432.jhb@freebsd.org> <4ED7F4BC.3080206@FreeBSD.org> <4ED855E6.20207@FreeBSD.org> <4ED8A306.9020801@FreeBSD.org> <4ED8F1C1.7010206@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 02 Dec 2011 13:40:13 -0500 (EST) Cc: freebsd-current@freebsd.org, Konstantin Belousov , Andriy Gapon Subject: Re: Stop scheduler on panic 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, 02 Dec 2011 18:40:14 -0000 On 12/2/11 12:18 PM, Attilio Rao wrote: > 2011/12/2 John Baldwin: >> On 12/2/11 5:05 AM, Andriy Gapon wrote: >>> >>> on 02/12/2011 06:36 John Baldwin said the following: >>>> >>>> Ah, ok (I had thought SCHEDULER_STOPPED was going to always be true when >>>> kdb was >>>> active). But I think these two changes should cover critical_exit() ok. >>>> >>> >>> I attempted to start a discussion about this a few times already :-) >>> Should we treat kdb context the same as SCHEDULER_STOPPED context (in the >>> current definition) ? That is, skip all locks in the same fashion? >>> There are pros and contras. >> >> >> kdb should not block on locks, no. Most debugger commands should not go >> near locks anyway unless they are intended to carefully modify the existing >> system in a safe manner (such as the 'kill' command which should only be >> using try locks and fail if it cannot safely post the signal). > > The biggest problem to KDB as the same as panic is that doing proper > 'continue' is impossible. > One of the features of the 'skip-locking' path is that it doesn't take > into account fast locking paths, where sometimes the lock can succeed > and other fails and you don't know about them. Also the restarted CPUs > can find corrupted datas (as they can be arbitrarely updated), I'm > sure it is too much panic prone. Yes, my thought is that kdb commands, etc. should be using dedicated routines that do not use locks whenever possible. The problem of a user calling an arbitrary routine is not solvable (so I don't think we should try to solve that, you use 'call' at your own risk), but built-in commands should explicitly either 1) not use locking, or 2) only use try locks and fail out cleanly (including dropping any try locks acquired) if a try fails. Now, that's an ideal view, I don't know how close we are to that in practice or if it is a realistically attainable goal. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 18:42:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98B421065670 for ; Fri, 2 Dec 2011 18:42:17 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 6C8E78FC20 for ; Fri, 2 Dec 2011 18:42:17 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id pB2IgHlD044341; Fri, 2 Dec 2011 10:42:17 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id pB2IgHvb044340; Fri, 2 Dec 2011 10:42:17 -0800 (PST) (envelope-from sgk) Date: Fri, 2 Dec 2011 10:42:17 -0800 From: Steve Kargl To: Ryan Stone Message-ID: <20111202184217.GA3911@troutmask.apl.washington.edu> References: <4ED8776F.9060301@FreeBSD.org> <20111202072349.GA89183@troutmask.apl.washington.edu> <20111202083501.GA73959@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, Lyndon Nerenberg , Chris Rees Subject: Re: WITHOUT_PROFILE=yes by default 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, 02 Dec 2011 18:42:17 -0000 On Fri, Dec 02, 2011 at 01:12:42PM -0500, Ryan Stone wrote: > On Fri, Dec 2, 2011 at 12:07 PM, Lyndon Nerenberg wrote: > > No, these days 'obsolete' seems to mean 'it does not have a sexy > > Flash-driven web GUI.' > > In this case, 'obsolete' means it's a difficult-to-use tool that > requires recompiling your application, can't be used in production, > doesn't work when shared libraries are in the picture, offers > limited-to-no visibility into the underlying reasons why a particular > code path is a hotspot and introduces large measurement errors Difficult to use? % gfortran -o ang -pg ang.f90 % ./ang % gprof -b -l ./ang ang.gmon | more ... % cumulative self self total time seconds seconds calls ms/call ms/call name 35.0 0.01 0.01 0 100.00% _write [1] 33.3 0.02 0.01 0 100.00% _mcount [2] 15.0 0.02 0.00 1080 0.00 0.00 arena_purge [4] 5.6 0.02 0.00 0 100.00% .mcount (40) 2.2 0.02 0.00 29600 0.00 0.00 __quorem_D2A [8] 1.7 0.02 0.00 1080 0.00 0.00 __dtoa [7] 1.1 0.02 0.00 29552 0.00 0.00 __multadd_D2A [13] 1.1 0.02 0.00 7557 0.00 0.00 memcpy [12] Please show me how you would get the same information with pmcstat (or other tools) in the base system. Note, ang.f90 is a toy app I had lying around, which completes in a second or 2. If you want a non-toy example, I'll happily run one of my libm testcase for you. -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 19:05:00 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE39F106566B for ; Fri, 2 Dec 2011 19:05:00 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [IPv6:2607:fc50:1000:8200:216:3eff:fe2c:dc8f]) by mx1.freebsd.org (Postfix) with ESMTP id 6F3F58FC20 for ; Fri, 2 Dec 2011 19:05:00 +0000 (UTC) Received: from [172.25.0.9] ([96.54.172.165]) (authenticated bits=0) by orthanc.ca (8.14.4/8.14.4) with ESMTP id pB2J4wXE070446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 2 Dec 2011 11:04:59 -0800 (PST) (envelope-from lyndon@orthanc.ca) Date: Fri, 2 Dec 2011 11:04:58 -0800 (PST) From: Lyndon Nerenberg To: freebsd-current@freebsd.org Message-ID: User-Agent: Alpine 1.10 (OSX 962 2008-03-14) Organization: The Frobozz Magic Homing Pigeon Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Sparc build boxes 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, 02 Dec 2011 19:05:00 -0000 Speaking of throwing hardware at people, I have a couple of Sun V100s that could go to a good home for FreeBSD Sparc development purposes. They come equipped with 1GB of RAM and a pair of 80GB disks. If anyone can make a legitimate case for them, drop me a note. --lyndon From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 19:19:19 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61B161065675 for ; Fri, 2 Dec 2011 19:19:19 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 161518FC18 for ; Fri, 2 Dec 2011 19:19:18 +0000 (UTC) Received: by ggnp1 with SMTP id p1so668851ggn.13 for ; Fri, 02 Dec 2011 11:19:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=YfFnnDqHI5py6+OpObgVrjFKTbuaAICO4UrGL+Qp4RY=; b=plakVMT3FzzB+C1VpVnfGSBPjSW1j3JLEeTPxEDoWpcU8pJYCmrQzinG3eke6ZHJgd ynCVy7ic0YILhyy/zn0u8hoQb5lAbliZlhnBUR8porXngvtEhNNxPg2dKEa3hDT0aBnn Gj8LAt31CjUcixI4X4e4ZXfn4S6LEX55qZAJ8= MIME-Version: 1.0 Received: by 10.182.74.37 with SMTP id q5mr2598929obv.32.1322853558489; Fri, 02 Dec 2011 11:19:18 -0800 (PST) Received: by 10.182.62.227 with HTTP; Fri, 2 Dec 2011 11:19:17 -0800 (PST) In-Reply-To: References: <20111202015133.GA4111@dragon.NUXI.org> <20111202064132.GC88903@troutmask.apl.washington.edu> <4ED8776F.9060301@FreeBSD.org> <20111202072349.GA89183@troutmask.apl.washington.edu> <20111202083501.GA73959@dragon.NUXI.org> Date: Fri, 2 Dec 2011 11:19:17 -0800 Message-ID: From: Garrett Cooper To: Lyndon Nerenberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Chris Rees Subject: Re: WITHOUT_PROFILE=yes by default 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, 02 Dec 2011 19:19:19 -0000 On Fri, Dec 2, 2011 at 10:39 AM, Lyndon Nerenberg wrote= : >> Isn't this about user choice, and making sensible defaults? > > > There are two or three "users" out of thousands complaining about the > default. =A0If the extra build time bugs you that much, I'll contribute > towards buying you better build hardware, too. "Suffer in silence" There are a lot more than two or three users, we just choose not to join in a bikeshed because of other more pressing issues. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 19:22:10 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C063106566B; Fri, 2 Dec 2011 19:22:10 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 60D8B8FC14; Fri, 2 Dec 2011 19:22:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pB2JMAt5037654; Fri, 2 Dec 2011 19:22:10 GMT (envelope-from bapt@FreeBSD.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pB2JMAjK037653; Fri, 2 Dec 2011 19:22:10 GMT (envelope-from bapt@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@FreeBSD.org using -f Date: Fri, 2 Dec 2011 20:22:06 +0100 From: Baptiste Daroussin To: obrien@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <20111202192206.GB1913@azathoth.lan> References: <20111125190137.GA4420@azathoth.lan> <20111202071633.GD4444@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CUfgB8w4ZwR/yMy5" Content-Disposition: inline In-Reply-To: <20111202071633.GD4444@dragon.NUXI.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: Upgrade contributed gperf, m4 and flex 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, 02 Dec 2011 19:22:10 -0000 --CUfgB8w4ZwR/yMy5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 01, 2011 at 11:16:33PM -0800, David O'Brien wrote: > On Fri, Nov 25, 2011 at 08:01:37PM +0100, Baptiste Daroussin wrote: > > and last: upgrade flex to the latest upstream version (it will need the= m4 > > upgrade) while here I'll move back flex to contrib/ > > patches can be found there:=20 > > http://people.freebsd.org/~bapt/flex-update.diff >=20 > Hi Baptiste, > I cannot tell from this what you are really doing. >=20 > It would likely be best to keep the old history, so that would involve > a 'svn move usr.bin/lex contrib/flex'. >=20 > Additionally if flex is now considered to be 3rd-party code (signified by > living in contrib/) it should be imported we into '$REPO/base/vendor'. >=20 > These actions would give a different diff than that above. >=20 > Do you have a diff that shows what the real changes to FreeBSD are? There are about no changes to FreeBSD, all the changes that were added in o= ur tree in the old version found their way into the upstream version I have two warning fixes, one in the generated code, and on the the flex code itself, = I'm planning to push them upstream. concerning the push into contrib, it was ju= st to try to do things the same way other contributed code are in our tree, maybe= I should just let it into the usr.bin/lex, I have no real opinion on this, I thought it would have been cleaner living in contrib. >=20 >=20 > > I also plan to upgrade m4 syncing code from openbsd, taking code from n= etbsd > > (improve gnu m4 compatibility). > > http://people.freebsd.org/~bapt/update_m4_from_openbsd_and_netbsd.diff >=20 > We don't seen to have '$REPO/base/vendor/OpenBSD/m4' as we likely should. > How different is our usr.bin/m4 from OpenBSD's? I didn't create a directory in vendor as our version is already from openbsd without the vendor entry, and lots of code like this one (ie from other bsd= ) do not have their entry in vendor, for example makefs and no one asked me to p= ush it into vendor/NetBSD at that time, once again if this the right way to do,= I'll create the OpenBSD/m4. Concerning the difference with the OpenBSD version this is only cosmetics a= nd warning fixes: function declared in a old fashion way, and small things like that, also took some fixes and way to build it from NetBSD (importing ohash which they took from OpenBSD). >=20 >=20 > > http://people.freebsd.org/~bapt/upgrade-gperf-to-3.0.3.diff >=20 > I assume an import into '$REPO/base/vendor/gperf/' will happen first? > ['$REPO/base/vendor/gperf/' needs to be "flattend out" first] > o I missed that one, I'll fix it as soon as possible. > thanks, Thanks for feedback. regards, Bapt --CUfgB8w4ZwR/yMy5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7ZJV4ACgkQ8kTtMUmk6EytjgCdG2PDPEGvQyDs7jr8kpVd8V/Z GoIAoLup4azxQVebkXUSo+nuIjPmZ4qV =oaqg -----END PGP SIGNATURE----- --CUfgB8w4ZwR/yMy5-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 19:38:18 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2966710656A8 for ; Fri, 2 Dec 2011 19:38:18 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [IPv6:2607:fc50:1000:8200:216:3eff:fe2c:dc8f]) by mx1.freebsd.org (Postfix) with ESMTP id DEAC58FC0C for ; Fri, 2 Dec 2011 19:38:17 +0000 (UTC) Received: from [172.25.0.9] ([96.54.172.165]) (authenticated bits=0) by orthanc.ca (8.14.4/8.14.4) with ESMTP id pB2JcGrS070652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 2 Dec 2011 11:38:17 -0800 (PST) (envelope-from lyndon@orthanc.ca) Date: Fri, 2 Dec 2011 11:38:16 -0800 (PST) From: Lyndon Nerenberg To: freebsd-current@freebsd.org Message-ID: User-Agent: Alpine 1.10 (OSX 962 2008-03-14) Organization: The Frobozz Magic Homing Pigeon Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Sparc V100s (re donations) 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, 02 Dec 2011 19:38:18 -0000 About the donations page et al ... that's set up for cash donations. Hardware doesn't go through there very well. I don't care about tax receipts. I'd rather just send the gear directly to any people who can legitimately use it (i.e. someone with an @freebsd.org address, or someone with an @freebsd friend who will vouch for them). I will pay for any reasonable shipping charges. --lyndon From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 20:00:57 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 798E5106566B; Fri, 2 Dec 2011 20:00:57 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 44F558FC1D; Fri, 2 Dec 2011 20:00:56 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id pB2K0skV080825 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 2 Dec 2011 12:00:55 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4ED92E82.4040800@freebsd.org> Date: Fri, 02 Dec 2011 12:01:06 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.24) Gecko/20111103 Thunderbird/3.1.16 MIME-Version: 1.0 To: Arnaud Lacombe References: <4EB9C469.9070208@freebsd.org> <4EB9E6FE.3060102@freebsd.org> <4EBABAC1.2090003@freebsd.org> <4EC0EA00.8030608@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]] 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, 02 Dec 2011 20:00:57 -0000 On 12/1/11 5:04 PM, Arnaud Lacombe wrote: > Hi, > > On Mon, Nov 14, 2011 at 5:14 AM, Andriy Gapon wrote: >> on 14/11/2011 02:38 Arnaud Lacombe said the following: >>> you (committers) >> I wonder how it would work out if you were made a committer and couldn't say >> "you (committers)" any more... :-) >> > The real question is rather whether or not I would accept such a role, > or better, would I ever be proposed such a role ? > > I doubt someone praising the Bazaar, openly challenging core and > historical members, would fit in the Cathedral, even if my work is > only ever gonna be in the `projects/' subdirectory. That's really funny.. we are the bazaar. Any developer can pretty quickly get to be a committer (*) and after mentorship (6 months) can commit to any part of the code. Linux is the catherderal. It has a pope, a whole array of bishops and then priests and finally millions of serfs. (*) we propose people to get commit bits on how useful they seem to be rather that their political views. > - Arnaud > _______________________________________________ > 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 Fri Dec 2 20:11:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E67C4106566B for ; Fri, 2 Dec 2011 20:11:52 +0000 (UTC) (envelope-from luke@foolishgames.com) Received: from stargazer.midnightbsd.org (cl-218.chi-02.us.sixxs.net [IPv6:2001:4978:f:d9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7DF218FC0C for ; Fri, 2 Dec 2011 20:11:52 +0000 (UTC) Received: from [10.5.148.226] (mobile-166-147-127-115.mycingular.net [166.147.127.115]) (authenticated bits=0) by stargazer.midnightbsd.org (8.14.5/8.14.5) with ESMTP id pB2KBmm0035117 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 2 Dec 2011 15:11:51 -0500 (EST) (envelope-from luke@foolishgames.com) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at stargazer.midnightbsd.org X-Authentication-Warning: stargazer.midnightbsd.org: Host mobile-166-147-127-115.mycingular.net [166.147.127.115] claimed to be [10.5.148.226] References: <20111202015133.GA4111@dragon.NUXI.org> <20111202064132.GC88903@troutmask.apl.washington.edu> <4ED8776F.9060301@FreeBSD.org> <20111202072349.GA89183@troutmask.apl.washington.edu> <20111202083501.GA73959@dragon.NUXI.org> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9A405) From: Lucas Holt Date: Fri, 2 Dec 2011 15:11:43 -0500 To: Lyndon Nerenberg Cc: "freebsd-current@freebsd.org" , Chris Rees Subject: Re: WITHOUT_PROFILE=yes by default 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, 02 Dec 2011 20:11:53 -0000 What if it was still included in tinderbox builds and releases. For the latt= er, the profiled versions could be in a separate distribution set much like d= oc or games. The ugly part is freebsd-update..=20 It could still be off by default in the buildworld as anyone smart enough to= do source upgrades can toggle something in src.conf.=20 This should make lazy devs happy, speed up build times for those upset about= that, etc. it sucks for RE though.=20 I was taught to use gprof in college and it was nice using the same tool on s= chool sun and Linux boxes as well as my own iBook and FreeBSD desktop.=20 This might be a fair compromise for now with a EOL date in a future release.= At some point I assume dropping gnu tools with llvm transition makes sense=20= Lucas Holt On Dec 2, 2011, at 1:39 PM, Lyndon Nerenberg wrote: >> Isn't this about user choice, and making sensible defaults? >=20 > There are two or three "users" out of thousands complaining about the defa= ult. If the extra build time bugs you that much, I'll contribute towards bu= ying you better build hardware, too. > _______________________________________________ > 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 Fri Dec 2 20:20:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC0F31065670; Fri, 2 Dec 2011 20:20:49 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id AB6F78FC0C; Fri, 2 Dec 2011 20:20:48 +0000 (UTC) Received: by faak28 with SMTP id k28so3467853faa.13 for ; Fri, 02 Dec 2011 12:20:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0uLkV7fCWCFQd6Yy/mn2RI6un/ROy1ROLZO0GFinmws=; b=SbtdalVKNAA0Vp3siSxy33W2KoTZo3alp1WhgPjJDe+3K+fU308/Zjo/mRYXPdgID9 DBbWpo7lKtBCH/SQwbAhB1ofrStdzYqfXbq8i7mpcRRI5UePkPDcxpk0WbN4ve4Spx/n B75y+pINGBxwa16MVkXVVyN9CqnLRFYIM9otA= MIME-Version: 1.0 Received: by 10.180.108.114 with SMTP id hj18mr12118243wib.2.1322857247476; Fri, 02 Dec 2011 12:20:47 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.47.211 with HTTP; Fri, 2 Dec 2011 12:20:47 -0800 (PST) In-Reply-To: <4ED91B8D.2080808@FreeBSD.org> References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201112011349.50502.jhb@freebsd.org> <4ED7E6B0.30400@FreeBSD.org> <201112011553.34432.jhb@freebsd.org> <4ED7F4BC.3080206@FreeBSD.org> <4ED855E6.20207@FreeBSD.org> <4ED8A306.9020801@FreeBSD.org> <4ED8F1C1.7010206@FreeBSD.org> <4ED91B8D.2080808@FreeBSD.org> Date: Fri, 2 Dec 2011 21:20:47 +0100 X-Google-Sender-Auth: nGogWj2bLU_FXIf1i-i8tSs0mRk Message-ID: From: Attilio Rao To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Konstantin Belousov , Andriy Gapon Subject: Re: Stop scheduler on panic 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, 02 Dec 2011 20:20:49 -0000 2011/12/2 John Baldwin : > On 12/2/11 12:18 PM, Attilio Rao wrote: >> >> 2011/12/2 John Baldwin: >>> >>> On 12/2/11 5:05 AM, Andriy Gapon wrote: >>>> >>>> >>>> on 02/12/2011 06:36 John Baldwin said the following: >>>>> >>>>> >>>>> Ah, ok (I had thought SCHEDULER_STOPPED was going to always be true >>>>> when >>>>> kdb was >>>>> active). =C2=A0But I think these two changes should cover critical_ex= it() >>>>> ok. >>>>> >>>> >>>> I attempted to start a discussion about this a few times already :-) >>>> Should we treat kdb context the same as SCHEDULER_STOPPED context (in >>>> the >>>> current definition) ? =C2=A0That is, skip all locks in the same fashio= n? >>>> There are pros and contras. >>> >>> >>> >>> kdb should not block on locks, no. =C2=A0Most debugger commands should = not go >>> near locks anyway unless they are intended to carefully modify the >>> existing >>> system in a safe manner (such as the 'kill' command which should only b= e >>> using try locks and fail if it cannot safely post the signal). >> >> >> The biggest problem to KDB as the same as panic is that doing proper >> 'continue' is impossible. >> One of the features of the 'skip-locking' path is that it doesn't take >> into account fast locking paths, where sometimes the lock can succeed >> and other fails and you don't know about them. Also the restarted CPUs >> can find corrupted datas (as they can be arbitrarely updated), I'm >> sure it is too much panic prone. > > > Yes, my thought is that kdb commands, etc. should be using dedicated > routines that do not use locks whenever possible. =C2=A0The problem of a = user > calling an arbitrary routine is not solvable (so I don't think we should = try > to solve that, you use 'call' at your own risk), but built-in commands > should explicitly either 1) not use locking, or 2) only use try locks and > fail out cleanly (including dropping any try locks acquired) if a try fai= ls. > =C2=A0Now, that's an ideal view, I don't know how close we are to that in > practice or if it is a realistically attainable goal. So you are not in favor of giving KDB its own context? There are some fallbacks (like, for example, bugs involving the scheduler or switching mechanism but for that we can make a facility like KDB_LITE if you want to debug a scheduler problem), but in general that would avoid replicating code to avoid the locking. If you don't want to give KDB its own context, we should work on a KPI (or similar) that defines the command to serve as KDB commands, that tries to keep things under control, etc. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 20:43:34 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DD97106566C for ; Fri, 2 Dec 2011 20:43:34 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id EC9C18FC08 for ; Fri, 2 Dec 2011 20:43:33 +0000 (UTC) Received: by ggnp1 with SMTP id p1so774804ggn.13 for ; Fri, 02 Dec 2011 12:43:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=FUdC4AjMheWDGhT3CvH4GKa9tYv3leZ/Ec9DOwCorC4=; b=kfZ0ZhCgJYDVweOQ6lRRbLSSCgfo6Ii+cZrK9FG2MLF98mW8NUKJc3f14xvjjDyGnm hfzs/mn5sT4/f1LDW3FRV1/ENj3iPErAhuQmAU+3ywcKOo3r8K34kUdVu48eqZHucCag CElScTiEMHnzRAR/z6C8IDr6ysHIfW/KKgC0Y= MIME-Version: 1.0 Received: by 10.182.40.65 with SMTP id v1mr2644111obk.72.1322858613145; Fri, 02 Dec 2011 12:43:33 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.182.62.227 with HTTP; Fri, 2 Dec 2011 12:43:33 -0800 (PST) In-Reply-To: References: Date: Fri, 2 Dec 2011 12:43:33 -0800 X-Google-Sender-Auth: -UQyADcD-7UhkGp9vQDVxUPaSv8 Message-ID: From: Garrett Cooper To: Lyndon Nerenberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 02 Dec 2011 20:57:30 +0000 Cc: Subject: Re: Sparc V100s (re donations) 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, 02 Dec 2011 20:43:34 -0000 On Fri, Dec 2, 2011 at 11:38 AM, Lyndon Nerenberg wrote= : > About the donations page et al ... that's set up for cash donations. > Hardware doesn't go through there very well. =A0I don't care about tax > receipts. =A0I'd rather just send the gear directly to any people who can > legitimately use it (i.e. someone with an @freebsd.org address, or someon= e > with an @freebsd friend who will vouch for them). =A0I will pay for any > reasonable shipping charges. (current@ BCCed) Lyndon, There are a ton of pages with info (mostly duplicated) on how to donate to the project (money, hardware, time, ...), a mailman list you can send requests to for adding yourself to the donations page ( http://www.freebsd.org/donations/donors.html ), etc that would be better for this request/offer than current@FreeBSD.org, as this is for end-users who run FreeBSD CURRENT. Thanks, -Garrett PS Look for "hardware donation form" on the page I just sent you (just in case, http://www.freebsd.org/donations/ ). From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 21:04:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86E28106564A for ; Fri, 2 Dec 2011 21:04:59 +0000 (UTC) (envelope-from hans@beastielabs.net) Received: from mail.beastielabs.net (beasties.demon.nl [82.161.3.114]) by mx1.freebsd.org (Postfix) with ESMTP id E4E708FC14 for ; Fri, 2 Dec 2011 21:04:58 +0000 (UTC) Received: from merom.hotsoft.nl (merom.hotsoft.nl [192.168.0.12]) by mail.beastielabs.net (8.14.4/8.14.4) with ESMTP id pB2KdC2Z077809; Fri, 2 Dec 2011 21:39:12 +0100 (CET) (envelope-from hans@beastielabs.net) Message-ID: <4ED9376A.1000104@beastielabs.net> Date: Fri, 02 Dec 2011 21:39:06 +0100 From: Hans Ottevanger User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: Lyndon Nerenberg References: <20111202015133.GA4111@dragon.NUXI.org> <20111202064132.GC88903@troutmask.apl.washington.edu> <4ED8776F.9060301@FreeBSD.org> <20111202072349.GA89183@troutmask.apl.washington.edu> <20111202083501.GA73959@dragon.NUXI.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_PROFILE=yes by default 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, 02 Dec 2011 21:04:59 -0000 On 12/02/11 19:39, Lyndon Nerenberg wrote: >> Isn't this about user choice, and making sensible defaults? > > There are two or three "users" out of thousands complaining about the > default. If the extra build time bugs you that much, I'll contribute > towards buying you better build hardware, too. Well, I am not a FreeBSD developer (though I do hunt down a bug occasionally), but for many, many years I do develop software using FreeBSD as a development platform. And for solving performance issues, mainly in long running, CPU intensive (numerical) applications gprof and all too often the profiled libraries appeared to be indispensable. I am mostly using STABLE, but occasionally switch to CURRENT to get a feeling for the newest developments (e.g. LLVM). One of the reasons I am still using FreeBSD is the out-of-the-box availability of tools like the profiler and profiled libraries. Maybe I could live with a switch in /etc/src.conf, if it were properly documented, but that would imply that the profiled libraries are not built anymore with any regularity. And of course we all know where that could lead to in the future ... I would certainly keep the profiled libraries by default in the build for CURRENT and maybe even in STABLE. With binary installations of RELEASE it could be an option, as it always was. Regards, Hans From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 21:14:58 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9844106566B for ; Fri, 2 Dec 2011 21:14:58 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 338078FC0C for ; Fri, 2 Dec 2011 21:14:57 +0000 (UTC) Received: by ghbg20 with SMTP id g20so4945377ghb.13 for ; Fri, 02 Dec 2011 13:14:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=IBo85gy9Zdp3hyL4+R/FiyCfDnsiuJVQDcqOK0DywXk=; b=vdfkRtNrx0rpPAEaO/eEqKcEjS7/4zu+1Y30T54RofPJH6dXa6e1SCqJKkGyeOlZx8 skAtPqQ5UpOfV1joZLNGIKsXu17kMjRly+fmw2fhTw+IvoKy6AeaoYiQXBKg9EwQ26AG POdhWeNV6o4n2h6HEH+vThUUb5jggEv2t9VcQ= MIME-Version: 1.0 Received: by 10.50.51.234 with SMTP id n10mr36454igo.10.1322860497232; Fri, 02 Dec 2011 13:14:57 -0800 (PST) Received: by 10.231.171.82 with HTTP; Fri, 2 Dec 2011 13:14:57 -0800 (PST) In-Reply-To: References: <20111202015133.GA4111@dragon.NUXI.org> <20111202064132.GC88903@troutmask.apl.washington.edu> <4ED8776F.9060301@FreeBSD.org> <20111202072349.GA89183@troutmask.apl.washington.edu> <20111202083501.GA73959@dragon.NUXI.org> Date: Fri, 2 Dec 2011 13:14:57 -0800 Message-ID: From: Kevin Oberman To: Lucas Holt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-current@freebsd.org" , Lyndon Nerenberg , Chris Rees Subject: Re: WITHOUT_PROFILE=yes by default 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, 02 Dec 2011 21:14:58 -0000 On Fri, Dec 2, 2011 at 12:11 PM, Lucas Holt wrote: > What if it was still included in tinderbox builds and releases. For the l= atter, the profiled versions could be in a separate distribution set much l= ike doc or games. =A0The ugly part is freebsd-update.. > > It could still be off by default in the buildworld as anyone smart enough= to do source upgrades can toggle something in src.conf. > > This should make lazy devs happy, speed up build times for those upset ab= out that, etc. it sucks for RE though. > > I was taught to use gprof in college and it was nice using the same tool = on school sun and Linux boxes as well as my own iBook and FreeBSD desktop. > > This might be a fair compromise for now with a EOL date in a future relea= se. At some point I assume dropping gnu tools with llvm transition makes se= nse > > Lucas Holt > > On Dec 2, 2011, at 1:39 PM, Lyndon Nerenberg wrote: > >>> Isn't this about user choice, and making sensible defaults? >> >> There are two or three "users" out of thousands complaining about the de= fault. =A0If the extra build time bugs you that much, I'll contribute towar= ds buying you better build hardware, too. OK. I am NOT a developer but have run -current as a user for extended intervals (v4 through V6) as I needed hardware support for my laptop that was not available in -stable. I'm sure I am not alone.I may be installing current again to get Intel KMS support for my Sandybridge. I did discover the amount of time spent building profile libs and turned them off in make.conf (later src.conf), but I think it is really, really silly to have a default in -stable that is used by almost no one. and wastes a little disk space and some time (it was a LOT on my old AMD 450 MHz system). Beyond that, for the relatively small number of folks using the libs and the trivial effort for those who do use it to turn the build on if it was made non-default, I can't really see the argument for building them in -current as a winner, either. But please, please turn it off in -stable at the very least. --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 22:32:07 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7DAD106564A; Fri, 2 Dec 2011 22:32:06 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id AFCBD8FC12; Fri, 2 Dec 2011 22:32:05 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA07476; Sat, 03 Dec 2011 00:32:03 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RWbeF-000B5l-Gb; Sat, 03 Dec 2011 00:32:03 +0200 Message-ID: <4ED951E0.9000000@FreeBSD.org> Date: Sat, 03 Dec 2011 00:32:00 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: John Baldwin References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201112011349.50502.jhb@freebsd.org> <4ED7E6B0.30400@FreeBSD.org> <201112011553.34432.jhb@freebsd.org> <4ED7F4BC.3080206@FreeBSD.org> <4ED855E6.20207@FreeBSD.org> <4ED8A306.9020801@FreeBSD.org> <4ED8F1C1.7010206@FreeBSD.org> <4ED91B8D.2080808@FreeBSD.org> In-Reply-To: <4ED91B8D.2080808@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Attilio Rao , freebsd-current@FreeBSD.org, Konstantin Belousov Subject: Re: Stop scheduler on panic 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, 02 Dec 2011 22:32:07 -0000 on 02/12/2011 20:40 John Baldwin said the following: > On 12/2/11 12:18 PM, Attilio Rao wrote: >> 2011/12/2 John Baldwin: >>> On 12/2/11 5:05 AM, Andriy Gapon wrote: >>>> >>>> on 02/12/2011 06:36 John Baldwin said the following: >>>>> >>>>> Ah, ok (I had thought SCHEDULER_STOPPED was going to always be true when >>>>> kdb was >>>>> active). But I think these two changes should cover critical_exit() ok. >>>>> >>>> >>>> I attempted to start a discussion about this a few times already :-) >>>> Should we treat kdb context the same as SCHEDULER_STOPPED context (in the >>>> current definition) ? That is, skip all locks in the same fashion? >>>> There are pros and contras. >>> >>> >>> kdb should not block on locks, no. Most debugger commands should not go >>> near locks anyway unless they are intended to carefully modify the existing >>> system in a safe manner (such as the 'kill' command which should only be >>> using try locks and fail if it cannot safely post the signal). >> >> The biggest problem to KDB as the same as panic is that doing proper >> 'continue' is impossible. >> One of the features of the 'skip-locking' path is that it doesn't take >> into account fast locking paths, where sometimes the lock can succeed >> and other fails and you don't know about them. Also the restarted CPUs >> can find corrupted datas (as they can be arbitrarely updated), I'm >> sure it is too much panic prone. > > Yes, my thought is that kdb commands, etc. should be using dedicated routines > that do not use locks whenever possible. The problem of a user > calling an arbitrary routine is not solvable (so I don't think we should try to > solve that, you use 'call' at your own risk), but built-in commands should > explicitly either 1) not use locking, or 2) only use try locks and fail out > cleanly (including dropping any try locks acquired) if a try fails. Now, that's > an ideal view, I don't know how close we are to that in practice or if it is a > realistically attainable goal. > I agree with what Attilio and you say. Initially it was tempting for me to apply the same SCHEDULER_STOPPED stopped medicine to the kdb_active context, but after trying to deal with kdb_active x SCHEDULER_STOPPED x ukbd situation I really changed my mind. I would classify the code that can be called in kdb_active context as follows: o debugger code proper (kdb, ddb, gdb stub, etc) - this obviously must not (doesn't have to) use any locking o code that can be invoked via 'call' command - this is essentially any code and I don't think that it can/should do anything special for the kdb_active context [*] o debugger helper routines - those that do something trivial should not acquire any locks; those that access shared resources should try the relevant locks and bail out if a resource can be in inconsistent state, or should be equipped to deal correctly with such a state; this is the same as what you say above o common code that the debuggers have to use - most obviously this is console code and drivers that serve a particular console; on one hand those drivers can have a non-trivial state that must be lock protected during normal operation, on the other hand the debugger must disregard those locks and grab its console; this is the most complex case in my opinion. Dealing with panics is much simpler, because it's a one way road to a system reset. Possibility to enter and exit debugger implies additional complications. So it doesn't look like SCHEDULER_STOPPED can be used equivalently for panic and for kdb_active. kdb_active requires more elaborate handling. [*] - but currently we depend on some "general purpose" routines to be 'callable' from debugger where we should really have a debugger command; the most popular example is 'call doadump'. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 22:37:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49851106564A; Fri, 2 Dec 2011 22:37:17 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 1FCF38FC15; Fri, 2 Dec 2011 22:37:17 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id pB2MbGpN035196; Fri, 2 Dec 2011 14:37:16 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id pB2MbGIN035195; Fri, 2 Dec 2011 14:37:16 -0800 (PST) (envelope-from sgk) Date: Fri, 2 Dec 2011 14:37:16 -0800 From: Steve Kargl To: Max Khon Message-ID: <20111202223716.GA35140@troutmask.apl.washington.edu> References: <20111202015133.GA4111@dragon.NUXI.org> <20111202064132.GC88903@troutmask.apl.washington.edu> <4ED8776F.9060301@FreeBSD.org> <20111202072349.GA89183@troutmask.apl.washington.edu> <20111202083501.GA73959@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Doug Barton , freebsd-current@freebsd.org Subject: Re: WITHOUT_PROFILE=yes by default 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, 02 Dec 2011 22:37:17 -0000 On Fri, Dec 02, 2011 at 04:21:14PM +0700, Max Khon wrote: > David, > > On Fri, Dec 2, 2011 at 3:35 PM, David O'Brien wrote: > > On Fri, Dec 02, 2011 at 11:56:31AM +0700, Max Khon wrote: > >> You still failed to name a single compelling reason to leave profiled > >> libs even in -CURRENT. > > > > Sorry Joe, I don't think your reasoning is compelling. > > I'm sure you know how to stick "NO_PROFILE=true" in your /etc/src.conf. > > > > How far do you want to take this? ??By this reasoning we should set all > > the knobs to "NO" to speed up the build. ??I mean we're all competent > > code builders running FreeBSD-current and know how to enable knobs in > > /etc/src.conf. > > > > Is speeding up the build import important to you then the default > > base system being an comfortable featureful development environment? > > The most important thing is to have reasonable defaults. > Having WITH_PROFILE by default does not seem to be a reasonable default to me. > Common options set in make.conf WITHOUT_MODULES="YES" WITHOUT_NLS="YES" WITHOUT_LIB32="YES" WITH_BSD_GREP="YES" Here's some numbers to consider: WITH_PROFILE="YES" rm -rf /usr/obj/* time make -j2 buildworld 6678.61 real 9752.40 user 1630.71 sys WITHOUT_PROFILE="YES" rm -rf /usr/obj/* time make -j2 buildworld 6221.21 real 9171.41 user 1471.23 sys WITH_PROFILE="YES" WITHOUT_CLANG="YES" 3388.27 real 4804.24 user 1160.12 sys If one wants to speed up buildworld, it would seem to be prudent to compile clang with profiled libraries to determined why it is such a time sync. >From dmesg.boot: CPU: AMD Opteron(tm) Processor 248 (2191.96-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0xf5a Family = f Model = 5 Stepping = 10 Features=0x78bfbff AMD Features=0xe0500800 real memory = 8589934592 (8192 MB) avail memory = 8203833344 (7823 MB) -- Steve From owner-freebsd-current@FreeBSD.ORG Sat Dec 3 01:00:20 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 0128E106566B; Sat, 3 Dec 2011 01:00:19 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 67446151398; Sat, 3 Dec 2011 01:00:19 +0000 (UTC) Message-ID: <4ED974A2.7080606@FreeBSD.org> Date: Fri, 02 Dec 2011 17:00:18 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Adrian Chadd References: <20111202115446.GB25963@server.vk2pj.dyndns.org> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current , Peter Jeremy , Max Khon Subject: Re: CVS removal from the 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, 03 Dec 2011 01:00:20 -0000 On 12/02/2011 04:35, Adrian Chadd wrote: > I think you're missing the point a little. > > The point is, you have to keep in mind how comfortable people feel > about things, and progress sometimes makes people uncomfortable. I > think you should leave these changes bake for a while and let people > get comfortable with the changing status quo. The fact that we have so many people who are radically change-averse, no matter how rational the change; is a bug, not a feature. This particular bug is complicated dramatically by the fact that the majority view seems to lean heavily towards "If I use it, it must be the default and/or in the base" rather than seeing ports as part of the overall operating SYSTEM. Doug -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Sat Dec 3 09:13:57 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6746F106564A; Sat, 3 Dec 2011 09:13:57 +0000 (UTC) (envelope-from rik@inse.ru) Received: from ns.rikbsd.org (ns.rikbsd.org [95.143.215.27]) by mx1.freebsd.org (Postfix) with ESMTP id 0FF998FC0A; Sat, 3 Dec 2011 09:13:56 +0000 (UTC) Received: from [127.0.0.1] (wn.rikbsd.org [192.168.1.254]) by ns.rikbsd.org (Postfix) with ESMTPA id 2F73C5CF13; Sat, 3 Dec 2011 10:14:23 +0000 (UTC) Message-ID: <4ED9EA27.8090206@inse.ru> Date: Sat, 03 Dec 2011 13:21:43 +0400 From: Roman Kurakin User-Agent: Thunderbird 2.0.0.24 (X11/20110906) MIME-Version: 1.0 To: Doug Barton References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> In-Reply-To: <4ED974A2.7080606@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , freebsd-current , Peter Jeremy , Max Khon Subject: Re: CVS removal from the 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, 03 Dec 2011 09:13:57 -0000 Doug Barton wrote: > [...] > The fact that we have so many people who are radically change-averse, no > matter how rational the change; is a bug, not a feature. > > This particular bug is complicated dramatically by the fact that the > majority view seems to lean heavily towards "If I use it, it must be the > default and/or in the base" rather than seeing ports as part of the > overall operating SYSTEM. > You are right in general, except one small factor. We are talking about bootstrap. CVS is used by many as the one of the ways to get the sources to the freshly installed system to recompile to the last available source. It will become inconvenient to do it through the process of installing some ports for that. Especially if corresponding ports would require some other ports as dependences. rik > > Doug > > From owner-freebsd-current@FreeBSD.ORG Sat Dec 3 13:30:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6441F106566B for ; Sat, 3 Dec 2011 13:30:17 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id BE71C8FC12 for ; Sat, 3 Dec 2011 13:30:16 +0000 (UTC) Received: (qmail 49223 invoked from network); 3 Dec 2011 13:03:34 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 3 Dec 2011 13:03:34 -0000 Date: Sat, 03 Dec 2011 14:03:34 +0100 (CET) Message-Id: <20111203.140334.74707074.sthaug@nethelp.no> To: freebsd-current@freebsd.org From: sthaug@nethelp.no In-Reply-To: <4ED9EA27.8090206@inse.ru> References: <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: CVS removal from the 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, 03 Dec 2011 13:30:17 -0000 > > The fact that we have so many people who are radically change-averse, no > > matter how rational the change; is a bug, not a feature. > > > > This particular bug is complicated dramatically by the fact that the > > majority view seems to lean heavily towards "If I use it, it must be the > > default and/or in the base" rather than seeing ports as part of the > > overall operating SYSTEM. I don't think of myself as change-averse. I've been using FreeBSD since 1996, and there have been lots of changes since that time. But two of the most important reasons I still use FreeBSD are: - Stability: Both in the sense of "stays up basically forever", and in the sense of "changes to interfaces and commands are carefully thought through and not applied indiscriminately". For instance, I like very much the fact that the ifconfig command can configure VLANs etc - while Linux has introduced new commands to do this. - The base system is a *system* and comes with most of what I need, for instance tcpdump and BIND. For me the fact that I don't need to install lots of packages to have a usable system is a *good* thing. > You are right in general, except one small factor. We are talking about > bootstrap. > CVS is used by many as the one of the ways to get the sources to the freshly > installed system to recompile to the last available source. It will > become inconvenient > to do it through the process of installing some ports for that. > Especially if corresponding > ports would require some other ports as dependences. I use CVS (or rather csup) to keep the base system up to date. I would be perfectly okay with using a different utility - however, I would strongly prefer that this utility was included in the base system. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-current@FreeBSD.ORG Sat Dec 3 14:48:31 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 583EE106566B for ; Sat, 3 Dec 2011 14:48:31 +0000 (UTC) (envelope-from rik@inse.ru) Received: from ns.rikbsd.org (ns.rikbsd.org [95.143.215.27]) by mx1.freebsd.org (Postfix) with ESMTP id 0A17B8FC13 for ; Sat, 3 Dec 2011 14:48:30 +0000 (UTC) Received: from [127.0.0.1] (wn.rikbsd.org [192.168.1.254]) by ns.rikbsd.org (Postfix) with ESMTPA id F1A6D5CEA3; Sat, 3 Dec 2011 15:41:09 +0000 (UTC) Message-ID: <4EDA36C0.7090109@inse.ru> Date: Sat, 03 Dec 2011 18:48:32 +0400 From: Roman Kurakin User-Agent: Thunderbird 2.0.0.24 (X11/20110906) MIME-Version: 1.0 To: Jase Thew References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <4ED9EAD0.3050207@beardz.net> In-Reply-To: <4ED9EAD0.3050207@beardz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current , Peter Jeremy , Max Khon Subject: Re: CVS removal from the 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, 03 Dec 2011 14:48:31 -0000 Jase Thew wrote: > On 03/12/2011 09:21, Roman Kurakin wrote: >> Doug Barton wrote: >>> [...] >>> The fact that we have so many people who are radically >>> change-averse, no >>> matter how rational the change; is a bug, not a feature. >>> >>> This particular bug is complicated dramatically by the fact that the >>> majority view seems to lean heavily towards "If I use it, it must be >>> the >>> default and/or in the base" rather than seeing ports as part of the >>> overall operating SYSTEM. >> You are right in general, except one small factor. We are talking about >> bootstrap. >> CVS is used by many as the one of the ways to get the sources to the >> freshly >> installed system to recompile to the last available source. It will >> become inconvenient >> to do it through the process of installing some ports for that. >> Especially if corresponding >> ports would require some other ports as dependences. > > As has been pointed out elsewhere in this thread, CVS doesn't cover > csup, a utility in base which allows you to obtain the source > trivially for the scenario you provide above. (Explicity ignoring > cvsup which requires a port). Does csup allows to checkout a random version from local cvs mirror? So better to say csup(cvsup) does not cover cvs. rik > Regards, > > Jase. From owner-freebsd-current@FreeBSD.ORG Sat Dec 3 15:23:05 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 583B31065670; Sat, 3 Dec 2011 15:23:05 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id E8B088FC14; Sat, 3 Dec 2011 15:23:04 +0000 (UTC) Received: by ggnp1 with SMTP id p1so1472973ggn.13 for ; Sat, 03 Dec 2011 07:23:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.45.6 with SMTP id i6mr507507obm.3.1322925783948; Sat, 03 Dec 2011 07:23:03 -0800 (PST) Received: by 10.182.76.225 with HTTP; Sat, 3 Dec 2011 07:23:03 -0800 (PST) X-Originating-IP: [80.89.199.122] In-Reply-To: <4ED9EA27.8090206@inse.ru> References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> Date: Sat, 3 Dec 2011 21:23:03 +0600 Message-ID: From: Max Khon To: Roman Kurakin Content-Type: text/plain; charset=UTF-8 Cc: Adrian Chadd , Doug Barton , Peter Jeremy , freebsd-current Subject: Re: CVS removal from the 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, 03 Dec 2011 15:23:05 -0000 Rik, On Sat, Dec 3, 2011 at 4:21 PM, Roman Kurakin wrote: >> The fact that we have so many people who are radically change-averse, no >> matter how rational the change; is a bug, not a feature. >> >> This particular bug is complicated dramatically by the fact that the >> majority view seems to lean heavily towards "If I use it, it must be the >> default and/or in the base" rather than seeing ports as part of the >> overall operating SYSTEM. >> > > You are right in general, except one small factor. We are talking about > bootstrap. > CVS is used by many as the one of the ways to get the sources to the freshly > installed system to recompile to the last available source. It will become > inconvenient > to do it through the process of installing some ports for that. Especially > if corresponding > ports would require some other ports as dependences. Do you really use CVS and not cvsup/csup? CVS != csup. Max From owner-freebsd-current@FreeBSD.ORG Sat Dec 3 15:24:51 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 763D0106566C for ; Sat, 3 Dec 2011 15:24:51 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3E14D8FC1C for ; Sat, 3 Dec 2011 15:24:51 +0000 (UTC) Received: by ggnp1 with SMTP id p1so1473791ggn.13 for ; Sat, 03 Dec 2011 07:24:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.16.101 with SMTP id f5mr492735obd.33.1322925890676; Sat, 03 Dec 2011 07:24:50 -0800 (PST) Received: by 10.182.76.225 with HTTP; Sat, 3 Dec 2011 07:24:50 -0800 (PST) X-Originating-IP: [80.89.199.122] In-Reply-To: <20111203.140334.74707074.sthaug@nethelp.no> References: <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <20111203.140334.74707074.sthaug@nethelp.no> Date: Sat, 3 Dec 2011 21:24:50 +0600 Message-ID: From: Max Khon To: sthaug@nethelp.no Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org Subject: Re: CVS removal from the 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, 03 Dec 2011 15:24:51 -0000 Hello! On Sat, Dec 3, 2011 at 8:03 PM, wrote: > I use CVS (or rather csup) to keep the base system up to date. I would > be perfectly okay with using a different utility - however, I would > strongly prefer that this utility was included in the base system. CVS != csup. I wonder how many people will express their sentiments about CVS when they really mean cvsup/csup. Max From owner-freebsd-current@FreeBSD.ORG Sat Dec 3 16:16:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7413106564A for ; Sat, 3 Dec 2011 16:16:47 +0000 (UTC) (envelope-from mailnull@mips.inka.de) Received: from mail-in-07.arcor-online.net (mail-in-07.arcor-online.net [151.189.21.47]) by mx1.freebsd.org (Postfix) with ESMTP id 60D568FC08 for ; Sat, 3 Dec 2011 16:16:47 +0000 (UTC) Received: from mail-in-20-z2.arcor-online.net (mail-in-20-z2.arcor-online.net [151.189.8.85]) by mx.arcor.de (Postfix) with ESMTP id D91F8107D39 for ; Sat, 3 Dec 2011 16:43:44 +0100 (CET) Received: from mail-in-09.arcor-online.net (mail-in-09.arcor-online.net [151.189.21.49]) by mail-in-20-z2.arcor-online.net (Postfix) with ESMTP id D5B5BE994E for ; Sat, 3 Dec 2011 16:43:44 +0100 (CET) Received: from lorvorc.mips.inka.de (dslb-188-105-080-134.pools.arcor-ip.net [188.105.80.134]) by mail-in-09.arcor-online.net (Postfix) with ESMTPS id 52E1C1977C1 for ; Sat, 3 Dec 2011 16:43:44 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-09.arcor-online.net 52E1C1977C1 Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.14.5/8.14.3) with ESMTP id pB3FhgC5002741 for ; Sat, 3 Dec 2011 16:43:42 +0100 (CET) (envelope-from mailnull@lorvorc.mips.inka.de) Received: (from mailnull@localhost) by lorvorc.mips.inka.de (8.14.5/8.14.5/Submit) id pB3FhgWH002740 for freebsd-current@freebsd.org; Sat, 3 Dec 2011 16:43:42 +0100 (CET) (envelope-from mailnull) From: naddy@mips.inka.de (Christian Weisgerber) Date: Sat, 3 Dec 2011 15:43:42 +0000 (UTC) Message-ID: References: Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-current@freebsd.org Subject: Re: CVS removal from the 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, 03 Dec 2011 16:16:47 -0000 Max Khon wrote: > As soon as ports/ (and doc/) are moved to SVN I do not see any > compelling reasons for keeping CVS in the base system. > Those who still use it for development can install ports/devel/opencvs Rather ports/devel/cvs-devel. Maybe we still need a regular cvs port. -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-current@FreeBSD.ORG Sat Dec 3 16:57:50 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71F661065675 for ; Sat, 3 Dec 2011 16:57:50 +0000 (UTC) (envelope-from sean@coreitpro.com) Received: from masakari.coreitpro.com (masakari.coreitpro.com [38.98.245.188]) by mx1.freebsd.org (Postfix) with ESMTP id 2140D8FC0C for ; Sat, 3 Dec 2011 16:57:49 +0000 (UTC) Received: from Uller.local (c-76-124-116-189.hsd1.pa.comcast.net [76.124.116.189]) (authenticated bits=0) by masakari.coreitpro.com (8.14.4/8.14.4) with ESMTP id pB3GU09L070677 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 3 Dec 2011 11:30:00 -0500 (EST) (envelope-from sean@coreitpro.com) Message-ID: <4EDA4E82.9040901@coreitpro.com> Date: Sat, 03 Dec 2011 11:29:54 -0500 From: "Sean M. Collins" Organization: Core IT Pro User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: In-Reply-To: X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: CVS removal from the 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, 03 Dec 2011 16:57:50 -0000 On 12/2/11 4:27 AM, Max Khon wrote: > In my opinion it is just another piece of bitrot that resides in the > base system for no real reasons. I agree, especially since all the development work is being done on SVN and then is exported back to CVS, if I am not mistaken[1]. We've done the hard part, moving the majority of development over to SVN. [1]: http://people.freebsd.org/~peter/svn_notes.txt -- Sean M. Collins From owner-freebsd-current@FreeBSD.ORG Sat Dec 3 17:14:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78117106564A for ; Sat, 3 Dec 2011 17:14:08 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 373968FC08 for ; Sat, 3 Dec 2011 17:14:07 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id pB3H1gCx040940; Sat, 3 Dec 2011 12:01:42 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Sat, 03 Dec 2011 12:01:42 -0500 (EST) Date: Sat, 3 Dec 2011 12:01:42 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Max Khon In-Reply-To: Message-ID: References: <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <20111203.140334.74707074.sthaug@nethelp.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, sthaug@nethelp.no Subject: Re: CVS removal from the base 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, 03 Dec 2011 17:14:08 -0000 On Sat, 3 Dec 2011, Max Khon wrote: > Hello! > > On Sat, Dec 3, 2011 at 8:03 PM, wrote: > >> I use CVS (or rather csup) to keep the base system up to date. I would >> be perfectly okay with using a different utility - however, I would >> strongly prefer that this utility was included in the base system. > > CVS != csup. > > I wonder how many people will express their sentiments about CVS when > they really mean cvsup/csup. We also use CVS (not cvsup/csup) after installing a fresh system. We mirror the CVS repo on an internal machine, then use CVS to checkout the latest HEAD or -stable from the internal mirror. The checkout from the internal mirror is much faster than trying to do it over our internet link (and that doesn't always work - we may not even be connected to the internet at times). Note that no ports are needed to update a system in this scenario. Also note that I can checkout any branch or from any known good date where the system builds and works. I would love to mirror the SVN repo in the same way and have an 'svn' in base, or at least something that could replace CVS in the above scenario. -- DE From owner-freebsd-current@FreeBSD.ORG Sat Dec 3 17:22:20 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA8E8106564A for ; Sat, 3 Dec 2011 17:22:20 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 728278FC17 for ; Sat, 3 Dec 2011 17:22:20 +0000 (UTC) Received: by ggnp1 with SMTP id p1so1541038ggn.13 for ; Sat, 03 Dec 2011 09:22:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.188.34 with SMTP id fx2mr550047obc.31.1322932939613; Sat, 03 Dec 2011 09:22:19 -0800 (PST) Received: by 10.182.187.8 with HTTP; Sat, 3 Dec 2011 09:22:19 -0800 (PST) X-Originating-IP: [93.221.167.98] In-Reply-To: References: Date: Sat, 3 Dec 2011 18:22:19 +0100 Message-ID: From: "C. P. Ghost" To: Max Khon Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current Subject: Re: CVS removal from the 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, 03 Dec 2011 17:22:20 -0000 On Fri, Dec 2, 2011 at 10:27 AM, Max Khon wrote: > Hello! > > I know that it is too early to speak about this, but I would like the > dust in the mailing lists to settle down before real actions can be > taken. > > As soon as ports/ (and doc/) are moved to SVN I do not see any > compelling reasons for keeping CVS in the base system. > Those who still use it for development can install ports/devel/opencvs > (like all the src/ developers do for ports/devel/subversion/). > > In my opinion it is just another piece of bitrot that resides in the > base system for no real reasons. This "bitrot" is being used daily here. And very heavily at that, thank you very much. Not every CVS repo is easily converted into newfangled SVN, GIT, Mercurial etc.. repos; thus moving away from CVS in real life is sometimes pretty painful, if not utterly impossible (without heavy hacking and tweaking). I realize how much better and easier to use those new SCMs are, but CVS still has its uses. Please refrain from killing functionality that is often needed out-of-the-box on machines with no ports installed. I understand the desire to move as much as possible from our userland to ports and to end up with a minimal system, but isn't this getting a bit too eager? > Max Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ From owner-freebsd-current@FreeBSD.ORG Sat Dec 3 17:58:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FFC4106564A; Sat, 3 Dec 2011 17:58:52 +0000 (UTC) (envelope-from rik@inse.ru) Received: from ns.rikbsd.org (ns.rikbsd.org [95.143.215.27]) by mx1.freebsd.org (Postfix) with ESMTP id 0B4CE8FC12; Sat, 3 Dec 2011 17:58:51 +0000 (UTC) Received: from [127.0.0.1] (wn.rikbsd.org [192.168.1.254]) by ns.rikbsd.org (Postfix) with ESMTPA id 7CD2A5CE1E; Sat, 3 Dec 2011 18:59:19 +0000 (UTC) Message-ID: <4EDA6532.3030601@inse.ru> Date: Sat, 03 Dec 2011 22:06:42 +0400 From: Roman Kurakin User-Agent: Thunderbird 2.0.0.24 (X11/20110906) MIME-Version: 1.0 To: Max Khon References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , Doug Barton , Peter Jeremy , freebsd-current Subject: Re: CVS removal from the 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, 03 Dec 2011 17:58:52 -0000 Max Khon wrote: > Rik, > > On Sat, Dec 3, 2011 at 4:21 PM, Roman Kurakin wrote: > > >>> The fact that we have so many people who are radically change-averse, no >>> matter how rational the change; is a bug, not a feature. >>> >>> This particular bug is complicated dramatically by the fact that the >>> majority view seems to lean heavily towards "If I use it, it must be the >>> default and/or in the base" rather than seeing ports as part of the >>> overall operating SYSTEM. >>> >>> >> You are right in general, except one small factor. We are talking about >> bootstrap. >> CVS is used by many as the one of the ways to get the sources to the freshly >> installed system to recompile to the last available source. It will become >> inconvenient >> to do it through the process of installing some ports for that. Especially >> if corresponding >> ports would require some other ports as dependences. >> > Do you really use CVS and not cvsup/csup? CVS != csup. > I use ctm/csup to get(update) CVS source tree and cvs to checkout the exact version I need. Having cvs tree locally it is more convenient to keep one central repo for updating local systems based on different branches and to roll back a little bit for example with the ports tree in case I can't upgrade all needed ports to "current" for some reasons and got some problems with dependences. I can have what ever development system on the development machine, but unlikely I'll have one on all production systems by default since of additional potentially buggy packages, additional dependences, additional upgrade problems etc. rik > Max > _______________________________________________ > 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 Sat Dec 3 19:00:15 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F298106566C; Sat, 3 Dec 2011 19:00:15 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id DA2EA8FC0C; Sat, 3 Dec 2011 19:00:14 +0000 (UTC) Received: by iafi7 with SMTP id i7so870317iaf.13 for ; Sat, 03 Dec 2011 11:00:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/Z08idJ1FtZCUwmO7e3KhKDzVI9WqOTgBMOXSVRo3jM=; b=DRiLDgEKEPuGrkektdHjqBwKNWSzbwusZbwDq5xlvBsaqsQx9ZEWJ6I0w87Iynr7pu 4Ugx4Adh7aD1gRhxmOE9VjJ5X2uVn8ZKD0jAT15BqSfC2pNfqmHIhg2985hN5HR6W3C8 j457N3EpQgEh7VDi4ad/XInmhM6GXIQlHyeIE= MIME-Version: 1.0 Received: by 10.50.51.234 with SMTP id n10mr3881394igo.10.1322938814152; Sat, 03 Dec 2011 11:00:14 -0800 (PST) Received: by 10.231.171.82 with HTTP; Sat, 3 Dec 2011 11:00:14 -0800 (PST) In-Reply-To: <4ED9EA27.8090206@inse.ru> References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> Date: Sat, 3 Dec 2011 11:00:14 -0800 Message-ID: From: Kevin Oberman To: Roman Kurakin Content-Type: text/plain; charset=ISO-8859-1 Cc: Adrian Chadd , Doug Barton , Max Khon , Peter Jeremy , freebsd-current Subject: Re: CVS removal from the 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, 03 Dec 2011 19:00:15 -0000 On Sat, Dec 3, 2011 at 1:21 AM, Roman Kurakin wrote: > Doug Barton wrote: >> >> [...] >> The fact that we have so many people who are radically change-averse, no >> matter how rational the change; is a bug, not a feature. >> >> This particular bug is complicated dramatically by the fact that the >> majority view seems to lean heavily towards "If I use it, it must be the >> default and/or in the base" rather than seeing ports as part of the >> overall operating SYSTEM. >> > > You are right in general, except one small factor. We are talking about > bootstrap. > CVS is used by many as the one of the ways to get the sources to the freshly > installed system to recompile to the last available source. It will become > inconvenient > to do it through the process of installing some ports for that. Especially > if corresponding > ports would require some other ports as dependencies. I have to agree with Roman. It's simply far too early to think of removing cvs from the base OS. If we can come up with a way to replace the functionality of csup with svn under it, that would be great, but it may be a long time coming. Until it does, cvs needs to remain with all of the awkwardness of maintaining cvs when the actual source of truth is in svn. The time will hopefully come, but I don't see it in the 10.0 time frame. OTOH, I can see Doug's argument. I'm sure that, even when no real need exists for CVS in the base, I imagine there will be loud objections to its removal, though I suspect Doug's comments were largely spawned by the debate on the default setting for building profile libraries. (And, IMHO, Doug is right on that one.) -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Sat Dec 3 19:57:01 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 210EB106577D for ; Sat, 3 Dec 2011 19:57:00 +0000 (UTC) (envelope-from giffunip@tutopia.com) Received: from nm16-vm3.bullet.mail.ne1.yahoo.com (nm16-vm3.bullet.mail.ne1.yahoo.com [98.138.91.146]) by mx1.freebsd.org (Postfix) with SMTP id 74E5F8FC14 for ; Sat, 3 Dec 2011 19:57:00 +0000 (UTC) Received: from [98.138.90.48] by nm16.bullet.mail.ne1.yahoo.com with NNFMP; 03 Dec 2011 19:56:59 -0000 Received: from [98.138.89.175] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 03 Dec 2011 19:56:59 -0000 Received: from [127.0.0.1] by omp1031.mail.ne1.yahoo.com with NNFMP; 03 Dec 2011 19:56:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 755868.15764.bm@omp1031.mail.ne1.yahoo.com Received: (qmail 8024 invoked by uid 60001); 3 Dec 2011 19:56:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1322942219; bh=WfkagmK896WwIOphO/1ZmDCDFA+qh4qBWUHKwWMTEFY=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=I2iK3djgWKh36u+O37gC1zlNweXwxp1A1n7WY2yCXtZQKIYO79tZx++/cVN9t3BNzjgc1/JBMeFmH5EmDWXRaqtKng9mKkDHCGedDoFizmVN12fgp05RS/ZNZE9+PcBWmoEde0XFyUFQ/I41gnQWoUU1V1JFD1a/NJrESQcQym0= X-YMail-OSG: hEE9530VM1lot_0ut1AfwCf4yNp.BUEeG9FOROUHSkNxPRh qMQlrJhw0CNptKcCUAiWolIsUDZFpis1XbmpfbtzGYs1K.O57W8ij96Y9ciQ frjIBST7ggPJZBL0RmJy9mOo_R6KqGMDFyw98pTdQmugy_sE7cIVSKSubXMT 3NPd3rejOfO8RAQdcKdQQT6t5QA7M90fy4qTGQ7W1emdz24O529BmW2ryDNM AckpLs_3QMH3T4kRieaDr8TPmosd8zUzTLkPyH6tTt5r26zd6Fe1AuNFX2Bu .hND5RE9O.GZ.FL8VjlzSrWpheU_qE2Nga3u.87XiRVMcd9hj0Q3GLhtK0dF hnmoIMytd853RaY_wP5_M3a64O08PCu737s8IehAsq41QkJqEPYb2lqy6KPi a2CMCEllguPDvIR.5M.lnbFkMnemAtPyNf.EadUTanMlGDlnhKPw.sZt5ejl NRCnU.8JBJ1Y5V6L.cDcXj5NSDw-- Received: from [200.118.157.7] by web113505.mail.gq1.yahoo.com via HTTP; Sat, 03 Dec 2011 11:56:58 PST X-RocketYMMF: giffunip X-Mailer: YahooMailClassic/15.0.4 YahooMailWebService/0.8.115.331698 Message-ID: <1322942218.7666.YahooMailClassic@web113505.mail.gq1.yahoo.com> Date: Sat, 3 Dec 2011 11:56:58 -0800 (PST) From: "Pedro F. Giffuni" To: Max Khon , Daniel Eischen In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: giffunip@tutopia.com 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 Dec 2011 19:57:01 -0000 Hi Daniel;=0A=0A--- On Sat, 12/3/11, Daniel Eischen = wrote:=0A...=0A> =0A> I would love to mirror the SVN repo in the same way= =0A> and have an 'svn' in base, or at least something that=0A> could replac= e CVS in the above scenario.=0A>=0A=0AI have to say I am surprised by all t= he people that=0Astill use CVS (for their own good reasons).=0A=0AIt still = would be helpful if cvs users could evaluate=0AOpenCVS: it's been experimen= tal for ages now. It does=0Aseem to have some advantage (other than the lic= ense)=0Ain that it's smaller and better maintained (or at=0Aleast not too d= ead).=0A=0Acheers,=0A=0APedro.=0A From owner-freebsd-current@FreeBSD.ORG Sat Dec 3 19:28:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1BA3106564A for ; Sat, 3 Dec 2011 19:28:13 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7AF888FC08 for ; Sat, 3 Dec 2011 19:28:13 +0000 (UTC) Received: by wgbdr11 with SMTP id dr11so3988324wgb.31 for ; Sat, 03 Dec 2011 11:28:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=MYA3lTyHqDsZl3spL/KWFPtDCKhZWRcSBpweEJ91NwQ=; b=GJOffAMOiLY6SUx1WemJAldP/BlAev7LE0CAM+IMwdhS05RMNHjnBFUsL4lrBkHwOZ Yg6A2VXPzJlz8OKVws0Kil9ORil5RyHFu+6Sdsytf9LtyToRTBfzMfuHCQiQ7+mTZ9Iz Ik03i5esShOEVn5ap2ziVgwNtkAikk2jb1xFc= MIME-Version: 1.0 Received: by 10.227.199.78 with SMTP id er14mr2971756wbb.10.1322938943923; Sat, 03 Dec 2011 11:02:23 -0800 (PST) Received: by 10.180.95.137 with HTTP; Sat, 3 Dec 2011 11:02:23 -0800 (PST) Date: Sat, 3 Dec 2011 14:02:23 -0500 Message-ID: From: grarpamp To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Sat, 03 Dec 2011 20:18:20 +0000 Subject: Third party apps in base [was CVS removal...] 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 Dec 2011 19:28:14 -0000 Hi. I have many dependencies on CVS that I 'need' 'out of the box'. Yet at the same time, I would not mind at all if it went to ports. In fact, and from a general position regarding all third party apps, I encourage it. Mostly because they are not authored or maintained by FreeBSD. Yet they are integrated, often in ways that need work to remove and/or manage separately. Such as when the upstream drops a feature version and FreeBSD only drops security/stability patches. If a lighter method than ports is desired, all the third party apps have binary packages (/pub/FreeBSD/ports/packages/All). And even pkg_add can be skipped if that's too heavy. The bit of extra work at install time isn't much, especially when your install already does a bunch of scripted localization. And as an aside, with what to this writer seems to be the majority of the world moving to git... I think it should now properly become user/admin choice as to which to install from ports/packages/source. Rather than say, being equally agnostic/fair in the other direction by including them all to satisfy all whims. The only justified exception I see would be to include whichever one is used by the master repository itself, which today is SVN. And as a topic for another thread, I think even that should be switched to git within the next couple years. And as another topic for another thread... the same goes for the various current methods of source (and other) distribution of the FreeBSD project. I'd be quite happy to see rsync become authoritative and even replace all of them. Lastly, regarding baking and planning... making more use of the wiki to document the FreeBSD timeline would be interesting. While distant dates my not be known, features and dependancies usually are. From owner-freebsd-current@FreeBSD.ORG Sat Dec 3 20:23:48 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1389106564A for ; Sat, 3 Dec 2011 20:23:48 +0000 (UTC) (envelope-from michiel@boland.org) Received: from smtp-vbr14.xs4all.nl (smtp-vbr14.xs4all.nl [194.109.24.34]) by mx1.freebsd.org (Postfix) with ESMTP id 717C98FC0C for ; Sat, 3 Dec 2011 20:23:47 +0000 (UTC) Received: from charlemagne.boland.org (59-36-215.ftth.xms.internl.net [82.215.36.59]) (authenticated bits=0) by smtp-vbr14.xs4all.nl (8.13.8/8.13.8) with ESMTP id pB3K373U080271 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sat, 3 Dec 2011 21:03:13 +0100 (CET) (envelope-from michiel@boland.org) Message-ID: <4EDA807B.4080202@boland.org> Date: Sat, 03 Dec 2011 21:03:07 +0100 From: Michiel Boland User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.24) Gecko/20111110 Thunderbird/3.1.16 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4EDA4E82.9040901@coreitpro.com> In-Reply-To: <4EDA4E82.9040901@coreitpro.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner X-Mailman-Approved-At: Sat, 03 Dec 2011 22:16:02 +0000 Subject: Re: CVS removal from the 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, 03 Dec 2011 20:23:49 -0000 On 12/03/2011 17:29, Sean M. Collins wrote: [...] > all the development work is being done on SVN > and then is exported back to CVS, if I am not mistaken[1]. [...] Aren't ports still updated with CVS? Cheers Michiel From owner-freebsd-current@FreeBSD.ORG Sat Dec 3 22:45:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0EF9106566C for ; Sat, 3 Dec 2011 22:45:35 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id A2F0F8FC16 for ; Sat, 3 Dec 2011 22:45:35 +0000 (UTC) Received: by ggnp1 with SMTP id p1so1684068ggn.13 for ; Sat, 03 Dec 2011 14:45:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QEPiyzNocKLnl08p2fv7Y9ux63WoTLHETIbDmj1AK+8=; b=QyvSlp8v+k5Vp0tiGTOupezywuVt+lX5nVJKNN3HgWepIRzoP/d6Qy30KBJazfzfnz pVCG9FnbLX3bsDj06pqaS6UkzgCYG3o/l7oq2R46c+BmoFghEuystNZk1eCtdumO/Y8u /pewwxV+z8+o/KNSX62PSFPs7yO2v3fbYMnjU= MIME-Version: 1.0 Received: by 10.182.218.100 with SMTP id pf4mr698780obc.12.1322952335052; Sat, 03 Dec 2011 14:45:35 -0800 (PST) Received: by 10.182.62.227 with HTTP; Sat, 3 Dec 2011 14:45:34 -0800 (PST) In-Reply-To: <4EDA807B.4080202@boland.org> References: <4EDA4E82.9040901@coreitpro.com> <4EDA807B.4080202@boland.org> Date: Sat, 3 Dec 2011 14:45:34 -0800 Message-ID: From: Garrett Cooper To: Michiel Boland Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: CVS removal from the 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, 03 Dec 2011 22:45:36 -0000 On Sat, Dec 3, 2011 at 12:03 PM, Michiel Boland wrote: > On 12/03/2011 17:29, Sean M. Collins wrote: > [...] > >> all the development work is being done on SVN >> and then is exported back to CVS, if I am not mistaken[1]. > > [...] > > Aren't ports still updated with CVS? Just to back up that point: until CVS is completely unused by releng (docs, ports are still done via CVS), it really shouldn't be removed from base (no matter how broken or undeveloped it is). WITHOUT_CVS (assuming that the knob actually works as advertised unlike many of our other knobs -- which last time I checked did in fact work) in /etc/src.conf suffices for now. Thanks, -Garrett I used to work with a group that used CVS extensively for managing changes to FreeBSD. It made my life a lot easier when we need to evaluate changes to code with FreeBSD to ensure we were license compliant.. it was very difficult to have to wade through with Protex Blackduck because it tosses up a ton of false positives, so any way we could avoid doing that by using an SCM that produces sane output which cv?sup doesn't currently do, all for the better. From owner-freebsd-current@FreeBSD.ORG Sat Dec 3 23:01:38 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBBBD106564A for ; Sat, 3 Dec 2011 23:01:38 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from phoenix.eternamente.info (phoenix.eternamente.info [109.169.62.232]) by mx1.freebsd.org (Postfix) with ESMTP id A67CA8FC08 for ; Sat, 3 Dec 2011 23:01:38 +0000 (UTC) Received: by phoenix.eternamente.info (Postfix, from userid 80) id C75FB1CC6C; Sat, 3 Dec 2011 20:01:34 -0300 (BRT) Received: from 186.214.130.125 (SquirrelMail authenticated user matheus) by eternamente.info with HTTP; Sat, 3 Dec 2011 21:01:34 -0200 Message-ID: <44b3c0f48d1cf64cc9237881c43c2be4.squirrel@eternamente.info> Date: Sat, 3 Dec 2011 21:01:34 -0200 From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Sil3124 + Sil4726 PortMultipier and FreeBSD9 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 Dec 2011 23:01:38 -0000 hail, I've heard great things about sil3124 and FreeBSD 8+ (saw mav@ talking in lists and forum). But I'm planning a home server, I already have an Atom board from Intel (old Atom 330), Soekris 6501-70 and Sil3124 PCI. I saw that both ICH7 and NM10 can't deal with port multipliers, so my focus is on the Sil3124 now. I heard from internet that Sil4726+SIl3124 got random resets, although that was some time ago and on linux lists. So as I'm about to buy the Port Multiplier, and as I'll run FreeBSD 9 on it, anyone here have any experiences on this regard and is willing to share ? this is a small footprint server, I plan to have 6-8 disks and may become ZFS based. I plan to buy this port multiplier http://www.addonics.com/products/ad5sahpm-ea.php thanks, matheus -- Vítima da Oi entre 2007 e 2011. We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-current@FreeBSD.ORG Sat Dec 3 23:06:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B857106564A for ; Sat, 3 Dec 2011 23:06:25 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id C39A88FC13 for ; Sat, 3 Dec 2011 23:06:24 +0000 (UTC) Received: by ggnp1 with SMTP id p1so1692360ggn.13 for ; Sat, 03 Dec 2011 15:06:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yaWCwHbOIhQlF5ePEHdHrfIBcVcJ4bUajfxkjdODCK0=; b=ZenhPcKTZj6wLgaRqij1OVJhgidZGaQfAAuiqbilcn4yUi9up/7uOyzbIFQjgg0pog fiewLr1EyNEen0Im/oxN7yNyMOHsEMeDBZG59HLXqgYf5AXAXhQeqrMEdfwMklBOTjcj XUCxAuY5K72+edH8TFuvVnUNU/0obgKQrOvaA= MIME-Version: 1.0 Received: by 10.182.154.66 with SMTP id vm2mr691410obb.52.1322953584006; Sat, 03 Dec 2011 15:06:24 -0800 (PST) Received: by 10.182.62.227 with HTTP; Sat, 3 Dec 2011 15:06:23 -0800 (PST) In-Reply-To: <44b3c0f48d1cf64cc9237881c43c2be4.squirrel@eternamente.info> References: <44b3c0f48d1cf64cc9237881c43c2be4.squirrel@eternamente.info> Date: Sat, 3 Dec 2011 15:06:23 -0800 Message-ID: From: Garrett Cooper To: Nenhum_de_Nos Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Sil3124 + Sil4726 PortMultipier and FreeBSD9 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 Dec 2011 23:06:25 -0000 On Sat, Dec 3, 2011 at 3:01 PM, Nenhum_de_Nos wrote: > hail, > > I've heard great things about sil3124 and FreeBSD 8+ (saw mav@ talking in lists and forum). But > I'm planning a home server, I already have an Atom board from Intel (old Atom 330), Soekris > 6501-70 and Sil3124 PCI. I saw that both ICH7 and NM10 can't deal with port multipliers, so my > focus is on the Sil3124 now. I heard from internet that Sil4726+SIl3124 got random resets, > although that was some time ago and on linux lists. > > So as I'm about to buy the Port Multiplier, and as I'll run FreeBSD 9 on it, anyone here have any > experiences on this regard and is willing to share ? > > this is a small footprint server, I plan to have 6-8 disks and may become ZFS based. > > I plan to buy this port multiplier http://www.addonics.com/products/ad5sahpm-ea.php What are your requirements (need compile toolchain, needs to be a fileserver, etc)? Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Dec 3 23:10:48 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22579106566B for ; Sat, 3 Dec 2011 23:10:48 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from phoenix.eternamente.info (phoenix.eternamente.info [109.169.62.232]) by mx1.freebsd.org (Postfix) with ESMTP id F177F8FC08 for ; Sat, 3 Dec 2011 23:10:45 +0000 (UTC) Received: by phoenix.eternamente.info (Postfix, from userid 80) id BBC021CC6C; Sat, 3 Dec 2011 20:10:41 -0300 (BRT) Received: from 186.214.130.125 (SquirrelMail authenticated user matheus) by eternamente.info with HTTP; Sat, 3 Dec 2011 21:10:41 -0200 Message-ID: <30c6076d340bdb3546054609939139c6.squirrel@eternamente.info> In-Reply-To: References: <44b3c0f48d1cf64cc9237881c43c2be4.squirrel@eternamente.info> Date: Sat, 3 Dec 2011 21:10:41 -0200 From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: Sil3124 + Sil4726 PortMultipier and FreeBSD9 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 Dec 2011 23:10:48 -0000 On Sat, December 3, 2011 21:06, Garrett Cooper wrote: > On Sat, Dec 3, 2011 at 3:01 PM, Nenhum_de_Nos wrote: >> hail, >> >> I've heard great things about sil3124 and FreeBSD 8+ (saw mav@ talking in lists and forum). But >> I'm planning a home server, I already have an Atom board from Intel (old Atom 330), Soekris >> 6501-70 and Sil3124 PCI. I saw that both ICH7 and NM10 can't deal with port multipliers, so my >> focus is on the Sil3124 now. I heard from internet that Sil4726+SIl3124 got random resets, >> although that was some time ago and on linux lists. >> >> So as I'm about to buy the Port Multiplier, and as I'll run FreeBSD 9 on it, anyone here have >> any >> experiences on this regard and is willing to share ? >> >> this is a small footprint server, I plan to have 6-8 disks and may become ZFS based. >> >> I plan to buy this port multiplier http://www.addonics.com/products/ad5sahpm-ea.php > > What are your requirements (need compile toolchain, needs to be a > fileserver, etc)? Mail purpose is fileserver. As my current fileserver is underused, it also servers some mail backup, svn, http and some other light use services. As a fileserver, it has a half dozen clients, the other services, almost just me. thanks, matheus -- Vítima da Oi entre 2007 e 2011. We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style