From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 1 22:05:33 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B834549F; Sun, 1 Dec 2013 22:05:33 +0000 (UTC) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 707BE1CA4; Sun, 1 Dec 2013 22:05:33 +0000 (UTC) Received: by mail-pd0-f175.google.com with SMTP id w10so16650439pde.6 for ; Sun, 01 Dec 2013 14:05:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e1cv8YIMheI3OX3t9bbbaK+qTT2rZOgfN6/cxwukZW4=; b=uu6dUrTOgayKTn2DknVn8hnKtiPT74uDuotg4A1gTnNQEsMgL7j2tTrc9y+Py/DkUA MI2IHemiOb/7gnFpg64vRtvV4rggDXNaDpGdw3NRXmcwefP3khY8IKL7LIn8Rn8UWSEl 5/swyABTG4lJDxFFGTqLX+YHjnzkzkUI2d5I7eKmZEFUIIPKFqwzgDhcc1bdbqNDGxD8 7nidt3tPNdgC7JkfgD6WJ5PFNgkITz3UItLOb7NYAUOqz65KaurN39ICckhmd/XnfMz/ 44z0hstTvvJecUi90fHghFAfpX9HbvcpfM3jiSEdbmurUUus0GKMLp4S6N950IKRnq7d HoBA== MIME-Version: 1.0 X-Received: by 10.68.232.37 with SMTP id tl5mr27972344pbc.86.1385935532994; Sun, 01 Dec 2013 14:05:32 -0800 (PST) Received: by 10.70.64.132 with HTTP; Sun, 1 Dec 2013 14:05:32 -0800 (PST) In-Reply-To: <706707CA-BD52-4814-BCCE-EB044B062BA6@kientzle.com> References: <718836647.19911209.1385302696963.JavaMail.root@uoguelph.ca> <706707CA-BD52-4814-BCCE-EB044B062BA6@kientzle.com> Date: Sun, 1 Dec 2013 23:05:32 +0100 Message-ID: Subject: Re: O_XATTR support in FreeBSD? From: Lionel Cons To: Tim Kientzle Content-Type: text/plain; charset=ISO-8859-1 Cc: Rick Macklem , Cedric Blancher , Freebsd hackers list , Richard Yao , Pedro Giffuni , Jordan Hubbard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 22:05:33 -0000 On 27 November 2013 05:52, Tim Kientzle wrote: > > On Nov 26, 2013, at 1:51 AM, Cedric Blancher wrote: > >> 5. Support for tar and pax is already there. Its described in >> Solaris's fsattr man page, they use a extended header with filename >> /dev/null (to prevent older tar versions from tripping over the new >> headers) and then have a named attribute header which describes the >> attributes names and flags. > > There are quite a few alternative approaches for storing > extended attributes in tar and pax files. But this discussion is *not* about extended attributes, this discussion is about Alternate Data Streams. Unfortunately the O_XATTR discussion somehow started to cover the Linux "extended attribute system", which is utterly useless in the intended use cases (as said, no access through normal POSIX read(), write(), mmap(), no unlimited size, no sparse data support (aka SEEK_HOLE, SEEK_DATA) etc etc). Lionel From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 1 23:19:54 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 63372E80; Sun, 1 Dec 2013 23:19:54 +0000 (UTC) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 28B2B1F57; Sun, 1 Dec 2013 23:19:54 +0000 (UTC) Received: by mail-pb0-f52.google.com with SMTP id uo5so17653399pbc.11 for ; Sun, 01 Dec 2013 15:19:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/lH2oZtp5dUpEp/C/QlTGIs4+z89aPXlT6NuyuULmNs=; b=oz0V/Nl9Tg2MTeMHqxKKRYHQjNSImPOT/gvUHYvNQw17CpycKRmG81nn5EVFCKwhEr VWtVImttRg0vEmRGMM8siHXp7aBPRgjY0uliP3TejnQ/hFPJdLftv9kHEOjB37qZyH0O Yrh1QoyLkX0COE6k4oVRXjqe5tU3USjeKGVVeLVX9P4OROK9reuQ8cdq3JZiGqYtzF3T 3CQ72ydR/GcwpE/YT5J556PJH4tgb2un4qRPma1+A2dgBfbvyPkme4DnB6i051vjfHlL gCcVOKw8I+qT/bQgwlcrewZc0OoTdtpJzATtq7hepaMUgqMJBsU6GtfHB9fmTwxdF031 gkPA== X-Received: by 10.66.197.135 with SMTP id iu7mr226096pac.149.1385939993701; Sun, 01 Dec 2013 15:19:53 -0800 (PST) Received: from [10.20.30.11] (75-101-82-48.static.sonic.net. [75.101.82.48]) by mx.google.com with ESMTPSA id sg1sm117872406pbb.16.2013.12.01.15.19.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Dec 2013 15:19:52 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Extended Attributes and how to avoid them (was Re: O_XATTR support in FreeBSD?) From: Jordan Hubbard In-Reply-To: Date: Sun, 1 Dec 2013 15:19:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <92F46317-D62D-4E19-B687-2A392309A244@mail.turbofuzz.com> References: <718836647.19911209.1385302696963.JavaMail.root@uoguelph.ca> <706707CA-BD52-4814-BCCE-EB044B062BA6@kientzle.com> To: Lionel Cons X-Mailer: Apple Mail (2.1822) Cc: Rick Macklem , Cedric Blancher , Freebsd hackers list , Richard Yao , Pedro Giffuni X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 23:19:54 -0000 On Dec 1, 2013, at 2:05 PM, Lionel Cons = wrote: > But this discussion is *not* about extended attributes, this > discussion is about Alternate Data Streams. Unfortunately the O_XATTR > discussion somehow started to cover the Linux "extended attribute > system", which is utterly useless in the intended use cases (as said, > no access through normal POSIX read(), write(), mmap(), no unlimited > size, no sparse data support (aka SEEK_HOLE, SEEK_DATA) etc etc). I think this discussion doesn't really *know* what it's about, frankly, = because there are so many possible avenues to choose from! :-) As we saw earlier, there is apparently some interest in supporting ADS = for Windows clients, though the question of how to actually add that = support seems primarily the job of Samba (or whatever BSD-licensed = equivalent someday emerges), so there's really not much to discuss there = from FreeBSD's perspective since FreeBSD itself has little to say on the = subject. If native CIFS support ever becomes a possibility, I'm sure it = will come up again! Then there's the whole topic of EAs (and I don't know who said Linux EAs = represented some sort of gold standard - I certainly didn't) and what = the intended use cases are. Let's stick with the intended (and = citable) use cases, if you please, because a lot of academic debate over = the years about "how EAs should work" has been, to be perfectly honest, = ultimately *pointless*. Academically speaking, there's nothing you can = do with an EA that you can't conceptually do just as well, if not = better, with a detached attribute database because academics don't have = to worry about their EAs working anywhere outside a laboratory setting! It's the *pragmatic* discussions and clearly defined use cases that = carry more weight (if not ALL the weight) - that's where you get into = real-world concerns about EAs and how to avoid them and their associated = files parting company, how to serialize and back them up, what clients = are *actually* going to use them and what APIs they need, etc. etc. Since you brought up POSIX APIs, let's talk about that for a second. = I've worked with EAs "in the field", as it were, a lot (a LOT) and no = one during my long history with them has ever demanded the ability to = call read() or write() on an EA, to mmap() one, or to store sparse data = in one. I would love to know which apps actually need to do that (and = why), because other than "unlimited size", none of those demands have = ever hit any bug database I've had access to. I'm also generally not = one to throw marketing numbers around in a technical conversation, but = with 72 million seats and over 1 million applications (and by all means = fact-check those numbers), if the ability to use EAs in that fashion = were truly necessary, I suspect I would have heard that early and often. = If anything, the trend has been in the other direction - people want a = simple file property getting/setting API that maybe uses EAs under the = covers or maybe it doesn't, all they know is that they can hand the API = a file handle (or path) and a dictionary and The Right Thing happens for = storing the EAs, the converse also being true for getting them. EAs = just are not first-class filesystem citizens and, frankly, they don't = really need to be in order to be "useful enough" for those situations = where an application or bit of OS middleware really needs a way of = storing some extended metadata for a file in a filesystem-neutral = fashion (and we've already covered the network filesystem and archiver = scenarios which make that important). I'll opine that If FreeBSD really wants to support EAs in a "useful = enough" way, then the best way of doing so is to stay focused on the = pragmatic "this our usage cases, and we are not afraid to describe them = in detail!" side of the street because, as I said, the academic = discussions generally don't lead anywhere but in circles. A pragmatic = approach will, conversely, lead to doing just the basic minimums and not = waste time implementing anything that won't actually be needed in = real-world scenarios. Heck, if we really want to get all academic about something here, let's = forget about EAs and ADS as comparatively uninteresting technologies = from the 90's and start talking instead about file object stores that = are far more flexible than what we have now! I don't want to have my filesystem view be necessarily hierarchical = (that should be a policy decision, not intrinsic to the filesystem = itself). I don't want any process to necessarily be able to see any = part of the file object space save that which I explicitly grant it or = its children. I don't want to have to think about where a file object = lives - I'd like it to be able to move around (memory, on-disk, "the = cloud", etc) purely in response to how "hot" it is without me having to = know or care about anything other than the object changing out from = under me (which should also be an intrinsic part of the filesystem = access APIs). I want file objects to be able to have arbitrary = properties of any type or size, and able to reference other file = objects, such that I don't have to keep side-stores around everywhere to = facilitate a lot of basic operations (like searching) that should be = intrinsic to the object store, or at least handled by a first class OS = service with the ability to be co-resident with it so things like = indexing are actually *efficient*. Can we have that discussion instead? It would be more fun. :-) - Jordan From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 2 00:25:43 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 001394B8; Mon, 2 Dec 2013 00:25:42 +0000 (UTC) Received: from smtpauth4.wiscmail.wisc.edu (wmauth4.doit.wisc.edu [144.92.197.145]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C196B11A8; Mon, 2 Dec 2013 00:25:42 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth4.wiscmail.wisc.edu by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MX500800KOXQI00@smtpauth4.wiscmail.wisc.edu>; Sun, 01 Dec 2013 18:25:40 -0600 (CST) X-Spam-PmxInfo: Server=avs-4, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.2.1814, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from comporellon.tachypleus.net (adsl-76-208-69-44.dsl.mdsnwi.sbcglobal.net [76.208.69.44]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MX50079ML6RPF00@smtpauth4.wiscmail.wisc.edu>; Sun, 01 Dec 2013 18:25:40 -0600 (CST) Message-id: <529BD383.508@freebsd.org> Date: Sun, 01 Dec 2013 18:25:39 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 To: Aleksander , freebsd-hackers@freebsd.org Subject: Re: modyfing cross toolchain compilation References: In-reply-to: X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 00:25:43 -0000 On 10/21/13 01:38, Aleksander wrote: > hello! > > Few days ago, when playing with linux-ppc, I have identified a bug with > PowerPC toolchain. It turns out that PowerPC e500 core is not compilant > with generic ppc ISA - it lacks of 'lwsync' instruction. This instruction > is used in libstdc++.so library, so I need to modify toolchain build > process by adding -me500v2 option, when building libraries. Can you tell > me how to do it, so I can test this potential soluton? > This is fixed now in the E500 kernel by adding emulation of the lwsync instruction. -Nathan From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 2 12:56:59 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46D98157 for ; Mon, 2 Dec 2013 12:56:59 +0000 (UTC) Received: from olymp.kibab.com (olymp.kibab.com [5.9.14.202]) by mx1.freebsd.org (Postfix) with ESMTP id 04E66112A for ; Mon, 2 Dec 2013 12:56:58 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 olymp.kibab.com CFC6F3F44A DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kibab.com; s=default; t=1385989010; bh=ZyLVuRqmzQzcQ/5A129AkYCOayExFeivrRVYTateGjQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=j0WD5avO29MWiyykD+ZxjDhjjRjrsfg37RUPvB3XmUBexC1Ez8NuE1tb4oGfL7Byw 4pkuRqkUakKzH4prUIChH8olmeiykkhWNCBrG3dr1Y40KzwmmqMoU3IHeoPNkqddBS FZySxnsKTQoTaMl3GyZEFR5Z/Ul5Vr2glQdtEnPY= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 02 Dec 2013 13:56:50 +0100 From: Ilya Bakulin To: Darren Pilgrim Subject: Re: unbound-control in FreeBSD-CURRENT and stable/10 Organization: Deglitch Networks In-Reply-To: <5298EA83.30705@bluerosetech.com> References: <20131129142143.GA29437@olymp.kibab.com> <20131129142729.GA29580@olymp.kibab.com> <5298EA83.30705@bluerosetech.com> Message-ID: <7507eb85a259cbb96c232625bb883460@mail.bakulin.de> X-Sender: webmaster@kibab.com Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 12:56:59 -0000 On 2013-11-29 20:26, Darren Pilgrim wrote: > On 11/29/2013 6:27 AM, Ilya Bakulin wrote: > > There's really no bug to fix. The base has unbound in it, > unbound-control is part of unbound. If you install unbound from > ports, you should delete unbound from base. I haven't tried out 10.x > yet, but you usually just set a knob like WITHOUT_UNBOUND in > /etc/src.conf, then do: Why on earth I should rebuild the whole system just to get rid of Unbound? Actually Unbound in base should be used only as a DNSSEC-aware resolver for the localhost, not as "real" DNS server. Just like BIND used to be earlier. You haven't recompiled the system (and lost freebsd-update!) when installing BIND from ports, have you? > Change your PATH to have /usr/local/bin and /usr/local/sbin first. > The shell will find /usr/local/bin/unbound-control first and run that. > I recommend this in general, since you pretty much always want a name > collision to prefer the from-ports program. This sounds a lot better, although then I don't understand why the system is not shipped with this setting by default. From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 2 12:58:28 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36F0E266; Mon, 2 Dec 2013 12:58:28 +0000 (UTC) Received: from olymp.kibab.com (olymp6.kibab.com [IPv6:2a01:4f8:160:84c1::2]) by mx1.freebsd.org (Postfix) with ESMTP id EDF521143; Mon, 2 Dec 2013 12:58:27 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 olymp.kibab.com 4C6B13F447 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kibab.com; s=default; t=1385989106; bh=H5Sh9/E9OTpVbs6s5CSUYIkJH4NKf8efhP0m/lF8seQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=FRiu6nNU3farIBt5zL2n5APntGNssVSve5wFMiexSUsTuvFUqVmuOx5NNxX1hcg8c mcoNiRbYg9Imb38Zg4Ex+od6xIUBjkUmMUs5TgH6fDUJRqAQJPCavxl9j/9PatJls8 ZeXhTw8MRsO4ub9kXQjV8LAp+oi1Q65NgGzhX36A= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 02 Dec 2013 13:58:26 +0100 From: Ilya Bakulin To: Gleb Smirnoff Subject: Re: unbound-control in FreeBSD-CURRENT and stable/10 Organization: Deglitch Networks In-Reply-To: <20131130082939.GJ90895@FreeBSD.org> References: <20131129142143.GA29437@olymp.kibab.com> <20131129142729.GA29580@olymp.kibab.com> <20131130082939.GJ90895@FreeBSD.org> Message-ID: X-Sender: webmaster@kibab.com Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 12:58:28 -0000 On 2013-11-30 09:29, Gleb Smirnoff wrote: > Ilya, > Shouldn't /usr/local/bin be earlier in your $PATH than /usr/bin? The system is shipped with .dot files that have /usr/local/bin _after_ /usr/bin. I agree that that is not optimal. Maybe it's not too late to change this? From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 2 13:03:53 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3CC063B6 for ; Mon, 2 Dec 2013 13:03:53 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B861A11AA for ; Mon, 2 Dec 2013 13:03:51 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id rB2D3nmG053916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Dec 2013 17:03:49 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id rB2D3n0f053915; Mon, 2 Dec 2013 17:03:49 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 2 Dec 2013 17:03:49 +0400 From: Gleb Smirnoff To: Ilya Bakulin Subject: Re: unbound-control in FreeBSD-CURRENT and stable/10 Message-ID: <20131202130349.GJ48919@glebius.int.ru> References: <20131129142143.GA29437@olymp.kibab.com> <20131129142729.GA29580@olymp.kibab.com> <20131130082939.GJ90895@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 13:03:53 -0000 On Mon, Dec 02, 2013 at 01:58:26PM +0100, Ilya Bakulin wrote: I> > Shouldn't /usr/local/bin be earlier in your $PATH than /usr/bin? I> I> The system is shipped with .dot files that have /usr/local/bin _after_ I> /usr/bin. I agree that that is not optimal. I> Maybe it's not too late to change this? My vote is "yes", but we need a much wider discussion for such a change. -- Totus tuus, Glebius. From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 2 13:06:24 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC4C54D2; Mon, 2 Dec 2013 13:06:24 +0000 (UTC) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3BCBC11CE; Mon, 2 Dec 2013 13:06:24 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id a1so4241369wgh.5 for ; Mon, 02 Dec 2013 05:06:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=vc33GFYev5MyLvTuSoAtbSLKBJ2uVwCnU3u6xVyvQg4=; b=gm2W5qZ1H6ejw03dyKAlNYCbQdCOsiw/on7gnaA1MU/yjliURvT36eczQkbHItzb/t ppqy4OtYWy/0htolND0nzQE9DCT6k7AT/1hdUSFdIQr6KKgC6qXhvOmIgv2mMYdW/xFU 9BXxW3JWrIZpWKIFqTlgz+tSt28pMRm5t0RLbNb4o/ry3UtYWPeBL9fXRMVFFE4Rn0h+ xhAf3L42EMCV6q7o02lIBrxPGCs3A0aTmFmMmFd0UikUAfOoVW5ZoTewUNkoH9+IXoGa 6FWw1RM4ceev4FES2Pks0MdLaneIlrGZZlmqVjoRJFP1rNQsj0mfWSEc8pZoghpx1Z9u qGSA== X-Received: by 10.180.92.230 with SMTP id cp6mr18047030wib.0.1385989582547; Mon, 02 Dec 2013 05:06:22 -0800 (PST) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id e10sm100544454wiy.7.2013.12.02.05.06.20 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 02 Dec 2013 05:06:21 -0800 (PST) Sender: Baptiste Daroussin Date: Mon, 2 Dec 2013 14:06:17 +0100 From: Baptiste Daroussin To: Gleb Smirnoff Subject: Re: unbound-control in FreeBSD-CURRENT and stable/10 Message-ID: <20131202130617.GE27759@ithaqua.etoilebsd.net> References: <20131129142143.GA29437@olymp.kibab.com> <20131129142729.GA29580@olymp.kibab.com> <20131130082939.GJ90895@FreeBSD.org> <20131202130349.GJ48919@glebius.int.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mrJd9p1Ce66CJMxE" Content-Disposition: inline In-Reply-To: <20131202130349.GJ48919@glebius.int.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Ilya Bakulin , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 13:06:24 -0000 --mrJd9p1Ce66CJMxE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 02, 2013 at 05:03:49PM +0400, Gleb Smirnoff wrote: > On Mon, Dec 02, 2013 at 01:58:26PM +0100, Ilya Bakulin wrote: > I> > Shouldn't /usr/local/bin be earlier in your $PATH than /usr/bin? > I>=20 > I> The system is shipped with .dot files that have /usr/local/bin _after_= =20 > I> /usr/bin. I agree that that is not optimal. > I> Maybe it's not too late to change this? >=20 > My vote is "yes", but we need a much wider discussion for such a change. >=20 > --=20 > Totus tuus, Glebius. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" That will help a lot with the ports :) and will allow to avoid hacks like we have on cups or openssh to "overwrite" the version in base. regards, Bapt --mrJd9p1Ce66CJMxE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlKchckACgkQ8kTtMUmk6EzZbwCgq7NI8Y5GrOEYRCtP9qhJvUFs R6AAn1yWEi75536CFWezbBfCjpRYUGP4 =b0cA -----END PGP SIGNATURE----- --mrJd9p1Ce66CJMxE-- From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 2 13:28:16 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DCCA9C9A for ; Mon, 2 Dec 2013 13:28:16 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9FA92131D for ; Mon, 2 Dec 2013 13:28:16 +0000 (UTC) Received: from 0x20.net (0x20.net [217.69.76.212]) (Authenticated sender: lala) by mail.0x20.net (Postfix) with ESMTPA id 5ED996A6002 for ; Mon, 2 Dec 2013 14:28:14 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 02 Dec 2013 14:28:14 +0100 From: Lars Engels To: freebsd-hackers@freebsd.org Subject: Re: unbound-control in FreeBSD-CURRENT and stable/10 Organization: FreeBSD In-Reply-To: <7507eb85a259cbb96c232625bb883460@mail.bakulin.de> References: <20131129142143.GA29437@olymp.kibab.com> <20131129142729.GA29580@olymp.kibab.com> <5298EA83.30705@bluerosetech.com> <7507eb85a259cbb96c232625bb883460@mail.bakulin.de> Message-ID: X-Sender: lme@FreeBSD.org User-Agent: Roundcube Webmail/0.7 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 13:28:16 -0000 Am 2013-12-02 13:56, schrieb Ilya Bakulin: > On 2013-11-29 20:26, Darren Pilgrim wrote: >> On 11/29/2013 6:27 AM, Ilya Bakulin wrote: >> >> There's really no bug to fix. The base has unbound in it, >> unbound-control is part of unbound. If you install unbound from >> ports, you should delete unbound from base. I haven't tried out 10.x >> yet, but you usually just set a knob like WITHOUT_UNBOUND in >> /etc/src.conf, then do: > Why on earth I should rebuild the whole system just to get rid of > Unbound? You removed the important thing: make -C /usr/src delete-old Together with WITHOUT_UNBOUND in src.conf the command just deletes unbound without building a new world. :) From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 2 17:31:36 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1206318C for ; Mon, 2 Dec 2013 17:31:36 +0000 (UTC) Received: from rush.bluerosetech.com (rush.bluerosetech.com [IPv6:2607:fc50:1000:9b00::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CDE6716DF for ; Mon, 2 Dec 2013 17:31:35 +0000 (UTC) Received: from chombo.houseloki.net (unknown [IPv6:2601:7:1680:365:21c:c0ff:fe7f:96ee]) by rush.bluerosetech.com (Postfix) with ESMTPSA id A8AE811437; Mon, 2 Dec 2013 09:31:34 -0800 (PST) Received: from [IPv6:2601:7:1680:365:6c84:41a:bb99:ad5e] (unknown [IPv6:2601:7:1680:365:6c84:41a:bb99:ad5e]) by chombo.houseloki.net (Postfix) with ESMTPSA id 740A4376; Mon, 2 Dec 2013 09:31:33 -0800 (PST) Message-ID: <529CC3EA.4030202@bluerosetech.com> Date: Mon, 02 Dec 2013 09:31:22 -0800 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Ilya Bakulin Subject: Re: unbound-control in FreeBSD-CURRENT and stable/10 References: <20131129142143.GA29437@olymp.kibab.com> <20131129142729.GA29580@olymp.kibab.com> <5298EA83.30705@bluerosetech.com> <7507eb85a259cbb96c232625bb883460@mail.bakulin.de> In-Reply-To: <7507eb85a259cbb96c232625bb883460@mail.bakulin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 17:31:36 -0000 On 12/2/2013 4:56 AM, Ilya Bakulin wrote: > On 2013-11-29 20:26, Darren Pilgrim wrote: >> On 11/29/2013 6:27 AM, Ilya Bakulin wrote: >> >> There's really no bug to fix. The base has unbound in it, >> unbound-control is part of unbound. If you install unbound from >> ports, you should delete unbound from base. I haven't tried out 10.x >> yet, but you usually just set a knob like WITHOUT_UNBOUND in >> /etc/src.conf, then do: > > Why on earth I should rebuild the whole system just to get rid of > Unbound? Who said anything about running the buildworld target? Just do what my original email said: 1. Add the appropriate knob to /etc/src.conf 2. make delete-old delete-old-libs From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 2 20:36:15 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7627483E for ; Mon, 2 Dec 2013 20:36:15 +0000 (UTC) Received: from zimbra2.tngtech.com (zimbra2.tngtech.com [212.204.93.103]) by mx1.freebsd.org (Postfix) with ESMTP id 0A4571365 for ; Mon, 2 Dec 2013 20:36:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra2.tngtech.com (Postfix) with ESMTP id A80A99CE0E7 for ; Mon, 2 Dec 2013 21:28:57 +0100 (CET) X-Virus-Scanned: amavisd-new at tngtech.com Received: from zimbra2.tngtech.com ([127.0.0.1]) by localhost (zimbra2.tngtech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBPxI8-LKINe for ; Mon, 2 Dec 2013 21:28:25 +0100 (CET) Received: from hactar.localnet (mnch-5d856701.pool.mediaWays.net [93.133.103.1]) by zimbra2.tngtech.com (Postfix) with ESMTPSA id C2C279CE10B for ; Mon, 2 Dec 2013 21:28:25 +0100 (CET) From: Stefan Wendler To: freebsd-hackers@freebsd.org Subject: Kind of hacky fix for banshee-2.6.0 Date: Mon, 02 Dec 2013 21:28:24 +0100 Message-ID: <3074012.QmsohyHcnK@hactar> Organization: TNG Technology Consulting GmbH User-Agent: KMail/4.10.5 (FreeBSD/9.2-RELEASE; KDE/4.10.5; amd64; ; ) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart7368799.mJgcGonVU6" Content-Transfer-Encoding: 7Bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 20:36:15 -0000 This is a multi-part message in MIME format. --nextPart7368799.mJgcGonVU6 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Hi, I've noticed a long time ago that banshee was not compiling anymore. When I wrote the maintainer nobody replied. So I kind of dirty-hacky-fixed it myself today. I generally did the following: I the Makefile.in files of the sources I changed (where this variable was available) ASSEMBLY_BUILD_FLAGS = -unsafe to ASSEMBLY_BUILD_FLAGS = -unsafe -sdk:4 Then I compiled my way through the rest of the sources and found loads of other files where this line was missing completely. I started by including it by hand but after the 20th Makefile.in it somehow got tedious. so I did a "export ASSEMBLY_BUILD_FLAGS = -unsafe -sdk:4" and then a make install. Now it compiles and banshee works. I attached the patch fle that can be copied to multimedia/banshee/files and works-for-me (TM) But I still have to do the export-thing before compiling. And I know this is a dirty hack. But I don't know if there is a way to include this once as a global compile time variable. Or if I have to patch this into every Makefile.in there is in banshee? Since I never did any patch at all for FreeBSD so far and didn't find anything about setting a global variable in the ports Makefile, I kind of hope that there is anybody out there who can guide me in the right direction? Cheers, Stefan --nextPart7368799.mJgcGonVU6 Content-Disposition: attachment; filename="patch-sdk4" Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; name="patch-sdk4" $FreeBSD$ --- src/Backends/Banshee.Osx/Makefile.in +++ src/Backends/Banshee.Osx/Makefile.in @@ -416,7 +416,7 @@ top_build_prefix = @top_build_prefix@ top_builddir = @top_builddir@ top_srcdir = @top_srcdir@ ASSEMBLY = Banshee.Osx -ASSEMBLY_BUILD_FLAGS = -unsafe +ASSEMBLY_BUILD_FLAGS = -unsafe -sdk:4 TARGET = library LINK = $(REF_BACKEND_OSX) $(am__append_1) INSTALL_DIR = $(BACKENDS_INSTALL_DIR) --- src/Core/Banshee.ThickClient/Makefile.in +++ src/Core/Banshee.ThickClient/Makefile.in @@ -417,7 +417,7 @@ top_builddir = @top_builddir@ top_srcdir = @top_srcdir@ ASSEMBLY = Banshee.ThickClient TARGET = library -ASSEMBLY_BUILD_FLAGS = -unsafe +ASSEMBLY_BUILD_FLAGS = -unsafe -sdk:4 LINK = $(REF_BANSHEE_THICKCLIENT) $(am__append_1) SOURCES = \ Banshee.Addins.Gui/AddinView.cs \ --- src/Core/Banshee.Widgets/Makefile.in +++ src/Core/Banshee.Widgets/Makefile.in @@ -417,7 +417,7 @@ top_builddir = @top_builddir@ top_srcdir = @top_srcdir@ ASSEMBLY = Banshee.Widgets TARGET = library -ASSEMBLY_BUILD_FLAGS = -unsafe +ASSEMBLY_BUILD_FLAGS = -unsafe -sdk:4 LINK = $(REF_BANSHEE_WIDGETS) $(am__append_1) SOURCES = \ Banshee.Widgets/CustomActionProxy.cs \ --- src/Hyena/Hyena.Gui/Makefile.in +++ src/Hyena/Hyena.Gui/Makefile.in @@ -416,7 +416,7 @@ top_build_prefix = @top_build_prefix@ top_builddir = @top_builddir@ top_srcdir = @top_srcdir@ ASSEMBLY = Hyena.Gui -ASSEMBLY_BUILD_FLAGS = -unsafe +ASSEMBLY_BUILD_FLAGS = -unsafe -sdk:4 TARGET = library LINK = -r:ICSharpCode.SharpZipLib -r:Mono.Posix -r:System \ -r:System.Core -r:Mono.Cairo $(GTKSHARP_LIBS) \ --nextPart7368799.mJgcGonVU6-- From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 2 23:09:41 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72027801; Mon, 2 Dec 2013 23:09:41 +0000 (UTC) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 45F8F1316; Mon, 2 Dec 2013 23:09:40 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id BAD4937B5C2; Mon, 2 Dec 2013 16:59:42 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3dYMGQ052MzGL1; Mon, 2 Dec 2013 16:59:42 -0600 (CST) Date: Mon, 2 Dec 2013 16:59:41 -0600 From: "Matthew D. Fuller" To: Gleb Smirnoff Subject: Re: unbound-control in FreeBSD-CURRENT and stable/10 Message-ID: <20131202225941.GF96826@over-yonder.net> References: <20131129142143.GA29437@olymp.kibab.com> <20131129142729.GA29580@olymp.kibab.com> <20131130082939.GJ90895@FreeBSD.org> <20131202130349.GJ48919@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131202130349.GJ48919@glebius.int.ru> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.22 (2013-10-16) X-Virus-Scanned: clamav-milter 0.98 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: Ilya Bakulin , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 23:09:41 -0000 On Mon, Dec 02, 2013 at 05:03:49PM +0400 I heard the voice of Gleb Smirnoff, and lo! it spake thus: > > My vote is "yes", but we need a much wider discussion for such a > change. I've had this in my rc files for a very long time. But note that it DOES cause occasional problems with port builds, when it tries using some port-installed tool rather than the base one (texinfo is a common offender), and so builds blow up. And they usually stay broken long enough that I take it as evidence that not many people do such path rearrangement :| -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 3 10:10:16 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D8DE926; Tue, 3 Dec 2013 10:10:16 +0000 (UTC) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5C55B15CF; Tue, 3 Dec 2013 10:10:16 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id x13so23224547ief.38 for ; Tue, 03 Dec 2013 02:10:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zIkOtdgqy59xQjRknMTDiEiEyddVRMjc+dDdc0Q+M6E=; b=BObGc9hO+GjbUWIQrNBcfuH7QH1d+16Ot7l1FtLLrKrwLxKSLlkN3bsUk35hXzypOb tviZgt8RP57ct3VVjdF2jDnpggUBSeVsElPxus45vvVuAIrVnFHWymTg35n5ME/OGYNt 8oJvjVSGcVlmSQ4sZH97fMJTsUELaGbwgJA0pK/H+A0brklTkNW0Egnw3+VMZnq4x/Bg /XYosv7q1wDJKiem+3xsj4holxV1ZEUod55Lz9FyXLTWFE49fN+pxv3IKws3QWbFrRHP mixpoM3PjUZcgqm1S1PN3qpmnnYJlasMl9Px68ZXzY5fOFIQj0WXXZUk3tWmfbg0LeEe 7QAw== MIME-Version: 1.0 X-Received: by 10.50.253.229 with SMTP id ad5mr1756513igd.42.1386065415793; Tue, 03 Dec 2013 02:10:15 -0800 (PST) Received: by 10.50.225.70 with HTTP; Tue, 3 Dec 2013 02:10:15 -0800 (PST) In-Reply-To: <92F46317-D62D-4E19-B687-2A392309A244@mail.turbofuzz.com> References: <718836647.19911209.1385302696963.JavaMail.root@uoguelph.ca> <706707CA-BD52-4814-BCCE-EB044B062BA6@kientzle.com> <92F46317-D62D-4E19-B687-2A392309A244@mail.turbofuzz.com> Date: Tue, 3 Dec 2013 11:10:15 +0100 Message-ID: Subject: Re: Extended Attributes and how to avoid them (was Re: O_XATTR support in FreeBSD?) From: Cedric Blancher To: Jordan Hubbard Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Rick Macklem , Freebsd hackers list , Richard Yao , Pedro Giffuni , Lionel Cons X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 10:10:16 -0000 On 2 December 2013 00:19, Jordan Hubbard wrote: > > On Dec 1, 2013, at 2:05 PM, Lionel Cons wrote: > >> But this discussion is *not* about extended attributes, this >> discussion is about Alternate Data Streams. Unfortunately the O_XATTR >> discussion somehow started to cover the Linux "extended attribute >> system", which is utterly useless in the intended use cases (as said, >> no access through normal POSIX read(), write(), mmap(), no unlimited >> size, no sparse data support (aka SEEK_HOLE, SEEK_DATA) etc etc). > > I think this discussion doesn't really *know* what it's about, frankly, b= ecause there are so many possible avenues to choose from! :-) I thought that had been explained in detail. What's needed here is the O_XATTR solution, which covers CIFS, NTFS, ZFS and NFSv4 functionality, Alternate Stream Garbage collection (this is the use case I've seen in most of nih.gov's work - they use it for application-specific index files which 'disappear' if the file gets deleted) and POSIX api access. Since O_XATTR meets all requirements this would IMHO be the way to go. Additionally ZFS already has O_XATTR functionality, so the main work would be in the FreeBSD vfs layer. I think the work required isn't very big... maybe even the whole discussion already exceeded the amount of work required. > Since you brought up POSIX APIs, let's talk about that for a second. I'v= e worked with EAs "in the field", as it were, a lot (a LOT) and no one duri= ng my long history with them has ever demanded the ability to call read() o= r write() on an EA, to mmap() one, or to store sparse data in one. I would= love to know which apps actually need to do that (and why), because other = than "unlimited size", none of those demands have ever hit any bug database= I've had access to. Well, where did you look? Opensolaris's bug database is no longer public, and so are the Architecture Cases from the days of Solaris 9, which clearly stated the requirements and intended usage. Microsofts bug database is not public either and even the paying audience doesn't see all details (I can say this: Microsofts butt is currently under fire (roasted!) because ADS is disabled by default in ReFS, which in turn caused a lot of stirr and anger). AT&T's work is done on top of libast (which is a platform abstraction and utility library), which either uses the O_XATTR API, attropen() or the Win32 Alternate Data Stream API (so just searching for O_XATTR doesn't give you the search results you'd may expect). The other places to look at would be nih.gov and CERN, but AFAIK both use platform abstraction libraries like libast does, so you'd have to dig around a *lot*. > I'm also generally not one to throw marketing numbers around in a technic= al conversation, but with 72 million seats and over 1 million applications = (and by all means fact-check those numbers), if the ability to use EAs in t= hat fashion were truly necessary, I suspect I would have heard that early a= nd often. You did notice that AT&T Research (to serve their cloud services), nih.gov and CERN did a lot of work related to ADS/O_XATTR in the last three years? > I'll opine that If FreeBSD really wants to support EAs in a "useful enoug= h" way, then the best way of doing so is to stay focused on the pragmatic "= this our usage cases, and we are not afraid to describe them in detail!" si= de of the street because, as I said, the academic discussions generally don= 't lead anywhere but in circles. A pragmatic approach will, conversely, l= ead to doing just the basic minimums and not waste time implementing anythi= ng that won't actually be needed in real-world scenarios. That ship already sailed off long ago (likely with Solaris 10 when NFSv4 with Alternate Data Streams/O_XATTR was introduced) - its in use now with a lot of applications. Ced --=20 Cedric Blancher Institute Pasteur From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 3 14:49:37 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 004FFF1E for ; Tue, 3 Dec 2013 14:49:36 +0000 (UTC) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::103]) by mx1.freebsd.org (Postfix) with ESMTP id CCB3B186C for ; Tue, 3 Dec 2013 14:49:36 +0000 (UTC) Received: from [IPv6:2001:470:1f11:617:8fe:6a13:797b:e9c9] (unknown [IPv6:2001:470:1f11:617:8fe:6a13:797b:e9c9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 1A61E5BA for ; Tue, 3 Dec 2013 14:49:29 +0000 (UTC) Subject: Automount and nfsv4 From: Eric McCorkle Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (11B511) Message-Id: Date: Tue, 3 Dec 2013 09:49:28 -0500 To: "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-Mailman-Approved-At: Tue, 03 Dec 2013 16:20:07 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 14:49:37 -0000 Hello, I have an interest in getting the automounter to work with an nfsv4 + ldap s= etup so that I can set up a FreeBSD development system at work (which would b= e a good test in a production environment). I also have a much smaller ldap= + nfsv4 setup on my home network that would act as a good smoke test. I know there was some work done at some point in this direction; is that cod= e still available somewhere, or is it too bit-rotted at this point? Either w= ay, are there any docs I should read in order to get started? Thanks, Eric= From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 3 15:50:11 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 80D262B9 for ; Tue, 3 Dec 2013 15:50:11 +0000 (UTC) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4E5921D95 for ; Tue, 3 Dec 2013 15:50:11 +0000 (UTC) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id ECD35216DE; Tue, 3 Dec 2013 10:50:07 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute5.internal (MEProxy); Tue, 03 Dec 2013 10:50:07 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=feld.me; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:in-reply-to:references:subject:date; s=mesmtp; bh= cXVTERypdrffekHQBuVmpKVpaG0=; b=Sf4ILCHyLCu+oY3fhGYsSMwSehtrTdqz mcMAIerQVFrko4/wyvsydzu8XaRFPWKGWuUlhWYkdfiqvl3Vsg+JcvLj1qDwNwbD tXB8h/hfPDRTX6fvhzBE77oIEXRhjB5kTneY7YU0DgD+zXI7ZHnGIXPUrUfp88QE 8mF4CpzMqSQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=cXVTERypdrffekHQBuVmpKVpaG0=; b=MiK 23ErSXeIv58N89CVx2Sk5oDx4GIs7mDnJePHzOHItw9WuiT9yk6S5d/NLKt+n58F vb9D0G3PX0yRheGAfObsXT3obo85JFIVSvKDCd15pvyxN/YRNI6fNeL3pEeVDn1v STqeLlKz8EGovhxbHyFSUKgv8oh7Y+P16EoG5OI8= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id BE18B106820; Tue, 3 Dec 2013 10:50:07 -0500 (EST) Message-Id: <1386085807.32047.54988641.54504273@webmail.messagingengine.com> X-Sasl-Enc: HIfsu3pJQ1+WveARshPM7J7PFncjv5Z4MekYEAWE463O 1386085807 From: Mark Felder To: Stefan Wendler , freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-24db94df In-Reply-To: <3074012.QmsohyHcnK@hactar> References: <3074012.QmsohyHcnK@hactar> Subject: Re: Kind of hacky fix for banshee-2.6.0 Date: Tue, 03 Dec 2013 09:50:07 -0600 X-Mailman-Approved-At: Tue, 03 Dec 2013 17:01:49 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 15:50:11 -0000 On Mon, Dec 2, 2013, at 14:28, Stefan Wendler wrote: > Hi, > > I've noticed a long time ago that banshee was not compiling anymore. When > I > wrote the maintainer nobody replied. So I kind of dirty-hacky-fixed it > myself > today. > > I generally did the following: > > I the Makefile.in files of the sources I changed (where this variable was > available) > ASSEMBLY_BUILD_FLAGS = -unsafe > to > ASSEMBLY_BUILD_FLAGS = -unsafe -sdk:4 > > Then I compiled my way through the rest of the sources and found loads of > other files where this line was missing completely. I started by > including it > by hand but after the 20th Makefile.in it somehow got tedious. > > so I did a "export ASSEMBLY_BUILD_FLAGS = -unsafe -sdk:4" and then a make > install. Now it compiles and banshee works. > > I attached the patch fle that can be copied to multimedia/banshee/files > and > works-for-me (TM) > But I still have to do the export-thing before compiling. And I know this > is a > dirty hack. But I don't know if there is a way to include this once as a > global compile time variable. Or if I have to patch this into every > Makefile.in there is in banshee? > > Since I never did any patch at all for FreeBSD so far and didn't find > anything > about setting a global variable in the ports Makefile, I kind of hope > that > there is anybody out there who can guide me in the right direction? > Are all of these files Makefile.in or Makefile.am ? If so, this patch would fix it: Index: Makefile =================================================================== --- Makefile (revision 335567) +++ Makefile (working copy) @@ -126,4 +126,8 @@ PLIST_SUB+= OPT_WEBKITORYOUTUBE="@comment " .endif +post-patch: + ${FIND} ${WRKSRC} -name 'Makefile.*' | ${XARGS} ${REINPLACE_CMD} \ + -E 's|ASSEMBLY_BUILD_FLAGS = -unsafe|ASSEMBLY_BUILD_FLAGS = -unsafe -sdk:4|' + .include From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 3 18:02:11 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66A85D6E for ; Tue, 3 Dec 2013 18:02:11 +0000 (UTC) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 37235164D for ; Tue, 3 Dec 2013 18:02:10 +0000 (UTC) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 98E6620BFE; Tue, 3 Dec 2013 13:02:09 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute4.internal (MEProxy); Tue, 03 Dec 2013 13:02:09 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date:in-reply-to :references; s=smtpout; bh=cXVTERypdrffekHQBuVmpKVpaG0=; b=gaxS5 5bf5cJK1wu1uv/LTy3kA3qdrXZ+qI1Maz7xVVoX67+5nyKafFfFdEt2hCOkePmGE rL0NgButcnRBVUTOLWD02pDKtnphu0+UhoxJzSL2kWIjsDjuULp2AJ5/iBlqwg+R vSALE1zX2vbVoxdI6frWD1LUQ8RMYxeelQZsTw= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 75600106EB5; Tue, 3 Dec 2013 13:02:09 -0500 (EST) Message-Id: <1386093729.5203.55046221.21CD5331@webmail.messagingengine.com> X-Sasl-Enc: 0y9mtIirnR2AtAIk92fbvWXtufHDsiqlFLZmVS9pYa1Q 1386093729 From: Mark Felder To: Stefan Wendler , freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-24db94df Subject: Re: Kind of hacky fix for banshee-2.6.0 Date: Tue, 03 Dec 2013 12:02:09 -0600 In-Reply-To: <3074012.QmsohyHcnK@hactar> References: <3074012.QmsohyHcnK@hactar> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 18:02:11 -0000 On Mon, Dec 2, 2013, at 14:28, Stefan Wendler wrote: > Hi, > > I've noticed a long time ago that banshee was not compiling anymore. When > I > wrote the maintainer nobody replied. So I kind of dirty-hacky-fixed it > myself > today. > > I generally did the following: > > I the Makefile.in files of the sources I changed (where this variable was > available) > ASSEMBLY_BUILD_FLAGS = -unsafe > to > ASSEMBLY_BUILD_FLAGS = -unsafe -sdk:4 > > Then I compiled my way through the rest of the sources and found loads of > other files where this line was missing completely. I started by > including it > by hand but after the 20th Makefile.in it somehow got tedious. > > so I did a "export ASSEMBLY_BUILD_FLAGS = -unsafe -sdk:4" and then a make > install. Now it compiles and banshee works. > > I attached the patch fle that can be copied to multimedia/banshee/files > and > works-for-me (TM) > But I still have to do the export-thing before compiling. And I know this > is a > dirty hack. But I don't know if there is a way to include this once as a > global compile time variable. Or if I have to patch this into every > Makefile.in there is in banshee? > > Since I never did any patch at all for FreeBSD so far and didn't find > anything > about setting a global variable in the ports Makefile, I kind of hope > that > there is anybody out there who can guide me in the right direction? > Are all of these files Makefile.in or Makefile.am ? If so, this patch would fix it: Index: Makefile =================================================================== --- Makefile (revision 335567) +++ Makefile (working copy) @@ -126,4 +126,8 @@ PLIST_SUB+= OPT_WEBKITORYOUTUBE="@comment " .endif +post-patch: + ${FIND} ${WRKSRC} -name 'Makefile.*' | ${XARGS} ${REINPLACE_CMD} \ + -E 's|ASSEMBLY_BUILD_FLAGS = -unsafe|ASSEMBLY_BUILD_FLAGS = -unsafe -sdk:4|' + .include From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 3 22:00:16 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E3D49F8 for ; Tue, 3 Dec 2013 22:00:16 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id E6BD715CC for ; Tue, 3 Dec 2013 22:00:14 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAPhTnlKDaFve/2dsb2JhbABagz9Tgnq1IE6BMXSCJQEBAQMBAQEBICsgCwUWGAICDRkCKQEJJgYIBwQBHASHWgYNsSGQGReBKY0EAQEbNAeCa4FIA4lCim+BFIN/kGODRx4xgQQ5 X-IronPort-AV: E=Sophos;i="4.93,820,1378872000"; d="scan'208";a="75232445" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 03 Dec 2013 16:58:53 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id F311EB403C; Tue, 3 Dec 2013 16:58:53 -0500 (EST) Date: Tue, 3 Dec 2013 16:58:53 -0500 (EST) From: Rick Macklem To: Eric McCorkle Message-ID: <1127153223.25369986.1386107933983.JavaMail.root@uoguelph.ca> In-Reply-To: Subject: Re: Automount and nfsv4 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 22:00:16 -0000 Eric McCorkie wrote: > Hello, > > I have an interest in getting the automounter to work with an nfsv4 + > ldap setup so that I can set up a FreeBSD development system at work > (which would be a good test in a production environment). I also > have a much smaller ldap + nfsv4 setup on my home network that would > act as a good smoke test. > > I know there was some work done at some point in this direction; is > that code still available somewhere, or is it too bit-rotted at this > point? Either way, are there any docs I should read in order to get > started? > I am not aware of any work done on amd to get it to work for NFSv4 mounts. >From what I can recall, amd uses the old mount(2) syscall instead of nmount(2). It would need to be converted to use nmount(2) so that it could do NFSv4 mounts, I think (without looking at the code). I once looked at the amd sources and decided to "run away..", so good luck if you try and convert it. rick > Thanks, > Eric > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 4 08:23:44 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DABAAA27 for ; Wed, 4 Dec 2013 08:23:44 +0000 (UTC) Received: from sanddollar.geekisp.com (sanddollar.geekisp.com [216.168.135.167]) by mx1.freebsd.org (Postfix) with SMTP id 6AE241D62 for ; Wed, 4 Dec 2013 08:23:44 +0000 (UTC) Received: (qmail 15370 invoked by uid 1003); 4 Dec 2013 08:23:37 -0000 Received: from unknown (HELO kiwi.coupleofllamas.com) (tyler@monkeypox.org@173.239.70.2) by mail.geekisp.com with (DHE-RSA-AES256-SHA encrypted) SMTP; 4 Dec 2013 08:23:37 -0000 Date: Wed, 4 Dec 2013 00:23:31 -0800 From: "R. Tyler Croy" To: "freebsd-hackers@freebsd.org" Subject: Who should really be using libbsdxml? Message-ID: <20131204082331.GV14900@kiwi.coupleofllamas.com> Mail-Followup-To: "freebsd-hackers@freebsd.org" MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="je0mZywpqEo4t1RU" Content-Disposition: inline User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 08:23:44 -0000 --je0mZywpqEo4t1RU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I'm working on a daemon for FreeBSD specifically, which I hope to one day merge into the base system, but first is going to live in ports for some amount of time. Does it make sense for me to even bother using libbsdxml right now, or should I just reference and link against a ports-installed libexpat? - R. Tyler Croy ------------------ Code: https://github.com/rtyler Chatter: https://twitter.com/agentdero rtyler@jabber.org --je0mZywpqEo4t1RU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iEYEARECAAYFAlKe5oIACgkQFCbH3D9R4W//fACdGd6M4ZcBB/GO7C3ilc+1Pi+Z DdEAn0sdbFG+QgyMQmz3dtXB0Bw8sM9X =PPYr -----END PGP SIGNATURE----- --je0mZywpqEo4t1RU-- From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 4 09:23:50 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59334440 for ; Wed, 4 Dec 2013 09:23:50 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E694E10BB for ; Wed, 4 Dec 2013 09:23:49 +0000 (UTC) Received: from mandree.no-ip.org ([78.49.75.28]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MNMyz-1Vhnsa26Kv-006tXu for ; Wed, 04 Dec 2013 10:18:37 +0100 Received: from [IPv6:::1] (localhost6.localdomain6 [IPv6:::1]) by apollo.emma.line.org (Postfix) with ESMTP id 091CA23D02A for ; Wed, 4 Dec 2013 10:18:35 +0100 (CET) Message-ID: <529EF36A.2020906@gmx.de> Date: Wed, 04 Dec 2013 10:18:34 +0100 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Asynchronous user-space notification of interface address changes? X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:xi9OmjkqXtQRbcCdh6OYu/U135gH/Cen+u+Of5JMp1XcNamUiQg dt+DASkN920jYjYxUwEoAwdXbfbe7bnOs7u+5K6N/m6xgxMl/ztTvtdDpOMpsXcW9O6yWOU vKN1Ijkol4LseU4QAup2YR1ppRC8lDuQa4u5Nyvz6OJLfOvVPem3om3ceVFM4gSKYY5KVHU A52bCuRVcGMvHudql+heA== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 09:23:50 -0000 Greetings, is there any sensible way to have a user-space application notified of interface address changes (in the light of - but not limited to - IPv6 automatic configuration, with accept_rtadv or similar), preferably without the application polling getifaddrs every five-ish seconds? It does not appear kevent/kqueue, or devctl, are up to the task. I am not asking for turnkey solutions (although I'll gladly take them), a rough sketch or pointers will suffice. Thanks. Best regards Matthias From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 4 10:33:51 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC01CEBA for ; Wed, 4 Dec 2013 10:33:51 +0000 (UTC) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 700891564 for ; Wed, 4 Dec 2013 10:33:51 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id w62so9001478wes.7 for ; Wed, 04 Dec 2013 02:33:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=q+qBxxC9SSUSNHca6tOmkE+LkdOExMMJEEmmnZ6jaDI=; b=lFaYw9+sXjb9yfz+j6v4MLtJtfhbDQ5HGHXNZoUOIT8G5bBKkaWAPFPoxtxuQHfuy3 I72QCOBkirf11HuqbcFPIU5SMbYUqHsulXf50CW3d7CXx839QKoH2VrgTiA29G7RFoi6 5JiVqLxd4VIEj54HHd4Z1HwdLfA60Lbf2B3/hJzhUTdb5Hetw/zRhE6FsJiINUbKN6sm TfLmzKPdd53OYeye3gVRuLS5asMC2Z78Sz0j+2OsMGczsdMBN9rtLeMD1j8J2jmiI9qU +1J89emLKPrSJ0ys6ND+wIdgK+Mj9DYskUP/cRwN+lnZ7E/Q+iK/rGWnivgFOtn9C3jU aasA== X-Received: by 10.180.39.177 with SMTP id q17mr6629877wik.16.1386153229624; Wed, 04 Dec 2013 02:33:49 -0800 (PST) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id f11sm5683819wic.4.2013.12.04.02.33.48 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 04 Dec 2013 02:33:48 -0800 (PST) Sender: Baptiste Daroussin Date: Wed, 4 Dec 2013 11:33:46 +0100 From: Baptiste Daroussin To: "freebsd-hackers@freebsd.org" Subject: Re: Who should really be using libbsdxml? Message-ID: <20131204103346.GS27759@ithaqua.etoilebsd.net> References: <20131204082331.GV14900@kiwi.coupleofllamas.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RvrrZ8vH9xW05bsQ" Content-Disposition: inline In-Reply-To: <20131204082331.GV14900@kiwi.coupleofllamas.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 10:33:51 -0000 --RvrrZ8vH9xW05bsQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 04, 2013 at 12:23:31AM -0800, R. Tyler Croy wrote: >=20 > I'm working on a daemon for FreeBSD specifically, which I hope to one day= merge > into the base system, but first is going to live in ports for some amount= of > time. >=20 > Does it make sense for me to even bother using libbsdxml right now, or sh= ould I > just reference and link against a ports-installed libexpat? Switching to libbsdxml would be easy if it one day goes into base, but for = now keep using libexpat, libbsdxml is not intended to be used outside of base. Even pkg(8) now uses a bundled version of expat to avoid using libbsdxml regards, Bapt --RvrrZ8vH9xW05bsQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlKfBQoACgkQ8kTtMUmk6Eym3QCePgZY92/sw0cABRCTFmPicToY voEAn21clEWJHDoCwgRiMNtWpGPK9vTu =cB3L -----END PGP SIGNATURE----- --RvrrZ8vH9xW05bsQ-- From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 4 10:41:28 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D36F12E for ; Wed, 4 Dec 2013 10:41:28 +0000 (UTC) Received: from zimbra2.tngtech.com (zimbra2.tngtech.com [212.204.93.103]) by mx1.freebsd.org (Postfix) with ESMTP id E01A415F2 for ; Wed, 4 Dec 2013 10:41:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra2.tngtech.com (Postfix) with ESMTP id 6AE2C9CE10B for ; Wed, 4 Dec 2013 11:41:21 +0100 (CET) X-Virus-Scanned: amavisd-new at tngtech.com Received: from zimbra2.tngtech.com ([127.0.0.1]) by localhost (zimbra2.tngtech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcEHH3parbtE for ; Wed, 4 Dec 2013 11:40:57 +0100 (CET) Received: from hactar.localnet (hactar.int.tngtech.com [10.1.2.115]) by zimbra2.tngtech.com (Postfix) with ESMTPSA id CFD769CE0E7 for ; Wed, 4 Dec 2013 11:40:57 +0100 (CET) From: Stefan Wendler To: freebsd-hackers@freebsd.org Subject: Re: Kind of hacky fix for banshee-2.6.0 Date: Wed, 04 Dec 2013 11:40:57 +0100 Message-ID: <2093792.KXDdxCWCWG@hactar> Organization: TNG Technology Consulting GmbH User-Agent: KMail/4.10.5 (FreeBSD/9.2-RELEASE; KDE/4.10.5; amd64; ; ) In-Reply-To: <1386093729.5203.55046221.21CD5331@webmail.messagingengine.com> References: <3074012.QmsohyHcnK@hactar> <1386093729.5203.55046221.21CD5331@webmail.messagingengine.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 10:41:28 -0000 On Tuesday 03 December 2013 12:02:09 Mark Felder wrote: > Are all of these files Makefile.in or Makefile.am ? If so, this patch= > would fix it: Hey, that's a nice hint. I've seen somthing similar in the doc right af= ter=20 I've sent the mail.=20 I am currently trying to figure out how to adapt the REINPLACE_CMD to n= ot only=20 change the line but to add the variable where it is not present. I thin= k I=20 have to play around a bit here, see how other ports solved this Thx for the patch. This helped alot! Cheers, Stefan --=20 Stefan Wendler stefan.wendler@tngtech.com +49 (0) 176 - 2438 3835 Senior Consultant TNG Technology Consulting GmbH, Betastr. 13a, 85774 Unterf=F6hring Gesch=E4ftsf=FChrer: Henrik Klagges, Gerhard M=FCller, Christoph Stock Amtsgericht M=FCnchen, HRB 135082 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 4 15:02:39 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2FAF9B2D; Wed, 4 Dec 2013 15:02:39 +0000 (UTC) Received: from mail-bk0-x232.google.com (mail-bk0-x232.google.com [IPv6:2a00:1450:4008:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 89915171B; Wed, 4 Dec 2013 15:02:38 +0000 (UTC) Received: by mail-bk0-f50.google.com with SMTP id e11so6655767bkh.37 for ; Wed, 04 Dec 2013 07:02:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=dB3b8iuuA0FFkwnzYZRW74HC1VfjUSlC0SxeBjLkLsY=; b=PZZhdUQwTC+n/9PouXdP9DhMhR59wQ9nvSwEy6CUn+/kXfHRsVyL5ppLS0KoFucuK5 oUjnAqMbAAGZODd9yeK3BgM2QXW2rDE29+Sg6djb77Z7ohBNlh8jLaNmlRYi8AX3HOae IbvH1sn1ZPZl/Wwc3ruP824Ujjy2adTWjVYtR+R2pWQwr1Ht8CALuf/L5Z6vuqMWQrWF eOteyUENNlMF5Ovw4wmuK3lXmuKVEY3ogMK9ZRBdA3Hxz8Vn5mw+CZweYfZYmausiD/w GA4SwOYUsAjzJSlFLi3625SeC20qk8YTi09z/JJizpD1Gd+CzBMjFe/Fn+zCsU1jXF9a PQjw== X-Received: by 10.204.230.197 with SMTP id jn5mr90754bkb.127.1386169356522; Wed, 04 Dec 2013 07:02:36 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([178.137.150.35]) by mx.google.com with ESMTPSA id o5sm29557401bkz.4.2013.12.04.07.02.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 07:02:35 -0800 (PST) Sender: Alexander Motin Message-ID: <529F4409.9080403@FreeBSD.org> Date: Wed, 04 Dec 2013 17:02:33 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Bret Ketchum Subject: Re: 9.1 callout behavior References: <5295A261.2060403@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , Adrian Chadd X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 15:02:39 -0000 On 04.12.2013 14:49, Bret Ketchum wrote: > See attached. I've tightened up the definition of inconsistent > callout calls. A "Whoops" message indicates the callout function was > called either side of a 10ms window than what was expected. "Ouch" > indicates the cyclecounter does not agree with the expected period given > the same 10ms fudge factor. I have this module running on two of my tests systems with stable/9 (2xE5645 and i7-3770) and half hour later I see no any of related messages on consoles. Could you share what exactly do you have there logged? > On Wed, Nov 27, 2013 at 3:28 AM, Bret Ketchum > wrote: > > Alexander, > > In this scenario, global ticks should have increased by 100 > every interval. When the wheels go off the truck, global ticks will > be 800+ yet only a fraction of usual number of clock cycles have > increased. > > I'll try to cook up an kernel module which will reproduce. > > > On Wed, Nov 27, 2013 at 1:42 AM, Alexander Motin > wrote: > > Hi, Brett, > > Could you tell more about "ticks has increased 8x"? Tickless > mode it is somewhat tricky algorithm to track global ticks > counter, but it should not jump that big. Jumps there could > easily trigger wrong callout behavior in 9 (in 10 callout code > was rewritten and no longer depend on ticks). > > > On 21.11.2013 22:19, Adrian Chadd wrote: > > It sounds like you may have found an interesting test case. > > Mav, any ideas? > > On 21 November 2013 05:20, Bret Ketchum > wrote: > > I've a callout which runs every 100ms and does a > bit of accounting > using the global ticks variable. This one-shot callout > was called fairly > consistently in 8.1, every 100ms give or take a few > thousand clocks. I've > recently upgraded to 9.1 and for the most part the > period is consistent. > However, periodically the callout function is executed > anywhere between 5ms > to 20ms after the callout was reset and the function > returned while global > ticks has increased 8x. The hardware has not changed > (using the same > timecounter configuration): > > CPU: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz > (2500.05-MHz K8-class CPU) > > kern.timecounter.hardware: TSC-low > kern.timecounter.tick: 1 > kern.timecounter.invariant___tsc: 1 > kern.timecounter.smp_tsc: 1 > > And default eventtimer configuration: > > kern.eventtimer.singlemul: 2 > kern.eventtimer.idletick: 0 > kern.eventtimer.activetick: 1 > kern.eventtimer.timer: LAPIC > kern.eventtimer.periodic: 0 > > If tickless mode is disabled the inconsistency > goes away. Is the > premature expiration of the callout expected? Is the > jump in global ticks > typical (say from 100 ticks to 800 ticks in 1.5ms)? > > Bret > _________________________________________________ > freebsd-hackers@freebsd.org > mailing list > http://lists.freebsd.org/__mailman/listinfo/freebsd-__hackers > > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@__freebsd.org > " > > > > -- > Alexander Motin > > > -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 4 15:34:20 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 202FD5CD for ; Wed, 4 Dec 2013 15:34:20 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E76801911 for ; Wed, 4 Dec 2013 15:34:18 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VoESq-0001ha-4K; Wed, 04 Dec 2013 15:34:12 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id rB4FY9xG021978; Wed, 4 Dec 2013 08:34:09 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19dBZ6b1ltkYnIw6dGDnLxr Subject: Re: Asynchronous user-space notification of interface address changes? From: Ian Lepore To: Matthias Andree In-Reply-To: <529EF36A.2020906@gmx.de> References: <529EF36A.2020906@gmx.de> Content-Type: text/plain; charset="us-ascii" Date: Wed, 04 Dec 2013 08:34:08 -0700 Message-ID: <1386171248.58852.78.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 15:34:20 -0000 On Wed, 2013-12-04 at 10:18 +0100, Matthias Andree wrote: > Greetings, > > is there any sensible way to have a user-space application notified of > interface address changes (in the light of - but not limited to - IPv6 > automatic configuration, with accept_rtadv or similar), preferably > without the application polling getifaddrs every five-ish seconds? > > It does not appear kevent/kqueue, or devctl, are up to the task. > > I am not asking for turnkey solutions (although I'll gladly take them), > a rough sketch or pointers will suffice. > > Thanks. > > Best regards > Matthias Open a routing socket, select/poll for readability, handle incoming RTM_NEWADDR/RTM_DELADDR messages. Example code in dhclient and faithd and I think ntpd among others. Some info available in man 4 route. I've never done this, just remember seeing the code for it in dhclient. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 4 17:05:17 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9B7A4347; Wed, 4 Dec 2013 17:05:17 +0000 (UTC) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4501A1FD3; Wed, 4 Dec 2013 17:05:17 +0000 (UTC) Received: by mail-qa0-f51.google.com with SMTP id o15so6862646qap.17 for ; Wed, 04 Dec 2013 09:05:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Y6P9t8oqGWiXeTjh6fuooLYEhp2aj6vjgkWJ7F+XcsI=; b=xeSHpRWbd1BM7dHTFfSfu8Sy4Tiahqg7RLNrNUhemi7ImM6xZ74V7rmJX82Ty3aaI/ /cx8tASCXXzfLjZ6F6O184tPKmkm9phzAkjkjvpOX2xNGwVbCmOyBlHgtYNvSK1G9CxT JT6D595mVHrIU5zPuBy7ae5v+uDXthzwz3tTzZb6PoR6Jk195ZukbWmO/ICnmh2LLyaY JsyNenllUddBwVOJgIoj+pGmdqzbcFscZ35/9yI0wn3dBQ/S+REfP61lYU7LO6I8NTJg XRuwwllV0YCyb2pTLr0YEjT8GpNKqKhP8Vir6RaVHYKVrF6Pw+RY6+tPfm8PIqcLi/9e KfhQ== MIME-Version: 1.0 X-Received: by 10.224.80.129 with SMTP id t1mr97796636qak.95.1386176716404; Wed, 04 Dec 2013 09:05:16 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Wed, 4 Dec 2013 09:05:16 -0800 (PST) In-Reply-To: References: <5295A261.2060403@FreeBSD.org> <529F4409.9080403@FreeBSD.org> Date: Wed, 4 Dec 2013 09:05:16 -0800 X-Google-Sender-Auth: 0n7vqjT76FDl3C4F6Gc8anyCD-c Message-ID: Subject: Re: 9.1 callout behavior From: Adrian Chadd To: Bret Ketchum Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" , Alexander Motin X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 17:05:17 -0000 Hi, What C states are you allowing the system to go into? sysctl dev.cpu -a On 4 December 2013 08:09, Bret Ketchum wrote: > Dec 4 16:10:42 Aldagautr kernel: Whoops(0) 1335665250 - 1335664940 = 310 > (125039:208) > Dec 4 16:10:42 Aldagautr kernel: 3532533380201277 - 3532533110189730 = 100 > Dec 4 16:10:46 Aldagautr kernel: Whoops(0) 1335669705 - 1335669450 = 255 > (125081:209) > Dec 4 16:10:46 Aldagautr kernel: 3532544993171592 - 3532544723156886 = 100 > Dec 4 16:10:46 Aldagautr kernel: Ouch(0) 1335669805 - 1335669705 = 100 > (125081:210) > Dec 4 16:10:46 Aldagautr kernel: 3532545106580358 - 3532544993171592 = 42 > Dec 4 16:10:51 Aldagautr kernel: Whoops(0) 1335674622 - 1335674406 = 216 > (125127:211) > Dec 4 16:10:51 Aldagautr kernel: 3532557637551168 - 3532557529541286 = 40 > Dec 4 16:10:51 Aldagautr kernel: Ouch(0) 1335674722 - 1335674622 = 100 > (125127:212) > Dec 4 16:10:51 Aldagautr kernel: 3532557856241106 - 3532557637551168 = 80 > Dec 4 16:10:51 Aldagautr kernel: Whoops(0) 1335675136 - 1335675023 = 113 > (125130:213) > Dec 4 16:10:51 Aldagautr kernel: 3532558941667944 - 3532558671656559 = 100 > Dec 4 16:11:02 Aldagautr kernel: Whoops(0) 1335685785 - 1335685544 = 241 > (125234:214) > Dec 4 16:11:02 Aldagautr kernel: 3532587178907223 - 3532587033073221 = 54 > > Not that with kern.eventtimer.periodic set to 1 the problem goes away. > > > On Wed, Dec 4, 2013 at 9:02 AM, Alexander Motin wrote: >> >> On 04.12.2013 14:49, Bret Ketchum wrote: >>> >>> See attached. I've tightened up the definition of inconsistent >>> callout calls. A "Whoops" message indicates the callout function was >>> called either side of a 10ms window than what was expected. "Ouch" >>> indicates the cyclecounter does not agree with the expected period given >>> the same 10ms fudge factor. >> >> >> I have this module running on two of my tests systems with stable/9 >> (2xE5645 and i7-3770) and half hour later I see no any of related messages >> on consoles. Could you share what exactly do you have there logged? >> >>> On Wed, Nov 27, 2013 at 3:28 AM, Bret Ketchum >> > wrote: >>> >>> Alexander, >>> >>> In this scenario, global ticks should have increased by 100 >>> every interval. When the wheels go off the truck, global ticks will >>> be 800+ yet only a fraction of usual number of clock cycles have >>> increased. >>> >>> I'll try to cook up an kernel module which will reproduce. >>> >>> >>> On Wed, Nov 27, 2013 at 1:42 AM, Alexander Motin >> > wrote: >>> >>> Hi, Brett, >>> >>> Could you tell more about "ticks has increased 8x"? Tickless >>> mode it is somewhat tricky algorithm to track global ticks >>> counter, but it should not jump that big. Jumps there could >>> easily trigger wrong callout behavior in 9 (in 10 callout code >>> was rewritten and no longer depend on ticks). >>> >>> >>> On 21.11.2013 22:19, Adrian Chadd wrote: >>> >>> It sounds like you may have found an interesting test case. >>> >>> Mav, any ideas? >>> >>> On 21 November 2013 05:20, Bret Ketchum >> > wrote: >>> >>> I've a callout which runs every 100ms and does a >>> bit of accounting >>> using the global ticks variable. This one-shot callout >>> was called fairly >>> consistently in 8.1, every 100ms give or take a few >>> thousand clocks. I've >>> recently upgraded to 9.1 and for the most part the >>> period is consistent. >>> However, periodically the callout function is executed >>> anywhere between 5ms >>> to 20ms after the callout was reset and the function >>> returned while global >>> ticks has increased 8x. The hardware has not changed >>> (using the same >>> timecounter configuration): >>> >>> CPU: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz >>> (2500.05-MHz K8-class CPU) >>> >>> kern.timecounter.hardware: TSC-low >>> kern.timecounter.tick: 1 >>> kern.timecounter.invariant___tsc: 1 >>> >>> kern.timecounter.smp_tsc: 1 >>> >>> And default eventtimer configuration: >>> >>> kern.eventtimer.singlemul: 2 >>> kern.eventtimer.idletick: 0 >>> kern.eventtimer.activetick: 1 >>> kern.eventtimer.timer: LAPIC >>> kern.eventtimer.periodic: 0 >>> >>> If tickless mode is disabled the inconsistency >>> goes away. Is the >>> premature expiration of the callout expected? Is the >>> jump in global ticks >>> typical (say from 100 ticks to 800 ticks in 1.5ms)? >>> >>> Bret >>> _________________________________________________ >>> freebsd-hackers@freebsd.org >>> mailing list >>> >>> http://lists.freebsd.org/__mailman/listinfo/freebsd-__hackers >>> >>> >>> >>> To unsubscribe, send any mail to >>> "freebsd-hackers-unsubscribe@__freebsd.org >>> " >>> >>> >>> >>> -- >>> Alexander Motin >>> >>> >>> >> >> >> -- >> Alexander Motin > > From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 4 17:45:07 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF98ADD0 for ; Wed, 4 Dec 2013 17:45:07 +0000 (UTC) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C09721220 for ; Wed, 4 Dec 2013 17:45:07 +0000 (UTC) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 20DF120F7A for ; Wed, 4 Dec 2013 12:45:06 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Wed, 04 Dec 2013 12:45:06 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=CKj1jqgG4uwa8PUTVl4A1CK82x8=; b=pfy lvLd6DnUgjg3gNXQ5i5hKQCfX9noZIKZ5rPTfukgoXkekAfIRFcGsThPaZgLzsBf mjheIenTbOUFg5Ri8gA/OAT+9eJGimVAYFJLcFIjbuuwz9RAVfyotOZVoBO4ZCsp OzNghgqazNqQQJB36Jv8HQesmTmqMqp8/U5LwqIE= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id F10E710B390; Wed, 4 Dec 2013 12:45:05 -0500 (EST) Message-Id: <1386179105.17871.55518481.669547E0@webmail.messagingengine.com> X-Sasl-Enc: /HVdR1ruYMReuXBcJb2dHA5iZtp5asQZ91dL0xnwEfCO 1386179105 From: Mark Felder To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-c99dcdd8 In-Reply-To: <2093792.KXDdxCWCWG@hactar> References: <3074012.QmsohyHcnK@hactar> <1386093729.5203.55046221.21CD5331@webmail.messagingengine.com> <2093792.KXDdxCWCWG@hactar> Subject: Re: Kind of hacky fix for banshee-2.6.0 Date: Wed, 04 Dec 2013 11:45:05 -0600 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 17:45:08 -0000 On Wed, Dec 4, 2013, at 4:40, Stefan Wendler wrote: > On Tuesday 03 December 2013 12:02:09 Mark Felder wrote: > > Are all of these files Makefile.in or Makefile.am ? If so, this patch > > would fix it: > > Hey, that's a nice hint. I've seen somthing similar in the doc right > after > I've sent the mail. > I am currently trying to figure out how to adapt the REINPLACE_CMD to not > only > change the line but to add the variable where it is not present. I think > I > have to play around a bit here, see how other ports solved this > > Thx for the patch. This helped alot! > I have a build dependency issue so I can't even get my poudriere to build banshee and test further. I'll poke at it again later this week if I get a chance. Feel free to bounce questions off us in IRC as well. From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 4 20:38:29 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6A58049C for ; Wed, 4 Dec 2013 20:38:29 +0000 (UTC) Received: from zimbra2.tngtech.com (zimbra2.tngtech.com [212.204.93.103]) by mx1.freebsd.org (Postfix) with ESMTP id 286141F9A for ; Wed, 4 Dec 2013 20:38:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra2.tngtech.com (Postfix) with ESMTP id F28199CE091 for ; Wed, 4 Dec 2013 21:38:22 +0100 (CET) X-Virus-Scanned: amavisd-new at tngtech.com Received: from zimbra2.tngtech.com ([127.0.0.1]) by localhost (zimbra2.tngtech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3a9Tk5MhGsZ for ; Wed, 4 Dec 2013 21:37:45 +0100 (CET) Received: from hactar.localnet (mnch-5d86e10d.pool.mediaWays.net [93.134.225.13]) by zimbra2.tngtech.com (Postfix) with ESMTPSA id 1905E9CE0E7 for ; Wed, 4 Dec 2013 21:37:45 +0100 (CET) From: Stefan Wendler To: freebsd-hackers@freebsd.org Subject: Re: Kind of hacky fix for banshee-2.6.0 Date: Wed, 04 Dec 2013 21:37:44 +0100 Message-ID: <1687534.6K1SDGFtbY@hactar> Organization: TNG Technology Consulting GmbH User-Agent: KMail/4.10.5 (FreeBSD/9.2-RELEASE; KDE/4.10.5; amd64; ; ) In-Reply-To: <1386179105.17871.55518481.669547E0@webmail.messagingengine.com> References: <3074012.QmsohyHcnK@hactar> <2093792.KXDdxCWCWG@hactar> <1386179105.17871.55518481.669547E0@webmail.messagingengine.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 20:38:29 -0000 On Wednesday 04 December 2013 11:45:05 Mark Felder wrote: > > I have a build dependency issue so I can't even get my poudriere to > build banshee and test further. I'll poke at it again later this week if > I get a chance. Feel free to bounce questions off us in IRC as well. I will do that. But I have a general question. Is it even possible to do the following within REINPLACE_CMD: insert a line, if it is not present? Because the ASSEMBLY_BUILD_FLAGS variable has to be in almost all Makefile.in files. And there are alot. Cheers, Stefan From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 4 21:19:04 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF0AC3D4 for ; Wed, 4 Dec 2013 21:19:04 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 645B411F1 for ; Wed, 4 Dec 2013 21:19:04 +0000 (UTC) Received: from mandree.no-ip.org ([78.49.75.28]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MbxJ8-1W4KnI0CGs-00JGiI for ; Wed, 04 Dec 2013 22:19:02 +0100 Received: from [IPv6:::1] (localhost6.localdomain6 [IPv6:::1]) by apollo.emma.line.org (Postfix) with ESMTP id D831E23D02A for ; Wed, 4 Dec 2013 22:19:00 +0100 (CET) Message-ID: <529F9C44.3070202@gmx.de> Date: Wed, 04 Dec 2013 22:19:00 +0100 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Kind of hacky fix for banshee-2.6.0 References: <3074012.QmsohyHcnK@hactar> <2093792.KXDdxCWCWG@hactar> <1386179105.17871.55518481.669547E0@webmail.messagingengine.com> <1687534.6K1SDGFtbY@hactar> In-Reply-To: <1687534.6K1SDGFtbY@hactar> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Onr5+/05TKtNxKeVaaGcP7PdHSky4KfwJpV6cjTRdbpzfaUfI3J Qvk/ylbP/RYC4+ifNgWUL/7BU4aBlE/oYHrM4vNGjNHLh+E9OPWW5Lsa/Aca5W/mBP+SLWk NqDgUQOOy2Rs2ZYurWsPk+D9j27xvPEDQHKlK4Xk3KMstfNeVceGgJQ66JzOFECFmMKidXI mK08UR0qkMfBfczF72GnA== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 21:19:04 -0000 Am 04.12.2013 21:37, schrieb Stefan Wendler: > On Wednesday 04 December 2013 11:45:05 Mark Felder wrote: >> >> I have a build dependency issue so I can't even get my poudriere to >> build banshee and test further. I'll poke at it again later this week if >> I get a chance. Feel free to bounce questions off us in IRC as well. > I will do that. > > But I have a general question. Is it even possible to do the following within > REINPLACE_CMD: insert a line, if it is not present? Because the > ASSEMBLY_BUILD_FLAGS variable has to be in almost all Makefile.in files. And > there are alot. Yes, but code like that starts getting cumbersome. You might get away with (sorry, I got to quote this to cheat my mailer not to word-wrap): > for i in $(${FIND} ${WRKSRC} -name 'Makefile.*'); do ; \ > if ${GREP} -q "ASSEMBLY_BUILD_FLAGS" ; then \ > ${REINPLACE_CMD} -E 's|ASSEMBLY_BUILD_FLAGS = -unsafe|ASSEMBLY_BUILD_FLAGS = -unsafe -sdk:4|' $$i ; \ > else ${REINPLACE_CMD} -E "1iASSEMBLY_BUILD_FLAGS=-unsafe -sdk:4" $$i ; fi; \ > done Where 1i is the magic incantation to insert on (i. e. before) line 1. If you have a common anchor text, you can replace the 1 by /uniquetext/, as in: ${REINPLACE_CMD} -E '/^MAGICPLACE/iASSEMBLY_BUILD_FLAGS=...' $$i From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 4 21:22:14 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 076FA501; Wed, 4 Dec 2013 21:22:14 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9C23D1239; Wed, 4 Dec 2013 21:22:13 +0000 (UTC) Received: from BL2PR03MB210.namprd03.prod.outlook.com (10.255.230.144) by BL2PR03MB210.namprd03.prod.outlook.com (10.255.230.144) with Microsoft SMTP Server (TLS) id 15.0.837.10; Wed, 4 Dec 2013 21:22:05 +0000 Received: from BL2PR03MB210.namprd03.prod.outlook.com ([169.254.1.158]) by BL2PR03MB210.namprd03.prod.outlook.com ([169.254.1.158]) with mapi id 15.00.0837.004; Wed, 4 Dec 2013 21:22:05 +0000 From: "Abhishek Gupta (LIS)" To: "freebsd-current@freebsd.org" , "freebsd-hackers@freebsd.org" Subject: Hyper-V Drivers Not Included in i386 ISO Thread-Topic: Hyper-V Drivers Not Included in i386 ISO Thread-Index: AQHO73pU4qFQham3Nk6nuDQj6C//0ppBX/wAgAAAJTCAAAKigIAAAB4ggABF94CAARaIa4AADSgAgAAD/ICAAauDsIAAEnow Date: Wed, 4 Dec 2013 21:22:04 +0000 Message-ID: <4fa6849bbb18403f8d30d5ab3a3a1c9c@BL2PR03MB210.namprd03.prod.outlook.com> References: <0fb7339604164487a4b200c364724e20@BL2PR03MB210.namprd03.prod.outlook.com> <529CF178.1000500@freebsd.org> <529CF3CD.2030509@freebsd.org> <606ef6c4b4f24fe4bd39506efc5f54be@BL2PR03MB210.namprd03.prod.outlook.com>, <529D2E97.7000604@freebsd.org> <529E2346.8040209@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ed43::2] x-forefront-prvs: 0050CEFE70 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(164054003)(83322001)(81686001)(56776001)(54316002)(90146001)(47446002)(56816005)(74502001)(81816001)(74706001)(53806001)(4396001)(2656002)(49866001)(76576001)(54356001)(77982001)(33646001)(77096001)(76796001)(59766001)(76786001)(87936001)(83072001)(74662001)(85852002)(31966008)(85306002)(69226001)(65816001)(80022001)(81542001)(85806002)(76482001)(79102001)(50986001)(81342001)(47976001)(47736001)(74366001)(80976001)(51856001)(63696002)(87266001)(74316001)(46102001)(74876001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB210; H:BL2PR03MB210.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ed43::2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/mixed; boundary="_002_4fa6849bbb18403f8d30d5ab3a3a1c9cBL2PR03MB210namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-Mailman-Approved-At: Wed, 04 Dec 2013 22:04:08 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 21:22:14 -0000 --_002_4fa6849bbb18403f8d30d5ab3a3a1c9cBL2PR03MB210namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks, It appears that Hyper-V drivers are not part of the FreeBSD 10 i386 ISO by = default. Please could someone help us include the attached patch in FreeBSD= 10? This will save a lot of time and headache for FreeBSD 10 i386 users. W= e have built a private ISO and have tested the patch locally and it seems t= o work. Unfortunately we do not have a committed maintainer at our end so a= re looking for some help. Please let us know if someone could lend a hand. Thanks, Abhishek --_002_4fa6849bbb18403f8d30d5ab3a3a1c9cBL2PR03MB210namprd03pro_ Content-Type: application/octet-stream; name="i386_patch.patch" Content-Description: i386_patch.patch Content-Disposition: attachment; filename="i386_patch.patch"; size=1927; creation-date="Wed, 04 Dec 2013 20:17:46 GMT"; modification-date="Wed, 04 Dec 2013 20:17:46 GMT" Content-Transfer-Encoding: base64 SW5kZXg6IHN5cy9jb25mL2ZpbGVzLmkzODYKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2NvbmYvZmlsZXMu aTM4NgkocmV2aXNpb24gMjU4OTEyKQorKysgc3lzL2NvbmYvZmlsZXMuaTM4Ngkod29ya2luZyBj b3B5KQpAQCAtMjIxLDYgKzIyMSwxOCBAQAogZGV2L2h3cG1jL2h3cG1jX3Bwcm8uYwkJb3B0aW9u YWwgaHdwbWMKIGRldi9od3BtYy9od3BtY190c2MuYwkJb3B0aW9uYWwgaHdwbWMKIGRldi9od3Bt Yy9od3BtY194ODYuYwkJb3B0aW9uYWwgaHdwbWMKK2Rldi9oeXBlcnYvbmV0dnNjL2h2X25ldF92 c2MuYyAgICAgICAgICAgICAgICAgICAgICAgICAgb3B0aW9uYWwgICAgICAgIGh5cGVydgorZGV2 L2h5cGVydi9uZXR2c2MvaHZfbmV0dnNjX2Rydl9mcmVlYnNkLmMgICAgICAgICAgICAgICBvcHRp b25hbCAgICAgICAgaHlwZXJ2CitkZXYvaHlwZXJ2L25ldHZzYy9odl9ybmRpc19maWx0ZXIuYyAg ICAgICAgICAgICAgICAgICAgIG9wdGlvbmFsICAgICAgICBoeXBlcnYKK2Rldi9oeXBlcnYvc3Rv cmRpc2VuZ2FnZS9odl9hdGFfcGNpX2Rpc2VuZ2FnZS5jICAgICAgICAgb3B0aW9uYWwgICAgICAg IGh5cGVydgorZGV2L2h5cGVydi9zdG9ydnNjL2h2X3N0b3J2c2NfZHJ2X2ZyZWVic2QuYyAgICAg ICAgICAgICBvcHRpb25hbCAgICAgICAgaHlwZXJ2CitkZXYvaHlwZXJ2L3V0aWxpdGllcy9odl91 dGlsLmMgICAgICAgICAgICAgICAgICAgICAgICAgIG9wdGlvbmFsICAgICAgICBoeXBlcnYKK2Rl di9oeXBlcnYvdm1idXMvaHZfY2hhbm5lbC5jICAgICAgICAgICAgICAgICAgICAgICAgICAgb3B0 aW9uYWwgICAgICAgIGh5cGVydgorZGV2L2h5cGVydi92bWJ1cy9odl9jaGFubmVsX21nbXQuYyAg ICAgICAgICAgICAgICAgICAgICBvcHRpb25hbCAgICAgICAgaHlwZXJ2CitkZXYvaHlwZXJ2L3Zt YnVzL2h2X2Nvbm5lY3Rpb24uYyAgICAgICAgICAgICAgICAgICAgICAgIG9wdGlvbmFsICAgICAg ICBoeXBlcnYKK2Rldi9oeXBlcnYvdm1idXMvaHZfaHYuYyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgb3B0aW9uYWwgICAgICAgIGh5cGVydgorZGV2L2h5cGVydi92bWJ1cy9odl9yaW5n X2J1ZmZlci5jICAgICAgICAgICAgICAgICAgICAgICBvcHRpb25hbCAgICAgICAgaHlwZXJ2Citk ZXYvaHlwZXJ2L3ZtYnVzL2h2X3ZtYnVzX2Rydl9mcmVlYnNkLmMgICAgICAgICAgICAgICAgIG9w dGlvbmFsICAgICAgICBoeXBlcnYKIGRldi9pY2h3ZC9pY2h3ZC5jCQlvcHRpb25hbCBpY2h3ZAog ZGV2L2lmX25kaXMvaWZfbmRpcy5jCQlvcHRpb25hbCBuZGlzCiBkZXYvaWZfbmRpcy9pZl9uZGlz X3BjY2FyZC5jCW9wdGlvbmFsIG5kaXMgcGNjYXJkCkluZGV4OiBzeXMvaTM4Ni9jb25mL0dFTkVS SUMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQotLS0gc3lzL2kzODYvY29uZi9HRU5FUklDCShyZXZpc2lvbiAyNTg5MTIp CisrKyBzeXMvaTM4Ni9jb25mL0dFTkVSSUMJKHdvcmtpbmcgY29weSkKQEAgLTM0Niw2ICszNDYs OSBAQAogZGV2aWNlCQl2aXJ0aW9fc2NzaQkjIFZpcnRJTyBTQ1NJIGRldmljZQogZGV2aWNlCQl2 aXJ0aW9fYmFsbG9vbgkjIFZpcnRJTyBNZW1vcnkgQmFsbG9vbiBkZXZpY2UKIAorIyBIeXBlclYg ZHJpdmVycworZGV2aWNlICAgICAgICAgIGh5cGVydiAgICAgICAgICAjIEh5cGVyViBkcml2ZXJz CisKICMgWGVuIEhWTSBHdWVzdCBPcHRpbWl6YXRpb25zCiAjIE5PVEU6IFhFTkhWTSBkZXBlbmRz IG9uIHhlbnBjaS4gIFRoZXkgbXVzdCBiZSBhZGRlZCBvciByZW1vdmVkIHRvZ2V0aGVyLgogb3B0 aW9ucyAJWEVOSFZNCQkjIFhlbiBIVk0ga2VybmVsIGluZnJhc3RydWN0dXJlCg== --_002_4fa6849bbb18403f8d30d5ab3a3a1c9cBL2PR03MB210namprd03pro_-- From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 5 00:23:41 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A36AA208 for ; Thu, 5 Dec 2013 00:23:41 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3BA2C1DC0 for ; Thu, 5 Dec 2013 00:23:40 +0000 (UTC) Received: from mandree.no-ip.org ([78.49.75.28]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MQhyf-1WB9u23VOv-00U2Bm for ; Thu, 05 Dec 2013 01:18:28 +0100 Received: from [IPv6:::1] (localhost6.localdomain6 [IPv6:::1]) by apollo.emma.line.org (Postfix) with ESMTP id 110B723D02A; Thu, 5 Dec 2013 01:18:27 +0100 (CET) Message-ID: <529FC652.1060004@gmx.de> Date: Thu, 05 Dec 2013 01:18:26 +0100 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Asynchronous user-space notification of interface address changes? References: <529EF36A.2020906@gmx.de> <1386171248.58852.78.camel@revolution.hippie.lan> In-Reply-To: <1386171248.58852.78.camel@revolution.hippie.lan> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:kuEcSoy8dmiW1b7DnTdanFu8vYsQQu8cECPW3eiM+Zo4YUo98dO /TQOhxWrS/kUTZv+WADVywvlx2siw+g6QMKs/3udusNnA/aTTMSF5v7iAXvef1eZV4yn//z ZLSBEUPaQ/oQbKV1JTvvJy7USH/UgnuH/8yg0kjHmkv23N+0DoXUgVMOeparuNNiK+nNl7n KL60wfDMVoMnc2+woEgFw== Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 00:23:41 -0000 Am 04.12.2013 16:34, schrieb Ian Lepore: > On Wed, 2013-12-04 at 10:18 +0100, Matthias Andree wrote: >> Greetings, >> >> is there any sensible way to have a user-space application notified of >> interface address changes (in the light of - but not limited to - IPv6 >> automatic configuration, with accept_rtadv or similar), preferably >> without the application polling getifaddrs every five-ish seconds? >> >> It does not appear kevent/kqueue, or devctl, are up to the task. >> >> I am not asking for turnkey solutions (although I'll gladly take them), >> a rough sketch or pointers will suffice. >> >> Thanks. >> >> Best regards >> Matthias > > Open a routing socket, select/poll for readability, handle incoming > RTM_NEWADDR/RTM_DELADDR messages. Example code in dhclient and faithd > and I think ntpd among others. Some info available in man 4 route. > I've never done this, just remember seeing the code for it in dhclient. Right on the spot, thank you. Quick and dirty demo code to decode such messages at and sent off to the dnsmasq-discuss mailing list. I find the part on how exactly the message addresses are laid out a bit too terse in route(4) and had to spy into natd.c to figure it out. Perhaps I've overlooked something, but rounding up the sockaddr to the next multiple of sizeof(long), or second-guessing to use sizeof(long) if the length is 0, was not obvious to me from that manual page, or the includes. From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 5 01:01:36 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05A4F51A for ; Thu, 5 Dec 2013 01:01:36 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1CE6F1FFA for ; Thu, 5 Dec 2013 01:01:34 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id m15so15845960wgh.25 for ; Wed, 04 Dec 2013 17:01:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=CYwy9GZdvaF6jJzfxO+fDz39X2BXyZet5YZgV2CGB9o=; b=gu6cwdUQZ3t5ZMlJ10kAiMEaMyV28/R7owg0AZGAUF1BEs0+ZBMbQIHcl+5gPflQjo cNgvOph2K7lfQAP/gOimKXKtpnd+ZImZqqS7Po+80d2i57KSAsJ85jpisjP2igH4dWV5 Gls37KMgJZ/2cm6R6KwuGcWzyjyrHxW78SBPPNXfDX4vLktX7zjATCDRosMQ6HOVbSbR Wpv7QR36G0TcwsABlVT9qX6SGBPoHaYZ9NCQzWoYVWcw4QSrj5QD3z2yLFn/kOGmv8+3 RL0qB+2dgkVn1LHY32DJOrcXHwd+WaBuL/zA1UB4cdt7S1hjkHDtpFHDMfFaIfpeuCgh 7HOg== MIME-Version: 1.0 X-Received: by 10.194.89.233 with SMTP id br9mr65448517wjb.15.1386205293375; Wed, 04 Dec 2013 17:01:33 -0800 (PST) Received: by 10.194.201.169 with HTTP; Wed, 4 Dec 2013 17:01:33 -0800 (PST) Date: Thu, 5 Dec 2013 05:01:33 +0400 Message-ID: Subject: [CFT] TPM(Trusted Platform Modules) replated ports From: Andrey Fesenko To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 01:01:36 -0000 Hello, anyone else tried to test these ports? uname -a FreeBSD x220.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r257734: Wed Nov 6 11:33:53 MSK 2013 andrey@x220.local:/usr/obj/usr/src/sys/W_BOOK amd64 security/trousers - need add user in comand line and remove path var directory pkg-plist security/opencryptoki - checking for csulincl.h... no configure: error: tpm token build requested but TSS development files not found ===> Script "configure" failed unexpectedly. Please report the problem to hrs@FreeBSD.org [maintainer] and attach the "/usr/ports/security/opencryptoki/work/opencryptoki-2.3.2/config.log" including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. a /usr/local/sbin/pkg-static info -g -Ea). *** Error code 1 Stop. make: stopped in /usr/ports/security/opencryptoki From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 5 01:10:10 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8F4D9AC for ; Thu, 5 Dec 2013 01:10:10 +0000 (UTC) Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 42FAE1068 for ; Thu, 5 Dec 2013 01:10:10 +0000 (UTC) Received: by mail-ee0-f41.google.com with SMTP id t10so2856706eei.0 for ; Wed, 04 Dec 2013 17:10:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QQJjq7aqc4XEGIa56HxrPDUUk6w7RxmdWmFCkUAAxsQ=; b=mEDMAHsHn3rG8L8gw2ZYlZLbMzrwloGJijOYvKHV88RtZN5SSskCUYEyY5JTbJqtkh nBMojz34QnYs07fNOU/N+otNll9Hab5eY/ZzNj6lq6F7RYiiHjI5yRjC8iMU3c0t3pu5 atZePOF3bU1zUEzU5UTzfsIAhHNcnV5et5y0x6IMSc2cK3DHoTyvY3rQf69skhWLZOyK 5/lw+UFMHtNgFz8ZjNBdbVFZrE/p+MStjtD4cufYgvI9aGHLRRKr/6XdQ5zbLzj1gagV l6SXvG6DETBibUZuyMc3m2yji+gRcY3RNSqrDJX/854APZ3MIa7hi7AvWxk2CA9yTRQA y50A== MIME-Version: 1.0 X-Received: by 10.14.4.67 with SMTP id 43mr9751534eei.70.1386205808764; Wed, 04 Dec 2013 17:10:08 -0800 (PST) Received: by 10.14.2.66 with HTTP; Wed, 4 Dec 2013 17:10:08 -0800 (PST) In-Reply-To: References: Date: Wed, 4 Dec 2013 17:10:08 -0800 Message-ID: Subject: Re: [CFT] TPM(Trusted Platform Modules) replated ports From: hiren panchasara To: Andrey Fesenko Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 01:10:10 -0000 On Wed, Dec 4, 2013 at 5:01 PM, Andrey Fesenko wrote: > security/trousers - need add user in comand line and remove path var > directory pkg-plist hrs@ just fixed this port a few mins back. > security/opencryptoki - checking for csulincl.h... no > configure: error: tpm token build requested but TSS development files not found > ===> Script "configure" failed unexpectedly. Try sending this report on ports@ ? cheers, Hiren From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 5 01:45:36 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 425804A2; Thu, 5 Dec 2013 01:45:36 +0000 (UTC) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 103FA125A; Thu, 5 Dec 2013 01:45:34 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id x12so15610700wgg.28 for ; Wed, 04 Dec 2013 17:45:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zMjZnOKOleiP4KAGmfLDRHJrWaqsAIYs03F4S83o6Co=; b=IZRmEIGL60Hb6WCI6NGNUasvrvTTfj3pAoTDMWbCzIMeUhkOi5Ln9fSDTIW31YMqMj o2urEDHqlMoWc8/bC13vmrSy/lln6kRInSEXXaMH5OQeXgI0wqA4te9TbeFAifdiz1Hb +Mc831C0yOAwK477BZ2X0v1BvqVAds6+rfPrF6O4m+K1DGGAyusy9P2MaA0yZmYza+uA tfDgy1CwbzvjPcQDWcWVJ6vCYuVRJWgcuR2P/CSv7FHXIwvJ+AD6bdLHcJljUoD5S+Rn eFd3wP3w5WiwH09tu5H/kSGALHPT/BzmDyikxKev64CzJHg1nxkIcp1R2KqoS6FH6cvg Vhjw== MIME-Version: 1.0 X-Received: by 10.180.91.11 with SMTP id ca11mr9788237wib.39.1386207933547; Wed, 04 Dec 2013 17:45:33 -0800 (PST) Received: by 10.194.201.169 with HTTP; Wed, 4 Dec 2013 17:45:33 -0800 (PST) In-Reply-To: References: Date: Thu, 5 Dec 2013 05:45:33 +0400 Message-ID: Subject: Re: [CFT] TPM(Trusted Platform Modules) replated ports From: Andrey Fesenko To: hiren panchasara Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: ports@freebsd.org, "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 01:45:36 -0000 On Thu, Dec 5, 2013 at 5:10 AM, hiren panchasara wrote: > On Wed, Dec 4, 2013 at 5:01 PM, Andrey Fesenko wrote: > >> security/trousers - need add user in comand line and remove path var >> directory pkg-plist > hrs@ just fixed this port a few mins back. > Yes, install not error :) >> security/opencryptoki - checking for csulincl.h... no >> configure: error: tpm token build requested but TSS development files not found >> ===> Script "configure" failed unexpectedly. > > Try sending this report on ports@ ? > > cheers, > Hiren No, make cc this message. ports revision 335651 configure: error: tpm token build requested but TSS development files not found ===> Script "configure" failed unexpectedly. Please report the problem to hrs@FreeBSD.org [maintainer] and attach the "/usr/ports/security/opencryptoki/work/opencryptoki-2.3.2/config.log" including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. a /usr/local/sbin/pkg-static info -g -Ea). From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 5 08:07:25 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 14F74FCE; Thu, 5 Dec 2013 08:07:25 +0000 (UTC) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 80DF21625; Thu, 5 Dec 2013 08:07:24 +0000 (UTC) Received: from alph.d.allbsd.org (p4181-ipbf1307funabasi.chiba.ocn.ne.jp [123.225.173.181]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id rB5874qB030041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Dec 2013 17:07:14 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.7/8.14.5) with ESMTP id rB5872t2014195; Thu, 5 Dec 2013 17:07:03 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Thu, 05 Dec 2013 17:06:56 +0900 (JST) Message-Id: <20131205.170656.1189588673301617423.hrs@allbsd.org> To: f0andrey@gmail.com Subject: Re: [CFT] TPM(Trusted Platform Modules) replated ports From: Hiroki Sato In-Reply-To: References: X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Thu_Dec__5_17_06_56_2013_719)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Thu, 05 Dec 2013 17:07:14 +0900 (JST) X-Spam-Status: No, score=-98.9 required=13.0 tests=CONTENT_TYPE_PRESENT, QENCPTR1,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: ports@FreeBSD.org, freebsd-hackers@FreeBSD.org, hiren.panchasara@gmail.com X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 08:07:25 -0000 ----Security_Multipart(Thu_Dec__5_17_06_56_2013_719)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andrey Fesenko wrote in : f0> On Thu, Dec 5, 2013 at 5:10 AM, hiren panchasara f0> wrote: f0> > On Wed, Dec 4, 2013 at 5:01 PM, Andrey Fesenko wrote: f0> > f0> >> security/trousers - need add user in comand line and remove path var f0> >> directory pkg-plist f0> > hrs@ just fixed this port a few mins back. f0> > f0> Yes, install not error :) f0> f0> >> security/opencryptoki - checking for csulincl.h... no f0> >> configure: error: tpm token build requested but TSS development files not found f0> >> ===> Script "configure" failed unexpectedly. f0> > f0> > Try sending this report on ports@ ? f0> > f0> > cheers, f0> > Hiren f0> f0> No, make cc this message. f0> ports revision 335651 Can you try r335654? security/trousers has to be updated because of iconv library conflict. -- Hiroki ----Security_Multipart(Thu_Dec__5_17_06_56_2013_719)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlKgNCAACgkQTyzT2CeTzy20FACdHoqmdUt4ng2wUoKfC4hnY8T9 PqsAn35eH7CZ83NP29QVAc7mbHNedOjT =LioH -----END PGP SIGNATURE----- ----Security_Multipart(Thu_Dec__5_17_06_56_2013_719)---- From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 5 08:32:20 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70151737; Thu, 5 Dec 2013 08:32:20 +0000 (UTC) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B067517B2; Thu, 5 Dec 2013 08:32:19 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id w62so10565165wes.35 for ; Thu, 05 Dec 2013 00:32:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QsUXKgfyF1pklnP0SCgwwWwVA17KwTQHzxsi8bUHPpY=; b=GfUR7joGQhQJUEZf7JWrP596r8FCXQwRr33sPkotZ9Cpa1qDCAsaZqF0eiodyU3mXq kqazHhDdcthATGkJY2/4YB7Sml90qxOdtlhxhJysCPofYFKmJPr7lpnTMMTHOrAbz3cV p8okcLpqKQ0kkeQU7QgSBQApjSEq2WgMs8xYFZTMZVIlXr5gdVEo4DXr9DIF+ODCvwYQ 2MuS3UtsUlnBMXGkByD5W+XcMzmfloS0vjRECY9f6L9RLIBOxaUei8k/N+t1qFT/LQI9 zOrJRSs9sXVzjy9ZFLG7plgJSyFADsWzqB3Bh1qMc0iwz3WoX+WJbQWMaZ5Ax5ni8xf/ Vqvg== MIME-Version: 1.0 X-Received: by 10.180.73.111 with SMTP id k15mr10886106wiv.39.1386232336697; Thu, 05 Dec 2013 00:32:16 -0800 (PST) Received: by 10.194.201.169 with HTTP; Thu, 5 Dec 2013 00:32:16 -0800 (PST) In-Reply-To: <20131205.170656.1189588673301617423.hrs@allbsd.org> References: <20131205.170656.1189588673301617423.hrs@allbsd.org> Date: Thu, 5 Dec 2013 12:32:16 +0400 Message-ID: Subject: Re: [CFT] TPM(Trusted Platform Modules) replated ports From: Andrey Fesenko To: Hiroki Sato Content-Type: text/plain; charset=UTF-8 Cc: ports@freebsd.org, "freebsd-hackers@freebsd.org" , hiren panchasara X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 08:32:20 -0000 On Thu, Dec 5, 2013 at 12:06 PM, Hiroki Sato wrote: > Andrey Fesenko wrote > in : > > f0> On Thu, Dec 5, 2013 at 5:10 AM, hiren panchasara > f0> wrote: > f0> > On Wed, Dec 4, 2013 at 5:01 PM, Andrey Fesenko wrote: > f0> > > f0> >> security/trousers - need add user in comand line and remove path var > f0> >> directory pkg-plist > f0> > hrs@ just fixed this port a few mins back. > f0> > > f0> Yes, install not error :) > f0> > f0> >> security/opencryptoki - checking for csulincl.h... no > f0> >> configure: error: tpm token build requested but TSS development files not found > f0> >> ===> Script "configure" failed unexpectedly. > f0> > > f0> > Try sending this report on ports@ ? > f0> > > f0> > cheers, > f0> > Hiren > f0> > f0> No, make cc this message. > f0> ports revision 335651 > > Can you try r335654? security/trousers has to be updated because of > iconv library conflict. > > -- Hiroki Thank you so much, after update r335655 work fine :) # tpm_version TPM 1.2 Version Info: Chip Version: 1.2.8.32 Spec Level: 2 Errata Revision: 3 TPM Vendor ID: STM TPM Version: 01010000 Manufacturer Info: 53544d20 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 5 13:53:44 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4956B20C for ; Thu, 5 Dec 2013 13:53:44 +0000 (UTC) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D79B41E27 for ; Thu, 5 Dec 2013 13:53:43 +0000 (UTC) Received: by mail-ee0-f48.google.com with SMTP id e49so3272135eek.21 for ; Thu, 05 Dec 2013 05:53:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:subject:date; bh=bkWWQzNq+sXvpIlf/WHS8cf1c+IaloutEfBStQm8Ev4=; b=v3zAPh06CuuLWNy+i1BMCPcfjb586QgZH5h6L94VxVvRbFoZy8DouhwohBlTuMMKlY xlHaQRS8OfxV7DXNfO7XAXAHm4Oa4oK+7MRdrO3q1lNCHgqDHysUKZ4Rq9HNfzg/M30z eBIrEL3KpZ7l9h0XXIWJVPo63oumlNfVxiHEREQPf8HSSIFWNo9kukhEQ9UCoxvZMr3/ o/UpkckEvkm3NO5dEQ44z6Xk5EC0m9S09DPidBxysFBJdHzEkULqskDnf+qZ68igbv7u 4R6ETDhzZnU9cwjLpn45MjoRVDo5k/aiyULymEKPh8KaVOF2Y8vENo6FG0UojV1hxgYl msaA== X-Received: by 10.14.113.199 with SMTP id a47mr16705623eeh.41.1386251622184; Thu, 05 Dec 2013 05:53:42 -0800 (PST) Received: from DOMYPC ([82.193.208.225]) by mx.google.com with ESMTPSA id n1sm106462119eep.20.2013.12.05.05.53.40 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 05 Dec 2013 05:53:41 -0800 (PST) Message-ID: <20131205.135341.967.2@DOMY-PC> From: rank1seeker@gmail.com To: hackers@freebsd.org Subject: 9.2-RELEASE p1 => p2 Date: Thu, 05 Dec 2013 14:53:41 +0100 X-Mailer: POP Peeper (3.8.1.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 13:53:44 -0000 Under 9.2-RELEASE-p1: After it's src tree updated to p2, it's sec advisory wasn't available: -- fetch: https://www.freebsd.org/security/advisories/FreeBSD-EN-13:05.freebsd-update.asc: Not Found -- But it was, a few hrs later. Then, upon custom kernel install, I've received non fatal error -- awk: can't open file /usr/obj/usr/src/include/osreldate.h source line number 1 "/usr/src/sys/conf/kern.post.mk", line 54: warning: "awk '/^#define[[:space:]]*__FreeBSD_version/ { print $3 }' /usr/obj/usr/src/include/osreldate.h" returned non-zero status -- Domagoj From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 5 15:17:08 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F24AB02 for ; Thu, 5 Dec 2013 15:17:08 +0000 (UTC) Received: from mail.embedded-brains.de (host-82-135-62-35.customer.m-online.net [82.135.62.35]) by mx1.freebsd.org (Postfix) with ESMTP id 0EEB11378 for ; Thu, 5 Dec 2013 15:17:05 +0000 (UTC) Received: by mail.embedded-brains.de (Postfix, from userid 65534) id 21A82652CFE; Thu, 5 Dec 2013 16:07:47 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on fidibusdmz X-Spam-Level: X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from [192.168.96.64] (eb0024.eb.z [192.168.96.64]) by mail.embedded-brains.de (Postfix) with ESMTP id B660B65253A; Thu, 5 Dec 2013 16:07:45 +0100 (CET) Message-ID: <52A096C1.9090400@embedded-brains.de> Date: Thu, 05 Dec 2013 16:07:45 +0100 From: Sebastian Huber User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Global variables in system programs References: <525D5A35.4040005@embedded-brains.de> In-Reply-To: <525D5A35.4040005@embedded-brains.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Eitan Adler X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 15:17:08 -0000 Hello, a small status update since some of my ROUTE(8) patches have been committed to FreeBSD HEAD recently. A library interface to the core network commands and utilities is useful, but it turned out that the ROUTE(8) program was just the most simple one to convert. I tried to do this also with IFCONFIG(8), but gave up (it uses some sort of module registry via linker sets, etc.). I use now a different approach. I initialize/destroy all global variables in a custom set-up/tear-down routine and protect the commands with a global mutex. Calls to the error and exit functions are wrapped to use a long jump. This works well so far with ROUTE(8), IFCONFIG(8), NETSTAT(1), PING(8) and PING6(8). What really helps is adding static and const qualifiers whenever possible. Function static variables are a problem since they cannot be initialized with a single set-up/tear-down routine for a module. Signals are also a problem in a multi-threaded environment (used by PING6(8)). -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 6 11:43:42 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 917F9E90; Fri, 6 Dec 2013 11:43:42 +0000 (UTC) Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EC19014CD; Fri, 6 Dec 2013 11:43:41 +0000 (UTC) Received: by mail-ee0-f52.google.com with SMTP id d17so242489eek.11 for ; Fri, 06 Dec 2013 03:43:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=2yDLcbk3AkaDanLDBJE6k6FQgaKD4irXxjzx4+IEF7k=; b=waU8x2OWyJJCyesiPCQnrNhZQQnLa4hHY6RdeeFI4hWd6vLpnWK96fcWESCaCSKEsa F6eZCUQy4EQQ2xEnwTQAHwJIdO1iEmQeJ3JNa4+NqaVkmpTMqn+t/hdpvT4/1/mbHVZn f5FkNiJeCwBm5E8/jiZhsU3Tg4aMiaVwfk0RZML9xU+iRD72A7KFlOCDMfqWivgiIfh8 r16eqM2zzvMzVXzIDADTMMwnpNGgh5CDIf/veobxGzpT9/+0MtNfBOfksNzFUzLgaQ5W my2x0thV3VULapWWa7ldoygT1bB2su16kKMbDanIX1i+LMy9a1bl1KD2gC6Z4sp5mQgU 6isA== X-Received: by 10.15.52.197 with SMTP id p45mr2266170eew.98.1386330220244; Fri, 06 Dec 2013 03:43:40 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([178.137.150.35]) by mx.google.com with ESMTPSA id h3sm91486854eem.15.2013.12.06.03.43.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Dec 2013 03:43:39 -0800 (PST) Sender: Alexander Motin Message-ID: <52A1B869.6080407@FreeBSD.org> Date: Fri, 06 Dec 2013 13:43:37 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Bret Ketchum , Adrian Chadd Subject: Re: 9.1 callout behavior References: <5295A261.2060403@FreeBSD.org> <529F4409.9080403@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 11:43:42 -0000 On 06.12.2013 13:41, Bret Ketchum wrote: > Any luck in recreating? Nope. I've tried with and without deep C-states enabled and still no any error messages on console. > On Wed, Dec 4, 2013 at 11:14 AM, Bret Ketchum > wrote: > > dev.cpu.0.%desc: ACPI CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=\_PR_.CPU1 > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.freq_levels: 2700/-1 2362/-1 2025/-1 1687/-1 1350/-1 > 1012/-1 675/-1 337/-1 > dev.cpu.0.cx_supported: C1/1 C2/41 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_usage: 100.00% 0.00% last 17444us > dev.cpu.1.%desc: ACPI CPU > dev.cpu.1.%driver: cpu > dev.cpu.1.%location: handle=\_PR_.CPU2 > dev.cpu.1.%pnpinfo: _HID=none _UID=0 > dev.cpu.1.%parent: acpi0 > dev.cpu.1.cx_supported: C1/1 C2/41 > dev.cpu.1.cx_lowest: C1 > dev.cpu.1.cx_usage: 100.00% 0.00% last 111391us > dev.cpu.2.%desc: ACPI CPU > dev.cpu.2.%driver: cpu > dev.cpu.2.%location: handle=\_PR_.CPU3 > dev.cpu.2.%pnpinfo: _HID=none _UID=0 > dev.cpu.2.%parent: acpi0 > dev.cpu.2.cx_supported: C1/1 C2/41 > dev.cpu.2.cx_lowest: C1 > dev.cpu.2.cx_usage: 100.00% 0.00% last 84732us > dev.cpu.3.%desc: ACPI CPU > dev.cpu.3.%driver: cpu > dev.cpu.3.%location: handle=\_PR_.CPU4 > dev.cpu.3.%pnpinfo: _HID=none _UID=0 > dev.cpu.3.%parent: acpi0 > dev.cpu.3.cx_supported: C1/1 C2/41 > dev.cpu.3.cx_lowest: C1 > dev.cpu.3.cx_usage: 100.00% 0.00% last 98118us > dev.cpu.4.%desc: ACPI CPU > dev.cpu.4.%driver: cpu > dev.cpu.4.%location: handle=\_PR_.CPU5 > dev.cpu.4.%pnpinfo: _HID=none _UID=0 > dev.cpu.4.%parent: acpi0 > dev.cpu.4.cx_supported: C1/1 C2/41 > dev.cpu.4.cx_lowest: C1 > dev.cpu.4.cx_usage: 100.00% 0.00% last 20991us > dev.cpu.5.%desc: ACPI CPU > dev.cpu.5.%driver: cpu > dev.cpu.5.%location: handle=\_PR_.CPU6 > dev.cpu.5.%pnpinfo: _HID=none _UID=0 > dev.cpu.5.%parent: acpi0 > dev.cpu.5.cx_supported: C1/1 C2/41 > dev.cpu.5.cx_lowest: C1 > dev.cpu.5.cx_usage: 100.00% 0.00% last 115281us > dev.cpu.6.%desc: ACPI CPU > dev.cpu.6.%driver: cpu > dev.cpu.6.%location: handle=\_PR_.CPU7 > dev.cpu.6.%pnpinfo: _HID=none _UID=0 > dev.cpu.6.%parent: acpi0 > dev.cpu.6.cx_supported: C1/1 C2/41 > dev.cpu.6.cx_lowest: C1 > dev.cpu.6.cx_usage: 100.00% 0.00% last 206us > dev.cpu.7.%desc: ACPI CPU > dev.cpu.7.%driver: cpu > dev.cpu.7.%location: handle=\_PR_.CPU8 > dev.cpu.7.%pnpinfo: _HID=none _UID=0 > dev.cpu.7.%parent: acpi0 > dev.cpu.7.cx_supported: C1/1 C2/41 > dev.cpu.7.cx_lowest: C1 > dev.cpu.7.cx_usage: 100.00% 0.00% last 111706us > dev.cpu.8.%desc: ACPI CPU > dev.cpu.8.%driver: cpu > dev.cpu.8.%location: handle=\_PR_.CPU9 > dev.cpu.8.%pnpinfo: _HID=none _UID=0 > dev.cpu.8.%parent: acpi0 > dev.cpu.8.cx_supported: C1/1 C2/41 > dev.cpu.8.cx_lowest: C1 > dev.cpu.8.cx_usage: 100.00% 0.00% last 86986us > dev.cpu.9.%desc: ACPI CPU > dev.cpu.9.%driver: cpu > dev.cpu.9.%location: handle=\_PR_.CPUA > dev.cpu.9.%pnpinfo: _HID=none _UID=0 > dev.cpu.9.%parent: acpi0 > dev.cpu.9.cx_supported: C1/1 C2/41 > dev.cpu.9.cx_lowest: C1 > dev.cpu.9.cx_usage: 100.00% 0.00% last 68431us > dev.cpu.10.%desc: ACPI CPU > dev.cpu.10.%driver: cpu > dev.cpu.10.%location: handle=\_PR_.CPUB > dev.cpu.10.%pnpinfo: _HID=none _UID=0 > dev.cpu.10.%parent: acpi0 > dev.cpu.10.cx_supported: C1/1 C2/41 > dev.cpu.10.cx_lowest: C1 > dev.cpu.10.cx_usage: 100.00% 0.00% last 109210us > dev.cpu.11.%desc: ACPI CPU > dev.cpu.11.%driver: cpu > dev.cpu.11.%location: handle=\_PR_.CPUC > dev.cpu.11.%pnpinfo: _HID=none _UID=0 > dev.cpu.11.%parent: acpi0 > dev.cpu.11.cx_supported: C1/1 C2/41 > dev.cpu.11.cx_lowest: C1 > dev.cpu.11.cx_usage: 100.00% 0.00% last 104907us > dev.cpu.12.%desc: ACPI CPU > dev.cpu.12.%driver: cpu > dev.cpu.12.%location: handle=\_PR_.CPUD > dev.cpu.12.%pnpinfo: _HID=none _UID=0 > dev.cpu.12.%parent: acpi0 > dev.cpu.12.cx_supported: C1/1 C2/41 > dev.cpu.12.cx_lowest: C1 > dev.cpu.12.cx_usage: 100.00% 0.00% last 103771us > dev.cpu.13.%desc: ACPI CPU > dev.cpu.13.%driver: cpu > dev.cpu.13.%location: handle=\_PR_.CPUE > dev.cpu.13.%pnpinfo: _HID=none _UID=0 > dev.cpu.13.%parent: acpi0 > dev.cpu.13.cx_supported: C1/1 C2/41 > dev.cpu.13.cx_lowest: C1 > dev.cpu.13.cx_usage: 100.00% 0.00% last 105845us > dev.cpu.14.%desc: ACPI CPU > dev.cpu.14.%driver: cpu > dev.cpu.14.%location: handle=\_PR_.CPUF > dev.cpu.14.%pnpinfo: _HID=none _UID=0 > dev.cpu.14.%parent: acpi0 > dev.cpu.14.cx_supported: C1/1 C2/41 > dev.cpu.14.cx_lowest: C1 > dev.cpu.14.cx_usage: 100.00% 0.00% last 83902us > dev.cpu.15.%desc: ACPI CPU > dev.cpu.15.%driver: cpu > dev.cpu.15.%location: handle=\_PR_.CPUG > dev.cpu.15.%pnpinfo: _HID=none _UID=0 > dev.cpu.15.%parent: acpi0 > dev.cpu.15.cx_supported: C1/1 C2/41 > dev.cpu.15.cx_lowest: C1 > dev.cpu.15.cx_usage: 100.00% 0.00% last 121122us > dev.cpu.16.%desc: ACPI CPU > dev.cpu.16.%driver: cpu > dev.cpu.16.%location: handle=\_PR_.CP17 > dev.cpu.16.%pnpinfo: _HID=none _UID=0 > dev.cpu.16.%parent: acpi0 > dev.cpu.16.cx_supported: C1/1 C2/41 > dev.cpu.16.cx_lowest: C1 > dev.cpu.16.cx_usage: 100.00% 0.00% last 87619us > dev.cpu.17.%desc: ACPI CPU > dev.cpu.17.%driver: cpu > dev.cpu.17.%location: handle=\_PR_.CP18 > dev.cpu.17.%pnpinfo: _HID=none _UID=0 > dev.cpu.17.%parent: acpi0 > dev.cpu.17.cx_supported: C1/1 C2/41 > dev.cpu.17.cx_lowest: C1 > dev.cpu.17.cx_usage: 100.00% 0.00% last 240us > dev.cpu.18.%desc: ACPI CPU > dev.cpu.18.%driver: cpu > dev.cpu.18.%location: handle=\_PR_.CP19 > dev.cpu.18.%pnpinfo: _HID=none _UID=0 > dev.cpu.18.%parent: acpi0 > dev.cpu.18.cx_supported: C1/1 C2/41 > dev.cpu.18.cx_lowest: C1 > dev.cpu.18.cx_usage: 100.00% 0.00% last 86250us > dev.cpu.19.%desc: ACPI CPU > dev.cpu.19.%driver: cpu > dev.cpu.19.%location: handle=\_PR_.CP20 > dev.cpu.19.%pnpinfo: _HID=none _UID=0 > dev.cpu.19.%parent: acpi0 > dev.cpu.19.cx_supported: C1/1 C2/41 > dev.cpu.19.cx_lowest: C1 > dev.cpu.19.cx_usage: 100.00% 0.00% last 68203us > dev.cpu.20.%desc: ACPI CPU > dev.cpu.20.%driver: cpu > dev.cpu.20.%location: handle=\_PR_.CP21 > dev.cpu.20.%pnpinfo: _HID=none _UID=0 > dev.cpu.20.%parent: acpi0 > dev.cpu.20.cx_supported: C1/1 C2/41 > dev.cpu.20.cx_lowest: C1 > dev.cpu.20.cx_usage: 100.00% 0.00% last 40696us > dev.cpu.21.%desc: ACPI CPU > dev.cpu.21.%driver: cpu > dev.cpu.21.%location: handle=\_PR_.CP22 > dev.cpu.21.%pnpinfo: _HID=none _UID=0 > dev.cpu.21.%parent: acpi0 > dev.cpu.21.cx_supported: C1/1 C2/41 > dev.cpu.21.cx_lowest: C1 > dev.cpu.21.cx_usage: 100.00% 0.00% last 114239us > dev.cpu.22.%desc: ACPI CPU > dev.cpu.22.%driver: cpu > dev.cpu.22.%location: handle=\_PR_.CP23 > dev.cpu.22.%pnpinfo: _HID=none _UID=0 > dev.cpu.22.%parent: acpi0 > dev.cpu.22.cx_supported: C1/1 C2/41 > dev.cpu.22.cx_lowest: C1 > dev.cpu.22.cx_usage: 100.00% 0.00% last 78379us > dev.cpu.23.%desc: ACPI CPU > dev.cpu.23.%driver: cpu > dev.cpu.23.%location: handle=\_PR_.CP24 > dev.cpu.23.%pnpinfo: _HID=none _UID=0 > dev.cpu.23.%parent: acpi0 > dev.cpu.23.cx_supported: C1/1 C2/41 > dev.cpu.23.cx_lowest: C1 > dev.cpu.23.cx_usage: 100.00% 0.00% last 80713us > dev.cpu.24.%desc: ACPI CPU > dev.cpu.24.%driver: cpu > dev.cpu.24.%location: handle=\_PR_.CP25 > dev.cpu.24.%pnpinfo: _HID=none _UID=0 > dev.cpu.24.%parent: acpi0 > dev.cpu.24.cx_supported: C1/1 C2/41 > dev.cpu.24.cx_lowest: C1 > dev.cpu.24.cx_usage: 100.00% 0.00% last 33025us > dev.cpu.25.%desc: ACPI CPU > dev.cpu.25.%driver: cpu > dev.cpu.25.%location: handle=\_PR_.CP26 > dev.cpu.25.%pnpinfo: _HID=none _UID=0 > dev.cpu.25.%parent: acpi0 > dev.cpu.25.cx_supported: C1/1 C2/41 > dev.cpu.25.cx_lowest: C1 > dev.cpu.25.cx_usage: 100.00% 0.00% last 100546us > dev.cpu.26.%desc: ACPI CPU > dev.cpu.26.%driver: cpu > dev.cpu.26.%location: handle=\_PR_.CP27 > dev.cpu.26.%pnpinfo: _HID=none _UID=0 > dev.cpu.26.%parent: acpi0 > dev.cpu.26.cx_supported: C1/1 C2/41 > dev.cpu.26.cx_lowest: C1 > dev.cpu.26.cx_usage: 100.00% 0.00% last 39748us > dev.cpu.27.%desc: ACPI CPU > dev.cpu.27.%driver: cpu > dev.cpu.27.%location: handle=\_PR_.CP28 > dev.cpu.27.%pnpinfo: _HID=none _UID=0 > dev.cpu.27.%parent: acpi0 > dev.cpu.27.cx_supported: C1/1 C2/41 > dev.cpu.27.cx_lowest: C1 > dev.cpu.27.cx_usage: 100.00% 0.00% last 83317us > dev.cpu.28.%desc: ACPI CPU > dev.cpu.28.%driver: cpu > dev.cpu.28.%location: handle=\_PR_.CP29 > dev.cpu.28.%pnpinfo: _HID=none _UID=0 > dev.cpu.28.%parent: acpi0 > dev.cpu.28.cx_supported: C1/1 C2/41 > dev.cpu.28.cx_lowest: C1 > dev.cpu.28.cx_usage: 100.00% 0.00% last 85644us > dev.cpu.29.%desc: ACPI CPU > dev.cpu.29.%driver: cpu > dev.cpu.29.%location: handle=\_PR_.CP30 > dev.cpu.29.%pnpinfo: _HID=none _UID=0 > dev.cpu.29.%parent: acpi0 > dev.cpu.29.cx_supported: C1/1 C2/41 > dev.cpu.29.cx_lowest: C1 > dev.cpu.29.cx_usage: 100.00% 0.00% last 98535us > dev.cpu.30.%desc: ACPI CPU > dev.cpu.30.%driver: cpu > dev.cpu.30.%location: handle=\_PR_.CP31 > dev.cpu.30.%pnpinfo: _HID=none _UID=0 > dev.cpu.30.%parent: acpi0 > dev.cpu.30.cx_supported: C1/1 C2/41 > dev.cpu.30.cx_lowest: C1 > dev.cpu.30.cx_usage: 100.00% 0.00% last 105936us > dev.cpu.31.%desc: ACPI CPU > dev.cpu.31.%driver: cpu > dev.cpu.31.%location: handle=\_PR_.CP32 > dev.cpu.31.%pnpinfo: _HID=none _UID=0 > dev.cpu.31.%parent: acpi0 > dev.cpu.31.cx_supported: C1/1 C2/41 > dev.cpu.31.cx_lowest: C1 > dev.cpu.31.cx_usage: 100.00% 0.00% last 85967us > > > > On Wed, Dec 4, 2013 at 11:05 AM, Adrian Chadd > wrote: > > Hi, > > What C states are you allowing the system to go into? > > sysctl dev.cpu > > > > -a > > > On 4 December 2013 08:09, Bret Ketchum > wrote: > > Dec 4 16:10:42 Aldagautr kernel: Whoops(0) 1335665250 - > 1335664940 = 310 > > (125039:208) > > Dec 4 16:10:42 Aldagautr kernel: 3532533380201277 - > 3532533110189730 = 100 > > Dec 4 16:10:46 Aldagautr kernel: Whoops(0) 1335669705 - > 1335669450 = 255 > > (125081:209) > > Dec 4 16:10:46 Aldagautr kernel: 3532544993171592 - > 3532544723156886 = 100 > > Dec 4 16:10:46 Aldagautr kernel: Ouch(0) 1335669805 - > 1335669705 = 100 > > (125081:210) > > Dec 4 16:10:46 Aldagautr kernel: 3532545106580358 - > 3532544993171592 = 42 > > Dec 4 16:10:51 Aldagautr kernel: Whoops(0) 1335674622 - > 1335674406 = 216 > > (125127:211) > > Dec 4 16:10:51 Aldagautr kernel: 3532557637551168 - > 3532557529541286 = 40 > > Dec 4 16:10:51 Aldagautr kernel: Ouch(0) 1335674722 - > 1335674622 = 100 > > (125127:212) > > Dec 4 16:10:51 Aldagautr kernel: 3532557856241106 - > 3532557637551168 = 80 > > Dec 4 16:10:51 Aldagautr kernel: Whoops(0) 1335675136 - > 1335675023 = 113 > > (125130:213) > > Dec 4 16:10:51 Aldagautr kernel: 3532558941667944 - > 3532558671656559 = 100 > > Dec 4 16:11:02 Aldagautr kernel: Whoops(0) 1335685785 - > 1335685544 = 241 > > (125234:214) > > Dec 4 16:11:02 Aldagautr kernel: 3532587178907223 - > 3532587033073221 = 54 > > > > Not that with kern.eventtimer.periodic set to 1 the > problem goes away. > > > > > > On Wed, Dec 4, 2013 at 9:02 AM, Alexander Motin > > wrote: > >> > >> On 04.12.2013 14:49, Bret Ketchum wrote: > >>> > >>> See attached. I've tightened up the definition of > inconsistent > >>> callout calls. A "Whoops" message indicates the callout > function was > >>> called either side of a 10ms window than what was expected. > "Ouch" > >>> indicates the cyclecounter does not agree with the expected > period given > >>> the same 10ms fudge factor. > >> > >> > >> I have this module running on two of my tests systems with > stable/9 > >> (2xE5645 and i7-3770) and half hour later I see no any of > related messages > >> on consoles. Could you share what exactly do you have there > logged? > >> > >>> On Wed, Nov 27, 2013 at 3:28 AM, Bret Ketchum > > >>> >> > wrote: > >>> > >>> Alexander, > >>> > >>> In this scenario, global ticks should have > increased by 100 > >>> every interval. When the wheels go off the truck, > global ticks will > >>> be 800+ yet only a fraction of usual number of clock > cycles have > >>> increased. > >>> > >>> I'll try to cook up an kernel module which will > reproduce. > >>> > >>> > >>> On Wed, Nov 27, 2013 at 1:42 AM, Alexander Motin > > >>> >> wrote: > >>> > >>> Hi, Brett, > >>> > >>> Could you tell more about "ticks has increased 8x"? > Tickless > >>> mode it is somewhat tricky algorithm to track > global ticks > >>> counter, but it should not jump that big. Jumps > there could > >>> easily trigger wrong callout behavior in 9 (in 10 > callout code > >>> was rewritten and no longer depend on ticks). > >>> > >>> > >>> On 21.11.2013 22:19, Adrian Chadd wrote: > >>> > >>> It sounds like you may have found an > interesting test case. > >>> > >>> Mav, any ideas? > >>> > >>> On 21 November 2013 05:20, Bret Ketchum > > >>> >> wrote: > >>> > >>> I've a callout which runs every > 100ms and does a > >>> bit of accounting > >>> using the global ticks variable. This > one-shot callout > >>> was called fairly > >>> consistently in 8.1, every 100ms give or > take a few > >>> thousand clocks. I've > >>> recently upgraded to 9.1 and for the most > part the > >>> period is consistent. > >>> However, periodically the callout function > is executed > >>> anywhere between 5ms > >>> to 20ms after the callout was reset and the > function > >>> returned while global > >>> ticks has increased 8x. The hardware has > not changed > >>> (using the same > >>> timecounter configuration): > >>> > >>> CPU: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz > >>> (2500.05-MHz K8-class CPU) > >>> > >>> kern.timecounter.hardware: TSC-low > >>> kern.timecounter.tick: 1 > >>> kern.timecounter.invariant___tsc: 1 > >>> > >>> kern.timecounter.smp_tsc: 1 > >>> > >>> And default eventtimer configuration: > >>> > >>> kern.eventtimer.singlemul: 2 > >>> kern.eventtimer.idletick: 0 > >>> kern.eventtimer.activetick: 1 > >>> kern.eventtimer.timer: LAPIC > >>> kern.eventtimer.periodic: 0 > >>> > >>> If tickless mode is disabled the > inconsistency > >>> goes away. Is the > >>> premature expiration of the callout > expected? Is the > >>> jump in global ticks > >>> typical (say from 100 ticks to 800 ticks in > 1.5ms)? > >>> > >>> Bret > >>> > _________________________________________________ > >>> freebsd-hackers@freebsd.org > > >>> > mailing list > >>> > >>> http://lists.freebsd.org/__mailman/listinfo/freebsd-__hackers > >>> > >>> > >>> > >>> To unsubscribe, send any mail to > >>> "freebsd-hackers-unsubscribe@__freebsd.org > > >>> > >" > >>> > >>> > >>> > >>> -- > >>> Alexander Motin > >>> > >>> > >>> > >> > >> > >> -- > >> Alexander Motin > > > > > > > -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 6 18:35:29 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DEE99754; Fri, 6 Dec 2013 18:35:29 +0000 (UTC) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 86FBE159E; Fri, 6 Dec 2013 18:35:29 +0000 (UTC) Received: by mail-qc0-f175.google.com with SMTP id e9so745890qcy.6 for ; Fri, 06 Dec 2013 10:35:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=TJvBax8iL6o/4N8SATx3zxkHcfSMsIhE6uQphU2qNMA=; b=n3JV90fwTY5/j4fhZxkGEMFaCMfL+te4LXZ1nUPDcBIi8ogcB21FnkE5Qym1G4FJz+ 1bMJIqyhYCZgFmZ2LEIrsjvQY3kEI6SncWSFWyjNuZe93oCqCjbEcdYYDkG8OAZPDSs4 u58ZZbWzV6jia4VqfghJCHP3qXExKzxSC6CQMzK/MZ6cyZ6/Xpjq7NF41vUXVQil/cqm RGkEtUPyKrqVYe2TFldrSHF+5vQZ+q2qwFyHKxgfPP7vdfdKdacdCmHvkSsFM0ZkGid2 SUI6bEpdKTJDrLvEodQJLPKuujC1ZtuI3Yvu8HnrM4nl5G3crX5NP8EKKQDuYs37fUhT SDxQ== MIME-Version: 1.0 X-Received: by 10.49.17.232 with SMTP id r8mr8989365qed.74.1386354928630; Fri, 06 Dec 2013 10:35:28 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Fri, 6 Dec 2013 10:35:28 -0800 (PST) In-Reply-To: <52A1B869.6080407@FreeBSD.org> References: <5295A261.2060403@FreeBSD.org> <529F4409.9080403@FreeBSD.org> <52A1B869.6080407@FreeBSD.org> Date: Fri, 6 Dec 2013 10:35:28 -0800 X-Google-Sender-Auth: FY5f1NUubjwT6t0bPU2yVvFwQgs Message-ID: Subject: Re: 9.1 callout behavior From: Adrian Chadd To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: Bret Ketchum , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 18:35:29 -0000 On 6 December 2013 03:43, Alexander Motin wrote: > On 06.12.2013 13:41, Bret Ketchum wrote: >> >> Any luck in recreating? > > > Nope. I've tried with and without deep C-states enabled and still no any > error messages on console. Are you trying it with the exact same hardware? For both of you - is HT on/off? -a From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 6 18:43:58 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1CC8AF9; Fri, 6 Dec 2013 18:43:58 +0000 (UTC) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5A6621631; Fri, 6 Dec 2013 18:43:58 +0000 (UTC) Received: by mail-ea0-f176.google.com with SMTP id h14so470839eaj.35 for ; Fri, 06 Dec 2013 10:43:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=qgFTjWW5VOeItjHuenkPxL1I9BalwkJmqtM6oaqfykY=; b=Uqc55vZjNEYNpv+H4AekGUdlfZ7w4KiILA6kZIyajuvN0Cm+XJR6xkhit/UBvgGMyd KZDhBFoZGsVr9+w5Z0LpFOKQb0XnWWYPe0m1PytcRza/2whaFbGKIxxXmojFQrq+HA4M Qtwy1i4lbwa15CRkwsQABzOvyvkJJPM3klvtZ9XptaS4TYUDv7K5EAVmRkfslJEtTrhi HDCYI1Qw1PF58d7tsvHsCY4LSntXrtQ6/1L5eUi0cDgboWcrsRJocMCyHRmmY5HtbZxH s+blOqSBFxtBK/q9/++oRZjsTgJALxux0L2vHo+dhwBB5/uO5U2TxTF2C5Yxrlsm+wXG eLJg== X-Received: by 10.14.119.1 with SMTP id m1mr3714891eeh.39.1386355436775; Fri, 06 Dec 2013 10:43:56 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([178.137.150.35]) by mx.google.com with ESMTPSA id e43sm109214826eep.7.2013.12.06.10.43.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Dec 2013 10:43:55 -0800 (PST) Sender: Alexander Motin Message-ID: <52A21AE9.5020803@FreeBSD.org> Date: Fri, 06 Dec 2013 20:43:53 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: 9.1 callout behavior References: <5295A261.2060403@FreeBSD.org> <529F4409.9080403@FreeBSD.org> <52A1B869.6080407@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bret Ketchum , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 18:43:59 -0000 On 06.12.2013 20:35, Adrian Chadd wrote: > On 6 December 2013 03:43, Alexander Motin wrote: >> On 06.12.2013 13:41, Bret Ketchum wrote: >>> >>> Any luck in recreating? >> >> >> Nope. I've tried with and without deep C-states enabled and still no any >> error messages on console. > > Are you trying it with the exact same hardware? No. We found that while both of my test machines active now has C-state invariant LAPIC, at least one of Bret's is not. But that doesn't really explain much because C-states there are not visually enabled either by OS, or via C1E by BIOS. > For both of you - is HT on/off? Both if my systems have HTT active. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 6 18:55:51 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F7F7F93; Fri, 6 Dec 2013 18:55:51 +0000 (UTC) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BA6AD16DD; Fri, 6 Dec 2013 18:55:50 +0000 (UTC) Received: by mail-qc0-f178.google.com with SMTP id i17so777339qcy.23 for ; Fri, 06 Dec 2013 10:55:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3l1C87u0WdF21g9WeADKSTbDtyluhKpc8GKVscBx2YI=; b=JW4H99UN2yZT5ZzMa6FunRgm378rEq8w3rID3fz0r0Prcr0k2f3BoC8LrBfqOAkMdp 21vU5fyNXQZQHz/UPEoi552nWVRpCrYVlsLESdyP9AjvB/isB1XF/j6Xz9xt7OM8c7nw FeJr1Ent/H5NCUbXqUvYJYVU/H2K2XI8YXmaSVQgqdMjxhrP8lAg73etApf8zstvLZng MxiC91JU4jV3158mFKucLqd8l/ZGTkKzLMT+7RinLc9N+NyEGdWA8tCG5Pn2iAAKOtXk 3PS+BPIKDHMSFw3pAUpT6ETMwE3XbaqRq4ze9U7dNc8MmvDMLgpYnL5UcXYn4QQ0e7fh HPZA== MIME-Version: 1.0 X-Received: by 10.49.129.38 with SMTP id nt6mr1192469qeb.78.1386356149910; Fri, 06 Dec 2013 10:55:49 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Fri, 6 Dec 2013 10:55:49 -0800 (PST) In-Reply-To: <52A21AE9.5020803@FreeBSD.org> References: <5295A261.2060403@FreeBSD.org> <529F4409.9080403@FreeBSD.org> <52A1B869.6080407@FreeBSD.org> <52A21AE9.5020803@FreeBSD.org> Date: Fri, 6 Dec 2013 10:55:49 -0800 X-Google-Sender-Auth: HFSkbB2_wwk3pvm91O6pYWsP7gE Message-ID: Subject: Re: 9.1 callout behavior From: Adrian Chadd To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: Bret Ketchum , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 18:55:51 -0000 Remember that I have such similar stupid behaviour with my three year old Atom laptop. I promise I'll bring it along to the next freebsd event you're at. :P -adrian On 6 December 2013 10:43, Alexander Motin wrote: > On 06.12.2013 20:35, Adrian Chadd wrote: >> >> On 6 December 2013 03:43, Alexander Motin wrote: >>> >>> On 06.12.2013 13:41, Bret Ketchum wrote: >>>> >>>> >>>> Any luck in recreating? >>> >>> >>> >>> Nope. I've tried with and without deep C-states enabled and still no any >>> error messages on console. >> >> >> Are you trying it with the exact same hardware? > > > No. We found that while both of my test machines active now has C-state > invariant LAPIC, at least one of Bret's is not. But that doesn't really > explain much because C-states there are not visually enabled either by OS, > or via C1E by BIOS. > > >> For both of you - is HT on/off? > > > Both if my systems have HTT active. > > -- > Alexander Motin