From owner-freebsd-current@FreeBSD.ORG Sat Jan 28 22:40:57 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B004106566C; Sat, 28 Jan 2012 22:40:57 +0000 (UTC) (envelope-from flo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 631718FC0A; Sat, 28 Jan 2012 22:40:57 +0000 (UTC) Received: from nibbler-wlan.fritz.box (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0SMesYw014466; Sat, 28 Jan 2012 22:40:55 GMT (envelope-from flo@FreeBSD.org) Message-ID: <4F247975.9050208@FreeBSD.org> Date: Sat, 28 Jan 2012 23:40:53 +0100 From: Florian Smeets User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0) Gecko/20120124 Thunderbird/10.0 MIME-Version: 1.0 To: performance@FreeBSD.org X-Enigmail-Version: 1.4a1pre Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig68C92A85B2E237E1C5E2AFBB" X-Mailman-Approved-At: Sun, 29 Jan 2012 00:13:23 +0000 Cc: Subject: ULE vs. 4BSD scheduler benchmarks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 22:40:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig68C92A85B2E237E1C5E2AFBB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable [current@ bcc'ed to get a wider audience, please discuss on performance@]= Hi, in recent times i saw a lot of threads where it was suggested people should switch from the ULE to the 4BSD scheduler. That got me thinking and i decided to run a few benchmarks. I looked through all the stuff Kris and Jeff did a few years ago and tried to follow their example. The main motivation is however that we (Attilio Rao and I) want to set a baseline for future reference, mainly for the work that's going on in the vmcontention branch right now, that is the reason why all tests were run on head@r229659. All debugging was disabled (WITNESS and friends for the kernel and MALLOC_PRODUCTION=3Dyes for libc). For now i ran 3 different things. MySQL/sysbench, PostgreSQL/pgbench and pbzip2. All software was installed from ports with the default system gcc (gcc version 4.2.1 20070831 patched [FreeBSD]), with the exception of PostgreSQL. I created new postgres92-{server,client} ports with a snapshot of PostgreSQL 9.2dev from 16.01.2012, as a lot of scalability work was done in PostgreSQL 9.2. MySQL version 5.5.20 sysbench version 0.4.12 PostgreSQL/pgbench version 9.2dev PBZIP2 version v1.1.6 The machine these test were run on is a 2x4 core Xeon L5310 @ 1.60GHz with 4GB RAM. Here is the complete topology: kern.sched.topology_spec: 0, 1, 2, 3, 4, 5, 6, 7 0, 1, 2, 3 4, 5, 6, 7 The database benchmarks were all run with a work set that fit into the configured database memory, so after the warmup phase no disk io was involved. sysbench was run with 1 million rows, innodb was the engine we used as Kris work already showed that it scales much better than myisam (also innodb is the default in MySQL's 5.5 branch). Pgbench was run using a scaling factor of 100. The connection to the databases was using a unix socket, also only read only tests were run. The input and output files for the pbzip2 test were on tmpfs. The results are available in this Google docs spreadsheet, if you scroll down there are also some nice graphs. https://docs.google.com/spreadsheet/ccc?key=3D0Ai0N1xDe3uNAdDRxcVFiYjNMSn= JWOTZhUWVWWlBlemc Over time i will add more benchmarks to the doc (i.e nginx/php-fpm and so on). I tried to run some nginx benchmarks, but those are limited by netisr, as i did not find a web server benchmark tool which can use unix sockets, any suggestions welcome. The conclusion right now seems to be that ULE is faster for database workload, but for strongly CPU-bound workloads 4BSD can be a better choice. I can provide KTR traces and/or schedgraph output for cases where 4BSD is better than ULE. I want to thank Sean Bruno and Yahoo for setting up / providing the machines to run these test on, and Attilio for suggestions and his general helpfulness. Florian --------------enig68C92A85B2E237E1C5E2AFBB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAk8keXYACgkQapo8P8lCvwkTIACgg1+ajRlZiWwfc5CVdEDIakk6 BfEAoInUvD5/UI1RWQ2Lg9OYsZLma4O6 =dhNX -----END PGP SIGNATURE----- --------------enig68C92A85B2E237E1C5E2AFBB-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 28 22:47:57 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DE8C106564A for ; Sat, 28 Jan 2012 22:47:57 +0000 (UTC) (envelope-from danielsh@apache.org) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1.freebsd.org (Postfix) with SMTP id 686238FC19 for ; Sat, 28 Jan 2012 22:47:57 +0000 (UTC) Received: (qmail 70019 invoked by uid 99); 28 Jan 2012 22:47:56 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 28 Jan 2012 22:47:56 +0000 Received: from localhost (HELO daniel3.local) (127.0.0.1) (smtp-auth username danielsh, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Sat, 28 Jan 2012 22:47:56 +0000 Date: Sun, 29 Jan 2012 00:47:40 +0200 From: Daniel Shahaf To: "Bjoern A. Zeeb" Message-ID: <20120128224740.GA1729@daniel3.local> References: <4F22D9FD.10502@p6m7g8.com> <20120128081919.GA6699@lp-shahaf.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Sun, 29 Jan 2012 00:13:39 +0000 Cc: Scott Sanders , Matt Mullins , "Philip M. Gollucci" , current@freebsd.org Subject: Re: jid and jname are numberic by default why? Can we change it ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 22:47:57 -0000 Bjoern A. Zeeb wrote on Sat, Jan 28, 2012 at 21:06:59 +0000: > > On 28. Jan 2012, at 08:19 , Daniel Shafaf wrote: > > > Matt Mullins wrote on Fri, Jan 27, 2012 at 12:06:48 -0800: > >> On Fri, Jan 27, 2012 at 9:08 AM, Philip M. Gollucci wrote: > >>> All, > >>> > >>> $ jls -nq | tail -1 | xargs -n1 | egrep '^(name|jid)='| xargs > >>> jid=17 name=17 > >>> > >>> # jubilee/chef > >>> jail_jubilee_hostname="jubilee.dca1.rws" > >>> jail_jubilee_ip="192.168.2.41" > >>> jail_jubilee_ip_multi0="192.168.2.42" > >>> jail_jubilee_interface="bge1" > >>> jail_jubilee_rootdir="/jubilee" > >>> jail_jubilee_devfs_enable="YES" > >> > >> The default flags that /etc/rc.d/jail passes to jail(8) are "-l -U > >> root". Failing to give jail(8) a name results in name==jid, as you > >> found above. > >> > >> You can make the rc script name the jail by setting: > >> jail_jubilee_flags="-n jubilee -l -U root" > >> > > > > Good point. Would it make sense to have rc.d/jail behave this way by > > default? > > > > % diff -u /etc/rc.d/jail jail > > --- /etc/rc.d/jail 2012-01-21 18:22:26.000000000 +0200 > > +++ jail 2012-01-28 10:13:03.000000000 +0200 > > @@ -112,7 +112,7 @@ > > eval _fstab=\"\${jail_${_j}_fstab:-${jail_fstab}}\" > > [ -z "${_fstab}" ] && _fstab="/etc/fstab.${_j}" > > eval _flags=\"\${jail_${_j}_flags:-${jail_flags}}\" > > - [ -z "${_flags}" ] && _flags="-l -U root" > > + [ -z "${_flags}" ] && _flags="-n ${_j} -l -U root" > > eval _consolelog=\"\${jail_${_j}_consolelog:-${jail_consolelog}}\" > > [ -z "${_consolelog}" ] && _consolelog="/var/log/jail_${_j}_console.log" > > eval _fib=\"\${jail_${_j}_fib:-${jail_fib}}\" > > > > No. rc.d/jail shall not be extended anymore; please see the framework Jamie posted > on freebsd-jail last year and test/review/report back there. > > See http://lists.freebsd.org/pipermail/freebsd-jail/2011-July/thread.html#1568 > It appears that the problem is already solved in that framework: a jail.conf(5) block defining a jail is required to be preceded by a jailname{}, which is documented to set the jail(8)'s name. In other words, it won't be possible to define in jail.conf(5) a jail that will end up nameless (and thus implicitly named as its jid). Thanks for the pointer, Daniel [1] http://svn.freebsd.org/base/projects/jailconf/usr.sbin/jail/jail.conf.5 P.S. As an aside, the provision in projects/jailconf/'s jail(8) that it's not possible for 'jail -r' to remove all jails _unless_ the '*' syntax is used seems unusual to me: I expect 'jail -r foo bar' to remove those two jails regardless of whether any other jails exist. (Sorry if this has been discussed already -- it's just an issue I ran across while examining the jail(8) man page in Jamie's framework.) > You get a config file etc and get rid of all the shell "magic" and "nightmare". > > /bz > > > >> Notice the rc script uses the second form of syntax listed in jail(8), > >> at least on 9.0-RELEASE. > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > -- > Bjoern A. Zeeb You have to have visions! > It does not matter how good you are. It matters what good you do! > From owner-freebsd-current@FreeBSD.ORG Sun Jan 29 01:06:31 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 20852106564A; Sun, 29 Jan 2012 01:06:31 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-150-251.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 205C114FCD1; Sun, 29 Jan 2012 01:06:29 +0000 (UTC) Message-ID: <4F249B95.9080808@FreeBSD.org> Date: Sat, 28 Jan 2012 17:06:29 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120119 Thunderbird/9.0 MIME-Version: 1.0 To: Andriy Gapon References: <4E23EE49.5040801@FreeBSD.org> <201201031714.40777.jhb@freebsd.org> <4F0401D3.9040903@FreeBSD.org> <201201271321.39632.jhb@freebsd.org> <4F23BC2B.8070801@FreeBSD.org> <4F23BE29.7040102@FreeBSD.org> <4F23C1DE.2010700@FreeBSD.org> <4F23C2BE.7080600@FreeBSD.org> In-Reply-To: <4F23C2BE.7080600@FreeBSD.org> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigE8BABC3CE012797212DF4653" Cc: freebsd-current@FreeBSD.org, John Baldwin Subject: Re: ichwd0: unable to reserve GCS registers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 01:06:31 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE8BABC3CE012797212DF4653 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 01/28/2012 01:41, Andriy Gapon wrote: > on 28/01/2012 11:37 Doug Barton said the following: >> On 01/28/2012 01:21, Andriy Gapon wrote: >>> on 28/01/2012 11:13 Doug Barton said the following: >>>> On 01/27/2012 10:21, John Baldwin wrote: >>>>> Does it operate fully with NEW_PCIB disabled entirely, or do you ge= t this >>>>> same message in that case? >>>> >>>> I put nooptions NEW_PCIB in my kernel config, and got basically the = same: >>>> >>>> isab0: found ICH10 or equivalent chipset: Intel ICH10DO watchdog tim= er >>>> ichwd0: on isa0 >>>> isab0: found ICH10 or equivalent chipset: Intel ICH10DO watchdog tim= er >>>> ichwd0: ICH WDT present but disabled in BIOS or hardware >>>> device_attach: ichwd0 attach returned 6 >>> >>> The next logical question is has ichwd ever worked on this system? W= ith any >>> version of FreeBSD.=20 >> >> I have a vague recollection that it did, but I just tried 8.1-RELEASE = on >> the same system and got the same message about it being disabled. >=20 > Then I'd guess that it has never actually worked (with FreeBSD). It's possible, sure. What I find interesting is that the message I'm seeing on -current is different after John's recent commit. OTOH I'm now seeing the same message on 8 as I am on -current, so you're probably righ= t. >> OTOH, >> on my laptop I know that it used to work, and then it didn't. >=20 > But that's a different system and, as such, a different problem? > Have you fixed it or debugged it in a similar fashion to this !laptop s= ystem? I did in the past, yes. But I haven't had a chance to do that since John's latest commit. I'll do that when I can. Doug --=20 It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ --------------enigE8BABC3CE012797212DF4653 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJPJJuVAAoJEFzGhvEaGryEimMH/2jWDgy+PovHyl2khFJtd8xo UNqlCkLIdhgtHdLP7ICzFOYpQrWF7QG40JrswHlzPFtOYFAE/aD6wJfx46MByWVH iQ/jrFs9TYVMzgsIwXA0e3a5jqd3ITiArViIg1lb8pNIyaY3T53zp59RIgSKHYWW Z1QIW+myL3UnbKuZRbwsil52R5ctCo2Ghdo+vPJj+4SBBvI/lp1KSI5aDQXlVhE+ OVQnLnJ74M8Z3wuvwe5i3sz885DILFp131qtSGuc4u7jsEk9iBP+EpGaFcn1vgnu XPYhgxoe+/KmTp1WePnniP+3xbg3eyAPxPdYXpErZASTbBHjmKAFVP4folIU8zs= =be6W -----END PGP SIGNATURE----- --------------enigE8BABC3CE012797212DF4653-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 29 07:50:52 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88776106564A for ; Sun, 29 Jan 2012 07:50:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 1A4DD8FC08 for ; Sun, 29 Jan 2012 07:50:51 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q0T7mie3002942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Jan 2012 09:48:44 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q0T7mhcM085676; Sun, 29 Jan 2012 09:48:43 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q0T7mhNl085675; Sun, 29 Jan 2012 09:48:43 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 29 Jan 2012 09:48:43 +0200 From: Kostik Belousov To: Dmitry Mikulin Message-ID: <20120129074843.GL2726@deviant.kiev.zoral.com.ua> References: <749E238A-A85F-4264-9DEB-BCE1BBD21C9D@juniper.net> <20120125074824.GD2726@deviant.kiev.zoral.com.ua> <4F2094B4.70707@juniper.net> <20120126122326.GT2726@deviant.kiev.zoral.com.ua> <4F22E8FD.6010201@juniper.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YiQKDdln2jY//0TJ" Content-Disposition: inline In-Reply-To: <4F22E8FD.6010201@juniper.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current Current , Marcel Moolenaar Subject: Re: [ptrace] please review follow fork/exec changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 07:50:52 -0000 --YiQKDdln2jY//0TJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 27, 2012 at 10:12:13AM -0800, Dmitry Mikulin wrote: > Attached are 4 separate patches for each somewhat independent portion of= =20 > the kernel work related to the follow-fork implementation. Ok, as I said, I think that vfork-fork.patch is just wrong. Lets postpone discussion of the orphan.patch for later. The follow-fork.patch and follow-exec.patch make me wonder, and I already expressed my doubts. IMO, all features, except one bug, are already presented in the stock src. More, suggested follow-{fork,exec} patches break the SCE/SCX tracers notification of fork and exec events, since TDB_FORK and TBD_EXEC flags are consumed before syscall returns (I also said this previously). Namely, if the process is being debugged, the successfull [f]execve() causes unconditional stop even. This makes PT_FOLLOW_EXEC unneccessary. Existing PT_FOLLOW_FORK implementation indeed has a bug, which was not revealed by my testing during the development, because I only tested SCE/SCX scenario. Namely, if PT_FOLLOW_FORK is requested, but the next stop is not SCX, then follow-fork notification is not sent. After this nit is fixed, PT_FOLLOW_FORK caller gets stops for the child creation. Child is put into stop state as needed to not loose it. I updated the test program I use to test this functionality, see http://people.freebsd.org/~kib/misc/scescx.c The default or -s flag causes it to use SCE/SCX tracing, while -c flag switches it to use PT_CONTINUE tracing, which should be the kind of loop performed by normal debuggers. You can see the exec/fork events and child auto-attach illustrated with this test. Can you, please, provide the test-case which illustrates the omissions in the existing API (with the patch below applied), if any ? diff --git a/sys/kern/subr_syscall.c b/sys/kern/subr_syscall.c index bba4479..75328f6 100644 --- a/sys/kern/subr_syscall.c +++ b/sys/kern/subr_syscall.c @@ -212,7 +212,8 @@ syscallret(struct thread *td, int error, struct syscall= _args *sa __unused) * executes. If debugger requested tracing of syscall * returns, do it now too. */ - if (traced && ((td->td_dbgflags & TDB_EXEC) !=3D 0 || + if (traced && + ((td->td_dbgflags & (TDB_FORK | TDB_EXEC)) !=3D 0 || (p->p_stops & S_PT_SCX) !=3D 0)) ptracestop(td, SIGTRAP); td->td_dbgflags &=3D ~(TDB_SCX | TDB_EXEC | TDB_FORK); --YiQKDdln2jY//0TJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk8k+dsACgkQC3+MBN1Mb4iRwQCeJKKjGvUpb9zx7gCfTJlB6nHX +PAAnjnEqI1R//4d60AZqhopRRNUBlkP =VY94 -----END PGP SIGNATURE----- --YiQKDdln2jY//0TJ-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 29 15:08:22 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEAB2106566B; Sun, 29 Jan 2012 15:08:22 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay011.isp.belgacom.be (mailrelay011.isp.belgacom.be [195.238.6.178]) by mx1.freebsd.org (Postfix) with ESMTP id 21F3E8FC0C; Sun, 29 Jan 2012 15:08:21 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMpfJU9bsYWl/2dsb2JhbABErCWCMYEGgXIBAQVWIxALGC45HhCICLdTiD0BKAMECwEIAQUJBgMKgw8NKG0EDwIBBiODHASeRokm Received: from 165.133-177-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.177.133.165]) by relay.skynet.be with ESMTP; 29 Jan 2012 16:08:19 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.5/8.14.5) with ESMTP id q0TF8J8n001396; Sun, 29 Jan 2012 16:08:19 +0100 (CET) (envelope-from tijl@coosemans.org) From: Tijl Coosemans To: freebsd-current@freebsd.org Date: Sun, 29 Jan 2012 16:08:10 +0100 User-Agent: KMail/1.13.7 (FreeBSD/10.0-CURRENT; KDE/4.7.3; i386; ; ) References: <201201191739.48327.tijl@coosemans.org> <201201201412.13269.jhb@freebsd.org> <201201251129.22368.jhb@freebsd.org> In-Reply-To: <201201251129.22368.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4901043.djbVi398T5"; protocol="application/pgp-signature"; micalg=pgp-sha256 Content-Transfer-Encoding: 7bit Message-Id: <201201291608.16741.tijl@coosemans.org> Cc: Subject: Re: posix_fadvise noreuse disables file caching X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 15:08:23 -0000 --nextPart4901043.djbVi398T5 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable On Wednesday 25 January 2012 17:29:22 John Baldwin wrote: > On Friday, January 20, 2012 2:12:13 pm John Baldwin wrote: >> On Thursday, January 19, 2012 11:39:42 am Tijl Coosemans wrote: >>> I recently noticed that multimedia/vlc generates a lot of disk IO when >>> playing media files. For instance, when playing a 320kbps mp3 gstat >>> reports about 1250kBps (=3D10000kbps). That's quite a lot of overhead. >>>=20 >>> It turns out that vlc sets POSIX_FADV_NOREUSE on the entire file and >>> reads in chunks of 1028 bytes. FreeBSD implements NOREUSE as if >>> O_DIRECT was specified during open(2), i.e. it disables all caching. >>> That means every 1028 byte read turns into a 32KiB read (new default >>> block size in 9.0) which explains the above numbers. >>>=20 >>> I've copied the relevant vlc code below (modules/access/file.c:Open()). >>> It's interesting to see that on OSX it sets F_NOCACHE which disables >>> caching too, but combined with F_RDAHEAD there's still read-ahead >>> caching. >>>=20 >>> I don't think POSIX intended for NOREUSE to mean O_DIRECT. It should >>> still cache data (and even do read-ahead if F_RDAHEAD is specified), >>> and once data is fetched from the cache, it can be marked WONTNEED. >>=20 >> POSIX doesn't specify O_DIRECT, so it's not clear what it asks for. >>=20 >>> Is it possible to implement it this way, or if not to just ignore >>> the NOREUSE hint for now? >>=20 >> I think it would be good to improve NOREUSE, though I had sort of >> assumed that applications using NOREUSE would do their own buffering >> and read full blocks. We could perhaps reimplement NOREUSE by doing >> the equivalent of POSIX_FADV_DONTNEED after each read to free buffers >> and pages after the data is copied out to userland. I also have an >> XXX about whether or not NOREUSE should still allow read-ahead as it >> isn't very clear what the right thing to do there is. HP-UX (IIRC) >> has an fadvise() that lets you specify multiple policies, so you >> could specify both NOREUSE and SEQUENTIAL for a single region to >> get read-ahead but still release memory once the data is read once. > > So I've came up with this untested patch. It uses > VOP_ADVISE(FADV_DONTNEED) after read(2) calls to a NOREUSE region, and > leaves read-ahead caching enabled for NOREUSE. FADV_DONTNEED doesn't > do any good really for writes (it only flushes clean buffers), so I've > left write(2) operations as using IO_DIRECT still. Does this sound > reasonable? I've not yet tested this at all: The patch drastically improves vlc, but there's still a tiny overhead. Without NOREUSE the disk is read in chunks of 128KiB (F_RDAHEAD buffer size). With NOREUSE there's an extra transfer of 32KiB (block size). --nextPart4901043.djbVi398T5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iF4EABEIAAYFAk8lYOAACgkQfoCS2CCgtivk2AD/RqvjPc4BSLqq/BzerszDDolM cwQBJoh2eMsxfpiJroMA/2pRubGDhtqL3nG7zIYfgm/2fcH2LYFm7W9ZrUCLxTgD =VmXF -----END PGP SIGNATURE----- --nextPart4901043.djbVi398T5-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 29 21:07:46 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CD50106564A for ; Sun, 29 Jan 2012 21:07:46 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7EA8E8FC13 for ; Sun, 29 Jan 2012 21:07:45 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA06192 for ; Sun, 29 Jan 2012 23:07:43 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RrbyR-000KEQ-El for freebsd-current@freebsd.org; Sun, 29 Jan 2012 23:07:43 +0200 Message-ID: <4F25B51D.4090207@FreeBSD.org> Date: Sun, 29 Jan 2012 23:07:41 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: FreeBSD current X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: Subject: stray symbol in hd's output? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 21:07:46 -0000 Does the following look familiar to anybody (note the stray 'n')? $ dd if=/dev/zero bs=1 count=1 | hd 1+0 records in 1+0 records out 1 bytes transferred in 0.000043 secs (23302 bytes/sec) 00000000 00 |.| n00000001 -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Jan 29 21:36:52 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D036106564A; Sun, 29 Jan 2012 21:36:52 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 352CB8FC19; Sun, 29 Jan 2012 21:36:51 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id A954A1DDAA4; Sun, 29 Jan 2012 22:36:48 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 900B428468; Sun, 29 Jan 2012 22:36:48 +0100 (CET) Date: Sun, 29 Jan 2012 22:36:48 +0100 From: Jilles Tjoelker To: Andriy Gapon Message-ID: <20120129213648.GB97754@stack.nl> References: <4F25B51D.4090207@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F25B51D.4090207@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD current Subject: Re: stray symbol in hd's output? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 21:36:52 -0000 On Sun, Jan 29, 2012 at 11:07:41PM +0200, Andriy Gapon wrote: > Does the following look familiar to anybody (note the stray 'n')? > $ dd if=/dev/zero bs=1 count=1 | hd > 1+0 records in > 1+0 records out > 1 bytes transferred in 0.000043 secs (23302 bytes/sec) > 00000000 00 |.| > n00000001 Yes, this was broken by r229794 (Jan 7) and repaired again by r230649 (yesterday). http://www.freebsd.org/cgi/query-pr.cgi?pr=144722 -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Sun Jan 29 21:38:04 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3CF11065678 for ; Sun, 29 Jan 2012 21:38:03 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 48E0D8FC1B for ; Sun, 29 Jan 2012 21:38:02 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA06418; Sun, 29 Jan 2012 23:38:00 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RrcRk-000KFW-IU; Sun, 29 Jan 2012 23:38:00 +0200 Message-ID: <4F25BC37.6020303@FreeBSD.org> Date: Sun, 29 Jan 2012 23:37:59 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Jilles Tjoelker References: <4F25B51D.4090207@FreeBSD.org> <20120129213648.GB97754@stack.nl> In-Reply-To: <20120129213648.GB97754@stack.nl> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD current Subject: Re: stray symbol in hd's output? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 21:38:04 -0000 on 29/01/2012 23:36 Jilles Tjoelker said the following: > On Sun, Jan 29, 2012 at 11:07:41PM +0200, Andriy Gapon wrote: >> Does the following look familiar to anybody (note the stray 'n')? > >> $ dd if=/dev/zero bs=1 count=1 | hd >> 1+0 records in >> 1+0 records out >> 1 bytes transferred in 0.000043 secs (23302 bytes/sec) >> 00000000 00 |.| >> n00000001 > > Yes, this was broken by r229794 (Jan 7) and repaired again by r230649 > (yesterday). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=144722 Ah, thank you! For both the information and the fix. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Jan 29 23:06:11 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4EB41065672; Sun, 29 Jan 2012 23:06:11 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 7F3D08FC13; Sun, 29 Jan 2012 23:06:11 +0000 (UTC) Received: from [89.204.130.20] (helo=tiny.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Rrc7c-0004vI-6N; Sun, 29 Jan 2012 22:17:12 +0100 Received: from tiny.Sisis.de (localhost [127.0.0.1]) by tiny.Sisis.de (8.14.5/8.14.3) with ESMTP id q0TLHgn8001426; Sun, 29 Jan 2012 22:17:43 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de (8.14.5/8.14.3/Submit) id q0TLHg6X001425; Sun, 29 Jan 2012 22:17:42 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Sun, 29 Jan 2012 22:17:41 +0100 From: Matthias Apitz To: Andriy Gapon Message-ID: <20120129211741.GA1384@tiny> References: <4F25B51D.4090207@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4F25B51D.4090207@FreeBSD.org> X-Operating-System: FreeBSD 10.0-CURRENT r226986 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.130.20 Cc: FreeBSD current Subject: Re: stray symbol in hd's output? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 23:06:11 -0000 El día Sunday, January 29, 2012 a las 11:07:41PM +0200, Andriy Gapon escribió: > > Does the following look familiar to anybody (note the stray 'n')? > > $ dd if=/dev/zero bs=1 count=1 | hd > 1+0 records in > 1+0 records out > 1 bytes transferred in 0.000043 secs (23302 bytes/sec) > 00000000 00 |.| > n00000001 $ uname -a FreeBSD tiny 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r226986: Tue Nov 1 14:27:40 CET 2011 guru@caracas:/usr/obj/usr/src/sys/GENERIC i386 $ dd if=/dev/zero bs=1 count=1 | hd 1+0 records in 1+0 records out 1 bytes transferred in 0.000149 secs (6711 bytes/sec) 00000000 00 |.| 00000001 I don't see it and would run both cmd with truss(1) to see which one is sending out the 'n'; matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 02:38:35 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 977B4106566C; Mon, 30 Jan 2012 02:38:35 +0000 (UTC) (envelope-from ambrosehua@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 07BA58FC0A; Mon, 30 Jan 2012 02:38:34 +0000 (UTC) Received: by werm13 with SMTP id m13so2031892wer.13 for ; Sun, 29 Jan 2012 18:38:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Y5rCNTk6ET/23FnX3pyKQU0k0Lo1BC+FwZ1A/TYvs08=; b=x5Sq3ifbXVBDEYXcJlPGxmDawE47BKH61PxLST+KJnL5t2isPCYdjNPUyrEblzReMh iH/4RwHPMONZSughGYvs25ELDw6rdPn0Jfp3+HEwIzOhFxi03kQ6rUsQjY9I0jWVKJJh lsdg7vOsnidb/rw52Va39qqdnZSut5sK68PzY= MIME-Version: 1.0 Received: by 10.216.138.24 with SMTP id z24mr6434766wei.48.1327889751434; Sun, 29 Jan 2012 18:15:51 -0800 (PST) Received: by 10.223.42.18 with HTTP; Sun, 29 Jan 2012 18:15:51 -0800 (PST) Date: Mon, 30 Jan 2012 10:15:51 +0800 Message-ID: From: Paul Ambrose To: freebsd-current Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: kib@freebsd.org Subject: Does anyone try kib's Sandy Bridge PCID patch (pcid.2.patch)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 02:38:35 -0000 I have two boxes, one is AMD Athlon 610e 2.4G with FreeBSD-current patched with pcid.2.patch? It works well without other issue and it seem the pcid patch does not affect other part of the kernel. The other one is Sandy Bridge i5-2300 with FreeBSD 9 release patched with pcid.1.patch( the pcid.2.patch seems dependent on AVX and XSAVE stuffs which is available on -current). But it hangs up just in a few minutes. I doubt the nvidia-driver which is not recompiled with patched kernel is the root, I will check this out later, but does anyone meet similar problem? I have two question about the pcid.2.patch 1. iff --git a/sys/amd64/amd64/apic_vector.S b/sys/amd64/amd64/apic_vector.S index 96c778d..5b7b759 100644 --- a/sys/amd64/amd64/apic_vector.S +++ b/sys/amd64/amd64/apic_vector.S @@ -149,17 +149,40 @@ IDTVEC(invltlb) #endif pushq %rax + pushq %rdx - movq %cr3, %rax /* invalidate the TLB */ - movq %rax, %cr3 - + cmpl $0,pmap_pcid_enabled + je 1f + + cmpq $0,smp_tlb_invpcid + je 1f + + /* + * For PCID-enabled pmap, set bit 63 of loaded %cr3 to zero. + */ + movq %cr3,%rax + movq $pcid_cr3,%rdx + cmpq %rax,%rdx + je 1f + movq %rdx,%cr3 + btsq $63, %rax //set bit 63. not flush the tlb when recovering + jmp 2f + + /* + * Invalidate the TLB. + */ +1: + movq %cr3,%rax +2: // if pcid is available, can we recover the old pcid with 63 bit set=A3=BF + movq %rax,%cr3 movq lapic, %rax movl $0, LA_EOI(%rax) /* End Of Interrupt to APIC */ 2. amd64/amd64/pmap.c @@ -5098,15 +5168,20 @@ pmap_activate(struct thread *td) critical_enter(); pmap =3D vmspace_pmap(td->td_proc->p_vmspace); oldpmap =3D PCPU_GET(curpmap); + CPU_ZERO(&pmap->pm_save); cpuid =3D PCPU_GET(cpuid); #ifdef SMP CPU_CLR_ATOMIC(cpuid, &oldpmap->pm_active); CPU_SET_ATOMIC(cpuid, &pmap->pm_active); + CPU_SET_ATOMIC(cpuid, &pmap->pm_save); #else CPU_CLR(cpuid, &oldpmap->pm_active); CPU_SET(cpuid, &pmap->pm_active); + CPU_SET(cpuid, &pmap->pm_active); // this should be pm_save not pm_active #endif cr3 =3D DMAP_TO_PHYS((vm_offset_t)pmap->pm_pml4); + if (pmap->pm_pcid !=3D -1) + cr3 |=3D pmap->pm_pcid; td->td_pcb->pcb_cr3 =3D cr3; load_cr3(cr3); PCPU_SET(curpmap, pmap); From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 06:36:13 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BCC6106566B for ; Mon, 30 Jan 2012 06:36:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id A2B768FC13 for ; Mon, 30 Jan 2012 06:36:12 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q0U6a8Sr033286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jan 2012 08:36:08 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q0U6a8o0092241; Mon, 30 Jan 2012 08:36:08 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q0U6a7bl092240; Mon, 30 Jan 2012 08:36:07 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 30 Jan 2012 08:36:07 +0200 From: Kostik Belousov To: Paul Ambrose Message-ID: <20120130063607.GV2726@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hRt258QUzs6ToQn5" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current Subject: Re: Does anyone try kib's Sandy Bridge PCID patch (pcid.2.patch)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 06:36:13 -0000 --hRt258QUzs6ToQn5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 30, 2012 at 10:15:51AM +0800, Paul Ambrose wrote: > I have two boxes, one is AMD Athlon 610e 2.4G with FreeBSD-current > patched with pcid.2.patch? It works well without other issue and it > seem the pcid patch > does not affect other part of the kernel. The other one is Sandy Athlons do not have PCID and probably will never implement it. They use other tricks to get similar optimizations, transparently to the OS. > Bridge i5-2300 with FreeBSD 9 release patched with pcid.1.patch( the > pcid.2.patch seems > dependent on AVX and XSAVE stuffs which is available on -current). But > it hangs up just in a few minutes. I doubt the nvidia-driver which is > not recompiled with > patched kernel is the root, I will check this out later, but does > anyone meet similar problem? There are two many variations compared to the config I did tested. I do not see anything obvious in the changes between HEAD and stable/9 which could be blamed. Nvidia driver might be bigger suspect, but again, I am not aware of anything wrong with it. >=20 > I have two question about the pcid.2.patch Item 2 is clean, I fixed it. For the item 1, I was only able to decipher the proposal to optimize the global shootdown handler to restore the %cr3 with bit 64 set to not invalidate current PCID. Is there some more changes ? Thank you for looking at the patch. --hRt258QUzs6ToQn5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk8mOlcACgkQC3+MBN1Mb4htogCg3r4+sKMAoRAEsYoH4s2Gmaz2 e8sAoIjf/8jWnOxfn/hpyU26DdEsMdCV =UV5E -----END PGP SIGNATURE----- --hRt258QUzs6ToQn5-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 09:25:51 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FCBA106566C for ; Mon, 30 Jan 2012 09:25:51 +0000 (UTC) (envelope-from Kashyap.Desai@lsi.com) Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by mx1.freebsd.org (Postfix) with ESMTP id CB58D8FC12 for ; Mon, 30 Jan 2012 09:25:50 +0000 (UTC) Received: from paledge01.lsi.com ([192.19.193.42]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKTyZiHhLlTaboGaXBHCSoWwUHiOeLjxw5@postini.com; Mon, 30 Jan 2012 01:25:50 PST Received: from PALHUB01.lsi.com (128.94.213.114) by PALEDGE01.lsi.com (192.19.193.42) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 30 Jan 2012 04:23:56 -0500 Received: from inbexch02.lsi.com (135.36.98.40) by PALHUB01.lsi.com (128.94.213.114) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 30 Jan 2012 04:19:17 -0500 Received: from inbmail01.lsi.com ([135.36.98.64]) by inbexch02.lsi.com ([135.36.98.40]) with mapi; Mon, 30 Jan 2012 14:49:14 +0530 From: "Desai, Kashyap" To: "Desai, Kashyap" , "freebsd-stable@freebsd.org" , "freebsd-current@freebsd.org" Date: Mon, 30 Jan 2012 14:49:12 +0530 Thread-Topic: mps module compilation issue on FreeBSD-9 amd64 Thread-Index: AczfL6p2onvxGYiiRyaw+Lm85o015QAAE/8w Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "gibbs@FreeBSD.org" , "Kenneth D. Merry" , "McConnell, Stephen" Subject: RE: mps module compilation issue on FreeBSD-9 amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 09:25:51 -0000 > -----Original Message----- > From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > stable@freebsd.org] On Behalf Of Desai, Kashyap > Sent: Monday, January 30, 2012 2:45 PM > To: freebsd-stable@freebsd.org; freebsd-current@freebsd.org > Cc: gibbs@FreeBSD.org; Kenneth D. Merry; McConnell, Stephen > Subject: mps module compilation issue on FreeBSD-9 amd64 >=20 > Hi, >=20 > I am seeing some uncommon problem while doing compilation of mps driver > (this is a latest driver from LSI). >=20 > Here are the steps I followed. >=20 > CASE-1 >=20 > 1. remove mps directory from sys/dev and sys/module and overwrite those > two directories with my latest code. > 2. go to sys/module/mps and run "make". [Things works fine.] >=20 > CASE-2. > 1. remove mps directory from sys/dev and sys/module and overwrite those > two directories with my latest code. > 2. go to main directory ( In my case it is "/usr/trees/9.0.0") > 3. Run below command > make -j8 buildkernel KERNCONF=3DGENERIC MODULES_OVERRIDE=3Dmps > TARGET_ARCH=3Damd64 SYSDIR=3D/usr/trees/9.0.0/sys -DNO_CLEAN - > DNO_KERNELCONFIG -DNO_KERNELCLEAN -DNO_KERNELDEPEND >=20 > Here I am seeing mps.ko file is generated, but it is failing at kernel.debug> steps. (this step is only seen in CASE-1). Typo: It should be=09 this step is only seen in CASE-2. Also, I have first finished buildworld before I tried mps (LSI driver) comp= ilation. > Any Idea How to resolve this issue ? >=20 > INFO: I am using FreeBSD-8.2-Release amd64.case-1 and case-2 both passes > for i386. \\\\ >=20 > --- Compilation failure log for CASE-2 ---- >=20 > ld -d -warn-common -r -d -o mpslsi.ko.debug mps_pci.o mps.o mps_sas.o > mps_table.o mps_user.o mps_config.o mps_mapping.o mps_sas_lsi.o > :> export_syms > awk -f /usr/trees/9.0.0/sys/conf/kmod_syms.awk mpslsi.ko.debug > export_syms | xargs -J% objcopy % mpslsi.ko.debug > /usr/local/bin/svnversion > objcopy --only-keep-debug mpslsi.ko.debug mpslsi.ko.symbols > objcopy --strip-debug --add-gnu-debuglink=3Dmpslsi.ko.symbols > mpslsi.ko.debug mpslsi.ko > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=3Dc99 -g - > Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing- > prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer- > sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show- > option -nostdinc -I. -I/usr/trees/9.0.0/sys - > I/usr/trees/9.0.0/sys/contrib/altq -D_KERNEL - > DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline- > limit=3D8000 --param inline-unit-growth=3D100 --param large-function- > growth=3D1000 -fno-omit-frame-pointer -mno-sse -mcmodel=3Dkernel -mno-re= d- > zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables - > ffreestanding -fstack-protector -Werror vers.c > linking kernel.debug > mps.o: In function `mps_startup': > /usr/trees/9.0.0/sys/dev/mps/mps.c:1249: undefined reference to > `mps_mapping_initialize' > mps.o: In function `mps_free': > /usr/trees/9.0.0/sys/dev/mps/mps.c:1410: undefined reference to > `mps_mapping_free_memory' > mps.o: In function `mps_attach': > /usr/trees/9.0.0/sys/dev/mps/mps.c:1204: undefined reference to > `mps_base_static_config_pages' > /usr/trees/9.0.0/sys/dev/mps/mps.c:1224: undefined reference to > `mpssas_ir_shutdown' > mps_sas.o: In function `mps_attach_sas': > /usr/trees/9.0.0/sys/dev/mps/mps_sas.c:614: undefined reference to > `mpssas_firmware_event_work' > mps_sas.o: In function `mpssas_register_events': > /usr/trees/9.0.0/sys/dev/mps/mps_sas.c:576: undefined reference to > `mpssas_evt_handler' > mps_sas.o: In function `mpssas_portenable_complete': > /usr/trees/9.0.0/sys/dev/mps/mps_sas.c:3069: undefined reference to > `mps_wd_config_pages' > mps_user.o: In function `mps_user_btdh': > /usr/trees/9.0.0/sys/dev/mps/mps_user.c:2038: undefined reference to > `mps_mapping_get_sas_id_from_handle' > mps_user.o: In function `mps_user_get_adapter_data': > /usr/trees/9.0.0/sys/dev/mps/mps_user.c:1101: undefined reference to > `mps_config_get_bios_pg3' > *** Error code 1 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > Failed : make -j8 buildkernel KERNCONF=3DGENERIC MODULES_OVERRIDE=3Dmps > TARGET_ARCH=3Damd64 SYSDIR=3D/usr/trees/9.0.0/sys -DNO_CLEAN - > DNO_KERNELCONFIG -DNO_KERNELCLEAN -DNO_KERNELDEPEND > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable- > unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 09:26:16 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CEC510657B2 for ; Mon, 30 Jan 2012 09:26:16 +0000 (UTC) (envelope-from Kashyap.Desai@lsi.com) Received: from na3sys009aog122.obsmtp.com (na3sys009aog122.obsmtp.com [74.125.149.147]) by mx1.freebsd.org (Postfix) with ESMTP id 1C0558FC08 for ; Mon, 30 Jan 2012 09:26:15 +0000 (UTC) Received: from paledge01.lsi.com ([192.19.193.42]) (using TLSv1) by na3sys009aob122.postini.com ([74.125.148.12]) with SMTP ID DSNKTyZiNzMS/MrsVAU1czrEiDnTpmTK5ucp@postini.com; Mon, 30 Jan 2012 01:26:16 PST Received: from PALHUB01.lsi.com (128.94.213.114) by PALEDGE01.lsi.com (192.19.193.42) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 30 Jan 2012 04:19:55 -0500 Received: from inbexch02.lsi.com (135.36.98.40) by PALHUB01.lsi.com (128.94.213.114) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 30 Jan 2012 04:15:16 -0500 Received: from inbmail01.lsi.com ([135.36.98.64]) by inbexch02.lsi.com ([135.36.98.40]) with mapi; Mon, 30 Jan 2012 14:45:13 +0530 From: "Desai, Kashyap" To: "freebsd-stable@freebsd.org" , "freebsd-current@freebsd.org" Date: Mon, 30 Jan 2012 14:45:10 +0530 Thread-Topic: mps module compilation issue on FreeBSD-9 amd64 Thread-Index: AczfL6p2onvxGYiiRyaw+Lm85o015Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "gibbs@FreeBSD.org" , "Kenneth D. Merry" , "McConnell, Stephen" Subject: mps module compilation issue on FreeBSD-9 amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 09:26:16 -0000 Hi, I am seeing some uncommon problem while doing compilation of mps driver (th= is is a latest driver from LSI). Here are the steps I followed. CASE-1=20 1. remove mps directory from sys/dev and sys/module and overwrite those two= directories with my latest code. 2. go to sys/module/mps and run "make". [Things works fine.] CASE-2. 1. remove mps directory from sys/dev and sys/module and overwrite those two= directories with my latest code. 2. go to main directory ( In my case it is "/usr/trees/9.0.0") 3. Run below command=20 make -j8 buildkernel KERNCONF=3DGENERIC MODULES_OVERRIDE=3Dmps TARGET_ARCH= =3Damd64 SYSDIR=3D/usr/trees/9.0.0/sys -DNO_CLEAN -DNO_KERNELCONFIG -DNO_KE= RNELCLEAN -DNO_KERNELDEPEND Here I am seeing mps.ko file is generated, but it is failing at steps. (this step is only seen in CASE-1). Any Idea How to resolve this issue ? INFO: I am using FreeBSD-8.2-Release amd64.case-1 and case-2 both passes fo= r i386. \\\\ --- Compilation failure log for CASE-2 ---- ld -d -warn-common -r -d -o mpslsi.ko.debug mps_pci.o mps.o mps_sas.o mps_= table.o mps_user.o mps_config.o mps_mapping.o mps_sas_lsi.o :> export_syms awk -f /usr/trees/9.0.0/sys/conf/kmod_syms.awk mpslsi.ko.debug export_syms= | xargs -J% objcopy % mpslsi.ko.debug /usr/local/bin/svnversion objcopy --only-keep-debug mpslsi.ko.debug mpslsi.ko.symbols objcopy --strip-debug --add-gnu-debuglink=3Dmpslsi.ko.symbols mpslsi.ko.deb= ug mpslsi.ko cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=3Dc99 -g -Wal= l -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototy= pes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fforma= t-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -= I. -I/usr/trees/9.0.0/sys -I/usr/trees/9.0.0/sys/contrib/altq -D_KERNEL -DH= AVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit= =3D8000 --param inline-unit-growth=3D100 --param large-function-growth=3D10= 00 -fno-omit-frame-pointer -mno-sse -mcmodel=3Dkernel -mno-red-zone -mno-m= mx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-pro= tector -Werror vers.c linking kernel.debug mps.o: In function `mps_startup': /usr/trees/9.0.0/sys/dev/mps/mps.c:1249: undefined reference to `mps_mappin= g_initialize' mps.o: In function `mps_free': /usr/trees/9.0.0/sys/dev/mps/mps.c:1410: undefined reference to `mps_mappin= g_free_memory' mps.o: In function `mps_attach': /usr/trees/9.0.0/sys/dev/mps/mps.c:1204: undefined reference to `mps_base_s= tatic_config_pages' /usr/trees/9.0.0/sys/dev/mps/mps.c:1224: undefined reference to `mpssas_ir_= shutdown' mps_sas.o: In function `mps_attach_sas': /usr/trees/9.0.0/sys/dev/mps/mps_sas.c:614: undefined reference to `mpssas_= firmware_event_work' mps_sas.o: In function `mpssas_register_events': /usr/trees/9.0.0/sys/dev/mps/mps_sas.c:576: undefined reference to `mpssas_= evt_handler' mps_sas.o: In function `mpssas_portenable_complete': /usr/trees/9.0.0/sys/dev/mps/mps_sas.c:3069: undefined reference to `mps_wd= _config_pages' mps_user.o: In function `mps_user_btdh': /usr/trees/9.0.0/sys/dev/mps/mps_user.c:2038: undefined reference to `mps_m= apping_get_sas_id_from_handle' mps_user.o: In function `mps_user_get_adapter_data': /usr/trees/9.0.0/sys/dev/mps/mps_user.c:1101: undefined reference to `mps_c= onfig_get_bios_pg3' *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error Failed : make -j8 buildkernel KERNCONF=3DGENERIC MODULES_OVERRIDE=3Dmps TAR= GET_ARCH=3Damd64 SYSDIR=3D/usr/trees/9.0.0/sys -DNO_CLEAN -DNO_KERNELCONFIG= -DNO_KERNELCLEAN -DNO_KERNELDEPEND From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 10:11:52 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0B91106566B; Mon, 30 Jan 2012 10:11:52 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 7B6788FC0A; Mon, 30 Jan 2012 10:11:51 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 584FC6AA3; Mon, 30 Jan 2012 10:11:50 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 345668570; Mon, 30 Jan 2012 11:11:50 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Attilio Rao References: <201111081018.pA8AI7ha027020@svn.freebsd.org> Date: Mon, 30 Jan 2012 11:11:50 +0100 In-Reply-To: (Attilio Rao's message of "Sat, 28 Jan 2012 17:03:11 +0100") Message-ID: <86wr89jy8p.fsf_-_@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD FS , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Retiring non-mpsafe filesystems (was: Re: svn commit: r227333 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/kern sys/mips/conf sys/pc98/conf sys/powerpc/conf sys/sparc64/conf) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 10:11:52 -0000 Attilio Rao writes: > In one month I'm going to disable VFS_ALLOW_NONMPSAFE by defaults in > order to see how well the users do with this option down. At the > present times this means that from 1st March you won't be able to > mount smbfs or ntfs volumes, for example. Hmm, wasn't there a GSoC project to reimplement NTFS? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 11:08:15 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A1641065670 for ; Mon, 30 Jan 2012 11:08:15 +0000 (UTC) (envelope-from ambrosehua@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id D27D98FC19 for ; Mon, 30 Jan 2012 11:08:14 +0000 (UTC) Received: by wgbdr11 with SMTP id dr11so4218850wgb.31 for ; Mon, 30 Jan 2012 03:08:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=BXm7cLk5eujK49ml4LhqNSmK9vD5FcVAZDgjgJCqwBY=; b=Cxp6QJ7t4Ker626KvfvfR5ZvmE0QMcrbmMytN8kTLGNcLq8FA11w2nFayTLI6vSAvP 9QteahEsd7/8t4REDAA2UpUT5s0Ny2MNp1N9H0wN5fNQ5ypejBwaeBBY8a7hYW4tkDAj yZgW7jV+9yAduP8eGyr4WeY0fpUhyNUeGMoQQ= MIME-Version: 1.0 Received: by 10.180.96.161 with SMTP id dt1mr27423270wib.13.1327921693666; Mon, 30 Jan 2012 03:08:13 -0800 (PST) Received: by 10.223.42.18 with HTTP; Mon, 30 Jan 2012 03:08:13 -0800 (PST) In-Reply-To: <20120130063607.GV2726@deviant.kiev.zoral.com.ua> References: <20120130063607.GV2726@deviant.kiev.zoral.com.ua> Date: Mon, 30 Jan 2012 19:08:13 +0800 Message-ID: From: Paul Ambrose To: Kostik Belousov Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current Subject: Re: Does anyone try kib's Sandy Bridge PCID patch (pcid.2.patch)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 11:08:15 -0000 =D4=DA 2012=C4=EA1=D4=C230=C8=D5 =CF=C2=CE=E72:36=A3=ACKostik Belousov =D0=B4=B5=C0=A3=BA > On Mon, Jan 30, 2012 at 10:15:51AM +0800, Paul Ambrose wrote: >> I have two boxes, one is AMD Athlon 610e 2.4G with FreeBSD-current >> patched with pcid.2.patch? It works well without other issue and it >> seem the pcid patch >> does not affect other part of the kernel. The other one is Sandy > Athlons do not have PCID and probably will never implement it. They use > other tricks to get similar optimizations, transparently to the OS. > Just curious, is this AMD similar optimizations Address Space Number (ASN) and Global flag US Patent 6,604,187. http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs= _64bit_Core.html I did not found anything about ASN in the AMD manual >> Bridge i5-2300 with FreeBSD 9 release patched with pcid.1.patch( the >> pcid.2.patch seems >> dependent on AVX and XSAVE stuffs which is available on -current). But >> it hangs up just in a few minutes. I doubt the nvidia-driver which is >> not recompiled with >> patched kernel is the root, I will check this out later, but does >> anyone meet similar problem? > There are two many variations compared to the config I did tested. > I do not see anything obvious in the changes between HEAD and stable/9 > which could be blamed. Nvidia driver might be bigger suspect, but again, > I am not aware of anything wrong with it. > >> >> I have two question about the pcid.2.patch > > Item 2 is clean, I fixed it. > > For the item 1, I was only able to decipher the proposal to optimize > the global shootdown handler to restore the %cr3 with bit 64 set to not > invalidate current PCID. Is there some more changes ? > yes, that is what I meant. I was wondering using another way that each process has different pcid in each active processor, just as the freebsd mips and powerpc uses. But obviously this way is more friendly to non-pcid x86 processor. > Thank you for looking at the patch. From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 12:03:31 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33568106564A; Mon, 30 Jan 2012 12:03:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id F1E6B8FC14; Mon, 30 Jan 2012 12:03:30 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q0UC3T1l026205; Mon, 30 Jan 2012 07:03:29 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q0UC3T5o026204; Mon, 30 Jan 2012 12:03:29 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 30 Jan 2012 12:03:29 GMT Message-Id: <201201301203.q0UC3T5o026204@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 12:03:31 -0000 TB --- 2012-01-30 09:29:29 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-30 09:29:29 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-01-30 09:29:29 - cleaning the object tree TB --- 2012-01-30 09:29:39 - cvsupping the source tree TB --- 2012-01-30 09:29:39 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-01-30 09:30:22 - building world TB --- 2012-01-30 09:30:22 - CROSS_BUILD_TESTING=YES TB --- 2012-01-30 09:30:22 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-30 09:30:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-30 09:30:22 - SRCCONF=/dev/null TB --- 2012-01-30 09:30:22 - TARGET=powerpc TB --- 2012-01-30 09:30:22 - TARGET_ARCH=powerpc64 TB --- 2012-01-30 09:30:22 - TZ=UTC TB --- 2012-01-30 09:30:22 - __MAKE_CONF=/dev/null TB --- 2012-01-30 09:30:22 - cd /src TB --- 2012-01-30 09:30:22 - /usr/bin/make -B buildworld >>> World build started on Mon Jan 30 09:30:23 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Mon Jan 30 11:53:29 UTC 2012 TB --- 2012-01-30 11:53:29 - generating LINT kernel config TB --- 2012-01-30 11:53:29 - cd /src/sys/powerpc/conf TB --- 2012-01-30 11:53:29 - /usr/bin/make -B LINT TB --- 2012-01-30 11:53:29 - cd /src/sys/powerpc/conf TB --- 2012-01-30 11:53:29 - /usr/sbin/config -m LINT TB --- 2012-01-30 11:53:29 - building LINT kernel TB --- 2012-01-30 11:53:29 - CROSS_BUILD_TESTING=YES TB --- 2012-01-30 11:53:29 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-30 11:53:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-30 11:53:29 - SRCCONF=/dev/null TB --- 2012-01-30 11:53:29 - TARGET=powerpc TB --- 2012-01-30 11:53:29 - TARGET_ARCH=powerpc64 TB --- 2012-01-30 11:53:29 - TZ=UTC TB --- 2012-01-30 11:53:29 - __MAKE_CONF=/dev/null TB --- 2012-01-30 11:53:29 - cd /src TB --- 2012-01-30 11:53:29 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 30 11:53:29 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror vnode_if.c :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror vers.c linking kernel mmu_oea64.o:(.got+0x88): undefined reference to `elf32_nxstack' *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-30 12:03:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-30 12:03:29 - ERROR: failed to build LINT kernel TB --- 2012-01-30 12:03:29 - 7853.72 user 1123.58 system 9240.35 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 12:39:35 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CD65106564A; Mon, 30 Jan 2012 12:39:35 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E95B98FC13; Mon, 30 Jan 2012 12:39:34 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0UCdYM9095231; Mon, 30 Jan 2012 12:39:34 GMT (envelope-from bapt@FreeBSD.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0UCdYdf095230; Mon, 30 Jan 2012 12:39:34 GMT (envelope-from bapt@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@FreeBSD.org using -f Date: Mon, 30 Jan 2012 13:39:30 +0100 From: Baptiste Daroussin To: current@FreeBSD.org, ports@FreeBSD.org, ports-announce@FreeBSD.org Message-ID: <20120130123930.GB40244@azathoth.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3lcZGd9BuhuYXNfi" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: [HEADSUP][CFT] pkgng beta1 is out X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 12:39:35 -0000 --3lcZGd9BuhuYXNfi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, pkgng has just reached the beta phase, and has now found its way to the ports tree (disabled by default). 1/ Why pkgng? ------------ Our current pkg_install tools are showing their age, are hard to maintain, and they lack features: - missing metadata - no upgrade support - no repository support - no fine dependency tracking - no modern binary package management - and many others Having old tools makes it hard to improve the ports infrastructure, as a result lots of hacks have found their way into the different Mk/bsd.*.mk files to work around pkg_install limitations plus there are lots of hacks in the packages metadata itself such as @comment which are not comments, and so forth. We have people writing tools to improve the situation (portmaster and portupgrade to name two), but they are limited by and can become quite complicated to maintain because of the pkg_install limitations. 2/ What it is? -------------- It is a tool that is designed to replace pkg_install and provide modern features to advance package management on FreeBSD. It has been done with compatibility in mind. Most of the ports tree are able to build on pkgng without modification (21500 successful packages is the highest pkgng score so far). The missing ones will be easily fixed with pkgng in ports. It has been done with ease of migration in mind. It is easy to migrate =66rom pkg_install to pkgng. (Please note that going backwards is not possible.) It has been done with FreeBSD features in mind: it supports chroot, jails, rcng, etc. It has been done with scripting features in mind: 'pkg query' will allow you to query almost everything from the pkgng database in a script friendly way. It has been done with improvement in mind: it doesn't require a privileged account to create packages with root files in it; it is already able to package from a stage/fakeroot/name_it_like_you_want directory; it is also able to fake the package creation to directly install the package from that fake/stage/whatever directory. It has been done with human readability in mind: the new metadata is stored in YAML format; the plist keywords can be extended with YAML (for the ports). It has been our thinking that the pkg binary is not able to please everyone's needs, so it has been written on top of a library which can be used by any other third party tools. (Think about packagekit, or ruby binding for portupgrade for example, or any other usage like these). pkgng is the result of my long studies and reflection about packaging (studying what is done elsewhere: apt/dpkg, yum/rpm, pacman, aix, solaris, netbsd, openbsd) and how to have something that tries to take the good ideas from them, but tries not to take the *over engineered* complicated parts. And most importantly, tries to do it the FreeBSD way: which means it should work with the ports tree as-is (and help improve it in the future= ). 3/ Roadmap ---------- We plan a very long beta phase with lots of beta versions, released as often as possible to ease testing and help improve the tool as much as possible. The goal, now that we are in beta is to not break anything for users, which means that pkgng will be able to safely upgrade itself. (No real breakage occurred during the alpha phase; expect even less in beta.) Most of the big features are implemented, so now if you have a revolutionary idea that breaks everything, it won't find its way into pkgng 1.0. You can still provide it for pkgng 2.0. 1.0 is not revolutionary because of the way that it is full of workarounds to allow compatibility with the current ports tree. At some future time (TBD), once we have dropped pkg_install support, things will be able to move forward faster. pkgng will live in the ports tree, so it will evolve with the infrastructure, allowing us not to have to wait for the EOL of a release to be able to move forward to new features. The library API is currently not considered stable; it will be designated stable as of pkgng 2.0. Therefore, if you are going to use the library in a third party project, you can expect some breakage from time to time. Of course, we will avoid breakage as much as possible. The plan is to have pkgng 1.0 ready and rock solid for 10.0-RELEASE and 9.1-RELEASE. The more testers/contributors we have, the faster we can go, and the faster we go, the faster we can drop pkg_install and improve our port infrastructure. (Note: due to limitations in FreeBSD 7.x, we do not plan to backport there.) 4/ pkgng itself ---------------- pkg add: add packages the old way (should be avoided by users) pkg audit: audit the installed packages for vulnerabilities pkg autoremove: interactively propose packages to be removed that were installed automatically (as a dependency) and not depended on anymore pkg check: check the installed packages database, prompting for inconsistency and proposing to try to fix it pkg clean: cleanup the package cache from binary installation (from repositories) pkg delete: deinstall packages pkg info: query information from the installed packages in a user-friendly way pkg install: install packages from a remote repository pkg query: query information from the installed packages in a script-friendly way pkg register: register packages in the database, synchronising the files =66rom a fake/stage directory, or with already installed files (like currently with ports) pkg search: search the remote database for packages pkg update: update the remote repositories databases pkg updating: scan the installed ports and show all UPDATING entries that affect one of the installed ports (same as old pkg_updating) pkg upgrade: perform a full binary upgrade of the installed packages pkg version: determine whether package(s) need to be updated (same as old pkg_version) pkg which: determine which package owns a file pkg2ng: convert a pkg_install installed database to a pkgng installed database (you would need the ports tree for pkg2ng to be able to gather missing information about packages) Sample output of pkg info: $ pkg info -f libreoffice: Name : libreoffice Version : 3.4.4 Origin : editors/libreoffice Prefix : /usr/local Categories : editors Licenses : MPL & LGPL3 Maintainer : office@FreeBSD.org WWW : http://www.libreoffice.org/ Comment : Full integrated office productivity suite Options : DEBUG: off GNOME: off GTK: on JAVA: off KDE4: off MMEDIA: off PYUNO: off SDK: off SYSTRAY: off WEBDAV: off Flat size : 319 MB Description : LibreOffice is the free power-packed Open Source personal productivity suit= e for Windows, Macintosh and Linux, that gives you six feature-rich applications = for all your document production and data processing needs: Writer, Calc, Impre= ss, Draw, Math and Base. WWW: http://www.libreoffice.org/ 5/ what is missing ------------------ - for 1.0: * currently the user handling is done using the @exec/@unexec scripts from the ports; we need to finish the switch to the pw_/gr_util API to have cleaner handling. * better error reporting; lots of error/warning messages are currently technical and need to be improved to become more user-friendly. * better documentation; pkgng does a lot of things (more than what is described here) and needs to be documented. We lack enough native English speakers that are able to correctly document everything. * bug hunting and fixing. - for future: * capsicum: during EuroBSDCon some ideas were shared on how we can capsicumize pkgng, and more generally, increase security in package management; we need to have more thought about this subject. * improved arch support; currently pkgng is able to prevent installing amd64 packages into an arm box for examples, but we can go further and have real arch handling -- packaging noarch packages only once for all architectures (shell scripts, data, etc) and share them between the repository. This would reduce the size of the repositories and speed up the packages building process. * incrementally updated packages (diff packages): this is a really complicated task but could be done, would need a clean design. * abstract/alternative packages (e.g. "provide http_server") * having a real sat solver for the dependency tree. Currently we have a really simple and minimalistic solver which works well but if we can to go to an even finer package management we would need a real solver. * many more to join the project to share your ideas. Keep in mind that in pkgng, every thing should be and will remain simple, so when you come up with ideas, try providing a simple and clean design :) to use pkgng: echo WITH_PKGNG=3Dyes >> /etc/make.conf make -C /usr/ports/ports-mgmt/pkg install clean Some links:=20 http://wiki.FreeBSD.org/pkgng http://github.com/pkgng/pkgng Note that on github you can find a patch for portmaster (against 3.10) On behalf of the pkgng team Bapt --3lcZGd9BuhuYXNfi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk8mj4IACgkQ8kTtMUmk6Exq2ACffqfOUVo/pz4MpmTAjsjMDdHr q28AoJQ7sBHyafRxjQXC4VD3XM7smTDk =nTG+ -----END PGP SIGNATURE----- --3lcZGd9BuhuYXNfi-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 13:07:50 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CB9A1065670; Mon, 30 Jan 2012 13:07:50 +0000 (UTC) (envelope-from wenheping@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id ED6E38FC18; Mon, 30 Jan 2012 13:07:49 +0000 (UTC) Received: by obcwo16 with SMTP id wo16so5964677obc.13 for ; Mon, 30 Jan 2012 05:07:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DEQcTqNR01mTuBhsFAtVU3CXTH05NGezmckEnwDGYsQ=; b=HaEfEr/pkHdCrlyJNFIVWVd6Rkucnr4L9xkxwzSvR6hM6PjlDzGCj4iFuWUBhFMvYd 4J2t3l9ur0gpMt4tlnu43K9qS0jHTK+ne0qs6QG/hkkfTOgFaxCMXkkZjznzpt3HivNv TrwdnX0dWrIW7Xqnxmb1GCQO0nrlPkyxFNpNc= MIME-Version: 1.0 Received: by 10.182.0.48 with SMTP id 16mr874577obb.23.1327927351062; Mon, 30 Jan 2012 04:42:31 -0800 (PST) Received: by 10.182.75.103 with HTTP; Mon, 30 Jan 2012 04:42:31 -0800 (PST) In-Reply-To: <20120130123930.GB40244@azathoth.lan> References: <20120130123930.GB40244@azathoth.lan> Date: Mon, 30 Jan 2012 20:42:31 +0800 Message-ID: From: wen heping To: Baptiste Daroussin Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: ports@freebsd.org, ports-announce@freebsd.org, current@freebsd.org Subject: Re: [HEADSUP][CFT] pkgng beta1 is out X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 13:07:50 -0000 Cool ! wen 2012/1/30 Baptiste Daroussin > Hi, > > pkgng has just reached the beta phase, and has now found its way to the > ports tree (disabled by default). > > 1/ Why pkgng? > ------------ > > Our current pkg_install tools are showing their age, are hard to maintain, > and they lack features: > > > From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 16:43:25 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70686106566C for ; Mon, 30 Jan 2012 16:43:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 02F148FC0A for ; Mon, 30 Jan 2012 16:43:24 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q0UGhGkk036453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jan 2012 18:43:17 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q0UGhG8K097150; Mon, 30 Jan 2012 18:43:16 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q0UGhGZO097149; Mon, 30 Jan 2012 18:43:16 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 30 Jan 2012 18:43:16 +0200 From: Kostik Belousov To: Paul Ambrose Message-ID: <20120130164316.GW2726@deviant.kiev.zoral.com.ua> References: <20120130063607.GV2726@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QWIFStbFpmlD00Pf" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current Subject: Re: Does anyone try kib's Sandy Bridge PCID patch (pcid.2.patch)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 16:43:25 -0000 --QWIFStbFpmlD00Pf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 30, 2012 at 07:08:13PM +0800, Paul Ambrose wrote: > ?? 2012??1??30?? ????2:36??Kostik Belousov ?????? > > On Mon, Jan 30, 2012 at 10:15:51AM +0800, Paul Ambrose wrote: > >> I have two boxes, one is AMD Athlon 610e 2.4G with FreeBSD-current > >> patched with pcid.2.patch? It works well without other issue and it > >> seem the pcid patch > >> does not affect other part of the kernel. The other one is Sandy > > Athlons do not have PCID and probably will never implement it. They use > > other tricks to get similar optimizations, transparently to the OS. > > > Just curious, is this AMD similar optimizations > Address Space Number (ASN) and Global flag > US Patent 6,604,187. > http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AM= Ds_64bit_Core.html This and the same-important next item 'The TLB Flush Filter' is what I referred to. > I did not found anything about ASN in the AMD manual It is a transparent optimization, which does not require any OS support. Intel PCID is completely different, it shall be explicitely handled by OS. It is some consequence of the nested pages support, AFAIU. >=20 > >> Bridge i5-2300 with FreeBSD 9 release patched with pcid.1.patch( the > >> pcid.2.patch seems > >> dependent on AVX and XSAVE stuffs which is available on -current). But > >> it hangs up just in a few minutes. I doubt the nvidia-driver which is > >> not recompiled with > >> patched kernel is the root, I will check this out later, but does > >> anyone meet similar problem? > > There are two many variations compared to the config I did tested. > > I do not see anything obvious in the changes between HEAD and stable/9 > > which could be blamed. Nvidia driver might be bigger suspect, but again, > > I am not aware of anything wrong with it. > > > >> > >> I have two question about the pcid.2.patch > > > > Item 2 is clean, I fixed it. > > > > For the item 1, I was only able to decipher the proposal to optimize > > the global shootdown handler to restore the %cr3 with bit 64 set to not > > invalidate current PCID. Is there some more changes ? > > > yes, that is what I meant. I was wondering using another way that each > process has different > pcid in each active processor, just as the freebsd mips and powerpc > uses. But obviously this way > is more friendly to non-pcid x86 processor. Each vmspace (or pmap) has unique PCID with the patch, at least until PCID space (12bit) is not exhausted. To really exhaust it, you need 4095 processes, so it is unlikely but possible event with the current settings. --QWIFStbFpmlD00Pf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk8myKQACgkQC3+MBN1Mb4gcxgCgkQBCUHUve1s8BKEET8Y/r6hy F4QAoM0OxgMI27N4VsxVftKKqBeu7eWG =Oobf -----END PGP SIGNATURE----- --QWIFStbFpmlD00Pf-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 16:59:10 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 007541065675 for ; Mon, 30 Jan 2012 16:59:10 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4E0348FC1C for ; Mon, 30 Jan 2012 16:59:08 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA21035; Mon, 30 Jan 2012 18:59:06 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4F26CC5A.2070501@FreeBSD.org> Date: Mon, 30 Jan 2012 18:59:06 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120111 Thunderbird/9.0 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: revisiting tunables under Safe Mode menu option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 16:59:10 -0000 First, I think that this proposal/discussion could have been more useful before the 9.0. Maybe the RE would be interested in adding another item to their pre-release checklist: ask developers about what could be dropped and what should be added to the Safe Mode settings in a new (.0) release. Probably the developers should keep the Safe Mode in mind too when adding new features or making other drastic changes, but the reminder should be welcome. What we have for Safe Mode now (from menu-commands.4th): > \ > \ Toggle ACPI elements if necessary > \ > acpipresent? if acpienabled? if > menuacpi @ dup 0<> if > toggle_menuitem ( N -- N ) > then > drop > acpi_disable > then then > > s" set hint.apic.0.disabled=1" evaluate > s" set hw.ata.ata_dma=0" evaluate > s" set hw.ata.atapi_dma=0" evaluate > s" set hw.ata.wc=0" evaluate > s" set hw.eisa_slots=0" evaluate > s" set hint.kbdmux.0.disabled=1" evaluate o Since we have a separate ACPI option and because ACPI now is almost a mandatory thing (and not a significant source of boot troubles), maybe we could remove the code that automatically disables ACPI in Safe Mode? o hint.apic.0.disabled - APIC code doesn't seem to be a significant source of boot troubles, like ACPI it has become almost a mandatory thing. So maybe we should remove this setting? o hw.ata.ata_dma, hw.ata.atapi_dma - I am not sure if there have been any significant problems with ATA DMA recently. Maybe these could be removed? o hw.ata.wc - I am not sure if this setting is relevant to the safe boot. Another candidate for removal? o hw.eisa_slot - Looks like something from ancient times. Probably just irrelevant for most systems. o hint.kbdmux.0.disabled - I do not recall any recent problems with kbdmux. In fact disabling it may produce a surprising behavior for a user if there are multiple keyboards actually attached. Just so that the Safe Mode doesn't turn into a NOP I propose to add the following tunables: o kern.eventtimer.periodic=1 - Use periodic timer to drive clocks just in case a system has any problems with the default mode. Example: PR 164457. o kern.geom.part.check_integrity=0 - Let GPART code be more permissive, could be useful during upgrades from earlier versions of FreeBSD or when multi-booting with other OSes. o More? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 17:10:48 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43AC31065674; Mon, 30 Jan 2012 17:10:48 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0FC318FC17; Mon, 30 Jan 2012 17:10:48 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0UHAlJ1046337; Mon, 30 Jan 2012 17:10:47 GMT (envelope-from bapt@freebsd.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0UHAlE7046302; Mon, 30 Jan 2012 17:10:47 GMT (envelope-from bapt@freebsd.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@freebsd.org using -f Date: Mon, 30 Jan 2012 18:10:44 +0100 From: Baptiste Daroussin To: Jos Backus Message-ID: <20120130171044.GD40244@azathoth.lan> References: <20120130123930.GB40244@azathoth.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PHCdUe6m4AxPMzOu" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ports@freebsd.org, current@freebsd.org Subject: Re: [HEADSUP][CFT] pkgng beta1 is out X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 17:10:48 -0000 --PHCdUe6m4AxPMzOu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 30, 2012 at 08:43:58AM -0800, Jos Backus wrote: > Hi Baptiste, >=20 > This looks great! >=20 > On Mon, Jan 30, 2012 at 4:39 AM, Baptiste Daroussin wro= te: >=20 > > > > Sample output of pkg info: > > > > $ pkg info -f libreoffice: > > Name : libreoffice > > Version : 3.4.4 > > Origin : editors/libreoffice > > Prefix : /usr/local > > Categories : editors > > Licenses : MPL & LGPL3 > > Maintainer : office@FreeBSD.org > > WWW : http://www.libreoffice.org/ > > Comment : Full integrated office productivity suite > > Options : > > DEBUG: off > > GNOME: off > > GTK: on > > JAVA: off > > KDE4: off > > MMEDIA: off > > PYUNO: off > > SDK: off > > SYSTRAY: off > > WEBDAV: off > > Flat size : 319 MB > > Description : > > LibreOffice is the free power-packed Open Source personal productivity > > suite for > > Windows, Macintosh and Linux, that gives you six feature-rich applicati= ons > > for > > all your document production and data processing needs: Writer, Calc, > > Impress, > > Draw, Math and Base. > > > > WWW: http://www.libreoffice.org/ > > > > >=20 >=20 > I haven't checked if `pkg query' can do this yet, but how about emitting > the above output in YAML as well? It would still be very readable for > humans. >=20 > Anyway, I'll try this out. >=20 No pkg query can't do this, but this would be a nice addition (something li= ke raw output for info or query) I do like the idea, please create an issue on= the github :)) regards, Bapt --PHCdUe6m4AxPMzOu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk8mzxQACgkQ8kTtMUmk6EwhkQCfScuhitnowlBrB1YNewqxLCfn sVEAn0LjYX0m6XwdMjUZxm/Km/uJyacJ =3UEt -----END PGP SIGNATURE----- --PHCdUe6m4AxPMzOu-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 17:11:41 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20AD71065673; Mon, 30 Jan 2012 17:11:41 +0000 (UTC) (envelope-from jos@catnook.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id B6BC18FC1B; Mon, 30 Jan 2012 17:11:40 +0000 (UTC) Received: by ghbg15 with SMTP id g15so2062287ghb.13 for ; Mon, 30 Jan 2012 09:11:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.202.97 with SMTP id kh1mr17789218igc.19.1327941838476; Mon, 30 Jan 2012 08:43:58 -0800 (PST) Received: by 10.42.218.7 with HTTP; Mon, 30 Jan 2012 08:43:58 -0800 (PST) In-Reply-To: <20120130123930.GB40244@azathoth.lan> References: <20120130123930.GB40244@azathoth.lan> Date: Mon, 30 Jan 2012 08:43:58 -0800 Message-ID: From: Jos Backus To: Baptiste Daroussin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: ports@freebsd.org, ports-announce@freebsd.org, current@freebsd.org Subject: Re: [HEADSUP][CFT] pkgng beta1 is out X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 17:11:41 -0000 Hi Baptiste, This looks great! On Mon, Jan 30, 2012 at 4:39 AM, Baptiste Daroussin wrote: > > Sample output of pkg info: > > $ pkg info -f libreoffice: > Name : libreoffice > Version : 3.4.4 > Origin : editors/libreoffice > Prefix : /usr/local > Categories : editors > Licenses : MPL & LGPL3 > Maintainer : office@FreeBSD.org > WWW : http://www.libreoffice.org/ > Comment : Full integrated office productivity suite > Options : > DEBUG: off > GNOME: off > GTK: on > JAVA: off > KDE4: off > MMEDIA: off > PYUNO: off > SDK: off > SYSTRAY: off > WEBDAV: off > Flat size : 319 MB > Description : > LibreOffice is the free power-packed Open Source personal productivity > suite for > Windows, Macintosh and Linux, that gives you six feature-rich applications > for > all your document production and data processing needs: Writer, Calc, > Impress, > Draw, Math and Base. > > WWW: http://www.libreoffice.org/ > > I haven't checked if `pkg query' can do this yet, but how about emitting the above output in YAML as well? It would still be very readable for humans. Anyway, I'll try this out. Jos -- Jos Backus jos at catnook.com From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 17:18:57 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A9D4106566C for ; Mon, 30 Jan 2012 17:18:57 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id DFB5A8FC15 for ; Mon, 30 Jan 2012 17:18:56 +0000 (UTC) Received: by obcwo16 with SMTP id wo16so6356762obc.13 for ; Mon, 30 Jan 2012 09:18:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.147.106 with SMTP id tj10mr29848811obb.12.1327942251054; Mon, 30 Jan 2012 08:50:51 -0800 (PST) Received: by 10.182.149.8 with HTTP; Mon, 30 Jan 2012 08:50:50 -0800 (PST) X-Originating-IP: [80.89.199.122] Date: Mon, 30 Jan 2012 22:50:50 +0600 Message-ID: From: Max Khon To: current@freebsd.org Content-Type: multipart/mixed; boundary=f46d04446c5728048a04b7c1a6d8 Cc: Subject: FILTER_SCHEDULE_THREAD is not a bit-value X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 17:18:57 -0000 --f46d04446c5728048a04b7c1a6d8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGVsbG8hCgpzeXMvYnVzLmggZG9jdW1lbnRzIHRoZSBmb2xsb3dpbmcgc2VtYW50aWNzIGZvciBG SUxURVJfU0NIRURVTEVfVEhSRUFEOgoKLyoqCsKgKiBAYnJpZWYgRHJpdmVyIGludGVycnVwdCBm aWx0ZXIgcmV0dXJuIHZhbHVlcwrCoCoKwqAqIElmIGEgZHJpdmVyIHByb3ZpZGVzIGFuIGludGVy cnVwdCBmaWx0ZXIgcm91dGluZSBpdCBtdXN0IHJldHVybiBhbgrCoCogaW50ZWdlciBjb25zaXN0 aW5nIG9mIG9yaW5nIHRvZ2V0aGVyIHplcm8gb3IgbW9yZSBvZiB0aGUgZm9sbG93aW5nCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIF5eXl5eXl4KwqAqIGZsYWdzOgrCoCoKwqAqwqDC oMKgwqDCoCBGSUxURVJfU1RSQVnCoMKgwqAgLSB0aGlzIGRldmljZSBkaWQgbm90IHRyaWdnZXIg dGhlIGludGVycnVwdArCoCrCoMKgwqDCoMKgIEZJTFRFUl9IQU5ETEVEwqAgLSB0aGUgaW50ZXJy dXB0IGhhcyBiZWVuIGZ1bGx5IGhhbmRsZWQgYW5kIGNhbiBiZSBFT0lkCsKgKsKgwqDCoMKgwqAg RklMVEVSX1NDSEVEVUxFX1RIUkVBRCAtIHRoZSB0aHJlYWRlZCBpbnRlcnJ1cHQgaGFuZGxlciBz aG91bGQgYmUKwqAqwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCBzY2hlZHVsZWQgdG8gZXhlY3V0ZQrCoCoKwqAqIElmIHRoZSBkcml2ZXIgZG9lcyBub3QgcHJv dmlkZSBhIGZpbHRlciwgdGhlbiB0aGUgaW50ZXJydXB0IGNvZGUgd2lsbArCoCogYWN0IGlzIGlm IHRoZSBmaWx0ZXIgaGFkIHJldHVybmVkIEZJTFRFUl9TQ0hFRFVMRV9USFJFQUQuwqAgTm90ZSB0 aGF0IGl0CsKgKiBpcyBpbGxlZ2FsIHRvIHNwZWNpZnkgYW55IG90aGVyIGZsYWcgd2l0aCBGSUxU RVJfU1RSQVkgYW5kIHRoYXQgaXQgaXMKwqAqIGlsbGVnYWwgdG8gbm90IHNwZWNpZnkgZWl0aGVy IG9mIEZJTFRFUl9IQU5ETEVEIG9yIEZJTFRFUl9TQ0hFRFVMRV9USFJFQUQKwqAqIGlmIEZJTFRF Ul9TVFJBWSBpcyBub3Qgc3BlY2lmaWVkLgrCoCovCiNkZWZpbmUgRklMVEVSX1NUUkFZwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCAweDAxCiNkZWZpbmUgRklMVEVSX0hBTkRMRUTCoMKgwqDCoMKgwqDC oMKgwqAgMHgwMgojZGVmaW5lIEZJTFRFUl9TQ0hFRFVMRV9USFJFQUTCoCAweDA0CgpCdXQgYWN0 dWFsbHkgRklMVEVSX1NDSEVEVUxFX1RIUkVBRCBpcyBub3QgdXNlZCBhcyBhIGJpdC12YWx1ZSAo c2VlCmtlcm4va2Vybl9pbnRyLmMpOgoKwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGlm ICghdGhyZWFkKSB7CsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgaWYgKHJldCA9PSBGSUxURVJfU0NIRURVTEVfVEhSRUFEKQrCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB0aHJlYWQgPSAxOwrC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfQoKVGhlcmUgaXMgYXQgbGVhc3Qgb25lIGlu LXRyZWUgZHJpdmVyIHRoYXQgY291bGQgYmUgYnJva2VuIGJlY2F1c2Ugb2YKdGhpcyAoYXNtYyg4 KSwgYnV0IEkgZm91bmQgdGhlIHByb2JsZW0gd2l0aCBzb21lIG90aGVyIG91dC1vZi10cmVlCmRy aXZlcikuClRoaXMgc2hvdWxkIGJlICJpZiAocmV0ICYgRklMVEVSX1NDSEVEVUxFX1RIUkVBRCki IGluc3RlYWQuIEF0dGFjaGVkCnBhdGNoIGZpeGVzIHRoZSBwcm9ibGVtLgoKV2hhdCBkbyB5b3Ug dGhpbms/CgpNYXgK --f46d04446c5728048a04b7c1a6d8 Content-Type: application/octet-stream; name="ithread.diff" Content-Disposition: attachment; filename="ithread.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gy1qh8si0 SW5kZXg6IHN5cy9rZXJuL2tlcm5faW50ci5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9rZXJuL2tlcm5f aW50ci5jCShyZXZpc2lvbiAyMjg0OTEpCisrKyBzeXMva2Vybi9rZXJuX2ludHIuYwkod29ya2lu ZyBjb3B5KQpAQCAtMTQ0OSw3ICsxNDQ5LDcgQEAKIAkJICogdGhlaXIgb3duCiAJCSAqLwogCQlp ZiAoIXRocmVhZCkgewotCQkJaWYgKHJldCA9PSBGSUxURVJfU0NIRURVTEVfVEhSRUFEKQorCQkJ aWYgKHJldCAmIEZJTFRFUl9TQ0hFRFVMRV9USFJFQUQpCiAJCQkJdGhyZWFkID0gMTsKIAkJfQog CX0K --f46d04446c5728048a04b7c1a6d8-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 17:21:38 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 998AB106564A; Mon, 30 Jan 2012 17:21:38 +0000 (UTC) (envelope-from jos@catnook.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 381DE8FC12; Mon, 30 Jan 2012 17:21:37 +0000 (UTC) Received: by ghbg15 with SMTP id g15so2070455ghb.13 for ; Mon, 30 Jan 2012 09:21:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.202.97 with SMTP id kh1mr17898445igc.19.1327944097311; Mon, 30 Jan 2012 09:21:37 -0800 (PST) Received: by 10.42.218.7 with HTTP; Mon, 30 Jan 2012 09:21:37 -0800 (PST) In-Reply-To: <20120130171044.GD40244@azathoth.lan> References: <20120130123930.GB40244@azathoth.lan> <20120130171044.GD40244@azathoth.lan> Date: Mon, 30 Jan 2012 09:21:37 -0800 Message-ID: From: Jos Backus To: Baptiste Daroussin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: ports@freebsd.org, current@freebsd.org Subject: Re: [HEADSUP][CFT] pkgng beta1 is out X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 17:21:38 -0000 On Mon, Jan 30, 2012 at 9:10 AM, Baptiste Daroussin wrote: No pkg query can't do this, but this would be a nice addition (something > like > raw output for info or query) I do like the idea, please create an issue > on the > github :)) > > regards, Bapt > I just created issue #128, thanks Baptiste! Cheers, Jos -- Jos Backus jos at catnook.com From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 17:30:34 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FBB3106566C for ; Mon, 30 Jan 2012 17:30:34 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by mx1.freebsd.org (Postfix) with ESMTP id 4567B8FC0A for ; Mon, 30 Jan 2012 17:30:34 +0000 (UTC) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta14.emeryville.ca.mail.comcast.net with comcast id TtU11i0050vp7WLAEtWZqC; Mon, 30 Jan 2012 17:30:33 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta05.emeryville.ca.mail.comcast.net with comcast id TtWY1i00m4NgCEG8RtWZue; Mon, 30 Jan 2012 17:30:33 +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 q0UHUVT4019270; Mon, 30 Jan 2012 10:30:31 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Andriy Gapon In-Reply-To: <4F26CC5A.2070501@FreeBSD.org> References: <4F26CC5A.2070501@FreeBSD.org> Content-Type: text/plain Date: Mon, 30 Jan 2012 10:30:31 -0700 Message-Id: <1327944631.1686.24.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: revisiting tunables under Safe Mode menu option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 17:30:34 -0000 On Mon, 2012-01-30 at 18:59 +0200, Andriy Gapon wrote: > > o hw.ata.ata_dma, hw.ata.atapi_dma - I am not sure if there have been any > significant problems with ATA DMA recently. Maybe these could be removed? I still have to work with hardware that requires ata_dma disabled. It seems to be required for most systems I've worked with that have a compact flash socket on the mainboard (sometimes you can just limit the mode to udma33 or less, sometimes you have to turn it off completely.) Adding kern.eventtimer.periodic=1 seems like a good idea. As a general philosophical thing, I don't have a problem with the idea "safe mode turns off everything that has ever historically been problematic," because I don't think anyone expects a system to run well in safe mode. I see it more as a tool to start narrowing down the area of trouble, like step 1 of a binary search for the problem. As such, the most important aspect is a comprehensive list of what changes for safe mode, so that you can procede by selectively en/disabling the various things it does. -- Ian From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 17:33:04 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42798106566B; Mon, 30 Jan 2012 17:33:04 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2749A8FC12; Mon, 30 Jan 2012 17:33:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0UHX42H071265; Mon, 30 Jan 2012 17:33:04 GMT (envelope-from bapt@freebsd.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0UHX3gD071264; Mon, 30 Jan 2012 17:33:03 GMT (envelope-from bapt@freebsd.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@freebsd.org using -f Date: Mon, 30 Jan 2012 18:32:57 +0100 From: Baptiste Daroussin To: Jos Backus Message-ID: <20120130173257.GE40244@azathoth.lan> References: <20120130123930.GB40244@azathoth.lan> <20120130171044.GD40244@azathoth.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+SfteS7bOf3dGlBC" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ports@freebsd.org, current@freebsd.org Subject: Re: [HEADSUP][CFT] pkgng beta1 is out X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 17:33:04 -0000 --+SfteS7bOf3dGlBC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 30, 2012 at 09:21:37AM -0800, Jos Backus wrote: > On Mon, Jan 30, 2012 at 9:10 AM, Baptiste Daroussin wro= te: >=20 > No pkg query can't do this, but this would be a nice addition (something > > like > > raw output for info or query) I do like the idea, please create an issue > > on the > > github :)) > > > > regards, >=20 > Bapt > > >=20 > I just created issue #128, thanks Baptiste! >=20 > Cheers, > Jos The time you did that I implemented it :) pkg info -R will be in beta2. Thank you, regards, Bapt --+SfteS7bOf3dGlBC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk8m1EkACgkQ8kTtMUmk6EzaSgCdGts1R68JDzY6T37QJp+9WuTr XlYAoIIKvyWtq+0tZKVTAIUMiH4nogTY =/gGZ -----END PGP SIGNATURE----- --+SfteS7bOf3dGlBC-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 17:34:15 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E59971065677 for ; Mon, 30 Jan 2012 17:34:15 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id B81198FC25 for ; Mon, 30 Jan 2012 17:34:15 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed; delsp=yes Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LYM00H0GGT3FN00@smtpauth1.wiscmail.wisc.edu>; Mon, 30 Jan 2012 11:34:15 -0600 (CST) Received: from [10.0.2.94] (adsl-76-208-68-223.dsl.mdsnwi.sbcglobal.net [76.208.68.223]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LYM00250GSV7X50@smtpauth1.wiscmail.wisc.edu>; Mon, 30 Jan 2012 11:34:08 -0600 (CST) Date: Mon, 30 Jan 2012 11:34:06 -0600 From: Nathan Whitehorn In-reply-to: <1327944631.1686.24.camel@revolution.hippie.lan> To: Ian Lepore Message-id: <864493F7-CAAA-4363-891D-9E2ACF90827C@freebsd.org> X-Mailer: Apple Mail (2.936) X-Spam-Report: AuthenticatedSender=yes, SenderIP=10.0.2.94 X-Spam-PmxInfo: Server=avs-12, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.1.30.172119, SenderIP=10.0.2.94 References: <4F26CC5A.2070501@FreeBSD.org> <1327944631.1686.24.camel@revolution.hippie.lan> Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: revisiting tunables under Safe Mode menu option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 17:34:16 -0000 On Jan 30, 2012, at 11:30 AM, Ian Lepore wrote: > On Mon, 2012-01-30 at 18:59 +0200, Andriy Gapon wrote: >> >> o hw.ata.ata_dma, hw.ata.atapi_dma - I am not sure if there have >> been any >> significant problems with ATA DMA recently. Maybe these could be >> removed? > > I still have to work with hardware that requires ata_dma disabled. It > seems to be required for most systems I've worked with that have a > compact flash socket on the mainboard (sometimes you can just limit > the > mode to udma33 or less, sometimes you have to turn it off completely.) > > Adding kern.eventtimer.periodic=1 seems like a good idea. > > As a general philosophical thing, I don't have a problem with the idea > "safe mode turns off everything that has ever historically been > problematic," because I don't think anyone expects a system to run > well > in safe mode. I see it more as a tool to start narrowing down the > area > of trouble, like step 1 of a binary search for the problem. As such, > the most important aspect is a comprehensive list of what changes for > safe mode, so that you can procede by selectively en/disabling the > various things it does. I second the point about ATA DMA, but it is worth pointing out that those sysctls don't do anything with ATA_CAM (see http://www.freebsd.org/cgi/query-pr.cgi?pr=164226) . -Nathan From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 17:57:18 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 783C5106566B for ; Mon, 30 Jan 2012 17:57:18 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id 5E0208FC0C for ; Mon, 30 Jan 2012 17:57:18 +0000 (UTC) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta08.emeryville.ca.mail.comcast.net with comcast id Tsdh1i0011wfjNsA8tk82t; Mon, 30 Jan 2012 17:44:08 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta23.emeryville.ca.mail.comcast.net with comcast id Ttk61i00Z4NgCEG8jtk7Pn; Mon, 30 Jan 2012 17:44:07 +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 q0UHi5KG019285; Mon, 30 Jan 2012 10:44:05 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Max Khon In-Reply-To: References: Content-Type: text/plain Date: Mon, 30 Jan 2012 10:44:05 -0700 Message-Id: <1327945445.1686.36.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: FILTER_SCHEDULE_THREAD is not a bit-value X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 17:57:18 -0000 On Mon, 2012-01-30 at 22:50 +0600, Max Khon wrote: > Hello! > > sys/bus.h documents the following semantics for FILTER_SCHEDULE_THREAD: > > /** > * @brief Driver interrupt filter return values > * > * If a driver provides an interrupt filter routine it must return an > * integer consisting of oring together zero or more of the following > ^^^^^^^ > * flags: > * > * FILTER_STRAY - this device did not trigger the interrupt > * FILTER_HANDLED - the interrupt has been fully handled and can be EOId > * FILTER_SCHEDULE_THREAD - the threaded interrupt handler should be > * scheduled to execute > * > * If the driver does not provide a filter, then the interrupt code will > * act is if the filter had returned FILTER_SCHEDULE_THREAD. Note that it > * is illegal to specify any other flag with FILTER_STRAY and that it is > * illegal to not specify either of FILTER_HANDLED or FILTER_SCHEDULE_THREAD > * if FILTER_STRAY is not specified. > */ > #define FILTER_STRAY 0x01 > #define FILTER_HANDLED 0x02 > #define FILTER_SCHEDULE_THREAD 0x04 > > But actually FILTER_SCHEDULE_THREAD is not used as a bit-value (see > kern/kern_intr.c): > > if (!thread) { > if (ret == FILTER_SCHEDULE_THREAD) > thread = 1; > } > > There is at least one in-tree driver that could be broken because of > this (asmc(8), but I found the problem with some other out-of-tree > driver). > This should be "if (ret & FILTER_SCHEDULE_THREAD)" instead. Attached > patch fixes the problem. > > What do you think? > > Max I think returning (FILTER_HANDLED | FILTER_SCHEDULE_THREAD) makes no sense given the definition "the interrupt has been fully handled and can be EOId". If you EOI in the primary interrupt context and then schedule a threaded handler to run as well you're likely to need complex locking between the primary and threaded interrupt handlers and I was under the impression that's just the sort of thing the filter/threaded scheme was designed to avoid. In other words, the part about ORing together values seems to be staking out room for future growth, because the current set of flags and the words about how to use them imply that only one of the current set of values should be returned at once. On the other hand, the words are also self-contradictory, in that they say "oring together zero or more" but then later when saying which flags can be used together it's defined as erronious to return zero. -- Ian From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 17:58:14 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19AAD106564A for ; Mon, 30 Jan 2012 17:58:14 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from m2.gritton.org (gritton.org [64.34.175.71]) by mx1.freebsd.org (Postfix) with ESMTP id CD0B48FC1D for ; Mon, 30 Jan 2012 17:58:13 +0000 (UTC) Received: from guppy.corp.verio.net (fw.oremut02.us.wh.verio.net [198.65.168.24]) (authenticated bits=0) by m2.gritton.org (8.14.4/8.14.4) with ESMTP id q0UHcMNe053517; Mon, 30 Jan 2012 10:38:23 -0700 (MST) (envelope-from jamie@FreeBSD.org) Message-ID: <4F26D588.9050709@FreeBSD.org> Date: Mon, 30 Jan 2012 10:38:16 -0700 From: Jamie Gritton User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120126 Thunderbird/9.0 MIME-Version: 1.0 To: Daniel Shahaf References: <4F22D9FD.10502@p6m7g8.com> <20120128081919.GA6699@lp-shahaf.local> <20120128224740.GA1729@daniel3.local> In-Reply-To: <20120128224740.GA1729@daniel3.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , current@FreeBSD.org, Matt Mullins , "Philip M. Gollucci" , Scott Sanders Subject: Re: jid and jname are numberic by default why? Can we change it ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 17:58:14 -0000 On 01/28/12 15:47, Daniel Shahaf wrote: > P.S. As an aside, the provision in projects/jailconf/'s jail(8) that > it's not possible for 'jail -r' to remove all jails _unless_ the '*' > syntax is used seems unusual to me: I expect 'jail -r foo bar' to remove > those two jails regardless of whether any other jails exist. (Sorry if > this has been discussed already -- it's just an issue I ran across while > examining the jail(8) man page in Jamie's framework.) I think I must have communicated something badly - "jail -r *" is the way to remove all jails without specifying them, but if your only jails are foo and bar, then "jail -r foo bar" will do the trick. - Jamie From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 18:44:26 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6315C1065674 for ; Mon, 30 Jan 2012 18:44:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 231BD8FC13 for ; Mon, 30 Jan 2012 18:44:26 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id B161846B2C; Mon, 30 Jan 2012 13:44:25 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 19A1BB9A3; Mon, 30 Jan 2012 13:44:25 -0500 (EST) From: John Baldwin To: Tijl Coosemans Date: Mon, 30 Jan 2012 09:36:45 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <201201191739.48327.tijl@coosemans.org> <201201251129.22368.jhb@freebsd.org> <201201291608.16741.tijl@coosemans.org> In-Reply-To: <201201291608.16741.tijl@coosemans.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201201300936.45290.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 30 Jan 2012 13:44:25 -0500 (EST) Cc: freebsd-current@freebsd.org Subject: Re: posix_fadvise noreuse disables file caching X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 18:44:26 -0000 On Sunday, January 29, 2012 10:08:10 am Tijl Coosemans wrote: > On Wednesday 25 January 2012 17:29:22 John Baldwin wrote: > > On Friday, January 20, 2012 2:12:13 pm John Baldwin wrote: > >> On Thursday, January 19, 2012 11:39:42 am Tijl Coosemans wrote: > >>> I recently noticed that multimedia/vlc generates a lot of disk IO when > >>> playing media files. For instance, when playing a 320kbps mp3 gstat > >>> reports about 1250kBps (=10000kbps). That's quite a lot of overhead. > >>> > >>> It turns out that vlc sets POSIX_FADV_NOREUSE on the entire file and > >>> reads in chunks of 1028 bytes. FreeBSD implements NOREUSE as if > >>> O_DIRECT was specified during open(2), i.e. it disables all caching. > >>> That means every 1028 byte read turns into a 32KiB read (new default > >>> block size in 9.0) which explains the above numbers. > >>> > >>> I've copied the relevant vlc code below (modules/access/file.c:Open()). > >>> It's interesting to see that on OSX it sets F_NOCACHE which disables > >>> caching too, but combined with F_RDAHEAD there's still read-ahead > >>> caching. > >>> > >>> I don't think POSIX intended for NOREUSE to mean O_DIRECT. It should > >>> still cache data (and even do read-ahead if F_RDAHEAD is specified), > >>> and once data is fetched from the cache, it can be marked WONTNEED. > >> > >> POSIX doesn't specify O_DIRECT, so it's not clear what it asks for. > >> > >>> Is it possible to implement it this way, or if not to just ignore > >>> the NOREUSE hint for now? > >> > >> I think it would be good to improve NOREUSE, though I had sort of > >> assumed that applications using NOREUSE would do their own buffering > >> and read full blocks. We could perhaps reimplement NOREUSE by doing > >> the equivalent of POSIX_FADV_DONTNEED after each read to free buffers > >> and pages after the data is copied out to userland. I also have an > >> XXX about whether or not NOREUSE should still allow read-ahead as it > >> isn't very clear what the right thing to do there is. HP-UX (IIRC) > >> has an fadvise() that lets you specify multiple policies, so you > >> could specify both NOREUSE and SEQUENTIAL for a single region to > >> get read-ahead but still release memory once the data is read once. > > > > So I've came up with this untested patch. It uses > > VOP_ADVISE(FADV_DONTNEED) after read(2) calls to a NOREUSE region, and > > leaves read-ahead caching enabled for NOREUSE. FADV_DONTNEED doesn't > > do any good really for writes (it only flushes clean buffers), so I've > > left write(2) operations as using IO_DIRECT still. Does this sound > > reasonable? I've not yet tested this at all: > > The patch drastically improves vlc, but there's still a tiny overhead. > Without NOREUSE the disk is read in chunks of 128KiB (F_RDAHEAD buffer > size). With NOREUSE there's an extra transfer of 32KiB (block size). This is probably because vlc is not reading on block boundaries, so the noreuse is throwing away partial blocks at the end of a read that then have to be re-read. We could maybe fix this by making FADV_DONTNEED only throw away completely-contained blocks rather than completely-contained pages. However, this will probably result in NOREUSE not actually throwing away anything at all if an app always reads sub-blocksize chunks. We could maybe make the case of vlc work ok in this case though by allowing an extension where you can do 'posix_fadvise(SEQUENTIAL | NOREUSE)', and in this case we could make the VOP_ADVISE(DONTNEED) in read() use an offset of 0 rather than the start of the read request. However, posix_fadvise() really is going to work best if the userland application reads aligned FS blocks. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 17:56:09 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AE09106566B for ; Mon, 30 Jan 2012 17:56:09 +0000 (UTC) (envelope-from danielsh@apache.org) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1.freebsd.org (Postfix) with SMTP id 00F6A8FC15 for ; Mon, 30 Jan 2012 17:56:08 +0000 (UTC) Received: (qmail 71303 invoked by uid 99); 30 Jan 2012 17:56:08 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Jan 2012 17:56:08 +0000 Received: from localhost (HELO daniel3.local) (127.0.0.1) (smtp-auth username danielsh, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Jan 2012 17:56:07 +0000 Date: Mon, 30 Jan 2012 19:55:42 +0200 From: Daniel Shahaf To: Jamie Gritton Message-ID: <20120130175542.GA31505@daniel3.local> References: <4F22D9FD.10502@p6m7g8.com> <20120128081919.GA6699@lp-shahaf.local> <20120128224740.GA1729@daniel3.local> <4F26D588.9050709@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F26D588.9050709@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Mon, 30 Jan 2012 18:45:13 +0000 Cc: "Bjoern A. Zeeb" , current@FreeBSD.org, Matt Mullins , "Philip M. Gollucci" , Scott Sanders Subject: Re: jid and jname are numberic by default why? Can we change it ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 17:56:09 -0000 Jamie Gritton wrote on Mon, Jan 30, 2012 at 10:38:16 -0700: > On 01/28/12 15:47, Daniel Shahaf wrote: > >P.S. As an aside, the provision in projects/jailconf/'s jail(8) that > >it's not possible for 'jail -r' to remove all jails _unless_ the '*' > >syntax is used seems unusual to me: I expect 'jail -r foo bar' to remove > >those two jails regardless of whether any other jails exist. (Sorry if > >this has been discussed already -- it's just an issue I ran across while > >examining the jail(8) man page in Jamie's framework.) > > I think I must have communicated something badly - "jail -r *" is the > way to remove all jails without specifying them, but if your only jails > are foo and bar, then "jail -r foo bar" will do the trick. That sounds absolutely sane; exactly the behaviour I'd expect. The sentence that led me to think otherwise is the second sentence of this excerpt from jail.8@r230776: An argument of .Dq * is a wildcard that will operate on all jails. To prevent errors, this is the only way for .Fl r to remove all jails. Thanks, Daniel P.S. What is the timeframe for the jailconf framework to be included in a release? 9.1, 10.0, ...? > > - Jamie From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 18:51:44 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2507C106567B; Mon, 30 Jan 2012 18:51:44 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E2D948FC1F; Mon, 30 Jan 2012 18:51:43 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q0UIpgbh045046; Mon, 30 Jan 2012 13:51:42 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q0UIpgMF045033; Mon, 30 Jan 2012 18:51:42 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 30 Jan 2012 18:51:42 GMT Message-Id: <201201301851.q0UIpgMF045033@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 18:51:44 -0000 TB --- 2012-01-30 17:49:37 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-30 17:49:37 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-01-30 17:49:37 - cleaning the object tree TB --- 2012-01-30 17:49:45 - cvsupping the source tree TB --- 2012-01-30 17:49:45 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-01-30 17:50:20 - building world TB --- 2012-01-30 17:50:20 - CROSS_BUILD_TESTING=YES TB --- 2012-01-30 17:50:20 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-30 17:50:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-30 17:50:20 - SRCCONF=/dev/null TB --- 2012-01-30 17:50:20 - TARGET=sparc64 TB --- 2012-01-30 17:50:20 - TARGET_ARCH=sparc64 TB --- 2012-01-30 17:50:20 - TZ=UTC TB --- 2012-01-30 17:50:20 - __MAKE_CONF=/dev/null TB --- 2012-01-30 17:50:20 - cd /src TB --- 2012-01-30 17:50:20 - /usr/bin/make -B buildworld >>> World build started on Mon Jan 30 17:50:21 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jan 30 18:46:15 UTC 2012 TB --- 2012-01-30 18:46:15 - generating LINT kernel config TB --- 2012-01-30 18:46:15 - cd /src/sys/sparc64/conf TB --- 2012-01-30 18:46:15 - /usr/bin/make -B LINT TB --- 2012-01-30 18:46:15 - cd /src/sys/sparc64/conf TB --- 2012-01-30 18:46:15 - /usr/sbin/config -m LINT TB --- 2012-01-30 18:46:15 - building LINT kernel TB --- 2012-01-30 18:46:15 - CROSS_BUILD_TESTING=YES TB --- 2012-01-30 18:46:15 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-30 18:46:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-30 18:46:15 - SRCCONF=/dev/null TB --- 2012-01-30 18:46:15 - TARGET=sparc64 TB --- 2012-01-30 18:46:15 - TARGET_ARCH=sparc64 TB --- 2012-01-30 18:46:15 - TZ=UTC TB --- 2012-01-30 18:46:15 - __MAKE_CONF=/dev/null TB --- 2012-01-30 18:46:15 - cd /src TB --- 2012-01-30 18:46:15 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 30 18:46:15 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ixgbe/ixgbe_mbx.c -I/src/sys/dev/ixgbe cc1: warnings being treated as errors /src/sys/dev/ixgbe/ixgbe_mbx.c: In function 'ixgbe_obtain_mbx_lock_pf': /src/sys/dev/ixgbe/ixgbe_mbx.c:629: warning: implicit declaration of function 'IXGBE_PFMAILBOX' /src/sys/dev/ixgbe/ixgbe_mbx.c:629: warning: nested extern declaration of 'IXGBE_PFMAILBOX' [-Wnested-externs] /src/sys/dev/ixgbe/ixgbe_mbx.c: In function 'ixgbe_write_mbx_pf': /src/sys/dev/ixgbe/ixgbe_mbx.c:667: warning: implicit declaration of function 'IXGBE_PFMBMEM' /src/sys/dev/ixgbe/ixgbe_mbx.c:667: warning: nested extern declaration of 'IXGBE_PFMBMEM' [-Wnested-externs] *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-30 18:51:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-30 18:51:42 - ERROR: failed to build LINT kernel TB --- 2012-01-30 18:51:42 - 3062.26 user 569.34 system 3725.59 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 19:18:09 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30EEF106566B for ; Mon, 30 Jan 2012 19:18:09 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from m2.gritton.org (gritton.org [64.34.175.71]) by mx1.freebsd.org (Postfix) with ESMTP id E5DF98FC14 for ; Mon, 30 Jan 2012 19:18:08 +0000 (UTC) Received: from guppy.corp.verio.net (fw.oremut02.us.wh.verio.net [198.65.168.24]) (authenticated bits=0) by m2.gritton.org (8.14.4/8.14.4) with ESMTP id q0UJHctV054358; Mon, 30 Jan 2012 12:17:38 -0700 (MST) (envelope-from jamie@FreeBSD.org) Message-ID: <4F26ECCC.6070408@FreeBSD.org> Date: Mon, 30 Jan 2012 12:17:32 -0700 From: Jamie Gritton User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120126 Thunderbird/9.0 MIME-Version: 1.0 To: Daniel Shahaf References: <4F22D9FD.10502@p6m7g8.com> <20120128081919.GA6699@lp-shahaf.local> <20120128224740.GA1729@daniel3.local> <4F26D588.9050709@FreeBSD.org> <20120130175542.GA31505@daniel3.local> In-Reply-To: <20120130175542.GA31505@daniel3.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , current@FreeBSD.org, Matt Mullins , "Philip M. Gollucci" , Scott Sanders Subject: Re: jid and jname are numberic by default why? Can we change it ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 19:18:09 -0000 On 01/30/12 10:55, Daniel Shahaf wrote: > Jamie Gritton wrote on Mon, Jan 30, 2012 at 10:38:16 -0700: >> On 01/28/12 15:47, Daniel Shahaf wrote: >>> P.S. As an aside, the provision in projects/jailconf/'s jail(8) that >>> it's not possible for 'jail -r' to remove all jails _unless_ the '*' >>> syntax is used seems unusual to me: I expect 'jail -r foo bar' to remove >>> those two jails regardless of whether any other jails exist. (Sorry if >>> this has been discussed already -- it's just an issue I ran across while >>> examining the jail(8) man page in Jamie's framework.) >> >> I think I must have communicated something badly - "jail -r *" is the >> way to remove all jails without specifying them, but if your only jails >> are foo and bar, then "jail -r foo bar" will do the trick. > > That sounds absolutely sane; exactly the behaviour I'd expect. > > The sentence that led me to think otherwise is the second sentence of this > excerpt from jail.8@r230776: > > An argument of > .Dq * > is a wildcard that will operate on all jails. To prevent errors, > this is the only way for > .Fl r > to remove all jails. Yes, I can see what you mean. I'd tell you that sentence obviously mean something else, but at the moment I'm not sure what I meant when I write that :-). > P.S. What is the timeframe for the jailconf framework to be included in > a release? 9.1, 10.0, ...? Yes, those. I had missed the cutoff for 9.0 (and then waited around until 9.0 was actually released), but I'll be putting in it soon. - Jamie From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 19:26:08 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FFA2106566B; Mon, 30 Jan 2012 19:26:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 596A48FC15; Mon, 30 Jan 2012 19:26:07 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q0UJQ7Gs045541; Mon, 30 Jan 2012 14:26:07 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q0UJQ7jA045540; Mon, 30 Jan 2012 19:26:07 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 30 Jan 2012 19:26:07 GMT Message-Id: <201201301926.q0UJQ7jA045540@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 19:26:08 -0000 TB --- 2012-01-30 16:48:46 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-30 16:48:46 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-01-30 16:48:46 - cleaning the object tree TB --- 2012-01-30 16:48:55 - cvsupping the source tree TB --- 2012-01-30 16:48:55 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-01-30 16:49:46 - building world TB --- 2012-01-30 16:49:46 - CROSS_BUILD_TESTING=YES TB --- 2012-01-30 16:49:46 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-30 16:49:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-30 16:49:46 - SRCCONF=/dev/null TB --- 2012-01-30 16:49:46 - TARGET=powerpc TB --- 2012-01-30 16:49:46 - TARGET_ARCH=powerpc64 TB --- 2012-01-30 16:49:46 - TZ=UTC TB --- 2012-01-30 16:49:46 - __MAKE_CONF=/dev/null TB --- 2012-01-30 16:49:46 - cd /src TB --- 2012-01-30 16:49:46 - /usr/bin/make -B buildworld >>> World build started on Mon Jan 30 16:49:46 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Mon Jan 30 19:15:57 UTC 2012 TB --- 2012-01-30 19:15:57 - generating LINT kernel config TB --- 2012-01-30 19:15:57 - cd /src/sys/powerpc/conf TB --- 2012-01-30 19:15:57 - /usr/bin/make -B LINT TB --- 2012-01-30 19:15:57 - cd /src/sys/powerpc/conf TB --- 2012-01-30 19:15:57 - /usr/sbin/config -m LINT TB --- 2012-01-30 19:15:57 - building LINT kernel TB --- 2012-01-30 19:15:57 - CROSS_BUILD_TESTING=YES TB --- 2012-01-30 19:15:57 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-30 19:15:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-30 19:15:57 - SRCCONF=/dev/null TB --- 2012-01-30 19:15:57 - TARGET=powerpc TB --- 2012-01-30 19:15:57 - TARGET_ARCH=powerpc64 TB --- 2012-01-30 19:15:57 - TZ=UTC TB --- 2012-01-30 19:15:57 - __MAKE_CONF=/dev/null TB --- 2012-01-30 19:15:57 - cd /src TB --- 2012-01-30 19:15:57 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 30 19:15:57 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror vnode_if.c :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror vers.c linking kernel mmu_oea64.o:(.got+0x88): undefined reference to `elf32_nxstack' *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-30 19:26:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-30 19:26:07 - ERROR: failed to build LINT kernel TB --- 2012-01-30 19:26:07 - 8055.72 user 1125.13 system 9440.44 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 19:27:34 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82B07106566C for ; Mon, 30 Jan 2012 19:27:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 15A238FC0A for ; Mon, 30 Jan 2012 19:27:33 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q0UJRSlk050688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jan 2012 21:27:28 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q0UJRRkN097983; Mon, 30 Jan 2012 21:27:27 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q0UJRR9V097982; Mon, 30 Jan 2012 21:27:27 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 30 Jan 2012 21:27:27 +0200 From: Kostik Belousov To: Dmitry Mikulin Message-ID: <20120130192727.GZ2726@deviant.kiev.zoral.com.ua> References: <749E238A-A85F-4264-9DEB-BCE1BBD21C9D@juniper.net> <20120125074824.GD2726@deviant.kiev.zoral.com.ua> <4F2094B4.70707@juniper.net> <20120126122326.GT2726@deviant.kiev.zoral.com.ua> <4F22E8FD.6010201@juniper.net> <20120129074843.GL2726@deviant.kiev.zoral.com.ua> <4F26E0D1.8040100@juniper.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0hyMCxJS7FIePeVX" Content-Disposition: inline In-Reply-To: <4F26E0D1.8040100@juniper.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current Current , Marcel Moolenaar Subject: Re: [ptrace] please review follow fork/exec changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 19:27:34 -0000 --0hyMCxJS7FIePeVX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 30, 2012 at 10:26:25AM -0800, Dmitry Mikulin wrote: >=20 >=20 > On 01/28/2012 11:48 PM, Kostik Belousov wrote: > >On Fri, Jan 27, 2012 at 10:12:13AM -0800, Dmitry Mikulin wrote: > >>Attached are 4 separate patches for each somewhat independent portion = of > >>the kernel work related to the follow-fork implementation. > >Ok, as I said, I think that vfork-fork.patch is just wrong. >=20 > Gdb needs to be able to read/write process memory between the time the=20 > child is forked and exec is called (in the vfork case). Without the chang= e=20 > it causes a kernel panic when gdb tries to read/write process memory. Sin= ce=20 > my understanding of the kernel is a bit limited, it was the best I could = do=20 > at the time. I will send more details about the panic once I get a workin= g=20 > fbsd system again. Maybe there's a better way to deal with the panic. Please provide more details, I am looking forward for the panic message and backtrace. >=20 > >Lets postpone discussion of the orphan.patch for later. >=20 > OK. >=20 > > > >The follow-fork.patch and follow-exec.patch make me wonder, and I > >already expressed my doubts. IMO, all features, except one bug, are > >already presented in the stock src. > > > >More, suggested follow-{fork,exec} patches break the SCE/SCX tracers > >notification of fork and exec events, since TDB_FORK and TBD_EXEC flags > >are consumed before syscall returns (I also said this previously). >=20 >=20 >=20 >=20 > > > >Namely, if the process is being debugged, the successfull [f]execve() > >causes unconditional stop even. This makes PT_FOLLOW_EXEC unneccessary. > > > >Existing PT_FOLLOW_FORK implementation indeed has a bug, which was not > >revealed by my testing during the development, because I only tested > >SCE/SCX scenario. Namely, if PT_FOLLOW_FORK is requested, but the next > >stop is not SCX, then follow-fork notification is not sent. After this > >nit is fixed, PT_FOLLOW_FORK caller gets stops for the child creation. > >Child is put into stop state as needed to not loose it. >=20 > I think this will fix only a part of the problem, the one that relates to= =20 > PT_CONTINUE. >=20 > I still need the change that forces a stop in both child and parent on=20 > fork(). Without my changes the notification is generated in the child but= =20 > not in the parent. I need to be able to have both processes stopped in gd= b=20 > in order to clean up and detach from the parent, and initialize and attac= h=20 > to the child. The main reason I need both processes stopped is that gdb h= as=20 > to be able to read/write into both processes address space and registers.= =20 > Ideally I would like to have a single event generated for fork() at a poi= nt=20 > where both child and parent are stopped and available for ptrace read/wri= te=20 > requests. Do you think it's possible? The lack of the notification for parent is exactly what the patch I posted fixes. More exactly, it is the lack of notification for parent with PT_CONTINUE loop. I will commit this today. Regarding a single notification. Currently, parent arrives at the syscall return code only after the child is attached to the debugger. See the cv_wait() in kern_fork.c:739. In other words, if you get the PL_FLAG_FORK, the child is already attached (at last it shall be). My scescx.c code illustrates this well, IMO. You still get a separate stop from the child, but I do not see how is it harmful. --0hyMCxJS7FIePeVX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk8m7x8ACgkQC3+MBN1Mb4ivfQCg5u5En+NVmD/0ZzPNUvv2AvXX C2QAoKM1fcZjqnvhOoXCYrL7wFWPlqDS =MLgx -----END PGP SIGNATURE----- --0hyMCxJS7FIePeVX-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 18:28:14 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AC531065672 for ; Mon, 30 Jan 2012 18:28:14 +0000 (UTC) (envelope-from dmitrym@juniper.net) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by mx1.freebsd.org (Postfix) with ESMTP id E2C8A8FC08 for ; Mon, 30 Jan 2012 18:28:13 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTybhPAcLm8ImVk6YADhapW8HbrNtS2JX@postini.com; Mon, 30 Jan 2012 10:28:13 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 30 Jan 2012 10:26:28 -0800 Received: from [172.24.26.191] (dmitrym-lnx.jnpr.net [172.24.26.191]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q0UIQR149709; Mon, 30 Jan 2012 10:26:27 -0800 (PST) (envelope-from dmitrym@juniper.net) Message-ID: <4F26E0D1.8040100@juniper.net> Date: Mon, 30 Jan 2012 10:26:25 -0800 From: Dmitry Mikulin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Kostik Belousov References: <749E238A-A85F-4264-9DEB-BCE1BBD21C9D@juniper.net> <20120125074824.GD2726@deviant.kiev.zoral.com.ua> <4F2094B4.70707@juniper.net> <20120126122326.GT2726@deviant.kiev.zoral.com.ua> <4F22E8FD.6010201@juniper.net> <20120129074843.GL2726@deviant.kiev.zoral.com.ua> In-Reply-To: <20120129074843.GL2726@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629 X-Mailman-Approved-At: Mon, 30 Jan 2012 19:37:56 +0000 Cc: freebsd-current Current , Marcel Moolenaar Subject: Re: [ptrace] please review follow fork/exec changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 18:28:14 -0000 On 01/28/2012 11:48 PM, Kostik Belousov wrote: > On Fri, Jan 27, 2012 at 10:12:13AM -0800, Dmitry Mikulin wrote: >> Attached are 4 separate patches for each somewhat independent portion of >> the kernel work related to the follow-fork implementation. > Ok, as I said, I think that vfork-fork.patch is just wrong. Gdb needs to be able to read/write process memory between the time the child is forked and exec is called (in the vfork case). Without the change it causes a kernel panic when gdb tries to read/write process memory. Since my understanding of the kernel is a bit limited, it was the best I could do at the time. I will send more details about the panic once I get a working fbsd system again. Maybe there's a better way to deal with the panic. > Lets postpone discussion of the orphan.patch for later. OK. > > The follow-fork.patch and follow-exec.patch make me wonder, and I > already expressed my doubts. IMO, all features, except one bug, are > already presented in the stock src. > > More, suggested follow-{fork,exec} patches break the SCE/SCX tracers > notification of fork and exec events, since TDB_FORK and TBD_EXEC flags > are consumed before syscall returns (I also said this previously). > > Namely, if the process is being debugged, the successfull [f]execve() > causes unconditional stop even. This makes PT_FOLLOW_EXEC unneccessary. > > Existing PT_FOLLOW_FORK implementation indeed has a bug, which was not > revealed by my testing during the development, because I only tested > SCE/SCX scenario. Namely, if PT_FOLLOW_FORK is requested, but the next > stop is not SCX, then follow-fork notification is not sent. After this > nit is fixed, PT_FOLLOW_FORK caller gets stops for the child creation. > Child is put into stop state as needed to not loose it. I think this will fix only a part of the problem, the one that relates to PT_CONTINUE. I still need the change that forces a stop in both child and parent on fork(). Without my changes the notification is generated in the child but not in the parent. I need to be able to have both processes stopped in gdb in order to clean up and detach from the parent, and initialize and attach to the child. The main reason I need both processes stopped is that gdb has to be able to read/write into both processes address space and registers. Ideally I would like to have a single event generated for fork() at a point where both child and parent are stopped and available for ptrace read/write requests. Do you think it's possible? > > I updated the test program I use to test this functionality, see > http://people.freebsd.org/~kib/misc/scescx.c > The default or -s flag causes it to use SCE/SCX tracing, while -c flag > switches it to use PT_CONTINUE tracing, which should be the kind of loop > performed by normal debuggers. You can see the exec/fork events and > child auto-attach illustrated with this test. > > Can you, please, provide the test-case which illustrates the omissions > in the existing API (with the patch below applied), if any ? > > diff --git a/sys/kern/subr_syscall.c b/sys/kern/subr_syscall.c > index bba4479..75328f6 100644 > --- a/sys/kern/subr_syscall.c > +++ b/sys/kern/subr_syscall.c > @@ -212,7 +212,8 @@ syscallret(struct thread *td, int error, struct syscall_args *sa __unused) > * executes. If debugger requested tracing of syscall > * returns, do it now too. > */ > - if (traced&& ((td->td_dbgflags& TDB_EXEC) != 0 || > + if (traced&& > + ((td->td_dbgflags& (TDB_FORK | TDB_EXEC)) != 0 || > (p->p_stops& S_PT_SCX) != 0)) > ptracestop(td, SIGTRAP); > td->td_dbgflags&= ~(TDB_SCX | TDB_EXEC | TDB_FORK); From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 19:57:23 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2711106566B for ; Mon, 30 Jan 2012 19:57:23 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id 8DD5A8FC08 for ; Mon, 30 Jan 2012 19:57:23 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.1.339.1; Mon, 30 Jan 2012 14:57:22 -0500 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id A16EB33C02; Mon, 30 Jan 2012 14:57:22 -0500 (EST) Date: Mon, 30 Jan 2012 14:57:22 -0500 From: Ed Maste To: Message-ID: <20120130195721.GA14612@sandvine.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: [patch] nextboot(8) arbitrary kernel environment X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 19:57:24 -0000 I have a patch to allow nextboot(8) to set arbitrary kernel environment variables (not just the kernel dir and kernel_options). The usage becomes: Usage: nextboot [-e variable=value] [-f] [-k kernel] [-o options] nextboot -D and the new option is documented as: -e variable=value This option adds the provided variable and value to the ker- nel environment. The value is quoted when written to the nextboot configuration. The patch also makes -k an option (no longer mandatory). The patch is at http://people.freebsd.org/~emaste/nextboot.diff . I'll commit it in a few days if no concerns are raised by review or my testing. -Ed From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 20:12:25 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49B44106564A for ; Mon, 30 Jan 2012 20:12:25 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id 2F6F68FC15 for ; Mon, 30 Jan 2012 20:12:24 +0000 (UTC) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta12.emeryville.ca.mail.comcast.net with comcast id Tw341i0031u4NiLACwCQLA; Mon, 30 Jan 2012 20:12:24 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta21.emeryville.ca.mail.comcast.net with comcast id TwCP1i00b4NgCEG8hwCQru; Mon, 30 Jan 2012 20:12:24 +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 q0UKCMYV019395; Mon, 30 Jan 2012 13:12:22 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Ed Maste In-Reply-To: <20120130195721.GA14612@sandvine.com> References: <20120130195721.GA14612@sandvine.com> Content-Type: text/plain Date: Mon, 30 Jan 2012 13:12:21 -0700 Message-Id: <1327954341.1662.2.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: [patch] nextboot(8) arbitrary kernel environment X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 20:12:25 -0000 On Mon, 2012-01-30 at 14:57 -0500, Ed Maste wrote: > I have a patch to allow nextboot(8) to set arbitrary kernel environment > variables (not just the kernel dir and kernel_options). The usage becomes: > > Usage: nextboot [-e variable=value] [-f] [-k kernel] [-o options] > nextboot -D > > and the new option is documented as: > > -e variable=value > This option adds the provided variable and value to the ker- > nel environment. The value is quoted when written to the > nextboot configuration. > > The patch also makes -k an option (no longer mandatory). The patch is at > http://people.freebsd.org/~emaste/nextboot.diff . I'll commit it in a few > days if no concerns are raised by review or my testing. > > -Ed Minor nit: -It is not the most thoroughly tested code. +It is not the most throughly tested code. The original spelling is the correct one. -- Ian From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 20:49:16 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE3B8106564A for ; Mon, 30 Jan 2012 20:49:16 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id 8140A8FC12 for ; Mon, 30 Jan 2012 20:49:16 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.1.339.1; Mon, 30 Jan 2012 15:49:15 -0500 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id AF09033C02; Mon, 30 Jan 2012 15:49:15 -0500 (EST) Date: Mon, 30 Jan 2012 15:49:15 -0500 From: Ed Maste To: Ian Lepore Message-ID: <20120130204915.GA30806@sandvine.com> References: <20120130195721.GA14612@sandvine.com> <1327954341.1662.2.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <1327954341.1662.2.camel@revolution.hippie.lan> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: [patch] nextboot(8) arbitrary kernel environment X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 20:49:16 -0000 On Mon, Jan 30, 2012 at 01:12:21PM -0700, Ian Lepore wrote: > Minor nit: > > -It is not the most thoroughly tested code. > +It is not the most throughly tested code. > > The original spelling is the correct one. Nice catch, and thanks for the review. This came from an accidental revert of r229778, which happened when I moved the change from 8.2 to my HEAD tree. -Ed From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 21:05:58 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3F581065673 for ; Mon, 30 Jan 2012 21:05:58 +0000 (UTC) (envelope-from dmitrym@juniper.net) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by mx1.freebsd.org (Postfix) with ESMTP id 58EE58FC15 for ; Mon, 30 Jan 2012 21:05:58 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTycGNDMoJTyJaESBGK5Yeu+lrfE9TLuK@postini.com; Mon, 30 Jan 2012 13:05:58 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 30 Jan 2012 13:05:22 -0800 Received: from [172.24.26.191] (dmitrym-lnx.jnpr.net [172.24.26.191]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q0UL5M147809; Mon, 30 Jan 2012 13:05:22 -0800 (PST) (envelope-from dmitrym@juniper.net) Message-ID: <4F270610.80505@juniper.net> Date: Mon, 30 Jan 2012 13:05:20 -0800 From: Dmitry Mikulin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Kostik Belousov References: <749E238A-A85F-4264-9DEB-BCE1BBD21C9D@juniper.net> <20120125074824.GD2726@deviant.kiev.zoral.com.ua> <4F2094B4.70707@juniper.net> <20120126122326.GT2726@deviant.kiev.zoral.com.ua> <4F22E8FD.6010201@juniper.net> <20120129074843.GL2726@deviant.kiev.zoral.com.ua> <4F26E0D1.8040100@juniper.net> <20120130192727.GZ2726@deviant.kiev.zoral.com.ua> In-Reply-To: <20120130192727.GZ2726@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629 X-Mailman-Approved-At: Mon, 30 Jan 2012 21:06:43 +0000 Cc: freebsd-current Current , Marcel Moolenaar Subject: Re: [ptrace] please review follow fork/exec changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 21:05:58 -0000 >> Gdb needs to be able to read/write process memory between the time the >> child is forked and exec is called (in the vfork case). Without the change >> it causes a kernel panic when gdb tries to read/write process memory. Since >> my understanding of the kernel is a bit limited, it was the best I could do >> at the time. I will send more details about the panic once I get a working >> fbsd system again. Maybe there's a better way to deal with the panic. > Please provide more details, I am looking forward for the panic > message and backtrace. As soon as I get my FreeBSD box fixed, hopefully tomorrow. > >>> Lets postpone discussion of the orphan.patch for later. >> OK. >> >>> The follow-fork.patch and follow-exec.patch make me wonder, and I >>> already expressed my doubts. IMO, all features, except one bug, are >>> already presented in the stock src. >>> >>> More, suggested follow-{fork,exec} patches break the SCE/SCX tracers >>> notification of fork and exec events, since TDB_FORK and TBD_EXEC flags >>> are consumed before syscall returns (I also said this previously). >> >> >> >>> Namely, if the process is being debugged, the successfull [f]execve() >>> causes unconditional stop even. This makes PT_FOLLOW_EXEC unneccessary. >>> >>> Existing PT_FOLLOW_FORK implementation indeed has a bug, which was not >>> revealed by my testing during the development, because I only tested >>> SCE/SCX scenario. Namely, if PT_FOLLOW_FORK is requested, but the next >>> stop is not SCX, then follow-fork notification is not sent. After this >>> nit is fixed, PT_FOLLOW_FORK caller gets stops for the child creation. >>> Child is put into stop state as needed to not loose it. >> I think this will fix only a part of the problem, the one that relates to >> PT_CONTINUE. >> >> I still need the change that forces a stop in both child and parent on >> fork(). Without my changes the notification is generated in the child but >> not in the parent. I need to be able to have both processes stopped in gdb >> in order to clean up and detach from the parent, and initialize and attach >> to the child. The main reason I need both processes stopped is that gdb has >> to be able to read/write into both processes address space and registers. >> Ideally I would like to have a single event generated for fork() at a point >> where both child and parent are stopped and available for ptrace read/write >> requests. Do you think it's possible? > The lack of the notification for parent is exactly what the patch I > posted fixes. More exactly, it is the lack of notification for parent > with PT_CONTINUE loop. I will commit this today. > > Regarding a single notification. Currently, parent arrives at the > syscall return code only after the child is attached to the debugger. > See the cv_wait() in kern_fork.c:739. In other words, if you get the > PL_FLAG_FORK, the child is already attached (at last it shall be). My > scescx.c code illustrates this well, IMO. OK, I see. I need to verify that it works with gdb and possibly tweak it to match the kernel. > > You still get a separate stop from the child, but I do not see how is it > harmful. It's not harmful as long as gdb can tell that those stops are generated by the fork(). From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 21:41:23 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20C681065670; Mon, 30 Jan 2012 21:41:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D4D728FC08; Mon, 30 Jan 2012 21:41:22 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q0ULfLAK015082; Mon, 30 Jan 2012 16:41:21 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q0ULfLwg015068; Mon, 30 Jan 2012 21:41:21 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 30 Jan 2012 21:41:21 GMT Message-Id: <201201302141.q0ULfLwg015068@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 21:41:23 -0000 TB --- 2012-01-30 19:30:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-30 19:30:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-01-30 19:30:00 - cleaning the object tree TB --- 2012-01-30 19:30:21 - cvsupping the source tree TB --- 2012-01-30 19:30:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-01-30 19:31:13 - building world TB --- 2012-01-30 19:31:13 - CROSS_BUILD_TESTING=YES TB --- 2012-01-30 19:31:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-30 19:31:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-30 19:31:13 - SRCCONF=/dev/null TB --- 2012-01-30 19:31:13 - TARGET=pc98 TB --- 2012-01-30 19:31:13 - TARGET_ARCH=i386 TB --- 2012-01-30 19:31:13 - TZ=UTC TB --- 2012-01-30 19:31:13 - __MAKE_CONF=/dev/null TB --- 2012-01-30 19:31:13 - cd /src TB --- 2012-01-30 19:31:13 - /usr/bin/make -B buildworld >>> World build started on Mon Jan 30 19:31:14 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jan 30 21:34:43 UTC 2012 TB --- 2012-01-30 21:34:43 - generating LINT kernel config TB --- 2012-01-30 21:34:43 - cd /src/sys/pc98/conf TB --- 2012-01-30 21:34:43 - /usr/bin/make -B LINT TB --- 2012-01-30 21:34:43 - cd /src/sys/pc98/conf TB --- 2012-01-30 21:34:43 - /usr/sbin/config -m LINT TB --- 2012-01-30 21:34:43 - building LINT kernel TB --- 2012-01-30 21:34:43 - CROSS_BUILD_TESTING=YES TB --- 2012-01-30 21:34:43 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-30 21:34:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-30 21:34:43 - SRCCONF=/dev/null TB --- 2012-01-30 21:34:43 - TARGET=pc98 TB --- 2012-01-30 21:34:43 - TARGET_ARCH=i386 TB --- 2012-01-30 21:34:43 - TZ=UTC TB --- 2012-01-30 21:34:43 - __MAKE_CONF=/dev/null TB --- 2012-01-30 21:34:43 - cd /src TB --- 2012-01-30 21:34:43 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 30 21:34:43 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ixgb/ixgb_hw.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ixgbe/ixgbe.c -I/src/sys/dev/ixgbe In file included from /src/sys/dev/ixgbe/ixgbe_type.h:38, from /src/sys/dev/ixgbe/ixgbe_api.h:38, from /src/sys/dev/ixgbe/ixgbe.h:96, from /src/sys/dev/ixgbe/ixgbe.c:40: /src/sys/dev/ixgbe/ixgbe_osdep.h:109: error: conflicting types for 'bool' /src/sys/sys/types.h:271: error: previous declaration of 'bool' was here *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-30 21:41:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-30 21:41:21 - ERROR: failed to build LINT kernel TB --- 2012-01-30 21:41:21 - 6419.70 user 950.52 system 7881.06 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 21:43:21 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FE86106566C; Mon, 30 Jan 2012 21:43:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 71BAB8FC18; Mon, 30 Jan 2012 21:43:21 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q0ULhKNf037862; Mon, 30 Jan 2012 16:43:20 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q0ULhK6l037848; Mon, 30 Jan 2012 21:43:20 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 30 Jan 2012 21:43:20 GMT Message-Id: <201201302143.q0ULhK6l037848@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 21:43:21 -0000 TB --- 2012-01-30 19:30:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-30 19:30:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-01-30 19:30:00 - cleaning the object tree TB --- 2012-01-30 19:30:46 - cvsupping the source tree TB --- 2012-01-30 19:30:46 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-01-30 19:31:13 - building world TB --- 2012-01-30 19:31:13 - CROSS_BUILD_TESTING=YES TB --- 2012-01-30 19:31:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-30 19:31:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-30 19:31:13 - SRCCONF=/dev/null TB --- 2012-01-30 19:31:13 - TARGET=i386 TB --- 2012-01-30 19:31:13 - TARGET_ARCH=i386 TB --- 2012-01-30 19:31:13 - TZ=UTC TB --- 2012-01-30 19:31:13 - __MAKE_CONF=/dev/null TB --- 2012-01-30 19:31:13 - cd /src TB --- 2012-01-30 19:31:13 - /usr/bin/make -B buildworld >>> World build started on Mon Jan 30 19:31:14 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jan 30 21:35:09 UTC 2012 TB --- 2012-01-30 21:35:09 - generating LINT kernel config TB --- 2012-01-30 21:35:09 - cd /src/sys/i386/conf TB --- 2012-01-30 21:35:09 - /usr/bin/make -B LINT TB --- 2012-01-30 21:35:10 - cd /src/sys/i386/conf TB --- 2012-01-30 21:35:10 - /usr/sbin/config -m LINT TB --- 2012-01-30 21:35:10 - building LINT kernel TB --- 2012-01-30 21:35:10 - CROSS_BUILD_TESTING=YES TB --- 2012-01-30 21:35:10 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-30 21:35:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-30 21:35:10 - SRCCONF=/dev/null TB --- 2012-01-30 21:35:10 - TARGET=i386 TB --- 2012-01-30 21:35:10 - TARGET_ARCH=i386 TB --- 2012-01-30 21:35:10 - TZ=UTC TB --- 2012-01-30 21:35:10 - __MAKE_CONF=/dev/null TB --- 2012-01-30 21:35:10 - cd /src TB --- 2012-01-30 21:35:10 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 30 21:35:10 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ixgb/ixgb_hw.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ixgbe/ixgbe.c -I/src/sys/dev/ixgbe In file included from /src/sys/dev/ixgbe/ixgbe_type.h:38, from /src/sys/dev/ixgbe/ixgbe_api.h:38, from /src/sys/dev/ixgbe/ixgbe.h:96, from /src/sys/dev/ixgbe/ixgbe.c:40: /src/sys/dev/ixgbe/ixgbe_osdep.h:109: error: conflicting types for 'bool' /src/sys/sys/types.h:271: error: previous declaration of 'bool' was here *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-30 21:43:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-30 21:43:20 - ERROR: failed to build LINT kernel TB --- 2012-01-30 21:43:20 - 6537.62 user 950.54 system 8000.41 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 22:20:02 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6034106564A; Mon, 30 Jan 2012 22:20:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A20CE8FC08; Mon, 30 Jan 2012 22:20:01 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q0UMK0Ul083411; Mon, 30 Jan 2012 17:20:00 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q0UMK0Hf083410; Mon, 30 Jan 2012 22:20:00 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 30 Jan 2012 22:20:00 GMT Message-Id: <201201302220.q0UMK0Hf083410@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 22:20:03 -0000 TB --- 2012-01-30 19:30:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-30 19:30:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-01-30 19:30:00 - cleaning the object tree TB --- 2012-01-30 19:30:49 - cvsupping the source tree TB --- 2012-01-30 19:30:49 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2012-01-30 19:36:14 - building world TB --- 2012-01-30 19:36:14 - CROSS_BUILD_TESTING=YES TB --- 2012-01-30 19:36:14 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-30 19:36:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-30 19:36:14 - SRCCONF=/dev/null TB --- 2012-01-30 19:36:14 - TARGET=amd64 TB --- 2012-01-30 19:36:14 - TARGET_ARCH=amd64 TB --- 2012-01-30 19:36:14 - TZ=UTC TB --- 2012-01-30 19:36:14 - __MAKE_CONF=/dev/null TB --- 2012-01-30 19:36:14 - cd /src TB --- 2012-01-30 19:36:14 - /usr/bin/make -B buildworld >>> World build started on Mon Jan 30 19:36:14 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Mon Jan 30 22:11:57 UTC 2012 TB --- 2012-01-30 22:11:57 - generating LINT kernel config TB --- 2012-01-30 22:11:57 - cd /src/sys/amd64/conf TB --- 2012-01-30 22:11:57 - /usr/bin/make -B LINT TB --- 2012-01-30 22:11:57 - cd /src/sys/amd64/conf TB --- 2012-01-30 22:11:57 - /usr/sbin/config -m LINT TB --- 2012-01-30 22:11:57 - building LINT kernel TB --- 2012-01-30 22:11:57 - CROSS_BUILD_TESTING=YES TB --- 2012-01-30 22:11:57 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-30 22:11:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-30 22:11:57 - SRCCONF=/dev/null TB --- 2012-01-30 22:11:57 - TARGET=amd64 TB --- 2012-01-30 22:11:57 - TARGET_ARCH=amd64 TB --- 2012-01-30 22:11:57 - TZ=UTC TB --- 2012-01-30 22:11:57 - __MAKE_CONF=/dev/null TB --- 2012-01-30 22:11:57 - cd /src TB --- 2012-01-30 22:11:57 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 30 22:11:57 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ixgb/ixgb_hw.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ixgbe/ixgbe.c -I/src/sys/dev/ixgbe In file included from /src/sys/dev/ixgbe/ixgbe_type.h:38, from /src/sys/dev/ixgbe/ixgbe_api.h:38, from /src/sys/dev/ixgbe/ixgbe.h:96, from /src/sys/dev/ixgbe/ixgbe.c:40: /src/sys/dev/ixgbe/ixgbe_osdep.h:109: error: conflicting types for 'bool' /src/sys/sys/types.h:271: error: previous declaration of 'bool' was here *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-30 22:20:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-30 22:20:00 - ERROR: failed to build LINT kernel TB --- 2012-01-30 22:20:00 - 7893.79 user 1277.53 system 10200.29 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 22:32:09 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CED631065670 for ; Mon, 30 Jan 2012 22:32:09 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9A5B08FC14 for ; Mon, 30 Jan 2012 22:32:09 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 68BE06104; Mon, 30 Jan 2012 17:32:08 -0500 (EST) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=Arfm/j250IJ8Y63A8KQKBn+aDQzLVrQz1zg6IDtiYeliaCuZcnbKg/iC2IxBTo88q f6izgZlIEWhVRKbKuB9/Y3gbOBLSPWwHtZ3RclZZ5tUSwOudh6AZ+PKc9arnBiU Message-ID: <4F271A66.6060601@protected-networks.net> Date: Mon, 30 Jan 2012 17:32:06 -0500 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:9.0) Gecko/20111223 Thunderbird/9.0 MIME-Version: 1.0 To: pyunyh@gmail.com References: <4F174C4F.2010302@protected-networks.net> <20120119005457.GE7469@michelle.cdnetworks.com> <4F176B76.5010809@protected-networks.net> <20120119015258.GF7469@michelle.cdnetworks.com> In-Reply-To: <20120119015258.GF7469@michelle.cdnetworks.com> X-Enigmail-Version: 1.3.5 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Intermittent re0 phy failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 22:32:09 -0000 On 01/18/12 20:52, YongHyeon PYUN wrote: > On Wed, Jan 18, 2012 at 08:01:42PM -0500, Michael Butler wrote: >> On 01/18/12 19:54, YongHyeon PYUN wrote: >>> On Wed, Jan 18, 2012 at 05:48:47PM -0500, Michael Butler wrote: >>>> At random intervals, when re0 is without any significant load; idle for >>>> lengthy periods, I see .. >>>> >>>> kernel: re0: PHY read failed >>>> last message repeated 4 times >>>> kernel: re0: link state changed to DOWN >>>> >>>> Unplugging the cable and re-inserting is sufficient to restore >>>> functionality. [ .. snip .. ] > > Thanks a lot. > Would you try attached patch? Since applying this (for 8168D) and the patch at SVN r230336 (which affected another system of mine), neither system has "gone deaf", Thanks! imb From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 22:35:01 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F4EA106566B; Mon, 30 Jan 2012 22:35:01 +0000 (UTC) (envelope-from yuri.pankov@gmail.com) Received: from sirius.xvoid.org (sirius.xvoid.org [IPv6:2001:470:28:4ba:20c:29ff:fe62:9a22]) by mx1.freebsd.org (Postfix) with ESMTP id 1FD548FC0C; Mon, 30 Jan 2012 22:35:00 +0000 (UTC) Received: from sirius.xvoid.org (yuri@sirius.xvoid.org [IPv6:::1]) by sirius.xvoid.org (8.14.5/8.14.5) with ESMTP id q0UMYxhq094819; Tue, 31 Jan 2012 02:34:59 +0400 (MSK) (envelope-from yuri.pankov@gmail.com) Received: (from yuri@localhost) by sirius.xvoid.org (8.14.5/8.14.5/Submit) id q0UMYxia094818; Tue, 31 Jan 2012 02:34:59 +0400 (MSK) (envelope-from yuri.pankov@gmail.com) X-Authentication-Warning: sirius.xvoid.org: yuri set sender to yuri.pankov@gmail.com using -f Date: Tue, 31 Jan 2012 02:34:59 +0400 From: Yuri Pankov To: Baptiste Daroussin Message-ID: <20120130223459.GA4707@sirius.xvoid.org> References: <20120130123930.GB40244@azathoth.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline In-Reply-To: <20120130123930.GB40244@azathoth.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ports@freebsd.org, current@freebsd.org Subject: Re: [HEADSUP][CFT] pkgng beta1 is out X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 22:35:01 -0000 --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 30, 2012 at 01:39:30PM +0100, Baptiste Daroussin wrote: [...]=20 > to use pkgng: >=20 > echo WITH_PKGNG=3Dyes >> /etc/make.conf > make -C /usr/ports/ports-mgmt/pkg install clean >=20 > Some links:=20 > http://wiki.FreeBSD.org/pkgng > http://github.com/pkgng/pkgng >=20 > Note that on github you can find a patch for portmaster (against 3.10) The patch seems to have typos in it (usr_pkgng): https://github.com/pkgng/pkgng/blob/master/ports/portmaster.patch#L514 https://github.com/pkgng/pkgng/blob/master/ports/portmaster.patch#L528 And most stupid question for today - how do I actually tell portmaster to use pkgng after applying the patch? Thanks, Yuri --Kj7319i9nmIyA2yE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQIcBAABAgAGBQJPJxsTAAoJEF9SuVmZPGsqEqUQALrj2OGjruYGCOM95ZbYen27 8MRqhaGdbAoAFHMRkvs04OlmzZnb5qf27t1yiPeiTpD3cp/AYY3OIdjHfvqVIvtp qkg5zUeUgeyNDx56R9EzxXCQc0CjZyExuHJqg99ksqzARPz3+i2WTSDDpWPVoeFW wnpDvxhhO37rUyTJ/3t0UJD+RKEyCzl9K21EqdBZsObNRfKbbuxXgmw4xk9P2Svm 3ejdPF3hvCVNzm7+8x3Gux3IgGy9tkSYQGS0P4V9Dtc5cnPPOkQlzsNux1AbEi+X CsiQsWbYyt7QQovJf/12xvUf0UTGIeDJxL0m3BR63PLhdZM8I/d1EBroydsbmU3G AP4VzeKLma83K0Lvc3WiYuR3hentctd4/4uJzCBy1EEod5hXC3KT20TPqFpk8RBs +iOFVdxcuu8REMBtIylZy1FKfWFWfsHkz/BwdiPvWOMl5/4jL9emYtS+PgV0MVl0 qbj5ElQCCBSMud4b8zVTffu7aDSZYKs2TGM7SD287L0JMVxw5q5nmZTGWZtbf9hy fNHZ6g3LdUn06Sn/FItnvPl/bFJnqNQAddNuqcWgb7ltxbM3XK54Qj5YtsMXRl2F MTNVDk3tjtRZ21U8eFW52t+514H1pmKXsK/B5wpdXR+iHS9c6bHgPGLcSBzpeSvw xYt5Av/YWOyaxGqW2Gnf =2NlJ -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 22:35:46 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 945771065675; Mon, 30 Jan 2012 22:35:46 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id EDC0D8FC12; Mon, 30 Jan 2012 22:35:45 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so5696936wib.13 for ; Mon, 30 Jan 2012 14:35:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=hpJKovzQTaA/W8KfTXcuf2S06F8EkAuqWkzGQWk5bnc=; b=W3xMLb8LEviXSGU++LXf366sOgu3x6ZVtaez8VvtnpIaGIIOkMTNd6EUgTqiJmFBn6 8KH1kj2QrBQlhUV/DtT8d/lXkIsfbt2NEQyhx//iHEutGP0jitwPoO2YXatcgUuifOma AryH5ZKIGnRW19+O1wMNTyKIV1Fz3DVQbTMQ8= MIME-Version: 1.0 Received: by 10.180.92.71 with SMTP id ck7mr38465713wib.3.1327961427414; Mon, 30 Jan 2012 14:10:27 -0800 (PST) Received: by 10.180.75.137 with HTTP; Mon, 30 Jan 2012 14:10:27 -0800 (PST) In-Reply-To: <201201301851.q0UIpgMF045033@freebsd-current.sentex.ca> References: <201201301851.q0UIpgMF045033@freebsd-current.sentex.ca> Date: Mon, 30 Jan 2012 14:10:27 -0800 Message-ID: From: Jack Vogel To: current@freebsd.org, sparc64@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 22:35:46 -0000 Someone with sparc build experience want to look at this and maybe see something I'm missing, this error makes no sense to me, these are defined in ixgbe_type.h and I see nothing architecture sensitive?? Jack On Mon, Jan 30, 2012 at 10:51 AM, FreeBSD Tinderbox wrote: > TB --- 2012-01-30 17:49:37 - tinderbox 2.8 running on > freebsd-current.sentex.ca > TB --- 2012-01-30 17:49:37 - starting HEAD tinderbox run for > sparc64/sparc64 > TB --- 2012-01-30 17:49:37 - cleaning the object tree > TB --- 2012-01-30 17:49:45 - cvsupping the source tree > TB --- 2012-01-30 17:49:45 - /usr/bin/csup -z -r 3 -g -L 1 -h > cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile > TB --- 2012-01-30 17:50:20 - building world > TB --- 2012-01-30 17:50:20 - CROSS_BUILD_TESTING=YES > TB --- 2012-01-30 17:50:20 - MAKEOBJDIRPREFIX=/obj > TB --- 2012-01-30 17:50:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2012-01-30 17:50:20 - SRCCONF=/dev/null > TB --- 2012-01-30 17:50:20 - TARGET=sparc64 > TB --- 2012-01-30 17:50:20 - TARGET_ARCH=sparc64 > TB --- 2012-01-30 17:50:20 - TZ=UTC > TB --- 2012-01-30 17:50:20 - __MAKE_CONF=/dev/null > TB --- 2012-01-30 17:50:20 - cd /src > TB --- 2012-01-30 17:50:20 - /usr/bin/make -B buildworld > >>> World build started on Mon Jan 30 17:50:21 UTC 2012 > >>> Rebuilding the temporary build tree > >>> stage 1.1: legacy release compatibility shims > >>> stage 1.2: bootstrap tools > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3: cross tools > >>> stage 4.1: building includes > >>> stage 4.2: building libraries > >>> stage 4.3: make dependencies > >>> stage 4.4: building everything > >>> World build completed on Mon Jan 30 18:46:15 UTC 2012 > TB --- 2012-01-30 18:46:15 - generating LINT kernel config > TB --- 2012-01-30 18:46:15 - cd /src/sys/sparc64/conf > TB --- 2012-01-30 18:46:15 - /usr/bin/make -B LINT > TB --- 2012-01-30 18:46:15 - cd /src/sys/sparc64/conf > TB --- 2012-01-30 18:46:15 - /usr/sbin/config -m LINT > TB --- 2012-01-30 18:46:15 - building LINT kernel > TB --- 2012-01-30 18:46:15 - CROSS_BUILD_TESTING=YES > TB --- 2012-01-30 18:46:15 - MAKEOBJDIRPREFIX=/obj > TB --- 2012-01-30 18:46:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2012-01-30 18:46:15 - SRCCONF=/dev/null > TB --- 2012-01-30 18:46:15 - TARGET=sparc64 > TB --- 2012-01-30 18:46:15 - TARGET_ARCH=sparc64 > TB --- 2012-01-30 18:46:15 - TZ=UTC > TB --- 2012-01-30 18:46:15 - __MAKE_CONF=/dev/null > TB --- 2012-01-30 18:46:15 - cd /src > TB --- 2012-01-30 18:46:15 - /usr/bin/make -B buildkernel KERNCONF=LINT > >>> Kernel build for LINT started on Mon Jan 30 18:46:15 UTC 2012 > >>> stage 1: configuring the kernel > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3.1: making dependencies > >>> stage 3.2: building everything > [...] > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions > -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. > -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > -include opt_global.h -fno-common -finline-limit=15000 --param > inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin > -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror > /src/sys/dev/ixgbe/ixgbe_mbx.c -I/src/sys/dev/ixgbe > cc1: warnings being treated as errors > /src/sys/dev/ixgbe/ixgbe_mbx.c: In function 'ixgbe_obtain_mbx_lock_pf': > /src/sys/dev/ixgbe/ixgbe_mbx.c:629: warning: implicit declaration of > function 'IXGBE_PFMAILBOX' > /src/sys/dev/ixgbe/ixgbe_mbx.c:629: warning: nested extern declaration of > 'IXGBE_PFMAILBOX' [-Wnested-externs] > /src/sys/dev/ixgbe/ixgbe_mbx.c: In function 'ixgbe_write_mbx_pf': > /src/sys/dev/ixgbe/ixgbe_mbx.c:667: warning: implicit declaration of > function 'IXGBE_PFMBMEM' > /src/sys/dev/ixgbe/ixgbe_mbx.c:667: warning: nested extern declaration of > 'IXGBE_PFMBMEM' [-Wnested-externs] > *** Error code 1 > > Stop in /obj/sparc64.sparc64/src/sys/LINT. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2012-01-30 18:51:42 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2012-01-30 18:51:42 - ERROR: failed to build LINT kernel > TB --- 2012-01-30 18:51:42 - 3062.26 user 569.34 system 3725.59 real > > > http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 22:55:58 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3441F10656A4 for ; Mon, 30 Jan 2012 22:55:58 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id C8B1D8FC0A for ; Mon, 30 Jan 2012 22:55:56 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1Rs08h-0006FS-Kz>; Mon, 30 Jan 2012 23:55:55 +0100 Received: from e178033054.adsl.alicedsl.de ([85.178.33.54] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1Rs08h-0007T8-Fj>; Mon, 30 Jan 2012 23:55:55 +0100 Message-ID: <4F271FF4.9010103@zedat.fu-berlin.de> Date: Mon, 30 Jan 2012 23:55:48 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120119 Thunderbird/9.0 MIME-Version: 1.0 To: Current FreeBSD X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig69307480CA2193C2ACBDBBE9" X-Originating-IP: 85.178.33.54 Subject: FreeBSD 10-CURRENT/amd64: revision 230789: usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe_osdep.h:109:19: error: typedef redefinition with different types ('boolean_t' (aka 'int') vs '_Bool'),typedef boolean_t bool;, ^,@/sys/types.h:271:15: note: previous definition is here,typedef _Bool bool; X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 22:55:58 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig69307480CA2193C2ACBDBBE9 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable The follwoing error occurs hwen trying to compile a kernel (make buildworld works fine): objcopy --strip-debug if_ixgb.ko =3D=3D=3D> ixgbe (all) clang -O2 -pipe -O2 -fno-strict-aliasing -pipe -pipe -O3 -fno-strict-aliasing -march=3Dnative -DSMP -DIXGBE_FDIR -D_KERNEL -DKLD_MODULE -nostdinc -I/usr/src/sys/modules/ixgbe/../../dev/ixgbe -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/THOR/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/THOR -mno-aes -mno-avx -mcmodel=3Dkernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c In file included from /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c:= 40: In file included from /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.h:= 96: In file included from /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe_api.h:38: In file included from /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe_type.h:38: /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe_osdep.h:109:19: error: typedef redefinition with different types ('boolean_t' (aka 'int') vs '_Bool') typedef boolean_t bool; ^ @/sys/types.h:271:15: note: previous definition is here typedef _Bool bool; ^ 1 error generated. *** Error code 1 Stop in /usr/src/sys/modules/ixgbe. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/THOR. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. --------------enig69307480CA2193C2ACBDBBE9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBAgAGBQJPJx/6AAoJEOgBcD7A/5N8OCwH/i/jlTXxB5MNEr83dv7mTvr1 U0ikpflv/bCaKTSu6B4QM8yhxKYTCxTDhTuw7CezAPaWAwE/D8xhol+trvAVcC0w +YjFRh8KEtZHf1iL8U1M1A3XFsNUhNBu8XGSLLppuQ+LmybLIcu89+HDZ6mR75VQ 2aReJ7Zr9DuTeJDexUYpFs+okrE5DXwckwWZ+90dCSROjZ7DF8hywSkia2KNlpJo aTh54Are3oIQv86o2aczdAAN9hyNyr9IxyTnDHoMyKb4eidGPbasBaLGfz4P36o8 y4q1fV3AXXKvqIQFuOX6hgA7CQrEuY5tfQMetjMsobHzhRTy+xqyqx9QxX/HXVk= =6xvb -----END PGP SIGNATURE----- --------------enig69307480CA2193C2ACBDBBE9-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 23:06:29 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED48B1065672; Mon, 30 Jan 2012 23:06:29 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id BBFF18FC12; Mon, 30 Jan 2012 23:06:29 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q0UN6Slg036442; Mon, 30 Jan 2012 18:06:28 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q0UN6S6R036431; Mon, 30 Jan 2012 23:06:28 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 30 Jan 2012 23:06:28 GMT Message-Id: <201201302306.q0UN6S6R036431@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 23:06:30 -0000 TB --- 2012-01-30 21:30:51 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-30 21:30:51 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-01-30 21:30:51 - cleaning the object tree TB --- 2012-01-30 21:30:58 - cvsupping the source tree TB --- 2012-01-30 21:30:58 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2012-01-30 21:31:53 - building world TB --- 2012-01-30 21:31:53 - CROSS_BUILD_TESTING=YES TB --- 2012-01-30 21:31:53 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-30 21:31:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-30 21:31:53 - SRCCONF=/dev/null TB --- 2012-01-30 21:31:53 - TARGET=ia64 TB --- 2012-01-30 21:31:53 - TARGET_ARCH=ia64 TB --- 2012-01-30 21:31:53 - TZ=UTC TB --- 2012-01-30 21:31:53 - __MAKE_CONF=/dev/null TB --- 2012-01-30 21:31:53 - cd /src TB --- 2012-01-30 21:31:53 - /usr/bin/make -B buildworld >>> World build started on Mon Jan 30 21:31:53 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jan 30 22:57:59 UTC 2012 TB --- 2012-01-30 22:57:59 - generating LINT kernel config TB --- 2012-01-30 22:57:59 - cd /src/sys/ia64/conf TB --- 2012-01-30 22:57:59 - /usr/bin/make -B LINT TB --- 2012-01-30 22:57:59 - cd /src/sys/ia64/conf TB --- 2012-01-30 22:57:59 - /usr/sbin/config -m LINT TB --- 2012-01-30 22:57:59 - building LINT kernel TB --- 2012-01-30 22:57:59 - CROSS_BUILD_TESTING=YES TB --- 2012-01-30 22:57:59 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-30 22:57:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-30 22:57:59 - SRCCONF=/dev/null TB --- 2012-01-30 22:57:59 - TARGET=ia64 TB --- 2012-01-30 22:57:59 - TARGET_ARCH=ia64 TB --- 2012-01-30 22:57:59 - TZ=UTC TB --- 2012-01-30 22:57:59 - __MAKE_CONF=/dev/null TB --- 2012-01-30 22:57:59 - cd /src TB --- 2012-01-30 22:57:59 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 30 22:57:59 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ixgb/ixgb_hw.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ixgbe/ixgbe.c -I/src/sys/dev/ixgbe In file included from /src/sys/dev/ixgbe/ixgbe_type.h:38, from /src/sys/dev/ixgbe/ixgbe_api.h:38, from /src/sys/dev/ixgbe/ixgbe.h:96, from /src/sys/dev/ixgbe/ixgbe.c:40: /src/sys/dev/ixgbe/ixgbe_osdep.h:109: error: conflicting types for 'bool' /src/sys/sys/types.h:271: error: previous declaration of 'bool' was here *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-30 23:06:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-30 23:06:28 - ERROR: failed to build LINT kernel TB --- 2012-01-30 23:06:28 - 4599.01 user 741.24 system 5736.93 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 23:11:27 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1E89106566C for ; Mon, 30 Jan 2012 23:11:27 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from glenbarber.us (onyx.glenbarber.us [199.48.134.227]) by mx1.freebsd.org (Postfix) with SMTP id 98B088FC0A for ; Mon, 30 Jan 2012 23:11:27 +0000 (UTC) Received: (qmail 57682 invoked by uid 0); 30 Jan 2012 18:11:26 -0500 Received: from unknown (HELO glenbarber.us) (75.146.225.65) by 0 with SMTP; 30 Jan 2012 18:11:26 -0500 Date: Mon, 30 Jan 2012 18:11:25 -0500 From: Glen Barber To: "O. Hartmann" Message-ID: <20120130231125.GC2315@glenbarber.us> References: <4F271FF4.9010103@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F271FF4.9010103@zedat.fu-berlin.de> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Current FreeBSD Subject: Re: FreeBSD 10-CURRENT/amd64: revision 230789: [...] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 23:11:27 -0000 On Mon, Jan 30, 2012 at 11:55:48PM +0100, O. Hartmann wrote: > The follwoing error occurs hwen trying to compile a kernel (make > buildworld works fine): > > objcopy --strip-debug if_ixgb.ko > ===> ixgbe (all) > clang -O2 -pipe -O2 -fno-strict-aliasing -pipe -pipe -O3 > -fno-strict-aliasing -march=native -DSMP -DIXGBE_FDIR -D_KERNEL > -DKLD_MODULE -nostdinc -I/usr/src/sys/modules/ixgbe/../../dev/ixgbe > -DHAVE_KERNEL_OPTION_HEADERS -include > /usr/obj/usr/src/sys/THOR/opt_global.h -I. -I@ -I@/contrib/altq > -fno-common -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/THOR > -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector > -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign > -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option > -Wno-error-tautological-compare -Wno-error-empty-body > -Wno-error-parentheses-equality -c > /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c > In file included from /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c:40: > In file included from /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.h:96: > In file included from > /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe_api.h:38: > In file included from > /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe_type.h:38: > /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe_osdep.h:109:19: error: > typedef redefinition with different types ('boolean_t' (aka 'int') vs > '_Bool') > typedef boolean_t bool; > ^ > @/sys/types.h:271:15: note: previous definition is here > typedef _Bool bool; > ^ > 1 error generated. > *** Error code 1 > > Stop in /usr/src/sys/modules/ixgbe. > *** Error code 1 > > Stop in /usr/src/sys/modules. > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/THOR. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > I believe this was just fixed: http://svn.freebsd.org/changeset/base/230790 Glen From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 23:39:13 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9ED6C106566B; Mon, 30 Jan 2012 23:39:13 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0B2B48FC08; Mon, 30 Jan 2012 23:39:12 +0000 (UTC) Received: by wgbdr11 with SMTP id dr11so5118235wgb.31 for ; Mon, 30 Jan 2012 15:39:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=M2EG4zaj4R0dSEhK1cSwj9nyys4I5x382YV2ZMyGrzY=; b=w5PCgMYV8Dt+tinzAnxsA+tUn6IHvED2/qhHLbhNCDFgSE1UlklyVA07xpl9CqJFgG rmrDc0HZIIGi4iOcH5IzEooZRtgT5rIrz2pksUOH4zBmzsWSXnkIpszHe/w3LaTlXwLt NWrlQiOcOW5dD7FVvCYxwcJcAHJDRLtl6ARbc= MIME-Version: 1.0 Received: by 10.180.103.132 with SMTP id fw4mr23353983wib.3.1327965263532; Mon, 30 Jan 2012 15:14:23 -0800 (PST) Received: by 10.180.75.137 with HTTP; Mon, 30 Jan 2012 15:14:23 -0800 (PST) In-Reply-To: <20120130231125.GC2315@glenbarber.us> References: <4F271FF4.9010103@zedat.fu-berlin.de> <20120130231125.GC2315@glenbarber.us> Date: Mon, 30 Jan 2012 15:14:23 -0800 Message-ID: From: Jack Vogel To: Glen Barber Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Current FreeBSD , "O. Hartmann" Subject: Re: FreeBSD 10-CURRENT/amd64: revision 230789: [...] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 23:39:13 -0000 Yes, it was. Now if I can just figure out what's going on with sparc.... Jack On Mon, Jan 30, 2012 at 3:11 PM, Glen Barber wrote: > On Mon, Jan 30, 2012 at 11:55:48PM +0100, O. Hartmann wrote: > > The follwoing error occurs hwen trying to compile a kernel (make > > buildworld works fine): > > > > objcopy --strip-debug if_ixgb.ko > > ===> ixgbe (all) > > clang -O2 -pipe -O2 -fno-strict-aliasing -pipe -pipe -O3 > > -fno-strict-aliasing -march=native -DSMP -DIXGBE_FDIR -D_KERNEL > > -DKLD_MODULE -nostdinc -I/usr/src/sys/modules/ixgbe/../../dev/ixgbe > > -DHAVE_KERNEL_OPTION_HEADERS -include > > /usr/obj/usr/src/sys/THOR/opt_global.h -I. -I@ -I@/contrib/altq > > -fno-common -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/THOR > > -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float > > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector > > -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls > > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > > -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign > > -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option > > -Wno-error-tautological-compare -Wno-error-empty-body > > -Wno-error-parentheses-equality -c > > /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c > > In file included from > /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c:40: > > In file included from > /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.h:96: > > In file included from > > /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe_api.h:38: > > In file included from > > /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe_type.h:38: > > /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe_osdep.h:109:19: error: > > typedef redefinition with different types ('boolean_t' (aka 'int') vs > > '_Bool') > > typedef boolean_t bool; > > ^ > > @/sys/types.h:271:15: note: previous definition is here > > typedef _Bool bool; > > ^ > > 1 error generated. > > *** Error code 1 > > > > Stop in /usr/src/sys/modules/ixgbe. > > *** Error code 1 > > > > Stop in /usr/src/sys/modules. > > *** Error code 1 > > > > Stop in /usr/obj/usr/src/sys/THOR. > > *** Error code 1 > > > > Stop in /usr/src. > > *** Error code 1 > > > > Stop in /usr/src. > > > > I believe this was just fixed: > > http://svn.freebsd.org/changeset/base/230790 > > Glen > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 23:43:25 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB085106564A; Mon, 30 Jan 2012 23:43:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A415A8FC13; Mon, 30 Jan 2012 23:43:24 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q0UNhN3p093930; Mon, 30 Jan 2012 18:43:23 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q0UNhNZ8093929; Mon, 30 Jan 2012 23:43:23 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 30 Jan 2012 23:43:23 GMT Message-Id: <201201302343.q0UNhNZ8093929@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 23:43:25 -0000 TB --- 2012-01-30 22:38:09 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-30 22:38:09 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-01-30 22:38:09 - cleaning the object tree TB --- 2012-01-30 22:38:14 - cvsupping the source tree TB --- 2012-01-30 22:38:14 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-01-30 22:38:31 - building world TB --- 2012-01-30 22:38:31 - CROSS_BUILD_TESTING=YES TB --- 2012-01-30 22:38:31 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-30 22:38:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-30 22:38:31 - SRCCONF=/dev/null TB --- 2012-01-30 22:38:31 - TARGET=sparc64 TB --- 2012-01-30 22:38:31 - TARGET_ARCH=sparc64 TB --- 2012-01-30 22:38:31 - TZ=UTC TB --- 2012-01-30 22:38:31 - __MAKE_CONF=/dev/null TB --- 2012-01-30 22:38:31 - cd /src TB --- 2012-01-30 22:38:31 - /usr/bin/make -B buildworld >>> World build started on Mon Jan 30 22:38:32 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jan 30 23:38:00 UTC 2012 TB --- 2012-01-30 23:38:00 - generating LINT kernel config TB --- 2012-01-30 23:38:00 - cd /src/sys/sparc64/conf TB --- 2012-01-30 23:38:00 - /usr/bin/make -B LINT TB --- 2012-01-30 23:38:00 - cd /src/sys/sparc64/conf TB --- 2012-01-30 23:38:00 - /usr/sbin/config -m LINT TB --- 2012-01-30 23:38:00 - building LINT kernel TB --- 2012-01-30 23:38:00 - CROSS_BUILD_TESTING=YES TB --- 2012-01-30 23:38:00 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-30 23:38:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-30 23:38:00 - SRCCONF=/dev/null TB --- 2012-01-30 23:38:00 - TARGET=sparc64 TB --- 2012-01-30 23:38:00 - TARGET_ARCH=sparc64 TB --- 2012-01-30 23:38:00 - TZ=UTC TB --- 2012-01-30 23:38:00 - __MAKE_CONF=/dev/null TB --- 2012-01-30 23:38:00 - cd /src TB --- 2012-01-30 23:38:00 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 30 23:38:00 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ixgb/ixgb_hw.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ixgbe/ixgbe.c -I/src/sys/dev/ixgbe In file included from /src/sys/dev/ixgbe/ixgbe_type.h:38, from /src/sys/dev/ixgbe/ixgbe_api.h:38, from /src/sys/dev/ixgbe/ixgbe.h:96, from /src/sys/dev/ixgbe/ixgbe.c:40: /src/sys/dev/ixgbe/ixgbe_osdep.h:109: error: conflicting types for 'bool' /src/sys/sys/types.h:271: error: previous declaration of 'bool' was here *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-30 23:43:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-30 23:43:23 - ERROR: failed to build LINT kernel TB --- 2012-01-30 23:43:23 - 3163.22 user 573.20 system 3914.28 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 23:49:36 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D802106564A; Mon, 30 Jan 2012 23:49:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 533A08FC19; Mon, 30 Jan 2012 23:49:36 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q0UNnZ3l031782; Mon, 30 Jan 2012 18:49:35 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q0UNnZ9v031777; Mon, 30 Jan 2012 23:49:35 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 30 Jan 2012 23:49:35 GMT Message-Id: <201201302349.q0UNnZ9v031777@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 23:49:36 -0000 TB --- 2012-01-30 21:43:21 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-30 21:43:21 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-01-30 21:43:21 - cleaning the object tree TB --- 2012-01-30 21:43:28 - cvsupping the source tree TB --- 2012-01-30 21:43:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2012-01-30 21:43:49 - building world TB --- 2012-01-30 21:43:49 - CROSS_BUILD_TESTING=YES TB --- 2012-01-30 21:43:49 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-30 21:43:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-30 21:43:49 - SRCCONF=/dev/null TB --- 2012-01-30 21:43:49 - TARGET=powerpc TB --- 2012-01-30 21:43:49 - TARGET_ARCH=powerpc TB --- 2012-01-30 21:43:49 - TZ=UTC TB --- 2012-01-30 21:43:49 - __MAKE_CONF=/dev/null TB --- 2012-01-30 21:43:49 - cd /src TB --- 2012-01-30 21:43:49 - /usr/bin/make -B buildworld >>> World build started on Mon Jan 30 21:43:49 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jan 30 23:45:32 UTC 2012 TB --- 2012-01-30 23:45:32 - generating LINT kernel config TB --- 2012-01-30 23:45:32 - cd /src/sys/powerpc/conf TB --- 2012-01-30 23:45:32 - /usr/bin/make -B LINT TB --- 2012-01-30 23:45:32 - cd /src/sys/powerpc/conf TB --- 2012-01-30 23:45:32 - /usr/sbin/config -m LINT TB --- 2012-01-30 23:45:32 - building LINT kernel TB --- 2012-01-30 23:45:32 - CROSS_BUILD_TESTING=YES TB --- 2012-01-30 23:45:32 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-30 23:45:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-30 23:45:32 - SRCCONF=/dev/null TB --- 2012-01-30 23:45:32 - TARGET=powerpc TB --- 2012-01-30 23:45:32 - TARGET_ARCH=powerpc TB --- 2012-01-30 23:45:32 - TZ=UTC TB --- 2012-01-30 23:45:32 - __MAKE_CONF=/dev/null TB --- 2012-01-30 23:45:32 - cd /src TB --- 2012-01-30 23:45:32 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 30 23:45:32 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ixgb/ixgb_hw.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ixgbe/ixgbe.c -I/src/sys/dev/ixgbe In file included from /src/sys/dev/ixgbe/ixgbe_type.h:38, from /src/sys/dev/ixgbe/ixgbe_api.h:38, from /src/sys/dev/ixgbe/ixgbe.h:96, from /src/sys/dev/ixgbe/ixgbe.c:40: /src/sys/dev/ixgbe/ixgbe_osdep.h:109: error: conflicting types for 'bool' /src/sys/sys/types.h:271: error: previous declaration of 'bool' was here *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-30 23:49:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-30 23:49:35 - ERROR: failed to build LINT kernel TB --- 2012-01-30 23:49:35 - 6420.60 user 887.09 system 7574.45 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 00:08:01 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B99921065675; Tue, 31 Jan 2012 00:08:01 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1E8458FC16; Tue, 31 Jan 2012 00:08:00 +0000 (UTC) Received: by eekb47 with SMTP id b47so1810100eek.13 for ; Mon, 30 Jan 2012 16:08:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:from:organization:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=52rDAk60U05DFFgZ2RXsb5xGiLieMQVl8glY5ZwHHsA=; b=ThJi9oWzersKtunMfoZFryI5RUwmbvQ1Wk1WzfGgC57d9RgL4Jt6UWL4zqzPIZZlTb CJew/TDrV5VeRr4S+hc8mLrhYkCQCdw5MFdu4GWy44ZzZ8WojdLTMhv3OGM9KwS2cySV R1Vj8IFExumNzHHip3X+cjNghA+SYOvAClZFE= Received: by 10.14.16.129 with SMTP id h1mr277159eeh.46.1327968034964; Mon, 30 Jan 2012 16:00:34 -0800 (PST) Received: from woodstock.peanuts (host171-147-dynamic.1-79-r.retail.telecomitalia.it. [79.1.147.171]) by mx.google.com with ESMTPS id x4sm78994608eeb.4.2012.01.30.16.00.33 (version=SSLv3 cipher=OTHER); Mon, 30 Jan 2012 16:00:34 -0800 (PST) Sender: Alberto Villa From: Alberto Villa Organization: The FreeBSD Project To: freebsd-ports@freebsd.org Date: Tue, 31 Jan 2012 01:00:32 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.0-RC2; KDE/4.7.4; amd64; ; ) References: <20120130123930.GB40244@azathoth.lan> <20120130223459.GA4707@sirius.xvoid.org> <201201310052.28073.avilla@freebsd.org> In-Reply-To: <201201310052.28073.avilla@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart60364322.4vuuFyRtHv"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201201310100.33133.avilla@freebsd.org> Cc: Yuri Pankov , ports@freebsd.org, Baptiste Daroussin , current@freebsd.org Subject: Re: [HEADSUP][CFT] pkgng beta1 is out X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 00:08:01 -0000 --nextPart60364322.4vuuFyRtHv Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable On Tuesday 31 January 2012 00:52:25 Alberto Villa wrote: > Set use_pkgng=3Dyes in /usr/local/etc/portmaster.conf. Sorry, portmaster.rc. =2D-=20 Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla The government of the United States is not in any sense founded on the Christian Religion -- George Washington --nextPart60364322.4vuuFyRtHv Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iJwEAAECAAYFAk8nLyEACgkQ3xiC6kQ1CosB7QP/T+6CB7Ob+28F/jvYEDN8lP8C JmGvRbW0lImZrdhES2GQOnAGlcv5pvTwOm7W4C4pJppqouIDdR19DvwjnEF3TWOZ bf5A9rj1YP9sTfiRyRPo0pwjJEnc9lBje+EcNXCcamTZ21YUuFT4rGq7i663pVnc CLz+9Vv0p8NZ7BkDyxM= =YfSI -----END PGP SIGNATURE----- --nextPart60364322.4vuuFyRtHv-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 00:14:55 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21D121065674; Tue, 31 Jan 2012 00:14:55 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 788DA8FC0C; Tue, 31 Jan 2012 00:14:54 +0000 (UTC) Received: by eaaa14 with SMTP id a14so1810757eaa.13 for ; Mon, 30 Jan 2012 16:14:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:from:organization:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=xbkUYDBzVA9wFf/7AEvzm+AG/p0rkOJS+wm+TEiYEmY=; b=jln+tYYlUpiSEVgJ4Ea/UBJmfXzkfbMfsvyoumAaQ62vYT1Kyv2SdHJH9yhksKjwIK NVR4k//UVu+WDCecRAUcdZWhaYuC1eeVrp31Ugz0XoYzrA7pdexfTpTeABEBRzX6fTRj R/lhATGzXAzDOMTyiv1mpLhTId6fuaw6HABAE= Received: by 10.213.113.196 with SMTP id b4mr28692ebq.0.1327967550247; Mon, 30 Jan 2012 15:52:30 -0800 (PST) Received: from woodstock.peanuts (host171-147-dynamic.1-79-r.retail.telecomitalia.it. [79.1.147.171]) by mx.google.com with ESMTPS id n17sm78932707eei.3.2012.01.30.15.52.28 (version=SSLv3 cipher=OTHER); Mon, 30 Jan 2012 15:52:29 -0800 (PST) Sender: Alberto Villa From: Alberto Villa Organization: The FreeBSD Project To: freebsd-ports@freebsd.org Date: Tue, 31 Jan 2012 00:52:25 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.0-RC2; KDE/4.7.4; amd64; ; ) References: <20120130123930.GB40244@azathoth.lan> <20120130223459.GA4707@sirius.xvoid.org> In-Reply-To: <20120130223459.GA4707@sirius.xvoid.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart20122859.J6yXZnFtgs"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201201310052.28073.avilla@freebsd.org> Cc: Yuri Pankov , ports@freebsd.org, Baptiste Daroussin , current@freebsd.org Subject: Re: [HEADSUP][CFT] pkgng beta1 is out X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 00:14:55 -0000 --nextPart20122859.J6yXZnFtgs Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable On Monday 30 January 2012 23:34:59 Yuri Pankov wrote: > The patch seems to have typos in it (usr_pkgng): > https://github.com/pkgng/pkgng/blob/master/ports/portmaster.patch#L514 > https://github.com/pkgng/pkgng/blob/master/ports/portmaster.patch#L528 Please, take the patch from here: https://github.com/xzhavilla/pkgng/blob/master/ports/portmaster.patch It should be pulled into the main repository soon. > And most stupid question for today - how do I actually tell portmaster > to use pkgng after applying the patch? Set use_pkgng=3Dyes in /usr/local/etc/portmaster.conf. =2D-=20 Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla Depend on the rabbit's foot if you will, but remember, it didn't help the rabbit. -- R. E. Shay --nextPart20122859.J6yXZnFtgs Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iJwEAAECAAYFAk8nLTsACgkQ3xiC6kQ1Cov92QQAu7vAkcQAfK6xY9fFzZ/HX/6R Y5Bl2J5o0UamMZyRJ6J4+eLj9+AoOcNXI+dVTWxmMlwZ7jUTdN7ZSQK49/bXN5Di ASKGQq46vIPoBFqozN32xSl8x5m9mI/vzyqQGUZMmi9XHU9AXBEqUQ6LK0ydFiq3 Oxjphutrz/gtU3FsCdw= =woRO -----END PGP SIGNATURE----- --nextPart20122859.J6yXZnFtgs-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 00:47:58 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05020106564A; Tue, 31 Jan 2012 00:47:58 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id BFBE28FC08; Tue, 31 Jan 2012 00:47:57 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q0V0luOn071861; Mon, 30 Jan 2012 19:47:56 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q0V0lujh071860; Tue, 31 Jan 2012 00:47:56 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 31 Jan 2012 00:47:56 GMT Message-Id: <201201310047.q0V0lujh071860@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 00:47:58 -0000 TB --- 2012-01-30 22:20:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-30 22:20:00 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-01-30 22:20:00 - cleaning the object tree TB --- 2012-01-30 22:20:08 - cvsupping the source tree TB --- 2012-01-30 22:20:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-01-30 22:20:24 - building world TB --- 2012-01-30 22:20:24 - CROSS_BUILD_TESTING=YES TB --- 2012-01-30 22:20:24 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-30 22:20:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-30 22:20:24 - SRCCONF=/dev/null TB --- 2012-01-30 22:20:24 - TARGET=powerpc TB --- 2012-01-30 22:20:24 - TARGET_ARCH=powerpc64 TB --- 2012-01-30 22:20:24 - TZ=UTC TB --- 2012-01-30 22:20:24 - __MAKE_CONF=/dev/null TB --- 2012-01-30 22:20:24 - cd /src TB --- 2012-01-30 22:20:24 - /usr/bin/make -B buildworld >>> World build started on Mon Jan 30 22:20:24 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Jan 31 00:43:38 UTC 2012 TB --- 2012-01-31 00:43:38 - generating LINT kernel config TB --- 2012-01-31 00:43:38 - cd /src/sys/powerpc/conf TB --- 2012-01-31 00:43:38 - /usr/bin/make -B LINT TB --- 2012-01-31 00:43:38 - cd /src/sys/powerpc/conf TB --- 2012-01-31 00:43:38 - /usr/sbin/config -m LINT TB --- 2012-01-31 00:43:38 - building LINT kernel TB --- 2012-01-31 00:43:38 - CROSS_BUILD_TESTING=YES TB --- 2012-01-31 00:43:38 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-31 00:43:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-31 00:43:38 - SRCCONF=/dev/null TB --- 2012-01-31 00:43:38 - TARGET=powerpc TB --- 2012-01-31 00:43:38 - TARGET_ARCH=powerpc64 TB --- 2012-01-31 00:43:38 - TZ=UTC TB --- 2012-01-31 00:43:38 - __MAKE_CONF=/dev/null TB --- 2012-01-31 00:43:38 - cd /src TB --- 2012-01-31 00:43:38 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jan 31 00:43:38 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ixgb/ixgb_hw.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ixgbe/ixgbe.c -I/src/sys/dev/ixgbe In file included from /src/sys/dev/ixgbe/ixgbe_type.h:38, from /src/sys/dev/ixgbe/ixgbe_api.h:38, from /src/sys/dev/ixgbe/ixgbe.h:96, from /src/sys/dev/ixgbe/ixgbe.c:40: /src/sys/dev/ixgbe/ixgbe_osdep.h:109: error: conflicting types for 'bool' /src/sys/sys/types.h:271: error: previous declaration of 'bool' was here *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-31 00:47:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-31 00:47:56 - ERROR: failed to build LINT kernel TB --- 2012-01-31 00:47:56 - 7707.61 user 1046.16 system 8875.72 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 01:23:52 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2B4C106566C for ; Tue, 31 Jan 2012 01:23:52 +0000 (UTC) (envelope-from ambrosehua@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2EACC8FC14 for ; Tue, 31 Jan 2012 01:23:51 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so5835343wib.13 for ; Mon, 30 Jan 2012 17:23:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XudcN5f5X4LohsGbGOWwuriJcg3DpB/YvPzS25kLu+c=; b=PNscELjJm6GNIzoAVM3wWfvE0e5nCX0e3NS1wbCLIKMXMZjOeU54nbF9naOX+PqyJY gMWV+yC8vXyKPk+ZY48XV63oe2i0lWXuCcLlxrkj3b4vJ2YSPNCvCzt69HQb7KLFjf1e yIaFGukwJD77x9LWuFMYTOao2EUQlf203m+MY= MIME-Version: 1.0 Received: by 10.180.94.97 with SMTP id db1mr31239779wib.16.1327973031174; Mon, 30 Jan 2012 17:23:51 -0800 (PST) Received: by 10.223.42.18 with HTTP; Mon, 30 Jan 2012 17:23:50 -0800 (PST) In-Reply-To: <20120130164316.GW2726@deviant.kiev.zoral.com.ua> References: <20120130063607.GV2726@deviant.kiev.zoral.com.ua> <20120130164316.GW2726@deviant.kiev.zoral.com.ua> Date: Tue, 31 Jan 2012 09:23:50 +0800 Message-ID: From: Paul Ambrose To: Kostik Belousov Content-Type: multipart/mixed; boundary=f46d0442681acb61dc04b7c8d014 Cc: freebsd-current Subject: Re: Does anyone try kib's Sandy Bridge PCID patch (pcid.2.patch)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 01:23:52 -0000 --f46d0442681acb61dc04b7c8d014 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable =D4=DA 2012=C4=EA1=D4=C231=C8=D5 =C9=CF=CE=E712:43=A3=ACKostik Belousov =D0=B4=B5=C0=A3=BA > On Mon, Jan 30, 2012 at 07:08:13PM +0800, Paul Ambrose wrote: >> ?? 2012??1??30?? ????2:36??Kostik Belousov ?????? >> > On Mon, Jan 30, 2012 at 10:15:51AM +0800, Paul Ambrose wrote: >> >> I have two boxes, one is AMD Athlon 610e 2.4G with FreeBSD-current >> >> patched with pcid.2.patch? It works well without other issue and it >> >> seem the pcid patch >> >> does not affect other part of the kernel. The other one is Sandy >> > Athlons do not have PCID and probably will never implement it. They us= e >> > other tricks to get similar optimizations, transparently to the OS. >> > >> Just curious, is this AMD similar optimizations >> Address Space Number (ASN) and Global flag >> US Patent 6,604,187. >> http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_A= MDs_64bit_Core.html > This and the same-important next item 'The TLB Flush Filter' is what > I referred to. > >> I did not found anything about ASN in the AMD manual > It is a transparent optimization, which does not require any OS support. > Intel PCID is completely different, it shall be explicitely handled by OS= . > It is some consequence of the nested pages support, AFAIU. > >> >> >> Bridge i5-2300 with FreeBSD 9 release patched with pcid.1.patch( the >> >> pcid.2.patch seems >> >> dependent on AVX and XSAVE stuffs which is available on -current). Bu= t >> >> it hangs up just in a few minutes. I doubt the nvidia-driver which is >> >> not recompiled with >> >> patched kernel is the root, I will check this out later, but does >> >> anyone meet similar problem? >> > There are two many variations compared to the config I did tested. >> > I do not see anything obvious in the changes between HEAD and stable/9 >> > which could be blamed. Nvidia driver might be bigger suspect, but agai= n, >> > I am not aware of anything wrong with it. >> > >> >> >> >> I have two question about the pcid.2.patch >> > >> > Item 2 is clean, I fixed it. >> > >> > For the item 1, I was only able to decipher the proposal to optimize >> > the global shootdown handler to restore the %cr3 with bit 64 set to no= t >> > invalidate current PCID. Is there some more changes ? >> > >> yes, that is what I meant. I was wondering using another way that each >> process has different >> pcid in each active processor, just as the freebsd mips and powerpc >> uses. But obviously this way >> is more friendly to non-pcid x86 processor. > Each vmspace (or pmap) has unique PCID with the patch, at least until > PCID space (12bit) is not exhausted. To really exhaust it, you need 4095 > processes, so it is unlikely but possible event with the current settings= . > Thank you for your explanation. I just disabled nvidia-driver( not load it) , and use "buildworld buildkernel" to test the pcid.1.patch with 9-release, it seems the box reset before completing the buildkernel, the attachment is my kernel config, would you mind try it on 9-release with pcid.1.patch? I will git 10-current a try to see if there is something wrong with my hardware --f46d0442681acb61dc04b7c8d014 Content-Type: application/octet-stream; name=MYKERNEL Content-Disposition: attachment; filename=MYKERNEL Content-Transfer-Encoding: base64 X-Attachment-Id: f_gy28s4o21 IwojIEdFTkVSSUMgLS0gR2VuZXJpYyBrZXJuZWwgY29uZmlndXJhdGlvbiBmaWxlIGZvciBGcmVl QlNEL2FtZDY0CiMKIyBGb3IgbW9yZSBpbmZvcm1hdGlvbiBvbiB0aGlzIGZpbGUsIHBsZWFzZSBy ZWFkIHRoZSBjb25maWcoNSkgbWFudWFsIHBhZ2UsCiMgYW5kL29yIHRoZSBoYW5kYm9vayBzZWN0 aW9uIG9uIEtlcm5lbCBDb25maWd1cmF0aW9uIEZpbGVzOgojCiMgICAgaHR0cDovL3d3dy5GcmVl QlNELm9yZy9kb2MvZW5fVVMuSVNPODg1OS0xL2Jvb2tzL2hhbmRib29rL2tlcm5lbGNvbmZpZy1j b25maWcuaHRtbAojCiMgVGhlIGhhbmRib29rIGlzIGFsc28gYXZhaWxhYmxlIGxvY2FsbHkgaW4g L3Vzci9zaGFyZS9kb2MvaGFuZGJvb2sKIyBpZiB5b3UndmUgaW5zdGFsbGVkIHRoZSBkb2MgZGlz dHJpYnV0aW9uLCBvdGhlcndpc2UgYWx3YXlzIHNlZSB0aGUKIyBGcmVlQlNEIFdvcmxkIFdpZGUg V2ViIHNlcnZlciAoaHR0cDovL3d3dy5GcmVlQlNELm9yZy8pIGZvciB0aGUKIyBsYXRlc3QgaW5m b3JtYXRpb24uCiMKIyBBbiBleGhhdXN0aXZlIGxpc3Qgb2Ygb3B0aW9ucyBhbmQgbW9yZSBkZXRh aWxlZCBleHBsYW5hdGlvbnMgb2YgdGhlCiMgZGV2aWNlIGxpbmVzIGlzIGFsc28gcHJlc2VudCBp biB0aGUgLi4vLi4vY29uZi9OT1RFUyBhbmQgTk9URVMgZmlsZXMuCiMgSWYgeW91IGFyZSBpbiBk b3VidCBhcyB0byB0aGUgcHVycG9zZSBvciBuZWNlc3NpdHkgb2YgYSBsaW5lLCBjaGVjayBmaXJz dAojIGluIE5PVEVTLgojCiMgJEZyZWVCU0Q6IHNyYy9zeXMvYW1kNjQvY29uZi9HRU5FUklDLHYg MS41MzEuMi42IDIwMDkvMTEvMTcgMTU6NTY6NDUgamhiIEV4cCAkCgpjcHUJCUhBTU1FUgppZGVu dAkJTVlLRVJORUwKCiMgVG8gc3RhdGljYWxseSBjb21waWxlIGluIGRldmljZSB3aXJpbmcgaW5z dGVhZCBvZiAvYm9vdC9kZXZpY2UuaGludHMKI2hpbnRzCQkiR0VORVJJQy5oaW50cyIJCSMgRGVm YXVsdCBwbGFjZXMgdG8gbG9vayBmb3IgZGV2aWNlcy4KCiMgVXNlIHRoZSBmb2xsb3dpbmcgdG8g Y29tcGlsZSBpbiB2YWx1ZXMgYWNjZXNzaWJsZSB0byB0aGUga2VybmVsCiMgdGhyb3VnaCBnZXRl bnYoKSAob3Iga2VudigxKSBpbiB1c2VybGFuZCkuIFRoZSBmb3JtYXQgb2YgdGhlIGZpbGUKIyBp cyAndmFyaWFibGU9dmFsdWUnLCBzZWUga2VudigxKQojCiMgZW52CQkiR0VORVJJQy5lbnYiCgpt YWtlb3B0aW9ucwlERUJVRz0tZwkJIyBCdWlsZCBrZXJuZWwgd2l0aCBnZGIoMSkgZGVidWcgc3lt Ym9scwoKb3B0aW9ucyAJU0NIRURfVUxFCQkjIFVMRSBzY2hlZHVsZXIKb3B0aW9ucyAJUFJFRU1Q VElPTgkJIyBFbmFibGUga2VybmVsIHRocmVhZCBwcmVlbXB0aW9uCm9wdGlvbnMgCUlORVQJCQkj IEludGVyTkVUd29ya2luZwpvcHRpb25zIAlJTkVUNgkJCSMgSVB2NiBjb21tdW5pY2F0aW9ucyBw cm90b2NvbHMKb3B0aW9ucyAJU0NUUAkJCSMgU3RyZWFtIENvbnRyb2wgVHJhbnNtaXNzaW9uIFBy b3RvY29sCm9wdGlvbnMgCUZGUwkJCSMgQmVya2VsZXkgRmFzdCBGaWxlc3lzdGVtCm9wdGlvbnMg CVNPRlRVUERBVEVTCQkjIEVuYWJsZSBGRlMgc29mdCB1cGRhdGVzIHN1cHBvcnQKb3B0aW9ucyAJ VUZTX0FDTAkJCSMgU3VwcG9ydCBmb3IgYWNjZXNzIGNvbnRyb2wgbGlzdHMKb3B0aW9ucyAJVUZT X0RJUkhBU0gJCSMgSW1wcm92ZSBwZXJmb3JtYW5jZSBvbiBiaWcgZGlyZWN0b3JpZXMKb3B0aW9u cyAJVUZTX0dKT1VSTkFMCQkjIEVuYWJsZSBnam91cm5hbC1iYXNlZCBVRlMgam91cm5hbGluZwpv cHRpb25zIAlNRF9ST09UCQkJIyBNRCBpcyBhIHBvdGVudGlhbCByb290IGRldmljZQpvcHRpb25z IAlORlNDTAkJCSMgTmV3IE5ldHdvcmsgRmlsZXN5c3RlbSBDbGllbnQKb3B0aW9ucyAJTkZTRAkJ CSMgTmV3IE5ldHdvcmsgRmlsZXN5c3RlbSBTZXJ2ZXIKb3B0aW9ucyAJTkZTTE9DS0QJCSMgTmV0 d29yayBMb2NrIE1hbmFnZXIKb3B0aW9ucyAJTkZTX1JPT1QJCSMgTkZTIHVzYWJsZSBhcyAvLCBy ZXF1aXJlcyBORlNDTApvcHRpb25zIAlNU0RPU0ZTCQkJIyBNU0RPUyBGaWxlc3lzdGVtCm9wdGlv bnMgCUNEOTY2MAkJCSMgSVNPIDk2NjAgRmlsZXN5c3RlbQpvcHRpb25zIAlQUk9DRlMJCQkjIFBy b2Nlc3MgZmlsZXN5c3RlbSAocmVxdWlyZXMgUFNFVURPRlMpCm9wdGlvbnMgCVBTRVVET0ZTCQkj IFBzZXVkby1maWxlc3lzdGVtIGZyYW1ld29yawpvcHRpb25zIAlHRU9NX1BBUlRfR1BUCQkjIEdV SUQgUGFydGl0aW9uIFRhYmxlcy4Kb3B0aW9ucyAJR0VPTV9MQUJFTAkJIyBQcm92aWRlcyBsYWJl bGl6YXRpb24Kb3B0aW9ucyAJQ09NUEFUX0ZSRUVCU0QzMgkjIENvbXBhdGlibGUgd2l0aCBpMzg2 IGJpbmFyaWVzCiNvcHRpb25zIAlDT01QQVRfRlJFRUJTRDQJCSMgQ29tcGF0aWJsZSB3aXRoIEZy ZWVCU0Q0CiNvcHRpb25zIAlDT01QQVRfRlJFRUJTRDUJCSMgQ29tcGF0aWJsZSB3aXRoIEZyZWVC U0Q1CiNvcHRpb25zIAlDT01QQVRfRlJFRUJTRDYJCSMgQ29tcGF0aWJsZSB3aXRoIEZyZWVCU0Q2 CiNvcHRpb25zIAlDT01QQVRfRlJFRUJTRDcJCSMgQ29tcGF0aWJsZSB3aXRoIEZyZWVCU0Q3Cm9w dGlvbnMgCVNDU0lfREVMQVk9NTAwMAkJIyBEZWxheSAoaW4gbXMpIGJlZm9yZSBwcm9iaW5nIFND U0kKb3B0aW9ucyAJS1RSQUNFCQkJIyBrdHJhY2UoMSkgc3VwcG9ydApvcHRpb25zIAlTVEFDSwkJ CSMgc3RhY2soOSkgc3VwcG9ydApvcHRpb25zIAlTWVNWU0hNCQkJIyBTWVNWLXN0eWxlIHNoYXJl ZCBtZW1vcnkKb3B0aW9ucyAJU1lTVk1TRwkJCSMgU1lTVi1zdHlsZSBtZXNzYWdlIHF1ZXVlcwpv cHRpb25zIAlTWVNWU0VNCQkJIyBTWVNWLXN0eWxlIHNlbWFwaG9yZXMKb3B0aW9ucyAJUDEwMDNf MUJfU0VNQVBIT1JFUwkjIFBPU0lYLXN0eWxlIHNlbWFwaG9yZXMKb3B0aW9ucyAJX0tQT1NJWF9Q UklPUklUWV9TQ0hFRFVMSU5HICMgUE9TSVggUDEwMDNfMUIgcmVhbC10aW1lIGV4dGVuc2lvbnMK b3B0aW9ucyAJUFJJTlRGX0JVRlJfU0laRT0xMjgJIyBQcmV2ZW50IHByaW50ZiBvdXRwdXQgYmVp bmcgaW50ZXJzcGVyc2VkLgpvcHRpb25zIAlLQkRfSU5TVEFMTF9DREVWCSMgaW5zdGFsbCBhIENE RVYgZW50cnkgaW4gL2RldgpvcHRpb25zIAlIV1BNQ19IT09LUwkJIyBOZWNlc3Nhcnkga2VybmVs IGhvb2tzIGZvciBod3BtYyg0KQpvcHRpb25zIAlBVURJVAkJCSMgU2VjdXJpdHkgZXZlbnQgYXVk aXRpbmcKb3B0aW9ucyAJTUFDCQkJIyBUcnVzdGVkQlNEIE1BQyBGcmFtZXdvcmsKb3B0aW9ucwkJ RkxPV1RBQkxFCQkjIHBlci1jcHUgcm91dGluZyBjYWNoZQpvcHRpb25zIAlLRFRSQUNFX0ZSQU1F CQkjIEVuc3VyZSBmcmFtZXMgYXJlIGNvbXBpbGVkIGluCm9wdGlvbnMgCUtEVFJBQ0VfSE9PS1MJ CSMgS2VybmVsIERUcmFjZSBob29rcwpvcHRpb25zIAlJTkNMVURFX0NPTkZJR19GSUxFICAgICAj IEluY2x1ZGUgdGhpcyBmaWxlIGluIGtlcm5lbAoKb3B0aW9ucwkJRERCX0NURgpvcHRpb25zCQlE REIKb3B0aW9ucwkJS0RCCm9wdGlvbnMJCUtEQl9UUkFDRQoKIyBNYWtlIGFuIFNNUC1jYXBhYmxl IGtlcm5lbCBieSBkZWZhdWx0Cm9wdGlvbnMgCVNNUAkJCSMgU3ltbWV0cmljIE11bHRpUHJvY2Vz c29yIEtlcm5lbAoKIyBDUFUgZnJlcXVlbmN5IGNvbnRyb2wKZGV2aWNlCQljcHVmcmVxCgojIEJ1 cyBzdXBwb3J0LgpkZXZpY2UJCWFjcGkKZGV2aWNlCQlwY2kKCiMgRmxvcHB5IGRyaXZlcwojZGV2 aWNlCQlmZGMKCiMgQVRBIGNvbnRyb2xsZXJzCmRldmljZQkJYWhjaQkJIyBBSENJLWNvbXBhdGli bGUgU0FUQSBjb250cm9sbGVycwpkZXZpY2UJCWF0YQkJIyBMZWdhY3kgQVRBL1NBVEEgY29udHJv bGxlcnMKb3B0aW9ucyAJQVRBX0NBTQkJIyBIYW5kbGUgbGVnYWN5IGNvbnRyb2xsZXJzIHdpdGgg Q0FNCm9wdGlvbnMgCUFUQV9TVEFUSUNfSUQJIyBTdGF0aWMgZGV2aWNlIG51bWJlcmluZwoKIyBT Q1NJIENvbnRyb2xsZXJzCiNkZXZpY2UJCWFoYwkJIyBBSEEyOTQwIGFuZCBvbmJvYXJkIEFJQzd4 eHggZGV2aWNlcwojb3B0aW9ucyAJQUhDX1JFR19QUkVUVFlfUFJJTlQJIyBQcmludCByZWdpc3Rl ciBiaXRmaWVsZHMgaW4gZGVidWcKCQkJCQkjIG91dHB1dC4gIEFkZHMgfjEyOGsgdG8gZHJpdmVy LgojZGV2aWNlCQlhaGQJCSMgQUhBMzkzMjAvMjkzMjAgYW5kIG9uYm9hcmQgQUlDNzl4eCBkZXZp Y2VzCiNvcHRpb25zIAlBSERfUkVHX1BSRVRUWV9QUklOVAkjIFByaW50IHJlZ2lzdGVyIGJpdGZp ZWxkcyBpbiBkZWJ1ZwoJCQkJCSMgb3V0cHV0LiAgQWRkcyB+MjE1ayB0byBkcml2ZXIuCiNkZXZp Y2UJCWFtZAkJIyBBTUQgNTNDOTc0IChUZWtyYW0gREMtMzkwKFQpKQojZGV2aWNlCQlocHRpb3AJ CSMgSGlnaHBvaW50IFJvY2tldFJhaWQgM3h4eCBzZXJpZXMKI2RldmljZQkJaXNwCQkjIFFsb2dp YyBmYW1pbHkKI2RldmljZQkJaXNwZncJCSMgRmlybXdhcmUgZm9yIFFMb2dpYyBIQkFzLSBub3Jt YWxseSBhIG1vZHVsZQpkZXZpY2UJCW1wdAkJIyBMU0ktTG9naWMgTVBULUZ1c2lvbgpkZXZpY2UJ CW1wcwkJIyBMU0ktTG9naWMgTVBULUZ1c2lvbiAyCiNkZXZpY2UJCW5jcgkJIyBOQ1IvU3ltYmlv cyBMb2dpYwojZGV2aWNlCQlzeW0JCSMgTkNSL1N5bWJpb3MgTG9naWMgKG5ld2VyIGNoaXBzZXRz ICsgdGhvc2Ugb2YgYG5jcicpCiNkZXZpY2UJCXRybQkJIyBUZWtyYW0gREMzOTVVL1VXL0YgREMz MTVVIGFkYXB0ZXJzCgojZGV2aWNlCQlhZHYJCSMgQWR2YW5zeXMgU0NTSSBhZGFwdGVycwojZGV2 aWNlCQlhZHcJCSMgQWR2YW5zeXMgd2lkZSBTQ1NJIGFkYXB0ZXJzCiNkZXZpY2UJCWFpYwkJIyBB ZGFwdGVjIDE1WzAxMl14IFNDU0kgYWRhcHRlcnMsIEFJQy02WzIzXTYwLgojZGV2aWNlCQlidAkJ IyBCdXNsb2dpYy9NeWxleCBNdWx0aU1hc3RlciBTQ1NJIGFkYXB0ZXJzCgojIEFUQS9TQ1NJIHBl cmlwaGVyYWxzCmRldmljZQkJc2NidXMJCSMgU0NTSSBidXMgKHJlcXVpcmVkIGZvciBBVEEvU0NT SSkKZGV2aWNlCQljaAkJIyBTQ1NJIG1lZGlhIGNoYW5nZXJzCmRldmljZQkJZGEJCSMgRGlyZWN0 IEFjY2VzcyAoZGlza3MpCmRldmljZQkJc2EJCSMgU2VxdWVudGlhbCBBY2Nlc3MgKHRhcGUgZXRj KQpkZXZpY2UJCWNkCQkjIENECmRldmljZQkJcGFzcwkJIyBQYXNzdGhyb3VnaCBkZXZpY2UgKGRp cmVjdCBBVEEvU0NTSSBhY2Nlc3MpCmRldmljZQkJc2VzCQkjIFNDU0kgRW52aXJvbm1lbnRhbCBT ZXJ2aWNlcyAoYW5kIFNBRi1URSkKCiMgUkFJRCBjb250cm9sbGVycyBpbnRlcmZhY2VkIHRvIHRo ZSBTQ1NJIHN1YnN5c3RlbQpkZXZpY2UJCWFtcgkJIyBBTUkgTWVnYVJBSUQKI2RldmljZQkJYXJj bXNyCQkjIEFyZWNhIFNBVEEgSUkgUkFJRAojWFhYIGl0IGlzIG5vdCA2NC1iaXQgY2xlYW4sIC1z Y290dGwKI2RldmljZQkJYXNyCQkjIERQVCBTbWFydFJBSUQgViwgVkkgYW5kIEFkYXB0ZWMgU0NT SSBSQUlECiNkZXZpY2UJCWNpc3MJCSMgQ29tcGFxIFNtYXJ0IFJBSUQgNSoKI2RldmljZQkJZHB0 CQkjIERQVCBTbWFydGNhY2hlIElJSSwgSVYgLSBTZWUgTk9URVMgZm9yIG9wdGlvbnMKI2Rldmlj ZQkJaHB0bXYJCSMgSGlnaHBvaW50IFJvY2tldFJBSUQgMTgyeAojZGV2aWNlCQlocHRycgkJIyBI aWdocG9pbnQgUm9ja2V0UkFJRCAxN3h4LCAyMnh4LCAyM3h4LCAyNXh4CiNkZXZpY2UJCWlpcgkJ IyBJbnRlbCBJbnRlZ3JhdGVkIFJBSUQKI2RldmljZQkJaXBzCQkjIElCTSAoQWRhcHRlYykgU2Vy dmVSQUlECiNkZXZpY2UJCW1seQkJIyBNeWxleCBBY2NlbGVSQUlEL2VYdHJlbWVSQUlECiNkZXZp Y2UJCXR3YQkJIyAzd2FyZSA5MDAwIHNlcmllcyBQQVRBL1NBVEEgUkFJRAoKIyBSQUlEIGNvbnRy b2xsZXJzCiNkZXZpY2UJCWFhYwkJIyBBZGFwdGVjIEZTQSBSQUlECiNkZXZpY2UJCWFhY3AJCSMg U0NTSSBwYXNzdGhyb3VnaCBmb3IgYWFjIChyZXF1aXJlcyBDQU0pCiNkZXZpY2UJCWlkYQkJIyBD b21wYXEgU21hcnQgUkFJRApkZXZpY2UJCW1maQkJIyBMU0kgTWVnYVJBSUQgU0FTCiNkZXZpY2UJ CW1seAkJIyBNeWxleCBEQUM5NjAgZmFtaWx5CiNYWFggcG9pbnRlci9pbnQgd2FybmluZ3MKI2Rl dmljZQkJcHN0CQkjIFByb21pc2UgU3VwZXJ0cmFrIFNYNjAwMAojZGV2aWNlCQl0d2UJCSMgM3dh cmUgQVRBIFJBSUQKCiMgYXRrYmRjMCBjb250cm9scyBib3RoIHRoZSBrZXlib2FyZCBhbmQgdGhl IFBTLzIgbW91c2UKZGV2aWNlCQlhdGtiZGMJCSMgQVQga2V5Ym9hcmQgY29udHJvbGxlcgpkZXZp Y2UJCWF0a2JkCQkjIEFUIGtleWJvYXJkCmRldmljZQkJcHNtCQkjIFBTLzIgbW91c2UKCmRldmlj ZQkJa2JkbXV4CQkjIGtleWJvYXJkIG11bHRpcGxleGVyCgpkZXZpY2UJCXZnYQkJIyBWR0Egdmlk ZW8gY2FyZCBkcml2ZXIKCiNkZXZpY2UJCXNwbGFzaAkJIyBTcGxhc2ggc2NyZWVuIGFuZCBzY3Jl ZW4gc2F2ZXIgc3VwcG9ydAoKIyBzeXNjb25zIGlzIHRoZSBkZWZhdWx0IGNvbnNvbGUgZHJpdmVy LCByZXNlbWJsaW5nIGFuIFNDTyBjb25zb2xlCm9wdGlvbnMJCVZFU0EKZGV2aWNlCQlzYwpvcHRp b25zIAlTQ19QSVhFTF9NT0RFCSMgYWRkIHN1cHBvcnQgZm9yIHRoZSByYXN0ZXIgdGV4dCBtb2Rl CgpkZXZpY2UJCWFncAkJIyBzdXBwb3J0IHNldmVyYWwgQUdQIGNoaXBzZXRzCgojIFBDQ0FSRCAo UENNQ0lBKSBzdXBwb3J0CiMgUENNQ0lBIGFuZCBjYXJkYnVzIGJyaWRnZSBzdXBwb3J0CiNkZXZp Y2UJCWNiYgkJIyBjYXJkYnVzICh5ZW50YSkgYnJpZGdlCiNkZXZpY2UJCXBjY2FyZAkJIyBQQyBD YXJkICgxNi1iaXQpIGJ1cwojZGV2aWNlCQljYXJkYnVzCQkjIENhcmRCdXMgKDMyLWJpdCkgYnVz CgojIFNlcmlhbCAoQ09NKSBwb3J0cwpkZXZpY2UJCXVhcnQJCSMgR2VuZXJpYyBVQVJUIGRyaXZl cgoKIyBQYXJhbGxlbCBwb3J0CmRldmljZQkJcHBjCmRldmljZQkJcHBidXMJCSMgUGFyYWxsZWwg cG9ydCBidXMgKHJlcXVpcmVkKQpkZXZpY2UJCWxwdAkJIyBQcmludGVyCmRldmljZQkJcGxpcAkJ IyBUQ1AvSVAgb3ZlciBwYXJhbGxlbApkZXZpY2UJCXBwaQkJIyBQYXJhbGxlbCBwb3J0IGludGVy ZmFjZSBkZXZpY2UKI2RldmljZQkJdnBvCQkjIFJlcXVpcmVzIHNjYnVzIGFuZCBkYQoKZGV2aWNl CQlwdWMJCSMgTXVsdGkgSS9PIGNhcmRzIGFuZCBtdWx0aS1jaGFubmVsIFVBUlRzCgojIFBDSSBF dGhlcm5ldCBOSUNzLgojZGV2aWNlCQlkZQkJIyBERUMvSW50ZWwgREMyMXg0eCAoYGBUdWxpcCcn KQojZGV2aWNlCQllbQkJIyBJbnRlbCBQUk8vMTAwMCBHaWdhYml0IEV0aGVybmV0IEZhbWlseQoj ZGV2aWNlCQlpZ2IJCSMgSW50ZWwgUFJPLzEwMDAgUENJRSBTZXJ2ZXIgR2lnYWJpdCBGYW1pbHkK I2RldmljZQkJaXhnYmUJCSMgSW50ZWwgUFJPLzEwR2JFIFBDSUUgRXRoZXJuZXQgRmFtaWx5CiNk ZXZpY2UJCWxlCQkjIEFNRCBBbTc5MDAgTEFOQ0UgYW5kIEFtNzlDOXh4IFBDbmV0CiNkZXZpY2UJ CXRpCQkjIEFsdGVvbiBOZXR3b3JrcyBUaWdvbiBJL0lJIGdpZ2FiaXQgRXRoZXJuZXQKI2Rldmlj ZQkJdHhwCQkjIDNDb20gM2NSOTkwIChgYFR5cGhvb24nJykKI2RldmljZQkJdngJCSMgM0NvbSAz YzU5MCwgM2M1OTUgKGBgVm9ydGV4JycpCgojIFBDSSBFdGhlcm5ldCBOSUNzIHRoYXQgdXNlIHRo ZSBjb21tb24gTUlJIGJ1cyBjb250cm9sbGVyIGNvZGUuCiMgTk9URTogQmUgc3VyZSB0byBrZWVw IHRoZSAnZGV2aWNlIG1paWJ1cycgbGluZSBpbiBvcmRlciB0byB1c2UgdGhlc2UgTklDcyEKZGV2 aWNlCQltaWlidXMJCSMgTUlJIGJ1cyBzdXBwb3J0CiNkZXZpY2UJCWFlCQkjIEF0dGFuc2ljL0F0 aGVyb3MgTDIgRmFzdEV0aGVybmV0CiNkZXZpY2UJCWFnZQkJIyBBdHRhbnNpYy9BdGhlcm9zIEwx IEdpZ2FiaXQgRXRoZXJuZXQKI2RldmljZQkJYWxjCQkjIEF0aGVyb3MgQVI4MTMxL0FSODEzMiBF dGhlcm5ldAojZGV2aWNlCQlhbGUJCSMgQXRoZXJvcyBBUjgxMjEvQVI4MTEzL0FSODExNCBFdGhl cm5ldAojZGV2aWNlCQliY2UJCSMgQnJvYWRjb20gQkNNNTcwNi9CQ001NzA4IEdpZ2FiaXQgRXRo ZXJuZXQKI2RldmljZQkJYmZlCQkjIEJyb2FkY29tIEJDTTQ0MHggMTAvMTAwIEV0aGVybmV0CiNk ZXZpY2UJCWJnZQkJIyBCcm9hZGNvbSBCQ001NzB4eCBHaWdhYml0IEV0aGVybmV0CiNkZXZpY2UJ CWRjCQkjIERFQy9JbnRlbCAyMTE0MyBhbmQgdmFyaW91cyB3b3JrYWxpa2VzCiNkZXZpY2UJCWV0 CQkjIEFnZXJlIEVUMTMxMCAxMC8xMDAvR2lnYWJpdCBFdGhlcm5ldAojZGV2aWNlCQlmeHAJCSMg SW50ZWwgRXRoZXJFeHByZXNzIFBSTy8xMDBCICg4MjU1NywgODI1NTgpCiNkZXZpY2UJCWptZQkJ IyBKTWljcm9uIEpNQzI1MCBHaWdhYml0L0pNQzI2MCBGYXN0IEV0aGVybmV0CiNkZXZpY2UJCWxn ZQkJIyBMZXZlbCAxIExYVDEwMDEgZ2lnYWJpdCBFdGhlcm5ldAojZGV2aWNlCQltc2sJCSMgTWFy dmVsbC9TeXNLb25uZWN0IFl1a29uIElJIEdpZ2FiaXQgRXRoZXJuZXQKI2RldmljZQkJbmZlCQkj IG5WaWRpYSBuRm9yY2UgTUNQIG9uLWJvYXJkIEV0aGVybmV0CiNkZXZpY2UJCW5nZQkJIyBOYXRT ZW1pIERQODM4MjAgZ2lnYWJpdCBFdGhlcm5ldAojZGV2aWNlCQludmUJCSMgblZpZGlhIG5Gb3Jj ZSBNQ1Agb24tYm9hcmQgRXRoZXJuZXQgTmV0d29ya2luZwojZGV2aWNlCQlwY24JCSMgQU1EIEFt NzlDOTd4IFBDSSAxMC8xMDAgKHByZWNlZGVuY2Ugb3ZlciAnbGUnKQpkZXZpY2UJCXJlCQkjIFJl YWxUZWsgODEzOUMrLzgxNjkvODE2OVMvODExMFMKI2RldmljZQkJcmwJCSMgUmVhbFRlayA4MTI5 LzgxMzkKI2RldmljZQkJc2YJCSMgQWRhcHRlYyBBSUMtNjkxNSAoYGBTdGFyZmlyZScnKQojZGV2 aWNlCQlzaXMJCSMgU2lsaWNvbiBJbnRlZ3JhdGVkIFN5c3RlbXMgU2lTIDkwMC9TaVMgNzAxNgoj ZGV2aWNlCQlzawkJIyBTeXNLb25uZWN0IFNLLTk4NHggJiBTSy05ODJ4IGdpZ2FiaXQgRXRoZXJu ZXQKI2RldmljZQkJc3RlCQkjIFN1bmRhbmNlIFNUMjAxIChELUxpbmsgREZFLTU1MFRYKQojZGV2 aWNlCQlzdGdlCQkjIFN1bmRhbmNlL1RhbWFyYWNrIFRDOTAyMSBnaWdhYml0IEV0aGVybmV0CiNk ZXZpY2UJCXRsCQkjIFRleGFzIEluc3RydW1lbnRzIFRodW5kZXJMQU4KI2RldmljZQkJdHgJCSMg U01DIEV0aGVyUG93ZXIgSUkgKDgzYzE3MCBgYEVQSUMnJykKI2RldmljZQkJdmdlCQkjIFZJQSBW VDYxMnggZ2lnYWJpdCBFdGhlcm5ldAojZGV2aWNlCQl2cgkJIyBWSUEgUmhpbmUsIFJoaW5lIElJ CiNkZXZpY2UJCXdiCQkjIFdpbmJvbmQgVzg5Qzg0MEYKI2RldmljZQkJeGwJCSMgM0NvbSAzYzkw eCAoYGBCb29tZXJhbmcnJywgYGBDeWNsb25lJycpCgojIElTQSBFdGhlcm5ldCBOSUNzLiAgcGNj YXJkIE5JQ3MgaW5jbHVkZWQuCiNkZXZpY2UJCWNzCQkjIENyeXN0YWwgU2VtaWNvbmR1Y3RvciBD Uzg5eDAgTklDCiMgJ2RldmljZSBlZCcgcmVxdWlyZXMgJ2RldmljZSBtaWlidXMnCiNkZXZpY2UJ CWVkCQkjIE5FWzEyXTAwMCwgU01DIFVsdHJhLCAzYzUwMywgRFM4MzkwIGNhcmRzCiNkZXZpY2UJ CWV4CQkjIEludGVsIEV0aGVyRXhwcmVzcyBQcm8vMTAgYW5kIFByby8xMCsKI2RldmljZQkJZXAJ CSMgRXRoZXJsaW5rIElJSSBiYXNlZCBjYXJkcwojZGV2aWNlCQlmZQkJIyBGdWppdHN1IE1CODY5 NnggYmFzZWQgY2FyZHMKI2RldmljZQkJc24JCSMgU01DJ3MgOTAwMCBzZXJpZXMgb2YgRXRoZXJu ZXQgY2hpcHMKI2RldmljZQkJeGUJCSMgWGlyY29tIHBjY2FyZCBFdGhlcm5ldAoKIyBXaXJlbGVz cyBOSUMgY2FyZHMKI2RldmljZQkJd2xhbgkJIyA4MDIuMTEgc3VwcG9ydAojb3B0aW9ucyAJSUVF RTgwMjExX0RFQlVHCSMgZW5hYmxlIGRlYnVnIG1zZ3MKI29wdGlvbnMgCUlFRUU4MDIxMV9BTVBE VV9BR0UgIyBhZ2UgZnJhbWVzIGluIEFNUERVIHJlb3JkZXIgcSdzCiNvcHRpb25zIAlJRUVFODAy MTFfU1VQUE9SVF9NRVNICSMgZW5hYmxlIDgwMi4xMXMgZHJhZnQgc3VwcG9ydAojZGV2aWNlCQl3 bGFuX3dlcAkjIDgwMi4xMSBXRVAgc3VwcG9ydAojZGV2aWNlCQl3bGFuX2NjbXAJIyA4MDIuMTEg Q0NNUCBzdXBwb3J0CiNkZXZpY2UJCXdsYW5fdGtpcAkjIDgwMi4xMSBUS0lQIHN1cHBvcnQKI2Rl dmljZQkJd2xhbl9hbXJyCSMgQU1SUiB0cmFuc21pdCByYXRlIGNvbnRyb2wgYWxnb3JpdGhtCiNk ZXZpY2UJCWFuCQkjIEFpcm9uZXQgNDUwMC80ODAwIDgwMi4xMSB3aXJlbGVzcyBOSUNzLgojZGV2 aWNlCQlhdGgJCSMgQXRoZXJvcyBwY2kvY2FyZGJ1cyBOSUMncwojZGV2aWNlCQlhdGhfaGFsCQkj IHBjaS9jYXJkYnVzIGNoaXAgc3VwcG9ydAojb3B0aW9ucyAJQUhfU1VQUE9SVF9BUjU0MTYJIyBl bmFibGUgQVI1NDE2IHR4L3J4IGRlc2NyaXB0b3JzCiNkZXZpY2UJCWF0aF9yYXRlX3NhbXBsZQkj IFNhbXBsZVJhdGUgdHggcmF0ZSBjb250cm9sIGZvciBhdGgKI2RldmljZQkJcmFsCQkjIFJhbGlu ayBUZWNobm9sb2d5IFJUMjUwMCB3aXJlbGVzcyBOSUNzLgojZGV2aWNlCQl3aQkJIyBXYXZlTEFO L0ludGVyc2lsL1N5bWJvbCA4MDIuMTEgd2lyZWxlc3MgTklDcy4KCiMgUHNldWRvIGRldmljZXMu CmRldmljZQkJbG9vcAkJIyBOZXR3b3JrIGxvb3BiYWNrCmRldmljZQkJcmFuZG9tCQkjIEVudHJv cHkgZGV2aWNlCmRldmljZQkJZXRoZXIJCSMgRXRoZXJuZXQgc3VwcG9ydApkZXZpY2UJCXZsYW4J CSMgODAyLjFRIFZMQU4gc3VwcG9ydApkZXZpY2UJCXR1bgkJIyBQYWNrZXQgdHVubmVsLgpkZXZp Y2UJCXB0eQkJIyBCU0Qtc3R5bGUgY29tcGF0aWJpbGl0eSBwc2V1ZG8gdHR5cwpkZXZpY2UJCW1k CQkjIE1lbW9yeSAiZGlza3MiCmRldmljZQkJZ2lmCQkjIElQdjYgYW5kIElQdjQgdHVubmVsaW5n CmRldmljZQkJZmFpdGgJCSMgSVB2Ni10by1JUHY0IHJlbGF5aW5nICh0cmFuc2xhdGlvbikKZGV2 aWNlCQlmaXJtd2FyZQkjIGZpcm13YXJlIGFzc2lzdCBtb2R1bGUKCiMgVGhlIGBicGYnIGRldmlj ZSBlbmFibGVzIHRoZSBCZXJrZWxleSBQYWNrZXQgRmlsdGVyLgojIEJlIGF3YXJlIG9mIHRoZSBh ZG1pbmlzdHJhdGl2ZSBjb25zZXF1ZW5jZXMgb2YgZW5hYmxpbmcgdGhpcyEKIyBOb3RlIHRoYXQg J2JwZicgaXMgcmVxdWlyZWQgZm9yIERIQ1AuCmRldmljZQkJYnBmCQkjIEJlcmtlbGV5IHBhY2tl dCBmaWx0ZXIKCiMgVVNCIHN1cHBvcnQKb3B0aW9ucyAJVVNCX0RFQlVHCSMgZW5hYmxlIGRlYnVn IG1zZ3MKZGV2aWNlCQl1aGNpCQkjIFVIQ0kgUENJLT5VU0IgaW50ZXJmYWNlCmRldmljZQkJb2hj aQkJIyBPSENJIFBDSS0+VVNCIGludGVyZmFjZQpkZXZpY2UJCWVoY2kJCSMgRUhDSSBQQ0ktPlVT QiBpbnRlcmZhY2UgKFVTQiAyLjApCmRldmljZQkJeGhjaQkJIyBYSENJIFBDSS0+VVNCIGludGVy ZmFjZSAoVVNCIDMuMCkKZGV2aWNlCQl1c2IJCSMgVVNCIEJ1cyAocmVxdWlyZWQpCiNkZXZpY2UJ CXVkYnAJCSMgVVNCIERvdWJsZSBCdWxrIFBpcGUgZGV2aWNlcwpkZXZpY2UJCXVoaWQJCSMgIkh1 bWFuIEludGVyZmFjZSBEZXZpY2VzIgpkZXZpY2UJCXVrYmQJCSMgS2V5Ym9hcmQKZGV2aWNlCQl1 bHB0CQkjIFByaW50ZXIKZGV2aWNlCQl1bWFzcwkJIyBEaXNrcy9NYXNzIHN0b3JhZ2UgLSBSZXF1 aXJlcyBzY2J1cyBhbmQgZGEKZGV2aWNlCQl1bXMJCSMgTW91c2UKI2RldmljZQkJdXJpbwkJIyBE aWFtb25kIFJpbyA1MDAgTVAzIHBsYXllcgojIFVTQiBTZXJpYWwgZGV2aWNlcwojZGV2aWNlCQl1 YXJrCQkjIFRlY2hub2xvZ2llcyBBUkszMTE2IGJhc2VkIHNlcmlhbCBhZGFwdGVycwojZGV2aWNl CQl1YnNhCQkjIEJlbGtpbiBGNVUxMDMgYW5kIGNvbXBhdGlibGUgc2VyaWFsIGFkYXB0ZXJzCmRl dmljZQkJdWZ0ZGkJCSMgRm9yIEZUREkgdXNiIHNlcmlhbCBhZGFwdGVycwojZGV2aWNlCQl1aXBh cQkJIyBTb21lIFdpbkNFIGJhc2VkIGRldmljZXMKI2RldmljZQkJdXBsY29tCQkjIFByb2xpZmlj IFBMLTIzMDMgc2VyaWFsIGFkYXB0ZXJzCiNkZXZpY2UJCXVzbGNvbQkJIyBTSSBMYWJzIENQMjEw MS9DUDIxMDIgc2VyaWFsIGFkYXB0ZXJzCiNkZXZpY2UJCXV2aXNvcgkJIyBWaXNvciBhbmQgUGFs bSBkZXZpY2VzCiNkZXZpY2UJCXV2c2NvbQkJIyBVU0Igc2VyaWFsIHN1cHBvcnQgZm9yIERESSBw b2NrZXQncyBQSFMKZGV2aWNlCQl1Y29tCiMgVVNCIEV0aGVybmV0LCByZXF1aXJlcyBtaWlidXMK I2RldmljZQkJYXVlCQkjIEFETXRlayBVU0IgRXRoZXJuZXQKI2RldmljZQkJYXhlCQkjIEFTSVgg RWxlY3Ryb25pY3MgVVNCIEV0aGVybmV0CiNkZXZpY2UJCWNkY2UJCSMgR2VuZXJpYyBVU0Igb3Zl ciBFdGhlcm5ldAojZGV2aWNlCQljdWUJCSMgQ0FUQyBVU0IgRXRoZXJuZXQKI2RldmljZQkJa3Vl CQkjIEthd2FzYWtpIExTSSBVU0IgRXRoZXJuZXQKI2RldmljZQkJcnVlCQkjIFJlYWxUZWsgUlRM ODE1MCBVU0IgRXRoZXJuZXQKI2RldmljZQkJdWRhdgkJIyBEYXZpY29tIERNOTYwMUUgVVNCCiMg VVNCIFdpcmVsZXNzCiNkZXZpY2UJCXJ1bQkJIyBSYWxpbmsgVGVjaG5vbG9neSBSVDI1MDFVU0Ig d2lyZWxlc3MgTklDcwojZGV2aWNlCQl1YXRoCQkjIEF0aGVyb3MgQVI1NTIzIHdpcmVsZXNzIE5J Q3MKI2RldmljZQkJdXJhbAkJIyBSYWxpbmsgVGVjaG5vbG9neSBSVDI1MDBVU0Igd2lyZWxlc3Mg TklDcwojZGV2aWNlCQl6eWQJCSMgWnlEQVMgemIxMjExL3piMTIxMWIgd2lyZWxlc3MgTklDcwoK IyBGaXJlV2lyZSBzdXBwb3J0CiNkZXZpY2UJCWZpcmV3aXJlCSMgRmlyZVdpcmUgYnVzIGNvZGUK I2RldmljZQkJc2JwCQkjIFNDU0kgb3ZlciBGaXJlV2lyZSAoUmVxdWlyZXMgc2NidXMgYW5kIGRh KQojZGV2aWNlCQlmd2UJCSMgRXRoZXJuZXQgb3ZlciBGaXJlV2lyZSAobm9uLXN0YW5kYXJkISkK I2RldmljZQkJZndpcAkJIyBJUCBvdmVyIEZpcmVXaXJlIChSRkMgMjczNCwzMTQ2KQojZGV2aWNl CQlkY29ucwkJIyBEdW1iIGNvbnNvbGUgZHJpdmVyCiNkZXZpY2UJCWRjb25zX2Nyb20JIyBDb25m aWd1cmF0aW9uIFJPTSBmb3IgZGNvbnMKIwptYWtlb3B0aW9ucwlXSVRIX0NURj0xCmRldmljZQkJ aHdwbWMKZGV2aWNlCQlhbWR0ZW1wCm9wdGlvbnMJCUlQSV9QUkVFTVBUSU9OCiNvcHRpb25zIAlW TV9LTUVNX1NJWkUKI29wdGlvbnMgCVZNX0tNRU1fU0laRV9NQVgKI29wdGlvbnMgCVZNX0tNRU1f U0laRV9TQ0FMRQpvcHRpb25zIAlLU1RBQ0tfUEFHRVM9NQoKZGV2aWNlCQlzb3VuZApkZXZpY2UJ CXNuZF9oZGEKZGV2aWNlIAkJa3N5bXMKb3B0aW9ucyAJQ09VTlRfWElOVkxUTEJfSElUUwkjIENv dW50ZXJzIGZvciBUTEIgZXZlbnRzCm9wdGlvbnMgCUNPVU5UX0lQSVMJCSMgUGVyLUNQVSBJUEkg aW50ZXJydXB0IGNvdW50ZXJzCg== --f46d0442681acb61dc04b7c8d014-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 02:27:28 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A036A106566C; Tue, 31 Jan 2012 02:27:28 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id A77108FC14; Tue, 31 Jan 2012 02:27:27 +0000 (UTC) Received: by eaaa14 with SMTP id a14so1831323eaa.13 for ; Mon, 30 Jan 2012 18:27:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:from:organization:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=lUZzgDWQerXFZeRG3/xG2rWYbXNHRYG4x7wta3w+180=; b=nFIKPa/W0WU48AVVFF7lFSiy8g8hriDnT5ku7Fifaiy6hhA08wrSlSax0/cGLK8rl/ rEaI5aejQNuqAujRzEznmnnSe1o31aBNIRYk+iRJQkwn4A+1IJP6wdxRyaiZ3i1Det25 4VmE3zL9McUkzSXLcG8wLHMuKBZGPyeifOXRs= Received: by 10.213.8.19 with SMTP id f19mr66294ebf.62.1327976846546; Mon, 30 Jan 2012 18:27:26 -0800 (PST) Received: from woodstock.peanuts (host171-147-dynamic.1-79-r.retail.telecomitalia.it. [79.1.147.171]) by mx.google.com with ESMTPS id x4sm80273513eeb.4.2012.01.30.18.27.25 (version=SSLv3 cipher=OTHER); Mon, 30 Jan 2012 18:27:25 -0800 (PST) Sender: Alberto Villa From: Alberto Villa Organization: The FreeBSD Project To: freebsd-ports@freebsd.org Date: Tue, 31 Jan 2012 03:27:20 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.0-RC2; KDE/4.7.4; amd64; ; ) References: <20120130123930.GB40244@azathoth.lan> <20120130223459.GA4707@sirius.xvoid.org> <201201310052.28073.avilla@freebsd.org> In-Reply-To: <201201310052.28073.avilla@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3338764.1nkEhFAoLA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201201310327.24206.avilla@freebsd.org> Cc: Yuri Pankov , ports@freebsd.org, Baptiste Daroussin , current@freebsd.org Subject: Re: [HEADSUP][CFT] pkgng beta1 is out X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 02:27:28 -0000 --nextPart3338764.1nkEhFAoLA Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable On Tuesday 31 January 2012 00:52:25 Alberto Villa wrote: > On Monday 30 January 2012 23:34:59 Yuri Pankov wrote: > > The patch seems to have typos in it (usr_pkgng): > > https://github.com/pkgng/pkgng/blob/master/ports/portmaster.patch#L514 > > https://github.com/pkgng/pkgng/blob/master/ports/portmaster.patch#L528 >=20 > Please, take the patch from here: > https://github.com/xzhavilla/pkgng/blob/master/ports/portmaster.patch >=20 > It should be pulled into the main repository soon. Just a quick note to say that I pushed some updates (now it works with=20 portmaster 3.11 *only*) which have yet to be checked by pkgng masters, so,= =20 unless you want to test the new version, please get it from here: https://github.com/xzhavilla/pkgng/blob/64ec7f352964b186b08aaa6b480afce8da6= 25cb4/ports/portmaster.patch =2D-=20 Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla Heisenberg may have slept here. --nextPart3338764.1nkEhFAoLA Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iJwEAAECAAYFAk8nUYwACgkQ3xiC6kQ1CosDoQQApz1WXQEAFBnf2OWa25X+d1kc cPNmXQMSkECNRi8BX/5CI5ZyXvI9jY26hGa0eRHPV4WUBJJFcs9BshZy3yXJo/Xz eqIBItHp6Imy2KYCXRuhTM1M2EumZbq/j2jzlO9sJpxEmTvxggLnHggpTwHIjtqP boFFXMY3aGdv2uqhSJU= =18r0 -----END PGP SIGNATURE----- --nextPart3338764.1nkEhFAoLA-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 05:56:32 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 860BA1065670; Tue, 31 Jan 2012 05:56:32 +0000 (UTC) (envelope-from jos@catnook.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 391A28FC0C; Tue, 31 Jan 2012 05:56:31 +0000 (UTC) Received: by iaeo4 with SMTP id o4so10302961iae.13 for ; Mon, 30 Jan 2012 21:56:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.169.9 with SMTP id aa9mr923313igc.23.1327989390717; Mon, 30 Jan 2012 21:56:30 -0800 (PST) Received: by 10.42.218.7 with HTTP; Mon, 30 Jan 2012 21:56:30 -0800 (PST) In-Reply-To: <20120130173257.GE40244@azathoth.lan> References: <20120130123930.GB40244@azathoth.lan> <20120130171044.GD40244@azathoth.lan> <20120130173257.GE40244@azathoth.lan> Date: Mon, 30 Jan 2012 21:56:30 -0800 Message-ID: From: Jos Backus To: Baptiste Daroussin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: ports@freebsd.org, current@freebsd.org Subject: Re: [HEADSUP][CFT] pkgng beta1 is out X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 05:56:32 -0000 On Mon, Jan 30, 2012 at 9:32 AM, Baptiste Daroussin wrote: > On Mon, Jan 30, 2012 at 09:21:37AM -0800, Jos Backus wrote: > > On Mon, Jan 30, 2012 at 9:10 AM, Baptiste Daroussin >wrote: > > > > No pkg query can't do this, but this would be a nice addition (something > > > like > > > raw output for info or query) I do like the idea, please create an > issue > > > on the > > > github :)) > > > > > > regards, > > > > Bapt > > > > > > > I just created issue #128, thanks Baptiste! > > > > Cheers, > > Jos > > The time you did that I implemented it :) > > pkg info -R will be in beta2. > > Merci beaucoup :) Salut, Jos > Thank you, > regards, > Bapt > -- Jos Backus jos at catnook.com From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 06:14:47 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E18D0106566B; Tue, 31 Jan 2012 06:14:47 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 976B08FC0A; Tue, 31 Jan 2012 06:14:47 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q0V6EiqB004602 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 30 Jan 2012 22:14:46 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F278720.5020405@freebsd.org> Date: Mon, 30 Jan 2012 22:16:00 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.25) Gecko/20111213 Thunderbird/3.1.17 MIME-Version: 1.0 To: Baptiste Daroussin References: <20120130123930.GB40244@azathoth.lan> In-Reply-To: <20120130123930.GB40244@azathoth.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, ports-announce@freebsd.org, current@freebsd.org Subject: Re: [HEADSUP][CFT] pkgng beta1 is out X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 06:14:48 -0000 On 1/30/12 4:39 AM, Baptiste Daroussin wrote: > Hi, > > pkgng has just reached the beta phase, and has now found its way to the > ports tree (disabled by default). > > 1/ Why pkgng? > ------------ the name sucks though it would be good to fix it before it's built in everywhere. like windows NT, which it is no longer NT. From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 06:23:15 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6162106566B; Tue, 31 Jan 2012 06:23:15 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 99E6D8FC16; Tue, 31 Jan 2012 06:23:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0V6NFi1083216; Tue, 31 Jan 2012 06:23:15 GMT (envelope-from bapt@freebsd.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0V6NF4J083215; Tue, 31 Jan 2012 06:23:15 GMT (envelope-from bapt@freebsd.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@freebsd.org using -f Date: Tue, 31 Jan 2012 07:23:10 +0100 From: Baptiste Daroussin To: Julian Elischer Message-ID: <20120131062310.GF40244@azathoth.lan> References: <20120130123930.GB40244@azathoth.lan> <4F278720.5020405@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Bqc0IY4JZZt50bUr" Content-Disposition: inline In-Reply-To: <4F278720.5020405@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ports@freebsd.org, current@freebsd.org Subject: Re: [HEADSUP][CFT] pkgng beta1 is out X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 06:23:15 -0000 --Bqc0IY4JZZt50bUr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 30, 2012 at 10:16:00PM -0800, Julian Elischer wrote: > On 1/30/12 4:39 AM, Baptiste Daroussin wrote: > > Hi, > > > > pkgng has just reached the beta phase, and has now found its way to the > > ports tree (disabled by default). > > > > 1/ Why pkgng? > > ------------ > the name sucks though > it would be good to fix it before it's built in everywhere. >=20 > like windows NT, which it is no longer NT. >=20 Well if you have better proposition, pkgng is just for now a code name :) the binary itself the library and the port are named simply pkg. bsd.pkgng.mk remain pkgng because when we will have pkg_install dead it wil= l be merged into bsd.port.mk regards, Bapt --Bqc0IY4JZZt50bUr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk8niM4ACgkQ8kTtMUmk6ExtmACdGFyH032W0RdPColbrKpWGDsY sKYAmgNbUCVyjLADbwCwAMlaZ36UQ4mJ =PRk2 -----END PGP SIGNATURE----- --Bqc0IY4JZZt50bUr-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 06:26:10 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78A5E106566B; Tue, 31 Jan 2012 06:26:10 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5A7008FC18; Tue, 31 Jan 2012 06:26:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0V6QAmK083268; Tue, 31 Jan 2012 06:26:10 GMT (envelope-from bapt@freebsd.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0V6QA7t083267; Tue, 31 Jan 2012 06:26:10 GMT (envelope-from bapt@freebsd.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@freebsd.org using -f Date: Tue, 31 Jan 2012 07:26:06 +0100 From: Baptiste Daroussin To: Alberto Villa Message-ID: <20120131062606.GG40244@azathoth.lan> References: <20120130123930.GB40244@azathoth.lan> <20120130223459.GA4707@sirius.xvoid.org> <201201310052.28073.avilla@freebsd.org> <201201310327.24206.avilla@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BzCohdixPhurzSK4" Content-Disposition: inline In-Reply-To: <201201310327.24206.avilla@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Yuri Pankov , ports@freebsd.org, current@freebsd.org Subject: Re: [HEADSUP][CFT] pkgng beta1 is out X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 06:26:10 -0000 --BzCohdixPhurzSK4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 31, 2012 at 03:27:20AM +0100, Alberto Villa wrote: > On Tuesday 31 January 2012 00:52:25 Alberto Villa wrote: > > On Monday 30 January 2012 23:34:59 Yuri Pankov wrote: > > > The patch seems to have typos in it (usr_pkgng): > > > https://github.com/pkgng/pkgng/blob/master/ports/portmaster.patch#L514 > > > https://github.com/pkgng/pkgng/blob/master/ports/portmaster.patch#L528 > >=20 > > Please, take the patch from here: > > https://github.com/xzhavilla/pkgng/blob/master/ports/portmaster.patch > >=20 > > It should be pulled into the main repository soon. >=20 > Just a quick note to say that I pushed some updates (now it works with=20 > portmaster 3.11 *only*) which have yet to be checked by pkgng masters, so= ,=20 > unless you want to test the new version, please get it from here: > https://github.com/xzhavilla/pkgng/blob/64ec7f352964b186b08aaa6b480afce8d= a625cb4/ports/portmaster.patch > --=20 > Alberto Villa, FreeBSD committer > http://people.FreeBSD.org/~avilla >=20 > Heisenberg may have slept here. This has been merged thank you very much, portmaster 3.11 seems to be full working for me. regards, Bapt --BzCohdixPhurzSK4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk8niX4ACgkQ8kTtMUmk6Ey61wCcCgO5162uUg/hiLyBE5A22Jce LUcAoIjXDDwAqXSL93Ejx+kxTiO27vKr =eCpe -----END PGP SIGNATURE----- --BzCohdixPhurzSK4-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 08:57:27 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28FE71065672 for ; Tue, 31 Jan 2012 08:57:27 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id EA9FF8FC12 for ; Tue, 31 Jan 2012 08:57:26 +0000 (UTC) Received: by obcwo16 with SMTP id wo16so7413374obc.13 for ; Tue, 31 Jan 2012 00:57:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.179.70 with SMTP id de6mr34517254obc.22.1328000246128; Tue, 31 Jan 2012 00:57:26 -0800 (PST) Received: by 10.182.149.8 with HTTP; Tue, 31 Jan 2012 00:57:26 -0800 (PST) X-Originating-IP: [93.92.220.178] In-Reply-To: <1327945445.1686.36.camel@revolution.hippie.lan> References: <1327945445.1686.36.camel@revolution.hippie.lan> Date: Tue, 31 Jan 2012 15:57:26 +0700 Message-ID: From: Max Khon To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: FILTER_SCHEDULE_THREAD is not a bit-value X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 08:57:27 -0000 Hello, On Tue, Jan 31, 2012 at 12:44 AM, Ian Lepore wrote: >> sys/bus.h documents the following semantics for FILTER_SCHEDULE_THREAD: >> >> /** >> =C2=A0* @brief Driver interrupt filter return values >> =C2=A0* >> =C2=A0* If a driver provides an interrupt filter routine it must return = an >> =C2=A0* integer consisting of oring together zero or more of the followi= ng >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^ >> =C2=A0* flags: >> =C2=A0* >> =C2=A0* =C2=A0 =C2=A0 =C2=A0FILTER_STRAY =C2=A0 =C2=A0- this device did = not trigger the interrupt >> =C2=A0* =C2=A0 =C2=A0 =C2=A0FILTER_HANDLED =C2=A0- the interrupt has bee= n fully handled and can be EOId >> =C2=A0* =C2=A0 =C2=A0 =C2=A0FILTER_SCHEDULE_THREAD - the threaded interr= upt handler should be >> =C2=A0* =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0scheduled to execute >> =C2=A0* >> =C2=A0* If the driver does not provide a filter, then the interrupt code= will >> =C2=A0* act is if the filter had returned FILTER_SCHEDULE_THREAD. =C2=A0= Note that it >> =C2=A0* is illegal to specify any other flag with FILTER_STRAY and that = it is >> =C2=A0* illegal to not specify either of FILTER_HANDLED or FILTER_SCHEDU= LE_THREAD >> =C2=A0* if FILTER_STRAY is not specified. >> =C2=A0*/ >> #define FILTER_STRAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x01 >> #define FILTER_HANDLED =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x02 >> #define FILTER_SCHEDULE_THREAD =C2=A00x04 >> >> But actually FILTER_SCHEDULE_THREAD is not used as a bit-value (see >> kern/kern_intr.c): >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (!thread) { >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 if (ret =3D=3D FILTER_SCHEDULE_THREAD) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 thread =3D 1; >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 } >> >> There is at least one in-tree driver that could be broken because of >> this (asmc(8), but I found the problem with some other out-of-tree >> driver). >> This should be "if (ret & FILTER_SCHEDULE_THREAD)" instead. Attached >> patch fixes the problem. >> >> What do you think? >> >> Max > > I think returning (FILTER_HANDLED | FILTER_SCHEDULE_THREAD) makes no > sense given the definition "the interrupt has been fully handled and can > be EOId". =C2=A0If you EOI in the primary interrupt context and then sche= dule > a threaded handler to run as well you're likely to need complex locking > between the primary and threaded interrupt handlers and I was under the > impression that's just the sort of thing the filter/threaded scheme was > designed to avoid. I see no sense here. 1) You would have to implement locking anyway to protect concurrent access from ithread/filter and other driver methods (char device or network device callbacks) 2) ithread and filter can already be executed simultaneously even when only FILTER_SCHEDULE_THREAD is returned: when ithread is scheduled to be executed the device can emit a new interrupt and it will be preempted by filter > In other words, the part about ORing together values seems to be staking > out room for future growth, because the current set of flags and the > words about how to use them imply that only one of the current set of > values should be returned at once. No, the text does not imply that only one of the values is supposed to be returned (where did you see it). See also KASSERT checks in intr_event_handle() -- they clearly show that the intention was to allow FILTER_HANDLED and FILTER_SCHEDULE_THREAD to be returned simultaneously. Max From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 10:29:56 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 794831065672 for ; Tue, 31 Jan 2012 10:29:56 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 2D77A8FC0A for ; Tue, 31 Jan 2012 10:29:55 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1RsAch-0000Iv-0P>; Tue, 31 Jan 2012 11:07:35 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RsAcg-000661-TE>; Tue, 31 Jan 2012 11:07:34 +0100 Message-ID: <4F27BD61.3050600@mail.zedat.fu-berlin.de> Date: Tue, 31 Jan 2012 11:07:29 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120118 Thunderbird/9.0 MIME-Version: 1.0 To: Jack Vogel References: <4F271FF4.9010103@zedat.fu-berlin.de> <20120130231125.GC2315@glenbarber.us> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig42374E641C6C2E11D7773747" X-Originating-IP: 130.133.86.198 X-Mailman-Approved-At: Tue, 31 Jan 2012 12:11:18 +0000 Cc: Glen Barber , Current FreeBSD Subject: Re: FreeBSD 10-CURRENT/amd64: revision 230789: [...] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 10:29:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig42374E641C6C2E11D7773747 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 01/31/12 00:14, Jack Vogel wrote: > Yes, it was. Now if I can just figure out what's going on with sparc...= =2E >=20 > Jack >=20 >=20 > On Mon, Jan 30, 2012 at 3:11 PM, Glen Barber > wrote: >=20 > On Mon, Jan 30, 2012 at 11:55:48PM +0100, O. Hartmann wrote: > > The follwoing error occurs hwen trying to compile a kernel (make > > buildworld works fine): > > > > objcopy --strip-debug if_ixgb.ko > > =3D=3D=3D> ixgbe (all) > > clang -O2 -pipe -O2 -fno-strict-aliasing -pipe -pipe -O3 > > -fno-strict-aliasing -march=3Dnative -DSMP -DIXGBE_FDIR -D_KERNEL= > > -DKLD_MODULE -nostdinc -I/usr/src/sys/modules/ixgbe/../../dev/ix= gbe > > -DHAVE_KERNEL_OPTION_HEADERS -include > > /usr/obj/usr/src/sys/THOR/opt_global.h -I. -I@ -I@/contrib/altq > > -fno-common -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/THOR > > -mno-aes -mno-avx -mcmodel=3Dkernel -mno-red-zone -mno-mmx -msoft= -float > > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector > > -std=3Diso9899:1999 -fstack-protector -Wall -Wredundant-decls > > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > > -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign > > -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-op= tion > > -Wno-error-tautological-compare -Wno-error-empty-body > > -Wno-error-parentheses-equality -c > > /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c > > In file included from > /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c:40: > > In file included from > /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.h:96: > > In file included from > > /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe_api.h:38: > > In file included from > > /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe_type.h:38: > > /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe_osdep.h:109:19: > error: > > typedef redefinition with different types ('boolean_t' (aka 'int'= ) vs > > '_Bool') > > typedef boolean_t bool; > > ^ > > @/sys/types.h:271:15: note: previous definition is here > > typedef _Bool bool; > > ^ > > 1 error generated. > > *** Error code 1 > > > > Stop in /usr/src/sys/modules/ixgbe. > > *** Error code 1 > > > > Stop in /usr/src/sys/modules. > > *** Error code 1 > > > > Stop in /usr/obj/usr/src/sys/THOR. > > *** Error code 1 > > > > Stop in /usr/src. > > *** Error code 1 > > > > Stop in /usr/src. > > >=20 > I believe this was just fixed: >=20 > http://svn.freebsd.org/changeset/base/230790 >=20 > Glen Thanks. Works fine again ;-) Oliver --=20 O. Hartmann Freie Universit=E4t Berlin FB Geologische Wissenschaften FR Planetologie und Fernerkundung Campus Lankwitz Malteser-Str. 74 - 100/Haus D 12249 Berlin Tel.: +49 (0) 30 838 70 508 FAX: +49 (0) 30 838 70 837 --------------enig42374E641C6C2E11D7773747 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iF4EAREIAAYFAk8nvWYACgkQU6Ni+wtCKv+eBQD8D1oyHaPiuJRE8j2sGkTYgW4o bffyGP91kI6Qstv6bngA/R6pdW6jvn110Bw83bZjAJ1GkMLre/ojlv0kCNavXjPR =F1tw -----END PGP SIGNATURE----- --------------enig42374E641C6C2E11D7773747-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 15:19:13 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FF3E1065670 for ; Tue, 31 Jan 2012 15:19:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 448178FC15 for ; Tue, 31 Jan 2012 15:19:13 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id EF19546B0C; Tue, 31 Jan 2012 10:19:12 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 823F6B93E; Tue, 31 Jan 2012 10:19:12 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 31 Jan 2012 10:05:16 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <1327945445.1686.36.camel@revolution.hippie.lan> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201201311005.16099.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 31 Jan 2012 10:19:12 -0500 (EST) Cc: Ian Lepore , Max Khon Subject: Re: FILTER_SCHEDULE_THREAD is not a bit-value X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 15:19:13 -0000 On Tuesday, January 31, 2012 3:57:26 am Max Khon wrote: > No, the text does not imply that only one of the values is supposed to > be returned (where did you see it). See also KASSERT checks in > intr_event_handle() -- they clearly show that the intention was to > allow FILTER_HANDLED and FILTER_SCHEDULE_THREAD to be returned > simultaneously. That was the original plan, but I now plan to no longer allow that. I think I posted a thread to that effect on arch@ several months ago. However, in some patches I have to rework ithreads, I remove the bitmask bits and make the return value a simple enum of distinct values. Also, your patch is not really correct I think, note that that code is only in the !INTR_FITLER case, and we don't allow you to OR together those two values in the INTR_FILTER case. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 15:19:15 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 249991065672; Tue, 31 Jan 2012 15:19:15 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id F17448FC17; Tue, 31 Jan 2012 15:19:14 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id A88CC46B0D; Tue, 31 Jan 2012 10:19:14 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0843FB958; Tue, 31 Jan 2012 10:19:14 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 31 Jan 2012 10:06:44 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <20120130195721.GA14612@sandvine.com> In-Reply-To: <20120130195721.GA14612@sandvine.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201201311006.44546.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 31 Jan 2012 10:19:14 -0500 (EST) Cc: Ed Maste Subject: Re: [patch] nextboot(8) arbitrary kernel environment X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 15:19:15 -0000 On Monday, January 30, 2012 2:57:22 pm Ed Maste wrote: > I have a patch to allow nextboot(8) to set arbitrary kernel environment > variables (not just the kernel dir and kernel_options). The usage becomes: > > Usage: nextboot [-e variable=value] [-f] [-k kernel] [-o options] > nextboot -D > > and the new option is documented as: > > -e variable=value > This option adds the provided variable and value to the ker- > nel environment. The value is quoted when written to the > nextboot configuration. > > The patch also makes -k an option (no longer mandatory). The patch is at > http://people.freebsd.org/~emaste/nextboot.diff . I'll commit it in a few > days if no concerns are raised by review or my testing. Nice! I like both of these features. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 15:28:37 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FC5B1065670 for ; Tue, 31 Jan 2012 15:28:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id D01C98FC16 for ; Tue, 31 Jan 2012 15:28:36 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q0VFSTkc065474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Jan 2012 17:28:29 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q0VFSS0M048382; Tue, 31 Jan 2012 17:28:28 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q0VFSSom048381; Tue, 31 Jan 2012 17:28:28 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 31 Jan 2012 17:28:28 +0200 From: Konstantin Belousov To: Paul Ambrose Message-ID: <20120131152828.GF3283@deviant.kiev.zoral.com.ua> References: <20120130063607.GV2726@deviant.kiev.zoral.com.ua> <20120130164316.GW2726@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ni93GHxFvA+th69W" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current Subject: Re: Does anyone try kib's Sandy Bridge PCID patch (pcid.2.patch)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 15:28:37 -0000 --ni93GHxFvA+th69W Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jan 31, 2012 at 09:23:50AM +0800, Paul Ambrose wrote: > ?? 2012??1??31?? ????12:43??Kostik Belousov ?????? > > On Mon, Jan 30, 2012 at 07:08:13PM +0800, Paul Ambrose wrote: > >> ?? 2012??1??30?? ????2:36??Kostik Belousov ?????? > >> > On Mon, Jan 30, 2012 at 10:15:51AM +0800, Paul Ambrose wrote: > >> >> I have two boxes, one is AMD Athlon 610e 2.4G with FreeBSD-current > >> >> patched with pcid.2.patch? It works well without other issue and it > >> >> seem the pcid patch > >> >> does not affect other part of the kernel. The other one is Sandy > >> > Athlons do not have PCID and probably will never implement it. They use > >> > other tricks to get similar optimizations, transparently to the OS. > >> > > >> Just curious, is this AMD similar optimizations > >> Address Space Number (ASN) and Global flag > >> US Patent 6,604,187. > >> http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html > > This and the same-important next item 'The TLB Flush Filter' is what > > I referred to. > > > >> I did not found anything about ASN in the AMD manual > > It is a transparent optimization, which does not require any OS support. > > Intel PCID is completely different, it shall be explicitely handled by OS. > > It is some consequence of the nested pages support, AFAIU. > > > >> > >> >> Bridge i5-2300 with FreeBSD 9 release patched with pcid.1.patch( the > >> >> pcid.2.patch seems > >> >> dependent on AVX and XSAVE stuffs which is available on -current). But > >> >> it hangs up just in a few minutes. I doubt the nvidia-driver which is > >> >> not recompiled with > >> >> patched kernel is the root, I will check this out later, but does > >> >> anyone meet similar problem? > >> > There are two many variations compared to the config I did tested. > >> > I do not see anything obvious in the changes between HEAD and stable/9 > >> > which could be blamed. Nvidia driver might be bigger suspect, but again, > >> > I am not aware of anything wrong with it. > >> > > >> >> > >> >> I have two question about the pcid.2.patch > >> > > >> > Item 2 is clean, I fixed it. > >> > > >> > For the item 1, I was only able to decipher the proposal to optimize > >> > the global shootdown handler to restore the %cr3 with bit 64 set to not > >> > invalidate current PCID. Is there some more changes ? > >> > > >> yes, that is what I meant. I was wondering using another way that each > >> process has different > >> pcid in each active processor, just as the freebsd mips and powerpc > >> uses. But obviously this way > >> is more friendly to non-pcid x86 processor. > > Each vmspace (or pmap) has unique PCID with the patch, at least until > > PCID space (12bit) is not exhausted. To really exhaust it, you need 4095 > > processes, so it is unlikely but possible event with the current settings. > > > Thank you for your explanation. I just disabled nvidia-driver( not > load it) , and > use "buildworld buildkernel" to test the pcid.1.patch with 9-release, > it seems the box reset before > completing the buildkernel, the attachment is my kernel config, would > you mind try it on > 9-release with pcid.1.patch? I will git 10-current a try to see if > there is something wrong with my hardware I just did checkout + buildworld + buildkernel with -j 10 on UFS with PCID turned on, everything finished fine. It is up to date HEAD. sandy% sysctl vm.stats.sys.v_swtch vm.pmap.pcid_save_cnt vm.stats.sys.v_swtch: 13743519 vm.pmap.pcid_save_cnt: 7853519 I.e. the TLB was not flushed one each second context switch. Trying the HEAD with the patch is probably easiest way forward. --ni93GHxFvA+th69W Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk8oCJwACgkQC3+MBN1Mb4i8YACfQce1x7zo1GpSYXkB/dPD3wgi XGUAoK8yATtEXCKSaLQZQA/FuFz3+0n8 =fmkn -----END PGP SIGNATURE----- --ni93GHxFvA+th69W-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 15:36:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1BF9106566B for ; Tue, 31 Jan 2012 15:36:19 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id D717A8FC08 for ; Tue, 31 Jan 2012 15:36:19 +0000 (UTC) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta05.emeryville.ca.mail.comcast.net with comcast id UF7j1i0011HpZEsA5FcKSX; Tue, 31 Jan 2012 15:36:19 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta14.emeryville.ca.mail.comcast.net with comcast id UFcJ1i0124NgCEG8aFcKR2; Tue, 31 Jan 2012 15:36:19 +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 q0VFaGIk020364; Tue, 31 Jan 2012 08:36:16 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Max Khon In-Reply-To: References: <1327945445.1686.36.camel@revolution.hippie.lan> Content-Type: text/plain Date: Tue, 31 Jan 2012 08:36:16 -0700 Message-Id: <1328024176.1662.273.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Current FreeBSD Subject: Re: FILTER_SCHEDULE_THREAD is not a bit-value X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 15:36:20 -0000 On Tue, 2012-01-31 at 15:57 +0700, Max Khon wrote: > Hello, > > On Tue, Jan 31, 2012 at 12:44 AM, Ian Lepore > wrote: > > >> sys/bus.h documents the following semantics for FILTER_SCHEDULE_THREAD: > >> > >> /** > >> * @brief Driver interrupt filter return values > >> * > >> * If a driver provides an interrupt filter routine it must return an > >> * integer consisting of oring together zero or more of the following > >> ^^^^^^^ > >> * flags: > >> * > >> * FILTER_STRAY - this device did not trigger the interrupt > >> * FILTER_HANDLED - the interrupt has been fully handled and can be EOId > >> * FILTER_SCHEDULE_THREAD - the threaded interrupt handler should be > >> * scheduled to execute > >> * > >> * If the driver does not provide a filter, then the interrupt code will > >> * act is if the filter had returned FILTER_SCHEDULE_THREAD. Note that it > >> * is illegal to specify any other flag with FILTER_STRAY and that it is > >> * illegal to not specify either of FILTER_HANDLED or FILTER_SCHEDULE_THREAD > >> * if FILTER_STRAY is not specified. > >> */ > >> #define FILTER_STRAY 0x01 > >> #define FILTER_HANDLED 0x02 > >> #define FILTER_SCHEDULE_THREAD 0x04 > >> > >> But actually FILTER_SCHEDULE_THREAD is not used as a bit-value (see > >> kern/kern_intr.c): > >> > >> if (!thread) { > >> if (ret == FILTER_SCHEDULE_THREAD) > >> thread = 1; > >> } > >> > >> There is at least one in-tree driver that could be broken because of > >> this (asmc(8), but I found the problem with some other out-of-tree > >> driver). > >> This should be "if (ret & FILTER_SCHEDULE_THREAD)" instead. Attached > >> patch fixes the problem. > >> > >> What do you think? > >> > >> Max > > > > I think returning (FILTER_HANDLED | FILTER_SCHEDULE_THREAD) makes no > > sense given the definition "the interrupt has been fully handled and can > > be EOId". If you EOI in the primary interrupt context and then schedule > > a threaded handler to run as well you're likely to need complex locking > > between the primary and threaded interrupt handlers and I was under the > > impression that's just the sort of thing the filter/threaded scheme was > > designed to avoid. > > I see no sense here. > 1) You would have to implement locking anyway to protect concurrent > access from ithread/filter and other driver methods (char device or > network device callbacks) > That is often, but not always, the case. Depending on the hardware and the needs of the driver, the guaranteed temporal separation between primary and threaded interrupt context can reduce the need for locking. In one case I managed to avoid the need to do any locking at all in the primary context (in a pps driver to replace the stock one that lost the ability to handle interrupts in a primary context at all). > 2) ithread and filter can already be executed simultaneously even when > only FILTER_SCHEDULE_THREAD is returned: when ithread is scheduled to > be executed the device can emit a new interrupt and it will be > preempted by filter > No, if the primary-context handler does not return FILTER_HANDLED and the interrupt dispatcher code does not EOI the interrupt until after the threaded handler has run, then another hardware interrupt from that source cannot interrupt the threaded handler. This amounts to implicit temporal synchronization between primary and threaded interrupt contexts that eliminates the need for explicit synchronization using locks. > > In other words, the part about ORing together values seems to be staking > > out room for future growth, because the current set of flags and the > > words about how to use them imply that only one of the current set of > > values should be returned at once. > > No, the text does not imply that only one of the values is supposed to > be returned (where did you see it). See also KASSERT checks in > intr_event_handle() -- they clearly show that the intention was to > allow FILTER_HANDLED and FILTER_SCHEDULE_THREAD to be returned > simultaneously. > > Max I have to admit that the text doesn't specifically forbid returning both values ORed together, but it seems to me that doing so is nonsensical. The reason is the corollary to the above point: if you return FILTER_HANDLED and allow the interrupt to be EOI'd from the primary context, then you have to deal with the possibility of being re-interrupted in the threaded handler. You have to cope with the possiblity of getting a new interrupt before having fully handled the prior one. Hmmm, but I guess I could imagine a situation where the primary context could capture and enqueue information on a list and then return FILTER_HANDLED specifically to request the EOI so that having multiple hardware interrupts occur between invocations of the threaded handler would work out okay. I wonder if that situation happens does the thread get invoked as many times as the primary context ran and returned FILTER_SCHEDULE_THREAD, or does it get invoked just once and has to handle finishing up the work for any number of previous primary-context handler invokations? (Yeah, I could look at the code, but I really need to wrap up my morning mail and get on with my paying-job work. :) Heh, looks like I talked myself into the idea that ORing together the two values might be useful for some drivers. -- Ian From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 16:17:06 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E00C106564A for ; Tue, 31 Jan 2012 16:17:06 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id D30E98FC1D for ; Tue, 31 Jan 2012 16:17:05 +0000 (UTC) Received: by vbbfa15 with SMTP id fa15so208709vbb.13 for ; Tue, 31 Jan 2012 08:17:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=na1ZHNEY5+7JSZ0545Ek8PE/UvoZpD1PIp4PBoXttRo=; b=bzdPsvoso3j2xRXJVBIELqA5lVyQUH6+5FWi/LBPNyGBrWEOrnpV64dgyaqS4Cr5ZB m/rdqTd3RvT45fVgnU7Tj7LH2HZ/wtuHXkVYcaLAtZ0YXh1w+6FPZIHT3cUuXoky7XAz PK6wrpDEbnfXBJobFL5c4PXuecqzc12XUw5XA= MIME-Version: 1.0 Received: by 10.52.76.196 with SMTP id m4mr10582149vdw.112.1328024991422; Tue, 31 Jan 2012 07:49:51 -0800 (PST) Received: by 10.220.187.130 with HTTP; Tue, 31 Jan 2012 07:49:51 -0800 (PST) Date: Tue, 31 Jan 2012 18:49:51 +0300 Message-ID: From: Andrey Fesenko To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: pjd@freebsd.org Subject: gptboot rewrite, bootonce, etc. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 16:17:06 -0000 This work if use ZFS? My issues "Root on ZFS & GPT and boot to ufs partition" http://lists.freebsd.org/pipermail/freebsd-fs/2012-January/013514.html I test # gpart show => 34 625142381 ada0 GPT (298G) 34 128 1 freebsd-boot (64k) 162 26621952 2 freebsd-ufs [bootonce,bootme] (12G) 26622114 8388608 3 freebsd-swap (4.0G) 35010722 590131693 4 freebsd-zfs (281G) system ada0p2 not boot. From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 16:21:35 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 868BB106566C for ; Tue, 31 Jan 2012 16:21:35 +0000 (UTC) (envelope-from pgollucci@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3BCFB8FC16 for ; Tue, 31 Jan 2012 16:21:34 +0000 (UTC) Received: by qcmt40 with SMTP id t40so149466qcm.13 for ; Tue, 31 Jan 2012 08:21:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:x-enigmail-version:content-type; bh=EQL4n3LTlMCvOa2ih/6988cxpMUk4lmhrSV0Kf4KUB8=; b=FtxT2w++ftxa/oBu1ZtrNt1ulbotj5dMq/1Sr5eJOGTH2CA179ghwyNMjMfLD45BDi lDcCGO4SR5CtMHsDDEFww7/KimR1aHqafONsE/fM1F2qvAkyD5Q9kEYg4Y+GGU1aGLB8 9/npyfgq2RMi9HDZYTEC8BOKQA/vC0LLsYyU0= Received: by 10.229.102.72 with SMTP id f8mr8677223qco.51.1328026894346; Tue, 31 Jan 2012 08:21:34 -0800 (PST) Received: from philip.hq.rws (wsip-174-79-184-239.dc.dc.cox.net. [174.79.184.239]) by mx.google.com with ESMTPS id r17sm42142827qap.11.2012.01.31.08.21.32 (version=SSLv3 cipher=OTHER); Tue, 31 Jan 2012 08:21:33 -0800 (PST) Message-ID: <4F281509.5070004@p6m7g8.com> Date: Tue, 31 Jan 2012 16:21:29 +0000 From: "Philip M. Gollucci" Organization: P6M7G8 Inc. User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111029 Thunderbird/7.0.1 MIME-Version: 1.0 To: current@FreeBSD.org X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2C7B19AE3CA7546199AC9E53" X-Mailman-Approved-At: Tue, 31 Jan 2012 16:27:07 +0000 Cc: Subject: em0 failure on 10-current w/ clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 16:21:35 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2C7B19AE3CA7546199AC9E53 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable sudo mv kernel kernel.clang sudo mv kernel.old kernel has me back in action for now on 9.0-RELEASE. What info can I provide to be of help? Jan 31 16:05:31 <4.5> frieza login: ROOT LOGIN (root) ON ttyv0 Jan 31 16:06:03 <18.5> frieza sudo: root : TTY=3Dttyv0 ; PWD=3D/root = ; USER=3Droot ; COMMAND=3D/etc/rc.d/netif restart Jan 31 16:06:03 <0.7> frieza kernel: ifa_del_loopback_route: deletion failed: 3 Jan 31 16:06:03 <0.7> frieza kernel: ifa_add_loopback_route: insertion failed: 17 Jan 31 16:06:05 <0.7> frieza kernel: ifa_del_loopback_route: deletion failed: 3 Jan 31 16:06:05 <0.7> frieza kernel: ifa_add_loopback_route: insertion failed: 17 Jan 31 16:06:05 <0.5> frieza kernel: em0: link state changed to DOWN Jan 31 16:06:09 <3.3> frieza dhclient[2315]: em0: not found Jan 31 16:06:09 <0.5> frieza kernel: em0: link state changed to UP Jan 31 16:06:09 <3.2> frieza dhclient[2315]: exiting. Jan 31 16:06:09 <3.3> frieza dhclient[2316]: connection closed Jan 31 16:06:09 <3.2> frieza dhclient[2316]: exiting. Jan 31 16:06:22 <0.7> frieza kernel: ifa_del_loopback_route: deletion failed: 3 Jan 31 16:06:22 <0.7> frieza kernel: ifa_add_loopback_route: insertion failed: 17 Jan 31 16:06:22 <0.5> frieza kernel: em0: link state changed to DOWN Jan 31 16:06:24 <3.3> frieza dhclient[2345]: em0: not found Jan 31 16:06:24 <0.5> frieza kernel: em0: link state changed to UP Jan 31 16:06:24 <3.2> frieza dhclient[2345]: exiting. Jan 31 16:06:24 <3.3> frieza dhclient[2346]: connection closed Jan 31 16:06:24 <3.2> frieza dhclient[2346]: exiting. Jan 31 16:06:39 <0.7> frieza kernel: ifa_del_loopback_route: deletion failed: 3 Jan 31 16:06:39 <0.7> frieza kernel: ifa_add_loopback_route: insertion failed: 17 Jan 31 16:06:41 <0.7> frieza kernel: ifa_del_loopback_route: deletion failed: 3 Jan 31 16:06:41 <0.7> frieza kernel: ifa_add_loopback_route: insertion failed: 17 Jan 31 16:06:41 <0.5> frieza kernel: em0: link state changed to DOWN Jan 31 16:06:48 <3.3> frieza dhclient[2811]: em0: not found Jan 31 16:06:48 <0.5> frieza kernel: em0: link state changed to UP Jan 31 16:06:48 <3.2> frieza dhclient[2811]: exiting. Jan 31 16:06:48 <3.3> frieza dhclient[2812]: connection closed Jan 31 16:06:48 <3.2> frieza dhclient[2812]: exiting. --=20 ------------------------------------------------------------------------ 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354 Member, Apache Software Foundation Committer, FreeBSD Foundation Consultant, P6M7G8 Inc. Director Operations, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. --------------enig2C7B19AE3CA7546199AC9E53 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPKBULdbiP+9ubjBwRAnryAJ9kJKTGjRW7yZiNKKHvxSYnS/QC5gCfVo+7 CjdWrsLzFx5FcpvJXIWRsdM= =QB6P -----END PGP SIGNATURE----- --------------enig2C7B19AE3CA7546199AC9E53-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 16:49:34 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BA94106566B for ; Tue, 31 Jan 2012 16:49:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 250518FC1D for ; Tue, 31 Jan 2012 16:49:34 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id D288046B06 for ; Tue, 31 Jan 2012 11:49:33 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 64103B960 for ; Tue, 31 Jan 2012 11:49:33 -0500 (EST) From: John Baldwin To: current@freebsd.org Date: Tue, 31 Jan 2012 11:49:32 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201201311149.32760.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 31 Jan 2012 11:49:33 -0500 (EST) Cc: Subject: Race between cron and crontab X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 16:49:34 -0000 A co-worker ran into a race between updating a cron tab via crontab(8) and cron(8) yesterday. Specifically, cron(8) failed to notice that a crontab was updated. The problem is that 1) by default our filesystems only use second granularity for timestamps and 2) cron only caches the seconds portion of a file's timestamp when checking for changes anyway. This means that cron can miss updates to a spool directory if multiple updates to the directory are performed within a single second and cron wakes up to scan the spool directory within the same second and scans it before all of the updates are complete. Specifically, when replacing a crontab, crontab(8) first creates a temporary file in /var/cron/tabs and then uses a rename to install it followed by touching the spool directory to update its modification time. However, the creation of the temporary file already changes the modification time of the directory, and cron may "miss" the rename if it scans the directory in between the creation of the temporary file and the rename. The "fix" I am planning to use locally is to simply force crontab(8) to sleep for a second before it touches the spool directory, thus ensuring that it the touch of the spool directory will use a later modification time than the creation of the temporary file. Note that crontab -r is not affected by this race as it only does one atomic update to the directory (unlink()). Index: crontab.c =================================================================== --- crontab.c (revision 225431) +++ crontab.c (working copy) @@ -604,6 +604,15 @@ replace_cmd() { log_it(RealUser, Pid, "REPLACE", User); + /* + * Creating the 'tn' temp file has already updated the + * modification time of the spool directory. Sleep for a + * second to ensure that poke_daemon() sets a later + * modification time. Otherwise, this can race with the cron + * daemon scanning for updated crontabs. + */ + sleep(1); + poke_daemon(); return (0); -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 17:21:14 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B78D106564A; Tue, 31 Jan 2012 17:21:14 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 719318FC15; Tue, 31 Jan 2012 17:21:13 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.5/8.14.4) with ESMTP id q0VHL8Lm022200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 31 Jan 2012 18:21:08 +0100 (CET) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1328030468; bh=zu0dLcMKzZEQ7+1mHk8QYtGln7v0DyQxl7idcpdcF3g=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=Eqsu4p23Ms/wyyvqYT+kAvmTvg8EuFNhlgmHTTxzkLh5XQ71UHadCwcHiSQEUuqK4 jU6O48sCXcyzTIe/nETzdGfmaCp0/JErrqPptm63vj+5jIN3eL5izPEsXoMlS4+yJI xDmBPE08nrBgJkWoPdVvVNqLMF6nGmB6jaDGosFk= Date: Tue, 31 Jan 2012 18:21:07 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: John Baldwin Message-ID: <20120131172107.GP3489@acme.spoerlein.net> Mail-Followup-To: John Baldwin , Tijl Coosemans , freebsd-current@freebsd.org References: <201201191739.48327.tijl@coosemans.org> <201201251129.22368.jhb@freebsd.org> <201201291608.16741.tijl@coosemans.org> <201201300936.45290.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201201300936.45290.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Tijl Coosemans , freebsd-current@freebsd.org Subject: Re: posix_fadvise noreuse disables file caching X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 17:21:14 -0000 On Mon, 2012-01-30 at 09:36:45 -0500, John Baldwin wrote: > On Sunday, January 29, 2012 10:08:10 am Tijl Coosemans wrote: > > On Wednesday 25 January 2012 17:29:22 John Baldwin wrote: > > > On Friday, January 20, 2012 2:12:13 pm John Baldwin wrote: > > >> On Thursday, January 19, 2012 11:39:42 am Tijl Coosemans wrote: > > >>> I recently noticed that multimedia/vlc generates a lot of disk IO when > > >>> playing media files. For instance, when playing a 320kbps mp3 gstat > > >>> reports about 1250kBps (=10000kbps). That's quite a lot of overhead. > > >>> > > >>> It turns out that vlc sets POSIX_FADV_NOREUSE on the entire file and > > >>> reads in chunks of 1028 bytes. FreeBSD implements NOREUSE as if > > >>> O_DIRECT was specified during open(2), i.e. it disables all caching. > > >>> That means every 1028 byte read turns into a 32KiB read (new default > > >>> block size in 9.0) which explains the above numbers. > > >>> > > >>> I've copied the relevant vlc code below (modules/access/file.c:Open()). > > >>> It's interesting to see that on OSX it sets F_NOCACHE which disables > > >>> caching too, but combined with F_RDAHEAD there's still read-ahead > > >>> caching. > > >>> > > >>> I don't think POSIX intended for NOREUSE to mean O_DIRECT. It should > > >>> still cache data (and even do read-ahead if F_RDAHEAD is specified), > > >>> and once data is fetched from the cache, it can be marked WONTNEED. > > >> > > >> POSIX doesn't specify O_DIRECT, so it's not clear what it asks for. > > >> > > >>> Is it possible to implement it this way, or if not to just ignore > > >>> the NOREUSE hint for now? > > >> > > >> I think it would be good to improve NOREUSE, though I had sort of > > >> assumed that applications using NOREUSE would do their own buffering > > >> and read full blocks. We could perhaps reimplement NOREUSE by doing > > >> the equivalent of POSIX_FADV_DONTNEED after each read to free buffers > > >> and pages after the data is copied out to userland. I also have an > > >> XXX about whether or not NOREUSE should still allow read-ahead as it > > >> isn't very clear what the right thing to do there is. HP-UX (IIRC) > > >> has an fadvise() that lets you specify multiple policies, so you > > >> could specify both NOREUSE and SEQUENTIAL for a single region to > > >> get read-ahead but still release memory once the data is read once. > > > > > > So I've came up with this untested patch. It uses > > > VOP_ADVISE(FADV_DONTNEED) after read(2) calls to a NOREUSE region, and > > > leaves read-ahead caching enabled for NOREUSE. FADV_DONTNEED doesn't > > > do any good really for writes (it only flushes clean buffers), so I've > > > left write(2) operations as using IO_DIRECT still. Does this sound > > > reasonable? I've not yet tested this at all: > > > > The patch drastically improves vlc, but there's still a tiny overhead. > > Without NOREUSE the disk is read in chunks of 128KiB (F_RDAHEAD buffer > > size). With NOREUSE there's an extra transfer of 32KiB (block size). > > This is probably because vlc is not reading on block boundaries, so the > noreuse is throwing away partial blocks at the end of a read that then have to > be re-read. We could maybe fix this by making FADV_DONTNEED only throw > away completely-contained blocks rather than completely-contained pages. > However, this will probably result in NOREUSE not actually throwing away > anything at all if an app always reads sub-blocksize chunks. > > We could maybe make the case of vlc work ok in this case though by allowing > an extension where you can do 'posix_fadvise(SEQUENTIAL | NOREUSE)', and > in this case we could make the VOP_ADVISE(DONTNEED) in read() use an offset > of 0 rather than the start of the read request. > > However, posix_fadvise() really is going to work best if the userland > application reads aligned FS blocks. I find it questionable in general that an application can tell the system what to do wrt. caching. Perhaps I'm running 100s of VLC players all on the same file and actually *do* want reads to be cached? What happens if I seek back in the file? It has to do a potentially high-latency read again. The system has a better overview of blocks that are frequently being requested than any individual application. I fully understand the intention, and in 99.99% of the cases, this data *is* just being read once so there's no need to cache any reads for actually requested data. But as the example shows, requested data is not necessarily the data that lower layers have to fetch from the disk. Perhaps taking to VLC people on why they think this is useful and where it actually, measurably helped them would be interesting. Sorry if this is all perfectly obvious Uli From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 17:31:13 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35BD21065670 for ; Tue, 31 Jan 2012 17:31:13 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id DE5B58FC15 for ; Tue, 31 Jan 2012 17:31:11 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 1C7D6492; Tue, 31 Jan 2012 18:31:08 +0100 (CET) Date: Tue, 31 Jan 2012 18:29:53 +0100 From: Pawel Jakub Dawidek To: Andrey Fesenko Message-ID: <20120131172953.GA1694@garage.freebsd.pl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: gptboot rewrite, bootonce, etc. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 17:31:13 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 31, 2012 at 06:49:51PM +0300, Andrey Fesenko wrote: > This work if use ZFS? > My issues "Root on ZFS & GPT and boot to ufs partition" > http://lists.freebsd.org/pipermail/freebsd-fs/2012-January/013514.html >=20 > I test > # gpart show > =3D> 34 625142381 ada0 GPT (298G) > 34 128 1 freebsd-boot (64k) > 162 26621952 2 freebsd-ufs [bootonce,bootme] (12G) > 26622114 8388608 3 freebsd-swap (4.0G) > 35010722 590131693 4 freebsd-zfs (281G) >=20 > system ada0p2 not boot. This functionality only works with UFS (gptboot). --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --azLHFNyN32YCQGCU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk8oJRAACgkQForvXbEpPzTongCg9NIXoORNXJwqNR3STQw+gdSq p9oAoMzCvLf/1EH/6WRNnwJFTo8602mv =Vjd7 -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 17:57:53 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC8211065676 for ; Tue, 31 Jan 2012 17:57:53 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 879368FC1A for ; Tue, 31 Jan 2012 17:57:53 +0000 (UTC) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta04.emeryville.ca.mail.comcast.net with comcast id UHr31i0020vp7WLA4Hxtjs; Tue, 31 Jan 2012 17:57:53 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta05.emeryville.ca.mail.comcast.net with comcast id UHxs1i00K4NgCEG8RHxsrh; Tue, 31 Jan 2012 17:57:53 +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 q0VHvoxV020505; Tue, 31 Jan 2012 10:57:50 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: John Baldwin In-Reply-To: <201201311149.32760.jhb@freebsd.org> References: <201201311149.32760.jhb@freebsd.org> Content-Type: multipart/mixed; boundary="=-8C+JykMdlr7Y4wfwfSp0" Date: Tue, 31 Jan 2012 10:57:50 -0700 Message-Id: <1328032670.1662.333.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port Cc: current@freebsd.org Subject: Re: Race between cron and crontab X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 17:57:53 -0000 --=-8C+JykMdlr7Y4wfwfSp0 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2012-01-31 at 11:49 -0500, John Baldwin wrote: > A co-worker ran into a race between updating a cron tab via crontab(8) and > cron(8) yesterday. Specifically, cron(8) failed to notice that a crontab was > updated. The problem is that 1) by default our filesystems only use second > granularity for timestamps and 2) cron only caches the seconds portion of a > file's timestamp when checking for changes anyway. This means that cron can > miss updates to a spool directory if multiple updates to the directory are > performed within a single second and cron wakes up to scan the spool directory > within the same second and scans it before all of the updates are complete. > > Specifically, when replacing a crontab, crontab(8) first creates a temporary > file in /var/cron/tabs and then uses a rename to install it followed by > touching the spool directory to update its modification time. However, the > creation of the temporary file already changes the modification time of the > directory, and cron may "miss" the rename if it scans the directory in between > the creation of the temporary file and the rename. > > The "fix" I am planning to use locally is to simply force crontab(8) to sleep > for a second before it touches the spool directory, thus ensuring that it the > touch of the spool directory will use a later modification time than the > creation of the temporary file. > > Note that crontab -r is not affected by this race as it only does one atomic > update to the directory (unlink()). > > Index: crontab.c > =================================================================== > --- crontab.c (revision 225431) > +++ crontab.c (working copy) > @@ -604,6 +604,15 @@ replace_cmd() { > > log_it(RealUser, Pid, "REPLACE", User); > > + /* > + * Creating the 'tn' temp file has already updated the > + * modification time of the spool directory. Sleep for a > + * second to ensure that poke_daemon() sets a later > + * modification time. Otherwise, this can race with the cron > + * daemon scanning for updated crontabs. > + */ > + sleep(1); > + > poke_daemon(); > > return (0); Maybe this is overly pedantic, but that solution still allows the possibility of the same sort of race if a user updates their crontab in the same second as an admin saves a new /etc/crontab, because cron takes the max timestamp of /etc/crontab and /var/cron/tabs and compares it against the database-rebuild timestamp. A possible solution on the daemon side of things might be something like the attached, but I should state (nay, shout) that I haven't looked beyond these few lines to see if there are any unintended side effects to such a change. -- Ian --=-8C+JykMdlr7Y4wfwfSp0 Content-Disposition: inline; filename="cron-database.patch" Content-Type: text/x-patch; name="cron-database.patch"; charset="us-ascii" Content-Transfer-Encoding: 7bit diff -r eb5f4971de86 usr.sbin/cron/cron/database.c --- usr.sbin/cron/cron/database.c Fri Jan 20 16:12:15 2012 -0700 +++ usr.sbin/cron/cron/database.c Tue Jan 31 10:48:32 2012 -0700 @@ -72,7 +72,7 @@ load_database(old_db) * so is guaranteed to be different than the stat() mtime the first * time this function is called. */ - if (old_db->mtime == TMAX(statbuf.st_mtime, syscron_stat.st_mtime)) { + if (old_db->mtime > TMAX(statbuf.st_mtime, syscron_stat.st_mtime)) { Debug(DLOAD, ("[%d] spool dir mtime unch, no load needed.\n", getpid())) return; @@ -83,7 +83,7 @@ load_database(old_db) * actually changed. Whatever is left in the old database when * we're done is chaff -- crontabs that disappeared. */ - new_db.mtime = TMAX(statbuf.st_mtime, syscron_stat.st_mtime); + new_db.mtime = 1 + TMAX(statbuf.st_mtime, syscron_stat.st_mtime); new_db.head = new_db.tail = NULL; if (syscron_stat.st_mtime) { --=-8C+JykMdlr7Y4wfwfSp0-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 18:35:18 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40423106566B for ; Tue, 31 Jan 2012 18:35:18 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 018588FC1B for ; Tue, 31 Jan 2012 18:35:18 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:4dd4:e805:cea2:78dc] (unknown [IPv6:2001:7b8:3a7:0:4dd4:e805:cea2:78dc]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id D48555C59; Tue, 31 Jan 2012 19:35:16 +0100 (CET) Message-ID: <4F283465.3000506@FreeBSD.org> Date: Tue, 31 Jan 2012 19:35:17 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120124 Thunderbird/10.0 MIME-Version: 1.0 To: "Philip M. Gollucci" References: <4F281509.5070004@p6m7g8.com> In-Reply-To: <4F281509.5070004@p6m7g8.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: em0 failure on 10-current w/ clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 18:35:18 -0000 On 2012-01-31 17:21, Philip M. Gollucci wrote: > sudo mv kernel kernel.clang > sudo mv kernel.old kernel > > has me back in action for now on 9.0-RELEASE. > > What info can I provide to be of help? > > > Jan 31 16:05:31<4.5> frieza login: ROOT LOGIN (root) ON ttyv0 > Jan 31 16:06:03<18.5> frieza sudo: root : TTY=ttyv0 ; PWD=/root ; > USER=root ; COMMAND=/etc/rc.d/netif restart > Jan 31 16:06:03<0.7> frieza kernel: ifa_del_loopback_route: deletion > failed: 3 > Jan 31 16:06:03<0.7> frieza kernel: ifa_add_loopback_route: insertion > failed: 17 > Jan 31 16:06:05<0.7> frieza kernel: ifa_del_loopback_route: deletion > failed: 3 > Jan 31 16:06:05<0.7> frieza kernel: ifa_add_loopback_route: insertion > failed: 17 > Jan 31 16:06:05<0.5> frieza kernel: em0: link state changed to DOWN > Jan 31 16:06:09<3.3> frieza dhclient[2315]: em0: not found I don't think it has anything to do with clang per se; there were some incompatibilities introduced in ifconfig's ioctls, so you must upgrade world before being able to use any networking. This is very annoying if you want to install of NFS... :( From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 18:42:27 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2A14106566C for ; Tue, 31 Jan 2012 18:42:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 974368FC0A for ; Tue, 31 Jan 2012 18:42:27 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 4CD3046B09; Tue, 31 Jan 2012 13:42:27 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D09E4B91E; Tue, 31 Jan 2012 13:42:26 -0500 (EST) From: John Baldwin To: Ulrich =?iso-8859-1?q?Sp=F6rlein?= Date: Tue, 31 Jan 2012 13:21:47 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <201201191739.48327.tijl@coosemans.org> <201201300936.45290.jhb@freebsd.org> <20120131172107.GP3489@acme.spoerlein.net> In-Reply-To: <20120131172107.GP3489@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201201311321.47714.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 31 Jan 2012 13:42:26 -0500 (EST) Cc: Tijl Coosemans , freebsd-current@freebsd.org Subject: Re: posix_fadvise noreuse disables file caching X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 18:42:27 -0000 On Tuesday, January 31, 2012 12:21:07 pm Ulrich Sp=F6rlein wrote: > On Mon, 2012-01-30 at 09:36:45 -0500, John Baldwin wrote: > > On Sunday, January 29, 2012 10:08:10 am Tijl Coosemans wrote: > > > On Wednesday 25 January 2012 17:29:22 John Baldwin wrote: > > > > On Friday, January 20, 2012 2:12:13 pm John Baldwin wrote: > > > >> On Thursday, January 19, 2012 11:39:42 am Tijl Coosemans wrote: > > > >>> I recently noticed that multimedia/vlc generates a lot of disk IO= when > > > >>> playing media files. For instance, when playing a 320kbps mp3 gst= at > > > >>> reports about 1250kBps (=3D10000kbps). That's quite a lot of over= head. > > > >>>=20 > > > >>> It turns out that vlc sets POSIX_FADV_NOREUSE on the entire file = and > > > >>> reads in chunks of 1028 bytes. FreeBSD implements NOREUSE as if > > > >>> O_DIRECT was specified during open(2), i.e. it disables all cachi= ng. > > > >>> That means every 1028 byte read turns into a 32KiB read (new defa= ult > > > >>> block size in 9.0) which explains the above numbers. > > > >>>=20 > > > >>> I've copied the relevant vlc code below (modules/access/file.c:Op= en()). > > > >>> It's interesting to see that on OSX it sets F_NOCACHE which disab= les > > > >>> caching too, but combined with F_RDAHEAD there's still read-ahead > > > >>> caching. > > > >>>=20 > > > >>> I don't think POSIX intended for NOREUSE to mean O_DIRECT. It sho= uld > > > >>> still cache data (and even do read-ahead if F_RDAHEAD is specifie= d), > > > >>> and once data is fetched from the cache, it can be marked WONTNEE= D. > > > >>=20 > > > >> POSIX doesn't specify O_DIRECT, so it's not clear what it asks for. > > > >>=20 > > > >>> Is it possible to implement it this way, or if not to just ignore > > > >>> the NOREUSE hint for now? > > > >>=20 > > > >> I think it would be good to improve NOREUSE, though I had sort of > > > >> assumed that applications using NOREUSE would do their own bufferi= ng > > > >> and read full blocks. We could perhaps reimplement NOREUSE by doi= ng > > > >> the equivalent of POSIX_FADV_DONTNEED after each read to free buff= ers > > > >> and pages after the data is copied out to userland. I also have an > > > >> XXX about whether or not NOREUSE should still allow read-ahead as = it > > > >> isn't very clear what the right thing to do there is. HP-UX (IIRC) > > > >> has an fadvise() that lets you specify multiple policies, so you > > > >> could specify both NOREUSE and SEQUENTIAL for a single region to > > > >> get read-ahead but still release memory once the data is read once. > > > > > > > > So I've came up with this untested patch. It uses > > > > VOP_ADVISE(FADV_DONTNEED) after read(2) calls to a NOREUSE region, = and > > > > leaves read-ahead caching enabled for NOREUSE. FADV_DONTNEED doesn= 't > > > > do any good really for writes (it only flushes clean buffers), so I= 've > > > > left write(2) operations as using IO_DIRECT still. Does this sound > > > > reasonable? I've not yet tested this at all: > > >=20 > > > The patch drastically improves vlc, but there's still a tiny overhead. > > > Without NOREUSE the disk is read in chunks of 128KiB (F_RDAHEAD buffer > > > size). With NOREUSE there's an extra transfer of 32KiB (block size). > >=20 > > This is probably because vlc is not reading on block boundaries, so the= =20 > > noreuse is throwing away partial blocks at the end of a read that then = have to=20 > > be re-read. We could maybe fix this by making FADV_DONTNEED only throw > > away completely-contained blocks rather than completely-contained pages. > > However, this will probably result in NOREUSE not actually throwing away > > anything at all if an app always reads sub-blocksize chunks. > >=20 > > We could maybe make the case of vlc work ok in this case though by allo= wing > > an extension where you can do 'posix_fadvise(SEQUENTIAL | NOREUSE)', and > > in this case we could make the VOP_ADVISE(DONTNEED) in read() use an of= fset > > of 0 rather than the start of the read request. > >=20 > > However, posix_fadvise() really is going to work best if the userland=20 > > application reads aligned FS blocks. >=20 > I find it questionable in general that an application can tell the > system what to do wrt. caching. Perhaps I'm running 100s of VLC players > all on the same file and actually *do* want reads to be cached? >=20 > What happens if I seek back in the file? It has to do a potentially > high-latency read again. The system has a better overview of blocks that > are frequently being requested than any individual application. >=20 > I fully understand the intention, and in 99.99% of the cases, this data > *is* just being read once so there's no need to cache any reads for > actually requested data. But as the example shows, requested data is not > necessarily the data that lower layers have to fetch from the disk. >=20 > Perhaps taking to VLC people on why they think this is useful and where > it actually, measurably helped them would be interesting. >=20 > Sorry if this is all perfectly obvious There are certainly cases where the user can choose to run specific apps in such a way where this makes sense, so the OS needs this functionality. As to whether or not specific apps should use these APIs or if they should make use of these APIs configurable, that is a question for each app (e.g. vlc). However, the OS should provide the tools. =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 18:42:29 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B2BA1065787 for ; Tue, 31 Jan 2012 18:42:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6CAA58FC0C for ; Tue, 31 Jan 2012 18:42:28 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 0742846B17; Tue, 31 Jan 2012 13:42:28 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7A174B960; Tue, 31 Jan 2012 13:42:27 -0500 (EST) From: John Baldwin To: Ian Lepore Date: Tue, 31 Jan 2012 13:30:15 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <201201311149.32760.jhb@freebsd.org> <1328032670.1662.333.camel@revolution.hippie.lan> In-Reply-To: <1328032670.1662.333.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201201311330.15480.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 31 Jan 2012 13:42:27 -0500 (EST) Cc: current@freebsd.org Subject: Re: Race between cron and crontab X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 18:42:29 -0000 On Tuesday, January 31, 2012 12:57:50 pm Ian Lepore wrote: > On Tue, 2012-01-31 at 11:49 -0500, John Baldwin wrote: > > A co-worker ran into a race between updating a cron tab via crontab(8) and > > cron(8) yesterday. Specifically, cron(8) failed to notice that a crontab was > > updated. The problem is that 1) by default our filesystems only use second > > granularity for timestamps and 2) cron only caches the seconds portion of a > > file's timestamp when checking for changes anyway. This means that cron can > > miss updates to a spool directory if multiple updates to the directory are > > performed within a single second and cron wakes up to scan the spool directory > > within the same second and scans it before all of the updates are complete. > > > > Specifically, when replacing a crontab, crontab(8) first creates a temporary > > file in /var/cron/tabs and then uses a rename to install it followed by > > touching the spool directory to update its modification time. However, the > > creation of the temporary file already changes the modification time of the > > directory, and cron may "miss" the rename if it scans the directory in between > > the creation of the temporary file and the rename. > > > > The "fix" I am planning to use locally is to simply force crontab(8) to sleep > > for a second before it touches the spool directory, thus ensuring that it the > > touch of the spool directory will use a later modification time than the > > creation of the temporary file. > > > > Note that crontab -r is not affected by this race as it only does one atomic > > update to the directory (unlink()). > > > > Index: crontab.c > > =================================================================== > > --- crontab.c (revision 225431) > > +++ crontab.c (working copy) > > @@ -604,6 +604,15 @@ replace_cmd() { > > > > log_it(RealUser, Pid, "REPLACE", User); > > > > + /* > > + * Creating the 'tn' temp file has already updated the > > + * modification time of the spool directory. Sleep for a > > + * second to ensure that poke_daemon() sets a later > > + * modification time. Otherwise, this can race with the cron > > + * daemon scanning for updated crontabs. > > + */ > > + sleep(1); > > + > > poke_daemon(); > > > > return (0); > > Maybe this is overly pedantic, but that solution still allows the > possibility of the same sort of race if a user updates their crontab in > the same second as an admin saves a new /etc/crontab, because cron takes > the max timestamp of /etc/crontab and /var/cron/tabs and compares it > against the database-rebuild timestamp. Hmm, I'm not sure I see the race in that case. If the /etc/crontab file matches the timestamp of the spool directory before the utimes() call after the one-second sleep, then it will still rescan it on the next check when it notices a newer timestamp on the spool directory. If it is the same timestamp as the second timestamp on the spool directory, then the scan is guaranteed to have not started before that second began, meaning that the crontab(8) process editing the user's crontab must have passed the rename, so the scan will see the user's new crontab. > A possible solution on the daemon side of things might be something like > the attached, but I should state (nay, shout) that I haven't looked > beyond these few lines to see if there are any unintended side effects > to such a change. I think this patch doesn't change anything at all actually. It is certainly subject to the original race I described if you do not use the patch in crontab(8) itself. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 20:13:37 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBFE11065670 for ; Tue, 31 Jan 2012 20:13:37 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id C164B8FC12 for ; Tue, 31 Jan 2012 20:13:37 +0000 (UTC) Received: from omta11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by qmta04.emeryville.ca.mail.comcast.net with comcast id UL8v1i0070mlR8UA4LDdTX; Tue, 31 Jan 2012 20:13:37 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta11.emeryville.ca.mail.comcast.net with comcast id ULDc1i00b4NgCEG8XLDcTt; Tue, 31 Jan 2012 20:13:37 +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 q0VKDYf2020627; Tue, 31 Jan 2012 13:13:34 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: John Baldwin In-Reply-To: <201201311330.15480.jhb@freebsd.org> References: <201201311149.32760.jhb@freebsd.org> <1328032670.1662.333.camel@revolution.hippie.lan> <201201311330.15480.jhb@freebsd.org> Content-Type: text/plain Date: Tue, 31 Jan 2012 13:13:34 -0700 Message-Id: <1328040814.1662.383.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Race between cron and crontab X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 20:13:37 -0000 On Tue, 2012-01-31 at 13:30 -0500, John Baldwin wrote: > On Tuesday, January 31, 2012 12:57:50 pm Ian Lepore wrote: > > On Tue, 2012-01-31 at 11:49 -0500, John Baldwin wrote: > > > A co-worker ran into a race between updating a cron tab via crontab(8) and > > > cron(8) yesterday. Specifically, cron(8) failed to notice that a crontab was > > > updated. The problem is that 1) by default our filesystems only use second > > > granularity for timestamps and 2) cron only caches the seconds portion of a > > > file's timestamp when checking for changes anyway. This means that cron can > > > miss updates to a spool directory if multiple updates to the directory are > > > performed within a single second and cron wakes up to scan the spool directory > > > within the same second and scans it before all of the updates are complete. > > > > > > Specifically, when replacing a crontab, crontab(8) first creates a temporary > > > file in /var/cron/tabs and then uses a rename to install it followed by > > > touching the spool directory to update its modification time. However, the > > > creation of the temporary file already changes the modification time of the > > > directory, and cron may "miss" the rename if it scans the directory in between > > > the creation of the temporary file and the rename. > > > > > > The "fix" I am planning to use locally is to simply force crontab(8) to sleep > > > for a second before it touches the spool directory, thus ensuring that it the > > > touch of the spool directory will use a later modification time than the > > > creation of the temporary file. > > > > > > Note that crontab -r is not affected by this race as it only does one atomic > > > update to the directory (unlink()). > > > > > > Index: crontab.c > > > =================================================================== > > > --- crontab.c (revision 225431) > > > +++ crontab.c (working copy) > > > @@ -604,6 +604,15 @@ replace_cmd() { > > > > > > log_it(RealUser, Pid, "REPLACE", User); > > > > > > + /* > > > + * Creating the 'tn' temp file has already updated the > > > + * modification time of the spool directory. Sleep for a > > > + * second to ensure that poke_daemon() sets a later > > > + * modification time. Otherwise, this can race with the cron > > > + * daemon scanning for updated crontabs. > > > + */ > > > + sleep(1); > > > + > > > poke_daemon(); > > > > > > return (0); > > > > Maybe this is overly pedantic, but that solution still allows the > > possibility of the same sort of race if a user updates their crontab in > > the same second as an admin saves a new /etc/crontab, because cron takes > > the max timestamp of /etc/crontab and /var/cron/tabs and compares it > > against the database-rebuild timestamp. > > Hmm, I'm not sure I see the race in that case. If the /etc/crontab file > matches the timestamp of the spool directory before the utimes() call > after the one-second sleep, then it will still rescan it on the next > check when it notices a newer timestamp on the spool directory. If > it is the same timestamp as the second timestamp on the spool directory, > then the scan is guaranteed to have not started before that second began, > meaning that the crontab(8) process editing the user's crontab must have > passed the rename, so the scan will see the user's new crontab. > > > A possible solution on the daemon side of things might be something like > > the attached, but I should state (nay, shout) that I haven't looked > > beyond these few lines to see if there are any unintended side effects > > to such a change. > > I think this patch doesn't change anything at all actually. It is > certainly subject to the original race I described if you do not use > the patch in crontab(8) itself. > You're right about my patch not fixing anything; I didn't think hard enough before I started typing. But I think the problem I was trying to get at with /etc/crontab still exists with your patch; it would be triggered if a user updated their crontab and after the 1 second sleep the directory timestamp gets updated and cron rebuilds the database, and then right after that but still in the same second /etc/crontab gets written. (That's why I was trying, however feebly, to move the solution into the daemon.) Maybe the simple answer is for admins to be sure not to save changes to /etc/crontab during the xx:xx:00 second, or with your patch, :01. (I'm kidding, of course. The fact that cron likes to wake up at the top of minute is no g'tee that it actually does so every time.) Once you start thinking along the "no g'tee" lines you realize that two users can be updating their tabs concurrently, and one arrives in poke_daemon() and grabs the current time (let's say it's noon) then gets preempted for a long while before calling utimes(), the other user runs through poke_daemon() and updates the directory timestamp to 12:00:01, then the first process gets some cycles again and re-updates the timestamp to 12:00:00. Ooopsie, we've achieved a complex and annoying proof of the idea that timestamps alone aren't an adequate synchronization primitive. -- Ian From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 22:03:08 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C221F1065676 for ; Tue, 31 Jan 2012 22:03:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 823558FC0C for ; Tue, 31 Jan 2012 22:03:08 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 2634D46B06; Tue, 31 Jan 2012 17:03:08 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7ED04B921; Tue, 31 Jan 2012 17:03:07 -0500 (EST) From: John Baldwin To: Ian Lepore Date: Tue, 31 Jan 2012 16:24:15 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <201201311149.32760.jhb@freebsd.org> <201201311330.15480.jhb@freebsd.org> <1328040814.1662.383.camel@revolution.hippie.lan> In-Reply-To: <1328040814.1662.383.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201201311624.15993.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 31 Jan 2012 17:03:07 -0500 (EST) Cc: current@freebsd.org Subject: Re: Race between cron and crontab X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 22:03:08 -0000 On Tuesday, January 31, 2012 3:13:34 pm Ian Lepore wrote: > On Tue, 2012-01-31 at 13:30 -0500, John Baldwin wrote: > > On Tuesday, January 31, 2012 12:57:50 pm Ian Lepore wrote: > > > On Tue, 2012-01-31 at 11:49 -0500, John Baldwin wrote: > > > > A co-worker ran into a race between updating a cron tab via crontab(8) and > > > > cron(8) yesterday. Specifically, cron(8) failed to notice that a crontab was > > > > updated. The problem is that 1) by default our filesystems only use second > > > > granularity for timestamps and 2) cron only caches the seconds portion of a > > > > file's timestamp when checking for changes anyway. This means that cron can > > > > miss updates to a spool directory if multiple updates to the directory are > > > > performed within a single second and cron wakes up to scan the spool directory > > > > within the same second and scans it before all of the updates are complete. > > > > > > > > Specifically, when replacing a crontab, crontab(8) first creates a temporary > > > > file in /var/cron/tabs and then uses a rename to install it followed by > > > > touching the spool directory to update its modification time. However, the > > > > creation of the temporary file already changes the modification time of the > > > > directory, and cron may "miss" the rename if it scans the directory in between > > > > the creation of the temporary file and the rename. > > > > > > > > The "fix" I am planning to use locally is to simply force crontab(8) to sleep > > > > for a second before it touches the spool directory, thus ensuring that it the > > > > touch of the spool directory will use a later modification time than the > > > > creation of the temporary file. > > > > > > > > Note that crontab -r is not affected by this race as it only does one atomic > > > > update to the directory (unlink()). > > > > > > > > Index: crontab.c > > > > =================================================================== > > > > --- crontab.c (revision 225431) > > > > +++ crontab.c (working copy) > > > > @@ -604,6 +604,15 @@ replace_cmd() { > > > > > > > > log_it(RealUser, Pid, "REPLACE", User); > > > > > > > > + /* > > > > + * Creating the 'tn' temp file has already updated the > > > > + * modification time of the spool directory. Sleep for a > > > > + * second to ensure that poke_daemon() sets a later > > > > + * modification time. Otherwise, this can race with the cron > > > > + * daemon scanning for updated crontabs. > > > > + */ > > > > + sleep(1); > > > > + > > > > poke_daemon(); > > > > > > > > return (0); > > > > > > Maybe this is overly pedantic, but that solution still allows the > > > possibility of the same sort of race if a user updates their crontab in > > > the same second as an admin saves a new /etc/crontab, because cron takes > > > the max timestamp of /etc/crontab and /var/cron/tabs and compares it > > > against the database-rebuild timestamp. > > > > Hmm, I'm not sure I see the race in that case. If the /etc/crontab file > > matches the timestamp of the spool directory before the utimes() call > > after the one-second sleep, then it will still rescan it on the next > > check when it notices a newer timestamp on the spool directory. If > > it is the same timestamp as the second timestamp on the spool directory, > > then the scan is guaranteed to have not started before that second began, > > meaning that the crontab(8) process editing the user's crontab must have > > passed the rename, so the scan will see the user's new crontab. > > > > > A possible solution on the daemon side of things might be something like > > > the attached, but I should state (nay, shout) that I haven't looked > > > beyond these few lines to see if there are any unintended side effects > > > to such a change. > > > > I think this patch doesn't change anything at all actually. It is > > certainly subject to the original race I described if you do not use > > the patch in crontab(8) itself. > > > > You're right about my patch not fixing anything; I didn't think hard > enough before I started typing. > > But I think the problem I was trying to get at with /etc/crontab still > exists with your patch; it would be triggered if a user updated their > crontab and after the 1 second sleep the directory timestamp gets > updated and cron rebuilds the database, and then right after that but > still in the same second /etc/crontab gets written. (That's why I was > trying, however feebly, to move the solution into the daemon.) What I would do for this case is change the daemon to remove all the TMAX crap and just cache both timestamps and rebuild the database any time either one changes. > Maybe the simple answer is for admins to be sure not to save changes > to /etc/crontab during the xx:xx:00 second, or with your patch, :01. > (I'm kidding, of course. The fact that cron likes to wake up at the top > of minute is no g'tee that it actually does so every time.) > > Once you start thinking along the "no g'tee" lines you realize that two > users can be updating their tabs concurrently, and one arrives in > poke_daemon() and grabs the current time (let's say it's noon) then gets > preempted for a long while before calling utimes(), the other user runs > through poke_daemon() and updates the directory timestamp to 12:00:01, > then the first process gets some cycles again and re-updates the > timestamp to 12:00:00. Ooopsie, we've achieved a complex and annoying > proof of the idea that timestamps alone aren't an adequate > synchronization primitive. Yes, a change id similar to what NFSv4 mandates is what you really want, but stat doesn't return one of those. However, the hack to crontab(8) should at least help with cases observed in the wild. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 23:03:31 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D0EE106564A for ; Tue, 31 Jan 2012 23:03:31 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 439DE8FC08 for ; Tue, 31 Jan 2012 23:03:31 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1RsMja-0005nI-3F>; Wed, 01 Feb 2012 00:03:30 +0100 Received: from e178014018.adsl.alicedsl.de ([85.178.14.18] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1RsMjZ-0004iI-UT>; Wed, 01 Feb 2012 00:03:30 +0100 Message-ID: <4F287338.8000002@zedat.fu-berlin.de> Date: Wed, 01 Feb 2012 00:03:20 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120119 Thunderbird/9.0 MIME-Version: 1.0 To: Current FreeBSD X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig39CD2492D1AA6F893ACDCA3A" X-Originating-IP: 85.178.14.18 Subject: using nscd (ldap) makes passwd/group disappearing while installing ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 23:03:31 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig39CD2492D1AA6F893ACDCA3A Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable I'm using on a couple of servers the nameservice cache dameon nscd and cache "group", "passwd" and "sudoers". Backend is LDAP, but local files should searched first. then ldap. cache is searched the very first even before files. Well, I'd expect that if a group is present, like "cups" or "dhcp" and reside in the local file (/etc/group or /etc/passwd), they are cached. Installing net/isc-dhcp42-server fails with this error: gmake[1]: Leaving directory `/usr/ports/net/isc-dhcp42-server/work/dhcp-4.2.3-P2/server' gmake[1]: Entering directory `/usr/ports/net/isc-dhcp42-server/work/dhcp-4.2.3-P2' gmake[1]: Nothing to be done for `all-am'. gmake[1]: Leaving directory `/usr/ports/net/isc-dhcp42-server/work/dhcp-4.2.3-P2' =3D=3D=3D> Installing for isc-dhcp42-server-4.2.3_2 =3D=3D=3D> Generating temporary packing list =3D=3D=3D> Creating users and/or groups. Creating group `dhcpd' with gid `136'. pw: group disappeared during update *** Error code 70 Stop in /usr/ports/net/isc-dhcp42-server. *** Error code 1 Stop in /usr/ports/net/isc-dhcp42-server. I also have this error very often when rebuilding/updating or even installing cups when "nscd" is enabled. A simple restart of nscd helps in most cases, most times I need to disable "cache" tag in /etc/nsswitch.conf, then everything runs smooth. Well, this behaviour is since a couple of years now, occurs sporadic. I have had in FreeBSD 7, 8, 9 and I see it in 10. What is it? I like the cache facility, since in domains with a lot of users searching LDAP takes some time and caching help keeping traffic and latency short. But the namservice caching mechanism seems to be unreliable. What is up there? --------------enig39CD2492D1AA6F893ACDCA3A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBAgAGBQJPKHNBAAoJEOgBcD7A/5N8qgYIANhc8Q7K6Jgif+j93ig0RivP qWpK0OXBsUocQiW6LGi3XDM0IwN3VXawLp+xxFOtI73JqNTvweimmJ/DBjnAPEJS xbbsnKiVZzs8qvgO9jwBi+/q6OXaFPnoPkX5Icn5l12+N08s3h4EyEny6LcEq7DB hlmOMEwa6QXGyjhgS9wNnqRWaj761QcJGHx+J5Pov27oYNt04eycSYPGFUPAVCSa UuMbsJF7XChGZeYu9wWY2F8UST1/3wZJdIe9d1unZk4Gr4mmQc/icdbjRBaUxk0C AJ3Sm3Ji86AMZoOymY00Sgp/G9O48BqP6eV35yyCaOPUcbGDrmSI3kpbceThTgo= =jf+c -----END PGP SIGNATURE----- --------------enig39CD2492D1AA6F893ACDCA3A-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 00:03:36 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3941D106564A for ; Wed, 1 Feb 2012 00:03:36 +0000 (UTC) (envelope-from ben@b1c1l1.com) Received: from lancer.b1c1l1.com (lancer.b1c1l1.com [IPv6:2607:f358:1a:1a:1000::]) by mx1.freebsd.org (Postfix) with ESMTP id 1B3028FC12 for ; Wed, 1 Feb 2012 00:03:36 +0000 (UTC) Received: from supra.b1c1l1.com (unknown [IPv6:2607:fc48:12:2:ca2a:14ff:fe3a:c94e]) by lancer.b1c1l1.com (Postfix) with ESMTPSA id 15EEA5C34; Tue, 31 Jan 2012 16:03:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=b1c1l1.com; s=default; t=1328054615; bh=a3dO4/ToThijurxuIIgs+SY1DB3uOVNo6dSsMUyvIaI=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=OBqwAq7lKI7eptj9ZRzGqSPnEaOTkgTRfzp9RE47qFiYfNpmbll/pKdGqsLdGvizc xCrG0cp4lR8uayaBkXswvBx/65YsIP57niMnkqUsroLmj1cBZYlx8keE+TJAhdkQSw sUaLSpnSg2hSXwHXaH2XcnkAf7belATGDKIRcvkk= Message-ID: <4F28814D.2030804@b1c1l1.com> Date: Tue, 31 Jan 2012 16:03:25 -0800 From: Benjamin Lee User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20120110 Thunderbird/9.0 MIME-Version: 1.0 To: "O. Hartmann" References: <4F287338.8000002@zedat.fu-berlin.de> In-Reply-To: <4F287338.8000002@zedat.fu-berlin.de> X-Enigmail-Version: 1.3.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEC6F7B58BF123392C1E1F8AF" Cc: Current FreeBSD Subject: Re: using nscd (ldap) makes passwd/group disappearing while installing ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 00:03:36 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEC6F7B58BF123392C1E1F8AF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/31/2012 03:03 PM, O. Hartmann wrote: > I'm using on a couple of servers the nameservice cache dameon nscd and > cache "group", "passwd" and "sudoers". Backend is LDAP, but local files= > should searched first. then ldap. cache is searched the very first even= > before files. >=20 > Well, I'd expect that if a group is present, like "cups" or "dhcp" and > reside in the local file (/etc/group or /etc/passwd), they are cached. >=20 > Installing net/isc-dhcp42-server fails with this error: >=20 >=20 > gmake[1]: Leaving directory > `/usr/ports/net/isc-dhcp42-server/work/dhcp-4.2.3-P2/server' > gmake[1]: Entering directory > `/usr/ports/net/isc-dhcp42-server/work/dhcp-4.2.3-P2' > gmake[1]: Nothing to be done for `all-am'. > gmake[1]: Leaving directory > `/usr/ports/net/isc-dhcp42-server/work/dhcp-4.2.3-P2' > =3D=3D=3D> Installing for isc-dhcp42-server-4.2.3_2 > =3D=3D=3D> Generating temporary packing list > =3D=3D=3D> Creating users and/or groups. > Creating group `dhcpd' with gid `136'. > pw: group disappeared during update > *** Error code 70 >=20 > Stop in /usr/ports/net/isc-dhcp42-server. > *** Error code 1 >=20 > Stop in /usr/ports/net/isc-dhcp42-server. What's going on is: 1) The port checks if the group exists 2) nscd caches that the group does not exist in its negative cache 3) pw(8) creates the group then checks if it exists 4) nscd returns the negative cache entry (group does not exist) This causes pw(8) to error since it expects the group that it just created to exist. > I also have this error very often when rebuilding/updating or even > installing cups when "nscd" is enabled. A simple restart of nscd helps > in most cases, most times I need to disable "cache" tag in > /etc/nsswitch.conf, then everything runs smooth. >=20 > Well, this behaviour is since a couple of years now, occurs sporadic. I= > have had in FreeBSD 7, 8, 9 and I see it in 10. What is it? >=20 > I like the cache facility, since in domains with a lot of users > searching LDAP takes some time and caching help keeping traffic and > latency short. But the namservice caching mechanism seems to be > unreliable. What is up there? You should put "files" before "cache" in /etc/nsswitch.conf, e.g.: group: files cache ldap passwd: files cache ldap The problem is that tools that modify the passwd and group files, like pw(8), don't invalidate nscd's negative cache entries when making changes. --=20 Benjamin Lee http://www.b1c1l1.com/ --------------enigEC6F7B58BF123392C1E1F8AF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPKIFSAAoJEAzughVKX1dUBOMP/A/DmkDCV23FwZoCJftKop1s KuFmP1VAFeJb7NgVsuqpajKkVCK7bPCTR0h7iEmaGukAZxsQ9iWnzWduujRGZmjg XRXpdXw1UY4/xTJyJh1ILPPvXr6ejSdvde38DqsjY1Ee7EhilqXmril3zh8K6k3M PXzTrGkpyYi8ZmPD6STf0bq+RM3BxrjXCi5fLER7ufxr5i+AGukPF/b1uSiC+sUm pOYKmsu9ZjA92TXUvhhraZDXEbROI8EEGcccMnebVEOkqueqkE9tfRz4Xlz54cOY RBwujRyzvvolS60Yy4AZgqGuFYLW9hDZKhxW4xIb+WaOIHRrSNH8YF0nDXXQVQT4 BGkA6JIblgNyeqX7RYiyM6G1O2RV6LWGVUWgVk+GHHgcYQGPu/KQX7gE2kBptynH vDY6UpLCLuL9u7xVY4U5qKPAl1bzXbLaHjTvmZxGZ6PoEhO07hCvy6gGRKp5B+7I 7+AGjVTEt7/dbr/p48JNZUffbnjOG6vptLDUh0+O9AffDsiUwPM538bIsFBclK9z 1WIfsBQsX9cRWBihA/YBGHexqbYBtdaO2sK+5phx1/1ixm2wBF3nltCXz0B3nSzX 2Kwx1+pytZWW/thMzKsX64HnSpTTfZpHrT/slQ+GWfevOrHUgAcLi09Gh7Coubp5 cXi1XDQNrSjberphhBi7 =fxlZ -----END PGP SIGNATURE----- --------------enigEC6F7B58BF123392C1E1F8AF-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 01:34:02 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48CFC106566C; Wed, 1 Feb 2012 01:34:02 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 8D76E8FC14; Wed, 1 Feb 2012 01:34:01 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAL+VKE+DaFvO/2dsb2JhbABDhQunOoMtgXIBAQQBI1YbDgoCAg0ZAlkGCogFp0uRcIEviW8HAgIdAwQBDgEIBQMDCQ2DAwIGBQIEDAYNAwkCAnMNAhCCI4EWBIhAjGCJLolE X-IronPort-AV: E=Sophos;i="4.71,599,1320642000"; d="scan'208";a="154535183" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 31 Jan 2012 20:34:00 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 44981B3F3A; Tue, 31 Jan 2012 20:34:00 -0500 (EST) Date: Tue, 31 Jan 2012 20:34:00 -0500 (EST) From: Rick Macklem To: John Baldwin Message-ID: <1517648658.522197.1328060040257.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <201201311321.47714.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Tijl Coosemans , freebsd-current@freebsd.org Subject: Re: posix_fadvise noreuse disables file caching X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 01:34:02 -0000 John Baldwin wrote: > On Tuesday, January 31, 2012 12:21:07 pm Ulrich Sp=C3=B6rlein wrote: > > On Mon, 2012-01-30 at 09:36:45 -0500, John Baldwin wrote: > > > On Sunday, January 29, 2012 10:08:10 am Tijl Coosemans wrote: > > > > On Wednesday 25 January 2012 17:29:22 John Baldwin wrote: > > > > > On Friday, January 20, 2012 2:12:13 pm John Baldwin wrote: > > > > >> On Thursday, January 19, 2012 11:39:42 am Tijl Coosemans > > > > >> wrote: > > > > >>> I recently noticed that multimedia/vlc generates a lot of > > > > >>> disk IO when > > > > >>> playing media files. For instance, when playing a 320kbps > > > > >>> mp3 gstat > > > > >>> reports about 1250kBps (=3D10000kbps). That's quite a lot of > > > > >>> overhead. > > > > >>> > > > > >>> It turns out that vlc sets POSIX_FADV_NOREUSE on the entire > > > > >>> file and > > > > >>> reads in chunks of 1028 bytes. FreeBSD implements NOREUSE as > > > > >>> if > > > > >>> O_DIRECT was specified during open(2), i.e. it disables all > > > > >>> caching. > > > > >>> That means every 1028 byte read turns into a 32KiB read (new > > > > >>> default > > > > >>> block size in 9.0) which explains the above numbers. > > > > >>> > > > > >>> I've copied the relevant vlc code below > > > > >>> (modules/access/file.c:Open()). > > > > >>> It's interesting to see that on OSX it sets F_NOCACHE which > > > > >>> disables > > > > >>> caching too, but combined with F_RDAHEAD there's still > > > > >>> read-ahead > > > > >>> caching. > > > > >>> > > > > >>> I don't think POSIX intended for NOREUSE to mean O_DIRECT. > > > > >>> It should > > > > >>> still cache data (and even do read-ahead if F_RDAHEAD is > > > > >>> specified), > > > > >>> and once data is fetched from the cache, it can be marked > > > > >>> WONTNEED. > > > > >> > > > > >> POSIX doesn't specify O_DIRECT, so it's not clear what it > > > > >> asks for. > > > > >> > > > > >>> Is it possible to implement it this way, or if not to just > > > > >>> ignore > > > > >>> the NOREUSE hint for now? > > > > >> > > > > >> I think it would be good to improve NOREUSE, though I had > > > > >> sort of > > > > >> assumed that applications using NOREUSE would do their own > > > > >> buffering > > > > >> and read full blocks. We could perhaps reimplement NOREUSE by > > > > >> doing > > > > >> the equivalent of POSIX_FADV_DONTNEED after each read to free > > > > >> buffers > > > > >> and pages after the data is copied out to userland. I also > > > > >> have an > > > > >> XXX about whether or not NOREUSE should still allow > > > > >> read-ahead as it > > > > >> isn't very clear what the right thing to do there is. HP-UX > > > > >> (IIRC) > > > > >> has an fadvise() that lets you specify multiple policies, so > > > > >> you > > > > >> could specify both NOREUSE and SEQUENTIAL for a single region > > > > >> to > > > > >> get read-ahead but still release memory once the data is read > > > > >> once. > > > > > > > > > > So I've came up with this untested patch. It uses > > > > > VOP_ADVISE(FADV_DONTNEED) after read(2) calls to a NOREUSE > > > > > region, and > > > > > leaves read-ahead caching enabled for NOREUSE. FADV_DONTNEED > > > > > doesn't > > > > > do any good really for writes (it only flushes clean buffers), > > > > > so I've > > > > > left write(2) operations as using IO_DIRECT still. Does this > > > > > sound > > > > > reasonable? I've not yet tested this at all: > > > > > > > > The patch drastically improves vlc, but there's still a tiny > > > > overhead. > > > > Without NOREUSE the disk is read in chunks of 128KiB (F_RDAHEAD > > > > buffer > > > > size). With NOREUSE there's an extra transfer of 32KiB (block > > > > size). > > > > > > This is probably because vlc is not reading on block boundaries, > > > so the > > > noreuse is throwing away partial blocks at the end of a read that > > > then have to > > > be re-read. We could maybe fix this by making FADV_DONTNEED only > > > throw > > > away completely-contained blocks rather than completely-contained > > > pages. > > > However, this will probably result in NOREUSE not actually > > > throwing away > > > anything at all if an app always reads sub-blocksize chunks. > > > > > > We could maybe make the case of vlc work ok in this case though by > > > allowing > > > an extension where you can do 'posix_fadvise(SEQUENTIAL | > > > NOREUSE)', and > > > in this case we could make the VOP_ADVISE(DONTNEED) in read() use > > > an offset > > > of 0 rather than the start of the read request. > > > > > > However, posix_fadvise() really is going to work best if the > > > userland > > > application reads aligned FS blocks. > > > > I find it questionable in general that an application can tell the > > system what to do wrt. caching. Perhaps I'm running 100s of VLC > > players > > all on the same file and actually *do* want reads to be cached? > > > > What happens if I seek back in the file? It has to do a potentially > > high-latency read again. The system has a better overview of blocks > > that > > are frequently being requested than any individual application. > > > > I fully understand the intention, and in 99.99% of the cases, this > > data > > *is* just being read once so there's no need to cache any reads for > > actually requested data. But as the example shows, requested data is > > not > > necessarily the data that lower layers have to fetch from the disk. > > > > Perhaps taking to VLC people on why they think this is useful and > > where > > it actually, measurably helped them would be interesting. > > > > Sorry if this is all perfectly obvious >=20 > There are certainly cases where the user can choose to run specific > apps in > such a way where this makes sense, so the OS needs this functionality. > As > to whether or not specific apps should use these APIs or if they > should make > use of these APIs configurable, that is a question for each app (e.g. > vlc). > However, the OS should provide the tools. >=20 I'd agree. However, there might be an argument for sysctl that tells the OS to ignore the hints, so a sysadmin can work around a case where an app runs poorly in their environment, due to the hint? rick From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 02:23:43 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 912111065673; Wed, 1 Feb 2012 02:23:43 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-150-251.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id CF2A314FED0; Wed, 1 Feb 2012 02:23:31 +0000 (UTC) Message-ID: <4F28A210.90303@FreeBSD.org> Date: Tue, 31 Jan 2012 18:23:12 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:9.0) Gecko/20120129 Thunderbird/9.0 MIME-Version: 1.0 To: John Baldwin References: <201201311149.32760.jhb@freebsd.org> In-Reply-To: <201201311149.32760.jhb@freebsd.org> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Race between cron and crontab X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 02:23:43 -0000 On 01/31/2012 08:49, John Baldwin wrote: > A co-worker ran into a race between updating a cron tab via crontab(8) and > cron(8) yesterday. Specifically, cron(8) failed to notice that a crontab was > updated. The problem is that 1) by default our filesystems only use second > granularity for timestamps and 2) cron only caches the seconds portion of a > file's timestamp when checking for changes anyway. This means that cron can > miss updates to a spool directory if multiple updates to the directory are > performed within a single second and cron wakes up to scan the spool directory > within the same second and scans it before all of the updates are complete. > > Specifically, when replacing a crontab, crontab(8) first creates a temporary > file in /var/cron/tabs and then uses a rename to install it followed by > touching the spool directory to update its modification time. However, the > creation of the temporary file already changes the modification time of the > directory, and cron may "miss" the rename if it scans the directory in between > the creation of the temporary file and the rename. > > The "fix" I am planning to use locally is to simply force crontab(8) to sleep > for a second before it touches the spool directory, thus ensuring that it the > touch of the spool directory will use a later modification time than the > creation of the temporary file. If you really want cron to have sub-second granularity I don't see how you could do it without using flags. crontab open sets flag that it is editing a file crontab close clears "editing" flag, sets "something changed" flag (if something actually changed of course) cron checks existence of "something changed" flag, pulls the update if there is no "editing" flag, clears "changed" flag Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 05:48:34 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A87B71065672 for ; Wed, 1 Feb 2012 05:48:34 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from mail.kirov.so-ups.ru (mail.kirov.so-ups.ru [178.74.170.1]) by mx1.freebsd.org (Postfix) with ESMTP id 4B9058FC1F for ; Wed, 1 Feb 2012 05:48:34 +0000 (UTC) Received: from kas30pipe.localhost (localhost.kirov.so-ups.ru [127.0.0.1]) by mail.kirov.so-ups.ru (Postfix) with SMTP id A1DA2B8024; Wed, 1 Feb 2012 09:28:41 +0400 (MSK) Received: from kirov.so-ups.ru (unknown [172.21.81.1]) by mail.kirov.so-ups.ru (Postfix) with ESMTP id 9C462B801F; Wed, 1 Feb 2012 09:28:41 +0400 (MSK) Received: by ns.kirov.so-ups.ru (Postfix, from userid 1010) id 986CDB8F54; Wed, 1 Feb 2012 09:28:41 +0400 (MSK) Received: from [127.0.0.1] (elsukov.kirov.oduur.so [10.118.3.52]) by ns.kirov.so-ups.ru (Postfix) with ESMTP id 5FD2BB8F4B; Wed, 1 Feb 2012 09:28:41 +0400 (MSK) Message-ID: <4F28CD85.101@FreeBSD.org> Date: Wed, 01 Feb 2012 09:28:37 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Andrey Fesenko References: In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig02CB74964D87AAFA502EDF1F" X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release X-SpamTest-Info: Not protected Cc: freebsd-current@freebsd.org, pjd@freebsd.org Subject: Re: gptboot rewrite, bootonce, etc. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 05:48:34 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig02CB74964D87AAFA502EDF1F Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 31.01.2012 19:49, Andrey Fesenko wrote: > This work if use ZFS? > My issues "Root on ZFS & GPT and boot to ufs partition" > http://lists.freebsd.org/pipermail/freebsd-fs/2012-January/013514.html >=20 > I test > # gpart show > =3D> 34 625142381 ada0 GPT (298G) > 34 128 1 freebsd-boot (64k) > 162 26621952 2 freebsd-ufs [bootonce,bootme] (12G) > 26622114 8388608 3 freebsd-swap (4.0G) > 35010722 590131693 4 freebsd-zfs (281G) >=20 > system ada0p2 not boot. Hi, Andrey If you want or plan rewrite boot code, i think it is better to write EFI loader with simple multiboot functionality. --=20 WBR, Andrey V. Elsukov --------------enig02CB74964D87AAFA502EDF1F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJPKM2JAAoJEAHF6gQQyKF6TjEH/AtH/EIGkM28rsGzBTzP4cCO EFfno7ydyu0MhNcJSjbF1F44UqDU/bTmU+dxVjkX23lVC66k/uJcCGeYNJSqaLhC TUJVVrAzRvvJcVGtUq0rt6xDRwGDGF5MvQJd6pgDq5oiFmq2Y0owaoofiyIzVGcE btpVIlCbZ+AuvgGjG59QV44oQyTWzYxunlNFUN3QL533xR6E84JoVzPXbF0kWzEb 90XHQKLXXHyCXu8cG5hRIC1ee4V+sN1r9mDa019OUVDCX8I0KFCvH9z5wBkKcUqd I0mVAncPWIw1X11Y5XQ3eIQ0D+KEo+8OkkbfPoLaGMmovdUmkyVkj8ng88Q5i6A= =58Ye -----END PGP SIGNATURE----- --------------enig02CB74964D87AAFA502EDF1F-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 07:54:21 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37E84106566C; Wed, 1 Feb 2012 07:54:21 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1BC7C8FC08; Wed, 1 Feb 2012 07:54:21 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q117sKn8053809; Wed, 1 Feb 2012 07:54:20 GMT (envelope-from bapt@FreeBSD.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q117sKn8053806; Wed, 1 Feb 2012 07:54:20 GMT (envelope-from bapt@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@FreeBSD.org using -f Date: Wed, 1 Feb 2012 08:54:16 +0100 From: Baptiste Daroussin To: Andrey Zonov Message-ID: <20120201075416.GF64311@azathoth.lan> References: <20120130123930.GB40244@azathoth.lan> <4F28CC57.9000202@zonov.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="z+pzSjdB7cqptWpS" Content-Disposition: inline In-Reply-To: <4F28CC57.9000202@zonov.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ports@FreeBSD.org, ports-announce@FreeBSD.org, current@FreeBSD.org Subject: Re: [HEADSUP][CFT] pkgng beta1 is out X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 07:54:21 -0000 --z+pzSjdB7cqptWpS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 01, 2012 at 09:23:35AM +0400, Andrey Zonov wrote: > On 30.01.2012 16:39, Baptiste Daroussin wrote: > > Hi, > > > > pkgng has just reached the beta phase, and has now found its way to the > > ports tree (disabled by default). > > > > 1/ Why pkgng? > > ------------ > Hi, >=20 > What about pkgng support in tinderbox? >=20 beat and I are working on it, just some typos left to figure out, should be there pretty much soon. regards, Bapt --z+pzSjdB7cqptWpS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk8o76gACgkQ8kTtMUmk6EwStACfdNSm4ZsCF7SHFGV2UXuD4RUl Vy0AoLAFDCzmYMxUuHWvER/U8NfDmLU6 =zKhR -----END PGP SIGNATURE----- --z+pzSjdB7cqptWpS-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 05:54:48 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BC5B1065673; Wed, 1 Feb 2012 05:54:48 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8DD798FC2B; Wed, 1 Feb 2012 05:54:47 +0000 (UTC) Received: by bkbzx1 with SMTP id zx1so945100bkb.13 for ; Tue, 31 Jan 2012 21:54:46 -0800 (PST) Received: by 10.204.154.140 with SMTP id o12mr12067680bkw.102.1328073819980; Tue, 31 Jan 2012 21:23:39 -0800 (PST) Received: from [10.254.254.77] (ppp95-165-137-107.pppoe.spdop.ru. [95.165.137.107]) by mx.google.com with ESMTPS id cz3sm51043169bkb.3.2012.01.31.21.23.38 (version=SSLv3 cipher=OTHER); Tue, 31 Jan 2012 21:23:39 -0800 (PST) Message-ID: <4F28CC57.9000202@zonov.org> Date: Wed, 01 Feb 2012 09:23:35 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Baptiste Daroussin References: <20120130123930.GB40244@azathoth.lan> In-Reply-To: <20120130123930.GB40244@azathoth.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 01 Feb 2012 12:27:19 +0000 Cc: ports@FreeBSD.org, ports-announce@FreeBSD.org, current@FreeBSD.org Subject: Re: [HEADSUP][CFT] pkgng beta1 is out X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 05:54:48 -0000 On 30.01.2012 16:39, Baptiste Daroussin wrote: > Hi, > > pkgng has just reached the beta phase, and has now found its way to the > ports tree (disabled by default). > > 1/ Why pkgng? > ------------ Hi, What about pkgng support in tinderbox? -- Andrey Zonov From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 08:55:35 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3800106566B for ; Wed, 1 Feb 2012 08:55:35 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 559EC8FC15 for ; Wed, 1 Feb 2012 08:55:35 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1RsVyX-0008RU-Op>; Wed, 01 Feb 2012 09:55:33 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RsVyX-0005b7-LO>; Wed, 01 Feb 2012 09:55:33 +0100 Message-ID: <4F28FDFF.10606@mail.zedat.fu-berlin.de> Date: Wed, 01 Feb 2012 09:55:27 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120118 Thunderbird/9.0 MIME-Version: 1.0 To: Benjamin Lee References: <4F287338.8000002@zedat.fu-berlin.de> <4F28814D.2030804@b1c1l1.com> In-Reply-To: <4F28814D.2030804@b1c1l1.com> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig502E466900026E2182338830" X-Originating-IP: 130.133.86.198 X-Mailman-Approved-At: Wed, 01 Feb 2012 12:27:35 +0000 Cc: Current FreeBSD Subject: Re: using nscd (ldap) makes passwd/group disappearing while installing ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 08:55:35 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig502E466900026E2182338830 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 02/01/12 01:03, Benjamin Lee wrote: > On 01/31/2012 03:03 PM, O. Hartmann wrote: >> I'm using on a couple of servers the nameservice cache dameon nscd and= >> cache "group", "passwd" and "sudoers". Backend is LDAP, but local file= s >> should searched first. then ldap. cache is searched the very first eve= n >> before files. >> >> Well, I'd expect that if a group is present, like "cups" or "dhcp" and= >> reside in the local file (/etc/group or /etc/passwd), they are cached.= >> >> Installing net/isc-dhcp42-server fails with this error: >> >> >> gmake[1]: Leaving directory >> `/usr/ports/net/isc-dhcp42-server/work/dhcp-4.2.3-P2/server' >> gmake[1]: Entering directory >> `/usr/ports/net/isc-dhcp42-server/work/dhcp-4.2.3-P2' >> gmake[1]: Nothing to be done for `all-am'. >> gmake[1]: Leaving directory >> `/usr/ports/net/isc-dhcp42-server/work/dhcp-4.2.3-P2' >> =3D=3D=3D> Installing for isc-dhcp42-server-4.2.3_2 >> =3D=3D=3D> Generating temporary packing list >> =3D=3D=3D> Creating users and/or groups. >> Creating group `dhcpd' with gid `136'. >> pw: group disappeared during update >> *** Error code 70 >> >> Stop in /usr/ports/net/isc-dhcp42-server. >> *** Error code 1 >> >> Stop in /usr/ports/net/isc-dhcp42-server. >=20 > What's going on is: >=20 > 1) The port checks if the group exists > 2) nscd caches that the group does not exist in its negative cache > 3) pw(8) creates the group then checks if it exists > 4) nscd returns the negative cache entry (group does not exist) >=20 > This causes pw(8) to error since it expects the group that it just > created to exist. >=20 >> I also have this error very often when rebuilding/updating or even >> installing cups when "nscd" is enabled. A simple restart of nscd helps= >> in most cases, most times I need to disable "cache" tag in >> /etc/nsswitch.conf, then everything runs smooth. >> >> Well, this behaviour is since a couple of years now, occurs sporadic. = I >> have had in FreeBSD 7, 8, 9 and I see it in 10. What is it? >> >> I like the cache facility, since in domains with a lot of users >> searching LDAP takes some time and caching help keeping traffic and >> latency short. But the namservice caching mechanism seems to be >> unreliable. What is up there? >=20 > You should put "files" before "cache" in /etc/nsswitch.conf, e.g.: >=20 > group: files cache ldap > passwd: files cache ldap >=20 > The problem is that tools that modify the passwd and group files, like > pw(8), don't invalidate nscd's negative cache entries when making > changes. >=20 >=20 Thank you for the explanation. Cheers, Oliver --------------enig502E466900026E2182338830 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iF4EAREIAAYFAk8o/gUACgkQU6Ni+wtCKv9pBAD6AvX//Pzw2+ktIoncr1iyfsYG tKQFY1OCEkJO57MunCcA/2h4qNUs+5/GcH/8kuiU75EuRvLQea6/i7+XYsrsWpzQ =Csob -----END PGP SIGNATURE----- --------------enig502E466900026E2182338830-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 13:05:30 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BF43106566B for ; Wed, 1 Feb 2012 13:05:30 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id B4E628FC12 for ; Wed, 1 Feb 2012 13:05:28 +0000 (UTC) Received: from ur.dons.net.au (ppp118-210-202-187.lns20.adl6.internode.on.net [118.210.202.187]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id q11D569S037143 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Feb 2012 23:35:11 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: <4F28FDFF.10606@mail.zedat.fu-berlin.de> Date: Wed, 1 Feb 2012 23:35:04 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: <8CE0E2D2-5DED-48CE-9EAC-E8923AADF9A6@gsoft.com.au> References: <4F287338.8000002@zedat.fu-berlin.de> <4F28814D.2030804@b1c1l1.com> <4F28FDFF.10606@mail.zedat.fu-berlin.de> To: "O. Hartmann" X-Mailer: Apple Mail (2.1251.1) X-Spam-Score: 2.162 (**) BAYES_00,KHOP_DYNAMIC,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: Benjamin Lee , Current FreeBSD Subject: Re: using nscd (ldap) makes passwd/group disappearing while installing ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 13:05:30 -0000 On 01/02/2012, at 19:25, O. Hartmann wrote: >> The problem is that tools that modify the passwd and group files, = like >> pw(8), don't invalidate nscd's negative cache entries when making >> changes. >>=20 >>=20 >=20 > Thank you for the explanation. How feasible would it be for pw to try and notify nscd? Or for nscd to = monitor the passwd & group files? Either would be somewhat racy though.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 13:17:33 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51EC2106566B for ; Wed, 1 Feb 2012 13:17:33 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm30-vm0.bullet.mail.sp2.yahoo.com (nm30-vm0.bullet.mail.sp2.yahoo.com [98.139.91.238]) by mx1.freebsd.org (Postfix) with SMTP id 2DF3F8FC0A for ; Wed, 1 Feb 2012 13:17:33 +0000 (UTC) Received: from [98.139.91.67] by nm30.bullet.mail.sp2.yahoo.com with NNFMP; 01 Feb 2012 13:05:20 -0000 Received: from [208.71.42.214] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 01 Feb 2012 13:05:20 -0000 Received: from [127.0.0.1] by smtp225.mail.gq1.yahoo.com with NNFMP; 01 Feb 2012 13:05:20 -0000 X-Yahoo-Newman-Id: 511382.55942.bm@smtp225.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: NXn8dXQVM1lmhCJo2mppF44h0NzKQJHYA9381sCce4B7bel KCPsVhUwhV_o1l89uR6xBzFxVcj55cTKIaRrXSNrQNr3Y_PZ1b151mpkMXhN 1zZRCj_wDG8BiGSP1UOLkzSnw.c4i.c.zQVGbBZulCwElYJ7_HPycRqH1rjZ YIrQODSRA2hzB22cdryOviE9ecuO508doVXmZY0FHZnuXGmh080Dw7k.HaWh nmxDMV59AzFil9N6Mgh4nJ.q2WykY80_xPEn9DJdOcqhETaW18S0U2kqntle 7phNHn8iWdb2.y.5dN.miMpjY9gPd6XpbsW4wIGskMGcTABqVD_h4ApiW5KH ot6W5pryABEM1wFy3TB43lobuwgqgyexc3CFA3gK572oh8KW00q40gcCwNR1 NjQ58_gSYqMOlkD1Rbwoy7cOmZ38KgA-- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.22] (se@81.173.148.171 with plain) by smtp225.mail.gq1.yahoo.com with SMTP; 01 Feb 2012 05:05:19 -0800 PST Message-ID: <4F293892.7080504@freebsd.org> Date: Wed, 01 Feb 2012 14:05:22 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4F287338.8000002@zedat.fu-berlin.de> <4F28814D.2030804@b1c1l1.com> In-Reply-To: <4F28814D.2030804@b1c1l1.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "O. Hartmann" Subject: Re: using nscd (ldap) makes passwd/group disappearing while installing ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 13:17:33 -0000 Am 01.02.2012 01:03, schrieb Benjamin Lee: > What's going on is: > > 1) The port checks if the group exists > 2) nscd caches that the group does not exist in its negative cache > 3) pw(8) creates the group then checks if it exists > 4) nscd returns the negative cache entry (group does not exist) > > This causes pw(8) to error since it expects the group that it just > created to exist. I had suggested before, that nscd be changed to only rely on cached negative entries, if they have repeatedly been seen in the underlying files/data-bases. E.g. only consider negative entries valid after they have been repeatedly stored into the cache (I'd think 3 times are a reasonable number). That way, the first lookup of an account or group will lead to an entry with count=1, which is found during cache lookup but which is ignored due to a too low "verification count". If the negative lookup is repeated 3 times within some reasonable time window (say 60 seconds), then it is to be considered verified. This will make the above sequence of queries and modifications of the passwd or group databases work with caching. This concept does not protect against scenarios where the negative cache entry is made active by several queries (e.g. manual checking for the presence of an account or group before the software installation repeats these tests). That is the reason to ask for more than 2 negative replies (3, perhaps better 5) before a negative cache entry is trusted. The main purpose of the cache (reduced latency for positive queries, limited load due to negative queries) will still be maintained. >> I also have this error very often when rebuilding/updating or even >> installing cups when "nscd" is enabled. A simple restart of nscd helps >> in most cases, most times I need to disable "cache" tag in >> /etc/nsswitch.conf, then everything runs smooth. >> >> Well, this behaviour is since a couple of years now, occurs sporadic. I >> have had in FreeBSD 7, 8, 9 and I see it in 10. What is it? >> >> I like the cache facility, since in domains with a lot of users >> searching LDAP takes some time and caching help keeping traffic and >> latency short. But the namservice caching mechanism seems to be >> unreliable. What is up there? > > You should put "files" before "cache" in /etc/nsswitch.conf, e.g.: > > group: files cache ldap > passwd: files cache ldap > > The problem is that tools that modify the passwd and group files, like > pw(8), don't invalidate nscd's negative cache entries when making > changes. You point out an alternative to making negative entries trusted only after they have been repeatedly entered into the cache: Tools that are used to modify the passwd/group databases might signal their changes to nscd. They could either purge the modified caches for the current or for all users, or they could just clear the single affected entry. In each case, nscd needs to re-fetch the modified (and possibly all other cached) entries. A simple implementation of such invalidation could be to invoke "nscd -I" after each modification performed by "pw". Still I think that the reduced trust in negative entries that have not been repeatedly tested is the best solution. I had looked into implementing such a logic in the cache, a few months back. It took more effort than I had hoped due to the way the cache is implemented, but I still think it should be possible without major changes to nscd. Regards, STefan From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 21:26:49 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67CA61065670; Wed, 1 Feb 2012 21:26:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 407848FC1B; Wed, 1 Feb 2012 21:26:49 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id D784D46B06; Wed, 1 Feb 2012 16:26:48 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 66171B946; Wed, 1 Feb 2012 16:26:48 -0500 (EST) From: John Baldwin To: Doug Barton Date: Wed, 1 Feb 2012 07:42:11 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <201201311149.32760.jhb@freebsd.org> <4F28A210.90303@FreeBSD.org> In-Reply-To: <4F28A210.90303@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201202010742.11936.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 01 Feb 2012 16:26:48 -0500 (EST) Cc: current@freebsd.org Subject: Re: Race between cron and crontab X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 21:26:49 -0000 On Tuesday, January 31, 2012 9:23:12 pm Doug Barton wrote: > On 01/31/2012 08:49, John Baldwin wrote: > > A co-worker ran into a race between updating a cron tab via crontab(8) and > > cron(8) yesterday. Specifically, cron(8) failed to notice that a crontab was > > updated. The problem is that 1) by default our filesystems only use second > > granularity for timestamps and 2) cron only caches the seconds portion of a > > file's timestamp when checking for changes anyway. This means that cron can > > miss updates to a spool directory if multiple updates to the directory are > > performed within a single second and cron wakes up to scan the spool directory > > within the same second and scans it before all of the updates are complete. > > > > Specifically, when replacing a crontab, crontab(8) first creates a temporary > > file in /var/cron/tabs and then uses a rename to install it followed by > > touching the spool directory to update its modification time. However, the > > creation of the temporary file already changes the modification time of the > > directory, and cron may "miss" the rename if it scans the directory in between > > the creation of the temporary file and the rename. > > > > The "fix" I am planning to use locally is to simply force crontab(8) to sleep > > for a second before it touches the spool directory, thus ensuring that it the > > touch of the spool directory will use a later modification time than the > > creation of the temporary file. > > If you really want cron to have sub-second granularity I don't see how > you could do it without using flags. > > crontab open sets flag that it is editing a file > crontab close clears "editing" flag, sets "something changed" flag > (if something actually changed of course) > > cron checks existence of "something changed" flag, pulls the > update if there is no "editing" flag, clears "changed" flag I don't want it to have sub-second granularity, I just want to make 'crontab -e' more reliable so that cron doesn't miss edits. cron is currently using the mod-time of the spool directory as the 'something changed' flag (have you read the cron code?). The problem is that it currently can set the 'something changed' flag non-atomically while it is updating a crontab. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 00:26:55 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89692106564A for ; Thu, 2 Feb 2012 00:26:55 +0000 (UTC) (envelope-from andrew.hobbs@ai.net) Received: from ginga.ai.net (ginga.ai.net [205.134.166.19]) by mx1.freebsd.org (Postfix) with ESMTP id 4AFAB8FC13 for ; Thu, 2 Feb 2012 00:26:54 +0000 (UTC) Received: from ginga.ai.net ([205.134.166.19]) by ginga.ai.net ([205.134.166.19]) with mapi; Wed, 1 Feb 2012 19:26:54 -0500 From: Andrew Hobbs To: "freebsd-current@freebsd.org" Date: Wed, 1 Feb 2012 19:26:52 -0500 Thread-Topic: CARP on -CURRENT Thread-Index: AczWJ4XZ+IVqcot3TYiqXM1iYlzHjALGH53w Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: RE: CARP on -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 00:26:55 -0000 I much appreciate the responses and I was able to get CARP functioning usin= g the new ifconfig syntax under -CURRENT. Having done that, CARP is now act= ing as it should, though now I have a new challenge with devd and automatic= firing of scripts during CARP failover. It appears that the documented met= hod of doing this at http://www.freebsd.org/doc/handbook/disks-hast.html no= longer works with the suggested devd.conf setup; notify 30 { match "system" "IFNET"; match "subsystem" "carp0"; match "type" "LINK_UP"; action "/usr/local/sbin/carp-hast-switch master"; }; notify 30 { match "system" "IFNET"; match "subsystem" "carp0"; match "type" "LINK_DOWN"; action "/usr/local/sbin/carp-hast-switch slave"; Is it likely that the triggers associated with CARP for devd have changed d= ue to the recent new CARP overhaul? Does anyone know what the new triggers = may be? Love, Andrew -----Original Message----- From: Sergey Kandaurov [mailto:pluknet@gmail.com]=20 Sent: Wednesday, January 18, 2012 4:24 PM To: Andrew Hobbs Cc: freebsd-current@freebsd.org Subject: Re: CARP on -CURRENT On 19 January 2012 00:54, Andrew Hobbs wrote: > Is CARP implemented on -CURRENT (FreeBSD 10)? > > I'm playing around with some test boxes in the office running=20 > -CURRENT; testbox# uname -a FreeBSD testbox.ai.net 10.0-CURRENT=20 > FreeBSD 10.0-CURRENT #0: Wed Jan 18 19:21:12 EST 2012 =A0 =A0=20 > root@testbox.ai.net:/usr/obj/usr/src/sys/CARP =A0amd64 > > I can't seem to create a carp interface despite having compiled a=20 > kernel with "device =A0 =A0 =A0carp" in it. Attempts to create a carp=20 > interface fail; # ifconfig carp create > ifconfig: SIOCIFCREATE2: Invalid argument > > >From what I've read in the handbook entry on CARP=20 > >(http://www.freebsd.org/doc/handbook/carp.html), I should be able to=20 > >either compile in the carp device, as above, or load the if_carp.ko=20 > >kern module. There doesn't appear to be a if_carp.ko module in the=20 > >-CURRENT source tree, however. Only the carp module itself; > # ls -ald /usr/src/sys/modules/*carp* > drwxr-xr-x =A02 root =A0wheel =A0512 Dec 27 15:12 /usr/src/sys/modules/ca= rp > > Am I missing something completely obvious? Was the functionality of if_ca= rp.ko rolled into another module? You should definitely read this changeset: http://svn.freebsd.org/changeset/base/228571 and the updated carp ifconfig syntax in man carp. As for if_carp.ko, it was= renamed into carp.ko as part of the CARP implementation overhaul. This only affects CURRENT. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 00:46:48 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDB2C106564A for ; Thu, 2 Feb 2012 00:46:48 +0000 (UTC) (envelope-from ambrosehua@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4C9F58FC0C for ; Thu, 2 Feb 2012 00:46:47 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so2127084wib.13 for ; Wed, 01 Feb 2012 16:46:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3/3IrBV7ASqUu5lRUC4bz02IXur8q9le0TUeN0QdYps=; b=h4YQ1nZvzIa1r6ANji8AojwLkGcgrfQIho8VQHRel9QLvczXepuBBPdj6WNFYCBd28 SWbKaiMyJqNAMDAJ8xhmBwjmLkublThfxBP7IWs8gERZhSeJbvmaj1ptUpuKcs1QsWzu i7+f5eDedwhrBI1ys/ARbPn9l/EyzxppMa9Ek= MIME-Version: 1.0 Received: by 10.180.89.67 with SMTP id bm3mr1177688wib.13.1328143607220; Wed, 01 Feb 2012 16:46:47 -0800 (PST) Received: by 10.223.42.18 with HTTP; Wed, 1 Feb 2012 16:46:47 -0800 (PST) In-Reply-To: <20120131152828.GF3283@deviant.kiev.zoral.com.ua> References: <20120130063607.GV2726@deviant.kiev.zoral.com.ua> <20120130164316.GW2726@deviant.kiev.zoral.com.ua> <20120131152828.GF3283@deviant.kiev.zoral.com.ua> Date: Thu, 2 Feb 2012 08:46:47 +0800 Message-ID: From: Paul Ambrose To: Konstantin Belousov Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current Subject: Re: Does anyone try kib's Sandy Bridge PCID patch (pcid.2.patch)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 00:46:48 -0000 =D4=DA 2012=C4=EA1=D4=C231=C8=D5 =CF=C2=CE=E711:28=A3=ACKonstantin Belousov= =D0=B4=B5=C0=A3=BA > On Tue, Jan 31, 2012 at 09:23:50AM +0800, Paul Ambrose wrote: >> ?? 2012??1??31?? ????12:43??Kostik Belousov ?????? >> > On Mon, Jan 30, 2012 at 07:08:13PM +0800, Paul Ambrose wrote: >> >> ?? 2012??1??30?? ????2:36??Kostik Belousov ????= ?? >> >> > On Mon, Jan 30, 2012 at 10:15:51AM +0800, Paul Ambrose wrote: >> >> >> I have two boxes, one is AMD Athlon 610e 2.4G with FreeBSD-curren= t >> >> >> patched with pcid.2.patch? It works well without other issue and i= t >> >> >> seem the pcid patch >> >> >> does not affect other part of the kernel. The other one is Sandy >> >> > Athlons do not have PCID and probably will never implement it. They= use >> >> > other tricks to get similar optimizations, transparently to the OS. >> >> > >> >> Just curious, is this AMD similar optimizations >> >> Address Space Number (ASN) and Global flag >> >> US Patent 6,604,187. >> >> http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_o= f_AMDs_64bit_Core.html >> > This and the same-important next item 'The TLB Flush Filter' is what >> > I referred to. >> > >> >> I did not found anything about ASN in the AMD manual >> > It is a transparent optimization, which does not require any OS suppor= t. >> > Intel PCID is completely different, it shall be explicitely handled by= OS. >> > It is some consequence of the nested pages support, AFAIU. >> > >> >> >> >> >> Bridge i5-2300 with FreeBSD 9 release patched with pcid.1.patch( t= he >> >> >> pcid.2.patch seems >> >> >> dependent on AVX and XSAVE stuffs which is available on -current).= But >> >> >> it hangs up just in a few minutes. I doubt the nvidia-driver which= is >> >> >> not recompiled with >> >> >> patched kernel is the root, I will check this out later, but does >> >> >> anyone meet similar problem? >> >> > There are two many variations compared to the config I did tested. >> >> > I do not see anything obvious in the changes between HEAD and stabl= e/9 >> >> > which could be blamed. Nvidia driver might be bigger suspect, but a= gain, >> >> > I am not aware of anything wrong with it. >> >> > >> >> >> >> >> >> I have two question about the pcid.2.patch >> >> > >> >> > Item 2 is clean, I fixed it. >> >> > >> >> > For the item 1, I was only able to decipher the proposal to optimiz= e >> >> > the global shootdown handler to restore the %cr3 with bit 64 set to= not >> >> > invalidate current PCID. Is there some more changes ? >> >> > >> >> yes, that is what I meant. I was wondering using another way that eac= h >> >> process has different >> >> pcid in each active processor, just as the freebsd mips and powerpc >> >> uses. But obviously this way >> >> is more friendly to non-pcid x86 processor. >> > Each vmspace (or pmap) has unique PCID with the patch, at least until >> > PCID space (12bit) is not exhausted. To really exhaust it, you need 40= 95 >> > processes, so it is unlikely but possible event with the current setti= ngs. >> > >> Thank you for your explanation. I just disabled nvidia-driver( not >> load it) , and >> use "buildworld buildkernel" to test the pcid.1.patch with 9-release, >> it seems the box reset before >> completing the buildkernel, the attachment is my kernel config, would >> you mind try it on >> 9-release with pcid.1.patch? I will git 10-current a try to see if >> there is something wrong with my hardware > > I just did checkout + buildworld + buildkernel with -j 10 on UFS with > PCID turned on, everything finished fine. It is up to date HEAD. > > sandy% sysctl vm.stats.sys.v_swtch vm.pmap.pcid_save_cnt > vm.stats.sys.v_swtch: 13743519 > vm.pmap.pcid_save_cnt: 7853519 > I.e. the TLB was not flushed one each second context switch. > > Trying the HEAD with the patch is probably easiest way forward. Unfortunately, I try 10-current(HEAD) with pcid.3.patch in my i5-2300 box, system panic From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 03:40:45 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D90E1065672; Thu, 2 Feb 2012 03:40:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0C6808FC15; Thu, 2 Feb 2012 03:40:44 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q123ehbC032919; Wed, 1 Feb 2012 22:40:44 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q123ehRe032904; Thu, 2 Feb 2012 03:40:43 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 2 Feb 2012 03:40:43 GMT Message-Id: <201202020340.q123ehRe032904@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 03:40:45 -0000 TB --- 2012-02-01 22:20:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-02-01 22:20:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-02-01 22:20:00 - cleaning the object tree TB --- 2012-02-01 22:21:02 - cvsupping the source tree TB --- 2012-02-01 22:21:02 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-02-01 22:26:27 - building world TB --- 2012-02-01 22:26:27 - CROSS_BUILD_TESTING=YES TB --- 2012-02-01 22:26:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-01 22:26:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-01 22:26:27 - SRCCONF=/dev/null TB --- 2012-02-01 22:26:27 - TARGET=i386 TB --- 2012-02-01 22:26:27 - TARGET_ARCH=i386 TB --- 2012-02-01 22:26:27 - TZ=UTC TB --- 2012-02-01 22:26:27 - __MAKE_CONF=/dev/null TB --- 2012-02-01 22:26:27 - cd /src TB --- 2012-02-01 22:26:27 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 1 22:26:28 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Feb 2 00:30:56 UTC 2012 TB --- 2012-02-02 00:30:56 - generating LINT kernel config TB --- 2012-02-02 00:30:56 - cd /src/sys/i386/conf TB --- 2012-02-02 00:30:56 - /usr/bin/make -B LINT TB --- 2012-02-02 00:30:57 - cd /src/sys/i386/conf TB --- 2012-02-02 00:30:57 - /usr/sbin/config -m LINT TB --- 2012-02-02 00:30:57 - building LINT kernel TB --- 2012-02-02 00:30:57 - CROSS_BUILD_TESTING=YES TB --- 2012-02-02 00:30:57 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-02 00:30:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-02 00:30:57 - SRCCONF=/dev/null TB --- 2012-02-02 00:30:57 - TARGET=i386 TB --- 2012-02-02 00:30:57 - TARGET_ARCH=i386 TB --- 2012-02-02 00:30:57 - TZ=UTC TB --- 2012-02-02 00:30:57 - __MAKE_CONF=/dev/null TB --- 2012-02-02 00:30:57 - cd /src TB --- 2012-02-02 00:30:57 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 2 00:30:57 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Thu Feb 2 01:02:24 UTC 2012 TB --- 2012-02-02 01:02:24 - cd /src/sys/i386/conf TB --- 2012-02-02 01:02:24 - /usr/sbin/config -m LINT-NOINET TB --- 2012-02-02 01:02:24 - building LINT-NOINET kernel TB --- 2012-02-02 01:02:24 - CROSS_BUILD_TESTING=YES TB --- 2012-02-02 01:02:24 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-02 01:02:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-02 01:02:24 - SRCCONF=/dev/null TB --- 2012-02-02 01:02:24 - TARGET=i386 TB --- 2012-02-02 01:02:24 - TARGET_ARCH=i386 TB --- 2012-02-02 01:02:24 - TZ=UTC TB --- 2012-02-02 01:02:24 - __MAKE_CONF=/dev/null TB --- 2012-02-02 01:02:24 - cd /src TB --- 2012-02-02 01:02:24 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Thu Feb 2 01:02:24 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Thu Feb 2 01:32:19 UTC 2012 TB --- 2012-02-02 01:32:19 - cd /src/sys/i386/conf TB --- 2012-02-02 01:32:19 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-02-02 01:32:19 - building LINT-NOINET6 kernel TB --- 2012-02-02 01:32:19 - CROSS_BUILD_TESTING=YES TB --- 2012-02-02 01:32:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-02 01:32:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-02 01:32:19 - SRCCONF=/dev/null TB --- 2012-02-02 01:32:19 - TARGET=i386 TB --- 2012-02-02 01:32:19 - TARGET_ARCH=i386 TB --- 2012-02-02 01:32:19 - TZ=UTC TB --- 2012-02-02 01:32:19 - __MAKE_CONF=/dev/null TB --- 2012-02-02 01:32:19 - cd /src TB --- 2012-02-02 01:32:19 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Thu Feb 2 01:32:19 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Thu Feb 2 02:02:32 UTC 2012 TB --- 2012-02-02 02:02:32 - cd /src/sys/i386/conf TB --- 2012-02-02 02:02:32 - /usr/sbin/config -m LINT-NOIP TB --- 2012-02-02 02:02:32 - building LINT-NOIP kernel TB --- 2012-02-02 02:02:32 - CROSS_BUILD_TESTING=YES TB --- 2012-02-02 02:02:32 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-02 02:02:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-02 02:02:32 - SRCCONF=/dev/null TB --- 2012-02-02 02:02:32 - TARGET=i386 TB --- 2012-02-02 02:02:32 - TARGET_ARCH=i386 TB --- 2012-02-02 02:02:32 - TZ=UTC TB --- 2012-02-02 02:02:32 - __MAKE_CONF=/dev/null TB --- 2012-02-02 02:02:32 - cd /src TB --- 2012-02-02 02:02:32 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Thu Feb 2 02:02:32 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Thu Feb 2 02:30:45 UTC 2012 TB --- 2012-02-02 02:30:45 - cd /src/sys/i386/conf TB --- 2012-02-02 02:30:45 - /usr/sbin/config -m LINT-VIMAGE TB --- 2012-02-02 02:30:45 - building LINT-VIMAGE kernel TB --- 2012-02-02 02:30:45 - CROSS_BUILD_TESTING=YES TB --- 2012-02-02 02:30:45 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-02 02:30:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-02 02:30:45 - SRCCONF=/dev/null TB --- 2012-02-02 02:30:45 - TARGET=i386 TB --- 2012-02-02 02:30:45 - TARGET_ARCH=i386 TB --- 2012-02-02 02:30:45 - TZ=UTC TB --- 2012-02-02 02:30:45 - __MAKE_CONF=/dev/null TB --- 2012-02-02 02:30:45 - cd /src TB --- 2012-02-02 02:30:45 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Thu Feb 2 02:30:45 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-VIMAGE completed on Thu Feb 2 03:01:20 UTC 2012 TB --- 2012-02-02 03:01:20 - cd /src/sys/i386/conf TB --- 2012-02-02 03:01:20 - /usr/sbin/config -m GENERIC TB --- 2012-02-02 03:01:20 - building GENERIC kernel TB --- 2012-02-02 03:01:20 - CROSS_BUILD_TESTING=YES TB --- 2012-02-02 03:01:20 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-02 03:01:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-02 03:01:20 - SRCCONF=/dev/null TB --- 2012-02-02 03:01:20 - TARGET=i386 TB --- 2012-02-02 03:01:20 - TARGET_ARCH=i386 TB --- 2012-02-02 03:01:20 - TZ=UTC TB --- 2012-02-02 03:01:20 - __MAKE_CONF=/dev/null TB --- 2012-02-02 03:01:20 - cd /src TB --- 2012-02-02 03:01:20 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Feb 2 03:01:20 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Thu Feb 2 03:25:51 UTC 2012 TB --- 2012-02-02 03:25:51 - cd /src/sys/i386/conf TB --- 2012-02-02 03:25:51 - /usr/sbin/config -m PAE TB --- 2012-02-02 03:25:51 - building PAE kernel TB --- 2012-02-02 03:25:51 - CROSS_BUILD_TESTING=YES TB --- 2012-02-02 03:25:51 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-02 03:25:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-02 03:25:51 - SRCCONF=/dev/null TB --- 2012-02-02 03:25:51 - TARGET=i386 TB --- 2012-02-02 03:25:51 - TARGET_ARCH=i386 TB --- 2012-02-02 03:25:51 - TZ=UTC TB --- 2012-02-02 03:25:51 - __MAKE_CONF=/dev/null TB --- 2012-02-02 03:25:51 - cd /src TB --- 2012-02-02 03:25:51 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Thu Feb 2 03:25:51 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PAE completed on Thu Feb 2 03:32:37 UTC 2012 TB --- 2012-02-02 03:32:37 - cd /src/sys/i386/conf TB --- 2012-02-02 03:32:37 - /usr/sbin/config -m XBOX TB --- 2012-02-02 03:32:37 - building XBOX kernel TB --- 2012-02-02 03:32:37 - CROSS_BUILD_TESTING=YES TB --- 2012-02-02 03:32:37 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-02 03:32:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-02 03:32:37 - SRCCONF=/dev/null TB --- 2012-02-02 03:32:37 - TARGET=i386 TB --- 2012-02-02 03:32:37 - TARGET_ARCH=i386 TB --- 2012-02-02 03:32:37 - TZ=UTC TB --- 2012-02-02 03:32:37 - __MAKE_CONF=/dev/null TB --- 2012-02-02 03:32:37 - cd /src TB --- 2012-02-02 03:32:37 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Thu Feb 2 03:32:37 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for XBOX completed on Thu Feb 2 03:35:47 UTC 2012 TB --- 2012-02-02 03:35:47 - cd /src/sys/i386/conf TB --- 2012-02-02 03:35:47 - /usr/sbin/config -m XEN TB --- 2012-02-02 03:35:47 - building XEN kernel TB --- 2012-02-02 03:35:47 - CROSS_BUILD_TESTING=YES TB --- 2012-02-02 03:35:47 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-02 03:35:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-02 03:35:47 - SRCCONF=/dev/null TB --- 2012-02-02 03:35:47 - TARGET=i386 TB --- 2012-02-02 03:35:47 - TARGET_ARCH=i386 TB --- 2012-02-02 03:35:47 - TZ=UTC TB --- 2012-02-02 03:35:47 - __MAKE_CONF=/dev/null TB --- 2012-02-02 03:35:47 - cd /src TB --- 2012-02-02 03:35:47 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Thu Feb 2 03:35:47 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/xen/netback/netback.c:622: warning: nested extern declaration of 'kmem_free' [-Wnested-externs] /src/sys/dev/xen/netback/netback.c:622: error: 'kernel_map' undeclared (first use in this function) /src/sys/dev/xen/netback/netback.c:622: error: (Each undeclared identifier is reported only once /src/sys/dev/xen/netback/netback.c:622: error: for each function it appears in.) /src/sys/dev/xen/netback/netback.c: In function 'xnb_alloc_communication_mem': /src/sys/dev/xen/netback/netback.c:812: warning: implicit declaration of function 'kmem_alloc_nofault' /src/sys/dev/xen/netback/netback.c:812: warning: nested extern declaration of 'kmem_alloc_nofault' [-Wnested-externs] /src/sys/dev/xen/netback/netback.c:812: error: 'kernel_map' undeclared (first use in this function) *** Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-02-02 03:40:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-02-02 03:40:43 - ERROR: failed to build XEN kernel TB --- 2012-02-02 03:40:43 - 15320.95 user 2139.58 system 19242.92 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 05:04:39 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B829D106564A for ; Thu, 2 Feb 2012 05:04:39 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from idcmail-mo2no.shaw.ca (idcmail-mo2no.shaw.ca [64.59.134.9]) by mx1.freebsd.org (Postfix) with ESMTP id 820908FC0C for ; Thu, 2 Feb 2012 05:04:39 +0000 (UTC) Received: from lb7f8hsrpno-svcs.dcs.int.inet (HELO pd5ml1no-ssvc.prod.shaw.ca) ([10.0.144.222]) by pd7mo1no-svcs.prod.shaw.ca with ESMTP; 01 Feb 2012 21:49:37 -0700 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=bD0CuDYpMgGTku+nVSbZuKP/9fNjspX1F8zuwcoBWhM= c=1 sm=1 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=FP58Ms26AAAA:8 a=BWvPGDcYAAAA:8 a=6I5d2MoRAAAA:8 a=P8EJTsFNWWfrW7xz8tAA:9 a=CjuIK1q_8ugA:10 a=V7tsTZBp22UA:10 a=SV7veod9ZcQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by pd5ml1no-dmz.prod.shaw.ca with ESMTP; 01 Feb 2012 21:49:37 -0700 Received: from slippy.cwsent.com (slippy3.cwsent.com [10.1.3.91]) by spqr.komquats.com (Postfix) with ESMTP id 4B1BD46B6E for ; Wed, 1 Feb 2012 20:49:37 -0800 (PST) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.5/8.14.5) with ESMTP id q124nbBB004310 for ; Wed, 1 Feb 2012 20:49:37 -0800 (PST) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201202020449.q124nbBB004310@slippy.cwsent.com> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: freebsd-current@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Feb 2012 20:49:37 -0800 Cc: Subject: Smartmontools X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Cy Schubert List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 05:04:39 -0000 Other than nooptions ATA_CAM, is there a fix or circumvention to allow smartmontools to work correctly under 9.0 and -CURRENT? slippy# smartctl -a /dev/ad0 smartctl 5.41 2011-06-09 r3365 [FreeBSD 9.0-STABLE i386] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net error sending CAMIOCOMMAND ioctl: Inappropriate ioctl for device Unable to get CAM device list /dev/ad0: Unable to detect device type Smartctl: please specify device type with the -d option. Use smartctl -h to get a usage summary slippy# -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 05:36:12 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67DD11065670 for ; Thu, 2 Feb 2012 05:36:12 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 39E208FC17 for ; Thu, 2 Feb 2012 05:36:12 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id q125aAMZ012117; Wed, 1 Feb 2012 22:36:10 -0700 (MST) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <201202020449.q124nbBB004310@slippy.cwsent.com> Date: Wed, 1 Feb 2012 22:36:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201202020449.q124nbBB004310@slippy.cwsent.com> To: Cy Schubert X-Mailer: Apple Mail (2.1251.1) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: Smartmontools X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 05:36:12 -0000 On Feb 1, 2012, at 9:49 PM, Cy Schubert wrote: > Other than nooptions ATA_CAM, is there a fix or circumvention to allow=20= > smartmontools to work correctly under 9.0 and -CURRENT? >=20 > slippy# smartctl -a /dev/ad0 > smartctl 5.41 2011-06-09 r3365 [FreeBSD 9.0-STABLE i386] (local build) > Copyright (C) 2002-11 by Bruce Allen, = http://smartmontools.sourceforge.net >=20 > error sending CAMIOCOMMAND ioctl: Inappropriate ioctl for device > Unable to get CAM device list > /dev/ad0: Unable to detect device type > Smartctl: please specify device type with the -d option. >=20 > Use smartctl -h to get a usage summary >=20 > slippy#=20 >=20 >=20 I can't say for certain, but my guess is that you've been victimized by = recent changes to CAM headers. Have you tried recompiling to get = everything in sync? Scott From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 05:49:02 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 979A6106564A for ; Thu, 2 Feb 2012 05:49:02 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from idcmail-mo1so.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id 5E4188FC0A for ; Thu, 2 Feb 2012 05:49:02 +0000 (UTC) Received: from pd2ml1so-ssvc.prod.shaw.ca ([10.0.141.139]) by pd3mo1so-svcs.prod.shaw.ca with ESMTP; 01 Feb 2012 22:49:01 -0700 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=2TvZ7eE48NdEYeaL5Xf58dNzJU178UzT+2lxUZ5Mhss= c=1 sm=1 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=-o65W9qwAAAA:8 a=FP58Ms26AAAA:8 a=BWvPGDcYAAAA:8 a=6I5d2MoRAAAA:8 a=wwWUOCx-lZnRln5ygC0A:9 a=PGPx5a1FkChWoYwDq7UA:7 a=CjuIK1q_8ugA:10 a=HRJsq0TPXRMA:10 a=V7tsTZBp22UA:10 a=SV7veod9ZcQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by pd2ml1so-dmz.prod.shaw.ca with ESMTP; 01 Feb 2012 22:49:01 -0700 Received: from slippy.cwsent.com (slippy3.cwsent.com [10.1.3.91]) by spqr.komquats.com (Postfix) with ESMTP id E99B446B6E; Wed, 1 Feb 2012 21:49:00 -0800 (PST) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.5/8.14.5) with ESMTP id q125n0xG065327; Wed, 1 Feb 2012 21:49:00 -0800 (PST) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201202020549.q125n0xG065327@slippy.cwsent.com> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Scott Long In-Reply-To: Message from Scott Long of "Wed, 01 Feb 2012 22:36:09 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Feb 2012 21:49:00 -0800 Cc: freebsd-current@freebsd.org Subject: Re: Smartmontools X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Cy Schubert List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 05:49:02 -0000 In message , Scott Long writes : > > On Feb 1, 2012, at 9:49 PM, Cy Schubert wrote: > > > Other than nooptions ATA_CAM, is there a fix or circumvention to allow > > smartmontools to work correctly under 9.0 and -CURRENT? > > > > slippy# smartctl -a /dev/ad0 > > smartctl 5.41 2011-06-09 r3365 [FreeBSD 9.0-STABLE i386] (local build) > > Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net > > > > error sending CAMIOCOMMAND ioctl: Inappropriate ioctl for device > > Unable to get CAM device list > > /dev/ad0: Unable to detect device type > > Smartctl: please specify device type with the -d option. > > > > Use smartctl -h to get a usage summary > > > > slippy# > > > > > > I can't say for certain, but my guess is that you've been victimized by recen > t changes to CAM headers. Have you tried recompiling to get everything in sy > nc? Everything (kernel and userland) but smaartmontools (and other ports) has been rebuilt (two days ago). Rebuilding the port did the trick. Thanks. :) -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 06:02:49 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05C4A106564A for ; Thu, 2 Feb 2012 06:02:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 656A38FC0C for ; Thu, 2 Feb 2012 06:02:47 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q1262hql036362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Feb 2012 08:02:43 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q1262goH094808; Thu, 2 Feb 2012 08:02:43 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q1262gPg094807; Thu, 2 Feb 2012 08:02:42 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 2 Feb 2012 08:02:42 +0200 From: Konstantin Belousov To: Paul Ambrose Message-ID: <20120202060242.GN3283@deviant.kiev.zoral.com.ua> References: <20120130063607.GV2726@deviant.kiev.zoral.com.ua> <20120130164316.GW2726@deviant.kiev.zoral.com.ua> <20120131152828.GF3283@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="R92lf0Oi2sxyK3LA" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current Subject: Re: Does anyone try kib's Sandy Bridge PCID patch (pcid.2.patch)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 06:02:49 -0000 --R92lf0Oi2sxyK3LA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Feb 02, 2012 at 08:46:47AM +0800, Paul Ambrose wrote: > Unfortunately, I try 10-current(HEAD) with pcid.3.patch in my i5-2300 > box, system panic Unfortunately, you did not provided any details of the panic. Panic message and backtrace is the absolute minimum. --R92lf0Oi2sxyK3LA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk8qJwIACgkQC3+MBN1Mb4gj5wCgvFWo9CiPm9V5zR1vqTdHmDuk vY8AoISHsvKGk30QZfS83SkMJo6XZk1Y =ekTn -----END PGP SIGNATURE----- --R92lf0Oi2sxyK3LA-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 07:00:28 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E6C8106564A for ; Thu, 2 Feb 2012 07:00:28 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2DAE88FC13 for ; Thu, 2 Feb 2012 07:00:27 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so2366351wib.13 for ; Wed, 01 Feb 2012 23:00:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=L8LX4ZBzV/0VVHUs0xPT3dfNodHmkXQw+BF5rf77UqQ=; b=ngmVr4vQjhfSNiDIDa0H+WyvW9gLOFptLpqI+LJ2ivzML4lmHqBBpQhrTI7BMFIULF FzTpGyGzVsbizqu0R9+qkvYs5XivQetq9/gIWfKMojLQOR3DzWz1rE6L6ToRTuH3k5mM xmpKc4PRzNU6ZctmQeJTYt/Od6Y/epRYDXpgc= MIME-Version: 1.0 Received: by 10.180.108.232 with SMTP id hn8mr2471904wib.16.1328166026711; Wed, 01 Feb 2012 23:00:26 -0800 (PST) Received: by 10.180.103.70 with HTTP; Wed, 1 Feb 2012 23:00:26 -0800 (PST) In-Reply-To: References: Date: Thu, 2 Feb 2012 10:00:26 +0300 Message-ID: From: Sergey Kandaurov To: Andrew Hobbs Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-current@freebsd.org" Subject: Re: CARP on -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 07:00:28 -0000 On 2 February 2012 04:26, Andrew Hobbs wrote: > I much appreciate the responses and I was able to get CARP functioning us= ing the new ifconfig syntax under -CURRENT. Having done that, CARP is now a= cting as it should, though now I have a new challenge with devd and automat= ic firing of scripts during CARP failover. It appears that the documented m= ethod of doing this at http://www.freebsd.org/doc/handbook/disks-hast.html = no longer works with the suggested devd.conf setup; > notify 30 { > =A0 =A0 =A0 =A0match "system" "IFNET"; > =A0 =A0 =A0 =A0match "subsystem" "carp0"; > =A0 =A0 =A0 =A0match "type" "LINK_UP"; > =A0 =A0 =A0 =A0action "/usr/local/sbin/carp-hast-switch master"; > }; > > notify 30 { > =A0 =A0 =A0 =A0match "system" "IFNET"; > =A0 =A0 =A0 =A0match "subsystem" "carp0"; > =A0 =A0 =A0 =A0match "type" "LINK_DOWN"; > =A0 =A0 =A0 =A0action "/usr/local/sbin/carp-hast-switch slave"; > > Is it likely that the triggers associated with CARP for devd have changed= due to the recent new CARP overhaul? Does anyone know what the new trigger= s may be? > You will need to change this to something like (as taken from man carp): match "system" "CARP"; match "subsystem" "[0-9]+@"; match "type" "(MASTER|BACKUP)"; The subsystem now is generated as snprintf(subsys, IFNAMSIZ+5, "%u@%s", sc->sc_vhid, sc->sc_carpdev->if_xname= ); --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 11:05:56 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3345106564A; Thu, 2 Feb 2012 11:05:56 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 973488FC15; Thu, 2 Feb 2012 11:05:56 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q12B5t7P020924; Thu, 2 Feb 2012 06:05:55 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q12B5twq020923; Thu, 2 Feb 2012 11:05:55 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 2 Feb 2012 11:05:55 GMT Message-Id: <201202021105.q12B5twq020923@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 11:05:56 -0000 TB --- 2012-02-02 05:50:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-02-02 05:50:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-02-02 05:50:00 - cleaning the object tree TB --- 2012-02-02 05:51:00 - cvsupping the source tree TB --- 2012-02-02 05:51:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-02-02 05:51:26 - building world TB --- 2012-02-02 05:51:26 - CROSS_BUILD_TESTING=YES TB --- 2012-02-02 05:51:26 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-02 05:51:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-02 05:51:26 - SRCCONF=/dev/null TB --- 2012-02-02 05:51:26 - TARGET=i386 TB --- 2012-02-02 05:51:26 - TARGET_ARCH=i386 TB --- 2012-02-02 05:51:26 - TZ=UTC TB --- 2012-02-02 05:51:26 - __MAKE_CONF=/dev/null TB --- 2012-02-02 05:51:26 - cd /src TB --- 2012-02-02 05:51:26 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 2 05:51:26 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Feb 2 07:54:49 UTC 2012 TB --- 2012-02-02 07:54:49 - generating LINT kernel config TB --- 2012-02-02 07:54:49 - cd /src/sys/i386/conf TB --- 2012-02-02 07:54:49 - /usr/bin/make -B LINT TB --- 2012-02-02 07:54:50 - cd /src/sys/i386/conf TB --- 2012-02-02 07:54:50 - /usr/sbin/config -m LINT TB --- 2012-02-02 07:54:50 - building LINT kernel TB --- 2012-02-02 07:54:50 - CROSS_BUILD_TESTING=YES TB --- 2012-02-02 07:54:50 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-02 07:54:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-02 07:54:50 - SRCCONF=/dev/null TB --- 2012-02-02 07:54:50 - TARGET=i386 TB --- 2012-02-02 07:54:50 - TARGET_ARCH=i386 TB --- 2012-02-02 07:54:50 - TZ=UTC TB --- 2012-02-02 07:54:50 - __MAKE_CONF=/dev/null TB --- 2012-02-02 07:54:50 - cd /src TB --- 2012-02-02 07:54:50 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 2 07:54:50 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Thu Feb 2 08:26:46 UTC 2012 TB --- 2012-02-02 08:26:46 - cd /src/sys/i386/conf TB --- 2012-02-02 08:26:46 - /usr/sbin/config -m LINT-NOINET TB --- 2012-02-02 08:26:46 - building LINT-NOINET kernel TB --- 2012-02-02 08:26:46 - CROSS_BUILD_TESTING=YES TB --- 2012-02-02 08:26:46 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-02 08:26:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-02 08:26:46 - SRCCONF=/dev/null TB --- 2012-02-02 08:26:46 - TARGET=i386 TB --- 2012-02-02 08:26:46 - TARGET_ARCH=i386 TB --- 2012-02-02 08:26:46 - TZ=UTC TB --- 2012-02-02 08:26:46 - __MAKE_CONF=/dev/null TB --- 2012-02-02 08:26:46 - cd /src TB --- 2012-02-02 08:26:46 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Thu Feb 2 08:26:46 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Thu Feb 2 08:56:38 UTC 2012 TB --- 2012-02-02 08:56:38 - cd /src/sys/i386/conf TB --- 2012-02-02 08:56:38 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-02-02 08:56:38 - building LINT-NOINET6 kernel TB --- 2012-02-02 08:56:38 - CROSS_BUILD_TESTING=YES TB --- 2012-02-02 08:56:38 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-02 08:56:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-02 08:56:38 - SRCCONF=/dev/null TB --- 2012-02-02 08:56:38 - TARGET=i386 TB --- 2012-02-02 08:56:38 - TARGET_ARCH=i386 TB --- 2012-02-02 08:56:38 - TZ=UTC TB --- 2012-02-02 08:56:38 - __MAKE_CONF=/dev/null TB --- 2012-02-02 08:56:38 - cd /src TB --- 2012-02-02 08:56:38 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Thu Feb 2 08:56:38 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Thu Feb 2 09:27:01 UTC 2012 TB --- 2012-02-02 09:27:01 - cd /src/sys/i386/conf TB --- 2012-02-02 09:27:01 - /usr/sbin/config -m LINT-NOIP TB --- 2012-02-02 09:27:01 - building LINT-NOIP kernel TB --- 2012-02-02 09:27:01 - CROSS_BUILD_TESTING=YES TB --- 2012-02-02 09:27:01 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-02 09:27:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-02 09:27:01 - SRCCONF=/dev/null TB --- 2012-02-02 09:27:01 - TARGET=i386 TB --- 2012-02-02 09:27:01 - TARGET_ARCH=i386 TB --- 2012-02-02 09:27:01 - TZ=UTC TB --- 2012-02-02 09:27:01 - __MAKE_CONF=/dev/null TB --- 2012-02-02 09:27:01 - cd /src TB --- 2012-02-02 09:27:01 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Thu Feb 2 09:27:01 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Thu Feb 2 09:54:49 UTC 2012 TB --- 2012-02-02 09:54:49 - cd /src/sys/i386/conf TB --- 2012-02-02 09:54:49 - /usr/sbin/config -m LINT-VIMAGE TB --- 2012-02-02 09:54:49 - building LINT-VIMAGE kernel TB --- 2012-02-02 09:54:49 - CROSS_BUILD_TESTING=YES TB --- 2012-02-02 09:54:49 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-02 09:54:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-02 09:54:49 - SRCCONF=/dev/null TB --- 2012-02-02 09:54:49 - TARGET=i386 TB --- 2012-02-02 09:54:49 - TARGET_ARCH=i386 TB --- 2012-02-02 09:54:49 - TZ=UTC TB --- 2012-02-02 09:54:49 - __MAKE_CONF=/dev/null TB --- 2012-02-02 09:54:49 - cd /src TB --- 2012-02-02 09:54:49 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Thu Feb 2 09:54:49 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-VIMAGE completed on Thu Feb 2 10:25:51 UTC 2012 TB --- 2012-02-02 10:25:51 - cd /src/sys/i386/conf TB --- 2012-02-02 10:25:51 - /usr/sbin/config -m GENERIC TB --- 2012-02-02 10:25:51 - building GENERIC kernel TB --- 2012-02-02 10:25:51 - CROSS_BUILD_TESTING=YES TB --- 2012-02-02 10:25:51 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-02 10:25:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-02 10:25:51 - SRCCONF=/dev/null TB --- 2012-02-02 10:25:51 - TARGET=i386 TB --- 2012-02-02 10:25:51 - TARGET_ARCH=i386 TB --- 2012-02-02 10:25:51 - TZ=UTC TB --- 2012-02-02 10:25:51 - __MAKE_CONF=/dev/null TB --- 2012-02-02 10:25:51 - cd /src TB --- 2012-02-02 10:25:51 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Feb 2 10:25:51 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Thu Feb 2 10:50:40 UTC 2012 TB --- 2012-02-02 10:50:40 - cd /src/sys/i386/conf TB --- 2012-02-02 10:50:40 - /usr/sbin/config -m PAE TB --- 2012-02-02 10:50:40 - building PAE kernel TB --- 2012-02-02 10:50:40 - CROSS_BUILD_TESTING=YES TB --- 2012-02-02 10:50:40 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-02 10:50:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-02 10:50:40 - SRCCONF=/dev/null TB --- 2012-02-02 10:50:40 - TARGET=i386 TB --- 2012-02-02 10:50:40 - TARGET_ARCH=i386 TB --- 2012-02-02 10:50:40 - TZ=UTC TB --- 2012-02-02 10:50:40 - __MAKE_CONF=/dev/null TB --- 2012-02-02 10:50:40 - cd /src TB --- 2012-02-02 10:50:40 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Thu Feb 2 10:50:40 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PAE completed on Thu Feb 2 10:57:36 UTC 2012 TB --- 2012-02-02 10:57:36 - cd /src/sys/i386/conf TB --- 2012-02-02 10:57:36 - /usr/sbin/config -m XBOX TB --- 2012-02-02 10:57:36 - building XBOX kernel TB --- 2012-02-02 10:57:36 - CROSS_BUILD_TESTING=YES TB --- 2012-02-02 10:57:36 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-02 10:57:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-02 10:57:36 - SRCCONF=/dev/null TB --- 2012-02-02 10:57:36 - TARGET=i386 TB --- 2012-02-02 10:57:36 - TARGET_ARCH=i386 TB --- 2012-02-02 10:57:36 - TZ=UTC TB --- 2012-02-02 10:57:36 - __MAKE_CONF=/dev/null TB --- 2012-02-02 10:57:36 - cd /src TB --- 2012-02-02 10:57:36 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Thu Feb 2 10:57:36 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for XBOX completed on Thu Feb 2 11:00:49 UTC 2012 TB --- 2012-02-02 11:00:49 - cd /src/sys/i386/conf TB --- 2012-02-02 11:00:49 - /usr/sbin/config -m XEN TB --- 2012-02-02 11:00:49 - building XEN kernel TB --- 2012-02-02 11:00:49 - CROSS_BUILD_TESTING=YES TB --- 2012-02-02 11:00:49 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-02 11:00:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-02 11:00:49 - SRCCONF=/dev/null TB --- 2012-02-02 11:00:49 - TARGET=i386 TB --- 2012-02-02 11:00:49 - TARGET_ARCH=i386 TB --- 2012-02-02 11:00:49 - TZ=UTC TB --- 2012-02-02 11:00:49 - __MAKE_CONF=/dev/null TB --- 2012-02-02 11:00:49 - cd /src TB --- 2012-02-02 11:00:49 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Thu Feb 2 11:00:49 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/xen/netback/netback.c:622: warning: nested extern declaration of 'kmem_free' [-Wnested-externs] /src/sys/dev/xen/netback/netback.c:622: error: 'kernel_map' undeclared (first use in this function) /src/sys/dev/xen/netback/netback.c:622: error: (Each undeclared identifier is reported only once /src/sys/dev/xen/netback/netback.c:622: error: for each function it appears in.) /src/sys/dev/xen/netback/netback.c: In function 'xnb_alloc_communication_mem': /src/sys/dev/xen/netback/netback.c:812: warning: implicit declaration of function 'kmem_alloc_nofault' /src/sys/dev/xen/netback/netback.c:812: warning: nested extern declaration of 'kmem_alloc_nofault' [-Wnested-externs] /src/sys/dev/xen/netback/netback.c:812: error: 'kernel_map' undeclared (first use in this function) *** Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-02-02 11:05:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-02-02 11:05:55 - ERROR: failed to build XEN kernel TB --- 2012-02-02 11:05:55 - 15409.35 user 2154.46 system 18955.08 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 13:48:29 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A260106566B; Thu, 2 Feb 2012 13:48:29 +0000 (UTC) (envelope-from sennaar@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 36D3C8FC13; Thu, 2 Feb 2012 13:48:27 +0000 (UTC) Received: by lagz14 with SMTP id z14so1673151lag.13 for ; Thu, 02 Feb 2012 05:48:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+2gU6zNYOedPu7YGpd3ap99OMTjSV5r9kFTc+MYiIcM=; b=wfCcv/HK0eC7/8PlSKvyEEuA3likR3dPisBbSva+lXKp11yfnZX0Bb4q9rc8IUGjJq X2Bpf3k6FGQTqYU1oMSCFcPMnEB3bg9NH2RlKCvFgc6Xqeck3RBjHjFf0wZlKE66jLl4 Azt+WJeVToq77RlTmKkSjgzlTM3/I+PaUdsCs= MIME-Version: 1.0 Received: by 10.112.100.34 with SMTP id ev2mr762284lbb.13.1328188692082; Thu, 02 Feb 2012 05:18:12 -0800 (PST) Received: by 10.112.12.49 with HTTP; Thu, 2 Feb 2012 05:18:12 -0800 (PST) In-Reply-To: <20120126045409.GA90912@nargothrond.kdm.org> References: <20120120204459.GA51162@nargothrond.kdm.org> <1327553257.19745.6.camel@btw.pki2.com> <20120126045409.GA90912@nargothrond.kdm.org> Date: Thu, 2 Feb 2012 17:18:12 +0400 Message-ID: From: Stas Orlov To: "Kenneth D. Merry" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org, Dennis Glatting Subject: Re: LSI supported mps(4) driver available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 13:48:29 -0000 Hi, We have a pack of identical Dell R610 mahcines with H200 cards. pciconf from R610 with FreeBSD9 on ZFS, disks in JBOD mode. mps0@pci0:3:0:0: class=0x010700 card=0x1f1e1028 chip=0x00721000 rev=0x02 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = 'SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon]' class = mass storage subclass = SAS bar [10] = type I/O Port, range 32, base 0xfc00, size 256, enabled bar [14] = type Memory, range 64, base 0xdf2b0000, size 65536, enabled bar [1c] = type Memory, range 64, base 0xdf2c0000, size 262144, enabled cap 01[50] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 10[68] = PCI-Express 2 endpoint max data 128(4096) link x4(x8) cap 03[d0] = VPD cap 05[a8] = MSI supports 1 message, 64 bit cap 11[c0] = MSI-X supports 15 messages in map 0x14 enabled We all aware of the state of things with the old mps driver, so I tried to pass a hardware array with the new one. Current snapshot from yesterday fails with following - http://oi40.tinypic.com/25gdw8o.jpg iirc, Dell has a nasty habit of writing its own firmware. On Thu, Jan 26, 2012 at 8:54 AM, Kenneth D. Merry wrote: > On Wed, Jan 25, 2012 at 20:47:37 -0800, Dennis Glatting wrote: > > On Fri, 2012-01-20 at 13:44 -0700, Kenneth D. Merry wrote: > > > The LSI-supported version of the mps(4) driver that supports their 6Gb > SAS > > > HBAs as well as WarpDrive controllers, is available here: > > > > > > http://people.freebsd.org/~ken/lsi/mps_lsi.20120120.1.txt > > > > > > I plan to check it in to head next week, and then MFC it into stable/9 > a > > > week after that most likely. > > > > > > Please test it out and let me know if you run into any problems. > > > > > > In addition to supporting WarpDrive, the driver also supports > Integrated > > > RAID. > > > > > > Thanks to LSI for doing the work on this driver! > > > > > > > Does this include the SAS2008 series chips? I have two systems, one a > > Tyan FT48-B8812 with a S8812 MB and Interlagos chips, where I am > > interested in using a driver under 9.0 amd64. > > Yes. The driver in 9.0 supports the 2008 as well. > > Ken > -- > Kenneth Merry > ken@FreeBSD.ORG > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 13:53:31 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 000351065672; Thu, 2 Feb 2012 13:53:30 +0000 (UTC) (envelope-from Kashyap.Desai@lsi.com) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by mx1.freebsd.org (Postfix) with ESMTP id 266828FC16; Thu, 2 Feb 2012 13:53:30 +0000 (UTC) Received: from paledge01.lsi.com ([192.19.193.42]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKTyqVWTD+QPxeJ0BlyvAMYGslCVB/JiA1@postini.com; Thu, 02 Feb 2012 05:53:30 PST Received: from PALHUB01.lsi.com (128.94.213.114) by PALEDGE01.lsi.com (192.19.193.42) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 2 Feb 2012 08:58:00 -0500 Received: from inbexch01.lsi.com (135.36.98.37) by PALHUB01.lsi.com (128.94.213.114) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 2 Feb 2012 08:53:28 -0500 Received: from inbmail01.lsi.com ([135.36.98.64]) by inbexch01.lsi.com ([135.36.98.37]) with mapi; Thu, 2 Feb 2012 19:23:24 +0530 From: "Desai, Kashyap" To: Stas Orlov , "Kenneth D. Merry" Date: Thu, 2 Feb 2012 19:23:23 +0530 Thread-Topic: LSI supported mps(4) driver available Thread-Index: AczhsWIKkazWgE2HRl6jupNqojjpJgAAGFlQ Message-ID: References: <20120120204459.GA51162@nargothrond.kdm.org> <1327553257.19745.6.camel@btw.pki2.com> <20120126045409.GA90912@nargothrond.kdm.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "freebsd-scsi@freebsd.org" , "freebsd-current@freebsd.org" , Dennis Glatting Subject: RE: LSI supported mps(4) driver available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 13:53:31 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogb3duZXItZnJlZWJzZC1z Y3NpQGZyZWVic2Qub3JnIFttYWlsdG86b3duZXItZnJlZWJzZC0NCj4gc2NzaUBmcmVlYnNkLm9y Z10gT24gQmVoYWxmIE9mIFN0YXMgT3Jsb3YNCj4gU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDAy LCAyMDEyIDY6NDggUE0NCj4gVG86IEtlbm5ldGggRC4gTWVycnkNCj4gQ2M6IGZyZWVic2Qtc2Nz aUBmcmVlYnNkLm9yZzsgZnJlZWJzZC1jdXJyZW50QGZyZWVic2Qub3JnOyBEZW5uaXMNCj4gR2xh dHRpbmcNCj4gU3ViamVjdDogUmU6IExTSSBzdXBwb3J0ZWQgbXBzKDQpIGRyaXZlciBhdmFpbGFi bGUNCj4gDQo+IEhpLA0KPiANCj4gV2UgaGF2ZSBhIHBhY2sgb2YgaWRlbnRpY2FsIERlbGwgUjYx MCBtYWhjaW5lcyB3aXRoIEgyMDAgY2FyZHMuDQo+IA0KPiBwY2ljb25mIGZyb20gUjYxMCB3aXRo IEZyZWVCU0Q5IG9uIFpGUywgZGlza3MgaW4gSkJPRCBtb2RlLg0KPiANCj4gbXBzMEBwY2kwOjM6 MDowOiAgICAgICAgY2xhc3M9MHgwMTA3MDAgY2FyZD0weDFmMWUxMDI4IGNoaXA9MHgwMDcyMTAw MA0KPiByZXY9MHgwMiBoZHI9MHgwMA0KPiAgICAgIHZlbmRvciAgICAgPSAnTFNJIExvZ2ljIC8g U3ltYmlvcyBMb2dpYycNCj4gICAgICBkZXZpY2UgICAgID0gJ1NBUzIwMDggUENJLUV4cHJlc3Mg RnVzaW9uLU1QVCBTQVMtMiBbRmFsY29uXScNCj4gICAgICBjbGFzcyAgICAgID0gbWFzcyBzdG9y YWdlDQo+ICAgICAgc3ViY2xhc3MgICA9IFNBUw0KPiAgICAgIGJhciAgIFsxMF0gPSB0eXBlIEkv TyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGZjMDAsIHNpemUgMjU2LA0KPiBlbmFibGVkDQo+ICAg ICAgYmFyICAgWzE0XSA9IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGRmMmIwMDAwLCBz aXplIDY1NTM2LA0KPiBlbmFibGVkDQo+ICAgICAgYmFyICAgWzFjXSA9IHR5cGUgTWVtb3J5LCBy YW5nZSA2NCwgYmFzZSAweGRmMmMwMDAwLCBzaXplIDI2MjE0NCwNCj4gZW5hYmxlZA0KPiAgICAg IGNhcCAwMVs1MF0gPSBwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQg RDANCj4gICAgICBjYXAgMTBbNjhdID0gUENJLUV4cHJlc3MgMiBlbmRwb2ludCBtYXggZGF0YSAx MjgoNDA5NikgbGluayB4NCh4OCkNCj4gICAgICBjYXAgMDNbZDBdID0gVlBEDQo+ICAgICAgY2Fw IDA1W2E4XSA9IE1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UsIDY0IGJpdA0KPiAgICAgIGNhcCAxMVtj MF0gPSBNU0ktWCBzdXBwb3J0cyAxNSBtZXNzYWdlcyBpbiBtYXAgMHgxNCBlbmFibGVkDQo+IA0K PiANCj4gV2UgYWxsIGF3YXJlIG9mIHRoZSBzdGF0ZSBvZiB0aGluZ3Mgd2l0aCB0aGUgb2xkIG1w cyBkcml2ZXIsIHNvIEkgdHJpZWQNCj4gdG8NCj4gcGFzcyBhIGhhcmR3YXJlIGFycmF5IHdpdGgg dGhlIG5ldyBvbmUuDQo+IEN1cnJlbnQgc25hcHNob3QgZnJvbSB5ZXN0ZXJkYXkgZmFpbHMgd2l0 aCBmb2xsb3dpbmcgLQ0KPiBodHRwOi8vb2k0MC50aW55cGljLmNvbS8yNWdkdzhvLmpwZw0KDQpD YW4geW91IGV4cGxhaW4gbW9yZSBhYm91dCB5b3VyIHNldHVwIGFuZCBob3cgdG8gcmVwcm9kdWNl IGl0ID8NCkkgd2lsbCBoYXZlIGxvb2sgb24gdGhpcyBpc3N1ZSBpZiBpdCBpcyByZXByb2R1Y2li bGUgPw0KDQpBbHNvIHdoYXQgaXMgRmlybXdhcmUgdmVyc2lvbiB5b3UgYXJlIHVzaW5nIG9uIEgy MDAgY2FyZCA/DQoNCn4gS2FzaHlhcA0KDQo+IA0KPiBpaXJjLCBEZWxsIGhhcyBhIG5hc3R5IGhh Yml0IG9mIHdyaXRpbmcgaXRzIG93biBmaXJtd2FyZS4NCj4gDQo+IA0KPiBPbiBUaHUsIEphbiAy NiwgMjAxMiBhdCA4OjU0IEFNLCBLZW5uZXRoIEQuIE1lcnJ5IDxrZW5AZnJlZWJzZC5vcmc+DQo+ IHdyb3RlOg0KPiANCj4gPiBPbiBXZWQsIEphbiAyNSwgMjAxMiBhdCAyMDo0NzozNyAtMDgwMCwg RGVubmlzIEdsYXR0aW5nIHdyb3RlOg0KPiA+ID4gT24gRnJpLCAyMDEyLTAxLTIwIGF0IDEzOjQ0 IC0wNzAwLCBLZW5uZXRoIEQuIE1lcnJ5IHdyb3RlOg0KPiA+ID4gPiBUaGUgTFNJLXN1cHBvcnRl ZCB2ZXJzaW9uIG9mIHRoZSBtcHMoNCkgZHJpdmVyIHRoYXQgc3VwcG9ydHMgdGhlaXINCj4gNkdi DQo+ID4gU0FTDQo+ID4gPiA+IEhCQXMgYXMgd2VsbCBhcyBXYXJwRHJpdmUgY29udHJvbGxlcnMs IGlzIGF2YWlsYWJsZSBoZXJlOg0KPiA+ID4gPg0KPiA+ID4gPiBodHRwOi8vcGVvcGxlLmZyZWVi c2Qub3JnL35rZW4vbHNpL21wc19sc2kuMjAxMjAxMjAuMS50eHQNCj4gPiA+ID4NCj4gPiA+ID4g SSBwbGFuIHRvIGNoZWNrIGl0IGluIHRvIGhlYWQgbmV4dCB3ZWVrLCBhbmQgdGhlbiBNRkMgaXQg aW50bw0KPiBzdGFibGUvOQ0KPiA+IGENCj4gPiA+ID4gd2VlayBhZnRlciB0aGF0IG1vc3QgbGlr ZWx5Lg0KPiA+ID4gPg0KPiA+ID4gPiBQbGVhc2UgdGVzdCBpdCBvdXQgYW5kIGxldCBtZSBrbm93 IGlmIHlvdSBydW4gaW50byBhbnkgcHJvYmxlbXMuDQo+ID4gPiA+DQo+ID4gPiA+IEluIGFkZGl0 aW9uIHRvIHN1cHBvcnRpbmcgV2FycERyaXZlLCB0aGUgZHJpdmVyIGFsc28gc3VwcG9ydHMNCj4g PiBJbnRlZ3JhdGVkDQo+ID4gPiA+IFJBSUQuDQo+ID4gPiA+DQo+ID4gPiA+IFRoYW5rcyB0byBM U0kgZm9yIGRvaW5nIHRoZSB3b3JrIG9uIHRoaXMgZHJpdmVyIQ0KPiA+ID4gPg0KPiA+ID4NCj4g PiA+IERvZXMgdGhpcyBpbmNsdWRlIHRoZSBTQVMyMDA4IHNlcmllcyBjaGlwcz8gSSBoYXZlIHR3 byBzeXN0ZW1zLCBvbmUNCj4gYQ0KPiA+ID4gVHlhbiBGVDQ4LUI4ODEyIHdpdGggYSBTODgxMiBN QiBhbmQgSW50ZXJsYWdvcyBjaGlwcywgd2hlcmUgSSBhbQ0KPiA+ID4gaW50ZXJlc3RlZCBpbiB1 c2luZyBhIGRyaXZlciB1bmRlciA5LjAgYW1kNjQuDQo+ID4NCj4gPiBZZXMuICBUaGUgZHJpdmVy IGluIDkuMCBzdXBwb3J0cyB0aGUgMjAwOCBhcyB3ZWxsLg0KPiA+DQo+ID4gS2VuDQo+ID4gLS0N Cj4gPiBLZW5uZXRoIE1lcnJ5DQo+ID4ga2VuQEZyZWVCU0QuT1JHDQo+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBmcmVlYnNkLWN1cnJlbnRA ZnJlZWJzZC5vcmcgbWFpbGluZyBsaXN0DQo+ID4gaHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21h aWxtYW4vbGlzdGluZm8vZnJlZWJzZC1jdXJyZW50DQo+ID4gVG8gdW5zdWJzY3JpYmUsIHNlbmQg YW55IG1haWwgdG8gImZyZWVic2QtY3VycmVudC0NCj4gdW5zdWJzY3JpYmVAZnJlZWJzZC5vcmci DQo+ID4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gZnJlZWJzZC1zY3NpQGZyZWVic2Qub3JnIG1haWxpbmcgbGlzdA0KPiBodHRwOi8vbGlzdHMu ZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLXNjc2kNCj4gVG8gdW5zdWJzY3Jp YmUsIHNlbmQgYW55IG1haWwgdG8gImZyZWVic2Qtc2NzaS11bnN1YnNjcmliZUBmcmVlYnNkLm9y ZyINCg== From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 14:14:40 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35F6D106564A; Thu, 2 Feb 2012 14:14:40 +0000 (UTC) (envelope-from sennaar@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 384998FC0C; Thu, 2 Feb 2012 14:14:38 +0000 (UTC) Received: by lagz14 with SMTP id z14so1691766lag.13 for ; Thu, 02 Feb 2012 06:14:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JZ10XowrofnFQRnNXJ5uJZvhoC7Mk6rWGiftG4ytEVc=; b=pxiB4nzVW0ZQ/enVBJEvPUGi0rbPoEy7hp3NSDZogb/2MXf+47SCkUqfFObkSSXbdz LvQpP48/HEETeoqaw9kX54qchjLeKfjNeuL0nkFGeKJc8mGyrMBBTFMgpjLbLaTuynLG lQLyg4H0gVTl8/G64V6nGsgyekUMc2OPF4wBo= MIME-Version: 1.0 Received: by 10.112.103.8 with SMTP id fs8mr763958lbb.39.1328192077913; Thu, 02 Feb 2012 06:14:37 -0800 (PST) Received: by 10.112.12.49 with HTTP; Thu, 2 Feb 2012 06:14:37 -0800 (PST) In-Reply-To: References: <20120120204459.GA51162@nargothrond.kdm.org> <1327553257.19745.6.camel@btw.pki2.com> <20120126045409.GA90912@nargothrond.kdm.org> Date: Thu, 2 Feb 2012 18:14:37 +0400 Message-ID: From: Stas Orlov To: "Desai, Kashyap" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-scsi@freebsd.org" , "freebsd-current@freebsd.org" , "Kenneth D. Merry" , Dennis Glatting Subject: Re: LSI supported mps(4) driver available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 14:14:40 -0000 Sure, I've made two RAID (1 and 10 ) arrays within LSI Config Utility and tried to install fresh current, every time I get error linked above, so yes, it's reproducible. MPT Firmware 2.15.63.00-IR Package Version 7.01.33.00 I do have another spare R610 with that card, I'll test it with current later this evening. On Thu, Feb 2, 2012 at 5:53 PM, Desai, Kashyap wrote: > > > > -----Original Message----- > > From: owner-freebsd-scsi@freebsd.org [mailto:owner-freebsd- > > scsi@freebsd.org] On Behalf Of Stas Orlov > > Sent: Thursday, February 02, 2012 6:48 PM > > To: Kenneth D. Merry > > Cc: freebsd-scsi@freebsd.org; freebsd-current@freebsd.org; Dennis > > Glatting > > Subject: Re: LSI supported mps(4) driver available > > > > Hi, > > > > We have a pack of identical Dell R610 mahcines with H200 cards. > > > > pciconf from R610 with FreeBSD9 on ZFS, disks in JBOD mode. > > > > mps0@pci0:3:0:0: class=0x010700 card=0x1f1e1028 chip=0x00721000 > > rev=0x02 hdr=0x00 > > vendor = 'LSI Logic / Symbios Logic' > > device = 'SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon]' > > class = mass storage > > subclass = SAS > > bar [10] = type I/O Port, range 32, base 0xfc00, size 256, > > enabled > > bar [14] = type Memory, range 64, base 0xdf2b0000, size 65536, > > enabled > > bar [1c] = type Memory, range 64, base 0xdf2c0000, size 262144, > > enabled > > cap 01[50] = powerspec 3 supports D0 D1 D2 D3 current D0 > > cap 10[68] = PCI-Express 2 endpoint max data 128(4096) link x4(x8) > > cap 03[d0] = VPD > > cap 05[a8] = MSI supports 1 message, 64 bit > > cap 11[c0] = MSI-X supports 15 messages in map 0x14 enabled > > > > > > We all aware of the state of things with the old mps driver, so I tried > > to > > pass a hardware array with the new one. > > Current snapshot from yesterday fails with following - > > http://oi40.tinypic.com/25gdw8o.jpg > > Can you explain more about your setup and how to reproduce it ? > I will have look on this issue if it is reproducible ? > > Also what is Firmware version you are using on H200 card ? > > ~ Kashyap > > > > > iirc, Dell has a nasty habit of writing its own firmware. > > > > > > On Thu, Jan 26, 2012 at 8:54 AM, Kenneth D. Merry > > wrote: > > > > > On Wed, Jan 25, 2012 at 20:47:37 -0800, Dennis Glatting wrote: > > > > On Fri, 2012-01-20 at 13:44 -0700, Kenneth D. Merry wrote: > > > > > The LSI-supported version of the mps(4) driver that supports their > > 6Gb > > > SAS > > > > > HBAs as well as WarpDrive controllers, is available here: > > > > > > > > > > http://people.freebsd.org/~ken/lsi/mps_lsi.20120120.1.txt > > > > > > > > > > I plan to check it in to head next week, and then MFC it into > > stable/9 > > > a > > > > > week after that most likely. > > > > > > > > > > Please test it out and let me know if you run into any problems. > > > > > > > > > > In addition to supporting WarpDrive, the driver also supports > > > Integrated > > > > > RAID. > > > > > > > > > > Thanks to LSI for doing the work on this driver! > > > > > > > > > > > > > Does this include the SAS2008 series chips? I have two systems, one > > a > > > > Tyan FT48-B8812 with a S8812 MB and Interlagos chips, where I am > > > > interested in using a driver under 9.0 amd64. > > > > > > Yes. The driver in 9.0 supports the 2008 as well. > > > > > > Ken > > > -- > > > Kenneth Merry > > > ken@FreeBSD.ORG > > > _______________________________________________ > > > freebsd-current@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to "freebsd-current- > > unsubscribe@freebsd.org" > > > > > _______________________________________________ > > freebsd-scsi@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 14:43:45 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB1731065670; Thu, 2 Feb 2012 14:43:45 +0000 (UTC) (envelope-from Kashyap.Desai@lsi.com) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by mx1.freebsd.org (Postfix) with ESMTP id 124118FC16; Thu, 2 Feb 2012 14:43:44 +0000 (UTC) Received: from paledge01.lsi.com ([192.19.193.42]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKTyqhHzF4HERM4o6GrhjguUqgCv6h7v3b@postini.com; Thu, 02 Feb 2012 06:43:45 PST Received: from PALCAS01.lsi.com (128.94.213.117) by PALEDGE01.lsi.com (192.19.193.42) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 2 Feb 2012 09:48:14 -0500 Received: from inbexch02.lsi.com (135.36.98.40) by PALCAS01.lsi.com (128.94.213.117) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 2 Feb 2012 09:43:42 -0500 Received: from inbmail01.lsi.com ([135.36.98.64]) by inbexch02.lsi.com ([135.36.98.40]) with mapi; Thu, 2 Feb 2012 20:13:38 +0530 From: "Desai, Kashyap" To: Stas Orlov Date: Thu, 2 Feb 2012 20:13:37 +0530 Thread-Topic: LSI supported mps(4) driver available Thread-Index: AczhtQaMAcyXx5tpRhWZfiMMmo/RHgAAwYYQ Message-ID: References: <20120120204459.GA51162@nargothrond.kdm.org> <1327553257.19745.6.camel@btw.pki2.com> <20120126045409.GA90912@nargothrond.kdm.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "freebsd-scsi@freebsd.org" , "freebsd-current@freebsd.org" , "Kenneth D. Merry" , Dennis Glatting Subject: RE: LSI supported mps(4) driver available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 14:43:46 -0000 DQoNCkZyb206IFN0YXMgT3Jsb3YgW21haWx0bzpzZW5uYWFyQGdtYWlsLmNvbV0gDQpTZW50OiBU aHVyc2RheSwgRmVicnVhcnkgMDIsIDIwMTIgNzo0NSBQTQ0KVG86IERlc2FpLCBLYXNoeWFwDQpD YzogS2VubmV0aCBELiBNZXJyeTsgZnJlZWJzZC1zY3NpQGZyZWVic2Qub3JnOyBmcmVlYnNkLWN1 cnJlbnRAZnJlZWJzZC5vcmc7IERlbm5pcyBHbGF0dGluZw0KU3ViamVjdDogUmU6IExTSSBzdXBw b3J0ZWQgbXBzKDQpIGRyaXZlciBhdmFpbGFibGUNCg0KU3VyZSwgSSd2ZSBtYWRlIHR3byBSQUlE ICgxIGFuZCAxMCApIGFycmF5cyB3aXRoaW4gTFNJIENvbmZpZyBVdGlsaXR5IGFuZCB0cmllZCB0 byBpbnN0YWxsIGZyZXNoIGN1cnJlbnQsIGV2ZXJ5IHRpbWUgSSBnZXQgZXJyb3IgbGlua2VkIGFi b3ZlLCBzbyB5ZXMsIGl0J3PCoHJlcHJvZHVjaWJsZS4NCg0KLT4gV2hhdCBJIHVuZGVyc3Rvb2Qg aGVyZSBpcywgeW91IGhhdmUgdHdvIHJhaWQgdm9sdW1lcyBSQUlEMSBhbmQgUkFJRDEwLCBhbmQg dHJ5aW5nIHRvIGluc3RhbGwgRnJlZUJTRCAoQWdhaW4gY2xhcmlmeSB3aGljaCB2ZXJzaW9uIG9m IEZyZWVCU0QgeW91IGFyZSB1c2luZykNCg0KDQpUcnkgZXJhc2luZyBhIGNvbnRyb2xsZXIgRlcg Y29tcGxldGVseSBhbmQgcmUtaW5zdGFsbCBldmVyeXRoaW5nIGZyb20gZnJlc2guDQooSGVyZSBt YWtlIHN1cmUgeW91IGZsYXNoIGNvbXBsZXRlbHkuIEhvcGUgeW91IGFyZSBhd2FyZSBvZiBjb250 cm9sbGVyIGZpcm13YXJlIHVwZ3JhZGUgcHJvY2VzcykNCg0KT3VyIGJvYXJkIGhhcyBEUE0gdGFi bGVzIGFuZCBmb3IgUmFpZCB2b2x1bWUgaXQgaXMgbWF4aW11bSAyIGVudHJ5LiANCldoZW4geW91 IGhhdmUgbW9yZSB0aGFuIHR3byBpbmFjdGl2ZSB2b2x1bWVzLCB3ZSBjYW5ub3QgYWRkIGFub3Ro ZXIgcmFpZCB2b2x1bWUuDQpUaGVyZSBpcyBzb21lIGltcGxlbWVudGF0aW9uIHJlY2VudGx5IGRv bmUgYnkgQklPUyB0ZWFtIHJlbGF0ZWQgdG8gdGhpcyBhcmVhLiBXaGVyZSBCSU9TIGl0c2VsZiB3 aWxsIGVyYXNlIGluYWN0aXZlIFJhaWQgdm9sdW1lIGVudHJ5IGZyb20gRFBNIHBhZ2VzLg0KDQp+ IEthc2h5YXANCg0KDQpNUFQgRmlybXdhcmUgMi4xNS42My4wMC1JUg0KUGFja2FnZSBWZXJzaW9u IDcuMDEuMzMuMDANCg0KSSBkbyBoYXZlIGFub3RoZXIgc3BhcmUgUjYxMCB3aXRoIHRoYXQgY2Fy ZCwgSSdsbCB0ZXN0IGl0IHdpdGggY3VycmVudCBsYXRlciB0aGlzIGV2ZW5pbmcuDQoNCk9uIFRo dSwgRmViIDIsIDIwMTIgYXQgNTo1MyBQTSwgRGVzYWksIEthc2h5YXAgPEthc2h5YXAuRGVzYWlA bHNpLmNvbT4gd3JvdGU6DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBvd25lci1mcmVlYnNkLXNjc2lAZnJlZWJzZC5vcmcgW21haWx0bzpvd25lci1mcmVlYnNkLQ0K PiBzY3NpQGZyZWVic2Qub3JnXSBPbiBCZWhhbGYgT2YgU3RhcyBPcmxvdg0KPiBTZW50OiBUaHVy c2RheSwgRmVicnVhcnkgMDIsIDIwMTIgNjo0OCBQTQ0KPiBUbzogS2VubmV0aCBELiBNZXJyeQ0K PiBDYzogZnJlZWJzZC1zY3NpQGZyZWVic2Qub3JnOyBmcmVlYnNkLWN1cnJlbnRAZnJlZWJzZC5v cmc7IERlbm5pcw0KPiBHbGF0dGluZw0KPiBTdWJqZWN0OiBSZTogTFNJIHN1cHBvcnRlZCBtcHMo NCkgZHJpdmVyIGF2YWlsYWJsZQ0KPg0KPiBIaSwNCj4NCj4gV2UgaGF2ZSBhIHBhY2sgb2YgaWRl bnRpY2FsIERlbGwgUjYxMCBtYWhjaW5lcyB3aXRoIEgyMDAgY2FyZHMuDQo+DQo+IHBjaWNvbmYg ZnJvbSBSNjEwIHdpdGggRnJlZUJTRDkgb24gWkZTLCBkaXNrcyBpbiBKQk9EIG1vZGUuDQo+DQo+ IG1wczBAcGNpMDozOjA6MDogwqAgwqAgwqAgwqBjbGFzcz0weDAxMDcwMCBjYXJkPTB4MWYxZTEw MjggY2hpcD0weDAwNzIxMDAwDQo+IHJldj0weDAyIGhkcj0weDAwDQo+IMKgIMKgIMKgdmVuZG9y IMKgIMKgID0gJ0xTSSBMb2dpYyAvIFN5bWJpb3MgTG9naWMnDQo+IMKgIMKgIMKgZGV2aWNlIMKg IMKgID0gJ1NBUzIwMDggUENJLUV4cHJlc3MgRnVzaW9uLU1QVCBTQVMtMiBbRmFsY29uXScNCj4g wqAgwqAgwqBjbGFzcyDCoCDCoCDCoD0gbWFzcyBzdG9yYWdlDQo+IMKgIMKgIMKgc3ViY2xhc3Mg wqAgPSBTQVMNCj4gwqAgwqAgwqBiYXIgwqAgWzEwXSA9IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMy LCBiYXNlIDB4ZmMwMCwgc2l6ZSAyNTYsDQo+IGVuYWJsZWQNCj4gwqAgwqAgwqBiYXIgwqAgWzE0 XSA9IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGRmMmIwMDAwLCBzaXplIDY1NTM2LA0K PiBlbmFibGVkDQo+IMKgIMKgIMKgYmFyIMKgIFsxY10gPSB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQs IGJhc2UgMHhkZjJjMDAwMCwgc2l6ZSAyNjIxNDQsDQo+IGVuYWJsZWQNCj4gwqAgwqAgwqBjYXAg MDFbNTBdID0gcG93ZXJzcGVjIDMgwqBzdXBwb3J0cyBEMCBEMSBEMiBEMyDCoGN1cnJlbnQgRDAN Cj4gwqAgwqAgwqBjYXAgMTBbNjhdID0gUENJLUV4cHJlc3MgMiBlbmRwb2ludCBtYXggZGF0YSAx MjgoNDA5NikgbGluayB4NCh4OCkNCj4gwqAgwqAgwqBjYXAgMDNbZDBdID0gVlBEDQo+IMKgIMKg IMKgY2FwIDA1W2E4XSA9IE1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UsIDY0IGJpdA0KPiDCoCDCoCDC oGNhcCAxMVtjMF0gPSBNU0ktWCBzdXBwb3J0cyAxNSBtZXNzYWdlcyBpbiBtYXAgMHgxNCBlbmFi bGVkDQo+DQo+DQo+IFdlIGFsbCBhd2FyZSBvZiB0aGUgc3RhdGUgb2YgdGhpbmdzIHdpdGggdGhl IG9sZCBtcHMgZHJpdmVyLCBzbyBJIHRyaWVkDQo+IHRvDQo+IHBhc3MgYSBoYXJkd2FyZSBhcnJh eSB3aXRoIHRoZSBuZXcgb25lLg0KPiBDdXJyZW50IHNuYXBzaG90IGZyb20geWVzdGVyZGF5IGZh aWxzIHdpdGggZm9sbG93aW5nIC0NCj4gaHR0cDovL29pNDAudGlueXBpYy5jb20vMjVnZHc4by5q cGcNCkNhbiB5b3UgZXhwbGFpbiBtb3JlIGFib3V0IHlvdXIgc2V0dXAgYW5kIGhvdyB0byByZXBy b2R1Y2UgaXQgPw0KSSB3aWxsIGhhdmUgbG9vayBvbiB0aGlzIGlzc3VlIGlmIGl0IGlzIHJlcHJv ZHVjaWJsZSA/DQoNCkFsc28gd2hhdCBpcyBGaXJtd2FyZSB2ZXJzaW9uIHlvdSBhcmUgdXNpbmcg b24gSDIwMCBjYXJkID8NCg0KfiBLYXNoeWFwDQoNCj4NCj4gaWlyYywgRGVsbCBoYXMgYSBuYXN0 eSBoYWJpdCBvZiB3cml0aW5nIGl0cyBvd24gZmlybXdhcmUuDQo+DQo+DQo+IE9uIFRodSwgSmFu IDI2LCAyMDEyIGF0IDg6NTQgQU0sIEtlbm5ldGggRC4gTWVycnkgPGtlbkBmcmVlYnNkLm9yZz4N Cj4gd3JvdGU6DQo+DQo+ID4gT24gV2VkLCBKYW4gMjUsIDIwMTIgYXQgMjA6NDc6MzcgLTA4MDAs IERlbm5pcyBHbGF0dGluZyB3cm90ZToNCj4gPiA+IE9uIEZyaSwgMjAxMi0wMS0yMCBhdCAxMzo0 NCAtMDcwMCwgS2VubmV0aCBELiBNZXJyeSB3cm90ZToNCj4gPiA+ID4gVGhlIExTSS1zdXBwb3J0 ZWQgdmVyc2lvbiBvZiB0aGUgbXBzKDQpIGRyaXZlciB0aGF0IHN1cHBvcnRzIHRoZWlyDQo+IDZH Yg0KPiA+IFNBUw0KPiA+ID4gPiBIQkFzIGFzIHdlbGwgYXMgV2FycERyaXZlIGNvbnRyb2xsZXJz LCBpcyBhdmFpbGFibGUgaGVyZToNCj4gPiA+ID4NCj4gPiA+ID4gaHR0cDovL3Blb3BsZS5mcmVl YnNkLm9yZy9+a2VuL2xzaS9tcHNfbHNpLjIwMTIwMTIwLjEudHh0DQo+ID4gPiA+DQo+ID4gPiA+ IEkgcGxhbiB0byBjaGVjayBpdCBpbiB0byBoZWFkIG5leHQgd2VlaywgYW5kIHRoZW4gTUZDIGl0 IGludG8NCj4gc3RhYmxlLzkNCj4gPiBhDQo+ID4gPiA+IHdlZWsgYWZ0ZXIgdGhhdCBtb3N0IGxp a2VseS4NCj4gPiA+ID4NCj4gPiA+ID4gUGxlYXNlIHRlc3QgaXQgb3V0IGFuZCBsZXQgbWUga25v dyBpZiB5b3UgcnVuIGludG8gYW55IHByb2JsZW1zLg0KPiA+ID4gPg0KPiA+ID4gPiBJbiBhZGRp dGlvbiB0byBzdXBwb3J0aW5nIFdhcnBEcml2ZSwgdGhlIGRyaXZlciBhbHNvIHN1cHBvcnRzDQo+ ID4gSW50ZWdyYXRlZA0KPiA+ID4gPiBSQUlELg0KPiA+ID4gPg0KPiA+ID4gPiBUaGFua3MgdG8g TFNJIGZvciBkb2luZyB0aGUgd29yayBvbiB0aGlzIGRyaXZlciENCj4gPiA+ID4NCj4gPiA+DQo+ ID4gPiBEb2VzIHRoaXMgaW5jbHVkZSB0aGUgU0FTMjAwOCBzZXJpZXMgY2hpcHM/IEkgaGF2ZSB0 d28gc3lzdGVtcywgb25lDQo+IGENCj4gPiA+IFR5YW4gRlQ0OC1CODgxMiB3aXRoIGEgUzg4MTIg TUIgYW5kIEludGVybGFnb3MgY2hpcHMsIHdoZXJlIEkgYW0NCj4gPiA+IGludGVyZXN0ZWQgaW4g dXNpbmcgYSBkcml2ZXIgdW5kZXIgOS4wIGFtZDY0Lg0KPiA+DQo+ID4gWWVzLiDCoFRoZSBkcml2 ZXIgaW4gOS4wIHN1cHBvcnRzIHRoZSAyMDA4IGFzIHdlbGwuDQo+ID4NCj4gPiBLZW4NCj4gPiAt LQ0KPiA+IEtlbm5ldGggTWVycnkNCj4gPiBrZW5ARnJlZUJTRC5PUkcNCj4gPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IGZyZWVic2QtY3VycmVu dEBmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QNCj4gPiBodHRwOi8vbGlzdHMuZnJlZWJzZC5vcmcv bWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLWN1cnJlbnQNCj4gPiBUbyB1bnN1YnNjcmliZSwgc2Vu ZCBhbnkgbWFpbCB0byAiZnJlZWJzZC1jdXJyZW50LQ0KPiB1bnN1YnNjcmliZUBmcmVlYnNkLm9y ZyINCj4gPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBmcmVlYnNkLXNjc2lAZnJlZWJzZC5vcmcgbWFpbGluZyBsaXN0DQo+IGh0dHA6Ly9saXN0 cy5mcmVlYnNkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZyZWVic2Qtc2NzaQ0KPiBUbyB1bnN1YnNj cmliZSwgc2VuZCBhbnkgbWFpbCB0byAiZnJlZWJzZC1zY3NpLXVuc3Vic2NyaWJlQGZyZWVic2Qu b3JnIg0KDQo= From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 14:58:50 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CAC4106564A; Thu, 2 Feb 2012 14:58:50 +0000 (UTC) (envelope-from sennaar@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6D96E8FC16; Thu, 2 Feb 2012 14:58:49 +0000 (UTC) Received: by lagz14 with SMTP id z14so1725195lag.13 for ; Thu, 02 Feb 2012 06:58:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CemPQqQoMIzrTHvV6uha4uUuXU/GcV0wYlK/1RPcpkc=; b=Jklvz6F6jGELEVIVyDVcAqsTZ3zKv2AuApL4M/gkFCEWUEMURECYF+EQkrfdlWZi9S Yx1hl3Tn7uTWrQVU+NSvu02epkrHLFgcssu8dEttuWsQNyS96jynDVVNQrcQTY6JNgV7 IgJ7Qjj00Sa31LVqTrQYvH8RHWlu7Ysy4KDBs= MIME-Version: 1.0 Received: by 10.152.125.12 with SMTP id mm12mr1606292lab.48.1328194727984; Thu, 02 Feb 2012 06:58:47 -0800 (PST) Received: by 10.112.12.49 with HTTP; Thu, 2 Feb 2012 06:58:47 -0800 (PST) In-Reply-To: References: <20120120204459.GA51162@nargothrond.kdm.org> <1327553257.19745.6.camel@btw.pki2.com> <20120126045409.GA90912@nargothrond.kdm.org> Date: Thu, 2 Feb 2012 18:58:47 +0400 Message-ID: From: Stas Orlov To: "Desai, Kashyap" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-scsi@freebsd.org" , "freebsd-current@freebsd.org" , "Kenneth D. Merry" , Dennis Glatting Subject: Re: LSI supported mps(4) driver available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 14:58:50 -0000 >> (Again clarify which version of FreeBSD you are using) As I've stated earlier it's current snapshot from the other day, to be more specific FreeBSD10-CURRENT r230857 Ok, I'll try to upgrade firmware. On Thu, Feb 2, 2012 at 6:43 PM, Desai, Kashyap wrote: > > > From: Stas Orlov [mailto:sennaar@gmail.com] > Sent: Thursday, February 02, 2012 7:45 PM > To: Desai, Kashyap > Cc: Kenneth D. Merry; freebsd-scsi@freebsd.org; > freebsd-current@freebsd.org; Dennis Glatting > Subject: Re: LSI supported mps(4) driver available > > Sure, I've made two RAID (1 and 10 ) arrays within LSI Config Utility and > tried to install fresh current, every time I get error linked above, so > yes, it's reproducible. > > -> What I understood here is, you have two raid volumes RAID1 and RAID10, > and trying to install FreeBSD (Again clarify which version of FreeBSD you > are using) > > > Try erasing a controller FW completely and re-install everything from > fresh. > (Here make sure you flash completely. Hope you are aware of controller > firmware upgrade process) > > Our board has DPM tables and for Raid volume it is maximum 2 entry. > When you have more than two inactive volumes, we cannot add another raid > volume. > There is some implementation recently done by BIOS team related to this > area. Where BIOS itself will erase inactive Raid volume entry from DPM > pages. > > ~ Kashyap > > > MPT Firmware 2.15.63.00-IR > Package Version 7.01.33.00 > > I do have another spare R610 with that card, I'll test it with current > later this evening. > > On Thu, Feb 2, 2012 at 5:53 PM, Desai, Kashyap > wrote: > > > > -----Original Message----- > > From: owner-freebsd-scsi@freebsd.org [mailto:owner-freebsd- > > scsi@freebsd.org] On Behalf Of Stas Orlov > > Sent: Thursday, February 02, 2012 6:48 PM > > To: Kenneth D. Merry > > Cc: freebsd-scsi@freebsd.org; freebsd-current@freebsd.org; Dennis > > Glatting > > Subject: Re: LSI supported mps(4) driver available > > > > Hi, > > > > We have a pack of identical Dell R610 mahcines with H200 cards. > > > > pciconf from R610 with FreeBSD9 on ZFS, disks in JBOD mode. > > > > mps0@pci0:3:0:0: class=0x010700 card=0x1f1e1028 chip=0x00721000 > > rev=0x02 hdr=0x00 > > vendor = 'LSI Logic / Symbios Logic' > > device = 'SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon]' > > class = mass storage > > subclass = SAS > > bar [10] = type I/O Port, range 32, base 0xfc00, size 256, > > enabled > > bar [14] = type Memory, range 64, base 0xdf2b0000, size 65536, > > enabled > > bar [1c] = type Memory, range 64, base 0xdf2c0000, size 262144, > > enabled > > cap 01[50] = powerspec 3 supports D0 D1 D2 D3 current D0 > > cap 10[68] = PCI-Express 2 endpoint max data 128(4096) link x4(x8) > > cap 03[d0] = VPD > > cap 05[a8] = MSI supports 1 message, 64 bit > > cap 11[c0] = MSI-X supports 15 messages in map 0x14 enabled > > > > > > We all aware of the state of things with the old mps driver, so I tried > > to > > pass a hardware array with the new one. > > Current snapshot from yesterday fails with following - > > http://oi40.tinypic.com/25gdw8o.jpg > Can you explain more about your setup and how to reproduce it ? > I will have look on this issue if it is reproducible ? > > Also what is Firmware version you are using on H200 card ? > > ~ Kashyap > > > > > iirc, Dell has a nasty habit of writing its own firmware. > > > > > > On Thu, Jan 26, 2012 at 8:54 AM, Kenneth D. Merry > > wrote: > > > > > On Wed, Jan 25, 2012 at 20:47:37 -0800, Dennis Glatting wrote: > > > > On Fri, 2012-01-20 at 13:44 -0700, Kenneth D. Merry wrote: > > > > > The LSI-supported version of the mps(4) driver that supports their > > 6Gb > > > SAS > > > > > HBAs as well as WarpDrive controllers, is available here: > > > > > > > > > > http://people.freebsd.org/~ken/lsi/mps_lsi.20120120.1.txt > > > > > > > > > > I plan to check it in to head next week, and then MFC it into > > stable/9 > > > a > > > > > week after that most likely. > > > > > > > > > > Please test it out and let me know if you run into any problems. > > > > > > > > > > In addition to supporting WarpDrive, the driver also supports > > > Integrated > > > > > RAID. > > > > > > > > > > Thanks to LSI for doing the work on this driver! > > > > > > > > > > > > > Does this include the SAS2008 series chips? I have two systems, one > > a > > > > Tyan FT48-B8812 with a S8812 MB and Interlagos chips, where I am > > > > interested in using a driver under 9.0 amd64. > > > > > > Yes. The driver in 9.0 supports the 2008 as well. > > > > > > Ken > > > -- > > > Kenneth Merry > > > ken@FreeBSD.ORG > > > _______________________________________________ > > > freebsd-current@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to "freebsd-current- > > unsubscribe@freebsd.org" > > > > > _______________________________________________ > > freebsd-scsi@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 14:41:52 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59DF01065672; Thu, 2 Feb 2012 14:41:52 +0000 (UTC) (envelope-from MFischer@reitzner.de) Received: from mail-out.m-online.net (mail-out.m-online.net [IPv6:2001:a60:0:32:0:1:25:1]) by mx1.freebsd.org (Postfix) with ESMTP id AD2088FC0C; Thu, 2 Feb 2012 14:41:51 +0000 (UTC) Received: from frontend1.mail.m-online.net (frontend1.mail.intern.m-online.net [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id EC80C18000C3; Thu, 2 Feb 2012 15:41:49 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.8.164]) by mail.m-online.net (Postfix) with ESMTP id 0D8F91C00145; Thu, 2 Feb 2012 15:41:50 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.180]) by localhost (dynscan1.mail.m-online.net [192.168.8.164]) (amavisd-new, port 10024) with ESMTP id pbt20MqmkTZP; Thu, 2 Feb 2012 15:41:49 +0100 (CET) Received: from EX02.reitzner.local (ppp-93-104-163-75.dynamic.mnet-online.de [93.104.163.75]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPS; Thu, 2 Feb 2012 15:41:49 +0100 (CET) Received: from EX02.reitzner.local ([fe80::3c40:2523:615c:77be]) by EX02.reitzner.local ([fe80::3c40:2523:615c:77be%14]) with mapi id 14.02.0247.003; Thu, 2 Feb 2012 15:41:48 +0100 From: Fischer Markus To: "freebsd-acpi@FreeBSD.org" Thread-Topic: Problem with ACPI / reboot: Black Screen? Thread-Index: AczhuMqZZ/If458/Rr+I5PkkFVMNvQ== Date: Thu, 2 Feb 2012 14:41:47 +0000 Message-ID: <35CFCFC220BF044DA8BFCE7FC11853D7033B49@EX02.reitzner.local> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [88.128.222.123] MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 02 Feb 2012 16:20:03 +0000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-current@freebsd.org" Subject: Problem with ACPI / reboot: Black Screen? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 14:41:52 -0000 Hello Guys, Tank you for fast andere. I habe Check The command: 'shutdown -r now' and 'init 6' The Same Problem! Can anyone help me? Thanks? by Markus Fischer Germany From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 20:39:08 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7630F1065670 for ; Thu, 2 Feb 2012 20:39:08 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 1C4E58FC15 for ; Thu, 2 Feb 2012 20:39:07 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1Rt3Qw-0002qJ-Up>; Thu, 02 Feb 2012 21:39:07 +0100 Received: from e178015217.adsl.alicedsl.de ([85.178.15.217] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1Rt3Qw-00061k-OY>; Thu, 02 Feb 2012 21:39:06 +0100 Message-ID: <4F2AF46A.8030105@zedat.fu-berlin.de> Date: Thu, 02 Feb 2012 21:39:06 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120119 Thunderbird/9.0 MIME-Version: 1.0 To: Current FreeBSD X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig76971744B705E9567BFB5044" X-Originating-IP: 85.178.15.217 Subject: x11/kde4-workspace 4.7.4: fails to be built on FreeBSD 10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 20:39:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig76971744B705E9567BFB5044 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Since a couple of days I try to update/compile x11/kd4-workspace (from 4.7.3 -> 4.7.4), but it fails. Compilation fails with gcc 4.2.1 and CLANG as well. On FreeBSD 9.0-STABLE/amd64 boxes I tried the port can be build with CLANG without any problem. Waht's going wrong on my box? Any hints? Thanks in advance, Oliver Linking CXX shared library ../../../lib/libprocesscore.so [ 13%] Built target processcore Scanning dependencies of target processui_automoc Generating ProcessModel.moc Generating ProcessModel_p.moc Generating ksysguardprocesslist.moc Generating ProcessFilter.moc Generating KTextEditVT.moc Generating ReniceDlg.moc Generating moc_scripting.cpp [ 13%] Built target processui_automoc [ 13%] Generating ui_ProcessWidgetUI.h [ 13%] Generating ui_ReniceDlgUi.h Scanning dependencies of target processui [ 13%] Building CXX object libs/ksysguard/processui/CMakeFiles/processui.dir/processui_automoc.o [ 13%] Building CXX object libs/ksysguard/processui/CMakeFiles/processui.dir/ksysguardprocesslist.o [ 13%] Building CXX object libs/ksysguard/processui/CMakeFiles/processui.dir/ProcessFilter.o [ 13%] Building CXX object libs/ksysguard/processui/CMakeFiles/processui.dir/ProcessModel.o /usr/ports/x11/kde4-workspace/work/kde-workspace-4.7.4/libs/ksysguard/pro= cessui/ProcessModel.cpp:424:40: error: redefinition of 'i' with a different type QMap::iterator i =3D mXResClientResources.lowerBound(-(qlonglong)(wid)); ^ /usr/ports/x11/kde4-workspace/work/kde-workspace-4.7.4/libs/ksysguard/pro= cessui/ProcessModel.cpp:422:15: note: previous definition is here for (uint i=3D0; i < count; ++i) { ^ /usr/ports/x11/kde4-workspace/work/kde-workspace-4.7.4/libs/ksysguard/pro= cessui/ProcessModel.cpp:425:17: error: 'operator _Bool' is a private member of 'QMap::iterator' if(i =3D=3D mXResClientResources.end()) ^~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/local/include/qt4/QtCore/qmap.h:294:16: note: declared private here inline operator bool() const { return false; } ^ /usr/ports/x11/kde4-workspace/work/kde-workspace-4.7.4/libs/ksysguard/pro= cessui/ProcessModel.cpp:428:15: error: member reference base type 'uint' (aka 'unsigned int') is not a structure or union if(-i.key() !=3D (qlonglong)(wid & ~i.value())) ~ ^ /usr/ports/x11/kde4-workspace/work/kde-workspace-4.7.4/libs/ksysguard/pro= cessui/ProcessModel.cpp:428:45: error: member reference base type 'uint' (aka 'unsigned int') is not a structure or union if(-i.key() !=3D (qlonglong)(wid & ~i.value())) ~ ^ /usr/ports/x11/kde4-workspace/work/kde-workspace-4.7.4/libs/ksysguard/pro= cessui/ProcessModel.cpp:441:36: error: no viable conversion from 'uint' (aka 'unsigned int') to 'QMap::iterator' mXResClientResources.erase(i); ^ /usr/local/include/qt4/QtCore/qmap.h:230:11: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 'uint' (aka 'unsigned int') to 'const QMap::iterator &' for 1st argument= ; class iterator ^ /usr/local/include/qt4/QtCore/qmap.h:245:16: note: candidate constructor not viable: no known conversion from 'uint' (aka 'unsigned int') to 'QMapData::Node *' for 1st argument; inline iterator(QMapData::Node *node) : i(node) { } ^ /usr/local/include/qt4/QtCore/qmap.h:378:29: note: passing argument to parameter 'it' here iterator erase(iterator it); ^ 5 errors generated. gmake[2]: *** [libs/ksysguard/processui/CMakeFiles/processui.dir/ProcessModel.o] Error = 1 gmake[1]: *** [libs/ksysguard/processui/CMakeFiles/processui.dir/all] Error 2 gmake: *** [all] Error 2 *** Error code 1 Stop in /usr/ports/x11/kde4-workspace. *** Error code 1 Stop in /usr/ports/x11/kde4-workspace. =3D=3D=3D>>> make failed for x11/kde4-workspace =3D=3D=3D>>> Aborting update =3D=3D=3D>>> Update for x11/kde4-workspace failed =3D=3D=3D>>> Aborting update Terminated --------------enig76971744B705E9567BFB5044 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBAgAGBQJPKvRqAAoJEOgBcD7A/5N8niwH/0kXmek0SoGJraxdIFhwDlB3 i1cidfufXlyeBLpRHFoooldYjBAm9e/zntpB2WEW+vLryku9LbGwX5cZvurCHKmT hITM5yK5XRLdBNY9hku89E84FQ8Lp1o4gUb/avBnA+3Q4sR6dFtQeRHTExTmq44q aujbgQaiZgPMKsLgQ7umf8Jp8um/T5/d6RJlfHfkh6akLvGUEnv0WYSBJDLMReng wgcrXqsa95LiEy6utqz8jhCBAn9AGyQ/pMggsME8zO5A2br9674KhrBDhHdHlDBn 5EFiMmK1Mu3nCxWUtuqZ2xCx9lT2QS8AwvX1RszLqbRCin+usKPlcmzg1u9IxJw= =eu/Y -----END PGP SIGNATURE----- --------------enig76971744B705E9567BFB5044-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 21:49:26 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CC43106564A for ; Thu, 2 Feb 2012 21:49:26 +0000 (UTC) (envelope-from conrads@cox.net) Received: from eastrmfepi102.cox.net (eastrmfepi102.cox.net [68.230.241.198]) by mx1.freebsd.org (Postfix) with ESMTP id AD4B88FC1A for ; Thu, 2 Feb 2012 21:49:25 +0000 (UTC) Received: from eastrmimpo209.cox.net ([68.230.241.224]) by eastrmfepo101.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20120202213835.BAAZ24648.eastrmfepo101.cox.net@eastrmimpo209.cox.net>; Thu, 2 Feb 2012 16:38:35 -0500 Received: from serene.no-ip.org ([98.164.86.55]) by eastrmimpo209.cox.net with bizsmtp id V9ea1i00R1BeFqy029eaus; Thu, 02 Feb 2012 16:38:35 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A02020B.4F2B025B.0021,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=1.1 cv=hkJgomM1yb1FNvb7z/X2sgOJ/oH6TIgQO6eG001lwPA= c=1 sm=1 a=xkzmqD_HdDQA:10 a=G8Uczd0VNMoA:10 a=kj9zAlcOel0A:10 a=fdHYxQQoAueMHNSmXppgDg==:17 a=6I5d2MoRAAAA:8 a=kviXuzpPAAAA:8 a=QddWjGbLkORaGvvPuzwA:9 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=4vB-4DCPJfMA:10 a=fdHYxQQoAueMHNSmXppgDg==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Received: from cox.net (localhost [127.0.0.1]) by serene.no-ip.org (8.14.5/8.14.5) with ESMTP id q12LcYNd049416; Thu, 2 Feb 2012 15:38:34 -0600 (CST) (envelope-from conrads@cox.net) Date: Thu, 2 Feb 2012 15:38:29 -0600 From: "Conrad J. Sabatier" To: Baptiste Daroussin Message-ID: <20120202153829.7213f698@cox.net> In-Reply-To: <20120130123930.GB40244@azathoth.lan> References: <20120130123930.GB40244@azathoth.lan> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, current@freebsd.org Subject: Re: [HEADSUP][CFT] pkgng beta1 is out X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 21:49:26 -0000 On Mon, 30 Jan 2012 13:39:30 +0100 Baptiste Daroussin wrote: > Hi, > > pkgng has just reached the beta phase, and has now found its way to > the ports tree (disabled by default). [remainder of announcement snipped for brevity] A feature request: I've long wished that "pkg_info -g" would set the return value to indicate whether or not a package's plist contained any errors, rather than always returning 0. This would be extremely helpful when using pkg_info in a script. Thanks! -- Conrad J. Sabatier conrads@cox.net From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 01:03:13 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id D3E071065689; Fri, 3 Feb 2012 01:03:13 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-150-251.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 19A0F155312; Fri, 3 Feb 2012 01:03:12 +0000 (UTC) Message-ID: <4F2B3250.7000000@FreeBSD.org> Date: Thu, 02 Feb 2012 17:03:12 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0) Gecko/20120201 Thunderbird/10.0 MIME-Version: 1.0 To: John Baldwin References: <201201311149.32760.jhb@freebsd.org> <4F28A210.90303@FreeBSD.org> <201202010742.11936.jhb@freebsd.org> In-Reply-To: <201202010742.11936.jhb@freebsd.org> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Race between cron and crontab X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 01:03:14 -0000 On 02/01/2012 04:42, John Baldwin wrote: > On Tuesday, January 31, 2012 9:23:12 pm Doug Barton wrote: >> On 01/31/2012 08:49, John Baldwin wrote: >>> A co-worker ran into a race between updating a cron tab via crontab(8) and >>> cron(8) yesterday. Specifically, cron(8) failed to notice that a crontab was >>> updated. The problem is that 1) by default our filesystems only use second >>> granularity for timestamps and 2) cron only caches the seconds portion of a >>> file's timestamp when checking for changes anyway. This means that cron can >>> miss updates to a spool directory if multiple updates to the directory are >>> performed within a single second and cron wakes up to scan the spool directory >>> within the same second and scans it before all of the updates are complete. >>> >>> Specifically, when replacing a crontab, crontab(8) first creates a temporary >>> file in /var/cron/tabs and then uses a rename to install it followed by >>> touching the spool directory to update its modification time. However, the >>> creation of the temporary file already changes the modification time of the >>> directory, and cron may "miss" the rename if it scans the directory in between >>> the creation of the temporary file and the rename. >>> >>> The "fix" I am planning to use locally is to simply force crontab(8) to sleep >>> for a second before it touches the spool directory, thus ensuring that it the >>> touch of the spool directory will use a later modification time than the >>> creation of the temporary file. >> >> If you really want cron to have sub-second granularity I don't see how >> you could do it without using flags. >> >> crontab open sets flag that it is editing a file >> crontab close clears "editing" flag, sets "something changed" flag >> (if something actually changed of course) >> >> cron checks existence of "something changed" flag, pulls the >> update if there is no "editing" flag, clears "changed" flag > > I don't want it to have sub-second granularity, Ok, I was interpolating, sorry if I misinterpreted your intentions. > I just want to make > 'crontab -e' more reliable so that cron doesn't miss edits. cron is > currently using the mod-time of the spool directory as the 'something > changed' flag (have you read the cron code?). I understand the spool behavior from history/experience, and I am relying on your excellent summary for the details. :) > The problem is that it > currently can set the 'something changed' flag non-atomically while it is > updating a crontab. That much I understood from your post. My response to what it is I think you're trying to achieve is that it's not likely that you can achieve it by only using 1 flag, no matter what that 1 flag is. I may be wrong about that, but hopefully my suggestion gives you some other ideas to consider. Meanwhile, I was thinking more about this and TMK cron doesn't actually *run* jobs with seconds granularity, only minutes, right? If so then it seems that the only really important seconds to care about are :59 and :00. That would seem to present a solution that rather than having cron wake up every second to see if something has changed that it only do that at :59 (or however many seconds in advance of :00 that it needs, although if it's more than 1 I'll be surprised). That limits the race to someone who writes out a new crontab entry at the point during second :59 that is after cron wakes up to look but before :00. So that's not a perfect solution to your problem, but it should limit the race to a very narrow window without having to modify the code very much. hth, Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 01:45:02 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB7341065672 for ; Fri, 3 Feb 2012 01:45:02 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id C98478FC18 for ; Fri, 3 Feb 2012 01:45:02 +0000 (UTC) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta07.emeryville.ca.mail.comcast.net with comcast id VAea1i0011afHeLA7Dl2nb; Fri, 03 Feb 2012 01:45:02 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta17.emeryville.ca.mail.comcast.net with comcast id VDl11i0094NgCEG8dDl2z0; Fri, 03 Feb 2012 01:45:02 +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 q131ix1B023015; Thu, 2 Feb 2012 18:44:59 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Doug Barton In-Reply-To: <4F2B3250.7000000@FreeBSD.org> References: <201201311149.32760.jhb@freebsd.org> <4F28A210.90303@FreeBSD.org> <201202010742.11936.jhb@freebsd.org> <4F2B3250.7000000@FreeBSD.org> Content-Type: text/plain Date: Thu, 02 Feb 2012 18:44:59 -0700 Message-Id: <1328233499.5484.617.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Race between cron and crontab X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 01:45:03 -0000 On Thu, 2012-02-02 at 17:03 -0800, Doug Barton wrote: > On 02/01/2012 04:42, John Baldwin wrote: > > On Tuesday, January 31, 2012 9:23:12 pm Doug Barton wrote: > >> On 01/31/2012 08:49, John Baldwin wrote: > >>> A co-worker ran into a race between updating a cron tab via crontab(8) and > >>> cron(8) yesterday. Specifically, cron(8) failed to notice that a crontab was > >>> updated. The problem is that 1) by default our filesystems only use second > >>> granularity for timestamps and 2) cron only caches the seconds portion of a > >>> file's timestamp when checking for changes anyway. This means that cron can > >>> miss updates to a spool directory if multiple updates to the directory are > >>> performed within a single second and cron wakes up to scan the spool directory > >>> within the same second and scans it before all of the updates are complete. > >>> > >>> Specifically, when replacing a crontab, crontab(8) first creates a temporary > >>> file in /var/cron/tabs and then uses a rename to install it followed by > >>> touching the spool directory to update its modification time. However, the > >>> creation of the temporary file already changes the modification time of the > >>> directory, and cron may "miss" the rename if it scans the directory in between > >>> the creation of the temporary file and the rename. > >>> > >>> The "fix" I am planning to use locally is to simply force crontab(8) to sleep > >>> for a second before it touches the spool directory, thus ensuring that it the > >>> touch of the spool directory will use a later modification time than the > >>> creation of the temporary file. > >> > >> If you really want cron to have sub-second granularity I don't see how > >> you could do it without using flags. > >> > >> crontab open sets flag that it is editing a file > >> crontab close clears "editing" flag, sets "something changed" flag > >> (if something actually changed of course) > >> > >> cron checks existence of "something changed" flag, pulls the > >> update if there is no "editing" flag, clears "changed" flag > > > > I don't want it to have sub-second granularity, > > Ok, I was interpolating, sorry if I misinterpreted your intentions. > > > I just want to make > > 'crontab -e' more reliable so that cron doesn't miss edits. cron is > > currently using the mod-time of the spool directory as the 'something > > changed' flag (have you read the cron code?). > > I understand the spool behavior from history/experience, and I am > relying on your excellent summary for the details. :) > > > The problem is that it > > currently can set the 'something changed' flag non-atomically while it is > > updating a crontab. > > That much I understood from your post. My response to what it is I think > you're trying to achieve is that it's not likely that you can achieve it > by only using 1 flag, no matter what that 1 flag is. I may be wrong > about that, but hopefully my suggestion gives you some other ideas to > consider. > > Meanwhile, I was thinking more about this and TMK cron doesn't actually > *run* jobs with seconds granularity, only minutes, right? If so then it > seems that the only really important seconds to care about are :59 and > :00. That would seem to present a solution that rather than having cron > wake up every second to see if something has changed that it only do > that at :59 (or however many seconds in advance of :00 that it needs, > although if it's more than 1 I'll be surprised). That limits the race to > someone who writes out a new crontab entry at the point during second > :59 that is after cron wakes up to look but before :00. So that's not a > perfect solution to your problem, but it should limit the race to a very > narrow window without having to modify the code very much. > > > hth, > > Doug I think part of the problem here is that I started typing without thinking enough... I thought I was offering a different small change that fixed more than one problem, but it was wrong. My mistake seems to be having the unintended effect of sidetracking a perfectly reasonable small fix for a problem that's known to happen in the real world, just because it doesn't also fix a theoretical problem that might happen somewhere some day; that sure wasn't my intention. -- Ian From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 07:12:41 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A4DB106566C; Fri, 3 Feb 2012 07:12:41 +0000 (UTC) (envelope-from freebsd@penx.com) Received: from btw.pki2.com (btw.pki2.com [IPv6:2001:470:a:6fd::2]) by mx1.freebsd.org (Postfix) with ESMTP id 311378FC12; Fri, 3 Feb 2012 07:12:41 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by btw.pki2.com (8.14.5/8.14.5) with ESMTP id q137Caxx022162; Thu, 2 Feb 2012 23:12:36 -0800 (PST) (envelope-from freebsd@penx.com) From: Dennis Glatting To: "Kenneth D. Merry" In-Reply-To: <20120120204459.GA51162@nargothrond.kdm.org> References: <20120120204459.GA51162@nargothrond.kdm.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 02 Feb 2012 23:12:36 -0800 Message-ID: <1328253156.15339.54.camel@btw.pki2.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-yoursite-MailScanner-Information: Dennis Glatting X-yoursite-MailScanner-ID: q137Caxx022162 X-yoursite-MailScanner: Found to be clean X-MailScanner-From: freebsd@penx.com Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org Subject: Re: LSI supported mps(4) driver available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 07:12:41 -0000 FYI. I just booted off a RAID1 array using this driver under RELENG_9 (below) on a Tyan 8812's on-board LSI 2008 chip. I have a second FreeBSD system with a LSI 9211-8i (IR) but it has a few more days of work before it can do the same. mc> dmesg Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-STABLE #1: Thu Feb 2 21:36:16 PST 2012 root@mc:/sys/amd64/compile/SMUNI amd64 CPU: AMD Opteron(TM) Processor 6274 (2200.07-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x600f12 Family = 15 Model = 1 Stepping = 2 Features=0x178bfbff Features2=0x1698220b AMD Features=0x2e500800 AMD Features2=0x1c9bfff,> TSC: P-state invariant, performance statistics real memory = 34359738368 (32768 MB) avail memory = 33091493888 (31558 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: <120911 APIC1027> FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs FreeBSD/SMP: 2 package(s) x 16 core(s) cpu0 (BSP): APIC ID: 32 cpu1 (AP): APIC ID: 33 cpu2 (AP): APIC ID: 34 cpu3 (AP): APIC ID: 35 cpu4 (AP): APIC ID: 36 cpu5 (AP): APIC ID: 37 cpu6 (AP): APIC ID: 38 cpu7 (AP): APIC ID: 39 cpu8 (AP): APIC ID: 40 cpu9 (AP): APIC ID: 41 cpu10 (AP): APIC ID: 42 cpu11 (AP): APIC ID: 43 cpu12 (AP): APIC ID: 44 cpu13 (AP): APIC ID: 45 cpu14 (AP): APIC ID: 46 cpu15 (AP): APIC ID: 47 cpu16 (AP): APIC ID: 64 cpu17 (AP): APIC ID: 65 cpu18 (AP): APIC ID: 66 cpu19 (AP): APIC ID: 67 cpu20 (AP): APIC ID: 68 cpu21 (AP): APIC ID: 69 cpu22 (AP): APIC ID: 70 cpu23 (AP): APIC ID: 71 cpu24 (AP): APIC ID: 72 cpu25 (AP): APIC ID: 73 cpu26 (AP): APIC ID: 74 cpu27 (AP): APIC ID: 75 cpu28 (AP): APIC ID: 76 cpu29 (AP): APIC ID: 77 cpu30 (AP): APIC ID: 78 cpu31 (AP): APIC ID: 79 ACPI Warning: Optional field Pm2ControlBlock has zero address or length: 0x0000000000000000/0x1 (20110527/tbfadt-586) ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-55 on motherboard kbd1 at kbdmux0 acpi0: <120911 XSDT1027> on motherboard acpi0: Power Button (fixed) acpi0: reservation of ffffff00, 4000 (3) failed acpi0: reservation of fec00000, 1000 (3) failed acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of ffb80000, 80000 (3) failed acpi0: reservation of fec10000, 20 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, dff00000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 cpu8: on acpi0 cpu9: on acpi0 cpu10: on acpi0 cpu11: on acpi0 cpu12: on acpi0 cpu13: on acpi0 cpu14: on acpi0 cpu15: on acpi0 cpu16: on acpi0 cpu17: on acpi0 cpu18: on acpi0 cpu19: on acpi0 cpu20: on acpi0 cpu21: on acpi0 cpu22: on acpi0 cpu23: on acpi0 cpu24: on acpi0 cpu25: on acpi0 cpu26: on acpi0 cpu27: on acpi0 cpu28: on acpi0 cpu29: on acpi0 cpu30: on acpi0 cpu31: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 52 at device 4.0 on pci0 pci7: on pcib1 igb0: port 0xe400-0xe41f mem 0xfeb60000-0xfeb7ffff,0xfeb40000-0xfeb5ffff,0xfeb1c000-0xfeb1ffff irq 44 at device 0.0 on pci7 igb0: Using MSIX interrupts with 9 vectors igb0: Ethernet address: 00:e0:81:c8:ee:8a igb1: port 0xe800-0xe81f mem 0xfebe0000-0xfebfffff,0xfebc0000-0xfebdffff,0xfeb9c000-0xfeb9ffff irq 45 at device 0.1 on pci7 igb1: Using MSIX interrupts with 9 vectors igb1: Ethernet address: 00:e0:81:c8:ee:8b pcib2: irq 53 at device 9.0 on pci0 pci6: on pcib2 em0: port 0xd800-0xd81f mem 0xfeae0000-0xfeafffff,0xfeadc000-0xfeadffff irq 48 at device 0.0 on pci6 em0: Using MSIX interrupts with 3 vectors em0: Ethernet address: 00:e0:81:c8:ee:ff pcib3: irq 54 at device 11.0 on pci0 pci5: on pcib3 mps0: port 0xc000-0xc0ff mem 0xfe93c000-0xfe93ffff,0xfe940000-0xfe97ffff irq 32 at device 0.0 on pci5 mps0: Firmware: 10.00.02.00, Driver: 11.255.03.00-fbsd mps0: IOCCapabilities: 1285c pcib4: irq 54 at device 12.0 on pci0 pci3: on pcib4 pcib5: irq 36 at device 0.0 on pci3 pci4: on pcib5 siis0: port 0xb800-0xb80f mem 0xfe877c00-0xfe877c7f,0xfe878000-0xfe87ffff irq 36 at device 0.0 on pci4 siisch0: at channel 0 on siis0 siisch1: at channel 1 on siis0 siisch2: at channel 2 on siis0 siisch3: at channel 3 on siis0 pcib6: irq 54 at device 13.0 on pci0 pci2: on pcib6 mps1: port 0xa000-0xa0ff mem 0xfe73c000-0xfe73ffff,0xfe740000-0xfe77ffff irq 40 at device 0.0 on pci2 mps1: Firmware: 10.00.00.00, Driver: 11.255.03.00-fbsd mps1: IOCCapabilities: 185c ahci0: port 0x8000-0x8007,0x7000-0x7003,0x6000-0x6007,0x5000-0x5003,0x4000-0x400f mem 0xfe6fa400-0xfe6fa7ff irq 22 at device 17.0 on pci0 ahci0: AHCI v1.10 with 4 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ohci0: mem 0xfe6f6000-0xfe6f6fff irq 16 at device 18.0 on pci0 usbus0: on ohci0 ohci1: mem 0xfe6f7000-0xfe6f7fff irq 16 at device 18.1 on pci0 usbus1: on ohci1 ehci0: mem 0xfe6fa800-0xfe6fa8ff irq 17 at device 18.2 on pci0 usbus2: EHCI version 1.0 usbus2: on ehci0 ohci2: mem 0xfe6f8000-0xfe6f8fff irq 18 at device 19.0 on pci0 usbus3: on ohci2 ohci3: mem 0xfe6f9000-0xfe6f9fff irq 18 at device 19.1 on pci0 usbus4: on ohci3 ehci1: mem 0xfe6fac00-0xfe6facff irq 19 at device 19.2 on pci0 usbus5: EHCI version 1.0 usbus5: on ehci1 pci0: at device 20.0 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 isab0: at device 20.3 on pci0 isa0: on isab0 pcib7: at device 20.4 on pci0 pci1: on pcib7 vgapci0: port 0x9800-0x987f mem 0xfd800000-0xfdffffff,0xfd7e0000-0xfd7fffff irq 23 at device 9.0 on pci1 ohci4: mem 0xfe6fb000-0xfe6fbfff irq 18 at device 20.5 on pci0 usbus6: on ohci4 acpi_button0: on acpi0 ipmi0: port 0xca8,0xcac on acpi0 ipmi0: KCS mode found at io 0xca8 on acpi attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart1: port 0x2f8-0x2ff irq 3 on acpi0 ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 ipmi1: on isa0 device_attach: ipmi1 attach returned 16 ipmi1: on isa0 device_attach: ipmi1 attach returned 16 orm0: at iomem 0xc0000-0xc7fff,0xce000-0xcefff,0xcf000-0xcffff,0xd0000-0xd0fff on isa0 sc0: at flags 0x100 on isa0 sc0: CGA <16 virtual consoles, flags=0x300> vga0: at port 0x3d0-0x3db iomem 0xb8000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] AcpiOsExecute: failed to enqueue task, consider increasing the debug.acpi.max_tasks tunable acpi_throttle0: on cpu0 hwpstate0: on cpu0 Timecounters tick every 1.000 msec (noperiph:siisch0:0:-1:-1): rescan already queued (noperiph:siisch1:0:-1:-1): rescan already queued usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 480Mbps High Speed USB v2.0 usbus6: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 uhub6: 2 ports with 2 removable, self powered uhub0: 3 ports with 3 removable, self powered uhub1: 3 ports with 3 removable, self powered uhub3: 3 ports with 3 removable, self powered uhub4: 3 ports with 3 removable, self powered uhub2: 6 ports with 6 removable, self powered uhub5: 6 ports with 6 removable, self powered ugen5.2: at usbus5 uhub7: on usbus5 ipmi0: Timed out waiting for GET_DEVICE_ID ugen0.2: at usbus0 ukbd0: on usbus0 kbd2 at ukbd0 uhid0: on usbus0 uhub7: 3 ports with 3 removable, self powered ugen5.3: at usbus5 ukbd1: on usbus5 kbd3 at ukbd1 ums0: on usbus5 ums0: 3 buttons and [Z] coordinates ID=0 ugen3.2: at usbus3 (probe126:mps1:0:0:0): REPORT LUNS. CDB: a0 0 0 0 0 0 0 0 0 10 0 0 (probe126:mps1:0:0:0): CAM status: SCSI Status Error (probe126:mps1:0:0:0): SCSI status: Check Condition (probe126:mps1:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) (probe126:mps1:0:0:0): Command Specific Info: 0x5303c0 (probe126:mps1:0:0:0): REPORT LUNS. CDB: a0 0 0 0 0 0 0 0 0 10 0 0 (probe126:mps1:0:0:0): CAM status: SCSI Status Error (probe126:mps1:0:0:0): SCSI status: Check Condition (probe126:mps1:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) (probe126:mps1:0:0:0): Field Replaceable Unit: 56 (probe126:mps1:0:0:0): Command Specific Info: 0x33353839 da0 at mps1 bus 0 scbus5 target 0 lun 0 da0: Fixed Direct Access SCSI-6 device da0: 150.000MB/s transfers da0: Command Queueing enabled da0: 68664MB (140623872 512 byte sectors: 255H 63S/T 8753C) ada0 at siisch0 bus 0 scbus1 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 57241MB (117231408 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ada1 at siisch1 bus 0 scbus2 target 0 lun 0 ada1: ATA-8 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 57241MB (117231408 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad6 SMP: AP CPU #1 Launched! cd0 at ahcich0 bus 0 scbus6 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA6, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed SMP: AP CPU #2 Launched! SMP: AP CPU #12 Launched! SMP: AP CPU #13 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #20 Launched! SMP: AP CPU #21 Launched! SMP: AP CPU #22 Launched! SMP: AP CPU #23 Launched! SMP: AP CPU #15 Launched! SMP: AP CPU #14 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #11 Launched! SMP: AP CPU #10 Launched! SMP: AP CPU #9 Launched! SMP: AP CPU #8 Launched! SMP: AP CPU #16 Launched! SMP: AP CPU #17 Launched! SMP: AP CPU #19 Launched! SMP: AP CPU #18 Launched! SMP: AP CPU #31 Launched! SMP: AP CPU #30 Launched! SMP: AP CPU #24 Launched! SMP: AP CPU #25 Launched! SMP: AP CPU #27 Launched! SMP: AP CPU #26 Launched! SMP: AP CPU #29 Launched! SMP: AP CPU #28 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #7 Launched! GEOM: ada0: the secondary GPT table is corrupt or invalid. GEOM: ada0: using the primary only -- recovery suggested. Trying to mount root from ufs:/dev/da0p2 [rw]... ZFS filesystem version 5 ZFS storage pool version 28 dragon_saver: the console does not support M_VGA_CG320 module_register_init: MOD_LOAD (dragon_saver, 0xffffffff81768140, 0) error 19 From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 08:10:40 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B81B106566B; Fri, 3 Feb 2012 08:10:40 +0000 (UTC) (envelope-from Kashyap.Desai@lsi.com) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by mx1.freebsd.org (Postfix) with ESMTP id 3CF888FC0A; Fri, 3 Feb 2012 08:10:38 +0000 (UTC) Received: from paledge01.lsi.com ([192.19.193.42]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKTyuWfgPF4eOZjD3sA8bSH9kXczfmJ4lH@postini.com; Fri, 03 Feb 2012 00:10:39 PST Received: from PALHUB01.lsi.com (128.94.213.114) by PALEDGE01.lsi.com (192.19.193.42) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 3 Feb 2012 03:15:07 -0500 Received: from inbexch02.lsi.com (135.36.98.40) by PALHUB01.lsi.com (128.94.213.114) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 3 Feb 2012 03:10:37 -0500 Received: from inbmail01.lsi.com ([135.36.98.64]) by inbexch02.lsi.com ([135.36.98.40]) with mapi; Fri, 3 Feb 2012 13:40:33 +0530 From: "Desai, Kashyap" To: Stas Orlov Date: Fri, 3 Feb 2012 13:40:32 +0530 Thread-Topic: LSI supported mps(4) driver available Thread-Index: AczhuzM+I9JcO6lbT1OzJ7SpelWmlQAj0nYQ Message-ID: References: <20120120204459.GA51162@nargothrond.kdm.org> <1327553257.19745.6.camel@btw.pki2.com> <20120126045409.GA90912@nargothrond.kdm.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "freebsd-scsi@freebsd.org" , "freebsd-current@freebsd.org" , "Kenneth D. Merry" , Dennis Glatting Subject: RE: LSI supported mps(4) driver available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 08:10:40 -0000 DQoNCkZyb206IFN0YXMgT3Jsb3YgW21haWx0bzpzZW5uYWFyQGdtYWlsLmNvbV0gDQpTZW50OiBU aHVyc2RheSwgRmVicnVhcnkgMDIsIDIwMTIgODoyOSBQTQ0KVG86IERlc2FpLCBLYXNoeWFwDQpD YzogS2VubmV0aCBELiBNZXJyeTsgZnJlZWJzZC1zY3NpQGZyZWVic2Qub3JnOyBmcmVlYnNkLWN1 cnJlbnRAZnJlZWJzZC5vcmc7IERlbm5pcyBHbGF0dGluZw0KU3ViamVjdDogUmU6IExTSSBzdXBw b3J0ZWQgbXBzKDQpIGRyaXZlciBhdmFpbGFibGUNCg0KPj4gKEFnYWluIGNsYXJpZnkgd2hpY2gg dmVyc2lvbiBvZiBGcmVlQlNEIHlvdSBhcmUgdXNpbmcpDQoNCkFzIEkndmUgc3RhdGVkIGVhcmxp ZXIgaXQncyBjdXJyZW50IHNuYXBzaG90IGZyb20gdGhlIG90aGVyIGRheSwgdG8gYmUgbW9yZSBz cGVjaWZpYyBGcmVlQlNEMTAtQ1VSUkVOVCByMjMwODU3DQoNCk9rLCBJJ2xsIHRyeSB0byB1cGdy YWRlIGZpcm13YXJlLg0KT24gVGh1LCBGZWIgMiwgMjAxMiBhdCA2OjQzIFBNLCBEZXNhaSwgS2Fz aHlhcCA8S2FzaHlhcC5EZXNhaUBsc2kuY29tPiB3cm90ZToNCg0KDQo+PiANCkNhbiB5b3Ugc3dp dGNoIHlvdXIgbWFpbCBjbGllbnQgdG8gZGVmYXVsdCA8dGV4dCBtb2RlPiByZXBseS4gSXQgaXMg YWx3YXlzIHR1cm5pbmcgaW50byBodG1sIGZvcm1hdCBhbmQgZGlmZmljdWx0IGZvciBpbmxpbmUg cmVwbHkuDQpJIGhhdmUgZG9uZSBzb21lIGFuYWx5c2lzIG9uIG9mIHlvdXIgbG9ncyBwcm92aWRl ZCBhdCAiaHR0cDovL29pNDAudGlueXBpYy5jb20vMjVnZHc4by5qcGciDQoNCjEuIGl0IHNlZW1z IERyaXZlciBpcyBzb21laG93IG5vdCBoYW5kbGluZyBlcnJvciBjb25kaXRpb24gd2hpY2ggc2hv dWxkIGJlIGJldHRlciBoYW5kbGVkIGF0IGRyaXZlci4NCiAgICBlLmEgZHJpdmVyIGRvZXMgbm90 IHJlaW5pdCBIQkEgaWYgYW55IGNvbmZpZyByZXF1ZXN0IHRpbWUgb3V0Lg0KICAgIEkgd2lsbCBh ZGQgdGhpcyBmZWF0dXJlIHNvbWV0aW1lIGxhdGVyLCBzaW5jZSBJIGhhdmUgc29tZSBtb3JlIGl0 ZW0gcXVldWVkIHVwIGFzIHdlbGwuDQoyLiBZb3VyIGxvZ3MgbWVudGlvbmVkIHRoZXJlIGFyZSB0 aHJlZSBkaWZmZXJlbnQgaGFuZGxlZCBnb3QgZnJvbSBGVyB0byBhZGQgYXMgQmFyZSBEcml2ZS4g KGl0IGlzIG5vdCBhIHZvbHVtZSBlbnRyeSkNClNvIGp1c3QgY3VyaW91cyB0byBrbm93IHdoeSB0 aG9zZSBlbnRyaWVzIGFyZSBjb21pbmcgYXMgYmFyZSBkcml2ZS4gPyAoZG8geW91IGhhdmUgYW55 IG90aGVyIGJhcmUgZHJpdmVzIGluIHlvdXIgdG9wb2xvZ3kgPyApDQoNCg0KYCBLYXNoeWFwDQoN CkZyb206IFN0YXMgT3Jsb3YgW21haWx0bzpzZW5uYWFyQGdtYWlsLmNvbV0NClNlbnQ6IFRodXJz ZGF5LCBGZWJydWFyeSAwMiwgMjAxMiA3OjQ1IFBNDQpUbzogRGVzYWksIEthc2h5YXANCkNjOiBL ZW5uZXRoIEQuIE1lcnJ5OyBmcmVlYnNkLXNjc2lAZnJlZWJzZC5vcmc7IGZyZWVic2QtY3VycmVu dEBmcmVlYnNkLm9yZzsgRGVubmlzIEdsYXR0aW5nDQpTdWJqZWN0OiBSZTogTFNJIHN1cHBvcnRl ZCBtcHMoNCkgZHJpdmVyIGF2YWlsYWJsZQ0KU3VyZSwgSSd2ZSBtYWRlIHR3byBSQUlEICgxIGFu ZCAxMCApIGFycmF5cyB3aXRoaW4gTFNJIENvbmZpZyBVdGlsaXR5IGFuZCB0cmllZCB0byBpbnN0 YWxsIGZyZXNoIGN1cnJlbnQsIGV2ZXJ5IHRpbWUgSSBnZXQgZXJyb3IgbGlua2VkIGFib3ZlLCBz byB5ZXMsIGl0J3PCoHJlcHJvZHVjaWJsZS4NCi0+IFdoYXQgSSB1bmRlcnN0b29kIGhlcmUgaXMs IHlvdSBoYXZlIHR3byByYWlkIHZvbHVtZXMgUkFJRDEgYW5kIFJBSUQxMCwgYW5kIHRyeWluZyB0 byBpbnN0YWxsIEZyZWVCU0QgKEFnYWluIGNsYXJpZnkgd2hpY2ggdmVyc2lvbiBvZiBGcmVlQlNE IHlvdSBhcmUgdXNpbmcpDQoNCg0KVHJ5IGVyYXNpbmcgYSBjb250cm9sbGVyIEZXIGNvbXBsZXRl bHkgYW5kIHJlLWluc3RhbGwgZXZlcnl0aGluZyBmcm9tIGZyZXNoLg0KKEhlcmUgbWFrZSBzdXJl IHlvdSBmbGFzaCBjb21wbGV0ZWx5LiBIb3BlIHlvdSBhcmUgYXdhcmUgb2YgY29udHJvbGxlciBm aXJtd2FyZSB1cGdyYWRlIHByb2Nlc3MpDQoNCk91ciBib2FyZCBoYXMgRFBNIHRhYmxlcyBhbmQg Zm9yIFJhaWQgdm9sdW1lIGl0IGlzIG1heGltdW0gMiBlbnRyeS4NCldoZW4geW91IGhhdmUgbW9y ZSB0aGFuIHR3byBpbmFjdGl2ZSB2b2x1bWVzLCB3ZSBjYW5ub3QgYWRkIGFub3RoZXIgcmFpZCB2 b2x1bWUuDQpUaGVyZSBpcyBzb21lIGltcGxlbWVudGF0aW9uIHJlY2VudGx5IGRvbmUgYnkgQklP UyB0ZWFtIHJlbGF0ZWQgdG8gdGhpcyBhcmVhLiBXaGVyZSBCSU9TIGl0c2VsZiB3aWxsIGVyYXNl IGluYWN0aXZlIFJhaWQgdm9sdW1lIGVudHJ5IGZyb20gRFBNIHBhZ2VzLg0KDQp+IEthc2h5YXAN Cg0KDQpNUFQgRmlybXdhcmUgMi4xNS42My4wMC1JUg0KUGFja2FnZSBWZXJzaW9uIDcuMDEuMzMu MDANCg0KSSBkbyBoYXZlIGFub3RoZXIgc3BhcmUgUjYxMCB3aXRoIHRoYXQgY2FyZCwgSSdsbCB0 ZXN0IGl0IHdpdGggY3VycmVudCBsYXRlciB0aGlzIGV2ZW5pbmcuDQoNCk9uIFRodSwgRmViIDIs IDIwMTIgYXQgNTo1MyBQTSwgRGVzYWksIEthc2h5YXAgPEthc2h5YXAuRGVzYWlAbHNpLmNvbT4g d3JvdGU6DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBvd25lci1m cmVlYnNkLXNjc2lAZnJlZWJzZC5vcmcgW21haWx0bzpvd25lci1mcmVlYnNkLQ0KPiBzY3NpQGZy ZWVic2Qub3JnXSBPbiBCZWhhbGYgT2YgU3RhcyBPcmxvdg0KPiBTZW50OiBUaHVyc2RheSwgRmVi cnVhcnkgMDIsIDIwMTIgNjo0OCBQTQ0KPiBUbzogS2VubmV0aCBELiBNZXJyeQ0KPiBDYzogZnJl ZWJzZC1zY3NpQGZyZWVic2Qub3JnOyBmcmVlYnNkLWN1cnJlbnRAZnJlZWJzZC5vcmc7IERlbm5p cw0KPiBHbGF0dGluZw0KPiBTdWJqZWN0OiBSZTogTFNJIHN1cHBvcnRlZCBtcHMoNCkgZHJpdmVy IGF2YWlsYWJsZQ0KPg0KPiBIaSwNCj4NCj4gV2UgaGF2ZSBhIHBhY2sgb2YgaWRlbnRpY2FsIERl bGwgUjYxMCBtYWhjaW5lcyB3aXRoIEgyMDAgY2FyZHMuDQo+DQo+IHBjaWNvbmYgZnJvbSBSNjEw IHdpdGggRnJlZUJTRDkgb24gWkZTLCBkaXNrcyBpbiBKQk9EIG1vZGUuDQo+DQo+IG1wczBAcGNp MDozOjA6MDogwqAgwqAgwqAgwqBjbGFzcz0weDAxMDcwMCBjYXJkPTB4MWYxZTEwMjggY2hpcD0w eDAwNzIxMDAwDQo+IHJldj0weDAyIGhkcj0weDAwDQo+IMKgIMKgIMKgdmVuZG9yIMKgIMKgID0g J0xTSSBMb2dpYyAvIFN5bWJpb3MgTG9naWMnDQo+IMKgIMKgIMKgZGV2aWNlIMKgIMKgID0gJ1NB UzIwMDggUENJLUV4cHJlc3MgRnVzaW9uLU1QVCBTQVMtMiBbRmFsY29uXScNCj4gwqAgwqAgwqBj bGFzcyDCoCDCoCDCoD0gbWFzcyBzdG9yYWdlDQo+IMKgIMKgIMKgc3ViY2xhc3MgwqAgPSBTQVMN Cj4gwqAgwqAgwqBiYXIgwqAgWzEwXSA9IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4 ZmMwMCwgc2l6ZSAyNTYsDQo+IGVuYWJsZWQNCj4gwqAgwqAgwqBiYXIgwqAgWzE0XSA9IHR5cGUg TWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGRmMmIwMDAwLCBzaXplIDY1NTM2LA0KPiBlbmFibGVk DQo+IMKgIMKgIMKgYmFyIMKgIFsxY10gPSB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhk ZjJjMDAwMCwgc2l6ZSAyNjIxNDQsDQo+IGVuYWJsZWQNCj4gwqAgwqAgwqBjYXAgMDFbNTBdID0g cG93ZXJzcGVjIDMgwqBzdXBwb3J0cyBEMCBEMSBEMiBEMyDCoGN1cnJlbnQgRDANCj4gwqAgwqAg wqBjYXAgMTBbNjhdID0gUENJLUV4cHJlc3MgMiBlbmRwb2ludCBtYXggZGF0YSAxMjgoNDA5Nikg bGluayB4NCh4OCkNCj4gwqAgwqAgwqBjYXAgMDNbZDBdID0gVlBEDQo+IMKgIMKgIMKgY2FwIDA1 W2E4XSA9IE1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UsIDY0IGJpdA0KPiDCoCDCoCDCoGNhcCAxMVtj MF0gPSBNU0ktWCBzdXBwb3J0cyAxNSBtZXNzYWdlcyBpbiBtYXAgMHgxNCBlbmFibGVkDQo+DQo+ DQo+IFdlIGFsbCBhd2FyZSBvZiB0aGUgc3RhdGUgb2YgdGhpbmdzIHdpdGggdGhlIG9sZCBtcHMg ZHJpdmVyLCBzbyBJIHRyaWVkDQo+IHRvDQo+IHBhc3MgYSBoYXJkd2FyZSBhcnJheSB3aXRoIHRo ZSBuZXcgb25lLg0KPiBDdXJyZW50IHNuYXBzaG90IGZyb20geWVzdGVyZGF5IGZhaWxzIHdpdGgg Zm9sbG93aW5nIC0NCj4gaHR0cDovL29pNDAudGlueXBpYy5jb20vMjVnZHc4by5qcGcNCkNhbiB5 b3UgZXhwbGFpbiBtb3JlIGFib3V0IHlvdXIgc2V0dXAgYW5kIGhvdyB0byByZXByb2R1Y2UgaXQg Pw0KSSB3aWxsIGhhdmUgbG9vayBvbiB0aGlzIGlzc3VlIGlmIGl0IGlzIHJlcHJvZHVjaWJsZSA/ DQoNCkFsc28gd2hhdCBpcyBGaXJtd2FyZSB2ZXJzaW9uIHlvdSBhcmUgdXNpbmcgb24gSDIwMCBj YXJkID8NCg0KfiBLYXNoeWFwDQoNCj4NCj4gaWlyYywgRGVsbCBoYXMgYSBuYXN0eSBoYWJpdCBv ZiB3cml0aW5nIGl0cyBvd24gZmlybXdhcmUuDQo+DQo+DQo+IE9uIFRodSwgSmFuIDI2LCAyMDEy IGF0IDg6NTQgQU0sIEtlbm5ldGggRC4gTWVycnkgPGtlbkBmcmVlYnNkLm9yZz4NCj4gd3JvdGU6 DQo+DQo+ID4gT24gV2VkLCBKYW4gMjUsIDIwMTIgYXQgMjA6NDc6MzcgLTA4MDAsIERlbm5pcyBH bGF0dGluZyB3cm90ZToNCj4gPiA+IE9uIEZyaSwgMjAxMi0wMS0yMCBhdCAxMzo0NCAtMDcwMCwg S2VubmV0aCBELiBNZXJyeSB3cm90ZToNCj4gPiA+ID4gVGhlIExTSS1zdXBwb3J0ZWQgdmVyc2lv biBvZiB0aGUgbXBzKDQpIGRyaXZlciB0aGF0IHN1cHBvcnRzIHRoZWlyDQo+IDZHYg0KPiA+IFNB Uw0KPiA+ID4gPiBIQkFzIGFzIHdlbGwgYXMgV2FycERyaXZlIGNvbnRyb2xsZXJzLCBpcyBhdmFp bGFibGUgaGVyZToNCj4gPiA+ID4NCj4gPiA+ID4gaHR0cDovL3Blb3BsZS5mcmVlYnNkLm9yZy9+ a2VuL2xzaS9tcHNfbHNpLjIwMTIwMTIwLjEudHh0DQo+ID4gPiA+DQo+ID4gPiA+IEkgcGxhbiB0 byBjaGVjayBpdCBpbiB0byBoZWFkIG5leHQgd2VlaywgYW5kIHRoZW4gTUZDIGl0IGludG8NCj4g c3RhYmxlLzkNCj4gPiBhDQo+ID4gPiA+IHdlZWsgYWZ0ZXIgdGhhdCBtb3N0IGxpa2VseS4NCj4g PiA+ID4NCj4gPiA+ID4gUGxlYXNlIHRlc3QgaXQgb3V0IGFuZCBsZXQgbWUga25vdyBpZiB5b3Ug cnVuIGludG8gYW55IHByb2JsZW1zLg0KPiA+ID4gPg0KPiA+ID4gPiBJbiBhZGRpdGlvbiB0byBz dXBwb3J0aW5nIFdhcnBEcml2ZSwgdGhlIGRyaXZlciBhbHNvIHN1cHBvcnRzDQo+ID4gSW50ZWdy YXRlZA0KPiA+ID4gPiBSQUlELg0KPiA+ID4gPg0KPiA+ID4gPiBUaGFua3MgdG8gTFNJIGZvciBk b2luZyB0aGUgd29yayBvbiB0aGlzIGRyaXZlciENCj4gPiA+ID4NCj4gPiA+DQo+ID4gPiBEb2Vz IHRoaXMgaW5jbHVkZSB0aGUgU0FTMjAwOCBzZXJpZXMgY2hpcHM/IEkgaGF2ZSB0d28gc3lzdGVt cywgb25lDQo+IGENCj4gPiA+IFR5YW4gRlQ0OC1CODgxMiB3aXRoIGEgUzg4MTIgTUIgYW5kIElu dGVybGFnb3MgY2hpcHMsIHdoZXJlIEkgYW0NCj4gPiA+IGludGVyZXN0ZWQgaW4gdXNpbmcgYSBk cml2ZXIgdW5kZXIgOS4wIGFtZDY0Lg0KPiA+DQo+ID4gWWVzLiDCoFRoZSBkcml2ZXIgaW4gOS4w IHN1cHBvcnRzIHRoZSAyMDA4IGFzIHdlbGwuDQo+ID4NCj4gPiBLZW4NCj4gPiAtLQ0KPiA+IEtl bm5ldGggTWVycnkNCj4gPiBrZW5ARnJlZUJTRC5PUkcNCj4gPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IGZyZWVic2QtY3VycmVudEBmcmVlYnNk Lm9yZyBtYWlsaW5nIGxpc3QNCj4gPiBodHRwOi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9s aXN0aW5mby9mcmVlYnNkLWN1cnJlbnQNCj4gPiBUbyB1bnN1YnNjcmliZSwgc2VuZCBhbnkgbWFp bCB0byAiZnJlZWJzZC1jdXJyZW50LQ0KPiB1bnN1YnNjcmliZUBmcmVlYnNkLm9yZyINCj4gPg0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBmcmVl YnNkLXNjc2lAZnJlZWJzZC5vcmcgbWFpbGluZyBsaXN0DQo+IGh0dHA6Ly9saXN0cy5mcmVlYnNk Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZyZWVic2Qtc2NzaQ0KPiBUbyB1bnN1YnNjcmliZSwgc2Vu ZCBhbnkgbWFpbCB0byAiZnJlZWJzZC1zY3NpLXVuc3Vic2NyaWJlQGZyZWVic2Qub3JnIg0KDQo= From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 09:35:21 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D1FE106566C for ; Fri, 3 Feb 2012 09:35:21 +0000 (UTC) (envelope-from andrew.hobbs@ai.net) Received: from ginga.ai.net (ginga.ai.net [205.134.166.19]) by mx1.freebsd.org (Postfix) with ESMTP id 04D6E8FC0C for ; Fri, 3 Feb 2012 09:35:20 +0000 (UTC) Received: from ginga.ai.net ([205.134.166.19]) by ginga.ai.net ([205.134.166.19]) with mapi; Fri, 3 Feb 2012 04:35:19 -0500 From: Andrew Hobbs To: Sergey Kandaurov Date: Fri, 3 Feb 2012 04:35:16 -0500 Thread-Topic: CARP on -CURRENT Thread-Index: AczheGMg3AgG5eGOTtiOMwRX6/gYrgA3Fuzg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-current@freebsd.org" Subject: RE: CARP on -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 09:35:21 -0000 > -----Original Message----- > From: Sergey Kandaurov [mailto:pluknet@gmail.com]=20 > Sent: Thursday, February 02, 2012 2:00 AM > To: Andrew Hobbs > Cc: freebsd-current@freebsd.org > Subject: Re: CARP on -CURRENT > > On 2 February 2012 04:26, Andrew Hobbs wrote: > > I much appreciate the responses and I was able to get CARP functioning= =20 > > using the new ifconfig syntax under -CURRENT. Having done that, CARP=20 > > is now acting as it should, though now I have a new challenge with=20 > > devd and automatic firing of scripts during CARP failover. It appears=20 > > that the documented method of doing this at=20 > > http://www.freebsd.org/doc/handbook/disks-hast.html no longer works=20 > > with the suggested devd.conf setup; notify 30 { > > =A0 =A0 =A0 =A0match "system" "IFNET"; > > =A0 =A0 =A0 =A0match "subsystem" "carp0"; > > =A0 =A0 =A0 =A0match "type" "LINK_UP"; > > =A0 =A0 =A0 =A0action "/usr/local/sbin/carp-hast-switch master"; }; > > > > notify 30 { > > =A0 =A0 =A0 =A0match "system" "IFNET"; > > =A0 =A0 =A0 =A0match "subsystem" "carp0"; > > =A0 =A0 =A0 =A0match "type" "LINK_DOWN"; > > =A0 =A0 =A0 =A0action "/usr/local/sbin/carp-hast-switch slave"; > > > > Is it likely that the triggers associated with CARP for devd have chang= ed due to the recent new CARP overhaul? Does anyone know what the new trigg= ers may be? > > > > You will need to change this to something like (as taken from man carp): > match "system" "CARP"; > match "subsystem" "[0-9]+@"; > match "type" "(MASTER|BACKUP)"; > > The subsystem now is generated as > snprintf(subsys, IFNAMSIZ+5, "%u@%s", sc->sc_vhid, sc->sc_carpdev->if_xna= me); > > -- > wbr, > pluknet Thanks for the info. I was able to get the triggers firing from devd. I als= o noticed that the man page on 'carp' references a "carpcontrol.sh" script = as an action. Has this script been prototyped anywhere yet?=20 -Andrew From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 12:59:49 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35993106566B; Fri, 3 Feb 2012 12:59:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id EA4A08FC08; Fri, 3 Feb 2012 12:59:48 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 7350F46B17; Fri, 3 Feb 2012 07:59:48 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 075A2B958; Fri, 3 Feb 2012 07:59:48 -0500 (EST) From: John Baldwin To: Doug Barton Date: Fri, 3 Feb 2012 07:59:47 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <201201311149.32760.jhb@freebsd.org> <201202010742.11936.jhb@freebsd.org> <4F2B3250.7000000@FreeBSD.org> In-Reply-To: <4F2B3250.7000000@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201202030759.47473.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 03 Feb 2012 07:59:48 -0500 (EST) Cc: current@freebsd.org Subject: Re: Race between cron and crontab X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 12:59:49 -0000 On Thursday, February 02, 2012 8:03:12 pm Doug Barton wrote: > On 02/01/2012 04:42, John Baldwin wrote: > > On Tuesday, January 31, 2012 9:23:12 pm Doug Barton wrote: > >> On 01/31/2012 08:49, John Baldwin wrote: > >>> A co-worker ran into a race between updating a cron tab via crontab(8) and > >>> cron(8) yesterday. Specifically, cron(8) failed to notice that a crontab was > >>> updated. The problem is that 1) by default our filesystems only use second > >>> granularity for timestamps and 2) cron only caches the seconds portion of a > >>> file's timestamp when checking for changes anyway. This means that cron can > >>> miss updates to a spool directory if multiple updates to the directory are > >>> performed within a single second and cron wakes up to scan the spool directory > >>> within the same second and scans it before all of the updates are complete. > >>> > >>> Specifically, when replacing a crontab, crontab(8) first creates a temporary > >>> file in /var/cron/tabs and then uses a rename to install it followed by > >>> touching the spool directory to update its modification time. However, the > >>> creation of the temporary file already changes the modification time of the > >>> directory, and cron may "miss" the rename if it scans the directory in between > >>> the creation of the temporary file and the rename. > >>> > >>> The "fix" I am planning to use locally is to simply force crontab(8) to sleep > >>> for a second before it touches the spool directory, thus ensuring that it the > >>> touch of the spool directory will use a later modification time than the > >>> creation of the temporary file. > >> > >> If you really want cron to have sub-second granularity I don't see how > >> you could do it without using flags. > >> > >> crontab open sets flag that it is editing a file > >> crontab close clears "editing" flag, sets "something changed" flag > >> (if something actually changed of course) > >> > >> cron checks existence of "something changed" flag, pulls the > >> update if there is no "editing" flag, clears "changed" flag > > > > I don't want it to have sub-second granularity, > > Ok, I was interpolating, sorry if I misinterpreted your intentions. > > > I just want to make > > 'crontab -e' more reliable so that cron doesn't miss edits. cron is > > currently using the mod-time of the spool directory as the 'something > > changed' flag (have you read the cron code?). > > I understand the spool behavior from history/experience, and I am > relying on your excellent summary for the details. :) > > > The problem is that it > > currently can set the 'something changed' flag non-atomically while it is > > updating a crontab. > > That much I understood from your post. My response to what it is I think > you're trying to achieve is that it's not likely that you can achieve it > by only using 1 flag, no matter what that 1 flag is. I may be wrong > about that, but hopefully my suggestion gives you some other ideas to > consider. Eh, I think the mod-time on the directory is fine. It will change anything anything in that directory changes, so that is good enough, and it's ok to lose the race in the direction of doing extra scans of the spool directory, it just needs to avoid not doing enough scans. > Meanwhile, I was thinking more about this and TMK cron doesn't actually > *run* jobs with seconds granularity, only minutes, right? If so then it > seems that the only really important seconds to care about are :59 and > :00. That would seem to present a solution that rather than having cron > wake up every second to see if something has changed that it only do > that at :59 (or however many seconds in advance of :00 that it needs, > although if it's more than 1 I'll be surprised). That limits the race to > someone who writes out a new crontab entry at the point during second > :59 that is after cron wakes up to look but before :00. So that's not a > perfect solution to your problem, but it should limit the race to a very > narrow window without having to modify the code very much. Hmm, did you see my original e-mail? I have a one-line fix to crontab(8). :) Do you think that patch is invalid? Also, the race is not what you think it is: cron already only checks once a minute, the problem is a crontab(8) replace happening concurrently with cron's scan of the spool directory in such a way that cron only sees part of the actions crontab(8) performs while updating a tab. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 15:14:30 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C83291065672 for ; Fri, 3 Feb 2012 15:14:30 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 4BFE28FC14 for ; Fri, 3 Feb 2012 15:14:30 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so4047191wgb.31 for ; Fri, 03 Feb 2012 07:14:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:from:organization:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=krUm9gLr8VMALMODzGCHpXzI6pnO8HHTTTwX1Gcxxmc=; b=KNqsg0971XvB2JwuQRms1nOuXNHdYVmHN0nIjPfv8vazCcUqXpGdVrP4fv20ghUSnu EbE5UqxOJKqhDoWumLamEoilmDPOHnDAwdeOQdLEvwBwcURvGhUHKvpUMHnXnJgpi7fq YLYPxna8IfFLAwkh9lv7diuph5cmzSokYtANw= Received: by 10.180.90.225 with SMTP id bz1mr25591392wib.5.1328280174209; Fri, 03 Feb 2012 06:42:54 -0800 (PST) Received: from woodstock.peanuts ([95.236.25.157]) by mx.google.com with ESMTPS id s2sm4817775wix.3.2012.02.03.06.42.53 (version=SSLv3 cipher=OTHER); Fri, 03 Feb 2012 06:42:53 -0800 (PST) Sender: Alberto Villa From: Alberto Villa Organization: The FreeBSD Project To: freebsd-current@freebsd.org Date: Fri, 3 Feb 2012 15:42:49 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.0-RC2; KDE/4.7.4; amd64; ; ) References: <4F2AF46A.8030105@zedat.fu-berlin.de> In-Reply-To: <4F2AF46A.8030105@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3027795.Mnt7HXCzTl"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201202031542.52241.avilla@freebsd.org> Cc: "O. Hartmann" Subject: Re: x11/kde4-workspace 4.7.4: fails to be built on FreeBSD 10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 15:14:30 -0000 --nextPart3027795.Mnt7HXCzTl Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable On Thursday 02 February 2012 21:39:06 O. Hartmann wrote: > Since a couple of days I try to update/compile x11/kd4-workspace (from > 4.7.3 -> 4.7.4), but it fails. Compilation fails with gcc 4.2.1 and > CLANG as well. You already reported this, but didn't answer to questions from rakuco@ and= =20 me... Can you please attach a log of the build with GCC using -DCMAKE_VERBOSE? =2D-=20 Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla Rainy days and Mondays always get me down. --nextPart3027795.Mnt7HXCzTl Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iJwEAAECAAYFAk8r8mwACgkQ3xiC6kQ1Cou9KQQAvLAxS6Gk6azHxInJRC8DKP8l /NXM0UMH+WUZgXzDHSgp0A0Bdi/kTXVyiyLZjjNo/t+S4ldDzZ2RJ/2J6g2+muFR HeJzJh/wwxBMrsV9zz8E6Gp8as0pziJu6cPRy8A2Rj3D5txRfArQ/gGOU3bLvucp 7I+PEWg4xh9gX17nXuE= =mt11 -----END PGP SIGNATURE----- --nextPart3027795.Mnt7HXCzTl-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 17:21:19 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCFB21065677 for ; Fri, 3 Feb 2012 17:21:19 +0000 (UTC) (envelope-from dlt@mebtel.net) Received: from mail941c35.nsolutionszone.com (mail941c35.nsolutionszone.com [209.235.152.131]) by mx1.freebsd.org (Postfix) with ESMTP id 710418FC0A for ; Fri, 3 Feb 2012 17:21:18 +0000 (UTC) X-POP-User: dlt.mebtel.net Received: from localhost (99-194-23-158.dyn.centurytel.net [99.194.23.158]) by mail941c35.nsolutionszone.com (8.13.6/8.13.1) with ESMTP id q13EYdkU003536 for ; Fri, 3 Feb 2012 14:34:40 GMT Date: Fri, 3 Feb 2012 09:34:38 -0500 From: Derek Tattersall To: current@FreeBSD.org Message-ID: <20120203143438.GA2798@oriental.arm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-CSC: 0 X-CHA: v=1.1 cv=9TUB+RS35G5y5DT6KTRCAKUVG+9gOaz+XaEOQ/3CU8k= c=1 sm=1 a=z1TLwsU0kBEA:10 a=foMAl8t5F5wA:10 a=P2oOn6vrs4wA:10 a=GPr01A5e9VcA:10 a=kj9zAlcOel0A:10 a=5FSmvsqyZ8dLHOg+TByL6Q==:17 a=xwPayol1AAAA:8 a=CjxXgO3LAAAA:8 a=pGLkceISAAAA:8 a=gI1602zpgqhbkwQnkw0A:9 a=CjuIK1q_8ugA:10 a=0Ob1RWNGeVAA:10 a=rC2wZJ5BpNYA:10 a=MSl-tDqOz04A:10 a=5FSmvsqyZ8dLHOg+TByL6Q==:117 Cc: Subject: Can't umount a formerly mounted drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dlt@mebtel.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 17:21:19 -0000 I have two drives in a x86-64 machine. Drive ada2 has current on it, and drive ada1 has 9-stable on it. At some point, while running current, I mounted the /home partition from stable to copy some files and re-ipled the system into stable. every thing worked properly. Some time later I ipled current again. I then noticed that the stable /home was mounted on /mnt. I tried to umount it but the operation failed as /dev/ada1p7 was not considered mounted. Yet with out mounting I could access all the files on stable's /home, I could create and delete files. The current system was cvsup'ed on Wednesday this week, while the stable system was cvsup'ed last Sunday. Neither system has exhibited any hiccups. Can somebody explain what has happened her on the current system and how it should be corrected? -- Best regards, Derek Tattersall dlt@mebtel.net dlt666@yahoo.com dtatters@gmail.com From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 18:02:52 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4254B106566C for ; Fri, 3 Feb 2012 18:02:52 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id E82F38FC15 for ; Fri, 3 Feb 2012 18:02:51 +0000 (UTC) Received: by vcmm1 with SMTP id m1so4343350vcm.13 for ; Fri, 03 Feb 2012 10:02:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=z0qo+V8I8S70NyC4zSsiTVODsTNsD+3thtfEhEWO5NA=; b=QF0eL0VNPTU3iEiLppu9t56zQrUXPGU+kGfQrHkq0yd69zpy0xy9lnMHAxWwyVa6dz vkeTog/8FbSiw87TzIy7nHRyWrbPzqg26oN27ihRAcOYTywjjyrQP6fmMhnr2IpLnVFP uNH8DbrTYRCpf8AK29WhyWHio3kEozsYbte7k= MIME-Version: 1.0 Received: by 10.221.13.196 with SMTP id pn4mr5040732vcb.74.1328292171179; Fri, 03 Feb 2012 10:02:51 -0800 (PST) Received: by 10.220.181.4 with HTTP; Fri, 3 Feb 2012 10:02:51 -0800 (PST) In-Reply-To: References: Date: Fri, 3 Feb 2012 10:02:51 -0800 Message-ID: From: Freddie Cash To: Andrew Hobbs Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-current@freebsd.org" Subject: Re: CARP on -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 18:02:52 -0000 On Fri, Feb 3, 2012 at 1:35 AM, Andrew Hobbs wrote: >> On 2 February 2012 04:26, Andrew Hobbs wrote: >> > I much appreciate the responses and I was able to get CARP functioning >> > using the new ifconfig syntax under -CURRENT. Having done that, CARP >> > is now acting as it should, though now I have a new challenge with >> > devd and automatic firing of scripts during CARP failover. It appears >> > that the documented method of doing this at >> > http://www.freebsd.org/doc/handbook/disks-hast.html no longer works >> > with the suggested devd.conf setup; notify 30 { >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0match "system" "IFNET"; >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0match "subsystem" "carp0"; >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0match "type" "LINK_UP"; >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0action "/usr/local/sbin/carp-hast-switch ma= ster"; }; >> > >> > notify 30 { >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0match "system" "IFNET"; >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0match "subsystem" "carp0"; >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0match "type" "LINK_DOWN"; >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0action "/usr/local/sbin/carp-hast-switch sl= ave"; >> > >> > Is it likely that the triggers associated with CARP for devd have chan= ged due to the recent new CARP overhaul? Does anyone know what the new trig= gers may be? >> > >> >> You will need to change this to something like (as taken from man carp): >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0match "system" =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0"CARP"; >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0match "subsystem" =C2=A0 =C2=A0 =C2=A0= "[0-9]+@"; >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0match "type" =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0"(MASTER|BACKUP)"; >> >> The subsystem now is generated as >> snprintf(subsys, IFNAMSIZ+5, "%u@%s", sc->sc_vhid, sc->sc_carpdev->if_xn= ame); > Thanks for the info. I was able to get the triggers firing from devd. I a= lso noticed that the man page on 'carp' references a "carpcontrol.sh" scrip= t as an action. Has this script been prototyped anywhere yet? Mind posting the devd.conf entries you are using? Maybe submitting a docs PR with them included, to update the HAST page? Thanks. I haven't played with HAST and the new CARP code yet. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 18:48:26 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C7181065672 for ; Fri, 3 Feb 2012 18:48:26 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 91AB98FC14 for ; Fri, 3 Feb 2012 18:48:25 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so4295302wgb.31 for ; Fri, 03 Feb 2012 10:48:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=8vz8YbCf3Z8YGWBkNusu+JMHiekpuxa59lxvyoxJplw=; b=LPeQy8rr7+mYhhussAM8vWkrNCYmoOWNJK8zhD4FuSMah7kfT24gXqAbWSJozXHCkn co7fsNpFgiP+3j96NNypPvLbsCwzW4ZGlnoDr1C1Tx3LR1Itf94iQf1MD5WMnhNZ4d7N Ly2LRVCc+Du5hWA/7H0viu4f2jPE+TpK8azDs= MIME-Version: 1.0 Received: by 10.180.84.105 with SMTP id x9mr26421506wiy.19.1328293527614; Fri, 03 Feb 2012 10:25:27 -0800 (PST) Received: by 10.180.106.129 with HTTP; Fri, 3 Feb 2012 10:25:27 -0800 (PST) In-Reply-To: <20120203143438.GA2798@oriental.arm.org> References: <20120203143438.GA2798@oriental.arm.org> Date: Fri, 3 Feb 2012 13:25:27 -0500 Message-ID: From: Ryan Stone To: dlt@mebtel.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: Can't umount a formerly mounted drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 18:48:26 -0000 On Fri, Feb 3, 2012 at 9:34 AM, Derek Tattersall wrote: > I have two drives in a x86-64 machine. =A0Drive ada2 has current on it, a= nd > drive ada1 has 9-stable on it. =A0At some point, while running current, I > mounted the /home partition from stable to copy some files and re-ipled > the system into stable. =A0every thing worked properly. =A0Some time late= r I > ipled current again. =A0I then noticed that the stable /home was mounted > on /mnt. =A0I tried to umount it but the operation failed as /dev/ada1p7 > was not considered mounted. =A0Yet with out mounting I could access all > the files on stable's /home, I could create and delete files. > > The current system was cvsup'ed on Wednesday this week, while the stable > system was cvsup'ed last Sunday. =A0Neither system has exhibited any > hiccups. =A0Can somebody explain what has happened her on the current > system and how it should be corrected? Does "mount" list anything as being mounted on /mnt? If not, are you sure that /mnt isn't a symlink to somewhere else? Or maybe the contents of the home directory were copied to /mnt by accident? From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 18:50:56 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E66A0106568D for ; Fri, 3 Feb 2012 18:50:56 +0000 (UTC) (envelope-from dlt@mebtel.net) Received: from mail941c35.nsolutionszone.com (mail941c35.nsolutionszone.com [209.235.152.131]) by mx1.freebsd.org (Postfix) with ESMTP id 920868FC0C for ; Fri, 3 Feb 2012 18:50:56 +0000 (UTC) X-POP-User: dlt.mebtel.net Received: from localhost (99-194-23-158.dyn.centurytel.net [99.194.23.158]) by mail941c35.nsolutionszone.com (8.13.6/8.13.1) with ESMTP id q13IoruQ005300; Fri, 3 Feb 2012 18:50:54 GMT Date: Fri, 3 Feb 2012 13:50:53 -0500 From: Derek Tattersall To: Ryan Stone Message-ID: <20120203185053.GA11019@oriental.arm.org> References: <20120203143438.GA2798@oriental.arm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-CSC: 0 X-CHA: v=1.1 cv=9TUB+RS35G5y5DT6KTRCAKUVG+9gOaz+XaEOQ/3CU8k= c=1 sm=1 a=wom5GMh1gUkA:10 a=AOmNu5pVU98A:10 a=P2oOn6vrs4wA:10 a=GPr01A5e9VcA:10 a=8nJEP1OIZ-IA:10 a=5FSmvsqyZ8dLHOg+TByL6Q==:17 a=pGLkceISAAAA:8 a=xwPayol1AAAA:8 a=CjxXgO3LAAAA:8 a=ZrG5GFV56G0ZXiGiZ0gA:9 a=wPNLvfGTeEIA:10 a=MSl-tDqOz04A:10 a=0Ob1RWNGeVAA:10 a=rC2wZJ5BpNYA:10 a=5FSmvsqyZ8dLHOg+TByL6Q==:117 Cc: current@freebsd.org Subject: Re: Can't umount a formerly mounted drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dlt@mebtel.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 18:50:57 -0000 * Ryan Stone [120203 13:41]: > On Fri, Feb 3, 2012 at 9:34 AM, Derek Tattersall wrote: > > I have two drives in a x86-64 machine.  Drive ada2 has current on it, and > > drive ada1 has 9-stable on it.  At some point, while running current, I > > mounted the /home partition from stable to copy some files and re-ipled > > the system into stable.  every thing worked properly.  Some time later I > > ipled current again.  I then noticed that the stable /home was mounted > > on /mnt.  I tried to umount it but the operation failed as /dev/ada1p7 > > was not considered mounted.  Yet with out mounting I could access all > > the files on stable's /home, I could create and delete files. > > > > The current system was cvsup'ed on Wednesday this week, while the stable > > system was cvsup'ed last Sunday.  Neither system has exhibited any > > hiccups.  Can somebody explain what has happened her on the current > > system and how it should be corrected? > > Does "mount" list anything as being mounted on /mnt? If not, are you > sure that /mnt isn't a symlink to somewhere else? Or maybe the > contents of the home directory were copied to /mnt by accident? mount command on the current system does not list anything under /mnt. ls /mnt on the current system list the top level directories on ada1p7, the stable /home. It lists them as soon as a user logs in on a newly booted current system. It's really frustrating. -- Best regards, Derek Tattersall dlt@mebtel.net dlt666@yahoo.com dtatters@gmail.com From owner-freebsd-current@FreeBSD.ORG Sat Feb 4 00:02:33 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7554E1065672 for ; Sat, 4 Feb 2012 00:02:33 +0000 (UTC) (envelope-from dmitrym@juniper.net) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by mx1.freebsd.org (Postfix) with ESMTP id EFFAD8FC21 for ; Sat, 4 Feb 2012 00:02:32 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTyx1l46edWDPR8yYCsUdy3EB4moczXtY@postini.com; Fri, 03 Feb 2012 16:02:33 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 3 Feb 2012 16:01:48 -0800 Received: from [172.24.26.191] (dmitrym-lnx.jnpr.net [172.24.26.191]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q1401m167044; Fri, 3 Feb 2012 16:01:48 -0800 (PST) (envelope-from dmitrym@juniper.net) Message-ID: <4F2C756A.80900@juniper.net> Date: Fri, 3 Feb 2012 16:01:46 -0800 From: Dmitry Mikulin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Kostik Belousov References: <749E238A-A85F-4264-9DEB-BCE1BBD21C9D@juniper.net> <20120125074824.GD2726@deviant.kiev.zoral.com.ua> <4F2094B4.70707@juniper.net> <20120126122326.GT2726@deviant.kiev.zoral.com.ua> <4F22E8FD.6010201@juniper.net> <20120129074843.GL2726@deviant.kiev.zoral.com.ua> <4F26E0D1.8040100@juniper.net> <20120130192727.GZ2726@deviant.kiev.zoral.com.ua> In-Reply-To: <20120130192727.GZ2726@deviant.kiev.zoral.com.ua> Content-Type: multipart/mixed; boundary="------------030706030706070106060906" X-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629 X-Mailman-Approved-At: Sat, 04 Feb 2012 00:19:19 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current Current , Marcel Moolenaar Subject: Re: [ptrace] please review follow fork/exec changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 00:02:33 -0000 --------------030706030706070106060906 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit > Please provide more details, I am looking forward for the panic > message and backtrace. I can't seem to get the panic with the latest source base, but tracing doesn't appear to work with vfork(). I attached a modified test case to closer model what gdb is doing. If you change fork() to vfork() in simple.c the parent doesn't get the events the same way it does under fork(). > The lack of the notification for parent is exactly what the patch I > posted fixes. More exactly, it is the lack of notification for parent > with PT_CONTINUE loop. I will commit this today. > > Regarding a single notification. Currently, parent arrives at the > syscall return code only after the child is attached to the debugger. > See the cv_wait() in kern_fork.c:739. In other words, if you get the > PL_FLAG_FORK, the child is already attached (at last it shall be). My > scescx.c code illustrates this well, IMO. > > You still get a separate stop from the child, but I do not see how is it > harmful. There a couple of tweaks to the interface that I'd like to have: - set PL_FLAG_FORKED in the child so gdb can identify the stop as a fork() event. - add a switch similar to PT_FOLLOW_FORK to enable/disable exec() notifications. Gdb gets confused by the events it hasn't explicitly asked for and having a switch makes it easier to filter out unwanted stops. Do you think it's possible/makes sense? Thanks. Dmitry. --------------030706030706070106060906-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 4 03:41:09 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D13F1065676 for ; Sat, 4 Feb 2012 03:41:09 +0000 (UTC) (envelope-from andrew.hobbs@ai.net) Received: from ginga.ai.net (ginga.ai.net [205.134.166.19]) by mx1.freebsd.org (Postfix) with ESMTP id 102678FC08 for ; Sat, 4 Feb 2012 03:41:08 +0000 (UTC) Received: from ginga.ai.net ([205.134.166.19]) by ginga.ai.net ([205.134.166.19]) with mapi; Fri, 3 Feb 2012 22:41:07 -0500 From: Andrew Hobbs To: Freddie Cash Date: Fri, 3 Feb 2012 22:41:06 -0500 Thread-Topic: CARP on -CURRENT Thread-Index: Aczi7tOhG7/uss9TTFq35K+T5VSZnQ== Message-ID: <239A12C9-1416-4BFC-80B5-2CA93B400CCB@ai.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-current@freebsd.org" Subject: Re: CARP on -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 03:41:09 -0000 On Feb 3, 2012, at 1:02 PM, Freddie Cash wrote: > On Fri, Feb 3, 2012 at 1:35 AM, Andrew Hobbs wrote: >>> On 2 February 2012 04:26, Andrew Hobbs wrote: >>>> I much appreciate the responses and I was able to get CARP functioning >>>> using the new ifconfig syntax under -CURRENT. Having done that, CARP >>>> is now acting as it should, though now I have a new challenge with >>>> devd and automatic firing of scripts during CARP failover. It appears >>>> that the documented method of doing this at >>>> http://www.freebsd.org/doc/handbook/disks-hast.html no longer works >>>> with the suggested devd.conf setup; notify 30 { >>>> match "system" "IFNET"; >>>> match "subsystem" "carp0"; >>>> match "type" "LINK_UP"; >>>> action "/usr/local/sbin/carp-hast-switch master"; }; >>>>=20 >>>> notify 30 { >>>> match "system" "IFNET"; >>>> match "subsystem" "carp0"; >>>> match "type" "LINK_DOWN"; >>>> action "/usr/local/sbin/carp-hast-switch slave"; >>>>=20 >>>> Is it likely that the triggers associated with CARP for devd have chan= ged due to the recent new CARP overhaul? Does anyone know what the new trig= gers may be? >>>>=20 >>>=20 >>> You will need to change this to something like (as taken from man carp)= : >>> match "system" "CARP"; >>> match "subsystem" "[0-9]+@"; >>> match "type" "(MASTER|BACKUP)"; >>>=20 >>> The subsystem now is generated as >>> snprintf(subsys, IFNAMSIZ+5, "%u@%s", sc->sc_vhid, sc->sc_carpdev->if_x= name); >=20 >> Thanks for the info. I was able to get the triggers firing from devd. I = also noticed that the man page on 'carp' references a "carpcontrol.sh" scri= pt as an action. Has this script been prototyped anywhere yet? >=20 > Mind posting the devd.conf entries you are using? Maybe submitting a > docs PR with them included, to update the HAST page? >=20 > Thanks. I haven't played with HAST and the new CARP code yet. >=20 > --=20 > Freddie Cash > fjwcash@gmail.com The entirety of the cogent entry in /etc/devd.conf that I am using follows; notify 0 { match "system" "CARP"; match "subsystem" "[0-9]+@"; match "type" "(INIT|MASTER|BACKUP)"; # action "/root/carpcontrol.sh $subsystem $type"; action "/etc/test_carp.sh $subsystem $type"; }; This differs from the example in "man 4 carp" only by one line. I substitut= ed the 'action "/etc/test_carp.sh $subsystem $type";' for the line above it= , as I cannot seem to locate a 'carpcontrol.sh' script anywhere on my 10.0-= CURRENT test platform. Hence my earlier inquiry as to if it had been protot= yped anywhere yet. I did locate several CARP related action scripts in /usr= /share/examples/hast/ but I'm not sure how they different from this ephemer= al 'carpcontrol.sh' script without seeing it. -Andrew= From owner-freebsd-current@FreeBSD.ORG Sat Feb 4 03:58:44 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF0AF106566B for ; Sat, 4 Feb 2012 03:58:44 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 62D588FC17 for ; Sat, 4 Feb 2012 03:58:44 +0000 (UTC) Received: by eekb47 with SMTP id b47so1619865eek.13 for ; Fri, 03 Feb 2012 19:58:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; bh=mClj3CXnoJS6hO0DoI8KzP8A1u+vn2177RwnVXsJssY=; b=YI3TkeNvv5I1F7pOuC/jgZqpLm6PCPszCp6S/BU5tEAZk+gh+m8a9Q6InBPSHSnrPH sNF6Jehc3j/2xCeNJcjdjm67aVhNg8PnDmSPcT79yMJlFDKXHWhhsE7X6y67mlylqpeq 5YQeKlP11LZL8oAgqmi427YKp8CtmSZG+Z33s= Received: by 10.14.17.75 with SMTP id i51mr3068558eei.70.1328327923525; Fri, 03 Feb 2012 19:58:43 -0800 (PST) Received: from ernst.jennejohn.org (p578E2EFA.dip.t-dialin.net. [87.142.46.250]) by mx.google.com with ESMTPS id y12sm29652622eeb.11.2012.02.03.19.58.41 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Feb 2012 19:58:42 -0800 (PST) Date: Sat, 4 Feb 2012 04:58:39 +0100 From: Gary Jennejohn To: dlt@mebtel.net Message-ID: <20120204045839.05be4572@ernst.jennejohn.org> In-Reply-To: <20120203185053.GA11019@oriental.arm.org> References: <20120203143438.GA2798@oriental.arm.org> <20120203185053.GA11019@oriental.arm.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Ryan Stone , current@freebsd.org Subject: Re: Can't umount a formerly mounted drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 03:58:44 -0000 On Fri, 3 Feb 2012 13:50:53 -0500 Derek Tattersall wrote: > * Ryan Stone [120203 13:41]: > > On Fri, Feb 3, 2012 at 9:34 AM, Derek Tattersall wrote: > > > I have two drives in a x86-64 machine.  Drive ada2 has current on it, and > > > drive ada1 has 9-stable on it.  At some point, while running current, I > > > mounted the /home partition from stable to copy some files and re-ipled > > > the system into stable.  every thing worked properly.  Some time later I > > > ipled current again.  I then noticed that the stable /home was mounted > > > on /mnt.  I tried to umount it but the operation failed as /dev/ada1p7 > > > was not considered mounted.  Yet with out mounting I could access all > > > the files on stable's /home, I could create and delete files. > > > > > > The current system was cvsup'ed on Wednesday this week, while the stable > > > system was cvsup'ed last Sunday.  Neither system has exhibited any > > > hiccups.  Can somebody explain what has happened her on the current > > > system and how it should be corrected? > > > > Does "mount" list anything as being mounted on /mnt? If not, are you > > sure that /mnt isn't a symlink to somewhere else? Or maybe the > > contents of the home directory were copied to /mnt by accident? > mount command on the current system does not list anything under /mnt. > ls /mnt on the current system list the top level directories on ada1p7, > the stable /home. It lists them as soon as a user logs in on a newly > booted current system. It's really frustrating. > Well, it certainly looks like Ryan's suggestion that files from /home were copied to /mnt (with nothing mounted on it) is correct. Try mounting /home to a different location, like /mnt1, and compare the dates on the suspicious files. Wouldn't surprise me to find that they differ. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Sat Feb 4 07:54:34 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C1741065670 for ; Sat, 4 Feb 2012 07:54:34 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 212EA8FC0A for ; Sat, 4 Feb 2012 07:54:33 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q147sVee027793 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 3 Feb 2012 23:54:33 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F2CE485.5020909@freebsd.org> Date: Fri, 03 Feb 2012 23:55:49 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.25) Gecko/20111213 Thunderbird/3.1.17 MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: problem with kgdb and modules X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 07:54:34 -0000 so We upgraded our development machines from 8 stable to 9 stable. and now kgdb can't debug inside modules. instead of getting anything useful, we just get: (kgdb) bt #0 0xffffffff81814600 in ?? () from /boot/kernel/netgraph.ko #1 0xffffffff81812d80 in ?? () from /boot/kernel/ng_socket.ko #2 0x0000000000000037 in ?? () #3 0x0000000000000002 in ?? () #4 0xfffffe0007176aa0 in ?? () #5 0xfffffe0007176aa0 in ?? () #6 0xffffffff818134a0 in ?? () from /boot/kernel/ng_socket.ko #7 0xffffffff81813960 in ?? () from /boot/kernel/ng_socket.ko #8 0xffffff860fa3cad0 in ?? () #9 0xffffffff808cc76e in socreate (dom=Variable "dom" is not available. ) at ../../../kern/uipc_socket.c:411 but stopping in the kernel itself, we DO see stuff.. (kgdb) break socreate Breakpoint 1 at 0xffffffff808cc628: file ../../../kern/uipc_socket.c, line 372. (kgdb) c Continuing. [New Thread 100198] [Switching to Thread 100198] Breakpoint 1, socreate (dom=32, aso=0xffffff860fa3caf0, type=2, proto=1, cred=0xfffffe000c63f600, td=0xfffffe011501a000) at ../../../kern/uipc_socket.c:372 372 if (proto) (kgdb) bt #0 socreate (dom=32, aso=0xffffff860fa3caf0, type=2, proto=1, cred=0xfffffe000c63f600, td=0xfffffe011501a000) at ../../../kern/uipc_socket.c:372 #1 0xffffffff808cf710 in sys_socket (td=0xfffffe011501a000, uap=0xffffff860fa3cbc0) at ../../../kern/uipc_syscalls.c:199 #2 0xffffffff80b5599a in amd64_syscall (td=0xfffffe011501a000, traced=0) at subr_syscall.c:131 #3 0xffffffff80b40b57 in Xfast_syscall () at ../../../amd64/amd64/exception.S:387 #4 0x00000008011c82ac in ?? () etc. it looks as if modules no longer have stack frames compiled in. does anyone know the culprit? From owner-freebsd-current@FreeBSD.ORG Sat Feb 4 09:14:38 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDEB9106564A for ; Sat, 4 Feb 2012 09:14:38 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id A802D8FC12 for ; Sat, 4 Feb 2012 09:14:38 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q149EaXC028028 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 4 Feb 2012 01:14:37 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F2CF74A.9040804@freebsd.org> Date: Sat, 04 Feb 2012 01:15:54 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.25) Gecko/20111213 Thunderbird/3.1.17 MIME-Version: 1.0 To: FreeBSD Current References: <4F2CE485.5020909@freebsd.org> In-Reply-To: <4F2CE485.5020909@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: problem with kgdb and modules X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 09:14:39 -0000 On 2/3/12 11:55 PM, Julian Elischer wrote: > so We upgraded our development machines from 8 stable to 9 stable. > and now kgdb can't debug inside modules. > > instead of getting anything useful, we just get: > > (kgdb) bt > #0 0xffffffff81814600 in ?? () from /boot/kernel/netgraph.ko > #1 0xffffffff81812d80 in ?? () from /boot/kernel/ng_socket.ko > #2 0x0000000000000037 in ?? () > #3 0x0000000000000002 in ?? () > #4 0xfffffe0007176aa0 in ?? () > #5 0xfffffe0007176aa0 in ?? () > #6 0xffffffff818134a0 in ?? () from /boot/kernel/ng_socket.ko > #7 0xffffffff81813960 in ?? () from /boot/kernel/ng_socket.ko > #8 0xffffff860fa3cad0 in ?? () > #9 0xffffffff808cc76e in socreate (dom=Variable "dom" is not > available. > ) at ../../../kern/uipc_socket.c:411 > > > > but stopping in the kernel itself, we DO see stuff.. > > (kgdb) break socreate > Breakpoint 1 at 0xffffffff808cc628: file > ../../../kern/uipc_socket.c, line 372. > (kgdb) c > Continuing. > > > > [New Thread 100198] > [Switching to Thread 100198] > > Breakpoint 1, socreate (dom=32, aso=0xffffff860fa3caf0, type=2, > proto=1, cred=0xfffffe000c63f600, td=0xfffffe011501a000) at > ../../../kern/uipc_socket.c:372 > 372 if (proto) > (kgdb) bt > #0 socreate (dom=32, aso=0xffffff860fa3caf0, type=2, proto=1, > cred=0xfffffe000c63f600, td=0xfffffe011501a000) at > ../../../kern/uipc_socket.c:372 > #1 0xffffffff808cf710 in sys_socket (td=0xfffffe011501a000, > uap=0xffffff860fa3cbc0) at ../../../kern/uipc_syscalls.c:199 > #2 0xffffffff80b5599a in amd64_syscall (td=0xfffffe011501a000, > traced=0) at subr_syscall.c:131 > #3 0xffffffff80b40b57 in Xfast_syscall () at > ../../../amd64/amd64/exception.S:387 > #4 0x00000008011c82ac in ?? () > > > > etc. > > it looks as if modules no longer have stack frames compiled in. > does anyone know the culprit? very easy to duplicate; load a module set a brakepoint in the module, make it go there and stop switch to remote kgdb . (.gdbinit has: # firewire dconschat is listening here: target remote localhost:2223 info sharedlibrary sharedlibrary ${YOUR_SHARED_LIBRARY} ) notice that backtrace in KGDB is now crappy, where it looks great in DDB > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Feb 4 14:00:16 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB7FA1065670; Sat, 4 Feb 2012 14:00:15 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 824A48FC13; Sat, 4 Feb 2012 14:00:15 +0000 (UTC) Received: by iaeo4 with SMTP id o4so9442157iae.13 for ; Sat, 04 Feb 2012 06:00:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; bh=3/Jxgo08NN5Vw88Lzo81Wr3daUo5lInUretihsJkNgE=; b=Dv84IPmUyjDd2JBcyH+m6ges7q+uX9UkKA1bz69g3hC69ALlZyo0UXlali0kDDxGSL uPKnVJcqOw4ftthLIv4A/iXw4GD130cQ6G1Ji9gokquTroi7QqXOBNl85rXDwfLgerfX iE6B6UKntR8GmlDdVolhgsvN/qdGXQv4ac9ss= Received: by 10.43.44.197 with SMTP id uh5mr12545065icb.34.1328362533668; Sat, 04 Feb 2012 05:35:33 -0800 (PST) Received: from triad.knownspace (216-15-41-8.c3-0.gth-ubr1.lnh-gth.md.cable.rcn.com. [216.15.41.8]) by mx.google.com with ESMTPS id 5sm16776262ibe.8.2012.02.04.05.35.32 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 04 Feb 2012 05:35:32 -0800 (PST) Message-Id: <4090E660-1712-4446-BAC9-6719D362B0E6@gmail.com> From: Justin Hibbits To: Baptiste Daroussin In-Reply-To: <20120130123930.GB40244@azathoth.lan> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 4 Feb 2012 08:33:04 -0500 References: <20120130123930.GB40244@azathoth.lan> X-Mailer: Apple Mail (2.936) Cc: ports@FreeBSD.org, ports-announce@FreeBSD.org, current@FreeBSD.org Subject: Re: [HEADSUP][CFT] pkgng beta1 is out X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 14:00:16 -0000 Hi Baptiste, On Jan 30, 2012, at 7:39 AM, Baptiste Daroussin wrote: > Hi, > > pkgng has just reached the beta phase, and has now found its way to > the > ports tree (disabled by default). > > I'll file an issue on github as well, but wanted to note it here, too. Seems pkgng segfaults reproducibly on powerpc, at least as pkg- static so it fails to even install. I'll post the backrace I got in the github issue. - Justin From owner-freebsd-current@FreeBSD.ORG Sat Feb 4 17:50:31 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59482106566B for ; Sat, 4 Feb 2012 17:50:31 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id D08D58FC13 for ; Sat, 4 Feb 2012 17:50:30 +0000 (UTC) Received: by eaan10 with SMTP id n10so2207030eaa.13 for ; Sat, 04 Feb 2012 09:50:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:from:organization:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=sDqN0CPtOTVOKj4Inlk4idGJCCk459nrkqkoIB31hJw=; b=sLmCr5aoOPWdQkRDVSdqlqCmkgngdXcOINbEkumGZBjlW+qgxQNR49JX21g+iArTzJ P70xAW4sDUruepk3ztcZA4zFZioXRlVpho1gX2FbgbkOJY1lknRo7fJHaCDrQzc08Y7x zPMAgHdZdvTprBwf8bucMoPBNt5VFGEA5/nC4= Received: by 10.213.8.71 with SMTP id g7mr38374ebg.103.1328377829710; Sat, 04 Feb 2012 09:50:29 -0800 (PST) Received: from woodstock.peanuts ([95.236.25.157]) by mx.google.com with ESMTPS id e12sm37547079eea.5.2012.02.04.09.50.26 (version=SSLv3 cipher=OTHER); Sat, 04 Feb 2012 09:50:26 -0800 (PST) Sender: Alberto Villa From: Alberto Villa Organization: The FreeBSD Project To: "O. Hartmann" Date: Sat, 4 Feb 2012 18:50:22 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.0-RC2; KDE/4.7.4; amd64; ; ) References: <4F2AF46A.8030105@zedat.fu-berlin.de> <201202031542.52241.avilla@freebsd.org> <4F2CE6FD.1010804@zedat.fu-berlin.de> In-Reply-To: <4F2CE6FD.1010804@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1334517.H57WOesY1B"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201202041850.24815.avilla@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: x11/kde4-workspace 4.7.4: fails to be built on FreeBSD 10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 17:50:31 -0000 --nextPart1334517.H57WOesY1B Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable On Saturday 04 February 2012 09:06:21 O. Hartmann wrote: > Mea culpa, mea culpa, mea maxima culpa! >=20 > I'm under pressure with my work and I guess I missed something. > Yes, of course, I'll give you the requested, as attached. I hope this is > satisfying, if any request remains, please send me an Email. >=20 > And sorry for I have missed your request! Don't worry! :) I've just fixed the Clang problem you reported earlier (thanks to rakuco@'s= =20 patch), but your last log shows a different problem. Can you update your=20 ports tree and try again, with both compilers? =2D-=20 Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla How sharper than a serpent's tooth is a sister's "See?" -- Linus Van Pelt --nextPart1334517.H57WOesY1B Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iJwEAAECAAYFAk8tb+AACgkQ3xiC6kQ1CouPYgP6A7g8ZcuFnzXq0b0PTKoTH2RW xQwqEaKbpg6iOi19MaXxPEeUk7Piemi1F7oykIupkCpfB1Q2vuPJYz1P3bxJNPeo Puy7kMTezZzUtppHSwFEZ0XTIT1X2kxmhR/M7/Z4pnWlYIEpPyNn3TIA97fEJSZA 1MIcTOBtt8oC/gX77G4= =UlAi -----END PGP SIGNATURE----- --nextPart1334517.H57WOesY1B-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 4 17:50:35 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 975F11065670 for ; Sat, 4 Feb 2012 17:50:35 +0000 (UTC) (envelope-from dlt@mebtel.net) Received: from mail960c35.nsolutionszone.com (mail960c35.nsolutionszone.com [209.235.152.150]) by mx1.freebsd.org (Postfix) with ESMTP id 3DE148FC0C for ; Sat, 4 Feb 2012 17:50:34 +0000 (UTC) X-POP-User: dlt.mebtel.net Received: from localhost (99-194-23-158.dyn.centurytel.net [99.194.23.158]) by mail960c35.nsolutionszone.com (8.13.6/8.13.1) with ESMTP id q14HoWrU004569; Sat, 4 Feb 2012 17:50:33 GMT Date: Sat, 4 Feb 2012 12:50:31 -0500 From: Derek Tattersall To: Gary Jennejohn Message-ID: <20120204175031.GA1995@oriental.arm.org> References: <20120203143438.GA2798@oriental.arm.org> <20120203185053.GA11019@oriental.arm.org> <20120204045839.05be4572@ernst.jennejohn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120204045839.05be4572@ernst.jennejohn.org> User-Agent: Mutt/1.4.2.3i X-CSC: 0 X-CHA: v=1.1 cv=4CGYjw/oV8PEeB5vew+vapoQn2uFUEWZZ0PAoVqqWoY= c=1 sm=1 a=z1TLwsU0kBEA:10 a=AOmNu5pVU98A:10 a=P2oOn6vrs4wA:10 a=GPr01A5e9VcA:10 a=kj9zAlcOel0A:10 a=5FSmvsqyZ8dLHOg+TByL6Q==:17 a=mK_AVkanAAAA:8 a=xwPayol1AAAA:8 a=pGLkceISAAAA:8 a=CjxXgO3LAAAA:8 a=QqZf8GRMlE7Vur2LoHMA:9 a=CjuIK1q_8ugA:10 a=9xyTavCNlvEA:10 a=0Ob1RWNGeVAA:10 a=MSl-tDqOz04A:10 a=rC2wZJ5BpNYA:10 a=5FSmvsqyZ8dLHOg+TByL6Q==:117 X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A020201.4F2D6FE9.0084,ss=1,re=0.000,fgs=0 Cc: Ryan Stone , current@freebsd.org Subject: Re: Can't umount a formerly mounted drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dlt@mebtel.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 17:50:35 -0000 * Gary Jennejohn [120204 06:24]: > On Fri, 3 Feb 2012 13:50:53 -0500 > Derek Tattersall wrote: > > > * Ryan Stone [120203 13:41]: > > > On Fri, Feb 3, 2012 at 9:34 AM, Derek Tattersall wrote: > > > > I have two drives in a x86-64 machine. ?Drive ada2 has current on it, and > > > > drive ada1 has 9-stable on it. ?At some point, while running current, I > > > > mounted the /home partition from stable to copy some files and re-ipled > > > > the system into stable. ?every thing worked properly. ?Some time later I > > > > ipled current again. ?I then noticed that the stable /home was mounted > > > > on /mnt. ?I tried to umount it but the operation failed as /dev/ada1p7 > > > > was not considered mounted. ?Yet with out mounting I could access all > > > > the files on stable's /home, I could create and delete files. > > > > > > > > The current system was cvsup'ed on Wednesday this week, while the stable > > > > system was cvsup'ed last Sunday. ?Neither system has exhibited any > > > > hiccups. ?Can somebody explain what has happened her on the current > > > > system and how it should be corrected? > > > > > > Does "mount" list anything as being mounted on /mnt? If not, are you > > > sure that /mnt isn't a symlink to somewhere else? Or maybe the > > > contents of the home directory were copied to /mnt by accident? > > mount command on the current system does not list anything under /mnt. > > ls /mnt on the current system list the top level directories on ada1p7, > > the stable /home. It lists them as soon as a user logs in on a newly > > booted current system. It's really frustrating. > > > > Well, it certainly looks like Ryan's suggestion that files from /home were > copied to /mnt (with nothing mounted on it) is correct. > > Try mounting /home to a different location, like /mnt1, and compare the > dates on the suspicious files. Wouldn't surprise me to find that they > differ. > > -- > Gary Jennejohn You and Ryan are absolutely right - the problem was my looking for a complicated answer. I can't quite figure how I copied the whole file system but that's what I did. Thanks for pointing out my incorrect direction. -- Best regards, Derek Tattersall dlt@mebtel.net dlt666@yahoo.com dtatters@gmail.com From owner-freebsd-current@FreeBSD.ORG Sat Feb 4 20:42:25 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AE65106564A for ; Sat, 4 Feb 2012 20:42:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id CC8638FC0A for ; Sat, 4 Feb 2012 20:42:23 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q14KgIYY042364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Feb 2012 22:42:18 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q14KgIKg046786; Sat, 4 Feb 2012 22:42:18 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q14KgIpR046785; Sat, 4 Feb 2012 22:42:18 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 4 Feb 2012 22:42:18 +0200 From: Konstantin Belousov To: Dmitry Mikulin Message-ID: <20120204204218.GC3283@deviant.kiev.zoral.com.ua> References: <749E238A-A85F-4264-9DEB-BCE1BBD21C9D@juniper.net> <20120125074824.GD2726@deviant.kiev.zoral.com.ua> <4F2094B4.70707@juniper.net> <20120126122326.GT2726@deviant.kiev.zoral.com.ua> <4F22E8FD.6010201@juniper.net> <20120129074843.GL2726@deviant.kiev.zoral.com.ua> <4F26E0D1.8040100@juniper.net> <20120130192727.GZ2726@deviant.kiev.zoral.com.ua> <4F2C756A.80900@juniper.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JQcTy30AFu/Rhea+" Content-Disposition: inline In-Reply-To: <4F2C756A.80900@juniper.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current Current , Marcel Moolenaar Subject: Re: [ptrace] please review follow fork/exec changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 20:42:25 -0000 --JQcTy30AFu/Rhea+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 03, 2012 at 04:01:46PM -0800, Dmitry Mikulin wrote: >=20 > >Please provide more details, I am looking forward for the panic > >message and backtrace. >=20 > I can't seem to get the panic with the latest source base, but tracing=20 > doesn't appear to work with vfork(). I attached a modified test case to= =20 > closer model what gdb is doing. If you change fork() to vfork() in simple= .c=20 > the parent doesn't get the events the same way it does under fork(). I see what is going on. The wait loop for P_PPWAIT in do_fork() simply do not allow the ptracestop() in the syscall return path to be reached. There seems to be more problems. In particular, I do not see anything which would prevent the child from being reapped while the loop is executing (assume that the parent is multithreaded and other thread processed SIGCHLD and called wait). Lets deal with these bugs after your proposal for interface changes is dealt with. >=20 > >The lack of the notification for parent is exactly what the patch I > >posted fixes. More exactly, it is the lack of notification for parent > >with PT_CONTINUE loop. I will commit this today. > > > >Regarding a single notification. Currently, parent arrives at the > >syscall return code only after the child is attached to the debugger. > >See the cv_wait() in kern_fork.c:739. In other words, if you get the > >PL_FLAG_FORK, the child is already attached (at last it shall be). My > >scescx.c code illustrates this well, IMO. > > > >You still get a separate stop from the child, but I do not see how is it > >harmful. >=20 > There a couple of tweaks to the interface that I'd like to have: > - set PL_FLAG_FORKED in the child so gdb can identify the stop as a fork(= )=20 > event. > - add a switch similar to PT_FOLLOW_FORK to enable/disable exec()=20 > notifications. Gdb gets confused by the events it hasn't explicitly asked= =20 > for and having a switch makes it easier to filter out unwanted stops. >=20 > Do you think it's possible/makes sense? Yes, I agree with the proposal to add flag to the child lwp info. I think it will be easier if the flag is different from PL_FLAG_FORKED. I named it PL_FLAG_CHILD. PT_FOLLOW_EXEC is easy to implement, but my question is, how can debugger operate (correctly) if it ignores exec events ? After exec, the whole cached state of the debuggee must be invalidated, and since debugger ignores the notification when the invalidation shall be done, it probably gets very confused. Anyway, below is the combined patch that adds PL_FLAG_CHILD and PT_FOLLOW_EXEC. If you agree with this, I will commit them (separately). diff --git a/sys/kern/kern_exec.c b/sys/kern/kern_exec.c index 135f798..c756777 100644 --- a/sys/kern/kern_exec.c +++ b/sys/kern/kern_exec.c @@ -889,7 +889,8 @@ exec_fail_dealloc: =20 if (error =3D=3D 0) { PROC_LOCK(p); - td->td_dbgflags |=3D TDB_EXEC; + if ((p->p_flag & P_NOFOLLOWEXEC) =3D=3D 0) + td->td_dbgflags |=3D TDB_EXEC; PROC_UNLOCK(p); =20 /* diff --git a/sys/kern/kern_fork.c b/sys/kern/kern_fork.c index 60639c9..e447c93 100644 --- a/sys/kern/kern_fork.c +++ b/sys/kern/kern_fork.c @@ -1035,7 +1035,9 @@ fork_return(struct thread *td, struct trapframe *fram= e) p->p_oppid =3D p->p_pptr->p_pid; proc_reparent(p, dbg); sx_xunlock(&proctree_lock); + td->td_dbgflags |=3D TDB_CHILD; ptracestop(td, SIGSTOP); + td->td_dbgflags &=3D ~TDB_CHILD; } else { /* * ... otherwise clear the request. diff --git a/sys/kern/sys_process.c b/sys/kern/sys_process.c index 4510380..f58039a 100644 --- a/sys/kern/sys_process.c +++ b/sys/kern/sys_process.c @@ -660,6 +660,7 @@ kern_ptrace(struct thread *td, int req, pid_t pid, void= *addr, int data) case PT_TO_SCX: case PT_SYSCALL: case PT_FOLLOW_FORK: + case PT_FOLLOW_EXEC: case PT_DETACH: sx_xlock(&proctree_lock); proctree_locked =3D 1; @@ -873,6 +874,12 @@ kern_ptrace(struct thread *td, int req, pid_t pid, voi= d *addr, int data) else p->p_flag &=3D ~P_FOLLOWFORK; break; + case PT_FOLLOW_EXEC: + if (data) + p->p_flag &=3D ~P_NOFOLLOWEXEC; + else + p->p_flag |=3D P_NOFOLLOWEXEC; + break; =20 case PT_STEP: case PT_CONTINUE: @@ -936,7 +943,8 @@ kern_ptrace(struct thread *td, int req, pid_t pid, void= *addr, int data) p->p_sigparent =3D SIGCHLD; } p->p_oppid =3D 0; - p->p_flag &=3D ~(P_TRACED | P_WAITED | P_FOLLOWFORK); + p->p_flag &=3D ~(P_TRACED | P_WAITED | P_FOLLOWFORK | + P_NOFOLLOWEXEC); =20 /* should we send SIGCHLD? */ /* childproc_continued(p); */ @@ -1145,6 +1153,8 @@ kern_ptrace(struct thread *td, int req, pid_t pid, vo= id *addr, int data) pl->pl_flags |=3D PL_FLAG_FORKED; pl->pl_child_pid =3D td2->td_dbg_forked; } + if (td2->td_dbgflags & TDB_CHILD) + pl->pl_flags |=3D PL_FLAG_CHILD; pl->pl_sigmask =3D td2->td_sigmask; pl->pl_siglist =3D td2->td_siglist; strcpy(pl->pl_tdname, td2->td_name); diff --git a/sys/sys/proc.h b/sys/sys/proc.h index 76f3355..91bc86e 100644 --- a/sys/sys/proc.h +++ b/sys/sys/proc.h @@ -384,6 +384,7 @@ do { \ process */ #define TDB_STOPATFORK 0x00000080 /* Stop at the return from fork (child only) */ +#define TDB_CHILD 0x00000100 /* New child indicator for ptrace() */ =20 /* * "Private" flags kept in td_pflags: @@ -613,6 +614,7 @@ struct proc { #define P_HWPMC 0x800000 /* Process is using HWPMCs */ =20 #define P_JAILED 0x1000000 /* Process is in jail. */ +#define P_NOFOLLOWEXEC 0x2000000 /* Do not report execs with ptrace. */ #define P_INEXEC 0x4000000 /* Process is in execve(). */ #define P_STATCHILD 0x8000000 /* Child process stopped or exited. */ #define P_INMEM 0x10000000 /* Loaded into memory. */ diff --git a/sys/sys/ptrace.h b/sys/sys/ptrace.h index 2583d59..05c758c 100644 --- a/sys/sys/ptrace.h +++ b/sys/sys/ptrace.h @@ -64,6 +64,7 @@ #define PT_SYSCALL 22 =20 #define PT_FOLLOW_FORK 23 +#define PT_FOLLOW_EXEC 24 =20 #define PT_GETREGS 33 /* get general-purpose registers */ #define PT_SETREGS 34 /* set general-purpose registers */ @@ -106,7 +107,8 @@ struct ptrace_lwpinfo { #define PL_FLAG_SCX 0x08 /* syscall leave point */ #define PL_FLAG_EXEC 0x10 /* exec(2) succeeded */ #define PL_FLAG_SI 0x20 /* siginfo is valid */ -#define PL_FLAG_FORKED 0x40 /* new child */ +#define PL_FLAG_FORKED 0x40 /* child born */ +#define PL_FLAG_CHILD 0x80 /* I am from child */ sigset_t pl_sigmask; /* LWP signal mask */ sigset_t pl_siglist; /* LWP pending signal */ struct __siginfo pl_siginfo; /* siginfo for signal */ --JQcTy30AFu/Rhea+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk8tmCkACgkQC3+MBN1Mb4h+UACfafFIz2TEj7aLvUsa9iNFpkL1 KOUAoM7eOMYUntzhYZMqBQVVI/a73dPV =dYNp -----END PGP SIGNATURE----- --JQcTy30AFu/Rhea+--