From owner-freebsd-current@FreeBSD.ORG Sun Nov 9 20:23:15 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5744E1B; Sun, 9 Nov 2014 20:23:15 +0000 (UTC) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A899E69C9F; Sun, 9 Nov 2014 20:23:15 +0000 (UTC) Received: by mail-ob0-f169.google.com with SMTP id va2so4797005obc.28 for ; Sun, 09 Nov 2014 12:23:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2ruNSKioQyDPIIvdiLlyJ0gfWNzUdbk/HE5KRaOowDQ=; b=LG+vLVgCrcOkaH5jDCQzz1yz3nDxNuiaYpbPpQBkNVW0TlXD1DlPcerEFrqNV1Ooo6 2dK/27cLiEs7ZVaACK0qrh1VvNog+H2qvsttI7B2+Cm/jg53Htb6CAc7Cv3tD8ziRgC4 9j15oqbuD5YEpncD0GUZtvtjnc65Xs+xT1CcV2JS82CC1AZ8k3C1qc0C2LpL6EPvPyCa /UoZQ+kiS2sJ6et7GgTdWuvahnnZsEaeJmQJFNpsSfd7VtjLsaNJ4WcJdqZY9J+epmXm +tn4pGSvxmy8OrUcYMsYzlOZgN/KPy8aCm1Ytr4ozVz3G7t63MeuMnw3b+cSrLZR2TKF 00bw== MIME-Version: 1.0 X-Received: by 10.202.203.149 with SMTP id b143mr3663845oig.60.1415564595029; Sun, 09 Nov 2014 12:23:15 -0800 (PST) Received: by 10.182.74.5 with HTTP; Sun, 9 Nov 2014 12:23:14 -0800 (PST) In-Reply-To: <20141107212639.2e3e71e5@hermann.walstatt.dynvpn.de> References: <20141107212639.2e3e71e5@hermann.walstatt.dynvpn.de> Date: Mon, 10 Nov 2014 00:23:14 +0400 Message-ID: Subject: Re: CURRENT breaks build of x11/nvidia-driver: pkg-static: nvidia-driver-343.22 conflicts with libEGL-10.3.2 From: Mikhail Tsatsenko To: "O. Hartmann" Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Sun, 09 Nov 2014 20:44:18 +0000 Cc: FreeBSD CURRENT , FreeBSD Ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 09 Nov 2014 20:23:16 -0000 2014-11-07 23:26 GMT+03:00 O. Hartmann : > Out of the blue the build of port x11/nvidia-driver fails - portmaster is that sloppy > that it can not check BEFORE it kills the existent driver and fails to install after the > deletion! > > The src tree is at Revision: 274250 and with Revision r274177 the build works. The > failure is: > > ===> Registering installation for nvidia-driver-343.22 > pkg-static: nvidia-driver-343.22 conflicts with libEGL-10.3.2 (installs files into the > same place). Problematic file: /usr/local/lib/libEGL.so To use these drivers, make sure > that you have loaded the NVidia kernel module, by doing > > [...] > > Please can someone fix this? I have three boxes now without graphics due to this. > > Regards, > > Oliver I had exactly the same problem with latest nvidia-driver port. For now I deinstalled both libglesv2 and libEGL with pkg delete -f after that I was able to install nvidia-driver. -- Mikhail From owner-freebsd-current@FreeBSD.ORG Sun Nov 9 20:56:39 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 85D63B15 for ; Sun, 9 Nov 2014 20:56:39 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 458BC69FE5 for ; Sun, 9 Nov 2014 20:56:38 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 70D5A1FE022; Sun, 9 Nov 2014 21:56:35 +0100 (CET) Message-ID: <545FD514.5060009@selasky.org> Date: Sun, 09 Nov 2014 21:56:52 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Marc UBM , current@freebsd.org Subject: Re: pkg 1.4 freeze please test test test! References: <20141028231933.GG26796@ivaldir.etoilebsd.net> <20141101161332.b9c8fc19bf9fc54f73bc5c00@gmail.com> <20141101224549.GG15967@ivaldir.etoilebsd.net> <20141108141723.d4ee23901414d619e13fade0@gmail.com> In-Reply-To: <20141108141723.d4ee23901414d619e13fade0@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 09 Nov 2014 20:56:39 -0000 Hi, Not sure why "pkg upgrade" stopped after #45. Maybe the error code below is incorrect or should not cause a halt? [45/128] Installing linux-c6-hicolor-icon-theme-0.5: 0% pkg: archive_read_extract(): Can't remove already-existing dir [45/128] Installing linux-c6-hicolor-icon-theme-0.5: 100% [45/128] Installing linux-c6-hicolor-icon-theme-0.5: 100% xxx# Solved it by manually going into the /usr/ports and installing the port in question. --HPS From owner-freebsd-current@FreeBSD.ORG Sun Nov 9 21:15:59 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C97728D for ; Sun, 9 Nov 2014 21:15:59 +0000 (UTC) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 23EA72D1 for ; Sun, 9 Nov 2014 21:15:59 +0000 (UTC) Received: by mail-vc0-f171.google.com with SMTP id id10so36088vcb.2 for ; Sun, 09 Nov 2014 13:15:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=5jwajaLbgYCAPbb+TyVqrqNEGysmJVh8S6i4DBv+pJw=; b=iQQD/84QykVotRinXJSkEQZ42sG2giqgZ586VaUemwNt3hkZYbNCTrS4/mUXXqgSz2 Tjf3qYFzfN5QS8AfQ9nMjgrqKeMAv+Y0/seIWiGTlGxIjTLTRUpvCbU2DLAwC98/AlgK JefdASIxC6O+klaiOv4plPM8wl7+hIKvbejfRKi2XWUSdlwft8knEku2fj2SomR5dzdD 52H1r1dLk87RSX8+57l0ux+1mVcXV7doq7ABT1pZAjJaVmEP+lModofiepwPb58rOelH 96y2y05aanOMKLPC8lG+ZIW2AquzoRRIUxSGun/gkAtsN2K8KZ4yK9FRczCZx1OO9SC8 Kb8w== X-Received: by 10.52.234.230 with SMTP id uh6mr15145227vdc.10.1415567757959; Sun, 09 Nov 2014 13:15:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.136.76 with HTTP; Sun, 9 Nov 2014 13:15:17 -0800 (PST) From: Henry Hu Date: Sun, 9 Nov 2014 16:15:17 -0500 Message-ID: Subject: Fatal trap 12 in fuse_vnop_create and patch To: FreeBSD CURRENT Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 09 Nov 2014 21:15:59 -0000 Hi, I've hit a crash in the fuse module when doing a rsync to an ntfs volume mounted with ntfs-3g. The crash is the same as ones reported before, in https://lists.freebsd.org/pipermail/freebsd-current/2013-October/045993.htm= l and there are other similar reports: http://www.bsdforen.de/threads/probleme-mit-rsync-und-sshfs.29323/ After digging it a bit, I found that the problem is in fuse_vnop_create(). Check https://github.com/freebsd/freebsd/blame/master/sys/fs/fuse/fuse_vnops.c#L3= 37 . At line 337, it checks if vap->va_type is VREG, and if it is not, it goes to label bringup. Then, feo is assigned with fdip->answ and used. But fdip which points to fdi is initialized after the goto. As a result, when vap->va_type !=3D VREG= , fdi is not initialized and feo is invalid. I made the following patch and it works for me. In my case, the problematic file is a socket. Index: fuse_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- fuse_vnops.c (=E7=89=88=E6=9C=AC 274059) +++ fuse_vnops.c (=E5=B7=A5=E4=BD=9C=E5=89=AF=E6=9C=AC) @@ -336,7 +336,8 @@ /* XXX: Will we ever want devices ? */ if ((vap->va_type !=3D VREG)) { MPASS(vap->va_type !=3D VFIFO); - goto bringup; + printf("unsupported vatype: %d\n", vap->va_type); + return EINVAL; } debug_printf("parent nid =3D %ju, mode =3D %x\n", (uintmax_t)parent= nid, mode); @@ -364,7 +365,7 @@ debug_printf("create: got err=3D%d from daemon\n", err); goto out; } -bringup: + feo =3D fdip->answ; if ((err =3D fuse_internal_checkentry(feo, VREG))) { But I think that fuse filesystems may support file types other than VREG, so maybe we should remove that check completely? --=20 Cheers, Henry From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 01:45:44 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E5D1A2B; Mon, 10 Nov 2014 01:45:44 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 02A2E8B; Mon, 10 Nov 2014 01:45:43 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 9629E7300A; Mon, 10 Nov 2014 02:49:39 +0100 (CET) Date: Mon, 10 Nov 2014 02:49:39 +0100 From: Luigi Rizzo To: current@freebsd.org Subject: dev_lock() contention for fdesc syscalls -- possible fix Message-ID: <20141110014939.GA21626@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: jmg@freebsd.org, gnn@freebsd.org, adrian@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 10 Nov 2014 01:45:44 -0000 It was noticed that there is huge dev_lock() contention when multiple processes do a poll() even on independent file descriptors. Turns out that not just poll but most syscalls on file descriptors (as opposed to sockets) in sys/fs/devfs/devfs_vnops.c including devfs_poll_f(), devfs_ioctl_f() and read/write share the problem as they use the following pattern devfs_poll_f() { ... devfs_fp_check(fp, ...) --> kern/kern_conf.c :: devvn_refthread(fp->f_vnode, ...) --> dev_lock(); dev = vp->v_rdev; // lock on vp ? ... check that dev != NULL atomic_add_long(&dev->si_threadcount, 1); dev_unlock(); dsw->d_poll() dev_relthread() --> atomic_subtract_rel_long(&dev->si_threadcount, 1); } I believe that dev_lock() in devvn_refthread() is protecting dev = vp->v_rdev (the cdev entry 'dev' cannot go away for the reasons stated below). However looking at places where vp->v_rdev is modified, turns out that it only happens when holding VI_LOCK(vp) -- the places are devfs_allocv() and devfs_reclaim(). There is one place in zfs where the vnode is created and v_rdev is set without holding a lock, so nobody can dereference it. As a consequence i believe that if in devfs_fp_check() we replace dev_lock() / dev_unlock() with VI_LOCK(vp) / VI_UNLOCK(vp), we make sure that we can safely dereference vp->v_rdev, and the cdev cannot go away because the vnode has a reference to it. The counter uses an atomic instruction (so the release is lockless) This should be enough to remove the contention. Anyone care to review/test the patch below ? (dev_refthread() still has the single dev_lock() contention, i don't know how to address that yet) cheers luigi Index: /home/luigi/FreeBSD/head/sys/kern/kern_conf.c =================================================================== --- /home/luigi/FreeBSD/head/sys/kern/kern_conf.c (revision 273452) +++ /home/luigi/FreeBSD/head/sys/kern/kern_conf.c (working copy) @@ -224,10 +224,11 @@ } csw = NULL; - dev_lock(); + ASSERT_VI_UNLOCKED(vp, __func__); + VI_LOCK(vp); // dev_lock(); dev = vp->v_rdev; if (dev == NULL) { - dev_unlock(); + VI_UNLOCK(vp); // dev_unlock(); return (NULL); } cdp = cdev2priv(dev); @@ -236,7 +237,7 @@ if (csw != NULL) atomic_add_long(&dev->si_threadcount, 1); } - dev_unlock(); + VI_UNLOCK(vp); // dev_unlock(); if (csw != NULL) { *devp = dev; *ref = 1; From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 04:35:54 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25052E5B; Mon, 10 Nov 2014 04:35:54 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 89310372; Mon, 10 Nov 2014 04:35:53 +0000 (UTC) Received-SPF: pass (freebsd.czest.pl: domain of wkoszek@freebsd.czest.pl designates 212.87.224.105 as permitted sender) receiver=freebsd.czest.pl; client-ip=212.87.224.105; helo=freebsd.czest.pl; envelope-from=wkoszek@freebsd.czest.pl; x-software=spfmilter 0.97 http://www.acme.com/software/spfmilter/ with libspf-unknown; Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id sAA3xFTu052281; Mon, 10 Nov 2014 03:59:15 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id sAA3xFgl052280; Mon, 10 Nov 2014 03:59:15 GMT (envelope-from wkoszek) Date: Mon, 10 Nov 2014 03:59:15 +0000 From: "Wojciech A. Koszek" To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: FreeBSD + Google Code-In 2014 = we need ideas. Message-ID: <20141110035915.GA50986@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD, SPF_HELO_PASS,SPF_PASS,URIBL_DBL_REDIR autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on freebsd.czest.pl X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Mon, 10 Nov 2014 03:59:21 +0000 (UTC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 10 Nov 2014 04:35:54 -0000 Hello, This year we'd like to participate in the Google Code-In 2014. This is Google Summer of Code, but for younger people: age range is 13--17. If you're one of them, we highly encourage you to apply! ***This year coding tasks are possible, so feel free to add those*** To submit idea which you'd like to see done in GCI, visit: http://bit.ly/FreeBSD_GCIN2014 Regardless of who you are, please use the form to submit ideas. Don't add stuff via Wiki, since this year we'll do direct import of all ideas from Google Forms. To see tasks from previous year that are yet to be copied to Google Forms: https://wiki.freebsd.org/GoogleCodeIn/2014Tasks Thanks to GCI in the previous years, we gained one more FreeBSD developer. We'd like to partcipate this year too. We need: 1) ideas. 2) mentors 3) participants. Just like in previous years we'll decide whether we're ready. Deadlines: --- November 12, 2014 - The 10-12 Mentoring organizations are announced for Google Code-in 2014 and the orgs can start entering their tasks into the Google system (the tasks will not be viewable to students until the contest opens on Dec 1). December 1, 2014 17:00 UTC - Google Code-in 2014 contest opens for students January 19, 2015 17:00 UTC - Google Code-in 2014 student work ends --- MORE INFO: [0] http://www.google-melange.com/gci/homepage/google/gci2014 [1] gci-mentors@googlegroups.com [2] https://developers.google.com/open-source/gci/resources/mentor-and-orgadmin-info -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 07:44:03 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9A3CA88 for ; Mon, 10 Nov 2014 07:44:03 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CF57A9A for ; Mon, 10 Nov 2014 07:44:02 +0000 (UTC) Received: from mandree.no-ip.org ([78.48.81.14]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Ltqmn-1XxwMA0jLR-011ETZ for ; Mon, 10 Nov 2014 08:43:55 +0100 Received: from [IPv6:::1] (localhost6.localdomain6 [IPv6:::1]) by apollo.emma.line.org (Postfix) with ESMTP id 89E5123D16D for ; Mon, 10 Nov 2014 08:43:53 +0100 (CET) Message-ID: <54606CB9.4070305@gmx.de> Date: Mon, 10 Nov 2014 08:43:53 +0100 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: pkg 1.4 freeze please test test test! References: <20141028231933.GG26796@ivaldir.etoilebsd.net> <20141101161332.b9c8fc19bf9fc54f73bc5c00@gmail.com> <20141101224549.GG15967@ivaldir.etoilebsd.net> <20141102102455.30d42f85ff81e079788eae06@gmail.com> <5457F64F.6090408@selasky.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:0+MVdayQSSSW/PJhvgUaKb0zFi2oH4z8bV/JCJe2VGQkdsUNop6 jx80l6jfkGDajPbnW4goUhHz7X0jQcQjEmAalnPicTJt0bRogaRZEHKrSHFsz4QLajwNlbX v8ajRR8bgFuj4OVFw23VlFD9Ret4iihZwX2a5f8Hy1m8fQaqndsQtX1FGDITLkq5LPCvDe8 io9fNE75IFDAfmxDkFlzA== X-UI-Out-Filterresults: notjunk:1; X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 10 Nov 2014 07:44:03 -0000 Am 03.11.2014 um 22:48 schrieb Freddie Cash: > On Mon, Nov 3, 2014 at 1:40 PM, Hans Petter Selasky w= rote: >=20 >> Is it possible when upgrading a system via "pkg" to selectivly switch >> upgrades ON/OFF. For example I have a custom ffmpeg install and would = like >> to keep it every time I do a binary upgrade? >> >=20 >=20 > =E2=80=8B# man pkg-lock >=20 > ;) >=20 > I believe that's what you are looking for.=E2=80=8B No idea how well i= t works > long-term, though, or if you lock a large number of packages. It used to refuse portmaster upgrades of a locked port and was thus useless for mixed binary packages + portmaster use. I haven't yet checked if pkg 1.4 has fixed this. From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 07:54:06 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9EA5CC1C for ; Mon, 10 Nov 2014 07:54:06 +0000 (UTC) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 70EC4B81 for ; Mon, 10 Nov 2014 07:54:06 +0000 (UTC) Received: by mail-ig0-f182.google.com with SMTP id hn18so8652742igb.15 for ; Sun, 09 Nov 2014 23:54:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Hml93ziHmDclI2LZ+BtEHip194jcGPB85pVwTGUDpYw=; b=sIspB5wPffiouKrajjGN1xG3yIekABcEKCLpG1ZOhqYlzPPgRJzlVS+i4CCax90bEa xshPVAQ0DwZ9SVdYwiFA9ViOJu+gsjHHrSCQq+aj//U9ydQC3oD8xALAJVe2K0l5bRc8 b6P8EmwTVEdlNj22FrIfGxJB/UJqupn1rWoN+GeYe9uY9bvI2y9LLDo5bdwWmc+r8aFR rNzq9hefJNdpNygS8h6yFb2GMY3yKtUGY/B2GBjbMYhTEntn4RwpOwXl4ThWjdZHuqhe DaVtbKnjmLnna0zEtL4oaUixAi/GWELFAl/08xFn7p07d5wZPiPqc/O/03U6vYaJI/NT 7oMw== MIME-Version: 1.0 X-Received: by 10.42.126.196 with SMTP id f4mr167022ics.91.1415606045791; Sun, 09 Nov 2014 23:54:05 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.107.11.152 with HTTP; Sun, 9 Nov 2014 23:54:05 -0800 (PST) In-Reply-To: <54606CB9.4070305@gmx.de> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> <20141101161332.b9c8fc19bf9fc54f73bc5c00@gmail.com> <20141101224549.GG15967@ivaldir.etoilebsd.net> <20141102102455.30d42f85ff81e079788eae06@gmail.com> <5457F64F.6090408@selasky.org> <54606CB9.4070305@gmx.de> Date: Sun, 9 Nov 2014 23:54:05 -0800 X-Google-Sender-Auth: 9WvGQTIk53xH8P_TOrIUExJ814A Message-ID: Subject: Re: pkg 1.4 freeze please test test test! From: Kevin Oberman To: Matthias Andree Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 10 Nov 2014 07:54:06 -0000 On Sun, Nov 9, 2014 at 11:43 PM, Matthias Andree wrote: > Am 03.11.2014 um 22:48 schrieb Freddie Cash: > > On Mon, Nov 3, 2014 at 1:40 PM, Hans Petter Selasky > wrote: > > > >> Is it possible when upgrading a system via "pkg" to selectivly switch > >> upgrades ON/OFF. For example I have a custom ffmpeg install and would > like > >> to keep it every time I do a binary upgrade? > >> > > > > > > =E2=80=8B# man pkg-lock > > > > ;) > > > > I believe that's what you are looking for.=E2=80=8B No idea how well i= t works > > long-term, though, or if you lock a large number of packages. > > It used to refuse portmaster upgrades of a locked port and was thus > useless for mixed binary packages + portmaster use. I haven't yet > checked if pkg 1.4 has fixed this. > I don't think that this is considered to be a bug, so it is not fixed. Easy work-around: pkg unlock PACKAGE portmaster PACKAGE pkg lock PACKAGE Personally I would prefer if portmaster did the unlock and lock, perhaps tied to an option, but it's not a big issue as far as I can see. Just an annoyance. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 08:35:05 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D778554; Mon, 10 Nov 2014 08:35:05 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8AFA3F64; Mon, 10 Nov 2014 08:35:04 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sAA8Ywaa067894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Nov 2014 10:34:58 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sAA8Ywaa067894 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sAA8YvGd067893; Mon, 10 Nov 2014 10:34:57 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 10 Nov 2014 10:34:57 +0200 From: Konstantin Belousov To: Luigi Rizzo Subject: Re: dev_lock() contention for fdesc syscalls -- possible fix Message-ID: <20141110083457.GD53947@kib.kiev.ua> References: <20141110014939.GA21626@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141110014939.GA21626@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: jmg@freebsd.org, gnn@freebsd.org, adrian@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 10 Nov 2014 08:35:05 -0000 On Mon, Nov 10, 2014 at 02:49:39AM +0100, Luigi Rizzo wrote: > It was noticed that there is huge dev_lock() contention when multiple > processes do a poll() even on independent file descriptors. > > Turns out that not just poll but most syscalls on file descriptors > (as opposed to sockets) in sys/fs/devfs/devfs_vnops.c including > devfs_poll_f(), devfs_ioctl_f() and read/write share the problem > as they use the following pattern > > devfs_poll_f() { > ... > devfs_fp_check(fp, ...) --> > kern/kern_conf.c :: devvn_refthread(fp->f_vnode, ...) --> > dev_lock(); > dev = vp->v_rdev; // lock on vp ? > ... check that dev != NULL > atomic_add_long(&dev->si_threadcount, 1); > dev_unlock(); > dsw->d_poll() > dev_relthread() --> > atomic_subtract_rel_long(&dev->si_threadcount, 1); > } > > > I believe that dev_lock() in devvn_refthread() is protecting > dev = vp->v_rdev > (the cdev entry 'dev' cannot go away for the reasons stated below). > > However looking at places where vp->v_rdev is modified, turns out > that it only happens when holding VI_LOCK(vp) -- the places are > devfs_allocv() and devfs_reclaim(). > There is one place in zfs where the vnode is created and v_rdev > is set without holding a lock, so nobody can dereference it. > > As a consequence i believe that if in devfs_fp_check() we replace > dev_lock() / dev_unlock() with VI_LOCK(vp) / VI_UNLOCK(vp), > we make sure that we can safely dereference vp->v_rdev, and the > cdev cannot go away because the vnode has a reference to it. > The counter uses an atomic instruction (so the release is lockless) Vnode reference, as well as cdev reference, which is obtained by dev_ref(), do not provide any protection there. v_rdev is only coincidentally protected by the vnode interlock. If you look at larger part of the code, you would note that dev mutex is held even after v_rdev is dereferenced. The real protection it provides is against race with destroy_dev(l)(), which could invalidate dev->so_devsw at any moment when either device thread reference is not held, or dev mutex is not held. So your patch breaks the device destruction. > > This should be enough to remove the contention. If you never calls destroy_dev() for the devfs node, you could use MAKEDEV_ETERNAL flag for make_dev_credf(), which indicates that there is no risk of race with destroy_dev() for the created node. Usually, code which could be compiled in kernel statically but also loaded as module, use MAKEDEV_ETERNAL_KLD flag, which takes care of module needed to call destroy_dev(). > > Anyone care to review/test the patch below ? Yes, there are people who care. > (dev_refthread() still has the single dev_lock() contention, > i don't know how to address that yet) > > cheers > luigi > > Index: /home/luigi/FreeBSD/head/sys/kern/kern_conf.c > =================================================================== > --- /home/luigi/FreeBSD/head/sys/kern/kern_conf.c (revision 273452) > +++ /home/luigi/FreeBSD/head/sys/kern/kern_conf.c (working copy) > @@ -224,10 +224,11 @@ > } > > csw = NULL; > - dev_lock(); > + ASSERT_VI_UNLOCKED(vp, __func__); > + VI_LOCK(vp); // dev_lock(); > dev = vp->v_rdev; > if (dev == NULL) { > - dev_unlock(); > + VI_UNLOCK(vp); // dev_unlock(); > return (NULL); > } > cdp = cdev2priv(dev); > @@ -236,7 +237,7 @@ > if (csw != NULL) > atomic_add_long(&dev->si_threadcount, 1); > } > - dev_unlock(); > + VI_UNLOCK(vp); // dev_unlock(); > if (csw != NULL) { > *devp = dev; > *ref = 1; > _______________________________________________ > 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 Nov 10 09:40:11 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6DAA25DD; Mon, 10 Nov 2014 09:40:11 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id E7E3C8D5; Mon, 10 Nov 2014 09:40:10 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id BCD3A7300A; Mon, 10 Nov 2014 10:44:12 +0100 (CET) Date: Mon, 10 Nov 2014 10:44:12 +0100 From: Luigi Rizzo To: Konstantin Belousov Subject: Re: dev_lock() contention for fdesc syscalls -- possible fix Message-ID: <20141110094412.GA25189@onelab2.iet.unipi.it> References: <20141110014939.GA21626@onelab2.iet.unipi.it> <20141110083457.GD53947@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141110083457.GD53947@kib.kiev.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: jmg@freebsd.org, gnn@freebsd.org, adrian@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 10 Nov 2014 09:40:11 -0000 On Mon, Nov 10, 2014 at 10:34:57AM +0200, Konstantin Belousov wrote: > On Mon, Nov 10, 2014 at 02:49:39AM +0100, Luigi Rizzo wrote: > > It was noticed that there is huge dev_lock() contention when multiple > > processes do a poll() even on independent file descriptors. > > > > Turns out that not just poll but most syscalls on file descriptors > > (as opposed to sockets) in sys/fs/devfs/devfs_vnops.c including > > devfs_poll_f(), devfs_ioctl_f() and read/write share the problem > > as they use the following pattern > > > > devfs_poll_f() { > > ... > > devfs_fp_check(fp, ...) --> > > kern/kern_conf.c :: devvn_refthread(fp->f_vnode, ...) --> > > dev_lock(); > > dev = vp->v_rdev; // lock on vp ? > > ... check that dev != NULL > > atomic_add_long(&dev->si_threadcount, 1); > > dev_unlock(); > > dsw->d_poll() > > dev_relthread() --> > > atomic_subtract_rel_long(&dev->si_threadcount, 1); > > } > > > > > > I believe that dev_lock() in devvn_refthread() is protecting > > dev = vp->v_rdev > > (the cdev entry 'dev' cannot go away for the reasons stated below). > > > > However looking at places where vp->v_rdev is modified, turns out > > that it only happens when holding VI_LOCK(vp) -- the places are > > devfs_allocv() and devfs_reclaim(). > > There is one place in zfs where the vnode is created and v_rdev > > is set without holding a lock, so nobody can dereference it. > > > > As a consequence i believe that if in devfs_fp_check() we replace > > dev_lock() / dev_unlock() with VI_LOCK(vp) / VI_UNLOCK(vp), > > we make sure that we can safely dereference vp->v_rdev, and the > > cdev cannot go away because the vnode has a reference to it. > > The counter uses an atomic instruction (so the release is lockless) > Vnode reference, as well as cdev reference, which is obtained by > dev_ref(), do not provide any protection there. v_rdev is only > coincidentally protected by the vnode interlock. > > If you look at larger part of the code, you would note that dev mutex > is held even after v_rdev is dereferenced. The real protection it > provides is against race with destroy_dev(l)(), which could invalidate > dev->so_devsw at any moment when either device thread reference is > not held, or dev mutex is not held. So your patch breaks the > device destruction. I see. Thanks for the clarification. Would it help to rewrite the part of devvn_refthread as follows: devvn_refthread() { // protect vp->v_rdev dereference and dev disappearing VI_LOCK(vp); dev = vi->v_rdev; .. check that dev != NULL // protect the race on dev->si_devsw atomic_add_long(&dev->si_threadcount, 1); VI_UNLOCK(vp); ... appropriate memory barrier csw = dev->si_devsw; if (csw != NULL) { // we won the race, even if destroy_devl() runs // it will keep the cdevsw alive until si_threadcount goes to 0 *devp = dev; *ref = 1; } else { // we lost *ref = 0; } return csw; } i.e. tentatively increment si_threadcount before dereferencing si_devsw and then restoring it if we lose the race ? It might be necessary to add a barrier in destroy_devl() between clearing si_devsw and reading si_threadcount. > > > > This should be enough to remove the contention. > If you never calls destroy_dev() for the devfs node, you could use > MAKEDEV_ETERNAL flag for make_dev_credf(), which indicates that there > is no risk of race with destroy_dev() for the created node. > > Usually, code which could be compiled in kernel statically but also > loaded as module, use MAKEDEV_ETERNAL_KLD flag, which takes care of > module needed to call destroy_dev(). that I suppose would mean that the module cannot be safely unloaded ? cheers luigi From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 10:34:19 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD764194; Mon, 10 Nov 2014 10:34:19 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 70D88E2C; Mon, 10 Nov 2014 10:34:19 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sAAAYEMo001958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Nov 2014 12:34:14 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sAAAYEMo001958 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sAAAYDOI001957; Mon, 10 Nov 2014 12:34:13 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 10 Nov 2014 12:34:13 +0200 From: Konstantin Belousov To: Luigi Rizzo Subject: Re: dev_lock() contention for fdesc syscalls -- possible fix Message-ID: <20141110103412.GG53947@kib.kiev.ua> References: <20141110014939.GA21626@onelab2.iet.unipi.it> <20141110083457.GD53947@kib.kiev.ua> <20141110094412.GA25189@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141110094412.GA25189@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: jmg@freebsd.org, gnn@freebsd.org, adrian@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 10 Nov 2014 10:34:19 -0000 On Mon, Nov 10, 2014 at 10:44:12AM +0100, Luigi Rizzo wrote: > On Mon, Nov 10, 2014 at 10:34:57AM +0200, Konstantin Belousov wrote: > > On Mon, Nov 10, 2014 at 02:49:39AM +0100, Luigi Rizzo wrote: > > > It was noticed that there is huge dev_lock() contention when multiple > > > processes do a poll() even on independent file descriptors. > > > > > > Turns out that not just poll but most syscalls on file descriptors > > > (as opposed to sockets) in sys/fs/devfs/devfs_vnops.c including > > > devfs_poll_f(), devfs_ioctl_f() and read/write share the problem > > > as they use the following pattern > > > > > > devfs_poll_f() { > > > ... > > > devfs_fp_check(fp, ...) --> > > > kern/kern_conf.c :: devvn_refthread(fp->f_vnode, ...) --> > > > dev_lock(); > > > dev = vp->v_rdev; // lock on vp ? > > > ... check that dev != NULL > > > atomic_add_long(&dev->si_threadcount, 1); > > > dev_unlock(); > > > dsw->d_poll() > > > dev_relthread() --> > > > atomic_subtract_rel_long(&dev->si_threadcount, 1); > > > } > > > > > > > > > I believe that dev_lock() in devvn_refthread() is protecting > > > dev = vp->v_rdev > > > (the cdev entry 'dev' cannot go away for the reasons stated below). > > > > > > However looking at places where vp->v_rdev is modified, turns out > > > that it only happens when holding VI_LOCK(vp) -- the places are > > > devfs_allocv() and devfs_reclaim(). > > > There is one place in zfs where the vnode is created and v_rdev > > > is set without holding a lock, so nobody can dereference it. > > > > > > As a consequence i believe that if in devfs_fp_check() we replace > > > dev_lock() / dev_unlock() with VI_LOCK(vp) / VI_UNLOCK(vp), > > > we make sure that we can safely dereference vp->v_rdev, and the > > > cdev cannot go away because the vnode has a reference to it. > > > The counter uses an atomic instruction (so the release is lockless) > > Vnode reference, as well as cdev reference, which is obtained by > > dev_ref(), do not provide any protection there. v_rdev is only > > coincidentally protected by the vnode interlock. > > > > If you look at larger part of the code, you would note that dev mutex > > is held even after v_rdev is dereferenced. The real protection it > > provides is against race with destroy_dev(l)(), which could invalidate > > dev->so_devsw at any moment when either device thread reference is > > not held, or dev mutex is not held. So your patch breaks the > > device destruction. > > I see. Thanks for the clarification. > > Would it help to rewrite the part of devvn_refthread as follows: > > devvn_refthread() { > // protect vp->v_rdev dereference and dev disappearing > VI_LOCK(vp); > dev = vi->v_rdev; > .. check that dev != NULL > // protect the race on dev->si_devsw > atomic_add_long(&dev->si_threadcount, 1); > VI_UNLOCK(vp); > ... appropriate memory barrier > csw = dev->si_devsw; > if (csw != NULL) { > // we won the race, even if destroy_devl() runs > // it will keep the cdevsw alive until si_threadcount goes to 0 > *devp = dev; > *ref = 1; > } else { > // we lost > *ref = 0; > } > return csw; > } > > i.e. tentatively increment si_threadcount before dereferencing si_devsw > and then restoring it if we lose the race ? > It might be necessary to add a barrier in destroy_devl() between clearing > si_devsw and reading si_threadcount. Sure it is neccessary to add a barrier in destroy_devl() then. >From the first look, this might work, but how would you handle the possibility that cdev memory is already freed when you do the increment ? The vnode interlock does not protect against it; if you mean that vnode reclamation already happen and vp->v_rdev must be cleared, this might need some additional argumentation. Note that the real patch is more involved, since both dev_refthread() and devvn_refthread() should be handled. Also, there is some ugly hack in sound/clone.c. > > > > > > > This should be enough to remove the contention. > > If you never calls destroy_dev() for the devfs node, you could use > > MAKEDEV_ETERNAL flag for make_dev_credf(), which indicates that there > > is no risk of race with destroy_dev() for the created node. > > > > Usually, code which could be compiled in kernel statically but also > > loaded as module, use MAKEDEV_ETERNAL_KLD flag, which takes care of > > module needed to call destroy_dev(). > > that I suppose would mean that the module cannot be safely unloaded ? Well, you are not supposed to use MAKEDEV_ETERNAL for loadable modules at all. This is what MAKEDEV_ETERNAL_KLD ensures. From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 11:09:46 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E135ED18; Mon, 10 Nov 2014 11:09:46 +0000 (UTC) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AE51B22A; Mon, 10 Nov 2014 11:09:46 +0000 (UTC) Received: by mail-pd0-f172.google.com with SMTP id r10so7642761pdi.31 for ; Mon, 10 Nov 2014 03:09:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=DmG6EpcpVS0JH+Uu87SbsVoa35vJKRfI3fehUgTccsY=; b=d1Xbq5Cl01mPViZ1s2jIdWC0cSBqV0MVBJKNPwPjpwFUQ0u7c6J8umpWJC5cM6i5KZ nbdF2NHjGxBZe6bpbXCb3JeTb/TIXLO/o/MUN/ztk3q/b7T7obK9cvDz1zi2AFaDGPgf jO7sZ0hxYKTOHMjVnJY150CkyEMP28UIBc2ChozhdYlVbGI4ep7x8iiF7AglJkhSNy+N fp/Y5j5kJk00EqHjA8WuoX3FhXicymqLZTFVQmphl/hsVEeYc+ZyVBO6+jBSIgfDzKLc E6Ar8QSW2lYeSez59CTmB5f0MbkZGUQk83xEgc2wEcpqyYneMyD4v3QBnXgur1AemmsJ GPJQ== X-Received: by 10.70.88.44 with SMTP id bd12mr3225357pdb.133.1415617786244; Mon, 10 Nov 2014 03:09:46 -0800 (PST) Received: from kmatoMacBook-Pro.local ([221.234.44.207]) by mx.google.com with ESMTPSA id rb2sm16372602pab.5.2014.11.10.03.09.44 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Nov 2014 03:09:45 -0800 (PST) Message-ID: <54609CF4.4030407@gmail.com> Date: Mon, 10 Nov 2014 19:09:40 +0800 From: k simon User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Wojciech A. Koszek" , freebsd-current@freebsd.org Subject: Re: FreeBSD + Google Code-In 2014 = we need ideas. References: <20141110035915.GA50986@FreeBSD.org> In-Reply-To: <20141110035915.GA50986@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 10 Nov 2014 11:09:47 -0000 Hello, List, 2 ideas: 1. port DFBSD's CAM DA driver It's doing much better than FB in heavy load with random IO, eg. squid or postgres databases for zabbix 1.8. It's released within DFBSD V2.10 "CAM DA driver enhanced to separate read and write streams, allowing concurrent write completion in the face of many stalled read requests." http://leaf.dragonflybsd.org/mailarchive/commits/2011-04/msg00062.html http://leaf.dragonflybsd.org/mailarchive/commits/2011-04/msg00061.html 2. port DFBSD's swapcache ZFS is so memory hungry, I'd like use the rock UFS for most other than nfs/samba server similar application, but curreently FB has no solutions can utilize SSD to speed up UFS's performance. Maybe it's not quite new technology, but it's useful. Regards Simon From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 11:30:53 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BFC2630D; Mon, 10 Nov 2014 11:30:53 +0000 (UTC) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8284C669; Mon, 10 Nov 2014 11:30:53 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XnnBL-000K1K-PL; Mon, 10 Nov 2014 12:30:51 +0100 Date: Mon, 10 Nov 2014 12:30:51 +0100 From: Kurt Jaeger To: k simon Subject: Re: FreeBSD + Google Code-In 2014 = we need ideas. Message-ID: <20141110113051.GU66862@home.opsec.eu> References: <20141110035915.GA50986@FreeBSD.org> <54609CF4.4030407@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54609CF4.4030407@gmail.com> Cc: freebsd-current@freebsd.org, "Wojciech A. Koszek" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 10 Nov 2014 11:30:53 -0000 Hi! > 2 ideas: > > 1. port DFBSD's CAM DA driver [...] Maybe I'm showing my age here, but Code-In is for school kids aged 13-17, and in my time, there were very few kids at that task level 8-} -- pi@opsec.eu +49 171 3101372 6 years to go ! From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 12:14:33 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B341FB40; Mon, 10 Nov 2014 12:14:33 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 870C2B04; Mon, 10 Nov 2014 12:14:30 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id sAACEIUF052716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 10 Nov 2014 04:14:21 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <5460AC13.5060001@freebsd.org> Date: Mon, 10 Nov 2014 20:14:11 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: FreeBSD Current , hackers@FreeBSD.ORG Subject: samba/NSSWITCH interaction in fbsd 10 vs fbsd 8 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 10 Nov 2014 12:14:33 -0000 When I try use the libnss_winbind.so that is generated by samba 3.6 I get the following message: NSSWITCH(nss_load_module): winbind, Undefined symbol "nss_module_register". First I have to change its' name to nss_winbins.so.1 however because that is what nsswitch is looking for.... (BTW where is that documented??) then it finds it but fails as mentioned above. This same samba source generates good nss files in 8.0 but under 10 it fails.. Literally it's the same sources just checked out into a different build system. (10 vs 8). Has there been a change in the API for the nss modules? where it he API for nsswitch files documented? Julian From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 12:36:31 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6280FC5 for ; Mon, 10 Nov 2014 12:36:31 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9DF64D27 for ; Mon, 10 Nov 2014 12:36:31 +0000 (UTC) Received: from [127.0.0.1] (nat.in.devexperts.com [89.113.128.63]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 9AA4B56404 for ; Mon, 10 Nov 2014 15:36:22 +0300 (MSK) Message-ID: <5460B143.3010004@FreeBSD.org> Date: Mon, 10 Nov 2014 15:36:19 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: FreeBSD Current Subject: Changing timezone without reboot/restarting each service? Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 10 Nov 2014 12:36:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 After changing timezones in Russia (with replacing /etc/localtime with new file), I found that cron works in "old" timezone till restart. And all other services do the same, but cron is most obvious here :) Looks like libc reads timezone only once and it could not be chamged for process without restart (which leads to, effectivly, restart of whole server). Is it known problem? I think, it should be fixed somehow. I understand, that re-check timezone file on each time-related call could be expensive, though :( - -- // Lev Serebryakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUYLE/XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePaAwP/AxFm4IT8GiScZ3TQkpO/89z +LKfHU5qF45M3fRQLU3wPPtp/RYFIb5SGPRLRg9L6SmY1tppx8GlBRU/kORUPizt e9865/4p1RwOlEOJ5vxulJGxMYEjWFGB9kLnkNLgpzMK/88GmT5ntZqVIoC9wuSo fYXME7O2ZOm7Fczaiu5oH8CSlOMBNXXuaXJsuvH7WVWKOLO5XbHZd4UJbkltJQGW LEfHzLcTIU0LEzuZSVIPIzde4cGey0phO7a01XXx2+SIydU077LdV6cB2pKvTYLR t7cifOjoCWkUX/5qknoIQMrY398b6NMpQQURQoG4Uh2WvLDm5OAwYZoHfjroU2+5 7XVSrkKJd67EEw0ve84DVHWAOdtPvciNNMTVZu5z9jkFZwkVKQP7i+ct9E5g5qRq N/hiz6mUrwOfHeXKdnXBg2zc2YLlHxvhJyUc45Gi0W0MmLVMRRFPKkcVblOB5rnJ JKz5fVAXiO8VMUmTCx2TJ/YUzvsxXXkSJ0+abMviV+zACPBdaxKWb4UhEIaNdSMg hrhkd1jOWVdP83ucvXRmIoBxW9Pvfs0r249lFDTRW1PuY+P4JZLvUplvIKo5wR/X mDfeOjSy7qWq2KMVlfHh+3r2wCqRsNWy3JzaRe1npSpD+34vI+7jhPPWS7yUILQi +JB5MQZr0BRwU59Hhi6o =mE5w -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 12:36:38 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03D75148 for ; Mon, 10 Nov 2014 12:36:38 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id BE6C4D2B for ; Mon, 10 Nov 2014 12:36:37 +0000 (UTC) Received: from [127.0.0.1] (nat.in.devexperts.com [89.113.128.63]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 8B31456403 for ; Mon, 10 Nov 2014 15:36:22 +0300 (MSK) Message-ID: <5460B143.6080206@FreeBSD.org> Date: Mon, 10 Nov 2014 15:36:19 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: FreeBSD Current Subject: Changing timezone without reboot/restarting each service? Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 10 Nov 2014 12:36:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 After changing timezones in Russia (with replacing /etc/localtime with new file), I found that cron works in "old" timezone till restart. And all other services do the same, but cron is most obvious here :) Looks like libc reads timezone only once and it could not be chamged for process without restart (which leads to, effectivly, restart of whole server). Is it known problem? I think, it should be fixed somehow. I understand, that re-check timezone file on each time-related call could be expensive, though :( - -- // Lev Serebryakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUYLEoXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePW08P/1hlYiwRN7AnEjGcnMMIDmW/ jkydPH8NPHr4PrEBexIJE9+bj1UzRSqK9v1t6r8ktdX7Myph1Kb8CaM4nS8+tesS 7Wqblk/o+zHkeBOtF8J9Ar7+7ZdZWd+oG/cTAmZdlxXV1i70s1Qe2TwozO0RKCgm DHtD65jTKGUxWIliRz3GX46NnhRdOeBj+m/2dxe5s0nkP7eUknpJKBBd3IZPAUAQ 5WQvX3YbVwlE9r+pVTWFGvotKMwbmHGtJSyDrsYxyL6T2FY8+8/jl31FSLQNvlXX 9ymWjKnVIECPdRpVfQsEgp6WvRJ+xEKhyDbXCLCiOtTWX8ieJd0qZPFS4J7V87uu SwSs1OVGwfy6zSVI33QFFsp4fJzpFACxUV7YfAO/SDM+CMrGsfSCFfSyutHx1Qip 3EiVAbHKFsCdiTHRiEZfE3cg91Gp25MDWwhmePo521UTS5bI9/vg9KVFF/5QyLgl jHDMz0T8LPUernxqZilJ02vBUu1eHaznbIRgD7zQjuG2YvO5S4vh/Rdt9dbj/cRp DpIfogfEpsvTHVv7N5xWfq0zu/DTCtNtv0eIFZy8WheFb5GvHlI8IwwgVE5CuF9D 4FcIJnOU20LqQjk7LujborqwMj8ifbz48wa4xYc8/G4woKJ/Snsu3Fxdbrtmc5b4 flIOddz8QQmSn28/wOF5 =HDMD -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 14:38:08 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E9BC6B5C for ; Mon, 10 Nov 2014 14:38:08 +0000 (UTC) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B1A9EBD3 for ; Mon, 10 Nov 2014 14:38:08 +0000 (UTC) Received: by mail-ig0-f181.google.com with SMTP id l13so9964500iga.2 for ; Mon, 10 Nov 2014 06:38:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=pOf3yBol5IhewlJ5GL7X9VYJ5EsQiBJd4iV1NIVAVqs=; b=maYd+w4ehUkX1lkDd/Enp16uYfuq4hfOe61gfy+UpxpZOQl1E6zjcEMk0L96rk+EFt 2IbAbEn2Hwvyp0ufjVSfMWc1o8wgsg2uqCEsWmB6dNS+f9MZqXVDzGkKgUBEUfg1NR72 8ul41xYstNQsKklYmngnwNF4YmJQdmE6IVtsf+Dc3yFPQbrbK3pUq/uz+4QtdQwmtU49 hl/p4I526sZhlxyjPK1A4ZM1zYRUTQGGu2VB7dByWgtxdljTnO6FcAHgxBXbHRH0jxL4 o2KUOKOhGecjCp3SvB8KUDpZoeOjQr4mik3+CzpjCrbmcNalWSz+yuVAfBqjwGgwNrUO Khbw== MIME-Version: 1.0 X-Received: by 10.50.73.135 with SMTP id l7mr24921680igv.10.1415630288127; Mon, 10 Nov 2014 06:38:08 -0800 (PST) Sender: vrwmiller@gmail.com Received: by 10.64.165.73 with HTTP; Mon, 10 Nov 2014 06:38:08 -0800 (PST) Date: Mon, 10 Nov 2014 09:38:08 -0500 X-Google-Sender-Auth: 4FExtdv0BKthFhaCFVPzBkd_LhQ Message-ID: Subject: MK_ vs. WITH_/WITHOUT_ in release/Makefile From: Rick Miller To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 10 Nov 2014 14:38:09 -0000 Hi all, release/Makefile in CURRENT utilizes MK_* knobs vs. the WITH_/WITHOUT_* knobs seen in release/Makefile in the STABLE/RELEASE branches. Merging a CURRENT version of the Makefile into a RELEASE branch and executing a release build results in an error citing "MK_KERNEL_SYMBOLS can't be set by a user". Comparisons of the Makefile between CURRENT and STABLE/RELEASE exposed the difference and changing the knobs from MK_ to WITHOUT_ resolved the error. I have little familiarity with these knobs, but was under the impression the Makefile would not differ like this. Is there documentation describing the use of these knobs between the varying branches and how they are changed from CURRENT to STABLE/RELEASE? -- Take care Rick Miller From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 17:41:37 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64A288CC; Mon, 10 Nov 2014 17:41:36 +0000 (UTC) Date: Mon, 10 Nov 2014 17:41:33 +0000 From: Glen Barber To: Rick Miller Subject: Re: MK_ vs. WITH_/WITHOUT_ in release/Makefile Message-ID: <20141110174133.GP1469@hub.FreeBSD.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WYfJCIN5rqlfy3K0" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 10 Nov 2014 17:41:37 -0000 --WYfJCIN5rqlfy3K0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 10, 2014 at 09:38:08AM -0500, Rick Miller wrote: > Hi all, >=20 > release/Makefile in CURRENT utilizes MK_* knobs vs. the WITH_/WITHOUT_* > knobs seen in release/Makefile in the STABLE/RELEASE branches. Merging a > CURRENT version of the Makefile into a RELEASE branch and executing a > release build results in an error citing "MK_KERNEL_SYMBOLS can't be set = by > a user". Comparisons of the Makefile between CURRENT and STABLE/RELEASE > exposed the difference and changing the knobs from MK_ to WITHOUT_ resolv= ed > the error. >=20 > I have little familiarity with these knobs, but was under the impression > the Makefile would not differ like this. Is there documentation describi= ng > the use of these knobs between the varying branches and how they are > changed from CURRENT to STABLE/RELEASE? >=20 These changes are result of src.opts.mk changes (only available in head/) that allows specifying MK_FOO=3Dno instead of WITHOUT_FOO=3Dyes on the command line. The changes were applied to the release/Makefile because it allows more granular tuning for different stages of the release build. For example, one might want to build userland/kernel with WITH_DEBUG_FILES=3Dyes, but does not want that to apply to the resulting ISOs, so a "global" WITH_DEBUG_FILES=3Dyes and target-specific MK_DEBUG_FILES=3Dno do not collide. Glen --WYfJCIN5rqlfy3K0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUYPjMAAoJEAMUWKVHj+KT2dQP/RTQyFBixnhKD97bmESdzPnQ RncTz2FolTuoDFh9qKqXr+0LZ118/i0frNnpQZPSp9pFtywva6k1DpUAvHjc64AL QSHazoxDFXUu4C53qrx77/608PDwXfok51QAexwv293tRtytLmZP30cO3cgaE0Sw rr78lIoZbROxvmCco01/QKl3+d4+hGi/j488Bgy96RBFBx1qAAUsoA3nGZp9J1hv ZMnAiY5vJmc1Ijyng9I8NRrV6MvE1AK1IUZfsXGUjpROyn8sIw9oNs9+slqw/YR4 4bUek85uwcgSc4GnwABD8Fj69llK0ClcdCwq7QrKb9TyMQAgpak14/u94JaVB+Fv HUtRs1BiKmeZ2Gp7cmzZ8lnzA13oKnyirDpN5SlXanQDfWAtHcve3lXmfR0Hg+hm vP+JWGuWFaSL6M5V8loMbfq4+xbMNeoq3YuxGX5OCxUBaj9H9DfDC8VklGpy/gNY mqvS/lURWl41UT4LMJ0fIgO1Lnp5MWYzc+ZTJmuXoRqMx4v7DQHfUc0fzU4+f7ct DGiBlKZ28BnuJYYBb2dvtkN/v5vni0lVNmZXJptLPx/ixAN4h0HQxT5UJDX0QyZC s6Ssm8z1L0HhmKquFbTWI5IrukXopt+V6AOMhktPrtB8pFZ6Q0iN8+UKwzIxCDsy JPoxw09TbWnPK4rJOnZc =YE3P -----END PGP SIGNATURE----- --WYfJCIN5rqlfy3K0-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 18:53:52 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D6DA8C2; Mon, 10 Nov 2014 18:53:52 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EAFF6BDD; Mon, 10 Nov 2014 18:53:51 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sAAIs6UW009583; Mon, 10 Nov 2014 10:54:06 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: "FreeBSD CURRENT" From: "Chris H" Subject: What's the least required in base to be functional? Date: Mon, 10 Nov 2014 10:54:06 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <35a0310882e1d8483662707a3925cbc9@ultimatedns.net> Content-Transfer-Encoding: 8bit Cc: FreeBSD toolchain X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 10 Nov 2014 18:53:52 -0000 Apologies. That may not have been the best choice of titles. What I'm trying to determine, is what is the very least I will require in base, to actually build a userland build environment. NOTE; this all concerns -CURRENT (recent 11). Point being, while I recognize that clang/llvm is the default on 10+. I have been building/installing world/kernel with make.conf(5) WITHOUT_CLANG=true FAVORITE_COMPILER=gcc src.conf(5) WITHOUT_CLANG=true on RELENG_8, and RELENG_9, and 11 (as of 1 mos ago) Everything worked as anticipated. But a recent (5 days ago) build/install on -CURRENT. Followed by a make delete-old _seemed_ to have an adverse affect. More specifically; having used the above declarations always resulted in the make delete-old removing clang from base. Which was fine. As I had intended to experiment with the different versions of lang/clang, and devel/llvm, via installing from ports. But my recent attempt using the above method, resulted in my being unable to build many ports. x11/* mostly. I ran into problems with "xmmintrin.h" not being found. Or other problems, where declarations were not supported in gcc(4.8,4.9, or 5). So what exactly *must* be installed in base to allow for a more *granular* approach to testing/building? Used to be IIRC, fmake, or bmake. But that's likely a pretty dated recollection. Thank you for all your time, and consideration. --Chris From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 19:28:10 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6DF01FD1; Mon, 10 Nov 2014 19:28:10 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A04BEE8; Mon, 10 Nov 2014 19:28:10 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::96f:bc74:b3c9:9d0e] (unknown [IPv6:2001:7b8:3a7:0:96f:bc74:b3c9:9d0e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 498F9B80A; Mon, 10 Nov 2014 20:28:07 +0100 (CET) Subject: Re: What's the least required in base to be functional? Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C9EA2FBB-7655-4E76-89FB-762AC2338744"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b1 From: Dimitry Andric In-Reply-To: <35a0310882e1d8483662707a3925cbc9@ultimatedns.net> Date: Mon, 10 Nov 2014 20:28:00 +0100 Message-Id: <620257BF-6202-4B3A-838F-9424D3E76BBF@FreeBSD.org> References: <35a0310882e1d8483662707a3925cbc9@ultimatedns.net> To: Chris H X-Mailer: Apple Mail (2.1990.1) Cc: FreeBSD toolchain , FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 10 Nov 2014 19:28:10 -0000 --Apple-Mail=_C9EA2FBB-7655-4E76-89FB-762AC2338744 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 10 Nov 2014, at 19:54, Chris H wrote: > > Apologies. That may not have been the best choice of titles. > What I'm trying to determine, is what is the very least I will > require in base, to actually build a userland build environment. > NOTE; this all concerns -CURRENT (recent 11). > Point being, while I recognize that clang/llvm is the default on > 10+. I have been building/installing world/kernel with > > make.conf(5) > WITHOUT_CLANG=true > FAVORITE_COMPILER=gcc > > src.conf(5) > WITHOUT_CLANG=true > > on RELENG_8, and RELENG_9, and 11 (as of 1 mos ago) > Everything worked as anticipated. But a recent (5 days ago) > build/install on -CURRENT. Followed by a make delete-old > _seemed_ to have an adverse affect. More specifically; > having used the above declarations always resulted in the > make delete-old removing clang from base. Which was fine. As > I had intended to experiment with the different versions of > lang/clang, and devel/llvm, via installing from ports. But my > recent attempt using the above method, resulted in my being > unable to build many ports. x11/* mostly. I ran into problems > with "xmmintrin.h" not being found. Or other problems, where > declarations were not supported in gcc(4.8,4.9, or 5). So what > exactly *must* be installed in base to allow for a more > *granular* approach to testing/building? > Used to be IIRC, fmake, or bmake. But that's likely a pretty > dated recollection. On recent -CURRENT, to build world using the version of gcc in base, and to not build or use the version of clang in base at all, you need at least the following settings in your src.conf: WITH_GCC=x # Enables building gcc for the final world WITH_GCC_BOOTSTRAP=x # Enables building gcc during cross-tools WITH_GNUCXX=x # Enables building libstdc++ and libsupc++ WITHOUT_CLANG_BOOTSTRAP=x # Disables building clang during cross-tools WITHOUT_CLANG=x # Disables building clang for the final world WITHOUT_CLANG_IS_CC=x # Links gcc to /usr/bin/cc, /usr/bin/c++, etc. Note that you can delete WITHOUT_CLANG from your make.conf, just like other WITH_ and WITHOUT_ settings. These only belong in src.conf. -Dimitry --Apple-Mail=_C9EA2FBB-7655-4E76-89FB-762AC2338744 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.26 iEYEARECAAYFAlRhEcQACgkQsF6jCi4glqPl9ACeM95WluQbVVPHhnilvZyGtgC0 VaoAoIsxHKOmpAtwAOCi+Vu7W1XVWME8 =bJCw -----END PGP SIGNATURE----- --Apple-Mail=_C9EA2FBB-7655-4E76-89FB-762AC2338744-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 19:47:27 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3147655 for ; Mon, 10 Nov 2014 19:47:27 +0000 (UTC) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E649125 for ; Mon, 10 Nov 2014 19:47:27 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id l18so9726039wgh.38 for ; Mon, 10 Nov 2014 11:47:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JXJ/SLNpSsXgYhzeBiE5VnlAAHC3FnLufGDSa6NgsdE=; b=ASPmyhcZ3VAQ1lkE7eVmogKWKtQmTWLCLgsJMWsL3xqATjFWKWXJb6KDeD9rk8vJwd UB4esv/h7lZgCGzyyyRVK3qtkCnGG7ZiKfRUGvVvmeWf9mn3RpYRQEXIo7PbpWlFevfQ OD9W1yxf4t6EBiifZ048kudTZBZHup3nJuO7HSAu2F4z8T/1ejj+Dhxlfp3G8z5qlisp vL+ErDO0/VcPilg6osAzj8om0pOdh8JepDrjs2zVJJGlwGCwGa0WE3RCh3ZQiEX4xVs6 NZ+RzO00+QfdpSP+cVeuDC6tsdbHG4HyGFk0XKv/kOLoX0geVHA0F+w/vJDL/k0feZZy JDFw== MIME-Version: 1.0 X-Received: by 10.194.60.16 with SMTP id d16mr47066495wjr.13.1415648842567; Mon, 10 Nov 2014 11:47:22 -0800 (PST) Received: by 10.27.46.14 with HTTP; Mon, 10 Nov 2014 11:47:22 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Nov 2014 13:47:22 -0600 Message-ID: Subject: Re: MK_ vs. WITH_/WITHOUT_ in release/Makefile From: Scot Hetzel To: Rick Miller Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 10 Nov 2014 19:47:27 -0000 On Mon, Nov 10, 2014 at 8:38 AM, Rick Miller wrote: > Hi all, > > release/Makefile in CURRENT utilizes MK_* knobs vs. the WITH_/WITHOUT_* > knobs seen in release/Makefile in the STABLE/RELEASE branches. Merging a > CURRENT version of the Makefile into a RELEASE branch and executing a > release build results in an error citing "MK_KERNEL_SYMBOLS can't be set by > a user". Comparisons of the Makefile between CURRENT and STABLE/RELEASE > exposed the difference and changing the knobs from MK_ to WITHOUT_ resolved > the error. > > I have little familiarity with these knobs, but was under the impression > the Makefile would not differ like this. Is there documentation describing > the use of these knobs between the varying branches and how they are > changed from CURRENT to STABLE/RELEASE? > According to head/share/Mk/src.opts.mk: # Users define WITH_FOO and WITHOUT_FOO on the command line or in /etc/src.conf # and /etc/make.conf files. These translate in the build system to MK_FOO={yes,no} # with sensible (usually) defaults. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 20:04:38 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E9D42B40; Mon, 10 Nov 2014 20:04:38 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BBCC133A; Mon, 10 Nov 2014 20:04:38 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sAAK4rWS035411; Mon, 10 Nov 2014 12:04:53 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: Dimitry Andric In-Reply-To: <620257BF-6202-4B3A-838F-9424D3E76BBF@FreeBSD.org> References: <35a0310882e1d8483662707a3925cbc9@ultimatedns.net>, <620257BF-6202-4B3A-838F-9424D3E76BBF@FreeBSD.org> From: "Chris H" Subject: Re: What's the least required in base to be functional? Date: Mon, 10 Nov 2014 12:04:53 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit Cc: FreeBSD toolchain , FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 10 Nov 2014 20:04:39 -0000 On Mon, 10 Nov 2014 20:28:00 +0100 Dimitry Andric wrote > On 10 Nov 2014, at 19:54, Chris H wrote: > > > > Apologies. That may not have been the best choice of titles. > > What I'm trying to determine, is what is the very least I will > > require in base, to actually build a userland build environment. > > NOTE; this all concerns -CURRENT (recent 11). > > Point being, while I recognize that clang/llvm is the default on > > 10+. I have been building/installing world/kernel with > > > > make.conf(5) > > WITHOUT_CLANG=true > > FAVORITE_COMPILER=gcc > > > > src.conf(5) > > WITHOUT_CLANG=true > > > > on RELENG_8, and RELENG_9, and 11 (as of 1 mos ago) > > Everything worked as anticipated. But a recent (5 days ago) > > build/install on -CURRENT. Followed by a make delete-old > > _seemed_ to have an adverse affect. More specifically; > > having used the above declarations always resulted in the > > make delete-old removing clang from base. Which was fine. As > > I had intended to experiment with the different versions of > > lang/clang, and devel/llvm, via installing from ports. But my > > recent attempt using the above method, resulted in my being > > unable to build many ports. x11/* mostly. I ran into problems > > with "xmmintrin.h" not being found. Or other problems, where > > declarations were not supported in gcc(4.8,4.9, or 5). So what > > exactly *must* be installed in base to allow for a more > > *granular* approach to testing/building? > > Used to be IIRC, fmake, or bmake. But that's likely a pretty > > dated recollection. > > On recent -CURRENT, to build world using the version of gcc in base, and > to not build or use the version of clang in base at all, you need at > least the following settings in your src.conf: > > WITH_GCC=x # Enables building gcc for the final world > WITH_GCC_BOOTSTRAP=x # Enables building gcc during cross-tools > WITH_GNUCXX=x # Enables building libstdc++ and libsupc++ > WITHOUT_CLANG_BOOTSTRAP=x # Disables building clang during cross-tools > WITHOUT_CLANG=x # Disables building clang for the final world > WITHOUT_CLANG_IS_CC=x # Links gcc to /usr/bin/cc, /usr/bin/c++, etc. > > Note that you can delete WITHOUT_CLANG from your make.conf, just like > other WITH_ and WITHOUT_ settings. These only belong in src.conf. > > -Dimitry Thank you, Dimitry. Perfect! So that I can become better acquainted. Where can I find (read) more about my options in base? KNOBS, and such. I don't recall reading about these in the developers handbook, and even then, especially where -CURRENT is concerned, they move/change pretty quickly. :) Thanks again. --Chris From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 20:16:50 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8EBCE5D; Mon, 10 Nov 2014 20:16:50 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 63DCB62B; Mon, 10 Nov 2014 20:16:49 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::96f:bc74:b3c9:9d0e] (unknown [IPv6:2001:7b8:3a7:0:96f:bc74:b3c9:9d0e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 9386DB80B; Mon, 10 Nov 2014 21:16:47 +0100 (CET) Subject: Re: What's the least required in base to be functional? Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Content-Type: multipart/signed; boundary="Apple-Mail=_CFC22B2E-1F5E-4BAC-B1AC-D1278C991463"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b1 From: Dimitry Andric In-Reply-To: Date: Mon, 10 Nov 2014 21:16:46 +0100 Message-Id: <097F046E-952E-45C6-B7CF-2FF59C3E257F@FreeBSD.org> References: <35a0310882e1d8483662707a3925cbc9@ultimatedns.net> <, > <620257BF-6202-4B3A-838F-9424D3E76BBF@FreeBSD.org> To: Chris H X-Mailer: Apple Mail (2.1990.1) Cc: FreeBSD toolchain , FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 10 Nov 2014 20:16:50 -0000 --Apple-Mail=_CFC22B2E-1F5E-4BAC-B1AC-D1278C991463 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 10 Nov 2014, at 21:04, Chris H wrote: > > On Mon, 10 Nov 2014 20:28:00 +0100 Dimitry Andric wrote ... >> Note that you can delete WITHOUT_CLANG from your make.conf, just like >> other WITH_ and WITHOUT_ settings. These only belong in src.conf. >> >> -Dimitry > > Thank you, Dimitry. Perfect! > > So that I can become better acquainted. Where can I find (read) > more about my options in base? KNOBS, and such. I don't recall > reading about these in the developers handbook, and even then, > especially where -CURRENT is concerned, they move/change pretty > quickly. :) You can read the build(7), src.conf(5) and make.conf(5) man pages. -Dimitry --Apple-Mail=_CFC22B2E-1F5E-4BAC-B1AC-D1278C991463 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.26 iEYEARECAAYFAlRhHS4ACgkQsF6jCi4glqNl+wCg8Xj6WKDeoHbl88n16FFgdKwc jAEAoPjxiJgRDsBvfVQSlvC8lrTTysZS =hRpj -----END PGP SIGNATURE----- --Apple-Mail=_CFC22B2E-1F5E-4BAC-B1AC-D1278C991463-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 20:20:45 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61D1B3BF; Mon, 10 Nov 2014 20:20:45 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2AAAF65E; Mon, 10 Nov 2014 20:20:45 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sAAKL03S041444; Mon, 10 Nov 2014 12:21:00 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: Dimitry Andric In-Reply-To: <097F046E-952E-45C6-B7CF-2FF59C3E257F@FreeBSD.org> References: <35a0310882e1d8483662707a3925cbc9@ultimatedns.net> <,> <620257BF-6202-4B3A-838F-9424D3E76BBF@FreeBSD.org> , <097F046E-952E-45C6-B7CF-2FF59C3E257F@FreeBSD.org> From: "Chris H" Subject: Re: What's the least required in base to be functional? Date: Mon, 10 Nov 2014 12:21:00 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit Cc: FreeBSD toolchain , FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 10 Nov 2014 20:20:45 -0000 On Mon, 10 Nov 2014 21:16:46 +0100 Dimitry Andric wrote > On 10 Nov 2014, at 21:04, Chris H wrote: > > > > On Mon, 10 Nov 2014 20:28:00 +0100 Dimitry Andric wrote > ... > >> Note that you can delete WITHOUT_CLANG from your make.conf, just like > >> other WITH_ and WITHOUT_ settings. These only belong in src.conf. > >> > >> -Dimitry > > > > Thank you, Dimitry. Perfect! > > > > So that I can become better acquainted. Where can I find (read) > > more about my options in base? KNOBS, and such. I don't recall > > reading about these in the developers handbook, and even then, > > especially where -CURRENT is concerned, they move/change pretty > > quickly. :) > > You can read the build(7), src.conf(5) and make.conf(5) man pages. > > -Dimitry D'OH! Sorry for the noise, and thanks. :) --Chris From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 20:56:30 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1FC5143; Mon, 10 Nov 2014 20:56:29 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 83E16AB7; Mon, 10 Nov 2014 20:56:29 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id ex7so11886146wid.10 for ; Mon, 10 Nov 2014 12:56:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=sXwuqty4ZgBa7Cq4cgR2q7XDPuymLvOLRlzyvTnPYw0=; b=T2FjRcr79v7HpS4qDMgqLNW3MlinPd/AiaROBKNsDZLbxUhdpztntuZiS3AyDUM91v /9C1PHsY9MmCUKK3SYBuZ4Tdn5eqI6bN/aC8EEWyndCIgHOpV1gS7f/hDJFP7skxGGfM 3Eh4neJ5Gg3H/hCsRFL/1OcONohs+sirB0YzG04nHGdpNnc/MxDi7dzaxDC5b8GoAJwG uBTi37orokwg7eICioBRLV/x7tbH/Fva06cK9D8i45KIXsxjjiC6Szr8lWKXyEZXhzPB XEIbeMsfZnS+k3kcbN/biQJyl6X9kGlELc1XsWy3oWdgxbevgVfumpQxCFF8SWvWC4cv vWHQ== MIME-Version: 1.0 X-Received: by 10.194.59.17 with SMTP id v17mr8314398wjq.130.1415652987273; Mon, 10 Nov 2014 12:56:27 -0800 (PST) Sender: asomers@gmail.com Received: by 10.194.220.227 with HTTP; Mon, 10 Nov 2014 12:56:27 -0800 (PST) In-Reply-To: <20141110035915.GA50986@FreeBSD.org> References: <20141110035915.GA50986@FreeBSD.org> Date: Mon, 10 Nov 2014 13:56:27 -0700 X-Google-Sender-Auth: i5twhmGcWSQHEIhy4lnKJ78cut8 Message-ID: Subject: Re: FreeBSD + Google Code-In 2014 = we need ideas. From: Alan Somers To: "Wojciech A. Koszek" Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 10 Nov 2014 20:56:30 -0000 On Sun, Nov 9, 2014 at 8:59 PM, Wojciech A. Koszek wrote: > Hello, > > This year we'd like to participate in the Google Code-In 2014. This is > Google Summer of Code, but for younger people: age range is 13--17. If > you're one of them, we highly encourage you to apply! > > ***This year coding tasks are possible, so feel free to add those*** > > To submit idea which you'd like to see done in GCI, visit: > > http://bit.ly/FreeBSD_GCIN2014 > > Regardless of who you are, please use the form to submit ideas. Don't add > stuff via Wiki, since this year we'll do direct import of all ideas from > Google Forms. > > To see tasks from previous year that are yet to be copied to Google Forms: > > https://wiki.freebsd.org/GoogleCodeIn/2014Tasks > > Thanks to GCI in the previous years, we gained one more FreeBSD developer. > We'd like to partcipate this year too. We need: > > 1) ideas. How about converting various utility functions to use libxo? I think that's within the grasp of a high-schooler. > > 2) mentors > > 3) participants. > > Just like in previous years we'll decide whether we're ready. Deadlines: > > --- > November 12, 2014 - The 10-12 Mentoring organizations are announced for > Google Code-in 2014 and the orgs can start entering their tasks into the > Google system (the tasks will not be viewable to students until the contest > opens on Dec 1). > December 1, 2014 17:00 UTC - Google Code-in 2014 contest opens for students > January 19, 2015 17:00 UTC - Google Code-in 2014 student work ends > --- > > MORE INFO: > > [0] http://www.google-melange.com/gci/homepage/google/gci2014 > [1] gci-mentors@googlegroups.com > [2] https://developers.google.com/open-source/gci/resources/mentor-and-orgadmin-info > > -- > Wojciech A. Koszek > wkoszek@FreeBSD.czest.pl > http://FreeBSD.czest.pl/~wkoszek/ > _______________________________________________ > 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 Nov 10 23:43:29 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D82FDE15; Mon, 10 Nov 2014 23:43:28 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5C1E8DFF; Mon, 10 Nov 2014 23:43:28 +0000 (UTC) Received-SPF: pass (freebsd.czest.pl: domain of wkoszek@freebsd.czest.pl designates 212.87.224.105 as permitted sender) receiver=freebsd.czest.pl; client-ip=212.87.224.105; helo=freebsd.czest.pl; envelope-from=wkoszek@freebsd.czest.pl; x-software=spfmilter 0.97 http://www.acme.com/software/spfmilter/ with libspf-unknown; Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id sAANYuk1059658; Mon, 10 Nov 2014 23:34:56 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id sAANYuhg059657; Mon, 10 Nov 2014 23:34:56 GMT (envelope-from wkoszek) Date: Mon, 10 Nov 2014 23:34:56 +0000 From: "Wojciech A. Koszek" To: Alan Somers Subject: Re: FreeBSD + Google Code-In 2014 = we need ideas. Message-ID: <20141110233456.GA52541@FreeBSD.org> References: <20141110035915.GA50986@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD, SPF_HELO_PASS,SPF_PASS,URIBL_DBL_REDIR autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on freebsd.czest.pl X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Mon, 10 Nov 2014 23:35:02 +0000 (UTC) Cc: "freebsd-hackers@freebsd.org" , FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 10 Nov 2014 23:43:29 -0000 On Mon, Nov 10, 2014 at 01:56:27PM -0700, Alan Somers wrote: > On Sun, Nov 9, 2014 at 8:59 PM, Wojciech A. Koszek wrote: > > Hello, > > > > This year we'd like to participate in the Google Code-In 2014. This is > > Google Summer of Code, but for younger people: age range is 13--17. If > > you're one of them, we highly encourage you to apply! > > > > ***This year coding tasks are possible, so feel free to add those*** > > > > To submit idea which you'd like to see done in GCI, visit: > > > > http://bit.ly/FreeBSD_GCIN2014 > > > > Regardless of who you are, please use the form to submit ideas. Don't add > > stuff via Wiki, since this year we'll do direct import of all ideas from > > Google Forms. > > > > To see tasks from previous year that are yet to be copied to Google Forms: > > > > https://wiki.freebsd.org/GoogleCodeIn/2014Tasks > > > > Thanks to GCI in the previous years, we gained one more FreeBSD developer. > > We'd like to partcipate this year too. We need: > > > > 1) ideas. > > > How about converting various utility functions to use libxo? I think > that's within the grasp of a high-schooler. This sounds good. Feel free to add 1 task for each such utility. Wojciech > > > > > > 2) mentors > > > > 3) participants. > > > > Just like in previous years we'll decide whether we're ready. Deadlines: > > > > --- > > November 12, 2014 - The 10-12 Mentoring organizations are announced for > > Google Code-in 2014 and the orgs can start entering their tasks into the > > Google system (the tasks will not be viewable to students until the contest > > opens on Dec 1). > > December 1, 2014 17:00 UTC - Google Code-in 2014 contest opens for students > > January 19, 2015 17:00 UTC - Google Code-in 2014 student work ends > > --- > > > > MORE INFO: > > > > [0] http://www.google-melange.com/gci/homepage/google/gci2014 > > [1] gci-mentors@googlegroups.com > > [2] https://developers.google.com/open-source/gci/resources/mentor-and-orgadmin-info > > > > -- > > Wojciech A. Koszek > > wkoszek@FreeBSD.czest.pl > > http://FreeBSD.czest.pl/~wkoszek/ > > _______________________________________________ > > 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" -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 00:54:36 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1540CAD; Tue, 11 Nov 2014 00:54:36 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 885A06EE; Tue, 11 Nov 2014 00:54:36 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sAB0sq8s082739; Mon, 10 Nov 2014 16:54:52 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: "FreeBSD CURRENT" From: "Chris H" Subject: Unable to build world w/o clang on 11 Date: Mon, 10 Nov 2014 16:54:52 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit Cc: FreeBSD toolchain X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 00:54:36 -0000 Greetings, I'm attempting to build/install world/kernel on a fresh install of 11 on bare metal, from the bootonly iso from 10-26. I understand that clang is the default for 10+. But had hoped to install it from ports *after* kernel/world. I used what I *thought* was the correct direction to do this: src.conf(5) WITH_GCC=true WITH_GCC_BOOTSTRAP=true WITH_GNUCXX=true WITHOUT_CLANG_BOOTSTRAP=true WITHOUT_CLANG=true WITHOUT_CLANG_IS_CC=true But after attempting to 'make -j6 buildworld'. It failed. So while still in /usr/src, I make clean, cd /usr/obj, and chflags -R noschg *, then rm -rf *, followed by cd /usr/src, and make buildworld. This too fails. I inadvertently clobbered the output I had intended to post along with this message. But I remember it being during the CC of rescue. If that helps any. Thank you for all your time, and consideration. --Chris From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 01:17:27 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F55DF58 for ; Tue, 11 Nov 2014 01:17:27 +0000 (UTC) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 69B3D90E for ; Tue, 11 Nov 2014 01:17:27 +0000 (UTC) Received: by mail-ig0-f176.google.com with SMTP id l13so141248iga.15 for ; Mon, 10 Nov 2014 17:17:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=a5KF27y1RECDmdKNkDalLGI7XsaZ/Mqre1Yshr4TQc8=; b=IunvqphOigWQfiq9EM3vtOxuqbGNmybSJfHR6+nR+/dyQ87KDKe4A7j65H2gNFSRBD ZeJUinaymUxFWRSKR2/J28b8oSjW41ny7SsF1ILa6Z22O724sAD1GAWqDgMbz1ct2xZ4 /mFsl8wBYVdyqRU9HSta86c9wmwFL5eaKcg8fT9MCBkoxCd+e1GNDGt8hULAA9y7EQtr UwgL7ycozjMTHVoMiuhwYwXQ48BGmN76tsXReAOlER3T8W1eAaSrHiuUZ7+EnN3iPLPL AH1SCwTyznqTO5utcANvh324ah5y37PFU6PVQKMPs1UE4kNQkg0ySbsFVWhON+fKkgpT FlpA== X-Received: by 10.42.84.83 with SMTP id k19mr14117icl.93.1415668646921; Mon, 10 Nov 2014 17:17:26 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.29.207 with HTTP; Mon, 10 Nov 2014 17:17:06 -0800 (PST) From: Ed Maste Date: Mon, 10 Nov 2014 20:17:06 -0500 X-Google-Sender-Auth: bPRexCk8xG5UEA6j1pHOKcy4dTg Message-ID: Subject: HEADS-UP: amd64 UEFI boot is broken To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 01:17:27 -0000 UEFI booting is broken for amd64 as of r273582 (Oct 24). The symptom is an apparent hang after the loader transfers control to the kernel (no output from the kernel is observed). Until this is addressed you can checkout an earlier revision or revert r273582 locally. -Ed From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 02:37:19 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40AE86A0; Tue, 11 Nov 2014 02:37:19 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EA58CFEA; Tue, 11 Nov 2014 02:37:18 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sAB2bZ65000895; Mon, 10 Nov 2014 18:37:35 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: "FreeBSD CURRENT" In-Reply-To: References: From: "Chris H" Subject: Re: Unable to build world w/o clang on 11 Date: Mon, 10 Nov 2014 18:37:35 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit Cc: FreeBSD toolchain X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 02:37:19 -0000 On Mon, 10 Nov 2014 16:54:52 -0800 "Chris H" wrote > Greetings, > I'm attempting to build/install world/kernel on a fresh > install of 11 on bare metal, from the bootonly iso from > 10-26. I understand that clang is the default for 10+. > But had hoped to install it from ports *after* kernel/world. > I used what I *thought* was the correct direction to do this: > src.conf(5) > WITH_GCC=true > WITH_GCC_BOOTSTRAP=true > WITH_GNUCXX=true > WITHOUT_CLANG_BOOTSTRAP=true > WITHOUT_CLANG=true > WITHOUT_CLANG_IS_CC=true > > But after attempting to 'make -j6 buildworld'. It failed. So while > still in /usr/src, I make clean, cd /usr/obj, and chflags -R noschg *, > then rm -rf *, followed by cd /usr/src, and make buildworld. > This too fails. I inadvertently clobbered the output I had intended > to post along with this message. But I remember it being during the > CC of rescue. If that helps any. > > Thank you for all your time, and consideration. > > --Chris Additional attempts, and information, in an attempt to buildworld without clang. FreeBSD dev FreeBSD 11.0-CURRENT #0 r273635: Sat Oct 25 14:23:40 UTC 2014 root@grind.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 Path: /usr/src Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 274349 Node Kind: directory Schedule: normal Last Changed Author: emaste Last Changed Rev: 274349 Last Changed Date: 2014-11-10 10:20:46 -0800 (Mon, 10 Nov 2014) Path: /usr/ports Working Copy Root Path: /usr/ports URL: svn://svn.freebsd.org/ports/head Relative URL: ^/head Repository Root: svn://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 372406 Node Kind: directory Schedule: normal Last Changed Author: pawel Last Changed Rev: 372406 Last Changed Date: 2014-11-10 09:25:04 -0800 (Mon, 10 Nov 2014) src.conf ONLY contains: WITHOUT_CLANG_BOOTSTRAP=true WITHOUT_CLANG=true WITHOUT_CLANG_IS_CC=true make -j6 buildworld fails with the following: --- cddl/lib__L --- --- ddt.So --- cc -fpic -DPIC -O2 -pipe -I/usr/src/cddl/lib/libzpool/../../../sys/cddl/comp at/opensolaris -I/usr/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/ usr/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/usr/src/cddl/l ib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/usr/src/cddl/lib/li bzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/usr/src/cddl/lib/ libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/usr/src/cddl /lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/usr/src/cddl/l ib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/usr/src/cddl/lib /libzpool/../../contrib/opensolaris/head -I/usr/src/cddl/lib/libzpool/../../lib/ libumem -I/usr/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DW ANTS_MUTEX_OWNED -I/usr/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/ usr/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/usr/src/cddl/lib/libzpo ol/../../../lib/libthr/arch/amd64/include -g -DDEBUG=1 -DNEED_SOLARIS_BOOLEAN -s td=iso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas -Wno-em pty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compa re -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-co nversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parenthes es -Qunused-arguments -c /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/op ensolaris/uts/common/fs/zfs/ddt.c -o ddt.So --- lib__L --- In file included from /usr/src/lib/libdpv/dialog_util.c:43: In file included from /usr/src/lib/libdpv/dialog_util.h:34: /usr/src/lib/libdpv/dialogrc.h:34:10: fatal error: 'figpar.h' file not found #include ^ 1 error generated. /usr/src/lib/libdpv/dialogrc.c:34:10: fatal error: 'figpar.h' file not found #include ^ --- depend_subdir_libedit --- ===> lib/libedit (depend) --- depend_subdir_libdpv --- 1 error generated. /usr/src/lib/libdpv/dprompt.c:40:10: fatal error: 'string_m.h' file not found #include ^ 1 error generated. --- depend_subdir_libedit --- --- common.h --- sh /usr/src/lib/libedit/makelist -h /usr/src/lib/libedit/common.c > common.h --- depend_subdir_libdpv --- /usr/src/lib/libdpv/dpv.c:42:10: fatal error: 'string_m.h' file not found #include ^ 1 error generated. --- depend_subdir_libedit --- --- emacs.h --- sh /usr/src/lib/libedit/makelist -h /usr/src/lib/libedit/emacs.c > emacs.h --- kerberos5/lib__L --- --- gss_oid.So --- --- lib__L --- --- depend_subdir_libdpv --- In file included from /usr/src/lib/libdpv/status.c:36: In file included from /usr/src/lib/libdpv/dialog_util.h:34: /usr/src/lib/libdpv/dialogrc.h:34:10: fatal error: 'figpar.h' file not found #include ^ 1 error generated. --- kerberos5/lib__L --- cc -fpic -DPIC -O2 -pipe -I/usr/src/kerberos5/lib/libgssapi_ntlm/../../../cr ypto/heimdal/lib/gssapi -I/usr/src/kerberos5/lib/libgssapi_ntlm/../../../crypto/ heimdal/lib/gssapi/gssapi -I/usr/src/kerberos5/lib/libgssapi_ntlm/../../../crypt o/heimdal/lib/gssapi/ntlm -I/usr/src/kerberos5/lib/libgssapi_ntlm/../../../crypt o/heimdal/lib/krb5 -I/usr/src/kerberos5/lib/libgssapi_ntlm/../../../crypto/heimd al/lib/ntlm -DHAVE_CONFIG_H -I/usr/src/kerberos5/lib/libgssapi_ntlm/../../includ e -std=gnu99 -fstack-protector -Qunused-arguments -c /usr/src/kerberos5/lib/li bgssapi_ntlm/../libgssapi_krb5/gss_oid.c -o gss_oid.So --- lib__L --- mkdep: compile failed --- depend_subdir_libedit --- --- help.h --- --- depend_subdir_libdpv --- *** [.depend] Error code 1 make[5]: stopped in /usr/src/lib/libdpv 1 error make[5]: stopped in /usr/src/lib/libdpv *** [depend_subdir_libdpv] Error code 2 make[4]: stopped in /usr/src/lib --- depend_subdir_libedit --- sh /usr/src/lib/libedit/makelist -bh /usr/src/lib/libedit/vi.c /usr/src/lib/libe dit/emacs.c /usr/src/lib/libedit/common.c > help.h A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/lib/libedit *** [depend_subdir_libedit] Error code 2 make[4]: stopped in /usr/src/lib 2 errors make[4]: stopped in /usr/src/lib --- kerberos5/lib__L --- A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/kerberos5/lib/libgssapi_ntlm *** [_sub.all] Error code 2 make[4]: stopped in /usr/src/kerberos5/lib 1 error make[4]: stopped in /usr/src/kerberos5/lib --- cddl/lib__L --- A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/cddl/lib/libzpool *** [_sub.all] Error code 2 make[4]: stopped in /usr/src/cddl/lib 1 error make[4]: stopped in /usr/src/cddl/lib A failure has been detected in another branch of the parallel make make[3]: stopped in /usr/src *** [libraries] Error code 2 make[2]: stopped in /usr/src 1 error make[2]: stopped in /usr/src *** [_libraries] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildworld] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src This time, with the above cited src.conf, but without -j # make buildworld fails with the following: s > ncurses_def.h rm -f .depend CC='cc ' mkdep -f .depend -a -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/ usr/obj/usr/src/lib/ncurses/menuw/../ncursesw -I/usr/src/lib/ncurses/menuw/../nc ursesw -I/usr/src/lib/ncurses/menuw/../ncurses -I/usr/src/lib/ncurses/menuw/../. /../contrib/ncurses/include -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurs es/ncurses -DNDEBUG -DHAVE_CONFIG_H -I/usr/src/lib/ncurses/menuw/../../../contri b/ncurses/menu -std=gnu99 /usr/src/lib/ncurses/menuw/../../../contrib/ncurses/ menu/m_attribs.c /usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu/m_curs or.c /usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu/m_driver.c /usr/sr c/lib/ncurses/menuw/../../../contrib/ncurses/menu/m_format.c /usr/src/lib/ncurse s/menuw/../../../contrib/ncurses/menu/m_global.c /usr/src/lib/ncurses/menuw/../. /../contrib/ncurses/menu/m_hook.c /usr/src/lib/ncurses/menuw/../../../contrib/n curses/menu/m_item_cur.c /usr/src/lib/ncurses/menuw/../../../contrib/ncurses/men u/m_item_nam.c /usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu/m_item_n ew.c /usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu/m_item_opt.c /usr/ src/lib/ncurses/menuw/../../../contrib/ncurses/menu/m_item_top.c /usr/src/lib/nc urses/menuw/../../../contrib/ncurses/menu/m_item_use.c /usr/src/lib/ncurses/menu w/../../../contrib/ncurses/menu/m_item_val.c /usr/src/lib/ncurses/menuw/../../.. /contrib/ncurses/menu/m_item_vis.c /usr/src/lib/ncurses/menuw/../../../contrib/n curses/menu/m_items.c /usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu/m _new.c /usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu/m_opts.c /usr/sr c/lib/ncurses/menuw/../../../contrib/ncurses/menu/m_pad.c /usr/src/lib/ncurses/m enuw/../../../contrib/ncurses/menu/m_pattern.c /usr/src/lib/ncurses/menuw/../../ ./contrib/ncurses/menu/m_post.c /usr/src/lib/ncurses/menuw/../../../contrib/ncu rses/menu/m_req_name.c /usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu/ m_scale.c /usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu/m_spacing.c / usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu/m_sub.c /usr/src/lib/ncu rses/menuw/../../../contrib/ncurses/menu/m_userptr.c /usr/src/lib/ncurses/menuw/ ./../../contrib/ncurses/menu/m_win.c echo libmenuw.so.5: /usr/obj/usr/src/tmp/usr/lib/libncursesw.a >> .depend ===> lib/ncurses/panelw (depend) AWK=awk sh /usr/src/lib/ncurses/panelw/../../../contrib/ncurses/include/MKncurse s_def.sh /usr/src/lib/ncurses/panelw/../../../contrib/ncurses/include/ncurses_d efs > ncurses_def.h rm -f .depend CC='cc ' mkdep -f .depend -a -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/ usr/obj/usr/src/lib/ncurses/panelw/../ncursesw -I/usr/src/lib/ncurses/panelw/../ ncursesw -I/usr/src/lib/ncurses/panelw/../ncurses -I/usr/src/lib/ncurses/panelw/ ./../../contrib/ncurses/include -I/usr/src/lib/ncurses/panelw/../../../contrib/ ncurses/ncurses -DNDEBUG -DHAVE_CONFIG_H -I/usr/src/lib/ncurses/panelw/../../../ contrib/ncurses/panel -std=gnu99 /usr/src/lib/ncurses/panelw/../../../contrib/ ncurses/panel/p_above.c /usr/src/lib/ncurses/panelw/../../../contrib/ncurses/pan el/p_below.c /usr/src/lib/ncurses/panelw/../../../contrib/ncurses/panel/p_bottom c /usr/src/lib/ncurses/panelw/../../../contrib/ncurses/panel/p_delete.c /usr/sr c/lib/ncurses/panelw/../../../contrib/ncurses/panel/p_hidden.c /usr/src/lib/ncur ses/panelw/../../../contrib/ncurses/panel/p_hide.c /usr/src/lib/ncurses/panelw/. /../../contrib/ncurses/panel/p_move.c /usr/src/lib/ncurses/panelw/../../../cont rib/ncurses/panel/p_new.c /usr/src/lib/ncurses/panelw/../../../contrib/ncurses/p anel/p_replace.c /usr/src/lib/ncurses/panelw/../../../contrib/ncurses/panel/p_sh ow.c /usr/src/lib/ncurses/panelw/../../../contrib/ncurses/panel/p_top.c /usr/src /lib/ncurses/panelw/../../../contrib/ncurses/panel/p_update.c /usr/src/lib/ncurs es/panelw/../../../contrib/ncurses/panel/p_user.c /usr/src/lib/ncurses/panelw/.. /../../contrib/ncurses/panel/p_win.c /usr/src/lib/ncurses/panelw/../../../contri b/ncurses/panel/panel.c echo libpanelw.so.5: /usr/obj/usr/src/tmp/usr/lib/libncursesw.a >> .depend ===> lib/libdpv (depend) rm -f .depend CC='cc ' mkdep -f .depend -a -I/usr/src/lib/libdpv -std=gnu99 /usr/src/lib /libdpv/dialog_util.c /usr/src/lib/libdpv/dialogrc.c /usr/src/lib/libdpv/dprompt c /usr/src/lib/libdpv/dpv.c /usr/src/lib/libdpv/status.c /usr/src/lib/libdpv/ut il.c In file included from /usr/src/lib/libdpv/dialog_util.c:43: In file included from /usr/src/lib/libdpv/dialog_util.h:34: /usr/src/lib/libdpv/dialogrc.h:34:10: fatal error: 'figpar.h' file not found #include ^ 1 error generated. /usr/src/lib/libdpv/dialogrc.c:34:10: fatal error: 'figpar.h' file not found #include ^ 1 error generated. /usr/src/lib/libdpv/dprompt.c:40:10: fatal error: 'string_m.h' file not found #include ^ 1 error generated. /usr/src/lib/libdpv/dpv.c:42:10: fatal error: 'string_m.h' file not found #include ^ 1 error generated. In file included from /usr/src/lib/libdpv/status.c:36: In file included from /usr/src/lib/libdpv/dialog_util.h:34: /usr/src/lib/libdpv/dialogrc.h:34:10: fatal error: 'figpar.h' file not found #include ^ 1 error generated. mkdep: compile failed *** Error code 1 Stop. make[5]: stopped in /usr/src/lib/libdpv *** Error code 1 Stop. make[4]: stopped in /usr/src/lib *** Error code 1 Stop. make[3]: stopped in /usr/src *** Error code 1 Stop. make[2]: stopped in /usr/src *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src So is there no other support for building world, except with clang. Or am I just doing it all wrong? Thank you for al your time, and consideration. --Chris > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 03:22:54 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7A53B1FD; Tue, 11 Nov 2014 03:22:54 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 579FD81E; Tue, 11 Nov 2014 03:22:54 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id sAB3MVkZ003773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 10 Nov 2014 19:22:31 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id sAB3MVX5003772; Mon, 10 Nov 2014 19:22:31 -0800 (PST) (envelope-from sgk) Date: Mon, 10 Nov 2014 19:22:31 -0800 From: Steve Kargl To: Chris H Subject: Re: Unable to build world w/o clang on 11 Message-ID: <20141111032231.GA3751@troutmask.apl.washington.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD toolchain , FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 03:22:54 -0000 On Mon, Nov 10, 2014 at 06:37:35PM -0800, Chris H wrote: > ===> lib/libdpv (depend) > rm -f .depend > CC='cc ' mkdep -f .depend -a -I/usr/src/lib/libdpv -std=gnu99 > /usr/src/lib > /libdpv/dialog_util.c /usr/src/lib/libdpv/dialogrc.c > /usr/src/lib/libdpv/dprompt > c /usr/src/lib/libdpv/dpv.c /usr/src/lib/libdpv/status.c > /usr/src/lib/libdpv/ut > il.c > In file included from /usr/src/lib/libdpv/dialog_util.c:43: > In file included from /usr/src/lib/libdpv/dialog_util.h:34: > /usr/src/lib/libdpv/dialogrc.h:34:10: fatal error: 'figpar.h' file not found > #include > ^ > 1 error generated. > /usr/src/lib/libdpv/dialogrc.c:34:10: fatal error: 'figpar.h' file not found Until such time that you can get the tree to build without -j, don't use it. Now, the obvious question: do you have figpar.h in /usr/src? -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 03:28:46 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E04C937C for ; Tue, 11 Nov 2014 03:28:46 +0000 (UTC) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B1E5F855 for ; Tue, 11 Nov 2014 03:28:46 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 1A68420923 for ; Mon, 10 Nov 2014 22:28:39 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Mon, 10 Nov 2014 22:28:39 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:x-sasl-enc:from:to :mime-version:content-transfer-encoding:content-type:subject :date:in-reply-to:references; s=smtpout; bh=u8at516xSdFVGVFTTztN ufiWNT0=; b=nfHd+zL6KETj6YOSCrDFYqOrP0+48do2ZavnsapTPwMxJqrdt1i6 0D3GIZxXxu9e4fNjSJc+dqdgGV1XyQm4Qn0D6T+4wyHeuuDEjM/AeK7Y0YJfH+Xl jIWjUWnkC6q0Qu2wJBFoK23kKMH6EQYzK0uWVo4yhbJ3C2VHuHbxs9g= Received: by web3.nyi.internal (Postfix, from userid 99) id E8E521066A1; Mon, 10 Nov 2014 22:28:38 -0500 (EST) Message-Id: <1415676518.1517572.189478341.09FB6AE5@webmail.messagingengine.com> X-Sasl-Enc: nC+52S79/0n8xKi2TwqnP862oYPEJirkdS5xZmgXlhB1 1415676518 From: Mark Felder To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-9183bd94 Subject: Re: Changing timezone without reboot/restarting each service? Date: Mon, 10 Nov 2014 21:28:38 -0600 In-Reply-To: <5460B143.3010004@FreeBSD.org> References: <5460B143.3010004@FreeBSD.org> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 03:28:47 -0000 On Mon, Nov 10, 2014, at 06:36, Lev Serebryakov wrote: > > After changing timezones in Russia (with replacing /etc/localtime > with new file), I found that cron works in "old" timezone till > restart. And all other services do the same, but cron is most obvious > here :) > > Looks like libc reads timezone only once and it could not be chamged > for process without restart (which leads to, effectivly, restart of > whole server). > > Is it known problem? I think, it should be fixed somehow. I > understand, that re-check timezone file on each time-related call > could be expensive, though :( > I think this was one of the crowning achievements of systemd, but I'm sure someone can come up with something much more sane than that to address this problem. From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 03:36:08 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D8CD14ED for ; Tue, 11 Nov 2014 03:36:08 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id B229192A for ; Tue, 11 Nov 2014 03:36:07 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 54EBD6CB3A for ; Tue, 11 Nov 2014 03:36:01 +0000 (UTC) Message-ID: <5461841F.9080208@freebsd.org> Date: Mon, 10 Nov 2014 22:35:59 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Changing timezone without reboot/restarting each service? References: <5460B143.3010004@FreeBSD.org> <1415676518.1517572.189478341.09FB6AE5@webmail.messagingengine.com> In-Reply-To: <1415676518.1517572.189478341.09FB6AE5@webmail.messagingengine.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EoFJhFJDLWWXl4skcmTOdAQsSWrvckRf9" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 03:36:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EoFJhFJDLWWXl4skcmTOdAQsSWrvckRf9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2014-11-10 22:28, Mark Felder wrote: >=20 >=20 > On Mon, Nov 10, 2014, at 06:36, Lev Serebryakov wrote: >> >> After changing timezones in Russia (with replacing /etc/localtime >> with new file), I found that cron works in "old" timezone till >> restart. And all other services do the same, but cron is most obvious >> here :) >> >> Looks like libc reads timezone only once and it could not be chamged >> for process without restart (which leads to, effectivly, restart of >> whole server). >> >> Is it known problem? I think, it should be fixed somehow. I >> understand, that re-check timezone file on each time-related call >> could be expensive, though :( >> >=20 > I think this was one of the crowning achievements of systemd, but I'm > sure someone can come up with something much more sane than that to > address this problem. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 jkh@ mentioned this specifically when he gave his talk at EuroBSDCon and MeetBSD, about how Apple solved this in LaunchD, because apparently originally libc DID check /etc/localtime constantly. --=20 Allan Jude --EoFJhFJDLWWXl4skcmTOdAQsSWrvckRf9 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.22 (MingW32) iQIcBAEBAgAGBQJUYYQiAAoJEJrBFpNRJZKfGKkP/1aBmx80UIih97GJVWLzmBUa KM6aAPOXQDxsPjyLZEKNGV22DmAHcNSAMEA5JE0o08cehq2vm4Hk/20Z8IlNwipy pWlg/1B1HGGvsmLq8LlsE8YuMby0nOlxCY3wDo0PiMsr9SnIUYJtV7Uf+e0bhJk4 bzYLsTV012MAQBl3/W7CIbxR6BApDokLoLyf5+Fj40Ugeuli8tUolwb+BqqhUpFa v5nTtzqx/GT476NZA6m1ykJ2VemH1ugxV/mXZrPhz9W+XZT3x99IF8iG3a7eZISc 6q48SHQgWjqtgNQ5E9TtukXYqfwXbjz50eVxUenP3PMD/FrxRqG6posLvfQlxtT0 TU/iZm3G5IovQpPN8cnohQg1g3dF7h3D5EVqHFQojRqkZ1BYRtqvxNIN0yZF7Bor eHiISy/KiC6bbvBLkMBjHBxYZONVvOs+fglQ9rz+h8uM/DFNzolULoFouuw11uLI wLwHAxU7m0o/v4BBNCfQ4XtUzSNcLUmsuThG6QBSMMdkfIKmKL9tQuDO4x8rsFCZ kMDq3I9Ks0s8yW22KKa9Y5B8fxG+OLizRJDpxEOkU6STZTK1XSeVdZ2GDFKEd6Mn d5ftj4TmHMWvWpI+2nq4TSiir+oZu6uyvYLFL3tK0zH/Wnjf8PFBx31sadQuV80w eF2QeqSeQ8elWjtqJ0JL =hxni -----END PGP SIGNATURE----- --EoFJhFJDLWWXl4skcmTOdAQsSWrvckRf9-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 03:52:32 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 11AD06DD; Tue, 11 Nov 2014 03:52:32 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D95FBABB; Tue, 11 Nov 2014 03:52:31 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sAB3qlVF012672; Mon, 10 Nov 2014 19:52:48 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: Steve Kargl In-Reply-To: <20141111032231.GA3751@troutmask.apl.washington.edu> References: , <20141111032231.GA3751@troutmask.apl.washington.edu> From: "Chris H" Subject: Re: Unable to build world w/o clang on 11 Date: Mon, 10 Nov 2014 19:52:48 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <8a1fd922bfe9a1c28726e82230c2cced@ultimatedns.net> Content-Transfer-Encoding: 8bit Cc: FreeBSD toolchain , FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 03:52:32 -0000 On Mon, 10 Nov 2014 19:22:31 -0800 Steve Kargl wrote > On Mon, Nov 10, 2014 at 06:37:35PM -0800, Chris H wrote: > > ===> lib/libdpv (depend) > > rm -f .depend > > CC='cc ' mkdep -f .depend -a -I/usr/src/lib/libdpv -std=gnu99 > > /usr/src/lib > > /libdpv/dialog_util.c /usr/src/lib/libdpv/dialogrc.c > > /usr/src/lib/libdpv/dprompt > > c /usr/src/lib/libdpv/dpv.c /usr/src/lib/libdpv/status.c > > /usr/src/lib/libdpv/ut > > il.c > > In file included from /usr/src/lib/libdpv/dialog_util.c:43: > > In file included from /usr/src/lib/libdpv/dialog_util.h:34: > > /usr/src/lib/libdpv/dialogrc.h:34:10: fatal error: 'figpar.h' file not > > found #include > > ^ > > 1 error generated. > > /usr/src/lib/libdpv/dialogrc.c:34:10: fatal error: 'figpar.h' file not > > found > > Until such time that you can get the tree to build without -j, don't > use it. > > Now, the obvious question: do you have figpar.h in /usr/src? Ugh... it's been a hectic day. Apparently it wasn't included in Revision: 274349 Last Changed Date: 2014-11-10 10:20:46 -0800 (Mon, 10 Nov 2014) :P I'll blow away src, and ports, and checkout what's ever available now. Hoping it's *now* included. ;) Thank you *very* much rubbing my face in the obvious, Steve. :) --Chris > > -- > Steve From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 08:29:06 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72E67943 for ; Tue, 11 Nov 2014 08:29:06 +0000 (UTC) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4107D7E2 for ; Tue, 11 Nov 2014 08:29:05 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id rp18so10994877iec.12 for ; Tue, 11 Nov 2014 00:28:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=T2DyZTiwLZedy5vWO/DAk1bQJKSsmitpEvUvaqHv4SU=; b=ePYyanhm5gz6vNY51tp+w8PrNgKldFONnhARk1jJcTypi6bSK3xWkwIyBZr+Nkte62 Ydu4NvysyTzSPIweBZcu1lqDi7ZybkcpqylgdZA9uQg31aGkk/SrXWMa7FVXLFPa7GPA lKwjjqyPew4ckTzv1J9evMwJGDmHOqvKTt1vvZv1ETR2wGYcty+EW1vn9YsmXZ39KaMX eMCT2L4wCZ+LtCVur7/NJPeUNJF319H10IpWtcj7mg81b7eZKIXy9hyZBoyxnDYEmyVT HORlReWTk8i8ldqaDaREpA86kyb41PBARthQ6UiUBwwrvSz3KyH4FGjkH9FIumEEfA4G s9nw== X-Gm-Message-State: ALoCoQmS1mCfElTchhsn3Qi0wBusxzidG4GpvOgaHruciPYH/4K1CtOADVACDGuEIpAgNq5/aMMB X-Received: by 10.51.15.132 with SMTP id fo4mr31252936igd.36.1415694538830; Tue, 11 Nov 2014 00:28:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.19.11 with HTTP; Tue, 11 Nov 2014 00:28:38 -0800 (PST) In-Reply-To: <5460AC13.5060001@freebsd.org> References: <5460AC13.5060001@freebsd.org> From: "Timur I. Bakeyev" Date: Tue, 11 Nov 2014 09:28:38 +0100 Message-ID: Subject: Re: samba/NSSWITCH interaction in fbsd 10 vs fbsd 8 To: Julian Elischer Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: hackers@freebsd.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 08:29:06 -0000 Do you use net/samba36 port? Looks like you don't... @@ -6336,12 +6373,13 @@ NSSSONAMEVERSIONSUFFIX=".2" WINBIND_NSS_EXTRA_OBJS="../nsswitch/winbind_nss_linux.o" ;; - *freebsd[[5-9]]*) + *freebsd*) # FreeBSD winbind client is implemented as a wrapper around # the Linux version. NSSSONAMEVERSIONSUFFIX=".1" WINBIND_NSS_EXTRA_OBJS="../nsswitch/winbind_nss_freebsd.o \ ../nsswitch/winbind_nss_linux.o" + WINBIND_WINS_NSS_EXTRA_OBJS="../nsswitch/wins_freebsd.o" WINBIND_NSS="../nsswitch/nss_winbind.$SHLIBEXT" WINBIND_WINS_NSS="../nsswitch/nss_wins.$SHLIBEXT" ;; On Mon, Nov 10, 2014 at 1:14 PM, Julian Elischer wrote: > When I try use the libnss_winbind.so that is generated by samba 3.6 I get > the following message: > > NSSWITCH(nss_load_module): winbind, Undefined symbol > "nss_module_register". > > First I have to change its' name to nss_winbins.so.1 however because that > is what nsswitch is looking for.... > (BTW where is that documented??) > > then it finds it but fails as mentioned above. > > This same samba source generates good nss files in 8.0 but under 10 it > fails.. Literally it's the same sources just checked out into a different > build system. (10 vs 8). > > Has there been a change in the API for the nss modules? where it he API > for nsswitch files documented? > > Julian > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 08:57:08 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E6AAAE54; Tue, 11 Nov 2014 08:57:08 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B769FA98; Tue, 11 Nov 2014 08:57:07 +0000 (UTC) Received: from [192.168.0.106] (cpc14-cmbg15-2-0-cust307.5-4.cable.virginm.net [82.26.1.52]) (authenticated bits=0) by theravensnest.org (8.14.9/8.14.9) with ESMTP id sAB8urfb038479 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Nov 2014 08:56:56 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc14-cmbg15-2-0-cust307.5-4.cable.virginm.net [82.26.1.52] claimed to be [192.168.0.106] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Changing timezone without reboot/restarting each service? From: David Chisnall In-Reply-To: <5461841F.9080208@freebsd.org> Date: Tue, 11 Nov 2014 08:56:47 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <96024C48-850E-4511-94E5-C39E5A8AA77F@FreeBSD.org> References: <5460B143.3010004@FreeBSD.org> <1415676518.1517572.189478341.09FB6AE5@webmail.messagingengine.com> <5461841F.9080208@freebsd.org> To: Allan Jude X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 08:57:09 -0000 On 11 Nov 2014, at 03:35, Allan Jude wrote: > jkh@ mentioned this specifically when he gave his talk at EuroBSDCon = and > MeetBSD, about how Apple solved this in LaunchD, because apparently > originally libc DID check /etc/localtime constantly. Darwin also has the notify(3) interface, which allows one-bit messages = to be transmitted either from the kernel to userspace or from userspace = to userspace very cheaply. This is ideal for this sort of 'something = you've cached is change, go and do something expensive to fix it' use = (time zone has changed, network connectivity has changed, power state = has changed). You can assign notifications to either file descriptors = (that can be monitored with kqueue), to signals, or to flags in memory = for things where polling is cheaper (as in this case - the libc = functions could just check whether a specific flag is set in memory when = accessing the time zone info and load a newer one if changed). David From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 11:00:15 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 12DAB5C5; Tue, 11 Nov 2014 11:00:15 +0000 (UTC) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CCD588FC; Tue, 11 Nov 2014 11:00:14 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id rp18so10779017iec.26 for ; Tue, 11 Nov 2014 03:00:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=GU75//Vt9SNz1YzIx2BE8zF2Ihylk1yXpvPUhWCYKbE=; b=cBmTyg9pv/GU1pgxdfISaNf3YlcGXN1r5VJpZZWr7H1vru24GRKvFaMJZ3rRSKNWq7 1PulOz1Bjtn89KvQIOrgl3oV9hG2xbqUNbWERsS1ltliwAnX28Ney02FqhY7J9KFsvKv 6PieMY3A4S/UDOxoNBA1d1nBPjkmpSajOsXoAdHUHsgW2CGskD9hwUeIX3onrkteUk65 cYLEWLVdKfzVWNtAbKxhs67srYA2rUSNy3P7h4sYwfX4z/d/cU6uKfgtAqdYpg7zcINP elrAljhmKuAtBcfD4mfQOCVti954TaD+x8Cx1F6/Ktmo5l8Jl5WH6Ddfn288OjKS9j63 g+OQ== MIME-Version: 1.0 X-Received: by 10.43.170.134 with SMTP id nq6mr41301530icc.30.1415703614201; Tue, 11 Nov 2014 03:00:14 -0800 (PST) Sender: vrwmiller@gmail.com Received: by 10.64.165.73 with HTTP; Tue, 11 Nov 2014 03:00:14 -0800 (PST) In-Reply-To: <20141110174133.GP1469@hub.FreeBSD.org> References: <20141110174133.GP1469@hub.FreeBSD.org> Date: Tue, 11 Nov 2014 06:00:14 -0500 X-Google-Sender-Auth: yG9gfMksZ5ykQqHy29nhjZxt-p8 Message-ID: Subject: Re: MK_ vs. WITH_/WITHOUT_ in release/Makefile From: Rick Miller To: Glen Barber Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 11:00:15 -0000 On Mon, Nov 10, 2014 at 12:41 PM, Glen Barber wrote: > On Mon, Nov 10, 2014 at 09:38:08AM -0500, Rick Miller wrote: > > Hi all, > > > > release/Makefile in CURRENT utilizes MK_* knobs vs. the WITH_/WITHOUT_* > > knobs seen in release/Makefile in the STABLE/RELEASE branches. Merging a > > CURRENT version of the Makefile into a RELEASE branch and executing a > > release build results in an error citing "MK_KERNEL_SYMBOLS can't be set > by > > a user". Comparisons of the Makefile between CURRENT and STABLE/RELEASE > > exposed the difference and changing the knobs from MK_ to WITHOUT_ > resolved > > the error. > > > > I have little familiarity with these knobs, but was under the impression > > the Makefile would not differ like this. Is there documentation > describing > > the use of these knobs between the varying branches and how they are > > changed from CURRENT to STABLE/RELEASE? > > > > These changes are result of src.opts.mk changes (only available in > head/) that allows specifying MK_FOO=no instead of WITHOUT_FOO=yes on > the command line. > > The changes were applied to the release/Makefile because it allows more > granular tuning for different stages of the release build. For example, > one might want to build userland/kernel with WITH_DEBUG_FILES=yes, but > does not want that to apply to the resulting ISOs, so a "global" > WITH_DEBUG_FILES=yes and target-specific MK_DEBUG_FILES=no do not > collide. > Thanks, Glen & Scot... The necessary bits exist in STABLE and were, therefore, merged from there as opposed to CURRENT. Your feedback is appreciated. -- Take care Rick Miller From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 15:12:50 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 425BB2CD for ; Tue, 11 Nov 2014 15:12:50 +0000 (UTC) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0A7839E9 for ; Tue, 11 Nov 2014 15:12:50 +0000 (UTC) Received: by mail-ig0-f170.google.com with SMTP id h15so1215870igd.5 for ; Tue, 11 Nov 2014 07:12:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=XAQK7bwI5+eatl0+pM5VHo4jToCu2b3RCADEbvlh9so=; b=bNSqAfHWiFt33g/arx1mZy8v4Pl6b1SNlxGgBg0/1ZwAyKNeLsMrI6XCdfyETK9/V2 tvbo3oBS1MYgdEG7wu3ZfpKVhfDsNgzIeBa/rxDQEB4MkviqNNgrAEr8VBFtxLfw0RlC 6cwFPNToOjaPYgXJbIsAKXEl1S0lWcDt3pxgS6cCD2+rBbRD1eJZ7xqpQRJtujBetFCn vQX5hVR11USMEfdWOZbdBy3OmrZJflKhnPvfKiFXnQ5MYYElXN7K4Unb6HEEvRYvcTVL HmuyhPZ6RM5Clr5od1gula9MEi5wQCejd75lciOtoIFlLbHzecUHaVlQgbL4QMCpfecg xhng== X-Received: by 10.107.40.141 with SMTP id o135mr26674296ioo.26.1415718765617; Tue, 11 Nov 2014 07:12:45 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.29.207 with HTTP; Tue, 11 Nov 2014 07:12:25 -0800 (PST) In-Reply-To: References: From: Ed Maste Date: Tue, 11 Nov 2014 10:12:25 -0500 X-Google-Sender-Auth: X-q48tid9FTx-pdhU-aw7It5Hvc Message-ID: Subject: Re: HEADS-UP: amd64 UEFI boot is broken To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 15:12:50 -0000 On 10 November 2014 20:17, Ed Maste wrote: > UEFI booting is broken for amd64 as of r273582 (Oct 24). The symptom > is an apparent hang after the loader transfers control to the kernel > (no output from the kernel is observed). Until this is addressed you > can checkout an earlier revision or revert r273582 locally. I have committed a workaround for this issue in r274382. The vt(4) EFI framebuffer driver makes use of kernel infrastructure in a way that is not correct, but works in practice, and this was caught by a new assertion added in r273582. My change loosens the assertion to allow efifb's use for now. We will need to fix the early framebuffer implementation in a subsequent change. -Ed From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 15:51:20 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7C87B71; Tue, 11 Nov 2014 15:51:19 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A587AE4C; Tue, 11 Nov 2014 15:51:19 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sABFpbRN084898; Tue, 11 Nov 2014 07:51:37 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: Steve Kargl In-Reply-To: <8a1fd922bfe9a1c28726e82230c2cced@ultimatedns.net> References: , <20141111032231.GA3751@troutmask.apl.washington.edu>, <8a1fd922bfe9a1c28726e82230c2cced@ultimatedns.net> From: "Chris H" Subject: Re: Unable to build world w/o clang on 11 Date: Tue, 11 Nov 2014 07:51:37 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit Cc: FreeBSD toolchain , FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 15:51:20 -0000 On Mon, 10 Nov 2014 19:52:48 -0800 "Chris H" wrote > On Mon, 10 Nov 2014 19:22:31 -0800 Steve Kargl > wrote > > > On Mon, Nov 10, 2014 at 06:37:35PM -0800, Chris H wrote: > > > ===> lib/libdpv (depend) > > > rm -f .depend > > > CC='cc ' mkdep -f .depend -a -I/usr/src/lib/libdpv -std=gnu99 > > > /usr/src/lib > > > /libdpv/dialog_util.c /usr/src/lib/libdpv/dialogrc.c > > > /usr/src/lib/libdpv/dprompt > > > c /usr/src/lib/libdpv/dpv.c /usr/src/lib/libdpv/status.c > > > /usr/src/lib/libdpv/ut > > > il.c > > > In file included from /usr/src/lib/libdpv/dialog_util.c:43: > > > In file included from /usr/src/lib/libdpv/dialog_util.h:34: > > > /usr/src/lib/libdpv/dialogrc.h:34:10: fatal error: 'figpar.h' file not > > > found #include > > > ^ > > > 1 error generated. > > > /usr/src/lib/libdpv/dialogrc.c:34:10: fatal error: 'figpar.h' file not > > > found > > > > Until such time that you can get the tree to build without -j, don't > > use it. > > > > Now, the obvious question: do you have figpar.h in /usr/src? > Ugh... it's been a hectic day. Apparently it wasn't included in > Revision: 274349 > Last Changed Date: 2014-11-10 10:20:46 -0800 (Mon, 10 Nov 2014) > > :P > > I'll blow away src, and ports, and checkout what's ever available > now. Hoping it's *now* included. ;) > > Thank you *very* much rubbing my face in the obvious, Steve. :) > > --Chris Checked out the current version of src from head, that was available (r274365) and gave it another go. While it *did* have the missing file. The results were less than hoped for: cc -O2 -pipe -I/usr/src/sbin/gbde/../../sys -DRESCUE -std=gnu99 -fstack-prote ctor -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Ws trict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/sbin/gbde/../../sys/crypto/rijndael/rijndael-api-fst.c cc1: warnings being treated as errors /usr/src/sbin/gbde/../../sys/crypto/rijndael/rijndael-api-fst.c: In function 'ri jndael_padEncrypt': /usr/src/sbin/gbde/../../sys/crypto/rijndael/rijndael-api-fst.c:236: warning: ca st discards qualifiers from pointer target type /usr/src/sbin/gbde/../../sys/crypto/rijndael/rijndael-api-fst.c:237: warning: ca st discards qualifiers from pointer target type /usr/src/sbin/gbde/../../sys/crypto/rijndael/rijndael-api-fst.c:238: warning: ca st discards qualifiers from pointer target type /usr/src/sbin/gbde/../../sys/crypto/rijndael/rijndael-api-fst.c:239: warning: ca st discards qualifiers from pointer target type *** Error code 1 Stop. make[6]: stopped in /usr/src/sbin/gbde *** Error code 1 Stop. make[5]: stopped in /usr/obj/usr/src/rescue/rescue *** Error code 1 Stop. make[4]: stopped in /usr/src/rescue/rescue *** Error code 1 Stop. make[3]: stopped in /usr/src/rescue *** Error code 1 Stop. make[2]: stopped in /usr/src *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src While I recognize that -CURRENT is a moving target. Things seem a bit brittle, at the moment. I'll check out what's available now (revision), and hope for the best. --Chris > > > > > -- > > Steve > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 16:08:27 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0243F13C; Tue, 11 Nov 2014 16:08:27 +0000 (UTC) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C8E02F84; Tue, 11 Nov 2014 16:08:26 +0000 (UTC) Received: by mail-pd0-f173.google.com with SMTP id v10so10322612pde.4 for ; Tue, 11 Nov 2014 08:08:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=fSywH9i1IXqsxhCNKHjnNJuO3Q46+JKQcW/sxO/rdDI=; b=McK6TxfNvRfJKqqb0tHhyRDFK0mVA7PzQ4YzwnMOYpkTZb8iV7qiyMkAdpfwG0+6vv FIQGRSc0Pk6EghMgyLrvHxIqCNoOZ6VKZUVP7l6po9cXnBi7WMA1tHjFb7bU07AJDqHf Bp5y6Ap4BPiPqvgS7bGdCM+iKOyCH0fYa26QA8Ut1+3sVNJD6bsTBtXeJyF9LpCrHmZE U9MkQLsMkdjcCb2el+SL4rESCtqih+EPLtvQdfCMOGvEOh35J34niBm5NpRVwzhs+Gw1 cGE3RMm59NK7oQiYRniWWJd1zoKZXZLyAutym899c61Nsn+rC/E/ip+R2jJeeFulAGPB RfVg== X-Received: by 10.68.98.131 with SMTP id ei3mr32758086pbb.127.1415722106286; Tue, 11 Nov 2014 08:08:26 -0800 (PST) Received: from [192.168.20.11] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id jc3sm19699269pbb.49.2014.11.11.08.08.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Nov 2014 08:08:25 -0800 (PST) References: <20141111032231.GA3751@troutmask.apl.washington.edu> <8a1fd922bfe9a1c28726e82230c2cced@ultimatedns.net> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <057607CB-91DF-4C0D-AB26-330D157755F3@gmail.com> X-Mailer: iPhone Mail (12B411) From: Garrett Cooper Subject: Re: Unable to build world w/o clang on 11 Date: Tue, 11 Nov 2014 08:08:24 -0800 To: Chris H Cc: FreeBSD toolchain , FreeBSD CURRENT , Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 16:08:27 -0000 > On Nov 11, 2014, at 07:51, Chris H wrote: >=20 > On Mon, 10 Nov 2014 19:52:48 -0800 "Chris H" wrot= e >=20 >> On Mon, 10 Nov 2014 19:22:31 -0800 Steve Kargl >> wrote >>=20 >>>> On Mon, Nov 10, 2014 at 06:37:35PM -0800, Chris H wrote: >>>> =3D=3D=3D> lib/libdpv (depend) >>>> rm -f .depend >>>> CC=3D'cc ' mkdep -f .depend -a -I/usr/src/lib/libdpv -std=3Dgnu99 =20= >>>> /usr/src/lib >>>> /libdpv/dialog_util.c /usr/src/lib/libdpv/dialogrc.c >>>> /usr/src/lib/libdpv/dprompt >>>> c /usr/src/lib/libdpv/dpv.c /usr/src/lib/libdpv/status.c >>>> /usr/src/lib/libdpv/ut >>>> il.c >>>> In file included from /usr/src/lib/libdpv/dialog_util.c:43: >>>> In file included from /usr/src/lib/libdpv/dialog_util.h:34: >>>> /usr/src/lib/libdpv/dialogrc.h:34:10: fatal error: 'figpar.h' file not >>>> found #include >>>> ^ >>>> 1 error generated. >>>> /usr/src/lib/libdpv/dialogrc.c:34:10: fatal error: 'figpar.h' file not >>>> found >>>=20 >>> Until such time that you can get the tree to build without -j, don't >>> use it. >>>=20 >>> Now, the obvious question: do you have figpar.h in /usr/src? >> Ugh... it's been a hectic day. Apparently it wasn't included in >> Revision: 274349 >> Last Changed Date: 2014-11-10 10:20:46 -0800 (Mon, 10 Nov 2014) >>=20 >> :P >>=20 >> I'll blow away src, and ports, and checkout what's ever available >> now. Hoping it's *now* included. ;) >>=20 >> Thank you *very* much rubbing my face in the obvious, Steve. :) > Checked out the current version of src from head, that was available (r274= 365) > and gave it another go. While it *did* have the missing file. The results > were less than hoped for: This issue was fixed just a few hours ago by des@ Cheers!= From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 16:10:19 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8CED273; Tue, 11 Nov 2014 16:10:19 +0000 (UTC) Received: from st11p02mm-asmtp001.mac.com (st11p02mm-asmtp001.mac.com [17.172.220.236]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8BC69F9D; Tue, 11 Nov 2014 16:10:19 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NEV00L82U8L3TB0@st11p02mm-asmtp001.mac.com>; Tue, 11 Nov 2014 16:10:01 +0000 (GMT) Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: Changing timezone without reboot/restarting each service? From: Rui Paulo In-reply-to: <96024C48-850E-4511-94E5-C39E5A8AA77F@FreeBSD.org> Date: Tue, 11 Nov 2014 08:09:57 -0800 Content-transfer-encoding: quoted-printable Message-id: <101111B9-226C-4E74-9318-376A9DADC6D0@me.com> References: <5460B143.3010004@FreeBSD.org> <1415676518.1517572.189478341.09FB6AE5@webmail.messagingengine.com> <5461841F.9080208@freebsd.org> <96024C48-850E-4511-94E5-C39E5A8AA77F@FreeBSD.org> To: David Chisnall X-Mailer: Apple Mail (2.1990.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.28,0.0.0000 definitions=2014-11-11_03:2014-11-11,2014-11-11,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1411110117 X-Mailman-Approved-At: Tue, 11 Nov 2014 16:25:15 +0000 Cc: freebsd-current@freebsd.org, Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 16:10:19 -0000 On Nov 11, 2014, at 00:56, David Chisnall wrote: >=20 > On 11 Nov 2014, at 03:35, Allan Jude wrote: >=20 >> jkh@ mentioned this specifically when he gave his talk at EuroBSDCon = and >> MeetBSD, about how Apple solved this in LaunchD, because apparently >> originally libc DID check /etc/localtime constantly. >=20 > Darwin also has the notify(3) interface, which allows one-bit messages = to be transmitted either from the kernel to userspace or from userspace = to userspace very cheaply. This is ideal for this sort of 'something = you've cached is change, go and do something expensive to fix it' use = (time zone has changed, network connectivity has changed, power state = has changed). You can assign notifications to either file descriptors = (that can be monitored with kqueue), to signals, or to flags in memory = for things where polling is cheaper (as in this case - the libc = functions could just check whether a specific flag is set in memory when = accessing the time zone info and load a newer one if changed). Except that's not how it works for network events: kernel control = sockets are used to communicate between the kernel and userland about = the state of the network. Kernel control sockets carry kernel event = messages. -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 17:57:52 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18BD0CEB; Tue, 11 Nov 2014 17:57:52 +0000 (UTC) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9EDC0A; Tue, 11 Nov 2014 17:57:51 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id b13so12177063wgh.12 for ; Tue, 11 Nov 2014 09:57:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=uboINQi4/F0XxWvctxDPyHHco0mvik99ye/B74udM+c=; b=Mv/DmRT8IzCbMZgZOP6bO/OXmNx3RSXxFiPVQEN78MEKO2fuBlR1KsNLcIH21I9idP tTqeMfW1HJ9XYnlopI0/e52QTyjAxHmO10qkp/c10nWChthd8xS5I5SeyO4t6StSXC7Z Y47VU/XFCzwyR4u0TrqUFYx+5GDhmXUH3MS4tv4pwipuHd254jf7+R60+fCgqwTVSGEz 8h9AuMO//M7oEKxtuj1QXU80OBICbxFtY3RXTd1FJP41lo0UcFr7S509nAUC69LWRAuF jGDENxnQj6SUkrEEWElg/q9n6ZOOPeO30UNWLz5yV1itXuguUTY2dd56BA+CnLA5EVJ3 NQhA== MIME-Version: 1.0 X-Received: by 10.180.188.41 with SMTP id fx9mr41983197wic.59.1415728670021; Tue, 11 Nov 2014 09:57:50 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Tue, 11 Nov 2014 09:57:49 -0800 (PST) In-Reply-To: References: Date: Tue, 11 Nov 2014 09:57:49 -0800 X-Google-Sender-Auth: bEhqQMC9ghyvVEXzxs33DdljGcs Message-ID: Subject: Re: HEADS-UP: amd64 UEFI boot is broken From: Adrian Chadd To: Ed Maste Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 17:57:52 -0000 On 11 November 2014 07:12, Ed Maste wrote: > On 10 November 2014 20:17, Ed Maste wrote: >> UEFI booting is broken for amd64 as of r273582 (Oct 24). The symptom >> is an apparent hang after the loader transfers control to the kernel >> (no output from the kernel is observed). Until this is addressed you >> can checkout an earlier revision or revert r273582 locally. > > I have committed a workaround for this issue in r274382. The vt(4) EFI > framebuffer driver makes use of kernel infrastructure in a way that is > not correct, but works in practice, and this was caught by a new > assertion added in r273582. My change loosens the assertion to allow > efifb's use for now. > > We will need to fix the early framebuffer implementation in a subsequent change. Woo, thanks! -adrian From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 19:03:50 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C532E71C; Tue, 11 Nov 2014 19:03:50 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 91968D2A; Tue, 11 Nov 2014 19:03:50 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sABJ48Zk010821; Tue, 11 Nov 2014 11:04:08 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: Garrett Cooper In-Reply-To: <057607CB-91DF-4C0D-AB26-330D157755F3@gmail.com> References: <20141111032231.GA3751@troutmask.apl.washington.edu> <8a1fd922bfe9a1c28726e82230c2cced@ultimatedns.net> , <057607CB-91DF-4C0D-AB26-330D157755F3@gmail.com> From: "Chris H" Subject: Re: Unable to build world w/o clang on 11 Date: Tue, 11 Nov 2014 11:04:08 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <7854f93b2c7110c1deb38790449e5977@ultimatedns.net> Content-Transfer-Encoding: 8bit Cc: FreeBSD toolchain , FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 19:03:51 -0000 On Tue, 11 Nov 2014 08:08:24 -0800 Garrett Cooper wrote > > On Nov 11, 2014, at 07:51, Chris H wrote: > > > > On Mon, 10 Nov 2014 19:52:48 -0800 "Chris H" wrote > > > >> On Mon, 10 Nov 2014 19:22:31 -0800 Steve Kargl > >> wrote > >> > >>>> On Mon, Nov 10, 2014 at 06:37:35PM -0800, Chris H wrote: > >>>> ===> lib/libdpv (depend) > >>>> rm -f .depend > >>>> CC='cc ' mkdep -f .depend -a -I/usr/src/lib/libdpv -std=gnu99 > >>>> /usr/src/lib > >>>> /libdpv/dialog_util.c /usr/src/lib/libdpv/dialogrc.c > >>>> /usr/src/lib/libdpv/dprompt > >>>> c /usr/src/lib/libdpv/dpv.c /usr/src/lib/libdpv/status.c > >>>> /usr/src/lib/libdpv/ut > >>>> il.c > >>>> In file included from /usr/src/lib/libdpv/dialog_util.c:43: > >>>> In file included from /usr/src/lib/libdpv/dialog_util.h:34: > >>>> /usr/src/lib/libdpv/dialogrc.h:34:10: fatal error: 'figpar.h' file not > >>>> found #include > >>>> ^ > >>>> 1 error generated. > >>>> /usr/src/lib/libdpv/dialogrc.c:34:10: fatal error: 'figpar.h' file not > >>>> found > >>> > >>> Until such time that you can get the tree to build without -j, don't > >>> use it. > >>> > >>> Now, the obvious question: do you have figpar.h in /usr/src? > >> Ugh... it's been a hectic day. Apparently it wasn't included in > >> Revision: 274349 > >> Last Changed Date: 2014-11-10 10:20:46 -0800 (Mon, 10 Nov 2014) > >> > >> :P > >> > >> I'll blow away src, and ports, and checkout what's ever available > >> now. Hoping it's *now* included. ;) > >> > >> Thank you *very* much rubbing my face in the obvious, Steve. :) > > Checked out the current version of src from head, that was available > > (r274365) and gave it another go. While it *did* have the missing file. The > > results were less than hoped for: > > This issue was fixed just a few hours ago by des@ > > Cheers! Thanks for the info, and the words of hope, Garrett. Indeed des@, *did* fix that, Thanks! But sadly. blowing away ports, src, and obj. Then checking out src r274382, and performing a buildworld. Although I got further. it bombed at: ===> usr.sbin/hyperv (all) ===> usr.sbin/hyperv/tools (all) cc -O2 -pipe -I/usr/src/usr.sbin/hyperv/tools/../../../sys/dev/hyperv/utiliti es -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k - W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold -style-definition -Wno-pointer-sign -c /usr/src/usr.sbin/hyperv/tools/../../.. /contrib/hyperv/tools/hv_kvp_daemon.c cc1: warnings being treated as errors /usr/src/usr.sbin/hyperv/tools/../../../contrib/hyperv/tools/hv_kvp_daemon.c: In function 'kvp_get_ip_info': /usr/src/usr.sbin/hyperv/tools/../../../contrib/hyperv/tools/hv_kvp_daemon.c:814 : warning: 'ip_buffer' may be used uninitialized in this function *** Error code 1 Stop. make[5]: stopped in /usr/src/usr.sbin/hyperv/tools *** Error code 1 Stop. make[4]: stopped in /usr/src/usr.sbin/hyperv *** Error code 1 Stop. make[3]: stopped in /usr/src/usr.sbin *** Error code 1 Stop. make[2]: stopped in /usr/src *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src :( Thanks again, Garrett. For taking the time to reply. --Chris From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 19:16:56 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 051E8C54; Tue, 11 Nov 2014 19:16:56 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B5811E9B; Tue, 11 Nov 2014 19:16:55 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::11d7:aebc:8d98:3fd1] (unknown [IPv6:2001:7b8:3a7:0:11d7:aebc:8d98:3fd1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 33C7FB80A; Tue, 11 Nov 2014 20:16:52 +0100 (CET) Subject: Re: Changing timezone without reboot/restarting each service? Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Content-Type: multipart/signed; boundary="Apple-Mail=_44FEAC56-EED7-44A1-B485-057EA3DB1CB7"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b1 From: Dimitry Andric In-Reply-To: <1415676518.1517572.189478341.09FB6AE5@webmail.messagingengine.com> Date: Tue, 11 Nov 2014 20:16:37 +0100 Message-Id: <2C79EC19-7271-4AC1-B9F8-B2992993823A@FreeBSD.org> References: <5460B143.3010004@FreeBSD.org> <1415676518.1517572.189478341.09FB6AE5@webmail.messagingengine.com> To: Mark Felder X-Mailer: Apple Mail (2.1990.1) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 19:16:56 -0000 --Apple-Mail=_44FEAC56-EED7-44A1-B485-057EA3DB1CB7 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 11 Nov 2014, at 04:28, Mark Felder wrote: > > On Mon, Nov 10, 2014, at 06:36, Lev Serebryakov wrote: >> >> After changing timezones in Russia (with replacing /etc/localtime >> with new file), I found that cron works in "old" timezone till >> restart. And all other services do the same, but cron is most obvious >> here :) >> >> Looks like libc reads timezone only once and it could not be chamged >> for process without restart (which leads to, effectivly, restart of >> whole server). >> >> Is it known problem? I think, it should be fixed somehow. I >> understand, that re-check timezone file on each time-related call >> could be expensive, though :( >> > > I think this was one of the crowning achievements of systemd, but I'm > sure someone can come up with something much more sane than that to > address this problem. Actually, it isn't: http://www.freedesktop.org/wiki/Software/systemd/timedated/ This reads "Note that this service will not inform you about system time changes. Use timerfd() with CLOCK_REALTIME and TFD_TIMER_CANCEL_ON_SET for that." So it mostly looks like a shared service to provide the graphical time control panel for GNOME. -Dimitry --Apple-Mail=_44FEAC56-EED7-44A1-B485-057EA3DB1CB7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.26 iEYEARECAAYFAlRiYKMACgkQsF6jCi4glqMfGQCfX1DsPyWQxtwMQz9moT7zefZf lEcAoP3rEsSlVX6eGRBv4ywr74QLrnWW =w58R -----END PGP SIGNATURE----- --Apple-Mail=_44FEAC56-EED7-44A1-B485-057EA3DB1CB7-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 19:21:52 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0BE4ADC1; Tue, 11 Nov 2014 19:21:52 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B8178F5A; Tue, 11 Nov 2014 19:21:51 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::11d7:aebc:8d98:3fd1] (unknown [IPv6:2001:7b8:3a7:0:11d7:aebc:8d98:3fd1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 86DB3B80A; Tue, 11 Nov 2014 20:21:49 +0100 (CET) Subject: Re: Unable to build world w/o clang on 11 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Content-Type: multipart/signed; boundary="Apple-Mail=_337D66B4-7CFC-4787-9528-CD16300F939A"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b1 From: Dimitry Andric In-Reply-To: <7854f93b2c7110c1deb38790449e5977@ultimatedns.net> Date: Tue, 11 Nov 2014 20:21:48 +0100 Message-Id: <788FBCF1-92E4-4A47-9A13-CC3B604501E5@FreeBSD.org> References: <20141111032231.GA3751@troutmask.apl.washington.edu> <8a1fd922bfe9a1c28726e82230c2cced@ultimatedns.net> <, > <057607CB-91DF-4C0D-AB26-330D157755F3@gmail.com> <7854f93b2c7110c1deb38790449e5977@ultimatedns.net> To: Chris H X-Mailer: Apple Mail (2.1990.1) Cc: FreeBSD toolchain , FreeBSD CURRENT , Garrett Cooper X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 19:21:52 -0000 --Apple-Mail=_337D66B4-7CFC-4787-9528-CD16300F939A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 11 Nov 2014, at 20:04, Chris H wrote: ... > But sadly. blowing away ports, src, and obj. Then checking out > src r274382, and performing a buildworld. Although I got further. > it bombed at: >=20 > =3D=3D=3D> usr.sbin/hyperv (all) > =3D=3D=3D> usr.sbin/hyperv/tools (all) > cc -O2 -pipe > -I/usr/src/usr.sbin/hyperv/tools/../../../sys/dev/hyperv/utiliti > es -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wall = -Wno-format-y2k > - > W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith > -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow = -Wunused-parameter > -Wcast-align -Wchar-subscripts -Winline -Wnested-externs = -Wredundant-decls > -Wold > -style-definition -Wno-pointer-sign -c > /usr/src/usr.sbin/hyperv/tools/../../.. > /contrib/hyperv/tools/hv_kvp_daemon.c > cc1: warnings being treated as errors > = /usr/src/usr.sbin/hyperv/tools/../../../contrib/hyperv/tools/hv_kvp_daemon= .c: > In > function 'kvp_get_ip_info': > = /usr/src/usr.sbin/hyperv/tools/../../../contrib/hyperv/tools/hv_kvp_daemon= .c:814 > : warning: 'ip_buffer' may be used uninitialized in this function Yep, this is another false positive from gcc. I've mailed a proposed workaround to Xin Li, but for now, if you compile world and kernel with gcc, use NO_WERROR=3D and WERROR=3D in your make.conf. Especially the kernel still needs a bunch of fixes to make it work with gcc again. It's a pity the gcc tinderboxes have been taken offline. Maybe this can be added to the FreeBSD Jenkins instance now? -Dimitry --Apple-Mail=_337D66B4-7CFC-4787-9528-CD16300F939A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.26 iEYEARECAAYFAlRiYcwACgkQsF6jCi4glqPX0wCg7hs/5Hv0DjrvPQY/ZthO34TK XdQAn3HSQ2m1VaerVXk6m+zT5Uz/LF2c =mt8U -----END PGP SIGNATURE----- --Apple-Mail=_337D66B4-7CFC-4787-9528-CD16300F939A-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 19:28:39 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F4D7F96 for ; Tue, 11 Nov 2014 19:28:39 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0A822FA7 for ; Tue, 11 Nov 2014 19:28:39 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8B0B9B941; Tue, 11 Nov 2014 14:28:37 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: r273918 buildworld broke at semaphore Date: Tue, 11 Nov 2014 13:33:05 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <1414786086662-5961241.post@n5.nabble.com> In-Reply-To: <1414786086662-5961241.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201411111333.05910.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 11 Nov 2014 14:28:37 -0500 (EST) Cc: Beeblebrox X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 19:28:39 -0000 On Friday, October 31, 2014 4:08:06 pm Beeblebrox wrote: > First breakage in a long time. Error is: > > In file included from cancelpoints_sem_new.c:47: > /usr/src/lib/libc/../../include/semaphore.h:41:16: error: field has > incomplete type 'struct _usem2' > struct _usem2 _kern; > ^ > /usr/src/lib/libc/../../include/semaphore.h:41:9: note: forward declaration > of 'struct _usem2' > struct _usem2 _kern; > ^ > cancelpoints_sem_new.c:66:33: error: use of undeclared identifier > 'USEM_MAX_COUNT' > _Static_assert(SEM_VALUE_MAX <= USEM_MAX_COUNT, "SEM_VALUE_MAX too large"); > ^ > cancelpoints_sem_new.c:335:15: warning: implicit declaration of function > 'USEM_COUNT' is invalid in C99 [-Wimplicit-function-declaration] > *sval = (int)USEM_COUNT(sem->_kern._count); > ^ > cancelpoints_sem_new.c:342:23: error: use of undeclared identifier > 'UMTX_OP_SEM2_WAKE' > return _umtx_op(sem, UMTX_OP_SEM2_WAKE, 0, NULL, NULL); > ^ > cancelpoints_sem_new.c:361:23: error: use of undeclared identifier > 'UMTX_OP_SEM2_WAIT' > return _umtx_op(sem, UMTX_OP_SEM2_WAIT, 0, > ^ > cancelpoints_sem_new.c:445:14: error: use of undeclared identifier > 'USEM_HAS_WAITERS' > if (count & USEM_HAS_WAITERS) > ^ > 1 warning and 5 errors generated. Seems like your tree is not fully up to date? The changes to sem_new.c were committed in the same commit as the changes to sys/umtx.h. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 19:28:44 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C4BE117; Tue, 11 Nov 2014 19:28:44 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4661BFA9; Tue, 11 Nov 2014 19:28:44 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 19883B97E; Tue, 11 Nov 2014 14:28:43 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: r273165. ZFS ARC: possible memory leak to Inact Date: Tue, 11 Nov 2014 13:47:59 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <5458c456.25b9340a.54d5.6310SMTPIN_ADDED_BROKEN@mx.google.com> <5458CCB6.7020602@multiplay.co.uk> <5459F372.1010405@FreeBSD.org> In-Reply-To: <5459F372.1010405@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201411111347.59169.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 11 Nov 2014 14:28:43 -0500 (EST) Cc: Steven Hartland , Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 19:28:44 -0000 On Wednesday, November 05, 2014 4:52:50 am Andriy Gapon wrote: > On 04/11/2014 14:55, Steven Hartland wrote: > > This is likely spikes in uma zones used by ARC. > > > > The VM doesn't ever clean uma zones unless it hits a low memory condition, which > > explains why your little script helps. > > > > Check the output of vmstat -z to confirm. > > Steve, > > this is nonsense :-) You know perfectly well that UMA memory is Wired not Inactive. Grab the code at www.freebsd.org/~jhb/vm_objects/. Build and load the kld and then use the vm_objects binary to generate a list of the active VM objects in the system along with counts of how many active / inactive pages each object contains. For your case with lots of inactive memory, you probably want something like 'vm_objects | sort -n -k 2'. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 19:28:48 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9CBDB214; Tue, 11 Nov 2014 19:28:48 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7682DFAC; Tue, 11 Nov 2014 19:28:48 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4A8B7B94E; Tue, 11 Nov 2014 14:28:47 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org, lev@freebsd.org Subject: Re: Changing timezone without reboot/restarting each service? Date: Tue, 11 Nov 2014 13:57:40 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <5460B143.6080206@FreeBSD.org> In-Reply-To: <5460B143.6080206@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201411111357.40061.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 11 Nov 2014 14:28:47 -0500 (EST) Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 19:28:48 -0000 On Monday, November 10, 2014 7:36:19 am Lev Serebryakov wrote: > > After changing timezones in Russia (with replacing /etc/localtime > with new file), I found that cron works in "old" timezone till > restart. And all other services do the same, but cron is most obvious > here :) > > Looks like libc reads timezone only once and it could not be chamged > for process without restart (which leads to, effectivly, restart of > whole server). > > Is it known problem? I think, it should be fixed somehow. I > understand, that re-check timezone file on each time-related call > could be expensive, though :( In practice, timezone changes are very rare, so rechecking the file is quite expensive to do. I think having to restart processes is fine for this. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 19:30:13 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DABB7602; Tue, 11 Nov 2014 19:30:13 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2F4C9CC; Tue, 11 Nov 2014 19:30:12 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sABJUR5W015809; Tue, 11 Nov 2014 11:30:27 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: Dimitry Andric In-Reply-To: <788FBCF1-92E4-4A47-9A13-CC3B604501E5@FreeBSD.org> References: <20141111032231.GA3751@troutmask.apl.washington.edu> <8a1fd922bfe9a1c28726e82230c2cced@ultimatedns.net> <, > <057607CB-91DF-4C0D-AB26-330D157755F3@gmail.com> <7854f93b2c7110c1deb38790449e5977@ultimatedns.net>, <788FBCF1-92E4-4A47-9A13-CC3B604501E5@FreeBSD.org> From: "Chris H" Subject: Re: Unable to build world w/o clang on 11 Date: Tue, 11 Nov 2014 11:30:27 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit Cc: FreeBSD toolchain , FreeBSD CURRENT , Garrett Cooper X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 19:30:14 -0000 On Tue, 11 Nov 2014 20:21:48 +0100 Dimitry Andric wrote > On 11 Nov 2014, at 20:04, Chris H wrote: > ... > > But sadly. blowing away ports, src, and obj. Then checking out > > src r274382, and performing a buildworld. Although I got further. > > it bombed at: > > > > ===> usr.sbin/hyperv (all) > > ===> usr.sbin/hyperv/tools (all) > > cc -O2 -pipe > > -I/usr/src/usr.sbin/hyperv/tools/../../../sys/dev/hyperv/utiliti > > es -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall > > -Wno-format-y2k - > > W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > > -Wpointer-arith > > -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow > > -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs > > -Wredundant-decls -Wold > > -style-definition -Wno-pointer-sign -c > > /usr/src/usr.sbin/hyperv/tools/../../.. > > /contrib/hyperv/tools/hv_kvp_daemon.c > > cc1: warnings being treated as errors > > > > /usr/src/usr.sbin/hyperv/tools/../../../contrib/hyperv/tools/hv_kvp_daemon.c: > > In > > function 'kvp_get_ip_info': > > > > /usr/src/usr.sbin/hyperv/tools/../../../contrib/hyperv/tools/hv_kvp_daemon.c: > > 814 : warning: 'ip_buffer' may be used uninitialized in this function > > Yep, this is another false positive from gcc. I've mailed a proposed > workaround to Xin Li, but for now, if you compile world and kernel with > gcc, use NO_WERROR= and WERROR= in your make.conf. Especially the > kernel still needs a bunch of fixes to make it work with gcc again. > > It's a pity the gcc tinderboxes have been taken offline. Maybe this can > be added to the FreeBSD Jenkins instance now? Thank you *very* much, Dimitry. For the informative reply. Yes. I agree, adding a task for Jenkins seems like a *very* good idea. Well, it looks like a real gamble not going with defaults, for now. I guess attempts using gcc as base compiler is off the table, for now. This must really hit some of the other ARCHS pretty hard. I can't imagine trying to develop under these circumstances. Here's hoping for improvements in this area soon! Thanks again, Dimitry. --Chris > > -Dimitry From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 19:46:31 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5DC084F5; Tue, 11 Nov 2014 19:46:31 +0000 (UTC) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) by mx1.freebsd.org (Postfix) with ESMTP id 3855924B; Tue, 11 Nov 2014 19:46:31 +0000 (UTC) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id B8F615A9F0C; Tue, 11 Nov 2014 19:46:30 +0000 (UTC) Date: Tue, 11 Nov 2014 19:46:30 +0000 From: Brooks Davis To: John Baldwin Subject: Re: Changing timezone without reboot/restarting each service? Message-ID: <20141111194630.GC11089@spindle.one-eyed-alien.net> References: <5460B143.6080206@FreeBSD.org> <201411111357.40061.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: <201411111357.40061.jhb@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@freebsd.org, lev@freebsd.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 19:46:31 -0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 11, 2014 at 01:57:40PM -0500, John Baldwin wrote: > On Monday, November 10, 2014 7:36:19 am Lev Serebryakov wrote: > >=20 > > After changing timezones in Russia (with replacing /etc/localtime > > with new file), I found that cron works in "old" timezone till > > restart. And all other services do the same, but cron is most obvious > > here :) > >=20 > > Looks like libc reads timezone only once and it could not be chamged > > for process without restart (which leads to, effectivly, restart of > > whole server). > >=20 > > Is it known problem? I think, it should be fixed somehow. I > > understand, that re-check timezone file on each time-related call > > could be expensive, though :( >=20 > In practice, timezone changes are very rare, so rechecking the file is > quite expensive to do. I think having to restart processes is fine for t= his. For cron it seems like a neglegable cost as it has to check a file and a directory at each interval. For most other things it seems like a waste of resources to check. Even on systems like MacOS where this is solved better, lots of behavior is application dependent. For example, current versions of Omni Focus behave very oddly when the timezone changes underneath them. In practice you need to restart the application when timezones change (such as after a flight). Just making libc aware isn't a magic bullet. -- Brooks --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlRiZ5YACgkQXY6L6fI4GtTp7gCeNUokksNWRSwGoC5V687AOMLJ y0cAn1Fm999Ua9pVEYbZ2A3stc2gfw6/ =OkpH -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 20:17:57 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EFF2316A for ; Tue, 11 Nov 2014 20:17:57 +0000 (UTC) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BF3557C6 for ; Tue, 11 Nov 2014 20:17:57 +0000 (UTC) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 54645205C0 for ; Tue, 11 Nov 2014 15:08:33 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute4.internal (MEProxy); Tue, 11 Nov 2014 15:08:33 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:x-sasl-enc:from:to:cc :mime-version:content-transfer-encoding:content-type:in-reply-to :references:subject:date; s=smtpout; bh=GNmYyttTk34fBk3aoRqM5Gh5 kyk=; b=mcLryOvIc4r0/alU4Hzeje8g1ir6+MA0glWGLiPbQ3y5zcc5c4QJfUjt Lneebytm0UHS0277J5ZhGiN2i4v5DR6GUGLgkMy54ZJfkbZ9eu4JwSEFzQ0ptg1K sWZK8ncaIClsjPRmjRzHNuLUEp7GPZzypnUPmx11BF5tw0mdaCk= Received: by web3.nyi.internal (Postfix, from userid 99) id 3301910E90A; Tue, 11 Nov 2014 15:08:33 -0500 (EST) Message-Id: <1415736513.1756131.189800941.79451E0C@webmail.messagingengine.com> X-Sasl-Enc: zOYb/QgP24Fn7ip8LiF1U+U67JGaGQqrnxl8uS6GEGwl 1415736513 From: Mark Felder To: Dimitry Andric MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-9183bd94 In-Reply-To: <2C79EC19-7271-4AC1-B9F8-B2992993823A@FreeBSD.org> References: <5460B143.3010004@FreeBSD.org> <1415676518.1517572.189478341.09FB6AE5@webmail.messagingengine.com> <2C79EC19-7271-4AC1-B9F8-B2992993823A@FreeBSD.org> Subject: Re: Changing timezone without reboot/restarting each service? Date: Tue, 11 Nov 2014 14:08:33 -0600 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 20:17:58 -0000 On Tue, Nov 11, 2014, at 13:16, Dimitry Andric wrote: > On 11 Nov 2014, at 04:28, Mark Felder wrote: > > > > On Mon, Nov 10, 2014, at 06:36, Lev Serebryakov wrote: > >> > >> After changing timezones in Russia (with replacing /etc/localtime > >> with new file), I found that cron works in "old" timezone till > >> restart. And all other services do the same, but cron is most obvious > >> here :) > >> > >> Looks like libc reads timezone only once and it could not be chamged > >> for process without restart (which leads to, effectivly, restart of > >> whole server). > >> > >> Is it known problem? I think, it should be fixed somehow. I > >> understand, that re-check timezone file on each time-related call > >> could be expensive, though :( > >> > > > > I think this was one of the crowning achievements of systemd, but I'm > > sure someone can come up with something much more sane than that to > > address this problem. > > Actually, it isn't: > http://www.freedesktop.org/wiki/Software/systemd/timedated/ > > This reads "Note that this service will not inform you about system time > changes. Use timerfd() with CLOCK_REALTIME and TFD_TIMER_CANCEL_ON_SET > for that." > > So it mostly looks like a shared service to provide the graphical time > control panel for GNOME. > Aha, I guess the article I read was as reliable as jamming all that code into PID 1. :-) From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 20:18:09 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9796D26B; Tue, 11 Nov 2014 20:18:09 +0000 (UTC) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6AEF57CC; Tue, 11 Nov 2014 20:18:08 +0000 (UTC) Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id CC.0A.12968.00F62645; Tue, 11 Nov 2014 12:18:08 -0800 (PST) X-AuditID: 11973e12-f79306d0000032a8-ab-54626f00a996 Received: from [17.149.228.80] (Unknown_Domain [17.149.228.80]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id A9.A7.17790.50F62645; Tue, 11 Nov 2014 12:18:13 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Changing timezone without reboot/restarting each service? From: Charles Swiger In-Reply-To: <201411111357.40061.jhb@freebsd.org> Date: Tue, 11 Nov 2014 12:16:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5330A42B-CBCA-4349-BE12-777401272050@mac.com> References: <5460B143.6080206@FreeBSD.org> <201411111357.40061.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1878.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUi2FAYrMuQnxRi8PS9ssWEKz+YLOa8+cBk sffIdWaL3lUbWR1YPGZ8ms8SwBjFZZOSmpNZllqkb5fAlXHyUQt7wWquihcnLzM3MM7i6GLk 5JAQMJGYN+0LM4QtJnHh3nq2LkYuDiGBvYwSV+ftZIYpuntyHyOILSTQyyTRvt8HxGYW0JK4 8e8lE4jNK2AgsWTXJrB6YQE3iQPzV7B2MXJwsAmoSUyYyAMS5hQwlHi1ZiMLiM0ioCrxvvkG E0gJs0C0xL7jRRATtSWWLXzNDDHRSuLWxXvMEFv9JXp3nWYBKRcRUJKY+k0N4jB5iQ8fjrOD XCwh8JNV4vTZNcwTGIVmITluFpLjZiFZsYCReRWjUG5iZo5uZp6JXmJBQU6qXnJ+7iZGUBhP txPawXhqldUhRgEORiUeXg3/xBAh1sSy4srcQ4zSHCxK4rxLcoBCAumJJanZqakFqUXxRaU5 qcWHGJk4OKUaGE1qlvq2TVrAUhHHtjzzsvaya6zu12NKrxp92Mn6syDnVd7v/s9lUQpzf6YY y2hP3tOq4bnWelPr6cIfBpHXk25fVUi95tt/QtFB7NuliKOzOTOnee1m6L6s+k1Mr6NEX2vq RAZOTUcZ7YDnOtfvhrrJsX3bwZpzm/FXIoM2a5XMmY7N+v+WKrEUZyQaajEXFScCAKjeI9lE AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUiOPVJgC5rflKIwf4/khYTrvxgspjz5gOT xd4j15kteldtZHVg8ZjxaT5LAGMUl01Kak5mWWqRvl0CV8bJRy3sBau5Kl6cvMzcwDiLo4uR k0NCwETi7sl9jBC2mMSFe+vZQGwhgV4mifb9PiA2s4CWxI1/L5lAbF4BA4kluzYxg9jCAm4S B+avYO1i5OBgE1CTmDCRByTMKWAo8WrNRhYQm0VAVeJ98w0mkBJmgWiJfceLICZqSyxb+JoZ YqKVxK2L95ghtvpL9O46zQJSLiKgJDH1mxrEYfISHz4cZ5/AyD8LyT2zkNwzC8nUBYzMqxgF ilJzEiuN9RILCnJS9ZLzczcxgsKuoTB4B+OfZVaHGAU4GJV4eDX8E0OEWBPLiitzDzFKcDAr ifAyhCWFCPGmJFZWpRblxxeV5qQWH2KU5mBREudNiI4NERJITyxJzU5NLUgtgskycXBKNTBy C1z1OiP7hp1/Zs73tUqX28+dM9Jb0/Rb7y8r+xXn45bZyyaq2z+/rxUUfVFg0qOQoEIZBvX9 Bc5W2UnyqqKbgvzZv+Z0HBZItKl8YyF8m/fmwkMud0o8fz6sFK7bd+7bEeHIrnAxS0XD7I39 x58sFU//2KrGbD/x66J4w2NWVcc3tTDosCqxFGckGmoxFxUnAgCRsTU5NwIAAA== Cc: freebsd-current@freebsd.org, lev@freebsd.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 20:18:09 -0000 On Nov 11, 2014, at 10:57 AM, John Baldwin wrote: > On Monday, November 10, 2014 7:36:19 am Lev Serebryakov wrote: >>=20 >> After changing timezones in Russia (with replacing /etc/localtime >> with new file), I found that cron works in "old" timezone till >> restart. And all other services do the same, but cron is most obvious >> here :) >>=20 >> Looks like libc reads timezone only once and it could not be chamged >> for process without restart (which leads to, effectivly, restart of >> whole server). >>=20 >> Is it known problem? I think, it should be fixed somehow. I >> understand, that re-check timezone file on each time-related call >> could be expensive, though :( >=20 > In practice, timezone changes are very rare, so rechecking the file is > quite expensive to do. I think having to restart processes is fine = for this. In theory, timezone changes should be very rare. We've actually had about ten TZ updates in 2014; the most recent was FET = -> MSK for Belarus plus minor tweaks to IDT vs ICT. If you're working within = the scope of a single country, I suspect that one could ignore the bulk of TZ = updates and be fine most of the time. If you're world-wide, however, TZ update frequency becomes more = noticeable.... Regards, --=20 -Chuck From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 20:49:28 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 20BCED81; Tue, 11 Nov 2014 20:49:28 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EE125AEA; Tue, 11 Nov 2014 20:49:27 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D731EB999; Tue, 11 Nov 2014 15:49:26 -0500 (EST) From: John Baldwin To: Charles Swiger Subject: Re: Changing timezone without reboot/restarting each service? Date: Tue, 11 Nov 2014 15:47:37 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <5460B143.6080206@FreeBSD.org> <201411111357.40061.jhb@freebsd.org> <5330A42B-CBCA-4349-BE12-777401272050@mac.com> In-Reply-To: <5330A42B-CBCA-4349-BE12-777401272050@mac.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201411111547.38001.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 11 Nov 2014 15:49:26 -0500 (EST) Cc: freebsd-current@freebsd.org, lev@freebsd.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 20:49:28 -0000 On Tuesday, November 11, 2014 3:16:19 pm Charles Swiger wrote: > On Nov 11, 2014, at 10:57 AM, John Baldwin wrote: > > On Monday, November 10, 2014 7:36:19 am Lev Serebryakov wrote: > >> > >> After changing timezones in Russia (with replacing /etc/localtime > >> with new file), I found that cron works in "old" timezone till > >> restart. And all other services do the same, but cron is most obvious > >> here :) > >> > >> Looks like libc reads timezone only once and it could not be chamged > >> for process without restart (which leads to, effectivly, restart of > >> whole server). > >> > >> Is it known problem? I think, it should be fixed somehow. I > >> understand, that re-check timezone file on each time-related call > >> could be expensive, though :( > > > > In practice, timezone changes are very rare, so rechecking the file is > > quite expensive to do. I think having to restart processes is fine for this. > > In theory, timezone changes should be very rare. > > We've actually had about ten TZ updates in 2014; the most recent was FET -> MSK > for Belarus plus minor tweaks to IDT vs ICT. If you're working within the scope > of a single country, I suspect that one could ignore the bulk of TZ updates and > be fine most of the time. > > If you're world-wide, however, TZ update frequency becomes more noticeable.... The vast majority of updates are historical changes however. Having used a timezone-aware version of cron for an international company so we can schedule jobs across multiple timezones for a single machine (times N machines scattered around the globe) for the last 4 or 5 years, FET -> MSK was the first time we had a timezone change in that span that actually impacted our operations (and we've just restarted cron / rebooted to cope). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 21:20:19 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E01526E1 for ; Tue, 11 Nov 2014 21:20:19 +0000 (UTC) Received: from host64.kissl.de (host64.kissl.de [213.239.241.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.shmhost.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A00FEE6A for ; Tue, 11 Nov 2014 21:20:19 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by host64.kissl.de (Postfix) with ESMTP id F1A42B010B7; Tue, 11 Nov 2014 22:13:56 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at host64.kissl.de Received: from host64.kissl.de ([127.0.0.1]) by localhost (host64.kissl.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9tZTeckNu2L; Tue, 11 Nov 2014 22:13:56 +0100 (CET) Received: from [192.168.0.11] (unknown [95.91.254.245]) (Authenticated sender: web104p1) by host64.kissl.de (Postfix) with ESMTPSA id B3A7EB010B6; Tue, 11 Nov 2014 22:13:56 +0100 (CET) From: Franco Fichtner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: netmap: extension to store user data per packet/slot? Date: Tue, 11 Nov 2014 22:13:54 +0100 Message-Id: <560E07EA-2506-487E-88DD-E2B9F7ED9792@lastsummer.de> To: Luigi Rizzo Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 21:20:20 -0000 Hi Luigi, hi all, so I was running into logistics issues with netmap(4) with regard to zero-copy and redirection through pipes: working on a load-balancing framework revealed that it is very hard to track a packet's origins to later move it onward to the respective outgoing interface, be it another device or the host stack. Long story short: user data needs to be stored for the packet buffer or slot. There are three ways that I can see so far: (1) Allocate a netmap pipe pair for each interface, in case of transparent mode also a pipe for the host stack each. That's a lot of pipes and most likely insane, but it won't extend the ABI. (2) Store the additional data in the actual buffer. That is sort of ok, but seems sluggish WRT cache behaviour -- maybe the buffer won't be read but it needs to be written. Sure, we can store it at the end, but there already resides the packet timestamp if enabled (if I recall correctly). Wouldn't extend the ABI per se, but might collide with the timestamping.... (3) Make room in struct netmap_slot itself like this: diff --git a/sys/net/netmap.h b/sys/net/netmap.h index 15ebf73..d0a9c0e 100644 --- a/sys/net/netmap.h +++ b/sys/net/netmap.h @@ -147,6 +147,7 @@ struct netmap_slot { uint16_t len; /* length for this slot */ uint16_t flags; /* buf changed, etc. */ uint64_t ptr; /* pointer for indirect buffers */ + uint64_t userdata; /* reserved storage for caller */ }; It could also be broken down in two fields with uint32_t each; not sure what would be more sensible. This of course requires an API bump, although it should be backwards compatible. Any feedback on this is highly appreciated. Cheers, Franco From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 21:22:46 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF787912; Tue, 11 Nov 2014 21:22:46 +0000 (UTC) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6B4A6EA5; Tue, 11 Nov 2014 21:22:46 +0000 (UTC) Received: by mail-vc0-f170.google.com with SMTP id hq12so2216872vcb.1 for ; Tue, 11 Nov 2014 13:22:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ri3Ans/6jnKnokNqlyzKvqdnMEiegIKjRxZj0meZDMY=; b=T8XwKA5CEfCLDX21izD2bCqESyR+We+UmjpEx09IqMhcL/0P2pMwSCnoFvnsYADiR0 XdCLxLHDYuLcXpXLkYYQqyodxO1OcEbQyUcM107L54kBqQVy4RMPtgUl/X71J6QdJ4py V3ChtWxq3AMJ3SDdSngthZM2gCBfHn0MBlCzbzEdwksHXMuOH1q99EVHfPr53PDJGi17 +OQQCHC05iYTKsoiHvEB4UV3FAc/NiOUirdBT59k9yvqsvlrW/Iha8glsnPOfoET/pDI N92/3BEROil/FekDtwDp36h9xfyWBDw5IVjYSYX6mLm0ZWwFzqhyP1JuzMaY9AWbz8TT BiRw== X-Received: by 10.52.66.142 with SMTP id f14mr2974792vdt.91.1415740965481; Tue, 11 Nov 2014 13:22:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.136.76 with HTTP; Tue, 11 Nov 2014 13:22:05 -0800 (PST) In-Reply-To: <201411111333.05910.jhb@freebsd.org> References: <1414786086662-5961241.post@n5.nabble.com> <201411111333.05910.jhb@freebsd.org> From: Henry Hu Date: Tue, 11 Nov 2014 16:22:05 -0500 Message-ID: Subject: Re: r273918 buildworld broke at semaphore To: John Baldwin Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD CURRENT , Beeblebrox X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 21:22:46 -0000 On Tue, Nov 11, 2014 at 1:33 PM, John Baldwin wrote: > On Friday, October 31, 2014 4:08:06 pm Beeblebrox wrote: > > First breakage in a long time. Error is: > > > > In file included from cancelpoints_sem_new.c:47: > > /usr/src/lib/libc/../../include/semaphore.h:41:16: error: field has > > incomplete type 'struct _usem2' > > struct _usem2 _kern; > > ^ > > /usr/src/lib/libc/../../include/semaphore.h:41:9: note: forward > declaration > > of 'struct _usem2' > > struct _usem2 _kern; > > ^ > > cancelpoints_sem_new.c:66:33: error: use of undeclared identifier > > 'USEM_MAX_COUNT' > > _Static_assert(SEM_VALUE_MAX <= USEM_MAX_COUNT, "SEM_VALUE_MAX too > large"); > > ^ > > cancelpoints_sem_new.c:335:15: warning: implicit declaration of function > > 'USEM_COUNT' is invalid in C99 [-Wimplicit-function-declaration] > > *sval = (int)USEM_COUNT(sem->_kern._count); > > ^ > > cancelpoints_sem_new.c:342:23: error: use of undeclared identifier > > 'UMTX_OP_SEM2_WAKE' > > return _umtx_op(sem, UMTX_OP_SEM2_WAKE, 0, NULL, NULL); > > ^ > > cancelpoints_sem_new.c:361:23: error: use of undeclared identifier > > 'UMTX_OP_SEM2_WAIT' > > return _umtx_op(sem, UMTX_OP_SEM2_WAIT, 0, > > ^ > > cancelpoints_sem_new.c:445:14: error: use of undeclared identifier > > 'USEM_HAS_WAITERS' > > if (count & USEM_HAS_WAITERS) > > ^ > > 1 warning and 5 errors generated. > > Seems like your tree is not fully up to date? The changes to sem_new.c > were > committed in the same commit as the changes to sys/umtx.h. Maybe it's another problem. buildworld may be picking up umtx.h from /usr/include which is the old version. > > -- > John Baldwin > _______________________________________________ > 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" > -- Cheers, Henry From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 21:22:51 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4FBAAA11 for ; Tue, 11 Nov 2014 21:22:51 +0000 (UTC) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D4CDFEAA for ; Tue, 11 Nov 2014 21:22:50 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id y19so1806032wgg.35 for ; Tue, 11 Nov 2014 13:22:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VANc12bKrToj/a9tBkLITtJP93lC1DPxplG2M8rh2y4=; b=uoe4dugd0Ga5gwYE/7frH+re7dgpdo+Leypb1CsGR1s4q1u+Bn3HGwoCIHPK9OYCkN hb7UW6Q3r2PgsF+L9KyzH3ypykqdTSN4CiuEH2WRwtVu72nhpmXl4Xm22N/eqElXUgSH R9M3N/2VWB4hX2LfvfDAQRgppaTTjRvWoMjvnbnmpurY7xizb+ODWp0YAnqh33hfGrUz qv930XRPAPvRe5EsvUfGpFwpBiJ+APiYd+DqBReM5jN6eePeqJ3P9xCzngIMDP10uvlN 02Bn9ED6SEFyC91D6lXtpB8Fhh8Gvg2p75vvv2FUviLXOutnRbdH6A00yreA25vClP7b 2XOQ== MIME-Version: 1.0 X-Received: by 10.194.85.83 with SMTP id f19mr34891727wjz.20.1415740969351; Tue, 11 Nov 2014 13:22:49 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Tue, 11 Nov 2014 13:22:49 -0800 (PST) In-Reply-To: <560E07EA-2506-487E-88DD-E2B9F7ED9792@lastsummer.de> References: <560E07EA-2506-487E-88DD-E2B9F7ED9792@lastsummer.de> Date: Tue, 11 Nov 2014 13:22:49 -0800 X-Google-Sender-Auth: Iw_H5kQrd0kmTrryznHY3vBqDrs Message-ID: Subject: Re: netmap: extension to store user data per packet/slot? From: Adrian Chadd To: Franco Fichtner Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current , Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 21:22:51 -0000 ... I'm confused. Do you have the slot id already, right? Why not allocate an array of userdata pointers somewhere else and just use the netmap slot id as an indirection into that? -adrian On 11 November 2014 13:13, Franco Fichtner wrote: > Hi Luigi, > hi all, > > so I was running into logistics issues with netmap(4) > with regard to zero-copy and redirection through pipes: > working on a load-balancing framework revealed that it > is very hard to track a packet's origins to later move > it onward to the respective outgoing interface, be it > another device or the host stack. > > Long story short: user data needs to be stored for the > packet buffer or slot. > > There are three ways that I can see so far: > > (1) Allocate a netmap pipe pair for each interface, > in case of transparent mode also a pipe for the > host stack each. That's a lot of pipes and > most likely insane, but it won't extend the ABI. > > (2) Store the additional data in the actual buffer. > That is sort of ok, but seems sluggish WRT cache > behaviour -- maybe the buffer won't be read but > it needs to be written. Sure, we can store it at > the end, but there already resides the packet > timestamp if enabled (if I recall correctly). > Wouldn't extend the ABI per se, but might collide > with the timestamping.... > > (3) Make room in struct netmap_slot itself like this: > > diff --git a/sys/net/netmap.h b/sys/net/netmap.h > index 15ebf73..d0a9c0e 100644 > --- a/sys/net/netmap.h > +++ b/sys/net/netmap.h > @@ -147,6 +147,7 @@ struct netmap_slot { > uint16_t len; /* length for this slot */ > uint16_t flags; /* buf changed, etc. */ > uint64_t ptr; /* pointer for indirect buffers */ > + uint64_t userdata; /* reserved storage for caller */ > }; > > It could also be broken down in two fields with uint32_t > each; not sure what would be more sensible. This of course > requires an API bump, although it should be backwards > compatible. > > Any feedback on this is highly appreciated. > > > Cheers, > Franco > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 21:39:34 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 749D017A for ; Tue, 11 Nov 2014 21:39:34 +0000 (UTC) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0383651 for ; Tue, 11 Nov 2014 21:39:33 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id n3so2966959wiv.14 for ; Tue, 11 Nov 2014 13:39:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb.com; s=google; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=RdPmRW1lNSWpew06mJaHNeK7vg8taLOdlUfcV8aNLGM=; b=QKe6brwhc5fFXlZHI5NWaRJl0MLTIlXgziIgE7GM1y+J+5xoBHpRC03oiG3DD6Zijk zgvVuoh/q24wX3am5kKaPLue7cmnb6bY3sQqufaOwcWybKNR9r0lKc7Na7bSExk0oe21 LO9p9oSXbO7jtmHCf7zOnSNBWgWR15D2MSFFs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RdPmRW1lNSWpew06mJaHNeK7vg8taLOdlUfcV8aNLGM=; b=hlg6n7QpJayb3wr911QXBfYAAhDG2A5MfNUHlN3WlhM0DCqpDf8oNtlPB/j7c70/mH WQJ2ZpZXqFYnxL7QTm7+aKBLWNFLBxXeOnbSV3e7Kr7ix089beFMkMeEUGMBxU72G+Pq 2EtR25PVcHvjkpyk26vj7RcG98WhVNOlZ01t6P40AXYDnx+pXYHt4hMwsBOEhj32jr0O JF4E5qgh79PZsrveC7U+Pjf8ofg2ROYD/Vxyk5De1ObP36ULThM+ouMlTtfZ49jX3gZI gwp0MuiSWlVrQ4fjZhY6fhh/pnEah6tomr6QasyRM11G4AbM6C9ZnCghuVrOpISiosYU Srog== X-Gm-Message-State: ALoCoQk29LAzuCCDGQnSKX+CU0ZjKFgbkwiCX6xy3/f37ucqDBeaIOg91Bd4Pjz/xcbmeQ/7Og/x X-Received: by 10.194.92.82 with SMTP id ck18mr57399317wjb.103.1415741972179; Tue, 11 Nov 2014 13:39:32 -0800 (PST) Received: from rsbsd.rsb ([31.200.21.116]) by mx.google.com with ESMTPSA id s2sm19105092wia.3.2014.11.11.13.39.30 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Nov 2014 13:39:31 -0800 (PST) Message-ID: <54628225.3060507@berentweb.com> Date: Tue, 11 Nov 2014 23:39:49 +0200 From: Beeblebrox User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: FreeBSD CURRENT Subject: Re: r273918 buildworld broke at semaphore References: <1414786086662-5961241.post@n5.nabble.com> <201411111333.05910.jhb@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 21:39:34 -0000 > Seems like your tree is not fully up to date? The changes to > sem_new.c were > committed in the same commit as the changes to sys/umtx.h. I deleted the entire contents of /usr/src, then did # svn co svn://svn.freebsd.org/base/head Buildworld breaks at same place (semaphore) This error AFAIK, was already combined with: http://freebsd.1045724.n5.nabble.com/r273910-build-failure-if-lt-sys-umtx-h-gt-is-out-of-date-td5961186.html Speaking of "out-of-date", http://freebsd.1045724.n5.nabble.com/version-number-error-with-ports-td5961642.html Regards. From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 21:41:20 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 56A6D29D; Tue, 11 Nov 2014 21:41:20 +0000 (UTC) Received: from host64.kissl.de (host64.kissl.de [213.239.241.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.shmhost.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 13CFC103; Tue, 11 Nov 2014 21:41:19 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by host64.kissl.de (Postfix) with ESMTP id 8D4B9B00ACF; Tue, 11 Nov 2014 22:41:18 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at host64.kissl.de Received: from host64.kissl.de ([127.0.0.1]) by localhost (host64.kissl.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id css7IlM5L5vO; Tue, 11 Nov 2014 22:41:18 +0100 (CET) Received: from [192.168.0.11] (unknown [95.91.254.245]) (Authenticated sender: web104p1) by host64.kissl.de (Postfix) with ESMTPSA id 3AF21B00ABD; Tue, 11 Nov 2014 22:41:18 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: netmap: extension to store user data per packet/slot? From: Franco Fichtner In-Reply-To: Date: Tue, 11 Nov 2014 22:41:16 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <560E07EA-2506-487E-88DD-E2B9F7ED9792@lastsummer.de> To: Adrian Chadd X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current , Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 21:41:20 -0000 Hi Adrian, On 11 Nov 2014, at 22:22, Adrian Chadd wrote: > ... I'm confused. Do you have the slot id already, right? Why not > allocate an array of userdata pointers somewhere else and just use the > netmap slot id as an indirection into that? The slot id is per ring and there are a lot of them. In case of zero-copy the slot changes at least 1. Consider two processes for the load balancing case. Process 1 attaches to the devices and Process 2 only has a a pipe pair for receiving and sending packets back to Process 1 after processing, because only that process has access to the real devices: em0, em1, etc. <--RX/TX--> Process 1 <--pipe pair--> Process 2 (Hardware) (Balancer) (Worker) There is no way to trace packet origin back to em0 or em1 after pushing the packets through the pipe pair unless either the pipes are unique for each device or there is another means to keep its state. Should, however, the buffer id be unique that would make it easy to do what you suggest, but I don't know the netmap(4) internals by heart. It seems a wee unnatural to rebuild tracing of packets in userland when netmap(4) has all the infrastructure needed to deal with this effectively, but I'm not opposed to doing that to avoid API/ABI changes. Speaking of those, should volatile internals change regarding the buffer id that would also break the attempts to deal with the issue consistently. Cheers, Franco From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 21:48:43 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 497664D1 for ; Tue, 11 Nov 2014 21:48:43 +0000 (UTC) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CDF70186 for ; Tue, 11 Nov 2014 21:48:42 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id n3so3002687wiv.8 for ; Tue, 11 Nov 2014 13:48:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=XmLdJi1XDoMk4FTcdNgqrofKNZ0EyzY+RzBx3ltkt5g=; b=kScz5idI3B1VfM+uTTxNXy9oN8n3jxyOTOV6TA1mJyqTRlGkyPWZiofr9FsJ9aTy9u mwQJIZIV+chuUUBeDZ02vyCBGTmvGqREvwJfnwWs8BcETQugoc5ASSmPhsVOgXNBlD21 9+rctAJqoR5zj3nGRQgE2BHZaDOQ+OXwoMVccWf/FZdI7ACYtdAJ1aEsNqqwx50GHiFc JRMEUY1cb/0F5BUiRf3k/rqBmQ2rxQlVp4RbbjtFA5kmq/xy7Prp31VHBehBy/Hmo/fx 7+HHW1Id/6aL7ovGyyyZg+VuLciQTXc4Pq9lcxQEIh4QTW0IqSGKy5+/i/mSUAkhtac+ kjQw== MIME-Version: 1.0 X-Received: by 10.180.73.212 with SMTP id n20mr1032898wiv.59.1415742521376; Tue, 11 Nov 2014 13:48:41 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Tue, 11 Nov 2014 13:48:40 -0800 (PST) In-Reply-To: References: <560E07EA-2506-487E-88DD-E2B9F7ED9792@lastsummer.de> Date: Tue, 11 Nov 2014 13:48:40 -0800 X-Google-Sender-Auth: kKSvXU3aqn5fRCPNxkP2ecN_jmQ Message-ID: Subject: Re: netmap: extension to store user data per packet/slot? From: Adrian Chadd To: Franco Fichtner Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current , Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 21:48:43 -0000 On 11 November 2014 13:41, Franco Fichtner wrote: > Hi Adrian, > > On 11 Nov 2014, at 22:22, Adrian Chadd wrote: > >> ... I'm confused. Do you have the slot id already, right? Why not >> allocate an array of userdata pointers somewhere else and just use the >> netmap slot id as an indirection into that? > > The slot id is per ring and there are a lot of them. In case of > zero-copy the slot changes at least 1. Consider two processes > for the load balancing case. Process 1 attaches to the devices > and Process 2 only has a a pipe pair for receiving and sending > packets back to Process 1 after processing, because only that > process has access to the real devices: > > em0, em1, etc. <--RX/TX--> Process 1 <--pipe pair--> Process 2 > (Hardware) (Balancer) (Worker) > > There is no way to trace packet origin back to em0 or em1 after > pushing the packets through the pipe pair unless either the > pipes are unique for each device or there is another means to > keep its state. > > Should, however, the buffer id be unique that would make it > easy to do what you suggest, but I don't know the netmap(4) > internals by heart. > > It seems a wee unnatural to rebuild tracing of packets in > userland when netmap(4) has all the infrastructure needed to > deal with this effectively, but I'm not opposed to doing that > to avoid API/ABI changes. Speaking of those, should volatile > internals change regarding the buffer id that would also break > the attempts to deal with the issue consistently. Ah, I see. You're missing some unique identifier for each netmap buffer. I thought there was one already. Silly me. Luigi? -adrian From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 22:01:28 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 90C93D22; Tue, 11 Nov 2014 22:01:28 +0000 (UTC) Received: from host64.kissl.de (host64.kissl.de [213.239.241.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.shmhost.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C192387; Tue, 11 Nov 2014 22:01:28 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by host64.kissl.de (Postfix) with ESMTP id 7C31FB00B09; Tue, 11 Nov 2014 23:01:26 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at host64.kissl.de Received: from host64.kissl.de ([127.0.0.1]) by localhost (host64.kissl.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PK-bzg4HoLF; Tue, 11 Nov 2014 23:01:26 +0100 (CET) Received: from [192.168.0.11] (unknown [95.91.254.245]) (Authenticated sender: web104p1) by host64.kissl.de (Postfix) with ESMTPSA id 2BC4FB00B07; Tue, 11 Nov 2014 23:01:26 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: netmap: extension to store user data per packet/slot? From: Franco Fichtner In-Reply-To: Date: Tue, 11 Nov 2014 23:01:24 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <560E07EA-2506-487E-88DD-E2B9F7ED9792@lastsummer.de> To: Adrian Chadd X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current , Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 22:01:28 -0000 On 11 Nov 2014, at 22:48, Adrian Chadd wrote: > Ah, I see. You're missing some unique identifier for each netmap > buffer. I thought there was one already. Silly me. Exactly, and, no, thank you for making clear what is needed. :) A little more on this: I think struct netmap_slot is convenient due to the fact that in zero-copy one wouldn't want to mess with the actual buffer for speed and userland code already touches slot internals for each ring transition so there is no performance degradation. The key benefit is that if userland can use this storage freely netmap(4) doesn't get in the way of building complex setups that require decoupled logic and each ring "hop" may alter the state as required. Cheers, Franco From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 22:39:57 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54502EB5; Tue, 11 Nov 2014 22:39:57 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 41E60947; Tue, 11 Nov 2014 22:39:57 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 12A0FD4B; Tue, 11 Nov 2014 22:39:56 +0000 (UTC) Date: Tue, 11 Nov 2014 22:39:54 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, glebius@FreeBSD.org, dim@FreeBSD.org, jhb@FreeBSD.org, jkim@FreeBSD.org, dteske@FreeBSD.org Message-ID: <1417818673.41.1415745596562.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #1820 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 22:39:57 -0000 See Changes: [glebius] Remove SF_KQUEUE code. This code was developed at Netflix, but w= as not ever used. It didn't go into stable/10, neither was documented. It might be useful, but we collectively decided to remove it, rather leave it abandoned and unmaintained. It is removed in one single commit, so restoring it should be easy, if anyone wants to reopen this idea. Sponsored by:=09Netflix [jhb] Add device ID for the T502-BT (dual-port 1G) adapter. Reviewed by:=09np MFC after:=091 week [dteske] Fix whitespace. Thanks to:=09nwhitehorn [jhb] Move NFS and TFTP filesystems before the synthetic filesystems (bzip, gzip, and split). "Real" filesystems should always be listed first so that the "bare" filename is tried before alternate filenames. For PXE booting in particular this can remove a lot of spurious pathname lookups. While here, move splitfs to the bottom after the bzip and gzip filesystems as it is the least often used. Tested by:=09Prokash Sinha MFC after:=091 week [jkim] Use the correct device. Note this commit complements r274386. PR:=09=09194884 [dteske] Default `bsdconfig timezone' and `tzsetup' to `-s' in a VM. Recommended by:=09cperciva Reviewed by:=09cperciva Relnotes:=09tzsetup and bsdconfig now assume that the "hardware" clock insi= de a VM is set to UTC [dim] Change kbdb's kthr::cpu field into an int, to avoid gcc warnings abou= t comparing it with NOCPU, which became -1 recently. While here, avoid using it for address calculations if it is negative. Reviewed by:=09jhb, adrian MFC after:=091 week ------------------------------------------ [...truncated 278416 lines...] ctfconvert -L VERSION -g mv.o --- ioctl.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- hptproc.o --- ctfconvert -L VERSION -g hptproc.o --- hv_net_vsc.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- ioctl.o --- ctfconvert -L VERSION -g ioctl.o --- gui_lib.o --- ctfconvert -L VERSION -g gui_lib.o --- hv_netvsc_drv_freebsd.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- hv_rndis_filter.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- hv_net_vsc.o --- ctfconvert -L VERSION -g hv_net_vsc.o --- hv_storvsc_drv_freebsd.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- hv_rndis_filter.o --- ctfconvert -L VERSION -g hv_rndis_filter.o --- hv_kvp.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- hv_netvsc_drv_freebsd.o --- ctfconvert -L VERSION -g hv_netvsc_drv_freebsd.o --- hv_util.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = ctfconvert -L VERSION -g hv_util.o --- hv_channel.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- hv_storvsc_drv_freebsd.o --- ctfconvert -L VERSION -g hv_storvsc_drv_freebsd.o --- hv_channel_mgmt.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- pmap.o --- ctfconvert -L VERSION -g pmap.o --- hv_kvp.o --- ctfconvert -L VERSION -g hv_kvp.o --- hv_connection.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- hv_hv.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- hv_channel_mgmt.o --- ctfconvert -L VERSION -g hv_channel_mgmt.o --- hv_ring_buffer.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- hv_channel.o --- ctfconvert -L VERSION -g hv_channel.o --- hv_vmbus_drv_freebsd.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- hv_connection.o --- ctfconvert -L VERSION -g hv_connection.o --- uart_cpu_x86.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- hv_hv.o --- ctfconvert -L VERSION -g hv_hv.o --- isci_controller.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- hv_ring_buffer.o --- ctfconvert -L VERSION -g hv_ring_buffer.o --- isci_domain.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- hv_vmbus_drv_freebsd.o --- ctfconvert -L VERSION -g hv_vmbus_drv_freebsd.o --- isci_io_request.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- uart_cpu_x86.o --- ctfconvert -L VERSION -g uart_cpu_x86.o --- isci_logger.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- isci_domain.o --- ctfconvert -L VERSION -g isci_domain.o --- isci_oem_parameters.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- isci_logger.o --- ctfconvert -L VERSION -g isci_logger.o --- isci_remote_device.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- isci_controller.o --- ctfconvert -L VERSION -g isci_controller.o --- isci_sysctl.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- isci_io_request.o --- ctfconvert -L VERSION -g isci_io_request.o --- isci_task_request.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- isci_oem_parameters.o --- ctfconvert -L VERSION -g isci_oem_parameters.o --- isci_timer.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- isci_remote_device.o --- ctfconvert -L VERSION -g isci_remote_device.o --- if_vtnet.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- isci_task_request.o --- ctfconvert -L VERSION -g isci_task_request.o --- virtio_blk.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- isci_sysctl.o --- ctfconvert -L VERSION -g isci_sysctl.o --- virtio_balloon.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- isci_timer.o --- ctfconvert -L VERSION -g isci_timer.o --- virtio_scsi.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- virtio_balloon.o --- ctfconvert -L VERSION -g virtio_balloon.o --- kern_clocksource.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- virtio_blk.o --- ctfconvert -L VERSION -g virtio_blk.o --- ia32_syscall.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- kern_clocksource.o --- ctfconvert -L VERSION -g kern_clocksource.o --- ia32_syscall.o --- ctfconvert -L VERSION -g ia32_syscall.o --- OsdEnvironment.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- intel_idpgtbl.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- virtio_scsi.o --- ctfconvert -L VERSION -g virtio_scsi.o --- busdma_bounce.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- OsdEnvironment.o --- ctfconvert -L VERSION -g OsdEnvironment.o --- busdma_machdep.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = ctfconvert -L VERSION -g busdma_machdep.o --- identcpu.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- busdma_bounce.o --- ctfconvert -L VERSION -g busdma_bounce.o --- intel_idpgtbl.o --- ctfconvert -L VERSION -g intel_idpgtbl.o --- intr_machdep.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- legacy.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- if_vtnet.o --- ctfconvert -L VERSION -g if_vtnet.o --- local_apic.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- legacy.o --- ctfconvert -L VERSION -g legacy.o --- mca.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- intr_machdep.o --- ctfconvert -L VERSION -g intr_machdep.o --- xen_apic.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- identcpu.o --- ctfconvert -L VERSION -g identcpu.o --- xenpv.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = ctfconvert -L VERSION -g xenpv.o --- ata_if.o --- awk -f -c ; cc -c -O2 -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 -Wno= -error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-e= quality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION= _HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-fram= e-pointer -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -= fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -= mno-aes -mno-avx -Werror ata_if.c --- xen_apic.o --- ctfconvert -L VERSION -g xen_apic.o --- eisa_if.o --- awk -f -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc9= 9 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissin= g-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sig= n -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -W= no-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses= -equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTI= ON_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-fr= ame-pointer -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float = -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2= -mno-aes -mno-avx -Werror eisa_if.c --- mca.o --- ctfconvert -L VERSION -g mca.o --- bus_if.o --- awk -f -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g = -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-pro= totypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ff= ormat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-er= ror-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equa= lity -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HE= ADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-p= ointer -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno= -asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno= -aes -mno-avx -Werror bus_if.c --- ata_if.o --- ctfconvert -L VERSION -g ata_if.o --- device_if.o --- awk -f -c ; cc -c -O2 -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 -Wno= -error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-e= quality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION= _HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-fram= e-pointer -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -= fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -= mno-aes -mno-avx -Werror device_if.c --- eisa_if.o --- ctfconvert -L VERSION -g eisa_if.o --- acpi_wmi_if.o --- awk -f -c ; cc -c -O2 -pipe -fno-strict-aliasin= g -std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototyp= es -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno= -pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-sho= w-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error= -parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE= _KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-= omit-leaf-frame-pointer -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -= msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protect= or -gdwarf-2 -mno-aes -mno-avx -Werror acpi_wmi_if.c --- local_apic.o --- ctfconvert -L VERSION -g local_apic.o --- virtio_if.o --- awk -f -c ; cc -c -O2 -pipe -fno-strict-aliasing -std= =3Dc99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wm= issing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointe= r-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-optio= n -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parent= heses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL= _OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-le= af-frame-pointer -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-f= loat -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdw= arf-2 -mno-aes -mno-avx -Werror virtio_if.c --- bus_if.o --- ctfconvert -L VERSION -g bus_if.o --- device_if.o --- ctfconvert -L VERSION -g device_if.o --- freebsd32_misc.o --- --- md.o --- --- freebsd32_misc.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- md.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- virtio_if.o --- ctfconvert -L VERSION -g virtio_if.o --- usb_dev.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- acpi_wmi_if.o --- ctfconvert -L VERSION -g acpi_wmi_if.o --- evtchn_dev.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = ctfconvert -L VERSION -g evtchn_dev.o --- dead_vnops.o --- --- freebsd32_misc.o --- :1611:23: error: use of undeclared identifier 'rights' cap_rights_init(&rights, CAP_PREAD), &fp)) !=3D 0) ^ :315:40: note: expanded from macro 'cap_rights_init' __cap_rights_init(CAP_RIGHTS_VERSION, __VA_ARGS__, 0ULL) ^ :1614:22: error: use of undeclared identifier 'fp' error =3D fo_sendfile(fp, uap->s, hdr_uio, trl_uio, offset, ^ :1616:8: error: use of undeclared identifier 'fp' fdrop(fp, td); ^ :27= 5:22: note: expanded from macro 'fdrop' (refcount_release(&(fp)->f_count) ? _fdrop((fp), (td)) : _fnoop()) ^ --- dead_vnops.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- freebsd32_misc.o --- :1616:8: error: use of undeclared identifier 'fp' :27= 5:46: note: expanded from macro 'fdrop' (refcount_release(&(fp)->f_count) ? _fdrop((fp), (td)) : _fnoop()) ^ 4 errors generated. *** [freebsd32_misc.o] Error code 1 make[2]: stopped in /usr/obj --- dead_vnops.o --- ctfconvert -L VERSION -g dead_vnops.o --- md.o --- ctfconvert -L VERSION -g md.o --- usb_dev.o --- ctfconvert -L VERSION -g usb_dev.o 1 error make[2]: stopped in /usr/obj *** [buildkernel] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildkernel] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 23:00:39 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 77E415D7; Tue, 11 Nov 2014 23:00:39 +0000 (UTC) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F1A3BBCE; Tue, 11 Nov 2014 23:00:38 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id n3so3134676wiv.14 for ; Tue, 11 Nov 2014 15:00:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=91oRtIlJhmzF5WOsf8FHKvOBi9tX+XnGBClzOGBCftw=; b=y3Dc+jT4z5Hj4H5/bQ3Xnt18XINgXdfpmCuWjMIHKtLkLlZ3zq792niyD9eza+ndIm 3yphj3151vFSk7prGA+VueTJ+2smOxveON5CGjp2w9Cd4++DdX2fy4tsyCtXs4ly84qr uQsWKiuyoBig2iGwoTrvh6Jpu7esFQh8i6iAYiXPfSP6/fuuFqkPhHGOb2Ts9n6HxV2p U4iAe8N8Z7j4L1mzhM0uJPiSGdZ1soAw9+NjCGFGUFKfcVECdgG717XxEkxq78wAJwks fVGrtKwiwv6dDFZ5eNl2BJBCtHGlKfOG/eI8t/znzLvgOcL6xPKEMu4ZZ3Zn0cTUjAf7 a1Kg== MIME-Version: 1.0 X-Received: by 10.194.110.161 with SMTP id ib1mr60503125wjb.78.1415746837442; Tue, 11 Nov 2014 15:00:37 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.194.19.9 with HTTP; Tue, 11 Nov 2014 15:00:37 -0800 (PST) In-Reply-To: References: <560E07EA-2506-487E-88DD-E2B9F7ED9792@lastsummer.de> Date: Tue, 11 Nov 2014 15:00:37 -0800 X-Google-Sender-Auth: hyD23Y4KVrfC0TZiBl9ew2JimFE Message-ID: Subject: Re: netmap: extension to store user data per packet/slot? From: Luigi Rizzo To: Franco Fichtner Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Adrian Chadd , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 11 Nov 2014 23:00:39 -0000 Franco, apparently you want some user-defined metadata to move along with the packet, but i do not think it is reasonable to put it in the slots. If we do that, what about timestamps, flow IDs, interface and queue index and all the rest of the things that we normally find in an mbuf/skbuf ? This is not going to scale. Also consider that at some point you may use a different arrangement (with packets passed along VALE switches or physical interfaces etc.) i believe the most reasonable place to put the extra info is at the end of the packet and possibly bump the length in the slot so you are safe in case the packet is copied. There is no timestamp appended to the packet at the moment, it was a feature i thought somebody may want to have, but between the relative scarcity of hardware that provides per-packet timestamps, and the questionable usefulness of the same, i doubt it will be available. cheers luigi On Tue, Nov 11, 2014 at 2:01 PM, Franco Fichtner wrote: > > On 11 Nov 2014, at 22:48, Adrian Chadd wrote: > > > Ah, I see. You're missing some unique identifier for each netmap > > buffer. I thought there was one already. Silly me. > > Exactly, and, no, thank you for making clear what is needed. :) > > A little more on this: I think struct netmap_slot is convenient > due to the fact that in zero-copy one wouldn't want to mess with > the actual buffer for speed and userland code already touches slot > internals for each ring transition so there is no performance > degradation. > > The key benefit is that if userland can use this storage freely > netmap(4) doesn't get in the way of building complex setups that > require decoupled logic and each ring "hop" may alter the state > as required. > > > Cheers, > Franco > -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 01:40:31 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EC570EF; Wed, 12 Nov 2014 01:40:30 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id DA6BBD33; Wed, 12 Nov 2014 01:40:30 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 48534D8B; Wed, 12 Nov 2014 01:40:31 +0000 (UTC) Date: Wed, 12 Nov 2014 01:40:28 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, glebius@FreeBSD.org, dim@FreeBSD.org, jhb@FreeBSD.org, loos@FreeBSD.org, grehan@FreeBSD.org, jkim@FreeBSD.org, dteske@FreeBSD.org, marcel@FreeBSD.org Message-ID: <396918881.42.1415756431248.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1417818673.41.1415745596562.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1417818673.41.1415745596562.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD #1821 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: SUCCESS X-Mailman-Approved-At: Wed, 12 Nov 2014 01:50:15 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 12 Nov 2014 01:40:31 -0000 See From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 02:28:12 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7FAA86A for ; Wed, 12 Nov 2014 02:28:12 +0000 (UTC) Received: from acipenser.esturion.net (acipenser.esturion.net [65.101.5.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B169E2BD for ; Wed, 12 Nov 2014 02:28:12 +0000 (UTC) Received: by acipenser.esturion.net (Postfix, from userid 112) id 2381626040A; Tue, 11 Nov 2014 19:28:11 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on acipenser.esturion.net X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Received: from feyerabend.n1.pinyon.org (quine.pinyon.org [65.101.5.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by acipenser.esturion.net (Postfix) with ESMTPSA id 7C27026018A for ; Tue, 11 Nov 2014 19:28:08 -0700 (MST) Message-ID: <5462C5B8.3070800@pinyon.org> Date: Tue, 11 Nov 2014 19:28:08 -0700 From: "Russell L. Carter" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: buildworld fails: spa_maxblocksize Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 12 Nov 2014 02:28:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So the ztest link fails looking for spa_maxblocksize, which is defined in sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c I don't see which lib it is included in. One of zpool, zfs, or zfs_core, apparently. As my build system is root on zfs, I am a bit nervous about just installing those (shouldn't buildworld take care of this?) It looks to me that my buildworld environment is reaching out to the exterior system, is that right? I have set export MAKEOBJDIRPREFIX=/usr/obj before invoking buildworld, but it doesn't help. Ideas? Thanks, Russell -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUYsW4AAoJEFnLrGVSDFaE6RwP/RL43zI7dIp3Xl3WSEVpCjLH uz7PLKjcHpJoLP8MU4cA6QYB+w2aIT6L5xEwdWDvFJXj1TIV0cgyd9Pn/nSmxKnD 2grZxcHmdKV9Lkmvegb6BaGs0ysSHbaVr95XIpRNCBXM9gE+8HIqLgFhkDPQCaRU OjbOOjLpdfdW5qWlQasMBVwsnLJHpd0TJKwV43NQYMkmohLsQWbPvEA72N5X1131 UzJZGP2SMivNwlyW++V0ZbNflsaR40IsZk+1BJaHS5ywnFVgXqj1uFnv5l0TfzUE nUsIcrQ00/ETpcypCnsHuJyUOKey/OzVyLLlzmSSpxUtDBU/2QKNxeVtkroLvJIf w6IBR9H6mWIzebNKodxnP7jkE59yMpgEzvFzNHwuc3EVhYRLK4eD7TN524DV3/KK 81b2rdpaPXHh+PqFJQ82XHlpV1pCn0JxQNUjVOzuiXchg7HQAJdBrJhTGsb/g0Z/ KxEuk7t+WchcIakemFQNPmvyg3r2UfzMTyrNN2nxyCRSXk94Xgw8GyWl9f+5DmtR m5gIdEVNpIijwBeYZ+ctDjzRrRJ+cwnVq/35Doiot+lvefDo3Ky00+5w8iHwPAmT rJ1X/lX00CmBcaU/bginYBJCSckvBOuoU6pW6W8F3wvsVKCOmBnLTz5e64P/i62R hLnD6BcqlmCORw6FqMaO =totl -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 06:52:46 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 764967ED; Wed, 12 Nov 2014 06:52:46 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 52748224; Wed, 12 Nov 2014 06:52:45 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id sAC6qV5I060273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 11 Nov 2014 22:52:35 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <546303A2.2070401@freebsd.org> Date: Wed, 12 Nov 2014 14:52:18 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Timur I. Bakeyev" Subject: Re: samba/NSSWITCH interaction in fbsd 10 vs fbsd 8 References: <5460AC13.5060001@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: hackers@freebsd.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 12 Nov 2014 06:52:46 -0000 On 11/11/14, 4:28 PM, Timur I. Bakeyev wrote: > Do you use net/samba36 port? Looks like you don't... It occurred to me after posting to check the port and I found this.. The company decided to go the independent route before I joined so they don't use the port. They have a huge set of diffs to samba so it kind of makes sense. > > @@ -6336,12 +6373,13 @@ > NSSSONAMEVERSIONSUFFIX=".2" > WINBIND_NSS_EXTRA_OBJS="../nsswitch/winbind_nss_linux.o" > ;; > - *freebsd[[5-9]]*) > + *freebsd*) > # FreeBSD winbind client is implemented as a wrapper > around > # the Linux version. > NSSSONAMEVERSIONSUFFIX=".1" > WINBIND_NSS_EXTRA_OBJS="../nsswitch/winbind_nss_freebsd.o \ > ../nsswitch/winbind_nss_linux.o" > + WINBIND_WINS_NSS_EXTRA_OBJS="../nsswitch/wins_freebsd.o" > WINBIND_NSS="../nsswitch/nss_winbind.$SHLIBEXT" > WINBIND_WINS_NSS="../nsswitch/nss_wins.$SHLIBEXT" > ;; > > > On Mon, Nov 10, 2014 at 1:14 PM, Julian Elischer > wrote: > > When I try use the libnss_winbind.so that is generated by samba > 3.6 I get the following message: > > NSSWITCH(nss_load_module): winbind, Undefined symbol > "nss_module_register". > > First I have to change its' name to nss_winbins.so.1 however > because that is what nsswitch is looking for.... > (BTW where is that documented??) > > then it finds it but fails as mentioned above. > > This same samba source generates good nss files in 8.0 but under > 10 it fails.. Literally it's the same sources just checked out > into a different build system. (10 vs 8). > > Has there been a change in the API for the nss modules? where it > he API for nsswitch files documented? > > Julian > _______________________________________________ > freebsd-current@freebsd.org > mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org > " > > From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 09:50:26 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8BD52910; Wed, 12 Nov 2014 09:50:26 +0000 (UTC) Received: from host64.kissl.de (host64.kissl.de [213.239.241.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.shmhost.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 452C17DC; Wed, 12 Nov 2014 09:50:26 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by host64.kissl.de (Postfix) with ESMTP id 85C2BB02DCA; Wed, 12 Nov 2014 10:50:23 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at host64.kissl.de Received: from host64.kissl.de ([127.0.0.1]) by localhost (host64.kissl.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntT3B2uGblyQ; Wed, 12 Nov 2014 10:50:23 +0100 (CET) Received: from francos-mbp.hq.packetwerk.com (p50993595.dip0.t-ipconnect.de [80.153.53.149]) (Authenticated sender: web104p1) by host64.kissl.de (Postfix) with ESMTPSA id 26E4BB02DC9; Wed, 12 Nov 2014 10:50:23 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: netmap: extension to store user data per packet/slot? From: Franco Fichtner In-Reply-To: Date: Wed, 12 Nov 2014 10:50:21 +0100 Content-Transfer-Encoding: 7bit Message-Id: <649AF052-F51A-48A7-BAA9-F85B36DD0C12@lastsummer.de> References: <560E07EA-2506-487E-88DD-E2B9F7ED9792@lastsummer.de> To: Luigi Rizzo X-Mailer: Apple Mail (2.1878.6) Cc: Adrian Chadd , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 12 Nov 2014 09:50:26 -0000 Hi Luigi, On 12 Nov 2014, at 00:00, Luigi Rizzo wrote: > apparently you want some user-defined metadata to move > along with the packet, but i do not think it is > reasonable to put it in the slots. > If we do that, what about timestamps, flow IDs, > interface and queue index and all the rest of the things that > we normally find in an mbuf/skbuf ? This is not > going to scale. that's true. I'm only suggesting a small extension to be used freely, but would never consider increasing the slot size beyond 32 bytes in any case. Keeping it sleek is obviously important. > Also consider that at some point you may use a different > arrangement (with packets passed along VALE switches > or physical interfaces etc.) i believe the most > reasonable place to put the extra info is at the end > of the packet and possibly bump the length in the slot > so you are safe in case the packet is copied. I dont believe dirtying the cache lines in the actual packet buffer is a wise choice, but it certainly works. > There is no timestamp appended to the packet at the moment, > it was a feature i thought somebody may want to have, > but between the relative scarcity of hardware that provides > per-packet timestamps, and the questionable usefulness > of the same, i doubt it will be available. It is a useful feature to have receive timestamps per packet for better accounting, but I can see it being too mystical in its current form inside the packet buffer. It's still in my TODO list to investigate the impact, but a system certainly works without that extra bit of resolution. For now, I'll go with Adrians suggestion and keep track of the buffer index inside the first process away from netmap(4) itself. This setup breaks for non-circular pipe arrangements, but the load-balancing use case at hand is alright. Cheers, Franco From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 13:36:41 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 466FA694 for ; Wed, 12 Nov 2014 13:36:41 +0000 (UTC) Received: from nf.net.npkgoi.ru (nf.net.npkgoi.ru [82.179.67.95]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D706FB8 for ; Wed, 12 Nov 2014 13:36:40 +0000 (UTC) Received: from nf.net.npkgoi.ru (localhost [127.0.0.1]) by nf.net.npkgoi.ru (8.14.1/8.14.1) with ESMTP id sACDUmWs044749 for ; Wed, 12 Nov 2014 16:30:48 +0300 (MSK) (envelope-from val@ns1.npkgoi.ru) Received: (from uucp@localhost) by nf.net.npkgoi.ru (8.14.1/8.14.1/Submit) with UUCP id sACDUm8V044748 for freebsd-current@freebsd.org; Wed, 12 Nov 2014 16:30:48 +0300 (MSK) (envelope-from val@ns1.npkgoi.ru) Received: from server.soi.spb.ru (localhost [127.0.0.1]) by server.soi.spb.ru (8.14.2/8.14.2) with ESMTP id sACDUihC094531; Wed, 12 Nov 2014 16:30:44 +0300 (MSK) (envelope-from val@ns1.npkgoi.ru) Received: (from val@localhost) by server.soi.spb.ru (8.14.2/8.14.2/Submit) id sACDUhlD094530; Wed, 12 Nov 2014 16:30:43 +0300 (MSK) (envelope-from val) Date: Wed, 12 Nov 2014 16:30:43 +0300 From: Valentin Davydov To: freebsd-current@freebsd.org Subject: New LOR's concerning zfs. Message-ID: <20141112133043.GA93891@soi.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Wed, 12 Nov 2014 14:12:29 +0000 Cc: cs@soi.spb.ru X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 12 Nov 2014 13:36:41 -0000 Recently I've installed current in an unusual configuration: root ZFS pool on an USB stick, without any partitioning. It works good, but quite often throws three different LORs, all related to ZFS subsystem. I suspect this is due to the irregular timing pattern of the USB access, and I couldn't find them in the list of known LORs. Hope this would help further integration of ZFS in kernel. Details please see below. Valentin Davydov. uname -a FreeBSD white.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r274379: Tue Nov 11 14:35:45 UTC 2014 root@white.local:/usr/obj/usr/src/sys/GENERIC amd64 LORs themselves: lock order reversal: 1st 0xfffff80009382d50 syncer (syncer) @ /White/usr/src/sys/kern/vfs_subr.c:1756 2nd 0xfffff8002d9dfb78 zfs (zfs) @ /White/usr/src/sys/kern/vfs_subr.c:2144 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00857186d0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0085718780 witness_checkorder() at witness_checkorder+0xdad/frame 0xfffffe0085718810 __lockmgr_args() at __lockmgr_args+0x9a4/frame 0xfffffe0085718940 vop_stdlock() at vop_stdlock+0x3c/frame 0xfffffe0085718960 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfffffe0085718990 _vn_lock() at _vn_lock+0xaa/frame 0xfffffe0085718a00 vget() at vget+0x67/frame 0xfffffe0085718a40 vfs_msync() at vfs_msync+0xa7/frame 0xfffffe0085718aa0 sync_fsync() at sync_fsync+0xcc/frame 0xfffffe0085718ae0 VOP_FSYNC_APV() at VOP_FSYNC_APV+0xf7/frame 0xfffffe0085718b10 sched_sync() at sched_sync+0x34b/frame 0xfffffe0085718bb0 fork_exit() at fork_exit+0x84/frame 0xfffffe0085718bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0085718bf0 --- trap 0, rip = 0, rsp = 0xfffffe0085718cb0, rbp = 0 --- lock order reversal: 1st 0xfffff80007c9cd50 zfs (zfs) @ /White/usr/src/sys/kern/vfs_mount.c:1223 2nd 0xfffff80007c9d5f0 devfs (devfs) @ /White/usr/src/sys/kern/vfs_subr.c:2144 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00859b63c0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe00859b6470 witness_checkorder() at witness_checkorder+0xdad/frame 0xfffffe00859b6500 __lockmgr_args() at __lockmgr_args+0x9a4/frame 0xfffffe00859b6630 vop_stdlock() at vop_stdlock+0x3c/frame 0xfffffe00859b6650 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfffffe00859b6680 _vn_lock() at _vn_lock+0xaa/frame 0xfffffe00859b66f0 vget() at vget+0x67/frame 0xfffffe00859b6730 devfs_allocv() at devfs_allocv+0xfd/frame 0xfffffe00859b6780 devfs_root() at devfs_root+0x43/frame 0xfffffe00859b67b0 vflush() at vflush+0x73/frame 0xfffffe00859b6900 devfs_unmount() at devfs_unmount+0x38/frame 0xfffffe00859b6930 dounmount() at dounmount+0x424/frame 0xfffffe00859b69b0 sys_unmount() at sys_unmount+0x2ec/frame 0xfffffe00859b6ae0 amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe00859b6bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe00859b6bf0 --- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x80089213a, rsp = 0x7fffffffe468, rbp = 0x7fffffffe580 --- lock order reversal: 1st 0xfffff800102ad038 filedesc structure (filedesc structure) @ /White/usr/src/sys/kern/kern_descrip.c:1218 2nd 0xfffff8007abb35f0 zfs (zfs) @ /White/usr/src/sys/kern/vfs_subr.c:4411 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe022d790590 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe022d790640 witness_checkorder() at witness_checkorder+0xdad/frame 0xfffffe022d7906d0 __lockmgr_args() at __lockmgr_args+0x9a4/frame 0xfffffe022d790800 vop_stdlock() at vop_stdlock+0x3c/frame 0xfffffe022d790820 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfffffe022d790850 _vn_lock() at _vn_lock+0xaa/frame 0xfffffe022d7908c0 knlist_remove_kq() at knlist_remove_kq+0x82/frame 0xfffffe022d7908f0 filt_vfsdetach() at filt_vfsdetach+0x28/frame 0xfffffe022d790910 knote_fdclose() at knote_fdclose+0xc7/frame 0xfffffe022d790960 closefp() at closefp+0x65/frame 0xfffffe022d7909a0 amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe022d790ab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe022d790ab0 --- syscall (6, FreeBSD ELF64, sys_close), rip = 0x80165c2ca, rsp = 0x7fffdfbfbef8, rbp = 0x7fffdfbfbf10 --- From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 16:52:42 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1CBB0C0 for ; Wed, 12 Nov 2014 16:52:42 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EA1D0A7E for ; Wed, 12 Nov 2014 16:52:41 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0CCFCB945; Wed, 12 Nov 2014 11:52:41 -0500 (EST) From: John Baldwin To: Henry Hu Subject: Re: r273918 buildworld broke at semaphore Date: Wed, 12 Nov 2014 11:51:05 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <1414786086662-5961241.post@n5.nabble.com> <201411111333.05910.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201411121151.05374.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 12 Nov 2014 11:52:41 -0500 (EST) Cc: FreeBSD CURRENT , Beeblebrox X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 12 Nov 2014 16:52:42 -0000 On Tuesday, November 11, 2014 4:22:05 pm Henry Hu wrote: > On Tue, Nov 11, 2014 at 1:33 PM, John Baldwin wrote: > > > On Friday, October 31, 2014 4:08:06 pm Beeblebrox wrote: > > > First breakage in a long time. Error is: > > > > > > In file included from cancelpoints_sem_new.c:47: > > > /usr/src/lib/libc/../../include/semaphore.h:41:16: error: field has > > > incomplete type 'struct _usem2' > > > struct _usem2 _kern; > > > ^ > > > /usr/src/lib/libc/../../include/semaphore.h:41:9: note: forward > > declaration > > > of 'struct _usem2' > > > struct _usem2 _kern; > > > ^ > > > cancelpoints_sem_new.c:66:33: error: use of undeclared identifier > > > 'USEM_MAX_COUNT' > > > _Static_assert(SEM_VALUE_MAX <= USEM_MAX_COUNT, "SEM_VALUE_MAX too > > large"); > > > ^ > > > cancelpoints_sem_new.c:335:15: warning: implicit declaration of function > > > 'USEM_COUNT' is invalid in C99 [-Wimplicit-function-declaration] > > > *sval = (int)USEM_COUNT(sem->_kern._count); > > > ^ > > > cancelpoints_sem_new.c:342:23: error: use of undeclared identifier > > > 'UMTX_OP_SEM2_WAKE' > > > return _umtx_op(sem, UMTX_OP_SEM2_WAKE, 0, NULL, NULL); > > > ^ > > > cancelpoints_sem_new.c:361:23: error: use of undeclared identifier > > > 'UMTX_OP_SEM2_WAIT' > > > return _umtx_op(sem, UMTX_OP_SEM2_WAIT, 0, > > > ^ > > > cancelpoints_sem_new.c:445:14: error: use of undeclared identifier > > > 'USEM_HAS_WAITERS' > > > if (count & USEM_HAS_WAITERS) > > > ^ > > > 1 warning and 5 errors generated. > > > > Seems like your tree is not fully up to date? The changes to sem_new.c > > were > > committed in the same commit as the changes to sys/umtx.h. > > > Maybe it's another problem. buildworld may be picking up umtx.h from > /usr/include which is the old version. 'make buildworld' should always populate an include tree under /usr/obj that is used instead of /usr/include. If this wasn't correct, then every change to add new constants, etc. to any header installed to /usr/include would fail to build. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 16:57:57 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31151234 for ; Wed, 12 Nov 2014 16:57:57 +0000 (UTC) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E598CABE for ; Wed, 12 Nov 2014 16:57:56 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id wn1so9446315obc.4 for ; Wed, 12 Nov 2014 08:57:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb.com; s=google; h=message-id:date:from:user-agent:mime-version:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=UozR8BXOOJZBzrVBvjjfXv0SJykMjcaXtYOlxjdzuH4=; b=H7zkmFBjywz2xWJG8L2JyZY8eUvjI/18PhsvS04rns3UwAFv58qKz34iEeBg0KlmOu fs+3nO9t22xQOnaliya8v/pIAo3pPQXT1AvXGUNya4zXF6P0JwEi+jOvp1vg3rcdtXO5 U+4KRn/EeQ9GYyKgtaKD40bu7uj+ah/unz5nM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=UozR8BXOOJZBzrVBvjjfXv0SJykMjcaXtYOlxjdzuH4=; b=dZ36kikCUzKREhLHX+AklI6c61+wGc92EzUZwddwaM4Udvw2DQ1H7LYb8bSu7Gi44I rBYDCQl1nmLQDzIT5C9cCGrRMOhM+8olzvsM8zcNYvVHMUXXIs/YBrttQrQN1oOsw1Wp I+9FSLU8OtkDGNAAsZg7EvocSaUWERkNtI30iPhLU8AhhyfDMQY1pCH2n6WR8KdgLsms a7STudeXseTpOrk9VEzBVSIfC4/lOO7qYFx+tYtOEKnulelI2kADweWp2qGBXEMmCIKH ZvLt5C0F6fjWOq25Rzr0gCc0ReyOqfJfjz8e7P4j9o2QG+naIQWZeJWPwkq4DNR+5E6t KwTg== X-Gm-Message-State: ALoCoQlYNmnGfbKqc6FgmRovPLc3+HxH7AVQ5Y2bgsrTuP1q34OuVlkaQVqI1DpJ/QEQ17mzOgOp X-Received: by 10.202.104.85 with SMTP id d82mr37219202oic.4.1415811476021; Wed, 12 Nov 2014 08:57:56 -0800 (PST) Received: from rsbsd.rsb ([31.200.21.116]) by mx.google.com with ESMTPSA id x10sm6876261oie.29.2014.11.12.08.57.54 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Nov 2014 08:57:55 -0800 (PST) Message-ID: <546391A5.4010203@berentweb.com> Date: Wed, 12 Nov 2014 18:58:13 +0200 From: Beeblebrox User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 CC: FreeBSD CURRENT Subject: Re: r273918 buildworld broke at semaphore References: <1414786086662-5961241.post@n5.nabble.com> <201411111333.05910.jhb@freebsd.org> <201411121151.05374.jhb@freebsd.org> In-Reply-To: <201411121151.05374.jhb@freebsd.org> Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 12 Nov 2014 16:57:57 -0000 I solved this problem about 4 hours ago and posted through the Nabble interface. My email is not posting to the mail list, and stil shows as "not-accepted" - there's some sort of problem there... Regards. From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 19:16:41 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07056AE0 for ; Wed, 12 Nov 2014 19:16:41 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AB6BCB75 for ; Wed, 12 Nov 2014 19:16:40 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XodP9-000LEd-Ke; Wed, 12 Nov 2014 23:16:35 +0400 Date: Wed, 12 Nov 2014 23:16:35 +0400 From: Slawa Olhovchenkov To: Franco Fichtner Subject: Re: netmap: extension to store user data per packet/slot? Message-ID: <20141112191635.GA91736@zxy.spb.ru> References: <560E07EA-2506-487E-88DD-E2B9F7ED9792@lastsummer.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <560E07EA-2506-487E-88DD-E2B9F7ED9792@lastsummer.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-current@freebsd.org, Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 12 Nov 2014 19:16:41 -0000 On Tue, Nov 11, 2014 at 10:13:54PM +0100, Franco Fichtner wrote: > Hi Luigi, > hi all, > > so I was running into logistics issues with netmap(4) > with regard to zero-copy and redirection through pipes: > working on a load-balancing framework revealed that it > is very hard to track a packet's origins to later move > it onward to the respective outgoing interface, be it > another device or the host stack. > > Long story short: user data needs to be stored for the > packet buffer or slot. I think need configurable (by sysctl) space recerved before packet. This is may be used as user data. Or for insert VLAN/MPLS/QinQ/etc headers. More general: tilera have good api for this. > There are three ways that I can see so far: > > (1) Allocate a netmap pipe pair for each interface, > in case of transparent mode also a pipe for the > host stack each. That's a lot of pipes and > most likely insane, but it won't extend the ABI. > > (2) Store the additional data in the actual buffer. > That is sort of ok, but seems sluggish WRT cache > behaviour -- maybe the buffer won't be read but > it needs to be written. Sure, we can store it at > the end, but there already resides the packet > timestamp if enabled (if I recall correctly). > Wouldn't extend the ABI per se, but might collide > with the timestamping.... > > (3) Make room in struct netmap_slot itself like this: > > diff --git a/sys/net/netmap.h b/sys/net/netmap.h > index 15ebf73..d0a9c0e 100644 > --- a/sys/net/netmap.h > +++ b/sys/net/netmap.h > @@ -147,6 +147,7 @@ struct netmap_slot { > uint16_t len; /* length for this slot */ > uint16_t flags; /* buf changed, etc. */ > uint64_t ptr; /* pointer for indirect buffers */ > + uint64_t userdata; /* reserved storage for caller */ > }; > > It could also be broken down in two fields with uint32_t > each; not sure what would be more sensible. This of course > requires an API bump, although it should be backwards > compatible. > > Any feedback on this is highly appreciated. > > > Cheers, > Franco > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 19:41:13 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F5F8DE7; Wed, 12 Nov 2014 19:41:13 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DF1D7DD7; Wed, 12 Nov 2014 19:41:12 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sACJfBxU032149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Nov 2014 11:41:11 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sACJfA3w032148; Wed, 12 Nov 2014 11:41:10 -0800 (PST) (envelope-from jmg) Date: Wed, 12 Nov 2014 11:41:10 -0800 From: John-Mark Gurney To: Vsevolod Stakhov Subject: Re: CFR: AES-GCM and OpenCrypto work review Message-ID: <20141112194110.GX24601@funkthat.com> Mail-Followup-To: Vsevolod Stakhov , freebsd-security@freebsd.org, FreeBSD-Current References: <20141108042300.GA24601@funkthat.com> <545E6712.5060305@highsecure.ru> <20141108204538.GI24601@funkthat.com> <545E8904.6070109@highsecure.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <545E8904.6070109@highsecure.ru> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 12 Nov 2014 11:41:11 -0800 (PST) Cc: freebsd-security@freebsd.org, FreeBSD-Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 12 Nov 2014 19:41:13 -0000 Vsevolod Stakhov wrote this message on Sat, Nov 08, 2014 at 21:20 +0000: > On 08/11/14 20:45, John-Mark Gurney wrote: > >Vsevolod Stakhov wrote this message on Sat, Nov 08, 2014 at 18:55 +0000: > >>On 08/11/14 04:23, John-Mark Gurney wrote: > >>>Hello, > >>> > >>>Over the last few months, I've been working on a project to add support > >>>for AES-GCM and AES-CTR modes to our OpenCrypto framework. The work is > >>>sponsored by The FreeBSD Foundation and Netgate. > >>> > >>>I plan on committing these patches early next week. If you need more > >>>time for review, please email me privately and I will make delay. > >>> > >>>The code has already been reviewed by Watson Ladd (the software crypto > >>>implementations) and Trevor Perrin (the aesni module part) and I have > >>>integrated these changes into the patch. > >>> > >>>There are two patches, one is the changes for OpenCrypto and the test > >>>framework. The other is the data files used by the test framework. > >>>The data is from NIST's CAVP program, and is about 20MB worth of test > >>>vectors. (I just realized, should we look at compressing these on > >>>disk?) > >>> > >>>Main patch (192KB): > >>>https://www.funkthat.com/~jmg/patches/aes.ipsec.5.patch > >>> > >>>Data files (~20MB): > >>>https://www.funkthat.com/~jmg/patches/aes.ipsec.5.testing.patch > >>> > >>>A list of notable changes in the patch: > >>>- Replacing crypto(4) w/ NetBSD's version + updates > >>>- Lots of man page updates, including CIOCFINDDEV and crypto(7) which > >>> adds specifics about restrictions on the modes. > >>>- Allow sane useage of both _HARDWARE and _SOFTWARE flags. > >>>- Add a timing safe bcmp for MAC comparision. > >>>- Add a software implementation of GCM that uses a four bit lookup > >>> table with parallelization. This algorithm is possibly vulnerable to > >>> timing attacks, but best known mitigation methods are used. Using > >>> a timing safe version is many times slower. > >>>- Added a CRYPTDEB macro that defaults to off. > >>>- Bring in some of OpenBSD's improvements to the OpenCrypto framework. > >>>- If an mbuf passed to the aesni module is only one segment, don't do > >>> a copy. This needs to be improved to support segmented buffers. > >>>- Remove the CRYPTO_F_REL flag. It was meaningless. It was used but > >>> did not change any behavior. > >>>- Add function crypto_mbuftoiov to convert an mbuf to an iov. This > >>> also converts the software crypto to only use iov's even for a simple > >>> linear buffer, and so simplifies the processing. > >>>- Add a dtrace probe for errors from the ioctl. > >>>- Add the CIOCCRYPTAEAD ioctl that allows userland processing (testing) > >>> of AES-GCM and future AEAD modes. > >>> > >>>Future improvements: > >>>- Support IV's longer than 12 bytes for GCM. > >>>- Make AES-NI support segmented buffers (iov or mbuf) so multisegmented > >>> inputs don't have to be copied. > >> > >>I have the question regarding to the algorithm of GF field calculations > >>used in the proposed implementation: why not use the recent researches > >>in GCM calculations, e.g. described in [1], for further speed > >>optimizations? > >> > >>[1] - https://eprint.iacr.org/2013/157.pdf > > > >The paper you linked to does not describe a new way of calculating > >GHASH, but evalutation of a bug in their implementation using the > >PCLMULQDQ instruction... > > > >If you mean, why don't I use OpenSSL's code? The reason is that their > >code is a perl script that generates assmebly... We don't have > >perl in base.. and I didn't want more assembly in our tree (see below).. > > > >Instead, I decided to use code from Intel's whitepaper: > >Intel® Carry-Less Multiplication Instruction and its Usage for > >Computing the GCM Mode > > > >I didn't use their assembly version because I wanted to have > >maintainable code, and also the same code can be used on both i386 > >and amd64 arches.. This turns out to also be a good thing, as when > >I add segmented buffer support, it'll be much easier to add to the C > >version, and I only have to do the work once for two arches... > > > >Also, the software GF library that I wrote is using state of the art > >algorithms... An OpenBSD developer has tested my code and has seen > >a significant performance improvement over their old code, and are > >evaluating if they want to/can include it in their tree... > > > >Hope this answers your question. If not, please be more specific so > >I can answer it. > > I'm sorry, I thought that is the paper that is a transcript of the > following presentation: > > http://2013.diac.cr.yp.to/slides/gueron.pdf > > made by the same authors. The transcript is not available so far it seems. > > And regarding assembler/C maintainability I would argue that the current > intrinsics based implementation is more readable than the pure assembler > solution (and it is still machine dependent). Of course, I'm not the > expert in such optimizations, so that is just my own feeling. > > By the way, do you have some concrete numbers about the performance of > your aes-gcm? (I recently could do aes-128-gcm at about 32 gigabits/sec > that is not a limit of the modern hardware for sure). So, in bare metal userland testing, iirc, I was able to get around 1GByte/sec on a single core... That doesn't take into account kernel and framework overhead... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 19:48:49 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0646FF7 for ; Wed, 12 Nov 2014 19:48:49 +0000 (UTC) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 80FAEE69 for ; Wed, 12 Nov 2014 19:48:48 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id k14so15093240wgh.0 for ; Wed, 12 Nov 2014 11:48:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=b/lWpysit3+A3aiVwsGMdVgTYRnsnoJZrFFrYwNUGYc=; b=J9BErlev+WnFa8kgVSmM/E2+Cpxm4ZDfbDPtqcX6IIAPkXWkSg2VuATygys4asOnrM y5lRhUSelLg93pOiRJ4xbcU3wwQkhvqN+9ZND9J3Gay/usPmM7/6u4I/DNZZYbntnVDl 9/VxcTF7HuHCZr92ZIaUGJo4J+UglK3EKjCOe+0y0qkLCpzmfvuYERhjw8ziKMU2qVk6 1N3qS7MdD05NQy0ggZiafToQ3bo+cS8W5P+i6v0gvAWg1ktsrffYcfwG8q7UvrcJEVBa FwGX558E4/KP2X5RiA2UVRc3QNRYPeCQaY1zY6g5xTJjmkzRzGdX5Wz8wcWaWZePLVFr LTNQ== MIME-Version: 1.0 X-Received: by 10.180.182.233 with SMTP id eh9mr44970909wic.31.1415821726964; Wed, 12 Nov 2014 11:48:46 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.194.19.9 with HTTP; Wed, 12 Nov 2014 11:48:46 -0800 (PST) In-Reply-To: <20141112191635.GA91736@zxy.spb.ru> References: <560E07EA-2506-487E-88DD-E2B9F7ED9792@lastsummer.de> <20141112191635.GA91736@zxy.spb.ru> Date: Wed, 12 Nov 2014 11:48:46 -0800 X-Google-Sender-Auth: aEWhgntiK28IW59X0CQ597jxJ4s Message-ID: Subject: Re: netmap: extension to store user data per packet/slot? From: Luigi Rizzo To: Slawa Olhovchenkov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Franco Fichtner , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 12 Nov 2014 19:48:49 -0000 On Wed, Nov 12, 2014 at 11:16 AM, Slawa Olhovchenkov wrote= : > On Tue, Nov 11, 2014 at 10:13:54PM +0100, Franco Fichtner wrote: > > > Hi Luigi, > > hi all, > > > > so I was running into logistics issues with netmap(4) > > with regard to zero-copy and redirection through pipes: > > working on a load-balancing framework revealed that it > > is very hard to track a packet's origins to later move > > it onward to the respective outgoing interface, be it > > another device or the host stack. > > > > Long story short: user data needs to be stored for the > > packet buffer or slot. > > I think need configurable (by sysctl) space recerved before packet. > This is may be used as user data. Or for insert VLAN/MPLS/QinQ/etc > headers. > > =E2=80=8Bthis is yet another requirement: not just metadata but also encapsulation. For the records, the VALE switch does have TSO support (implemented through the VHOST header) so that VMs can pass large segments across a switch and they are properly split when traffic goes to a physical interface or a port that does not support the header. We also support scatter-gather I/O at least on the switch (haven't implemented this feature yet on NICs). But please consider that following this route we end up more or less into the same complications that afflict the standard stack: everything is configurable and decided at runtime, and the code becomes a maze of conditionals or indirect function calls with little chance of optimisations. Also, it's not that one sysctl works for all cases. Different ports typically have different encapsulation sizes, NICs may have alignment constraints (even those who don't suffer if buffers not 64-byte aligned), so you'll end up with scatter-gather I/O or copying anyways. After two years of experience with netmap i am not so sure anymore that zero copy makes much sense, except perhaps for the case of large packets (but i am not so sure about that, either). Apart from benchmarks, if you want to do something useful with the packets you need to read the header, at which point the concerns on having data in cache or not are less significant and the cost of the copy is heavily reduced. Tracking ownership of buffers (which is needed for zero copy) is also expensive even when they are not shared (and we have great trouble in managing the "extra buffers" we recently added to the netmap API to support zero-copy, to the point that I am tempted to remove the feature. cheers luigi From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 22:42:19 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94803E24 for ; Wed, 12 Nov 2014 22:42:19 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5A2025FB for ; Wed, 12 Nov 2014 22:42:19 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id sACMgD6w014066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 12 Nov 2014 14:42:13 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id sACMgD0L014065 for freebsd-current@freebsd.org; Wed, 12 Nov 2014 14:42:13 -0800 (PST) (envelope-from sgk) Date: Wed, 12 Nov 2014 14:42:13 -0800 From: Steve Kargl To: freebsd-current@freebsd.org Subject: shutdown or acpi problem Message-ID: <20141112224212.GA14013@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 12 Nov 2014 22:42:19 -0000 I have a kernel/world from r274273 sources, which is exhibiting a new issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' work. I get to the end of shutdown and see for example All buffers synced Uptime: 4h23m15s and then the laptop just sits there. It does not power off with the -p option nor does it reboot with the -r. Has anyone else seen this behavior? -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 23:12:48 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D99E55C1 for ; Wed, 12 Nov 2014 23:12:48 +0000 (UTC) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 592DD940 for ; Wed, 12 Nov 2014 23:12:48 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id 10so10224108lbg.14 for ; Wed, 12 Nov 2014 15:12:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CUmloID2QgfzWCXF3ysoYyyC/FtkG+jV0pnYsiBWPZM=; b=xbOe7Yntb1COQYapk+xs/HM50w+cpt2Zg9F1Uche+vtX4rJBWeQdW4gJQVxHJzzYh7 80PkfUykpOpH1QUCHxFhg3H7ICNCvvGwa9VI52k6DQbMM/9S1/11DBiCRsBnbUm6dxVL cyzjBMtaa7+lh+uan3iNP9WEmmsHN0f5QR4+NoCLpNMcrMJiJ95eZcJW7kxTlcS4+yzU BA3Gm7k9R2fCgvwrU3RX3ZIiBnjDtJbHAFCe8tw7jnVX7EhHjD+he4AHNcIQD9F8Dq1s GEV9yyRU7vM5D0N6zGXlVozQVLBETSD3RBuNwPqAxzRb0UaLw9nv/BQGCnaOFR/jHFWr OqLw== MIME-Version: 1.0 X-Received: by 10.153.11.169 with SMTP id ej9mr1216189lad.72.1415833966382; Wed, 12 Nov 2014 15:12:46 -0800 (PST) Received: by 10.25.42.193 with HTTP; Wed, 12 Nov 2014 15:12:46 -0800 (PST) In-Reply-To: <20141112224212.GA14013@troutmask.apl.washington.edu> References: <20141112224212.GA14013@troutmask.apl.washington.edu> Date: Wed, 12 Nov 2014 15:12:46 -0800 Message-ID: Subject: Re: shutdown or acpi problem From: NGie Cooper To: Steve Kargl Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 12 Nov 2014 23:12:48 -0000 On Wed, Nov 12, 2014 at 2:42 PM, Steve Kargl wrote: > I have a kernel/world from r274273 sources, which is exhibiting a new > issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' > work. I get to the end of shutdown and see for example > > All buffers synced > Uptime: 4h23m15s > > and then the laptop just sits there. It does not power off with > the -p option nor does it reboot with the -r. Has anyone else > seen this behavior? Are you upgrading from a pre-r273872 world, and if so, did you run make delete-old first ( http://svnweb.freebsd.org/base?view=revision&revision= )? Cheers! From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 23:14:38 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 895E16DF for ; Wed, 12 Nov 2014 23:14:38 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 674F9954 for ; Wed, 12 Nov 2014 23:14:38 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id sACNEbrW014277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 12 Nov 2014 15:14:37 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id sACNEbdx014276 for freebsd-current@freebsd.org; Wed, 12 Nov 2014 15:14:37 -0800 (PST) (envelope-from sgk) Date: Wed, 12 Nov 2014 15:14:37 -0800 From: Steve Kargl To: freebsd-current@freebsd.org Subject: Re: shutdown or acpi problem Message-ID: <20141112231437.GA14255@troutmask.apl.washington.edu> References: <20141112224212.GA14013@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141112224212.GA14013@troutmask.apl.washington.edu> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 12 Nov 2014 23:14:38 -0000 On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: > I have a kernel/world from r274273 sources, which is exhibiting a new > issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' > work. I get to the end of shutdown and see for example > > All buffers synced > Uptime: 4h23m15s > > and then the laptop just sits there. It does not power off with > the -p option nor does it reboot with the -r. Has anyone else > seen this behavior? > Note booting /boot/kernel.old/kernel and then using 'shutdown -p now' works as expected. The old kernel was bulit from r271492 sources. Any guidance on where to start to debug this issue would be welcomed. -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 23:26:55 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F25F892D for ; Wed, 12 Nov 2014 23:26:55 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B5880A64 for ; Wed, 12 Nov 2014 23:26:55 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id sACNQtWY014317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 Nov 2014 15:26:55 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id sACNQt4q014316; Wed, 12 Nov 2014 15:26:55 -0800 (PST) (envelope-from sgk) Date: Wed, 12 Nov 2014 15:26:55 -0800 From: Steve Kargl To: NGie Cooper Subject: Re: shutdown or acpi problem Message-ID: <20141112232655.GB14255@troutmask.apl.washington.edu> References: <20141112224212.GA14013@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 12 Nov 2014 23:26:56 -0000 On Wed, Nov 12, 2014 at 03:12:46PM -0800, NGie Cooper wrote: > On Wed, Nov 12, 2014 at 2:42 PM, Steve Kargl > wrote: > > I have a kernel/world from r274273 sources, which is exhibiting a new > > issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' > > work. I get to the end of shutdown and see for example > > > > All buffers synced > > Uptime: 4h23m15s > > > > and then the laptop just sits there. It does not power off with > > the -p option nor does it reboot with the -r. Has anyone else > > seen this behavior? > > Are you upgrading from a pre-r273872 world, and if so, did you run > make delete-old first ( > http://svnweb.freebsd.org/base?view=revision&revision= )? > Cheers! > _______________________________________________ I run 'make delete-old' and 'make delete-old-libs' after each installworld. In this case, I was upgrading from r271492 to r274273. The procedure I use is cd /usr/obj rm -rf * cd /usr/src svn update make buildworld make buildkernel make installkernel mergemaster -p (may or may not boot to single user mode here) make installworld mergemaster -iU make delete-old make delete-old-libs shutdown -r +1 -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 23:53:13 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5ECAF2A for ; Wed, 12 Nov 2014 23:53:13 +0000 (UTC) Received: from acipenser.esturion.net (acipenser.esturion.net [65.101.5.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BEA93CF9 for ; Wed, 12 Nov 2014 23:53:13 +0000 (UTC) Received: by acipenser.esturion.net (Postfix, from userid 112) id 7686826040D; Wed, 12 Nov 2014 16:53:05 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on acipenser.esturion.net X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Received: from feyerabend.n1.pinyon.org (quine.pinyon.org [65.101.5.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by acipenser.esturion.net (Postfix) with ESMTPSA id 6D33C26012A for ; Wed, 12 Nov 2014 16:53:03 -0700 (MST) Message-ID: <5463F2DE.2040408@pinyon.org> Date: Wed, 12 Nov 2014 16:53:02 -0700 From: "Russell L. Carter" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: building stable/10 on -current Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 12 Nov 2014 23:53:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On current r273808, make buildworld in a stable/10 tree fails with: building shared library libc.so.7 /usr/bin/ld: _umtx_unlock.So: relocation R_X86_64_32 against `SYS__umtx_unlock' can not be used when making a shared object; recompile with -fPIC _umtx_unlock.So: could not read symbols: Bad value However, poudriere can build it just fine in its jail. I am curious why that is. Can a -current host be made to build stable/10, or is that impossible? Thanks, Russell -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUY/LeAAoJEFnLrGVSDFaE0IEQAJ3PMZduxTkNpTp8jVTQjPQO L7Ngzp46qpsuIIPDJ2mwFwKUC5R5qA9nh2oHgt0RTJjGYXpj5k7K5PN2Qt/0jZnf sLt6ju05cTfF1gPch1hD54N9ADG2MIiXs+Fa4CI/GiROwP+AWesI+Ri71E8SBqqn yjZF4QLP1S4QlKuhHrsSv2REUj/lv7qmJyxuih9HePJIIvUHguvy/5imKD/3WSxX 6MO1JjEneKvI3lGMcAV15/6z13GPHaj/vCZZ7lGfthHvYUWqtalRx9S3XM3AUgNq MKk2U5L9lAf346RTbVRv/ff3N61+3ahBJ1StJNMetk80WtmokTvAuKC4y8Ywrr8e GiLrYoPm6rPTlEj87/QHTBSg/uiXogI14vcRs/npiS2Uw2B8k6iXOxQxpnNiedqA xkc310MJCSUuB/1p5HC+gU3rIw8k+gEmVVCW9yx/rcdKCm6wLG/h9yGeA0/gI1nb QCTwLvOcq+mjQgH/AQlBm+s0otT4nonU93dcpxRwW/0F1D5zBIqzGzm66O6Gh83Z vgZMXHgfVr1FAer03vRHQjRWYl0CcaQ4DnaIXmJHz+m39x+/C3IFIeuBt9LIu1rM GBdml6+nbAK0B6UahbdpRQfadha5gZ1QKap4Fy2oO9XlR4ovTYcqLzNfHTfANd2Q mBnfMYYLqVY0UzI3hzqu =T1Ia -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Nov 13 02:03:20 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8FBBC927 for ; Thu, 13 Nov 2014 02:03:20 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 51E50AF9 for ; Thu, 13 Nov 2014 02:03:20 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sAD23gNL011514; Wed, 12 Nov 2014 18:03:43 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: NGie Cooper , Steve Kargl In-Reply-To: <20141112232655.GB14255@troutmask.apl.washington.edu> References: <20141112224212.GA14013@troutmask.apl.washington.edu> , <20141112232655.GB14255@troutmask.apl.washington.edu> From: "Chris H" Subject: Re: shutdown or acpi problem Date: Wed, 12 Nov 2014 18:03:43 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <92789318fd5154c3da0f7ea3f5362f67@ultimatedns.net> Content-Transfer-Encoding: 8bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 13 Nov 2014 02:03:20 -0000 On Wed, 12 Nov 2014 15:26:55 -0800 Steve Kargl wrote > On Wed, Nov 12, 2014 at 03:12:46PM -0800, NGie Cooper wrote: > > On Wed, Nov 12, 2014 at 2:42 PM, Steve Kargl > > wrote: > > > I have a kernel/world from r274273 sources, which is exhibiting a new > > > issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' > > > work. I get to the end of shutdown and see for example > > > > > > All buffers synced > > > Uptime: 4h23m15s > > > > > > and then the laptop just sits there. It does not power off with > > > the -p option nor does it reboot with the -r. Has anyone else > > > seen this behavior? > > > > Are you upgrading from a pre-r273872 world, and if so, did you run > > make delete-old first ( > > http://svnweb.freebsd.org/base?view=revision&revision= )? > > Cheers! > > _______________________________________________ > > I run 'make delete-old' and 'make delete-old-libs' after > each installworld. In this case, I was upgrading from > r271492 to r274273. The procedure I use is > > cd /usr/obj Can I throw a chflags -R noschg * here first? Point being, you may well not have gotten everything, otherwise. :) > rm -rf * > cd /usr/src > svn update > make buildworld > make buildkernel > make installkernel > mergemaster -p > (may or may not boot to single user mode here) > make installworld > mergemaster -iU > make delete-old > make delete-old-libs > shutdown -r +1 > > -- > Steve --Chris > _______________________________________________ > 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 Nov 13 02:08:59 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0C75A74 for ; Thu, 13 Nov 2014 02:08:59 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A443FB26 for ; Thu, 13 Nov 2014 02:08:59 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id sAD28qfs015125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 Nov 2014 18:08:52 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id sAD28qjp015124; Wed, 12 Nov 2014 18:08:52 -0800 (PST) (envelope-from sgk) Date: Wed, 12 Nov 2014 18:08:52 -0800 From: Steve Kargl To: Chris H Subject: Re: shutdown or acpi problem Message-ID: <20141113020852.GA15115@troutmask.apl.washington.edu> References: <20141112224212.GA14013@troutmask.apl.washington.edu> <20141112232655.GB14255@troutmask.apl.washington.edu> <92789318fd5154c3da0f7ea3f5362f67@ultimatedns.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <92789318fd5154c3da0f7ea3f5362f67@ultimatedns.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD Current , NGie Cooper X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 13 Nov 2014 02:09:00 -0000 On Wed, Nov 12, 2014 at 06:03:43PM -0800, Chris H wrote: > On Wed, 12 Nov 2014 15:26:55 -0800 Steve Kargl > wrote > > > I run 'make delete-old' and 'make delete-old-libs' after > > each installworld. In this case, I was upgrading from > > r271492 to r274273. The procedure I use is > > > > cd /usr/obj > Can I throw a > > chflags -R noschg * > > here first? Point being, you may well not have gotten > everything, otherwise. :) It's not needed. -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Nov 13 02:26:48 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E233BF09 for ; Thu, 13 Nov 2014 02:26:48 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A7F4ECC4 for ; Thu, 13 Nov 2014 02:26:48 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sAD2RCqk018397; Wed, 12 Nov 2014 18:27:12 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: Steve Kargl In-Reply-To: <20141113020852.GA15115@troutmask.apl.washington.edu> References: <20141112224212.GA14013@troutmask.apl.washington.edu> <20141112232655.GB14255@troutmask.apl.washington.edu> <92789318fd5154c3da0f7ea3f5362f67@ultimatedns.net>, <20141113020852.GA15115@troutmask.apl.washington.edu> From: "Chris H" Subject: Re: shutdown or acpi problem Date: Wed, 12 Nov 2014 18:27:13 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <1a9e9845d80c8049a81af2d1b29be3da@ultimatedns.net> Content-Transfer-Encoding: 8bit Cc: FreeBSD Current , NGie Cooper X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 13 Nov 2014 02:26:49 -0000 On Wed, 12 Nov 2014 18:08:52 -0800 Steve Kargl wrote > On Wed, Nov 12, 2014 at 06:03:43PM -0800, Chris H wrote: > > On Wed, 12 Nov 2014 15:26:55 -0800 Steve Kargl > > wrote > > > > > I run 'make delete-old' and 'make delete-old-libs' after > > > each installworld. In this case, I was upgrading from > > > r271492 to r274273. The procedure I use is > > > > > > cd /usr/obj > > Can I throw a > > > > chflags -R noschg * > > > > here first? Point being, you may well not have gotten > > everything, otherwise. :) > > It's not needed. How so? It's been necessary for as long as I can remember. Just to confirm, I looked to see if anything had changed: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html seems not. Do note; I'm not trying to be argumentative. Just don't see where it's not true (needed). :) --Chris > > -- > Steve From owner-freebsd-current@FreeBSD.ORG Thu Nov 13 02:43:38 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 836D625C for ; Thu, 13 Nov 2014 02:43:38 +0000 (UTC) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4875DE53 for ; Thu, 13 Nov 2014 02:43:38 +0000 (UTC) Received: by mail-ig0-f181.google.com with SMTP id l13so4522694iga.2 for ; Wed, 12 Nov 2014 18:43:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DWJBumWKVxrkneklcAItX85tH8x45ZieMQwcfkEnnvk=; b=tXCkdGRr/mHHgkl8Z07I0o923KFCoMpRH/Qdhwk03eAG3BS7cfRHxcU7R43nOOwENG rAbZkbypcsevFeRuJw8tBakzo5nh5IkVwBHnobkOHte+cBOzHpljmErGJ0OPMfBtPUrJ sWidSE7dMBekleJBRTBF3LS6jjaSiL5+Sk1daGtfNak9xCCaal26mg3vDjch4QAi7/Fa yo5N2wMrmAWoxi68u7fPnnw/zI5/VVRP0VuEzpeIu8SKhDbBYPfoszAG0X4N1QoAJ+Rd yQufC9gqFjHOjs81zvWvlpQpzg+4Ps8AsQZTw4sPCg5ttI+gIUiTWFbx0Knv4ZN50qdg V62Q== MIME-Version: 1.0 X-Received: by 10.43.90.198 with SMTP id bj6mr2470635icc.4.1415846617690; Wed, 12 Nov 2014 18:43:37 -0800 (PST) Received: by 10.50.235.49 with HTTP; Wed, 12 Nov 2014 18:43:37 -0800 (PST) In-Reply-To: <1a9e9845d80c8049a81af2d1b29be3da@ultimatedns.net> References: <20141112224212.GA14013@troutmask.apl.washington.edu> <20141112232655.GB14255@troutmask.apl.washington.edu> <92789318fd5154c3da0f7ea3f5362f67@ultimatedns.net> <20141113020852.GA15115@troutmask.apl.washington.edu> <1a9e9845d80c8049a81af2d1b29be3da@ultimatedns.net> Date: Wed, 12 Nov 2014 18:43:37 -0800 Message-ID: Subject: Re: shutdown or acpi problem From: NGie Cooper To: Chris H Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Current , Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 13 Nov 2014 02:43:38 -0000 On Wed, Nov 12, 2014 at 6:27 PM, Chris H wrote: ... > How so? It's been necessary for as long > as I can remember. Just to confirm, I looked to see if anything > had changed: > https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html > seems not. Do note; I'm not trying to be argumentative. Just > don't see where it's not true (needed). :) It's technically not needed with -DNO_CLEAN (it's handled in Makefile.inc1), however if you're doing that you might as well not specify NO_CLEAN: http://svnweb.freebsd.org/base/head/Makefile.inc1?view=annotate#l481 Cheers! From owner-freebsd-current@FreeBSD.ORG Thu Nov 13 02:46:40 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36D5536F for ; Thu, 13 Nov 2014 02:46:40 +0000 (UTC) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EF248E67 for ; Thu, 13 Nov 2014 02:46:39 +0000 (UTC) Received: by mail-ig0-f169.google.com with SMTP id hn18so426235igb.4 for ; Wed, 12 Nov 2014 18:46:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=puW2fNS+qncfZO5Qx2tK2OUPPEpLWr6wJOMC12O82tg=; b=0QJTEZfSj8tTV4wh23l6cKbYvD9sDxp8TuPotraQHHFCwdIiG214pJ4aLN/Gbk1km1 ursbGWz9XezEigAINBVxI5QzZVuJ36GGBgAE4NXFqhPdIy/hDpihCO5lmI1Pbu5JLKkX yEdnlf2ceCwWWCYWD3X1zwxCHcaYqLXrhX7u9vLKsZkGt1LH2wRG3Is8KH1jHzQiocQf HsaK2UyRCh+SM25UFJ5q40JzeiuxMxOcb5ezprOwK6Se92B1PsKXNx+b5E6RuDNV2GM4 cvk3PSBi5xylTxc7BlhchRX2059sjwIl5PqUjFPnnNCM0FjODZIThVTVgV/nc4qnFGW6 Vm4A== MIME-Version: 1.0 X-Received: by 10.50.50.228 with SMTP id f4mr44212748igo.49.1415846799490; Wed, 12 Nov 2014 18:46:39 -0800 (PST) Received: by 10.50.235.49 with HTTP; Wed, 12 Nov 2014 18:46:39 -0800 (PST) In-Reply-To: References: <20141112224212.GA14013@troutmask.apl.washington.edu> <20141112232655.GB14255@troutmask.apl.washington.edu> <92789318fd5154c3da0f7ea3f5362f67@ultimatedns.net> <20141113020852.GA15115@troutmask.apl.washington.edu> <1a9e9845d80c8049a81af2d1b29be3da@ultimatedns.net> Date: Wed, 12 Nov 2014 18:46:39 -0800 Message-ID: Subject: Re: shutdown or acpi problem From: NGie Cooper To: Chris H Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Current , Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 13 Nov 2014 02:46:40 -0000 On Wed, Nov 12, 2014 at 6:43 PM, NGie Cooper wrote: > On Wed, Nov 12, 2014 at 6:27 PM, Chris H wrote: > > ... > >> How so? It's been necessary for as long >> as I can remember. Just to confirm, I looked to see if anything >> had changed: >> https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html >> seems not. Do note; I'm not trying to be argumentative. Just >> don't see where it's not true (needed). :) > > It's technically not needed with -DNO_CLEAN (it's handled in > Makefile.inc1), however if you're doing that you might as well not > specify NO_CLEAN: > > http://svnweb.freebsd.org/base/head/Makefile.inc1?view=annotate#l481 My apologies... I was thinking of another build process. Yes, it's very much required according to the process noted in the handbook. From owner-freebsd-current@FreeBSD.ORG Thu Nov 13 02:56:39 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89D7B4FD for ; Thu, 13 Nov 2014 02:56:39 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6499BF3D for ; Thu, 13 Nov 2014 02:56:39 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id sAD2uXvK015394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 Nov 2014 18:56:33 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id sAD2uWkY015393; Wed, 12 Nov 2014 18:56:32 -0800 (PST) (envelope-from sgk) Date: Wed, 12 Nov 2014 18:56:32 -0800 From: Steve Kargl To: Chris H Subject: Re: shutdown or acpi problem Message-ID: <20141113025632.GA15384@troutmask.apl.washington.edu> References: <20141112224212.GA14013@troutmask.apl.washington.edu> <20141112232655.GB14255@troutmask.apl.washington.edu> <92789318fd5154c3da0f7ea3f5362f67@ultimatedns.net> <20141113020852.GA15115@troutmask.apl.washington.edu> <1a9e9845d80c8049a81af2d1b29be3da@ultimatedns.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1a9e9845d80c8049a81af2d1b29be3da@ultimatedns.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD Current , NGie Cooper X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 13 Nov 2014 02:56:39 -0000 On Wed, Nov 12, 2014 at 06:27:13PM -0800, Chris H wrote: > On Wed, 12 Nov 2014 18:08:52 -0800 Steve Kargl > wrote > > > On Wed, Nov 12, 2014 at 06:03:43PM -0800, Chris H wrote: > > > On Wed, 12 Nov 2014 15:26:55 -0800 Steve Kargl > > > wrote > > > > > > > I run 'make delete-old' and 'make delete-old-libs' after > > > > each installworld. In this case, I was upgrading from > > > > r271492 to r274273. The procedure I use is > > > > > > > > cd /usr/obj > > > Can I throw a > > > > > > chflags -R noschg * > > > > > > here first? Point being, you may well not have gotten > > > everything, otherwise. :) > > > > It's not needed. > How so? It's been necessary for as long > as I can remember. Just to confirm, I looked to see if anything > had changed: > https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html > seems not. Do note; I'm not trying to be argumentative. Just > don't see where it's not true (needed). :) It not needed. % su root % script Script started on Wed Nov 12 18:54:16 2014 troutmask:root[201] cd /usr/obj troutmask:root[202] ls usr/ troutmask:root[203] rm -rf usr troutmask:root[204] ls troutmask:root[205] exit exit Script done on Wed Nov 12 18:54:40 2014 QED -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Nov 13 03:30:45 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1442CA86 for ; Thu, 13 Nov 2014 03:30:45 +0000 (UTC) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mailuogwprd01.lss.emc.com", Issuer "RSA Corporate Server CA v2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B771835F for ; Thu, 13 Nov 2014 03:30:44 +0000 (UTC) Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sAD3Ub37023288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 12 Nov 2014 22:30:37 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com sAD3Ub37023288 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=isilon.com; s=jan2013; t=1415849437; bh=ZDW5xhesU7Ohy25VvXbgQ89t4CQ=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=EgUbn3X+m78M5A5QLxodUl9OvhaywxalHydDXLXpAviG9i4Aw4MSeLtTJ0YZrI19B ERoj7KZkBX2esYXrOpi1x94VXlzrMw5U7HvxwMlAfc14tgbFktqiMOLRgdDWWqHkXv RZ/Kr6PsTFY2qEG/vvdcR0tHUpTVENe5nx398ZS4= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com sAD3Ub37023288 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd04.lss.emc.com (RSA Interceptor) for ; Wed, 12 Nov 2014 22:30:07 -0500 Received: from mxhub22.corp.emc.com (mxhub22.corp.emc.com [128.222.70.134]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sAD3UOSD002463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 12 Nov 2014 22:30:24 -0500 Received: from MXHUB108.corp.emc.com (10.253.58.24) by mxhub22.corp.emc.com (128.222.70.134) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 12 Nov 2014 22:30:23 -0500 Received: from MX104CL01.corp.emc.com ([169.254.7.35]) by MXHUB108.corp.emc.com ([10.253.58.24]) with mapi id 14.03.0195.001; Wed, 12 Nov 2014 22:30:23 -0500 From: "Rang, Anton" To: "freebsd-current@freebsd.org" Subject: Minor bug in SCSI definition Thread-Topic: Minor bug in SCSI definition Thread-Index: Ac/+8bm7L6SD3RGAR7mfJJ6wuTR2AA== Date: Thu, 13 Nov 2014 03:30:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.46.243] MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: Source Code, public Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 13 Nov 2014 03:30:45 -0000 Coverity found an issue in this area which I tracked down to the incorrect = definition patched below. The SID_QUAL macro is (((inq_data)->device & 0xE0) >> 5) which extracts the= peripheral qualifier. Per SCSI-2 (draft 10L) table 46, the vendor-specific values are "1XXb". This probably affects almost nobody, but it will clear up a couple of Cover= ity warnings. Anton Index: sys/cam/scsi/scsi_all.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/cam/scsi/scsi_all.h (revision 274352) +++ sys/cam/scsi/scsi_all.h (working copy) @@ -1817,7 +1817,7 @@ * reserved for = this peripheral * qualifier. */ -#define SID_QUAL_IS_VENDOR_UNIQUE(inq_data) ((SID_QUAL(inq_data) = & 0x08) !=3D 0) +#define SID_QUAL_IS_VENDOR_UNIQUE(inq_data) ((SID_QUAL(inq_data) &= 0x04) !=3D 0) u_int8_t dev_qual2; #define SID_QUAL2 0x7F #define SID_LU_CONG 0x40 From owner-freebsd-current@FreeBSD.ORG Thu Nov 13 03:44:18 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A183CB3; Thu, 13 Nov 2014 03:44:18 +0000 (UTC) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DC55F6C9; Thu, 13 Nov 2014 03:44:17 +0000 (UTC) Received: by mail-ig0-f171.google.com with SMTP id hl2so4270521igb.4 for ; Wed, 12 Nov 2014 19:44:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xp2vOxpxr61sFNYeGprjcGU4tlh7GXBK5jfkZNMW9a0=; b=T1GG5QV7XyqgLM4cd70J/R5hl/N+D7yHXZoV8vhtiOPsoefJ7cPhFfBWKGDpUzvqx2 L0rFWTduuSZhPZ6Eo9Sr4l+ubDZkiYoeiSIZ/ePjuD6zlVH2HTjv3eV9Mi0kySBAXDQo EfUstjDyNKnOyTaoYE9XQmjZdek2boKsdlBuhfz88H1HJK9B0GNC/90j8olS30U/9K9e lmOCtx/nqWJw9CwGCB08Q71LADUfIl3c6k59+f81E6A7KmeBI2pWdm0GrrNksTF6r0zm HY4KqIAlb/xkhY/jstp+DAV/yD7TFN7FUh310wxOkgYmyolUi5KUmEkub2iYO2Nkowxt VfTA== MIME-Version: 1.0 X-Received: by 10.107.137.194 with SMTP id t63mr29423629ioi.52.1415850257034; Wed, 12 Nov 2014 19:44:17 -0800 (PST) Received: by 10.50.235.49 with HTTP; Wed, 12 Nov 2014 19:44:16 -0800 (PST) In-Reply-To: References: Date: Wed, 12 Nov 2014 19:44:16 -0800 Message-ID: Subject: Re: Minor bug in SCSI definition From: NGie Cooper To: "Rang, Anton" Content-Type: text/plain; charset=UTF-8 Cc: Scott Long , Alexander Motin , "freebsd-current@freebsd.org" , "Kenneth D. Merry" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 13 Nov 2014 03:44:18 -0000 On Wed, Nov 12, 2014 at 7:30 PM, Rang, Anton wrote: > Coverity found an issue in this area which I tracked down to the incorrect definition patched below. > > The SID_QUAL macro is (((inq_data)->device & 0xE0) >> 5) which extracts the peripheral qualifier. > Per SCSI-2 (draft 10L) table 46, the vendor-specific values are "1XXb". > > This probably affects almost nobody, but it will clear up a couple of Coverity warnings. > > Anton > > Index: sys/cam/scsi/scsi_all.h > =================================================================== > --- sys/cam/scsi/scsi_all.h (revision 274352) > +++ sys/cam/scsi/scsi_all.h (working copy) > @@ -1817,7 +1817,7 @@ > * reserved for this peripheral > * qualifier. > */ > -#define SID_QUAL_IS_VENDOR_UNIQUE(inq_data) ((SID_QUAL(inq_data) & 0x08) != 0) > +#define SID_QUAL_IS_VENDOR_UNIQUE(inq_data) ((SID_QUAL(inq_data) & 0x04) != 0) > u_int8_t dev_qual2; > #define SID_QUAL2 0x7F > #define SID_LU_CONG 0x40 CCing ken@/mav@/scottl@ -- thanks! From owner-freebsd-current@FreeBSD.ORG Thu Nov 13 05:18:13 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E24EA659 for ; Thu, 13 Nov 2014 05:18:13 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id D3781E64 for ; Thu, 13 Nov 2014 05:18:13 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id F2FADFDA for ; Thu, 13 Nov 2014 05:18:13 +0000 (UTC) Date: Thu, 13 Nov 2014 05:18:13 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1367088253.43.1415855893739.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build became unstable: FreeBSD_HEAD-tests2 #237 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 13 Nov 2014 05:18:14 -0000 See From owner-freebsd-current@FreeBSD.ORG Thu Nov 13 08:07:19 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C49B1E0 for ; Thu, 13 Nov 2014 08:07:19 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 8B953AB for ; Thu, 13 Nov 2014 08:07:19 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id EA84B92 for ; Thu, 13 Nov 2014 08:07:19 +0000 (UTC) Date: Thu, 13 Nov 2014 08:07:19 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <641957638.44.1415866039914.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1367088253.43.1415855893739.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1367088253.43.1415855893739.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #238 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 13 Nov 2014 08:07:19 -0000 See From owner-freebsd-current@FreeBSD.ORG Thu Nov 13 14:08:53 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75C8CDD5 for ; Thu, 13 Nov 2014 14:08:53 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 64BEDE1A for ; Thu, 13 Nov 2014 14:08:53 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id BC5B3110 for ; Thu, 13 Nov 2014 14:08:53 +0000 (UTC) Date: Thu, 13 Nov 2014 14:08:53 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <567282484.45.1415887733676.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <641957638.44.1415866039914.JavaMail.jenkins@jenkins-9.freebsd.org> References: <641957638.44.1415866039914.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #239 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 13 Nov 2014 14:08:53 -0000 See From owner-freebsd-current@FreeBSD.ORG Thu Nov 13 17:25:35 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 112EB3A7 for ; Thu, 13 Nov 2014 17:25:35 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DC1F5A90 for ; Thu, 13 Nov 2014 17:25:34 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id sADHPYpt018760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 13 Nov 2014 09:25:34 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id sADHPXPZ018759 for freebsd-current@freebsd.org; Thu, 13 Nov 2014 09:25:33 -0800 (PST) (envelope-from sgk) Date: Thu, 13 Nov 2014 09:25:33 -0800 From: Steve Kargl To: freebsd-current@freebsd.org Subject: USB locks up system -- WAS Re: shutdown or acpi problem Message-ID: <20141113172533.GA18690@troutmask.apl.washington.edu> References: <20141112224212.GA14013@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141112224212.GA14013@troutmask.apl.washington.edu> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 13 Nov 2014 17:25:35 -0000 On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: > I have a kernel/world from r274273 sources, which is exhibiting a new > issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' > work. I get to the end of shutdown and see for example > > All buffers synced > Uptime: 4h23m15s > > and then the laptop just sits there. It does not power off with > the -p option nor does it reboot with the -r. Has anyone else > seen this behavior? > The problem appears to be related to a recent change in the USB stack. If I have the following drive plugged into a usb port, the above behavior is observed on shutdown. ugen6.2: at usbus6 umass0: on usbus6 da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: Fixed Direct Access SCSI-6 device da0: Serial Number 57584B314537324445595A31 da0: 40.000MB/s transfers da0: 1907697MB (3906963456 512 byte sectors: 255H 63S/T 243197C) da0: quirks=0x2 ses1 at umass-sim0 bus 0 scbus4 target 0 lun 1 ses1: Fixed Enclosure Services SCSI-6 device ses1: Serial Number 57584B314537324445595A31 ses1: 40.000MB/s transfers ses1: SCSI-3 ENC Device If this drive was never plugged into a usb port, 'shutdown -r now' and 'shutdown -p now' work as expected. If drive is plugged into a usb port, and I then unplug the drive the laptop is turned into a brick. In a vt(4) console, there is no keyboard and no output is displayed to the console. Logging into the laptop with ssh works. With the laptop in a brick state, issuing 'usbconfig' yields a wedged process with no output to the terminal and 'usbconfig' is unkillable. ^T yields load: 0.30 cmd: usbconfig 1068 [USB config SX lock] 441.15r 0.00u 0.00s 1884k. Unfortunately, a 'gdb -p 1068' yields a core dump for gdb. :( Logging into the laptop again with ssh works. Issuing the command 'camcontrol rescan all' yields Re-scan of bus 4 returned error 0xa Re-scan of bus 0 was successful Re-scan of bus 1 was successful Re-scan of bus 2 was successful Re-scan of bus 3 was successful dmesg follows my sig. -- Steve Copyright (c) 1992-2014 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 11.0-CURRENT #0 r274456: Thu Nov 13 07:45:01 PST 2014 kargl@laptop-kargl.apl.washington.edu:/usr/obj/usr/src/sys/MOBILE i386 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 VT: running with driver "vga". CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz 686-class CPU) Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20000000 AMD Features2=0x1 VT-x: (disabled in BIOS) HLT,PAUSE TSC: P-state invariant, performance statistics real memory = 3221225472 (3072 MB) avail memory = 3136098304 (2990 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard random: entropy device infrastructure driver random: selecting highest priority adaptor kbd1 at kbdmux0 random: SOFT: yarrow init() random: selecting highest priority adaptor module_register_init: MOD_LOAD (vesa, 0xc0b3a4e0, 0) error 19 acpi0: on motherboard hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 acpi0: reservation of 0, 9f000 (3) failed acpi0: reservation of 100000, bf5c0400 (3) failed cpu0: on acpi0 cpu1: on acpi0 atrtc0: port 0x70-0x71,0x72-0x77 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 2 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xeff8-0xefff mem 0xfea00000-0xfeafffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 vgapci0: Boot video device vgapci1: mem 0xfeb00000-0xfebfffff at device 2.1 on pci0 uhci0: port 0x6f20-0x6f3f irq 20 at device 26.0 on pci0 usbus0 on uhci0 uhci1: port 0x6f00-0x6f1f irq 21 at device 26.1 on pci0 usbus1 on uhci1 ehci0: mem 0xfed1c400-0xfed1c7ff irq 22 at device 26.7 on pci0 usbus2: EHCI version 1.0 usbus2 on ehci0 hdac0: mem 0xfe9fc000-0xfe9fffff irq 21 at device 27.0 on pci0 pcib1: at device 28.0 on pci0 pci11: on pcib1 pcib2: at device 28.1 on pci0 pci12: on pcib2 wpi0: mem 0xfe8ff000-0xfe8fffff irq 17 at device 0.0 on pci12 pcib3: at device 28.5 on pci0 pci9: on pcib3 bge0: mem 0xfe7f0000-0xfe7fffff irq 17 at device 0.0 on pci9 bge0: CHIP ID 0x0000a002; ASIC REV 0x0a; CHIP REV 0xa0; PCI-E miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: 00:1d:09:ba:cc:0d uhci2: port 0x6f80-0x6f9f irq 20 at device 29.0 on pci0 usbus3 on uhci2 uhci3: port 0x6f60-0x6f7f irq 21 at device 29.1 on pci0 usbus4 on uhci3 uhci4: port 0x6f40-0x6f5f irq 22 at device 29.2 on pci0 usbus5 on uhci4 ehci1: mem 0xfed1c000-0xfed1c3ff irq 20 at device 29.7 on pci0 usbus6: EHCI version 1.0 usbus6 on ehci1 pcib4: at device 30.0 on pci0 pci3: on pcib4 cbb0: at device 1.0 on pci3 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pci3: at device 1.4 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x6fa0-0x6faf irq 16 at device 31.1 on pci0 ata0: at channel 0 on atapci0 ahci0: port 0x6eb0-0x6eb7,0x6eb8-0x6ebb,0x6ec0-0x6ec7,0x6ec8-0x6ecb,0x6ee0-0x6eff mem 0xfe9fb800-0xfe9fbfff irq 17 at device 31.2 on pci0 ahci0: AHCI v1.10 with 3 3Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich2: at channel 2 on ahci0 ahciem0: on ahci0 ichsmb0: port 0x10c0-0x10df mem 0xfe9fb700-0xfe9fb7ff irq 17 at device 31.3 on pci0 smbus0: on ichsmb0 smb0: on smbus0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64,0x62,0x66 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model GlidePoint, device ID 0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ichwd0 on isa0 ichwd0: resuming after hardware watchdog timeout pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcefff,0xcf000-0xcffff pnpid ORM0000 on isa0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: parallel port not found. coretemp0: on cpu0 est0: on cpu0 coretemp1: on cpu1 est1: on cpu1 fuse-freebsd: version 0.4.4, FUSE ABI 7.8 Timecounters tick every 1.000 msec hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 13,10 and 12,11 on hdaa0 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: 12Mbps Full Speed USB v1.0 usbus6: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen2.1: at usbus2 ugen1.1: at usbus1 uhub1: on usbus1 ugen5.1: at usbus5 ugen4.1: at usbus4 uhub2: on usbus4 ugen3.1: at usbus3 ugen6.1: at usbus6 uhub3: on usbus6 uhub4: on usbus2 uhub5: on usbus5 uhub6: on usbus3 ses0 at ahciem0 bus 0 scbus3 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 ada0: ATA-7 SATA 1.x device ada0: Serial Number WD-WXCZ07905963 ada0: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 76319MB (156301488 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 random: unblocking device. SMP: AP CPU #1 Launched! cd0 at ata0 bus 0 scbus0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present hwpmc: SOFT/16/64/0x67 TSC/1/64/0x20 IAP/2/40/0x3ff IAF/3/40/0x67 uhub2: 2 ports with 2 removable, self powered uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered Root mount waiting for: usbus6 usbus2 Root mount waiting for: usbus6 usbus2 uhub4: 4 ports with 4 removable, self powered uhub3: 6 ports with 6 removable, self powered Root mount waiting for: usbus6 Trying to mount root from ufs:/dev/ada0s3a [rw]... WARNING: / was not properly dismounted WARNING: /: mount pending error: blocks 8 files 0 ugen4.2: at usbus4 ums0: on usbus4 ums0: 8 buttons and [XYZT] coordinates ID=0 uhid0: on usbus4 bge0: link state changed to UP agp0: on vgapci0 agp0: aperture size is 256M, detected 7676k stolen memory info: [drm] Initialized drm 1.1.0 20060810 drmn0: on vgapci0 info: [drm] MSI enabled 1 message(s) info: [drm] AGP at 0xe0000000 256MB iicbus0: on iicbb0 addr 0xec iic0: on iicbus0 iic1: on iicbus1 iicbus2: on iicbb1 addr 0xc8 iic2: on iicbus2 iic3: on iicbus3 iicbus4: on iicbb2 addr 0xc8 iic4: on iicbus4 iic5: on iicbus5 iicbus6: on iicbb3 addr 0xc8 iic6: on iicbus6 iic7: on iicbus7 iicbus8: on iicbb4 addr 0xc8 iic8: on iicbus8 iic9: on iicbus9 iicbus10: on iicbb5 addr 0xc8 iic10: on iicbus10 iic11: on iicbus11 iicbus12: on iicbb6 addr 0xc8 iic12: on iicbus12 iic13: on iicbus13 iicbus14: on iicbb7 addr 0xc8 iic14: on iicbus14 iic15: on iicbus15 info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. composite sync not supported drmn0: taking over the fictitious range 0xe0000000-0xf0000000 info: [drm] initialized overlay support info: [drm] Connector LVDS-1: get mode from tunables: info: [drm] - kern.vt.fb.modes.LVDS-1 info: [drm] - kern.vt.fb.default_mode info: [drm] Connector VGA-1: get mode from tunables: info: [drm] - kern.vt.fb.modes.VGA-1 info: [drm] - kern.vt.fb.default_mode info: [drm] Connector DVI-D-1: get mode from tunables: info: [drm] - kern.vt.fb.modes.DVI-D-1 info: [drm] - kern.vt.fb.default_mode info: [drm] Connector SVIDEO-1: get mode from tunables: info: [drm] - kern.vt.fb.modes.SVIDEO-1 info: [drm] - kern.vt.fb.default_mode composite sync not supported fbd0 on drmn0 VT: Replacing driver "vga" with new "fb". info: [drm] Initialized i915 1.6.0 20080730 composite sync not supported composite sync not supported ugen6.2: at usbus6 umass0: on usbus6 da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: Fixed Direct Access SCSI-6 device da0: Serial Number 57584B314537324445595A31 da0: 40.000MB/s transfers da0: 1907697MB (3906963456 512 byte sectors: 255H 63S/T 243197C) da0: quirks=0x2 ses1 at umass-sim0 bus 0 scbus4 target 0 lun 1 ses1: Fixed Enclosure Services SCSI-6 device ses1: Serial Number 57584B314537324445595A31 ses1: 40.000MB/s transfers ses1: SCSI-3 ENC Device From owner-freebsd-current@FreeBSD.ORG Thu Nov 13 17:39:49 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E07A0A72; Thu, 13 Nov 2014 17:39:49 +0000 (UTC) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id C6962BCA; Thu, 13 Nov 2014 17:39:49 +0000 (UTC) Received: from marvin.lab.vangyzen.net (c-24-125-214-90.hsd1.va.comcast.net [24.125.214.90]) by smtp.vangyzen.net (Postfix) with ESMTPSA id E587856467; Thu, 13 Nov 2014 11:39:41 -0600 (CST) Message-ID: <5464ECDC.1080002@vangyzen.net> Date: Thu, 13 Nov 2014 12:39:40 -0500 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: FreeBSD current , kib@freebsd.org Subject: [patch] Wrong assertion in kern_umtx.c Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 13 Nov 2014 17:39:50 -0000 There is a [practically] tautological assertion in kern_umtx.c. I have not even compile-tested the following patch. I'll test it when I have time. I'd be grateful if someone beats me to it. Eric diff --git a/sys/kern/kern_umtx.c b/sys/kern/kern_umtx.c index 33fdf71..c6b42c0 100644 --- a/sys/kern/kern_umtx.c +++ b/sys/kern/kern_umtx.c @@ -169,7 +169,7 @@ struct umtxq_chain { }; #define UMTXQ_LOCKED_ASSERT(uc) mtx_assert(&(uc)->uc_lock, MA_OWNED) -#define UMTXQ_BUSY_ASSERT(uc) KASSERT(&(uc)->uc_busy, ("umtx chain is not busy")) +#define UMTXQ_BUSY_ASSERT(uc) KASSERT((uc)->uc_busy, ("umtx chain is not busy")) /* * Don't propagate time-sharing priority, there is a security reason, From owner-freebsd-current@FreeBSD.ORG Thu Nov 13 17:52:13 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB700BE; Thu, 13 Nov 2014 17:52:13 +0000 (UTC) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 94BC7D68; Thu, 13 Nov 2014 17:52:13 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id lj1so15476760pab.8 for ; Thu, 13 Nov 2014 09:52:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=jbEHLw7LqlrcfjTOxU/n7NhDcFUx/5Wvfk2lx4tVxb4=; b=jK/3ozk5VuBomlkgotmvADuJ+bpDFh2sMpYf4fkpIgL0T1vTIF5+q5O9HaUmJ0OKob uR1bbB2HmkQUL+maGYmxTNFIZrCeBWN2gwWYpfosl6/1jwkv2WPyQQoovfLjeMQrMngQ 999o3PwR3LZ+z8T19b+3WUQW89UdOGdm+PUqoPMt+6vHsSREgGEB1LdBR+m8hl9YcY2T JYQ3bsXszG2oA4pQDEzlTh4KyzhtRDBVXp7AomotBdMEwpTladPP3+Ononx4jiSFHa+6 X7hc+l7nxHTzgnzJjZiO6/tIC9JdQUMkZ5ctSbwZzMJChuibXtAZXIblw/m7g3zQXgEr /jUg== X-Received: by 10.66.237.145 with SMTP id vc17mr4465076pac.34.1415901132810; Thu, 13 Nov 2014 09:52:12 -0800 (PST) Received: from ?IPv6:2601:8:ab80:7d6:1547:f46b:5da4:f0f2? ([2601:8:ab80:7d6:1547:f46b:5da4:f0f2]) by mx.google.com with ESMTPSA id sg4sm20897842pbc.24.2014.11.13.09.52.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Nov 2014 09:52:11 -0800 (PST) References: <20141112224212.GA14013@troutmask.apl.washington.edu> <20141113172533.GA18690@troutmask.apl.washington.edu> Mime-Version: 1.0 (1.0) In-Reply-To: <20141113172533.GA18690@troutmask.apl.washington.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12B411) From: Garrett Cooper Subject: Re: USB locks up system -- WAS Re: shutdown or acpi problem Date: Thu, 13 Nov 2014 09:52:05 -0800 To: Steve Kargl Cc: Alexander Motin , "freebsd-current@freebsd.org" , Hans Petter Selasky X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 13 Nov 2014 17:52:14 -0000 CCing hps and mav.. > On Nov 13, 2014, at 09:25, Steve Kargl w= rote: >=20 >> On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: >> I have a kernel/world from r274273 sources, which is exhibiting a new >> issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' >> work. I get to the end of shutdown and see for example >>=20 >> All buffers synced >> Uptime: 4h23m15s >>=20 >> and then the laptop just sits there. It does not power off with >> the -p option nor does it reboot with the -r. Has anyone else >> seen this behavior? >=20 > The problem appears to be related to a recent change in the > USB stack. If I have the following drive plugged into a > usb port, the above behavior is observed on shutdown. >=20 > ugen6.2: at usbus6 > umass0: on usbus6 > da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 > da0: Fixed Direct Access SCSI-6 device=20 > da0: Serial Number 57584B314537324445595A31 > da0: 40.000MB/s transfers > da0: 1907697MB (3906963456 512 byte sectors: 255H 63S/T 243197C) > da0: quirks=3D0x2 > ses1 at umass-sim0 bus 0 scbus4 target 0 lun 1 > ses1: Fixed Enclosure Services SCSI-6 device=20 > ses1: Serial Number 57584B314537324445595A31 > ses1: 40.000MB/s transfers > ses1: SCSI-3 ENC Device >=20 > If this drive was never plugged into a usb port, 'shutdown -r now' > and 'shutdown -p now' work as expected. >=20 > If drive is plugged into a usb port, and I then unplug the drive the > laptop is turned into a brick. In a vt(4) console, there is no keyboard=20= > and no output is displayed to the console. >=20 > Logging into the laptop with ssh works. With the laptop > in a brick state, issuing 'usbconfig' yields a wedged process > with no output to the terminal and 'usbconfig' is unkillable.=20 > ^T yields >=20 > load: 0.30 cmd: usbconfig 1068 [USB config SX lock] 441.15r 0.00u 0.00s 1= 884k. >=20 > Unfortunately, a 'gdb -p 1068' yields a core dump for gdb. :( >=20 > Logging into the laptop again with ssh works. Issuing the command > 'camcontrol rescan all' yields >=20 > Re-scan of bus 4 returned error 0xa > Re-scan of bus 0 was successful > Re-scan of bus 1 was successful > Re-scan of bus 2 was successful > Re-scan of bus 3 was successful >=20 > dmesg follows my sig. >=20 > --=20 > Steve >=20 > Copyright (c) 1992-2014 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 11.0-CURRENT #0 r274456: Thu Nov 13 07:45:01 PST 2014 > kargl@laptop-kargl.apl.washington.edu:/usr/obj/usr/src/sys/MOBILE i386 > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 > VT: running with driver "vga". > CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz 686-clas= s CPU) > Origin=3D"GenuineIntel" Id=3D0x6fd Family=3D0x6 Model=3D0xf Stepping=3D= 13 > Features=3D0xbfebfbff > Features2=3D0xe3bd > AMD Features=3D0x20000000 > AMD Features2=3D0x1 > VT-x: (disabled in BIOS) HLT,PAUSE > TSC: P-state invariant, performance statistics > real memory =3D 3221225472 (3072 MB) > avail memory =3D 3136098304 (2990 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > ioapic0: Changing APIC ID to 2 > ioapic0 irqs 0-23 on motherboard > random: entropy device infrastructure driver > random: selecting highest priority adaptor > kbd1 at kbdmux0 > random: SOFT: yarrow init() > random: selecting highest priority adaptor > module_register_init: MOD_LOAD (vesa, 0xc0b3a4e0, 0) error 19 > acpi0: on motherboard > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 950 > Event timer "HPET" frequency 14318180 Hz quality 450 > Event timer "HPET1" frequency 14318180 Hz quality 440 > Event timer "HPET2" frequency 14318180 Hz quality 440 > acpi0: reservation of 0, 9f000 (3) failed > acpi0: reservation of 100000, bf5c0400 (3) failed > cpu0: on acpi0 > cpu1: on acpi0 > atrtc0: port 0x70-0x71,0x72-0x77 irq 8 on acpi0 > Event timer "RTC" frequency 32768 Hz quality 0 > attimer0: port 0x40-0x43,0x50-0x53 irq 2 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > vgapci0: port 0xeff8-0xefff mem 0xfea00000-0xfeaf= ffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 > vgapci0: Boot video device > vgapci1: mem 0xfeb00000-0xfebfffff at device 2.1 o= n pci0 > uhci0: port 0x6f20-0x6f3f irq 2= 0 at device 26.0 on pci0 > usbus0 on uhci0 > uhci1: port 0x6f00-0x6f1f irq 2= 1 at device 26.1 on pci0 > usbus1 on uhci1 > ehci0: mem 0xfed1c400-0xfe= d1c7ff irq 22 at device 26.7 on pci0 > usbus2: EHCI version 1.0 > usbus2 on ehci0 > hdac0: mem 0xfe9fc000-0xfe9fffff irq 21 at d= evice 27.0 on pci0 > pcib1: at device 28.0 on pci0 > pci11: on pcib1 > pcib2: at device 28.1 on pci0 > pci12: on pcib2 > wpi0: mem 0xfe8ff000-0xfe8fffff irq 17 at d= evice 0.0 on pci12 > pcib3: at device 28.5 on pci0 > pci9: on pcib3 > bge0: = mem 0xfe7f0000-0xfe7fffff irq 17 at device 0.0 on pci9 > bge0: CHIP ID 0x0000a002; ASIC REV 0x0a; CHIP REV 0xa0; PCI-E > miibus0: on bge0 > brgphy0: PHY 1 on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000b= aseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > bge0: Ethernet address: 00:1d:09:ba:cc:0d > uhci2: port 0x6f80-0x6f9f irq 2= 0 at device 29.0 on pci0 > usbus3 on uhci2 > uhci3: port 0x6f60-0x6f7f irq 2= 1 at device 29.1 on pci0 > usbus4 on uhci3 > uhci4: port 0x6f40-0x6f5f irq 2= 2 at device 29.2 on pci0 > usbus5 on uhci4 > ehci1: mem 0xfed1c000-0xfe= d1c3ff irq 20 at device 29.7 on pci0 > usbus6: EHCI version 1.0 > usbus6 on ehci1 > pcib4: at device 30.0 on pci0 > pci3: on pcib4 > cbb0: at device 1.0 on pci3 > cardbus0: on cbb0 > pccard0: <16-bit PCCard bus> on cbb0 > pci3: at device 1.4 (no driver attached) > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x1= 77,0x376,0x6fa0-0x6faf irq 16 at device 31.1 on pci0 > ata0: at channel 0 on atapci0 > ahci0: port 0x6eb0-0x6eb7,0x6eb8-0x6ebb= ,0x6ec0-0x6ec7,0x6ec8-0x6ecb,0x6ee0-0x6eff mem 0xfe9fb800-0xfe9fbfff irq 17 a= t device 31.2 on pci0 > ahci0: AHCI v1.10 with 3 3Gbps ports, Port Multiplier not supported > ahcich0: at channel 0 on ahci0 > ahcich2: at channel 2 on ahci0 > ahciem0: on ahci0 > ichsmb0: port 0x10c0-0x10df mem 0xf= e9fb700-0xfe9fb7ff irq 17 at device 31.3 on pci0 > smbus0: on ichsmb0 > smb0: on smbus0 > acpi_lid0: on acpi0 > acpi_button0: on acpi0 > acpi_button1: on acpi0 > acpi_acad0: on acpi0 > battery0: on acpi0 > battery1: on acpi0 > acpi_tz0: on acpi0 > atkbdc0: port 0x60,0x64,0x62,0x66 irq 1 on a= cpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: model GlidePoint, device ID 0 > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > ichwd0 on isa0 > ichwd0: resuming after hardware watchdog timeout > pmtimer0 on isa0 > orm0: at iomem 0xc0000-0xcefff,0xcf000-0xcffff pnpid ORM= 0000 on isa0 > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > ppc0: parallel port not found. > coretemp0: on cpu0 > est0: on cpu0 > coretemp1: on cpu1 > est1: on cpu1 > fuse-freebsd: version 0.4.4, FUSE ABI 7.8 > Timecounters tick every 1.000 msec > hdacc0: at cad 0 on hdac0 > hdaa0: at nid 1 on hdacc0 > pcm0: at nid 13,10 and 12,11 on h= daa0 > 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: 12Mbps Full Speed USB v1.0 > usbus6: 480Mbps High Speed USB v2.0 > ugen0.1: at usbus0 > uhub0: on usbus0 > ugen2.1: at usbus2 > ugen1.1: at usbus1 > uhub1: on usbus1 > ugen5.1: at usbus5 > ugen4.1: at usbus4 > uhub2: on usbus4 > ugen3.1: at usbus3 > ugen6.1: at usbus6 > uhub3: on usbus6 > uhub4: on usbus2 > uhub5: on usbus5 > uhub6: on usbus3 > ses0 at ahciem0 bus 0 scbus3 target 0 lun 0 > ses0: SEMB S-E-S 2.00 device > ses0: SEMB SES Device > ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 > ada0: ATA-7 SATA 1.x device > ada0: Serial Number WD-WXCZ07905963 > ada0: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 76319MB (156301488 512 byte sectors: 16H 63S/T 16383C) > ada0: Previously was known as ad0 > random: unblocking device. > SMP: AP CPU #1 Launched! > cd0 at ata0 bus 0 scbus0 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device=20 > cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) > cd0: Attempt to query device size failed: NOT READY, Medium not present > hwpmc: SOFT/16/64/0x67 TSC/1/64/0x20 IAP/2/40/0x= 3ff IAF/3/40/0x67 > uhub2: 2 ports with 2 removable, self powered > uhub0: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub6: 2 ports with 2 removable, self powered > uhub5: 2 ports with 2 removable, self powered > Root mount waiting for: usbus6 usbus2 > Root mount waiting for: usbus6 usbus2 > uhub4: 4 ports with 4 removable, self powered > uhub3: 6 ports with 6 removable, self powered > Root mount waiting for: usbus6 > Trying to mount root from ufs:/dev/ada0s3a [rw]... > WARNING: / was not properly dismounted > WARNING: /: mount pending error: blocks 8 files 0 > ugen4.2: at usbus4 > ums0: on usbus4= > ums0: 8 buttons and [XYZT] coordinates ID=3D0 > uhid0: on usbus= 4 > bge0: link state changed to UP > agp0: on vgapci0 > agp0: aperture size is 256M, detected 7676k stolen memory > info: [drm] Initialized drm 1.1.0 20060810 > drmn0: on vgapci0 > info: [drm] MSI enabled 1 message(s) > info: [drm] AGP at 0xe0000000 256MB > iicbus0: on iicbb0 addr 0xec > iic0: on iicbus0 > iic1: on iicbus1 > iicbus2: on iicbb1 addr 0xc8 > iic2: on iicbus2 > iic3: on iicbus3 > iicbus4: on iicbb2 addr 0xc8 > iic4: on iicbus4 > iic5: on iicbus5 > iicbus6: on iicbb3 addr 0xc8 > iic6: on iicbus6 > iic7: on iicbus7 > iicbus8: on iicbb4 addr 0xc8 > iic8: on iicbus8 > iic9: on iicbus9 > iicbus10: on iicbb5 addr 0xc8 > iic10: on iicbus10 > iic11: on iicbus11 > iicbus12: on iicbb6 addr 0xc8 > iic12: on iicbus12 > iic13: on iicbus13 > iicbus14: on iicbb7 addr 0xc8 > iic14: on iicbus14 > iic15: on iicbus15 > info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). > info: [drm] Driver supports precise vblank timestamp query. > composite sync not supported > drmn0: taking over the fictitious range 0xe0000000-0xf0000000 > info: [drm] initialized overlay support > info: [drm] Connector LVDS-1: get mode from tunables: > info: [drm] - kern.vt.fb.modes.LVDS-1 > info: [drm] - kern.vt.fb.default_mode > info: [drm] Connector VGA-1: get mode from tunables: > info: [drm] - kern.vt.fb.modes.VGA-1 > info: [drm] - kern.vt.fb.default_mode > info: [drm] Connector DVI-D-1: get mode from tunables: > info: [drm] - kern.vt.fb.modes.DVI-D-1 > info: [drm] - kern.vt.fb.default_mode > info: [drm] Connector SVIDEO-1: get mode from tunables: > info: [drm] - kern.vt.fb.modes.SVIDEO-1 > info: [drm] - kern.vt.fb.default_mode > composite sync not supported > fbd0 on drmn0 > VT: Replacing driver "vga" with new "fb". > info: [drm] Initialized i915 1.6.0 20080730 > composite sync not supported > composite sync not supported > ugen6.2: at usbus6 > umass0: on usbus6 > da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 > da0: Fixed Direct Access SCSI-6 device=20 > da0: Serial Number 57584B314537324445595A31 > da0: 40.000MB/s transfers > da0: 1907697MB (3906963456 512 byte sectors: 255H 63S/T 243197C) > da0: quirks=3D0x2 > ses1 at umass-sim0 bus 0 scbus4 target 0 lun 1 > ses1: Fixed Enclosure Services SCSI-6 device=20 > ses1: Serial Number 57584B314537324445595A31 > ses1: 40.000MB/s transfers > ses1: SCSI-3 ENC Device > _______________________________________________ > 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 Nov 13 17:53:27 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35F181F3 for ; Thu, 13 Nov 2014 17:53:27 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 252C3D85 for ; Thu, 13 Nov 2014 17:53:27 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 10094152 for ; Thu, 13 Nov 2014 17:53:26 +0000 (UTC) Date: Thu, 13 Nov 2014 17:53:26 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1176907898.46.1415901206963.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <567282484.45.1415887733676.JavaMail.jenkins@jenkins-9.freebsd.org> References: <567282484.45.1415887733676.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #240 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 13 Nov 2014 17:53:27 -0000 See From owner-freebsd-current@FreeBSD.ORG Thu Nov 13 18:03:33 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2520B93F for ; Thu, 13 Nov 2014 18:03:33 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 02DD5EA0 for ; Thu, 13 Nov 2014 18:03:32 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id sADI3WiX019033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 13 Nov 2014 10:03:32 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id sADI3W43019032 for freebsd-current@freebsd.org; Thu, 13 Nov 2014 10:03:32 -0800 (PST) (envelope-from sgk) Date: Thu, 13 Nov 2014 10:03:32 -0800 From: Steve Kargl To: freebsd-current@freebsd.org Subject: Re: USB locks up system -- WAS Re: shutdown or acpi problem Message-ID: <20141113180332.GA18990@troutmask.apl.washington.edu> References: <20141112224212.GA14013@troutmask.apl.washington.edu> <20141113172533.GA18690@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141113172533.GA18690@troutmask.apl.washington.edu> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 13 Nov 2014 18:03:33 -0000 On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote: > On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: > > I have a kernel/world from r274273 sources, which is exhibiting a new > > issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' > > work. I get to the end of shutdown and see for example > > > > All buffers synced > > Uptime: 4h23m15s > > > > and then the laptop just sits there. It does not power off with > > the -p option nor does it reboot with the -r. Has anyone else > > seen this behavior? > > > > The problem appears to be related to a recent change in the > USB stack. If I have the following drive plugged into a > usb port, the above behavior is observed on shutdown. > > ugen6.2: at usbus6 > umass0: on usbus6 > da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 > da0: Fixed Direct Access SCSI-6 device > da0: Serial Number 57584B314537324445595A31 > da0: 40.000MB/s transfers > da0: 1907697MB (3906963456 512 byte sectors: 255H 63S/T 243197C) > da0: quirks=0x2 > ses1 at umass-sim0 bus 0 scbus4 target 0 lun 1 > ses1: Fixed Enclosure Services SCSI-6 device > ses1: Serial Number 57584B314537324445595A31 > ses1: 40.000MB/s transfers > ses1: SCSI-3 ENC Device > The problem is not restricted to hte WD My Passport drive. The memstick ugen6.2: at usbus6 umass0: on usbus6 da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: < 0.00> Removable Direct Access SCSI-2 device da0: Serial Number 08102201c42413 da0: 40.000MB/s transfers da0: 963MB (1974271 512 byte sectors: 64H 32S/T 963C) da0: quirks=0x2 will also cause the system to wedge when removed. I failed to report that /dev/da0, /dev/da0s1, /dev/da0s1a, etc were not destroyed when the WD My Passport was removed. -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Nov 13 18:04:01 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 49BA7A4B; Thu, 13 Nov 2014 18:04:01 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C2893EB0; Thu, 13 Nov 2014 18:04:00 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sADI4Q4V031484; Thu, 13 Nov 2014 10:04:26 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: "FreeBSD CURRENT" , "FreeBSD ports" From: "Chris H" Subject: gcc48-4.8.4.s20141030.txz: Forbidden?! Date: Thu, 13 Nov 2014 10:04:26 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <72582d1a798f9d453cad66e9ce6e9d3e@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 13 Nov 2014 18:04:01 -0000 OK. I'm on 11 (r274393 amd64, custom kernel. fresh world) svn info /usr/ports -- r372460 src, and make.conf were both empty. While building a port, lang/gcc48, and lang/gcc-ecj45 were sucked in as dependency. During the building of one of them (ecj45?) I noticed a (core dumped). I was unable to capture the context of the event. But decided to make deinstall both. Followed by a pkg install of both. The ecj45 installed w/o issue. But gcc48 failed with gcc48-4.8.4.s20141030.txz: Forbidden. Why? Thank you for all your time, and consideration. --Chris From owner-freebsd-current@FreeBSD.ORG Thu Nov 13 18:15:16 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51DACEB4 for ; Thu, 13 Nov 2014 18:15:16 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1516B9 for ; Thu, 13 Nov 2014 18:15:16 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id sADIFFZ9019138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 13 Nov 2014 10:15:15 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id sADIFFJu019137 for freebsd-current@freebsd.org; Thu, 13 Nov 2014 10:15:15 -0800 (PST) (envelope-from sgk) Date: Thu, 13 Nov 2014 10:15:15 -0800 From: Steve Kargl To: freebsd-current@freebsd.org Subject: Re: USB locks up system -- WAS Re: shutdown or acpi problem Message-ID: <20141113181515.GA19117@troutmask.apl.washington.edu> References: <20141112224212.GA14013@troutmask.apl.washington.edu> <20141113172533.GA18690@troutmask.apl.washington.edu> <20141113180332.GA18990@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141113180332.GA18990@troutmask.apl.washington.edu> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 13 Nov 2014 18:15:16 -0000 On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote: > On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote: > > On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: > > > I have a kernel/world from r274273 sources, which is exhibiting a new > > > issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' > > > work. I get to the end of shutdown and see for example > > > > > > All buffers synced > > > Uptime: 4h23m15s > > > > > > and then the laptop just sits there. It does not power off with > > > the -p option nor does it reboot with the -r. Has anyone else > > > seen this behavior? > > > > > > > The problem appears to be related to a recent change in the > > USB stack. If I have the following drive plugged into a > > usb port, the above behavior is observed on shutdown. > > Adding hw.usb.no_shutdown_wait: 1 to /boot/loader.conf appears to work around the 'shutdown -p now' and 'shutdown -r now' issue. Unfortunately, the bricking of the laptop is not affected by this sysctl. Once a device is plugged into a usb, it must remain plugged in. -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Nov 13 18:16:07 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B0A04FC6; Thu, 13 Nov 2014 18:16:07 +0000 (UTC) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7A2A56B; Thu, 13 Nov 2014 18:16:07 +0000 (UTC) Received: by mail-pd0-f182.google.com with SMTP id fp1so15051196pdb.13 for ; Thu, 13 Nov 2014 10:16:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ON283uNws9BTwlzQ6QhoXjxYR31ocQXuD2tAJugIFp4=; b=FzIP1eZOhjq2RnPR34NsrYaCYJPd0deCWA/mflMd+vqvpKlvCXfwltlxN1H0lK1B19 VdgfqgIwrHx1pjZqtGNI67hpWd8L6NAUbQq5ompxNx+glVW9J7nYpop3gB97PGTtYVFy u4vDJGncuKQXI+JXlzxJpETKTDN6720eLJWCDPOdmj406OtKYEw+klSr+bJQlfk/J6yK 7RzIvq8VRo8gwF2vVjeAndKYF4Ky3FYM2T82GCpN08LbDzOsyeOYxAglvyPR3etZVcqL A+BT0AT9TXw9ZHcJ/2yXN2YTyGbHpbSgmibxDD59Kc0jfEga3k/IByhCckDaIaV2W6Tk X0Eg== X-Received: by 10.66.141.167 with SMTP id rp7mr4469031pab.118.1415902567094; Thu, 13 Nov 2014 10:16:07 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([12.229.62.2]) by mx.google.com with ESMTPSA id r15sm7052887pdn.23.2014.11.13.10.16.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Nov 2014 10:16:06 -0800 (PST) Sender: Alexander Motin Message-ID: <5464F565.1070105@FreeBSD.org> Date: Thu, 13 Nov 2014 20:16:05 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: NGie Cooper , "Rang, Anton" Subject: Re: Minor bug in SCSI definition References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Scott Long , "freebsd-current@freebsd.org" , "Kenneth D. Merry" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 13 Nov 2014 18:16:07 -0000 On 13.11.2014 05:44, NGie Cooper wrote: > On Wed, Nov 12, 2014 at 7:30 PM, Rang, Anton wrote: >> Coverity found an issue in this area which I tracked down to the incorrect definition patched below. >> >> The SID_QUAL macro is (((inq_data)->device & 0xE0) >> 5) which extracts the peripheral qualifier. >> Per SCSI-2 (draft 10L) table 46, the vendor-specific values are "1XXb". >> >> This probably affects almost nobody, but it will clear up a couple of Coverity warnings. >> >> Anton >> >> Index: sys/cam/scsi/scsi_all.h >> =================================================================== >> --- sys/cam/scsi/scsi_all.h (revision 274352) >> +++ sys/cam/scsi/scsi_all.h (working copy) >> @@ -1817,7 +1817,7 @@ >> * reserved for this peripheral >> * qualifier. >> */ >> -#define SID_QUAL_IS_VENDOR_UNIQUE(inq_data) ((SID_QUAL(inq_data) & 0x08) != 0) >> +#define SID_QUAL_IS_VENDOR_UNIQUE(inq_data) ((SID_QUAL(inq_data) & 0x04) != 0) >> u_int8_t dev_qual2; >> #define SID_QUAL2 0x7F >> #define SID_LU_CONG 0x40 > > CCing ken@/mav@/scottl@ -- thanks! Looks good to me. Committed it to head at r274477. Thank you! -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Nov 13 18:56:33 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF1D4D78 for ; Thu, 13 Nov 2014 18:56:33 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 53405697 for ; Thu, 13 Nov 2014 18:56:33 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sADIuQvM024096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2014 20:56:26 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sADIuQvM024096 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sADIuQ8V024095; Thu, 13 Nov 2014 20:56:26 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 13 Nov 2014 20:56:26 +0200 From: Konstantin Belousov To: Eric van Gyzen Subject: Re: [patch] Wrong assertion in kern_umtx.c Message-ID: <20141113185626.GB17068@kib.kiev.ua> References: <5464ECDC.1080002@vangyzen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5464ECDC.1080002@vangyzen.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 13 Nov 2014 18:56:34 -0000 On Thu, Nov 13, 2014 at 12:39:40PM -0500, Eric van Gyzen wrote: > There is a [practically] tautological assertion in kern_umtx.c. I have > not even compile-tested the following patch. I'll test it when I have > time. I'd be grateful if someone beats me to it. > > Eric > > > diff --git a/sys/kern/kern_umtx.c b/sys/kern/kern_umtx.c > index 33fdf71..c6b42c0 100644 > --- a/sys/kern/kern_umtx.c > +++ b/sys/kern/kern_umtx.c > @@ -169,7 +169,7 @@ struct umtxq_chain { > }; > > #define UMTXQ_LOCKED_ASSERT(uc) > mtx_assert(&(uc)->uc_lock, MA_OWNED) > -#define UMTXQ_BUSY_ASSERT(uc) KASSERT(&(uc)->uc_busy, ("umtx > chain is not busy")) > +#define UMTXQ_BUSY_ASSERT(uc) KASSERT((uc)->uc_busy, ("umtx > chain is not busy")) > > /* > * Don't propagate time-sharing priority, there is a security reason, > Yes, I tested it, thanks for the submission. I committed r274478, and I decided to remove macro used in single place, at all. There is one more place, which I added several weeks ago, but I really do not see much point in using the macro, it obfuscates the code. From owner-freebsd-current@FreeBSD.ORG Thu Nov 13 19:15:29 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03BB82D6 for ; Thu, 13 Nov 2014 19:15:29 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C12D98D6 for ; Thu, 13 Nov 2014 19:15:28 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id sADJFSeV064616 for ; Thu, 13 Nov 2014 19:15:28 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id sADJFSIn064613 for current@freebsd.org; Thu, 13 Nov 2014 19:15:28 GMT (envelope-from bdrewery) Received: (qmail 53550 invoked from network); 13 Nov 2014 13:15:27 -0600 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 13 Nov 2014 13:15:27 -0600 Message-ID: <5465034E.1050104@FreeBSD.org> Date: Thu, 13 Nov 2014 13:15:26 -0600 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Chris H , FreeBSD CURRENT , FreeBSD ports Subject: Re: gcc48-4.8.4.s20141030.txz: Forbidden?! References: <72582d1a798f9d453cad66e9ce6e9d3e@ultimatedns.net> In-Reply-To: <72582d1a798f9d453cad66e9ce6e9d3e@ultimatedns.net> OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mbedU01JjVeGTHSInxtHMatn4pjJGm3u1" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 13 Nov 2014 19:15:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mbedU01JjVeGTHSInxtHMatn4pjJGm3u1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11/13/2014 12:04 PM, Chris H wrote: > OK. I'm on 11 (r274393 amd64, custom kernel. fresh world) > svn info /usr/ports -- r372460 > src, and make.conf were both empty. > While building a port, lang/gcc48, and lang/gcc-ecj45 were > sucked in as dependency. During the building of one of them > (ecj45?) I noticed a (core dumped). I was unable to capture > the context of the event. But decided to make deinstall both. > Followed by a pkg install of both. The ecj45 installed w/o > issue. But gcc48 failed with gcc48-4.8.4.s20141030.txz: Forbidden. >=20 > Why? >=20 > Thank you for all your time, and consideration. Was this error from 'pkg install' during the fetch phase? I'd suggest just trying again, the mirror may have been updating at the time. 'pkg update -f' and try again. --=20 Regards, Bryan Drewery --mbedU01JjVeGTHSInxtHMatn4pjJGm3u1 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) iQEcBAEBAgAGBQJUZQNOAAoJEDXXcbtuRpfPxq4IAI2aJk/wNJ+JZtMCo4DEH00h 16FWAZdMsXSh3eYYSSk+aVRCthX738ivLXCu9U+j/qvgLUDG1wd2hm4daxOSa/Kd 6awyFwb03fdbzuIPlRB3S9Hiw6m41glXp+Wc3Ae4/oTDrDBIU9Uu7dtbP5viyMvR rkcENC26+b513JTqr1IMivWeBmMU9UHIZN62MB83cgdcNXieL0OmOQOJXU2XYYtl fcpIsyf40d55XEa8+qL8qnKKQr3wyOUbnZykEhmfTCEhSoUFPKK3Q0zPOQRSS97B xyx+4XNhHvdTzV/U81lRxcQ+1Ji4ISwkPPDz9fkaZcxsWTHWt618BhYlAjkXjC8= =z3HV -----END PGP SIGNATURE----- --mbedU01JjVeGTHSInxtHMatn4pjJGm3u1-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 13 19:32:04 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6FE45A18; Thu, 13 Nov 2014 19:32:04 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 44E48AFA; Thu, 13 Nov 2014 19:32:04 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sADJWVrU049578; Thu, 13 Nov 2014 11:32:31 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: FreeBSD CURRENT , FreeBSD ports , Bryan Drewery In-Reply-To: <5465034E.1050104@FreeBSD.org> References: <72582d1a798f9d453cad66e9ce6e9d3e@ultimatedns.net>, <5465034E.1050104@FreeBSD.org> From: "Chris H" Subject: Re: gcc48-4.8.4.s20141030.txz: Forbidden?! Date: Thu, 13 Nov 2014 11:32:31 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 13 Nov 2014 19:32:04 -0000 On Thu, 13 Nov 2014 13:15:26 -0600 Bryan Drewery wrote > On 11/13/2014 12:04 PM, Chris H wrote: > > OK. I'm on 11 (r274393 amd64, custom kernel. fresh world) > > svn info /usr/ports -- r372460 > > src, and make.conf were both empty. > > While building a port, lang/gcc48, and lang/gcc-ecj45 were > > sucked in as dependency. During the building of one of them > > (ecj45?) I noticed a (core dumped). I was unable to capture > > the context of the event. But decided to make deinstall both. > > Followed by a pkg install of both. The ecj45 installed w/o > > issue. But gcc48 failed with gcc48-4.8.4.s20141030.txz: Forbidden. > > > > Why? > > > > Thank you for all your time, and consideration. > > Was this error from 'pkg install' during the fetch phase? I'd suggest > just trying again, the mirror may have been updating at the time. 'pkg > update -f' and try again. Yes. This was via pkg install lang/gcc48 Probably during a fetch. Funny though. I got impatient, and decided to try a cd /usr/ports/lang/gcc48; make which resulted in the first 6 servers fetch attempted, replying Forbidden. I know clang is the preferred method. But isn't this going a bit too far. ;) The 7th server succeeded, and it seems to be building fine. Thanks for taking the time to reply, Bryan. --Chris > > > -- > Regards, > Bryan Drewery From owner-freebsd-current@FreeBSD.ORG Thu Nov 13 20:33:52 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59178902 for ; Thu, 13 Nov 2014 20:33:52 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 17DFB127 for ; Thu, 13 Nov 2014 20:33:51 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 6027D1FE022; Thu, 13 Nov 2014 21:33:49 +0100 (CET) Message-ID: <546515BF.6030508@selasky.org> Date: Thu, 13 Nov 2014 21:34:07 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Steve Kargl , freebsd-current@freebsd.org Subject: Re: USB locks up system -- WAS Re: shutdown or acpi problem References: <20141112224212.GA14013@troutmask.apl.washington.edu> <20141113172533.GA18690@troutmask.apl.washington.edu> <20141113180332.GA18990@troutmask.apl.washington.edu> <20141113181515.GA19117@troutmask.apl.washington.edu> In-Reply-To: <20141113181515.GA19117@troutmask.apl.washington.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 13 Nov 2014 20:33:52 -0000 On 11/13/14 19:15, Steve Kargl wrote: > On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote: >> On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote: >>> On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: >>>> I have a kernel/world from r274273 sources, which is exhibiting a new >>>> issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' >>>> work. I get to the end of shutdown and see for example >>>> >>>> All buffers synced >>>> Uptime: 4h23m15s >>>> >>>> and then the laptop just sits there. It does not power off with >>>> the -p option nor does it reboot with the -r. Has anyone else >>>> seen this behavior? >>>> >>> >>> The problem appears to be related to a recent change in the >>> USB stack. If I have the following drive plugged into a >>> usb port, the above behavior is observed on shutdown. >>> > > Adding > > hw.usb.no_shutdown_wait: 1 > > to /boot/loader.conf appears to work around the 'shutdown -p now' > and 'shutdown -r now' issue. Unfortunately, the bricking of the > laptop is not affected by this sysctl. Once a device is plugged > into a usb, it must remain plugged in. > Hi, Is using this sysctl/tunable a suitable solution for you? --HPS From owner-freebsd-current@FreeBSD.ORG Thu Nov 13 20:48:39 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A56C414F for ; Thu, 13 Nov 2014 20:48:39 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 93FD227C for ; Thu, 13 Nov 2014 20:48:39 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 2FB081A6 for ; Thu, 13 Nov 2014 20:48:39 +0000 (UTC) Date: Thu, 13 Nov 2014 20:48:39 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <458364766.47.1415911719941.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1176907898.46.1415901206963.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1176907898.46.1415901206963.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #241 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 13 Nov 2014 20:48:39 -0000 See From owner-freebsd-current@FreeBSD.ORG Thu Nov 13 21:22:08 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9F4BDA3 for ; Thu, 13 Nov 2014 21:22:08 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A6052866 for ; Thu, 13 Nov 2014 21:22:08 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id sADLM73W020870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 13 Nov 2014 13:22:07 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id sADLM6cX020869; Thu, 13 Nov 2014 13:22:06 -0800 (PST) (envelope-from sgk) Date: Thu, 13 Nov 2014 13:22:06 -0800 From: Steve Kargl To: Hans Petter Selasky Subject: Re: USB locks up system -- WAS Re: shutdown or acpi problem Message-ID: <20141113212206.GA20802@troutmask.apl.washington.edu> References: <20141112224212.GA14013@troutmask.apl.washington.edu> <20141113172533.GA18690@troutmask.apl.washington.edu> <20141113180332.GA18990@troutmask.apl.washington.edu> <20141113181515.GA19117@troutmask.apl.washington.edu> <546515BF.6030508@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <546515BF.6030508@selasky.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 13 Nov 2014 21:22:08 -0000 On Thu, Nov 13, 2014 at 09:34:07PM +0100, Hans Petter Selasky wrote: > On 11/13/14 19:15, Steve Kargl wrote: > > On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote: > >> On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote: > >>> On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: > >>>> I have a kernel/world from r274273 sources, which is exhibiting a new > >>>> issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' > >>>> work. I get to the end of shutdown and see for example > >>>> > >>>> All buffers synced > >>>> Uptime: 4h23m15s > >>>> > >>>> and then the laptop just sits there. It does not power off with > >>>> the -p option nor does it reboot with the -r. Has anyone else > >>>> seen this behavior? > >>>> > >>> > >>> The problem appears to be related to a recent change in the > >>> USB stack. If I have the following drive plugged into a > >>> usb port, the above behavior is observed on shutdown. > >>> > > > > Adding > > > > hw.usb.no_shutdown_wait: 1 > > > > to /boot/loader.conf appears to work around the 'shutdown -p now' > > and 'shutdown -r now' issue. Unfortunately, the bricking of the > > laptop is not affected by this sysctl. Once a device is plugged > > into a usb, it must remain plugged in. > > > > Hi, > > Is using this sysctl/tunable a suitable solution for you? > The sysctl is a suitable solution for the shutdown issues. It is not suitable solution for the general use of using a memory stick to for example quickly transfer files. Once the memory stick is plugged into the usb port, it must remain there unless one wants to reboot the system. I rebuilt the kernel with USB_DEBUG and CAMDEBUG enabled. I need to wade through a rather large /var/log/messages to see if anything appears unusual. -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Nov 13 22:40:49 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C1D7EDD2; Thu, 13 Nov 2014 22:40:49 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id B06E9AE; Thu, 13 Nov 2014 22:40:49 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id DC4B01D9; Thu, 13 Nov 2014 22:40:49 +0000 (UTC) Date: Thu, 13 Nov 2014 22:40:48 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, dim@FreeBSD.org, jhb@FreeBSD.org, mjg@FreeBSD.org, kib@FreeBSD.org Message-ID: <2032357817.48.1415918449825.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #1835 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 13 Nov 2014 22:40:49 -0000 See Changes: [dim] =EF=BB=BFThe fix imported into llvm in r274442 contains some C++11 co= nstructs, which gcc in base cannot handle. Replace these with C++98 equivalents. While here, add the patch for the adapted fix. Reported by:=09bz, kib Pointy hat to:=09dim MFC after:=091 week X-MFC-With:=09r274442 [mjg] filedesc: fixup fdinit to lock fdp and preapare files conditinally Not all consumers providing fdp to copy from want files. Perhaps these functions should be reorganized to better express the outcome= . This fixes up panics after r273895 . Reported by:=09markj [jhb] Drop mention of ISA cards. Note that I have no idea what to cull fro= m the supported hardware list. Judging by the PCI driver attachment, dpt_pci.c only supports a single adapter rather than the various PCI adapters listed. The list of EISA adapters listed somewhat overlaps with the device IDs in dpt_eisa.c. It's not clear which devices are ISA-only devices. [jhb] Remove dpt_isa.c and commented out references to it. It was never co= nnected to the build in either sys/conf/files* or sys/modules/dpt/Makefile. Also, it was denoted as "doesn't quite work yet" when the file was initially adde= d (which may account for it never having been hooked up to the build). [jhb] Remove reference to sys/dev/dpt/dpt_control.c. It was removed back i= n 2001 after having never been updated for CAM changes in 1998. [kib] Fix assertion, &uc->uc_busy is never zero, the intent is to test the uc_busy value, and not its address [1]. Remove the single use of the macro, write KASSERT() explicitely in the code of umtxq_sleep_pi(). Submitted by:=09Eric van Gyzen [1] MFC after:=091 week ------------------------------------------ [...truncated 281713 lines...] ctfconvert -L VERSION -g bus_if.o --- md.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- virtio_if.o --- ctfconvert -L VERSION -g virtio_if.o --- usb_dev.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- acpi_wmi_if.o --- ctfconvert -L VERSION -g acpi_wmi_if.o --- evtchn_dev.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = ctfconvert -L VERSION -g evtchn_dev.o --- dead_vnops.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = ctfconvert -L VERSION -g dead_vnops.o --- devfs_devs.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- md.o --- ctfconvert -L VERSION -g md.o --- devfs_vfsops.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- usb_dev.o --- ctfconvert -L VERSION -g usb_dev.o --- devfs_vnops.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- devfs_vfsops.o --- ctfconvert -L VERSION -g devfs_vfsops.o --- fifo_vnops.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- devfs_devs.o --- ctfconvert -L VERSION -g devfs_devs.o --- msdosfs_denode.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- freebsd32_misc.o --- ctfconvert -L VERSION -g freebsd32_misc.o --- msdosfs_fat.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- fifo_vnops.o --- ctfconvert -L VERSION -g fifo_vnops.o --- msdosfs_lookup.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- msdosfs_denode.o --- ctfconvert -L VERSION -g msdosfs_denode.o --- msdosfs_vfsops.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- devfs_vnops.o --- ctfconvert -L VERSION -g devfs_vnops.o --- msdosfs_vnops.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- msdosfs_lookup.o --- ctfconvert -L VERSION -g msdosfs_lookup.o --- nfs_commonkrpc.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- msdosfs_fat.o --- ctfconvert -L VERSION -g msdosfs_fat.o --- nfs_commonsubs.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- msdosfs_vfsops.o --- ctfconvert -L VERSION -g msdosfs_vfsops.o --- nfs_commonport.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- msdosfs_vnops.o --- ctfconvert -L VERSION -g msdosfs_vnops.o --- nfs_commonacl.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- nfs_commonport.o --- ctfconvert -L VERSION -g nfs_commonport.o --- nfs_commonacl.o --- ctfconvert -L VERSION -g nfs_commonacl.o --- nfs_clcomsubs.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- nfs_clsubs.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- nfs_commonkrpc.o --- ctfconvert -L VERSION -g nfs_commonkrpc.o --- nfs_clstate.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- nfs_clsubs.o --- ctfconvert -L VERSION -g nfs_clsubs.o --- nfs_clcomsubs.o --- ctfconvert -L VERSION -g nfs_clcomsubs.o --- nfs_clkrpc.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- nfs_clrpcops.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- nfs_clkrpc.o --- ctfconvert -L VERSION -g nfs_clkrpc.o --- nfs_clvnops.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- nfs_commonsubs.o --- ctfconvert -L VERSION -g nfs_commonsubs.o --- nfs_clnode.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = ctfconvert -L VERSION -g nfs_clnode.o --- nfs_clvfsops.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- nfs_clstate.o --- ctfconvert -L VERSION -g nfs_clstate.o --- nfs_clvnops.o --- ctfconvert -L VERSION -g nfs_clvnops.o --- nfs_clport.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- nfs_clbio.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- nfs_clrpcops.o --- ctfconvert -L VERSION -g nfs_clrpcops.o --- nfs_clvfsops.o --- ctfconvert -L VERSION -g nfs_clvfsops.o --- nfs_clnfsiod.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- nfs_fha_new.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- nfs_clport.o --- ctfconvert -L VERSION -g nfs_clport.o --- nfs_clbio.o --- ctfconvert -L VERSION -g nfs_clbio.o --- nfs_nfsdsocket.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- nfs_nfsdsubs.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- nfs_fha_new.o --- ctfconvert -L VERSION -g nfs_fha_new.o --- nfs_clnfsiod.o --- ctfconvert -L VERSION -g nfs_clnfsiod.o --- nfs_nfsdstate.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- nfs_nfsdkrpc.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- nfs_nfsdsocket.o --- ctfconvert -L VERSION -g nfs_nfsdsocket.o --- nfs_nfsdserv.o --- --- nfs_nfsdsubs.o --- ctfconvert -L VERSION -g nfs_nfsdsubs.o --- nfs_nfsdserv.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- nfs_nfsdport.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- nfs_nfsdkrpc.o --- ctfconvert -L VERSION -g nfs_nfsdkrpc.o --- nfs_nfsdcache.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = ctfconvert -L VERSION -g nfs_nfsdcache.o --- procfs.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = ctfconvert -L VERSION -g procfs.o --- procfs_map.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- nfs_nfsdport.o --- ctfconvert -L VERSION -g nfs_nfsdport.o --- nfs_nfsdserv.o --- ctfconvert -L VERSION -g nfs_nfsdserv.o --- pseudofs.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- pseudofs_vncache.o --- --- procfs_map.o --- ctfconvert -L VERSION -g procfs_map.o --- pseudofs_vncache.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- pseudofs_vnops.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- nfs_nfsdstate.o --- ctfconvert -L VERSION -g nfs_nfsdstate.o --- geom_vfs.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- pseudofs_vncache.o --- ctfconvert -L VERSION -g pseudofs_vncache.o --- pseudofs.o --- ctfconvert -L VERSION -g pseudofs.o --- cd9660_bmap.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- cd9660_lookup.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- geom_vfs.o --- ctfconvert -L VERSION -g geom_vfs.o --- cd9660_bmap.o --- ctfconvert -L VERSION -g cd9660_bmap.o --- cd9660_node.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- cd9660_rrip.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- pseudofs_vnops.o --- ctfconvert -L VERSION -g pseudofs_vnops.o --- cd9660_util.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- cd9660_lookup.o --- ctfconvert -L VERSION -g cd9660_lookup.o --- cd9660_vfsops.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- cd9660_node.o --- ctfconvert -L VERSION -g cd9660_node.o --- cd9660_vnops.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- cd9660_util.o --- ctfconvert -L VERSION -g cd9660_util.o --- imgact_elf.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- cd9660_rrip.o --- ctfconvert -L VERSION -g cd9660_rrip.o --- imgact_elf32.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- cd9660_vfsops.o --- ctfconvert -L VERSION -g cd9660_vfsops.o --- cd9660_vnops.o --- ctfconvert -L VERSION -g cd9660_vnops.o --- imgact_shell.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- init_main.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- imgact_shell.o --- ctfconvert -L VERSION -g imgact_shell.o --- init_main.o --- :530:25: error: too many arguments to function call, expected single arg= ument 'fdp', have 2 arguments p->p_fd =3D fdinit(NULL, false); ~~~~~~ ^~~~~ :2= 72:15: note: expanded from macro 'false' #define false 0 ^ :161:1: note: 'fdinit' declared here struct filedesc *fdinit(struct filedesc *fdp); ^ --- kern_acct.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glo= bal.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror = --- init_main.o --- 1 error generated. *** [init_main.o] Error code 1 make[2]: stopped in /usr/obj --- imgact_elf.o --- ctfconvert -L VERSION -g imgact_elf.o --- imgact_elf32.o --- ctfconvert -L VERSION -g imgact_elf32.o --- kern_acct.o --- ctfconvert -L VERSION -g kern_acct.o 1 error make[2]: stopped in /usr/obj *** [buildkernel] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildkernel] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Thu Nov 13 22:42:57 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70D14F26; Thu, 13 Nov 2014 22:42:57 +0000 (UTC) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F0B3E16D; Thu, 13 Nov 2014 22:42:56 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id bs8so1046833wib.11 for ; Thu, 13 Nov 2014 14:42:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=gDNXA3fmAT4kPlzbg1fSQtKj0XBX/qvlfNOv6kvAVhs=; b=QRyx1yu0kxhbw1h2nnWv5bhHXJdERg9ZXsQv1OP+tbXYep9ko0EnwZgLOn8fHCs8rP QBG8y59l3kKalfzd+7UfIivzF3JST8rtJ4qiZWJ36vcgx19rJ91gXJPlpbDqBSdZTwBY fwEYuChuwq0yOMCODDJCgrCd+MLTuawIBCKv8WM+C4qsIpO+ObCkEdm3zgaR6ljUQCos rWzvvQGXfGBanolB9fL6uyrKsItdvf1qt0nByfn9ShYCPdwyfjw8QFgRHL3xrbhvF0wt oBb/kNRc8wp7rRSYXBd1u5VPfMVVQHfRElX4Oavw6zS2tgga46DLFF27uA7XTtHRluXi RsFg== X-Received: by 10.180.87.196 with SMTP id ba4mr2287950wib.40.1415918575418; Thu, 13 Nov 2014 14:42:55 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id gc7sm37270436wjb.16.2014.11.13.14.42.54 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 13 Nov 2014 14:42:54 -0800 (PST) Date: Thu, 13 Nov 2014 23:42:52 +0100 From: Mateusz Guzik To: jenkins-admin@freebsd.org Subject: Re: Build failed in Jenkins: FreeBSD_HEAD #1835 Message-ID: <20141113224252.GD31600@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , jenkins-admin@freebsd.org, freebsd-current@freebsd.org, dim@FreeBSD.org, jhb@FreeBSD.org, mjg@FreeBSD.org, kib@FreeBSD.org References: <2032357817.48.1415918449825.JavaMail.jenkins@jenkins-9.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <2032357817.48.1415918449825.JavaMail.jenkins@jenkins-9.freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: kib@FreeBSD.org, freebsd-current@freebsd.org, dim@FreeBSD.org, mjg@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 13 Nov 2014 22:42:57 -0000 On Thu, Nov 13, 2014 at 10:40:48PM +0000, jenkins-admin@freebsd.org wrote: > --- imgact_shell.o --- > ctfconvert -L VERSION -g imgact_shell.o > --- init_main.o --- > :530:25: error: too many arguments to function call, expected single argument 'fdp', have 2 arguments > p->p_fd = fdinit(NULL, false); > ~~~~~~ ^~~~~ > :272:15: note: expanded from macro 'false' > #define false 0 > ^ > :161:1: note: 'fdinit' declared here > struct filedesc *fdinit(struct filedesc *fdp); > ^ That's my fault, fixed in https://svnweb.freebsd.org/changeset/base/274485 -- Mateusz Guzik From owner-freebsd-current@FreeBSD.ORG Fri Nov 14 00:53:16 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE83EA66; Fri, 14 Nov 2014 00:53:16 +0000 (UTC) Received: from forward4l.mail.yandex.net (forward4l.mail.yandex.net [IPv6:2a02:6b8:0:1819::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7C6ACA4; Fri, 14 Nov 2014 00:53:16 +0000 (UTC) Received: from smtp2h.mail.yandex.net (smtp2h.mail.yandex.net [84.201.187.145]) by forward4l.mail.yandex.net (Yandex) with ESMTP id 190531440E8F; Fri, 14 Nov 2014 03:53:13 +0300 (MSK) Received: from smtp2h.mail.yandex.net (localhost [127.0.0.1]) by smtp2h.mail.yandex.net (Yandex) with ESMTP id 8D3E61703976; Fri, 14 Nov 2014 03:53:12 +0300 (MSK) Received: from 84.201.167.97-vpn.dhcp.yndx.net (84.201.167.97-vpn.dhcp.yndx.net [84.201.167.97]) by smtp2h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id zanu1dxmSn-rBH0erNx; Fri, 14 Nov 2014 03:53:11 +0300 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 967a624c-2690-4607-8972-9aacbe2218b8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1415926391; bh=XQOdl5wldJ2nq3H96DodnztqCCVBQTN99100DNGD9wQ=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type; b=J8tn0e1By3UPIGCr7ckosi0NK5ojALvf3yrw4/z26BhqdzAjuhEOmoACS3cYX8+Bk CpATJmYuj/uiNXZ5HXhNXXdkgkJPwIIVlniaA5xdhAGG4lozL4TKIDmThmOC0zv8at DA+dgtctJCLBNOKWWmC0J+zTCew4A9czx5JFJ/eo= Authentication-Results: smtp2h.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <54655257.8080705@yandex.ru> Date: Fri, 14 Nov 2014 03:52:39 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-security@FreeBSD.org, current@FreeBSD.org Subject: Re: CFR: AES-GCM and OpenCrypto work review References: <20141108042300.GA24601@funkthat.com> In-Reply-To: <20141108042300.GA24601@funkthat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mIJ8gMC0hbLng2nPMX2ha3xC2gE3kxrGc" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 14 Nov 2014 00:53:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mIJ8gMC0hbLng2nPMX2ha3xC2gE3kxrGc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 08.11.2014 07:23, John-Mark Gurney wrote: > Hello, >=20 > Over the last few months, I've been working on a project to add support= > for AES-GCM and AES-CTR modes to our OpenCrypto framework. The work is= > sponsored by The FreeBSD Foundation and Netgate. >=20 > I plan on committing these patches early next week. If you need more > time for review, please email me privately and I will make delay. >=20 > The code has already been reviewed by Watson Ladd (the software crypto > implementations) and Trevor Perrin (the aesni module part) and I have > integrated these changes into the patch. >=20 > There are two patches, one is the changes for OpenCrypto and the test > framework. The other is the data files used by the test framework. > The data is from NIST's CAVP program, and is about 20MB worth of test > vectors. (I just realized, should we look at compressing these on > disk?) >=20 > Main patch (192KB): > https://www.funkthat.com/~jmg/patches/aes.ipsec.5.patch >=20 > Data files (~20MB): > https://www.funkthat.com/~jmg/patches/aes.ipsec.5.testing.patch >=20 > A list of notable changes in the patch: > - Replacing crypto(4) w/ NetBSD's version + updates > - Lots of man page updates, including CIOCFINDDEV and crypto(7) which > adds specifics about restrictions on the modes. > - Allow sane useage of both _HARDWARE and _SOFTWARE flags. > - Add a timing safe bcmp for MAC comparision. > - Add a software implementation of GCM that uses a four bit lookup > table with parallelization. This algorithm is possibly vulnerable to= > timing attacks, but best known mitigation methods are used. Using > a timing safe version is many times slower. > - Added a CRYPTDEB macro that defaults to off. > - Bring in some of OpenBSD's improvements to the OpenCrypto framework. > - If an mbuf passed to the aesni module is only one segment, don't do > a copy. This needs to be improved to support segmented buffers. > - Remove the CRYPTO_F_REL flag. It was meaningless. It was used but > did not change any behavior. > - Add function crypto_mbuftoiov to convert an mbuf to an iov. This > also converts the software crypto to only use iov's even for a simple= > linear buffer, and so simplifies the processing. > - Add a dtrace probe for errors from the ioctl. > - Add the CIOCCRYPTAEAD ioctl that allows userland processing (testing)= > of AES-GCM and future AEAD modes. >=20 > Future improvements: > - Support IV's longer than 12 bytes for GCM. > - Make AES-NI support segmented buffers (iov or mbuf) so multisegmented= > inputs don't have to be copied. >=20 > I know there are more fixes and future improvements, but can't think of= > them now. I tried your patch with my IPv4 forwarding test. When aesni module is loaded and aes-cbc is used I see growing of `invalid outbound packets` counter in `netstat -sp ipsec` output. And no packets are forwarded. Also while testing I got a panic in aesni_encrypt_cbc(). atal trap 9: general protection fault while in kernel mode cpuid =3D 4; apic id =3D 04 instruction pointer =3D 0x20:0xffffffff80d05c43 stack pointer =3D 0x28:0xfffffe00003f7e70 frame pointer =3D 0x28:0xfffffe00003f7eb0 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 12 (irq286: ix0:que 4) The backtrace: #0 doadump (textdump=3D276160512) at pcpu.h:219 #1 0xffffffff80355525 in db_fncall (dummy1=3D, dummy2=3D, dummy3=3D, dummy4=3D) at /usr/src/sys/ddb/db_command.c:568 #2 0xffffffff8035520d in db_command (cmd_table=3D0x0) at /usr/src/sys/ddb/db_command.c:440 #3 0xffffffff80354f84 in db_command_loop () at /usr/src/sys/ddb/db_command.c:493 #4 0xffffffff80357980 in db_trap (type=3D, code=3D0= ) at /usr/src/sys/ddb/db_main.c:251 #5 0xffffffff8095c641 in kdb_trap (type=3D9, code=3D0, tf=3D) at /usr/src/sys/kern/subr_kdb.c:654 #6 0xffffffff80d1edcc in trap_fatal (frame=3D0xfffffe00003f7dc0, eva=3D) at /usr/src/sys/amd64/amd64/trap.c:861 #7 0xffffffff80d1ea6e in trap (frame=3D) at /usr/src/sys/amd64/amd64/trap.c:201 #8 0xffffffff80d04092 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #9 0xffffffff80d05c43 in fpudna () at /usr/src/sys/amd64/amd64/fpu.c:85 #10 0xffffffff80d1e7ae in trap (frame=3D) at /usr/src/sys/amd64/amd64/trap.c:432 #11 0xffffffff80d04092 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #12 0xffffffff8202f96e in aesni_encrypt_cbc (rounds=3D10, key_schedule=3D0xfffff8005603d400, len=3D3, from=3D0xfffff8013b0de65a "E"= , to=3D0xfffff8013b0de65a "E", iv=3D0xfffff8005603d6d0 "=EF=BF=BD#=EF=BF=BD=EF=BF=BD8=EF=BF=BD:n=EF=BF= =BD\r=EF=BF=BD=EF=BF=BD\f=EF=BF=BD=EF=BF=BD=EF=BF=BD\v") at /usr/src/sys/modules/aesni/../../crypto/aesni/aesni_wrap.c:63 #13 0xffffffff820318d0 in aesni_process (dev=3D, crp=3D0xfffff80109f7bc08, hint=3D) at /usr/src/sys/modules/aesni/../../crypto/aesni/aesni.c:535 #14 0xffffffff80b170e9 in crypto_dispatch (crp=3D0xfffff80109f7bc08) at /usr/src/sys/opencrypto/crypto.c:807 #15 0xffffffff80b076d6 in esp_output (m=3D, isr=3D, mp=3D0x3, skip=3D, protoff=3D) at /usr/src/sys/netipsec/xform_esp.c:905 #16 0xffffffff80af7457 in ipsec4_process_packet (m=3D0xfffff8013b0de600, isr=3D, flags=3D, tunalready=3D) at /usr/src/sys/netipsec/ipsec_output.c:594 #17 0xffffffff80a4a0db in ip_ipsec_output (m=3D, inp=3D, flags=3D0xfffffe00003f8494, error=3D0xfffffe00003f8490) at /usr/src/sys/netinet/ip_ipsec.c:332 #18 0xffffffff80a4b6b9 in ip_output (m=3D0xfffff8013b0de600, opt=3D, flags=3D1, imo=3D, inp=3D0x0) at /usr/src/sys/netinet/ip_output.c:476 #19 0xffffffff80a485eb in ip_forward (m=3D0xfffff8013b0de600, srcrt=3D) at /usr/src/sys/netinet/ip_input.c:1571 #20 0xffffffff80a4825e in ip_input (m=3D0xfffff8013b0de600) at /usr/src/sys/netinet/ip_input.c:754 #21 0xffffffff809e7be1 in netisr_dispatch_src (proto=3D, source=3D, m=3D0xfffff8013b0de65a) at /usr/src/sys/net/netisr.c:968 #22 0xffffffff809dfb53 in ether_demux (ifp=3D, m=3D0xfffff8013b0de600) at /usr/src/sys/net/if_ethersubr.c:766 #23 0xffffffff809e0758 in ether_nh_input (m=3D) at /usr/src/sys/net/if_ethersubr.c:573 #24 0xffffffff809e7be1 in netisr_dispatch_src (proto=3D, source=3D, m=3D0xfffff8013b0de65a) at /usr/src/sys/net/netisr.c:968 #25 0xffffffff809dfdb6 in ether_input (ifp=3D, m=3D0= x0) at /usr/src/sys/net/if_ethersubr.c:674 #26 0xffffffff809e55e5 in vlan_input (ifp=3D0xfffff8000ef3e800, m=3D) at /usr/src/sys/net/if_vlan.c:1239 #27 0xffffffff809dfac4 in ether_demux (ifp=3D0xfffff8000ef3e800, m=3D0xfffff8013b0de600) at /usr/src/sys/net/if_ethersubr.c:717 #28 0xffffffff809e0758 in ether_nh_input (m=3D) at /usr/src/sys/net/if_ethersubr.c:573 #29 0xffffffff809e7be1 in netisr_dispatch_src (proto=3D, source=3D, m=3D0xfffff8013b0de65a) at /usr/src/sys/net/netisr.c:968 #30 0xffffffff809dfdb6 in ether_input (ifp=3D, m=3D0= x0) at /usr/src/sys/net/if_ethersubr.c:674 #31 0xffffffff8059f303 in ixgbe_rxeof (que=3D0xfffff8000ef5c1a0) at /usr/src/sys/dev/ixgbe/ixgbe.c:4530 > Ermal (eri) has patches that enable AES-GCM (and I believe AES-CTR) > support for our IPsec. Once these patches have been committed, I'll > work with him to integrate his patch. --=20 WBR, Andrey V. Elsukov --mIJ8gMC0hbLng2nPMX2ha3xC2gE3kxrGc 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 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJUZVJoAAoJEAHF6gQQyKF6gQoH/3BABEMxojQOwmeVo+ZR4Kh1 w3pi23AcHhw4v7fn0H+h0KHwuo4ZfNOJe5KrSSJ9BEt8wEQZnGS2LSQT7FZKDr8b oxUOrt9L2oQmjVLuIBlqbfIyAKPsCPN/Mt86EvBYTKQymWxstfLAct4ogx16SnSc qNKlb7IFONqAWIDfFGkOjLcwJdEq9YHCkPX4/lEurgJ2+BV/ToSl9Veq90HZL7ty fQ5+GYSRmDSYsuDwZQjy0fYYVdELnXYNR3Pzcfd9rr0pMvOsIlP4M29Bi22xvmzY AJzjPilR6Naj6viYr/3gr3bg5SW/g7WUfKnm6XyNGoXTPhPfF+FiMUCi18jLcjs= =PVaI -----END PGP SIGNATURE----- --mIJ8gMC0hbLng2nPMX2ha3xC2gE3kxrGc-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 14 01:15:20 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 21BC6E0B; Fri, 14 Nov 2014 01:15:20 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B429133A; Fri, 14 Nov 2014 01:15:19 +0000 (UTC) Received-SPF: pass (freebsd.czest.pl: domain of wkoszek@freebsd.czest.pl designates 212.87.224.105 as permitted sender) receiver=freebsd.czest.pl; client-ip=212.87.224.105; helo=freebsd.czest.pl; envelope-from=wkoszek@freebsd.czest.pl; x-software=spfmilter 0.97 http://www.acme.com/software/spfmilter/ with libspf-unknown; Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id sAE16gRe090216; Fri, 14 Nov 2014 01:06:43 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id sAE16gdp090215; Fri, 14 Nov 2014 01:06:42 GMT (envelope-from wkoszek) Date: Fri, 14 Nov 2014 01:06:42 +0000 From: "Wojciech A. Koszek" To: Alan Somers Subject: Re: FreeBSD + Google Code-In 2014 = we need ideas. Message-ID: <20141114010642.GB89106@FreeBSD.org> References: <20141110035915.GA50986@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD, SPF_HELO_PASS,SPF_PASS,URIBL_DBL_REDIR autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on freebsd.czest.pl X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Fri, 14 Nov 2014 01:06:49 +0000 (UTC) Cc: "freebsd-hackers@freebsd.org" , FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 14 Nov 2014 01:15:20 -0000 On Mon, Nov 10, 2014 at 01:56:27PM -0700, Alan Somers wrote: > On Sun, Nov 9, 2014 at 8:59 PM, Wojciech A. Koszek wrote: > > Hello, BTW, FYI: We didn't make it this year. Judging by the GSoC 2014 Reunion, there is a lot of seasoned Orgs which treat GCIN very seriously, so I think if we plan to participate, it'll be a lot of effort to compete with them Anyway: thanks for the tasks which were submitted. I will put them in Wiki for the reference, Wojciech > > > > This year we'd like to participate in the Google Code-In 2014. This is > > Google Summer of Code, but for younger people: age range is 13--17. If > > you're one of them, we highly encourage you to apply! > > > > ***This year coding tasks are possible, so feel free to add those*** > > > > To submit idea which you'd like to see done in GCI, visit: > > > > http://bit.ly/FreeBSD_GCIN2014 > > > > Regardless of who you are, please use the form to submit ideas. Don't add > > stuff via Wiki, since this year we'll do direct import of all ideas from > > Google Forms. > > > > To see tasks from previous year that are yet to be copied to Google Forms: > > > > https://wiki.freebsd.org/GoogleCodeIn/2014Tasks > > > > Thanks to GCI in the previous years, we gained one more FreeBSD developer. > > We'd like to partcipate this year too. We need: > > > > 1) ideas. > > > How about converting various utility functions to use libxo? I think > that's within the grasp of a high-schooler. > > > > > > 2) mentors > > > > 3) participants. > > > > Just like in previous years we'll decide whether we're ready. Deadlines: > > > > --- > > November 12, 2014 - The 10-12 Mentoring organizations are announced for > > Google Code-in 2014 and the orgs can start entering their tasks into the > > Google system (the tasks will not be viewable to students until the contest > > opens on Dec 1). > > December 1, 2014 17:00 UTC - Google Code-in 2014 contest opens for students > > January 19, 2015 17:00 UTC - Google Code-in 2014 student work ends > > --- > > > > MORE INFO: > > > > [0] http://www.google-melange.com/gci/homepage/google/gci2014 > > [1] gci-mentors@googlegroups.com > > [2] https://developers.google.com/open-source/gci/resources/mentor-and-orgadmin-info > > > > -- > > Wojciech A. Koszek > > wkoszek@FreeBSD.czest.pl > > http://FreeBSD.czest.pl/~wkoszek/ > > _______________________________________________ > > 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" -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-current@FreeBSD.ORG Fri Nov 14 01:40:02 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 68F4E376; Fri, 14 Nov 2014 01:40:02 +0000 (UTC) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EDBBB79F; Fri, 14 Nov 2014 01:40:01 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id b13so18213570wgh.26 for ; Thu, 13 Nov 2014 17:40:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=ERVdAnQ2p+YzJIOZIUCzbLP3BM9C0Y+IFUkZBk+/oCM=; b=Ihh5R4SDOWklentsE0YMd0nGwMzNHAZaouPXrhUN0WCH0u1NKtjIbtqW7eYuq8xXUv UxIa1dhxqyk1GCeH7Otx5AOPSNNrnCv2X1+BAXl4IsRxr40hFnsWTRBYxJhiIQkDaFpw wL51wuWYsLpXGddrcmhrtqRKRSeWFxtCxFKSXCkvTHtXTAV5vfQ3tJnnzG3zaINCvmZY 1QzOGyUtnTP/+rM6wDGoNTwIwfgwYFgKInWu2i3pSQm3FXh40Yqg8/9oeHJpyataT+um rcrn/B3HVwmfb3vrbLFCHWvR6yxhMwci94gL1vw0D5RQU6gb7BZCsEjH2hePoAMW+y0k pHJA== MIME-Version: 1.0 X-Received: by 10.194.110.161 with SMTP id ib1mr9485384wjb.78.1415929200339; Thu, 13 Nov 2014 17:40:00 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.194.19.9 with HTTP; Thu, 13 Nov 2014 17:40:00 -0800 (PST) Date: Thu, 13 Nov 2014 17:40:00 -0800 X-Google-Sender-Auth: nKWFoKJddQ3JUgIt_68XbOAJ7xc Message-ID: Subject: comments on code-in tasks for FreeBSD (Re: FreeBSD + Google Code-In 2014 = we need ideas.) From: Luigi Rizzo To: "Wojciech A. Koszek" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-hackers@freebsd.org" , FreeBSD CURRENT , Alan Somers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 14 Nov 2014 01:40:02 -0000 On Thu, Nov 13, 2014 at 5:06 PM, Wojciech A. Koszek wrote: > On Mon, Nov 10, 2014 at 01:56:27PM -0700, Alan Somers wrote: > > On Sun, Nov 9, 2014 at 8:59 PM, Wojciech A. Koszek > wrote: > > > Hello, > > BTW, FYI: > > We didn't make it this year. > > Judging by the GSoC 2014 Reunion, there is a lot of seasoned Orgs which > treat GCIN very seriously, so I think if we plan to participate, it'll be= a > lot of effort to compete with them > > Anyway: thanks for the tasks which were submitted. I will put them in Wik= i > for the reference, > =E2=80=8Bhi, i meant to send this email before but given the outcome this seems a good time to prepare for next year. I have been looking at tasks to submit (especially coding, but not just those) and looking at other organisations who participated in past years, i believe that FreeBSD (with its C- and kernel- centric environment) is a poor match for code-in, specifically due to the young age and predictable lack of expertise of most of the participants, and the small size of the tasks. In my view, most of the documentation tasks listed in the wiki https://wiki.freebsd.org/GoogleCodeIn/2014Tasks are not approachable by students -- they require experience and knowledge of compilers, subsystems and development techniques that are unlikely to exist for teenagers. When it comes to programming tasks, again the list has entries simply beyond the ability of the students. First three tasks: "static analysis for kernel locking", "static analysis of kernel conventions", "profile libc++". These are important tasks, but they just do not belong here. As a rule of thumb i would say that anything that is in the list should not take more than 2-3 hours/half a day to an experienced developer, be accompanied by a detailed description on what to do and how, and by a commitment from the mentor to review it. Also, if we want to suggest some coding task, it is important that we can give students a preloaded OS image with all the tools and repos they may need for their work, otherwise they end up spending a lot of time setting up the environment and possibly making mistakes in the process that prevent a correct completion of the work. Sure we ship with compilers and make, but we miss svn/git, an embedded snapshot of source and ports tree, and now that we can, also a bhyve or qemu example to help them testing kernels. Finally, we should shift the approach from "something we need" to "something can be a useful exercise for the students" even if it replicates features that already exist in the OS. That might perhaps lead to smaller, better and easier to define tasks with a better chance to be completed. Lacking any better idea (which I don't have because as i said i think FreeBSD just is not a good match for this competition), we could take some specific bug reports, and provide details and hints for solutions. But please nuke the current list -- it is completely inadequate for the code-in candidates and misleading for whoever wants to suggest new tasks. Again i am not saying that the projects suggested there are not important, just belong somewhere else e.g. gsoc. =E2=80=8Bcheers luigi =E2=80=8B > > Wojciech > > > > > > > This year we'd like to participate in the Google Code-In 2014. This i= s > > > Google Summer of Code, but for younger people: age range is 13--17. I= f > > > you're one of them, we highly encourage you to apply! > > > > > > ***This year coding tasks are possible, so feel free to add those*** > > > > > > To submit idea which you'd like to see done in GCI, visit: > > > > > > http://bit.ly/FreeBSD_GCIN2014 > > > > > > Regardless of who you are, please use the form to submit ideas. Don'= t > add > > > stuff via Wiki, since this year we'll do direct import of all ideas > from > > > Google Forms. > > > > > > To see tasks from previous year that are yet to be copied to Google > Forms: > > > > > > https://wiki.freebsd.org/GoogleCodeIn/2014Tasks > > > > > > Thanks to GCI in the previous years, we gained one more FreeBSD > developer. > > > We'd like to partcipate this year too. We need: > > > > > > 1) ideas. > > > > > > How about converting various utility functions to use libxo? I think > > that's within the grasp of a high-schooler. > > > > > > > > > > 2) mentors > > > > > > 3) participants. > > > > > > Just like in previous years we'll decide whether we're ready. > Deadlines: > > > > > > --- > > > November 12, 2014 - The 10-12 Mentoring organizations are > announced for > > > Google Code-in 2014 and the orgs can start entering their > tasks into the > > > Google system (the tasks will not be viewable to students > until the contest > > > opens on Dec 1). > > > December 1, 2014 17:00 UTC - Google Code-in 2014 contest open= s > for students > > > January 19, 2015 17:00 UTC - Google Code-in 2014 student work > ends > > > --- > > > > > > MORE INFO: > > > > > > [0] http://www.google-melange.com/gci/homepage/google/gci2014 > > > [1] gci-mentors@googlegroups.com > > > [2] > https://developers.google.com/open-source/gci/resources/mentor-and-orgadm= in-info > > > > > > -- > > > Wojciech A. Koszek > > > wkoszek@FreeBSD.czest.pl > > > http://FreeBSD.czest.pl/~wkoszek/ > > > _______________________________________________ > > > 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" > > -- > Wojciech A. Koszek > wkoszek@FreeBSD.czest.pl > http://FreeBSD.czest.pl/~wkoszek/ > _______________________________________________ > 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= " > --=20 -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-current@FreeBSD.ORG Fri Nov 14 02:07:42 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 50A93C41 for ; Fri, 14 Nov 2014 02:07:42 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 23F53A31 for ; Fri, 14 Nov 2014 02:07:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:Subject:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=ThDnYwAkwzpeimb6dV/IM1k94mHrV8/+LbyYkD8Rl4c=; b=J2jONVzaBVVY5/DpZv2kTw70OyEHCFcF8lvNsPOkKo/U2aS42wS0FoQIBXNpAueLJDTtMXtEcdWWEdNM7S0uLMi0cHEaJZvq+1lonV4ZJBn6ISK1Feb3Y1DxbkZ7ea/0KvckhDnwH3XKdgz0Wt1bjkNGIZf4TVpIxTfCQHESbK8=; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]:59339 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:DHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Xp6IV-0008Qo-QT for freebsd-current@freebsd.org; Thu, 13 Nov 2014 20:07:40 -0600 Received: from 104-54-221-134.lightspeed.austtx.sbcglobal.net ([104.54.221.134]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Thu, 13 Nov 2014 20:07:39 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 13 Nov 2014 20:07:39 -0600 From: Larry Rosenman To: Freebsd current Subject: How do I get someone to look at / comment on Message-ID: <7d96aa32d0369b9e98cd452498a1ec8d@thebighonker.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.0.3 X-Spam-Score: -3.9 (---) X-LERCTR-Spam-Score: -3.9 (---) X-Spam-Report: SpamScore (-3.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-1 X-LERCTR-Spam-Report: SpamScore (-3.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 14 Nov 2014 02:07:42 -0000 this bug? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194770 It's to stop a constant stream of noise on my 11-CURRENT box. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Fri Nov 14 02:23:43 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B021BE6D for ; Fri, 14 Nov 2014 02:23:43 +0000 (UTC) Received: from mail.egr.msu.edu (gribble.egr.msu.edu [35.9.37.169]) by mx1.freebsd.org (Postfix) with ESMTP id 87632BB9 for ; Fri, 14 Nov 2014 02:23:42 +0000 (UTC) Received: from gribble (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id 1B2D83E399 for ; Thu, 13 Nov 2014 21:23:35 -0500 (EST) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by gribble (gribble.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFht-ncimjzN for ; Thu, 13 Nov 2014 21:23:34 -0500 (EST) Received: from EGR authenticated sender Message-ID: <546567A6.5050206@egr.msu.edu> Date: Thu, 13 Nov 2014 21:23:34 -0500 From: Adam McDougall User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: How do I get someone to look at / comment on References: <7d96aa32d0369b9e98cd452498a1ec8d@thebighonker.lerctr.org> In-Reply-To: <7d96aa32d0369b9e98cd452498a1ec8d@thebighonker.lerctr.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 14 Nov 2014 02:23:43 -0000 On 11/13/2014 21:07, Larry Rosenman wrote: > this bug? > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194770 > > It's to stop a constant stream of noise on my 11-CURRENT box. > > > Doesn't r273962 take care of this? From owner-freebsd-current@FreeBSD.ORG Fri Nov 14 02:45:55 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0CCD2114; Fri, 14 Nov 2014 02:45:55 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D1AF5D53; Fri, 14 Nov 2014 02:45:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=+8cBRH7aFyuViuxGZEzOWb6S59Smy4CbWPvOTxdxkv0=; b=msF3UfvAqgrej+l/ndqnn2UB3LMnh6ZlBU3SiWD9VFoeOGlB0bSl70rtgzBP3jwak26zof2fCyhESjL5QCjJcLZZ+P8VlBgPq93NW63ebvkj9afRfpyrHAcCft1LJMPI6d1/Y/q3Pi4FtdPmM2NBKwxw0G5zcZRGss0FEmT3p88=; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]:62115 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:DHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Xp6tU-0008d2-7s; Thu, 13 Nov 2014 20:45:53 -0600 Received: from 104-54-221-134.lightspeed.austtx.sbcglobal.net ([104.54.221.134]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Thu, 13 Nov 2014 20:45:52 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 13 Nov 2014 20:45:52 -0600 From: Larry Rosenman To: Adam McDougall Subject: Re: How do I get someone to look at / comment on In-Reply-To: <546567A6.5050206@egr.msu.edu> References: <7d96aa32d0369b9e98cd452498a1ec8d@thebighonker.lerctr.org> <546567A6.5050206@egr.msu.edu> Message-ID: X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.0.3 X-Spam-Score: -3.9 (---) X-LERCTR-Spam-Score: -3.9 (---) X-Spam-Report: SpamScore (-3.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-1 X-LERCTR-Spam-Report: SpamScore (-3.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-1 Cc: freebsd-current@freebsd.org, owner-freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 14 Nov 2014 02:45:55 -0000 On 2014-11-13 20:23, Adam McDougall wrote: > On 11/13/2014 21:07, Larry Rosenman wrote: >> this bug? >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194770 >> >> It's to stop a constant stream of noise on my 11-CURRENT box. >> >> >> > > Doesn't r273962 take care of this? > _______________________________________________ > 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" It misses this block: Index: sys/dev/drm2/radeon/radeon_connectors.c @@ -954,7 +954,7 @@ radeon_connector->edid = drm_get_edid(&radeon_connector->base, radeon_connector->ddc_bus->adapter); if (!radeon_connector->edid) { - DRM_ERROR("%s: probed a monitor but no|invalid EDID\n", + DRM_DEBUG_KMS("%s: probed a monitor but no|invalid EDID\n", drm_get_connector_name(connector)); /* rs690 seems to have a problem with connectors not existing and always * return a block of 0's. If we see this just stop polling on this output */ Which is one of the messages I was getting... -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Fri Nov 14 02:46:25 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD21D21C for ; Fri, 14 Nov 2014 02:46:25 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id C8094D60 for ; Fri, 14 Nov 2014 02:46:25 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 23BC3231 for ; Fri, 14 Nov 2014 02:46:26 +0000 (UTC) Date: Fri, 14 Nov 2014 02:46:26 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <847680241.50.1415933186112.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <458364766.47.1415911719941.JavaMail.jenkins@jenkins-9.freebsd.org> References: <458364766.47.1415911719941.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to stable : FreeBSD_HEAD-tests2 #242 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 14 Nov 2014 02:46:25 -0000 See From owner-freebsd-current@FreeBSD.ORG Fri Nov 14 02:21:13 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 56DEDDE0; Fri, 14 Nov 2014 02:21:13 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 42549B09; Fri, 14 Nov 2014 02:21:13 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 39F4221B; Fri, 14 Nov 2014 02:21:12 +0000 (UTC) Date: Fri, 14 Nov 2014 02:21:10 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, scottl@FreeBSD.org, dim@FreeBSD.org, jhb@FreeBSD.org, zbb@FreeBSD.org, mjg@FreeBSD.org, sbruno@FreeBSD.org, jkim@FreeBSD.org, kib@FreeBSD.org Message-ID: <464636451.49.1415931672760.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <2032357817.48.1415918449825.JavaMail.jenkins@jenkins-9.freebsd.org> References: <2032357817.48.1415918449825.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD #1836 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: SUCCESS X-Mailman-Approved-At: Fri, 14 Nov 2014 03:03:54 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 14 Nov 2014 02:21:13 -0000 See From owner-freebsd-current@FreeBSD.ORG Fri Nov 14 07:23:27 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0587CD9 for ; Fri, 14 Nov 2014 07:23:27 +0000 (UTC) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7AC01C1F for ; Fri, 14 Nov 2014 07:23:27 +0000 (UTC) Received: by mail-qg0-f44.google.com with SMTP id q107so11741843qgd.31 for ; Thu, 13 Nov 2014 23:23:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Lde7JckqgBBbc9WmxGtLAbCWh1JAXhozAz1dkJBjXd4=; b=EphM5yMDblyxuAQfG8Nt0Lt/5ClAGw4xd+D8SfA4LMLY1FsHUVhWlhMbszNqaM6hRV 7tWzVzXV4+7wo0hAjQZEh4BwXTjsrWsN6Nrx3w28A9TNHzr8MDzoA6axCMKrtTG4xQgi Gqf29KMi2ZeCiepZRwtNRf4S1d31Avp5KXmS1yWeCM5xHCSEB7+HMOgzOGxgDFtnzdZT CA02l/d3f4T+4h5pGgvUX7tJzJDnnzRV+x2ayfjpOMjv7fpfaLu4Xsv0Y50+UC0FmOX8 3SgQaq9FN7JfNNkw83gox851G6WxyUsEf0pdVHUfofq05eaaETUP3xZ8EhcTRT4P+Ks6 q+gA== MIME-Version: 1.0 X-Received: by 10.224.23.9 with SMTP id p9mr9095883qab.92.1415949806656; Thu, 13 Nov 2014 23:23:26 -0800 (PST) Sender: hiren.panchasara@gmail.com Received: by 10.96.205.201 with HTTP; Thu, 13 Nov 2014 23:23:26 -0800 (PST) In-Reply-To: <5463F2DE.2040408@pinyon.org> References: <5463F2DE.2040408@pinyon.org> Date: Thu, 13 Nov 2014 23:23:26 -0800 X-Google-Sender-Auth: QHCecYnNJU5hXUK_KqTxFVjH3Jw Message-ID: Subject: Re: building stable/10 on -current From: hiren panchasara To: "Russell L. Carter" Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 14 Nov 2014 07:23:27 -0000 On Wed, Nov 12, 2014 at 3:53 PM, Russell L. Carter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > On current r273808, make buildworld in a stable/10 tree fails > with: > > building shared library libc.so.7 > /usr/bin/ld: _umtx_unlock.So: relocation R_X86_64_32 against > `SYS__umtx_unlock' can not be used when making a shared object; > recompile with -fPIC > _umtx_unlock.So: could not read symbols: Bad value > > However, poudriere can build it just fine in its jail. I am > curious why that is. I've not tried recently so no clue. > Can a -current host be made to build > stable/10, or is that impossible? iirc, it should. If it doesn't, something is broken and should be fixed. cheers, Hiren From owner-freebsd-current@FreeBSD.ORG Fri Nov 14 08:13:14 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8EE2267F for ; Fri, 14 Nov 2014 08:13:14 +0000 (UTC) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4EF7FCC for ; Fri, 14 Nov 2014 08:13:14 +0000 (UTC) Received: by mail-ob0-f178.google.com with SMTP id vb8so12083450obc.23 for ; Fri, 14 Nov 2014 00:13:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb.com; s=google; h=message-id:date:from:user-agent:mime-version:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=z7xZqLjGBmZthlL/VfGlnFEUL4nnN1WkkSgE8a85Nh8=; b=eXbRIT4+n8Ry5Es4zLtP3Sx7HF7J3RctG5QV44EjllplWc+qRLDGl5mvjj7TFueg4j zyxJGNrKjF10pIUSrjc+/MyFuWxC7jUOnX1wvh/siwRW/jtR6YZ7mYS0K4wuuYMCK2Jv gf8u6ood9cxzfFH4pPPoXx4hEeZc1MzYsa0b8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=z7xZqLjGBmZthlL/VfGlnFEUL4nnN1WkkSgE8a85Nh8=; b=SOMatPKx2KaCjV81kOmSN2KDilQgKvy8t2y7Kg4fsHoxjLVwTrDD+JCEPwrvQYdvrv BTbYTjdjn7FWuOYIafEKEWv8CN2pXMOOhoiyiYQzfIzfV+6L2ZvgpK0QUQSYGaNXAcdr rQISRXf0eKGo+UCgJ/piYtd9NWI0U2mIocZcJt0utQxbkvULEXJAiQRn7qxcoB01n+En mN8TPrvVUb5asP/dr9XxKIgrdQsFtbiZegqlWXdBWFTbjzwfQZL+62f/a74EpP6amDOK KuFIkm9BVRmRPTmB4P6rcFCbodSMPVewrYQ/bx0A3wqhOe0e7u7lCbatLAMwZM8vCgcj y0EQ== X-Gm-Message-State: ALoCoQk4JYS2pqwHzot1xDVp7sCoimxqlmLh8P+x1EDkDhlEEMGTWEeacOvzwfCgzqEq4z4BI4bY X-Received: by 10.182.50.168 with SMTP id d8mr6615567obo.2.1415952793409; Fri, 14 Nov 2014 00:13:13 -0800 (PST) Received: from rsbsd.rsb ([31.200.21.116]) by mx.google.com with ESMTPSA id u5sm11265664oem.1.2014.11.14.00.13.10 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Nov 2014 00:13:12 -0800 (PST) Message-ID: <5465B996.8020705@berentweb.com> Date: Fri, 14 Nov 2014 10:13:10 +0200 From: Beeblebrox User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 CC: FreeBSD CURRENT Subject: Re: r273918 buildworld broke at semaphore References: <1414786086662-5961241.post@n5.nabble.com> <201411111333.05910.jhb@freebsd.org> <201411121151.05374.jhb@freebsd.org> <546391A5.4010203@berentweb.com> In-Reply-To: <546391A5.4010203@berentweb.com> Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 14 Nov 2014 08:13:14 -0000 I posted the solution to this through the Nabble page, but there's a change in setting there and the messages have not gone through. So, re-posting to mail list: I disabled ccache, then buildworld / buildkernel completed. I had in /etc/make.conf: .if ${.CURDIR:M/usr/src} || ${.CURDIR:M/usr/src/*} || ${.CURDIR:M/asp/git/src} || ${.CURDIR:M/asp/git/src/*} THREADS=16 #CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/clang,1} #CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/clang++,1} The only reason I can think of is that somehow ccache was passing the older cached code to the buildworld process, and the reason for that wold be because certain clang components fail to identify themselves to ccache correctly. Once I installed the newly built kernel/world and re-booted * I deleted all under /usr/obj * re-enabled ccache in make.conf * re-ran "# make buildworld" > completed without problem. From owner-freebsd-current@FreeBSD.ORG Fri Nov 14 08:16:12 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4A6B7D1 for ; Fri, 14 Nov 2014 08:16:12 +0000 (UTC) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 80B53F9 for ; Fri, 14 Nov 2014 08:16:12 +0000 (UTC) Received: by mail-ob0-f174.google.com with SMTP id uz6so12163588obc.19 for ; Fri, 14 Nov 2014 00:16:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb.com; s=google; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=Njz1Z3F5q/5JLxgU7mKWviEnzM27DDzSu1r11pJSR1g=; b=M/65sQ23osasuch3Alej2Xs1gUWXh5g+TMv0i++XMt6mFBYv7ExrBcOTzx06f6W6Om vuzmYkCo8q7S8lu/XgNvSXlIL96xN2edGwfSZcQbIv0TXlIbDeUTctQyb6d/29XelZmK /IcXsj4Iv0xxRaIDrU5RwMeEnsBnP3lKBjEZI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=Njz1Z3F5q/5JLxgU7mKWviEnzM27DDzSu1r11pJSR1g=; b=MsLJX27Rr6u/acuO2R7jqZOuG6Ymp0X9IH38qZ9mFFEfJUhEDO6bhDD4F5nL9E5QWT FHCUpg2wZi9pt8ZafLTzsovDovpufLhIOQbj9AgJ7bngHw1EdeymwEnp35nJGk4TWGs3 z558QhmO/sGea/FUgezK5AdJ50nb8tJzBPXc+U4VWhZSn0OXZOL8odGuc2BdhUYJdW4m Ji1zpZt0USArOR/fy5qkJ189W6d0iEIuV+zq19Yj+rm6AeV0H2nyCKVKypz/a6VQmV8N J1RTDqafhnnj5NWmF/MFHXhKv0nFI4V5NwDkXrOpIMQUZuUFaGPktuP15PkDlwfzFJ3O YViQ== X-Gm-Message-State: ALoCoQmUjGDQn4GmxPRkdQIRyAOWIRiVa7IM+pJj5Hgegi3jELaLMin/LOtwZGhyudDEXB/FVkHF X-Received: by 10.202.225.5 with SMTP id y5mr6122292oig.33.1415952971933; Fri, 14 Nov 2014 00:16:11 -0800 (PST) Received: from rsbsd.rsb ([31.200.21.116]) by mx.google.com with ESMTPSA id l10sm9446242oev.7.2014.11.14.00.16.10 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Nov 2014 00:16:11 -0800 (PST) Message-ID: <5465BA4A.8010205@berentweb.com> Date: Fri, 14 Nov 2014 10:16:10 +0200 From: Beeblebrox User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: FreeBSD CURRENT Subject: Is libLLVM-3.4.so: part of src or not? Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 14 Nov 2014 08:16:12 -0000 When starting Xorg, AIGLX gets disabled and RadeonKMS complains: (EE) AIGLX error: dlopen of /usr/local/lib/dri/r600_dri.so failed (Shared object "libLLVM-3.4.so" n ot found, required by "r600_dri.so") (EE) AIGLX: reverting to software rendering (II) AIGLX: Screen 0 is not DRI capable (EE) AIGLX error: dlopen of /usr/local/lib/dri/swrast_dri.so failed (Shared object "libLLVM-3.4.so" not found, required by "swrast_dri.so") (EE) GLX: could not load software renderer (II) GLX: no usable GL providers found for screen 0 A search on the system shows libLLVM-3.4.so only exists under /usr/local/lib32. I built and installed devel/llvm34, re-started Xorg and the log shows AIGLX as starting normally (no error). From owner-freebsd-current@FreeBSD.ORG Fri Nov 14 09:33:48 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA30693C for ; Fri, 14 Nov 2014 09:33:48 +0000 (UTC) Received: from nimbus.fccf.net (nimbus.fccf.net [77.77.144.35]) by mx1.freebsd.org (Postfix) with ESMTP id 6038FAE6 for ; Fri, 14 Nov 2014 09:33:47 +0000 (UTC) Received: from straylight.m.ringlet.net (unknown [46.233.30.128]) by nimbus.fccf.net (Postfix) with ESMTPSA id 707AF465 for ; Fri, 14 Nov 2014 11:27:27 +0200 (EET) Received: from roam (uid 1000) (envelope-from roam@ringlet.net) id 2540176 by straylight.m.ringlet.net (DragonFly Mail Agent v0.9); Fri, 14 Nov 2014 11:27:26 +0200 Date: Fri, 14 Nov 2014 11:27:26 +0200 From: Peter Pentchev To: Rui Paulo Subject: Re: comments on code-in tasks for FreeBSD (Re: FreeBSD + Google Code-In 2014 = we need ideas.) Message-ID: <20141114092726.GH3196@straylight.m.ringlet.net> Mail-Followup-To: Rui Paulo , Luigi Rizzo , "freebsd-hackers@freebsd.org" , FreeBSD CURRENT , "Wojciech A. Koszek" , Alan Somers References: <2FA736F4-8D06-4BBC-81DC-3E3A646BD391@me.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="a7XSrSxqzVsaECgU" Content-Disposition: inline In-Reply-To: <2FA736F4-8D06-4BBC-81DC-3E3A646BD391@me.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "Wojciech A. Koszek" , "freebsd-hackers@freebsd.org" , FreeBSD CURRENT , Luigi Rizzo , Alan Somers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 14 Nov 2014 09:33:49 -0000 --a7XSrSxqzVsaECgU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 13, 2014 at 07:55:16PM -0800, Rui Paulo wrote: > On Nov 13, 2014, at 17:40, Luigi Rizzo wrote: > > But please nuke the current list -- it is completely inadequate > > for the code-in candidates and misleading for whoever wants to > > suggest new tasks. Again i am not saying that the projects > > suggested there are not important, just belong somewhere else > > e.g. gsoc. >=20 > I refrained from voicing my opinion while the call for help was going > on, but I completely agree that the target age of this Google initiative > is inadequate to FreeBSD. The target population is 13 years to 17 years > old and I cannot even imagine a 13 year old knowing what FreeBSD is. =2E..and yet there was pat@ becoming a ports committer at the age of 16 and chris@ becoming a docs committer at the age of 14 :) I think hmp@, alepulver@, issyl0@ and jmallett@ were pretty young when they joined, too. Just an observation, I know that one or two isolated cases do not prove a point :) G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@FreeBSD.org p.penchev@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 --a7XSrSxqzVsaECgU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJUZcr5AAoJEGUe77AlJ98TzGkP/RVzKKGRJIIhSAGOUSwTvF+g VDMO9/8G5eAgob5njG3LDyYhZ8+ni2kMfLqsQZArz8JNocAEF8I2M6UmahQdBDFg X6Wqiyp4rOaz4NHofDgibkRMlBzgh9/YhqG2oyL090t2MlsP3t27jdkJUoKN2e6C zCopo250Pn46ZsS3cSDu1vD3MTZMucrUzSbbo9aZQ4nNTQ5BtL7RQCtJCCQGosy1 W2hJqkIIRaRC3ruCN2dbuK+dBkZWgBJBzdTQd50FTSUzNAXJikNADoTxxtMYn5d9 H5pfMPzOPZWxmOAP1DG9orB90m5Rc/FP4WHUF5KNap1RYgCX0hjW/OR33+LBzznY 3oU61XJinbfI8E7sh4eJB+ThHahHBYnBvvhvo8FvnemsTGD26VPV+z89vcNi3dR9 cfMa6V3J7BZmDX0asvMbIQ5Vb46l/jC/vG4i7kMC3eWPQWeBY30/jhJatdcoqCH+ b5FsnjuH19z8bSK87V1WT1FhPd1PmFMjmIiaciKxffB3H5VFIBG1L/2vRAEq6LUo 4sPn8VvUNToWBva0Az1fLwTfZ0LsSIr/uMUWkT0eLLJH+y+spJC426t0BrsEnD0L qHYCuGW02JvYDN/9KzJvdBdOwl3Can7vLjr9i1AiDBnJ/JQdscHjAaeRbtrgPCrW AqkswiV6mRP2JWCK5K15 =3R3n -----END PGP SIGNATURE----- --a7XSrSxqzVsaECgU-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 14 09:35:14 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1001CB2B; Fri, 14 Nov 2014 09:35:14 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8BDEAB04; Fri, 14 Nov 2014 09:35:13 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sAE9Z4Ao025491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Nov 2014 11:35:04 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sAE9Z4Ao025491 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sAE9Z3cB025486; Fri, 14 Nov 2014 11:35:03 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 14 Nov 2014 11:35:03 +0200 From: Konstantin Belousov To: "Andrey V. Elsukov" Subject: Re: CFR: AES-GCM and OpenCrypto work review Message-ID: <20141114093503.GC17068@kib.kiev.ua> References: <20141108042300.GA24601@funkthat.com> <54655257.8080705@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54655257.8080705@yandex.ru> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-security@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 14 Nov 2014 09:35:14 -0000 On Fri, Nov 14, 2014 at 03:52:39AM +0300, Andrey V. Elsukov wrote: > On 08.11.2014 07:23, John-Mark Gurney wrote: > > Hello, > > > > Over the last few months, I've been working on a project to add support > > for AES-GCM and AES-CTR modes to our OpenCrypto framework. The work is > > sponsored by The FreeBSD Foundation and Netgate. > > > > I plan on committing these patches early next week. If you need more > > time for review, please email me privately and I will make delay. > > > > The code has already been reviewed by Watson Ladd (the software crypto > > implementations) and Trevor Perrin (the aesni module part) and I have > > integrated these changes into the patch. > > > > There are two patches, one is the changes for OpenCrypto and the test > > framework. The other is the data files used by the test framework. > > The data is from NIST's CAVP program, and is about 20MB worth of test > > vectors. (I just realized, should we look at compressing these on > > disk?) > > > > Main patch (192KB): > > https://www.funkthat.com/~jmg/patches/aes.ipsec.5.patch > > > > Data files (~20MB): > > https://www.funkthat.com/~jmg/patches/aes.ipsec.5.testing.patch > > > > A list of notable changes in the patch: > > - Replacing crypto(4) w/ NetBSD's version + updates > > - Lots of man page updates, including CIOCFINDDEV and crypto(7) which > > adds specifics about restrictions on the modes. > > - Allow sane useage of both _HARDWARE and _SOFTWARE flags. > > - Add a timing safe bcmp for MAC comparision. > > - Add a software implementation of GCM that uses a four bit lookup > > table with parallelization. This algorithm is possibly vulnerable to > > timing attacks, but best known mitigation methods are used. Using > > a timing safe version is many times slower. > > - Added a CRYPTDEB macro that defaults to off. > > - Bring in some of OpenBSD's improvements to the OpenCrypto framework. > > - If an mbuf passed to the aesni module is only one segment, don't do > > a copy. This needs to be improved to support segmented buffers. > > - Remove the CRYPTO_F_REL flag. It was meaningless. It was used but > > did not change any behavior. > > - Add function crypto_mbuftoiov to convert an mbuf to an iov. This > > also converts the software crypto to only use iov's even for a simple > > linear buffer, and so simplifies the processing. > > - Add a dtrace probe for errors from the ioctl. > > - Add the CIOCCRYPTAEAD ioctl that allows userland processing (testing) > > of AES-GCM and future AEAD modes. > > > > Future improvements: > > - Support IV's longer than 12 bytes for GCM. > > - Make AES-NI support segmented buffers (iov or mbuf) so multisegmented > > inputs don't have to be copied. > > > > I know there are more fixes and future improvements, but can't think of > > them now. > > I tried your patch with my IPv4 forwarding test. When aesni module is > loaded and aes-cbc is used I see growing of `invalid outbound packets` > counter in `netstat -sp ipsec` output. And no packets are forwarded. > Also while testing I got a panic in aesni_encrypt_cbc(). > > atal trap 9: general protection fault while in kernel mode > cpuid = 4; apic id = 04 > instruction pointer = 0x20:0xffffffff80d05c43 > stack pointer = 0x28:0xfffffe00003f7e70 > frame pointer = 0x28:0xfffffe00003f7eb0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 12 (irq286: ix0:que 4) > > The backtrace: > #0 doadump (textdump=276160512) at pcpu.h:219 > #1 0xffffffff80355525 in db_fncall (dummy1=, > dummy2=, dummy3=, > dummy4=) > at /usr/src/sys/ddb/db_command.c:568 > #2 0xffffffff8035520d in db_command (cmd_table=0x0) at > /usr/src/sys/ddb/db_command.c:440 > #3 0xffffffff80354f84 in db_command_loop () at > /usr/src/sys/ddb/db_command.c:493 > #4 0xffffffff80357980 in db_trap (type=, code=0) > at /usr/src/sys/ddb/db_main.c:251 > #5 0xffffffff8095c641 in kdb_trap (type=9, code=0, tf= out>) at /usr/src/sys/kern/subr_kdb.c:654 > #6 0xffffffff80d1edcc in trap_fatal (frame=0xfffffe00003f7dc0, > eva=) at /usr/src/sys/amd64/amd64/trap.c:861 > #7 0xffffffff80d1ea6e in trap (frame=) at > /usr/src/sys/amd64/amd64/trap.c:201 > #8 0xffffffff80d04092 in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:231 > #9 0xffffffff80d05c43 in fpudna () at /usr/src/sys/amd64/amd64/fpu.c:85 > #10 0xffffffff80d1e7ae in trap (frame=) at > /usr/src/sys/amd64/amd64/trap.c:432 > #11 0xffffffff80d04092 in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:231 > #12 0xffffffff8202f96e in aesni_encrypt_cbc (rounds=10, > key_schedule=0xfffff8005603d400, len=3, from=0xfffff8013b0de65a "E", > to=0xfffff8013b0de65a "E", > iv=0xfffff8005603d6d0 "???#??????8???:n???\r??????\f?????????\v") at > /usr/src/sys/modules/aesni/../../crypto/aesni/aesni_wrap.c:63 > #13 0xffffffff820318d0 in aesni_process (dev=, > crp=0xfffff80109f7bc08, hint=) > at /usr/src/sys/modules/aesni/../../crypto/aesni/aesni.c:535 > #14 0xffffffff80b170e9 in crypto_dispatch (crp=0xfffff80109f7bc08) at > /usr/src/sys/opencrypto/crypto.c:807 > #15 0xffffffff80b076d6 in esp_output (m=, > isr=, mp=0x3, skip=, > protoff=) > at /usr/src/sys/netipsec/xform_esp.c:905 > #16 0xffffffff80af7457 in ipsec4_process_packet (m=0xfffff8013b0de600, > isr=, flags=, > tunalready=) > at /usr/src/sys/netipsec/ipsec_output.c:594 > #17 0xffffffff80a4a0db in ip_ipsec_output (m=, > inp=, flags=0xfffffe00003f8494, > error=0xfffffe00003f8490) > at /usr/src/sys/netinet/ip_ipsec.c:332 > #18 0xffffffff80a4b6b9 in ip_output (m=0xfffff8013b0de600, opt= optimized out>, flags=1, imo=, inp=0x0) > at /usr/src/sys/netinet/ip_output.c:476 > #19 0xffffffff80a485eb in ip_forward (m=0xfffff8013b0de600, srcrt= optimized out>) at /usr/src/sys/netinet/ip_input.c:1571 > #20 0xffffffff80a4825e in ip_input (m=0xfffff8013b0de600) at > /usr/src/sys/netinet/ip_input.c:754 > #21 0xffffffff809e7be1 in netisr_dispatch_src (proto= out>, source=, m=0xfffff8013b0de65a) at > /usr/src/sys/net/netisr.c:968 > #22 0xffffffff809dfb53 in ether_demux (ifp=, > m=0xfffff8013b0de600) at /usr/src/sys/net/if_ethersubr.c:766 > #23 0xffffffff809e0758 in ether_nh_input (m=) at > /usr/src/sys/net/if_ethersubr.c:573 > #24 0xffffffff809e7be1 in netisr_dispatch_src (proto= out>, source=, m=0xfffff8013b0de65a) at > /usr/src/sys/net/netisr.c:968 > #25 0xffffffff809dfdb6 in ether_input (ifp=, m=0x0) > at /usr/src/sys/net/if_ethersubr.c:674 > #26 0xffffffff809e55e5 in vlan_input (ifp=0xfffff8000ef3e800, m= optimized out>) at /usr/src/sys/net/if_vlan.c:1239 > #27 0xffffffff809dfac4 in ether_demux (ifp=0xfffff8000ef3e800, > m=0xfffff8013b0de600) at /usr/src/sys/net/if_ethersubr.c:717 > #28 0xffffffff809e0758 in ether_nh_input (m=) at > /usr/src/sys/net/if_ethersubr.c:573 > #29 0xffffffff809e7be1 in netisr_dispatch_src (proto= out>, source=, m=0xfffff8013b0de65a) at > /usr/src/sys/net/netisr.c:968 > #30 0xffffffff809dfdb6 in ether_input (ifp=, m=0x0) > at /usr/src/sys/net/if_ethersubr.c:674 > #31 0xffffffff8059f303 in ixgbe_rxeof (que=0xfffff8000ef5c1a0) at > /usr/src/sys/dev/ixgbe/ixgbe.c:4530 > Is the backtrace above full ? ixgbe_rxeof() cannot be the top frame, there must be a caller above it. Does this happen in interrupt thread ? Out of curiosity, can you do p *td and p *(td->td_pcb) for the paniced thread ? From owner-freebsd-current@FreeBSD.ORG Fri Nov 14 12:06:13 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B15DB7B2; Fri, 14 Nov 2014 12:06:13 +0000 (UTC) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 65FAEC1E; Fri, 14 Nov 2014 12:06:13 +0000 (UTC) Received: by mail-yk0-f178.google.com with SMTP id 20so922523yks.23 for ; Fri, 14 Nov 2014 04:06:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nRoS1orkEfpRzT81vwLXPDdkt+O7irQNL+9rYVOUUps=; b=QA0OYY8Ovn/9O8Uq2PKMefzAe+frT5rjXn/qNdRdHmslcD71sOoDT1xmFCbBRc2JtH Y/wFMPC0BhJ7fLl8WKkIP0fRXl46Zczox42PAXuUSBGZ8aiZp9gUBbcOO2HPs64xTH+R UwfGzrCMWgzevmNbwY7re4OVMbK3OROfYeK8jYStWl4Xb1Zb3hq5qbMbO0xt7mEDMMBT 5nc5znlw46KtD4AF/UWczYmdzw+70u6EooR6dfY0tLFEB/wErFypj6Khv++I3pxscfYd bVI+ZLYSWT2bKLGgyE0ugjpSB6v8jKoBRcqVNGnuxXhyfN+zLt0M3U15JFuNp71/F2v3 NxOQ== MIME-Version: 1.0 X-Received: by 10.236.2.170 with SMTP id 30mr9330901yhf.122.1415966772530; Fri, 14 Nov 2014 04:06:12 -0800 (PST) Received: by 10.170.84.133 with HTTP; Fri, 14 Nov 2014 04:06:12 -0800 (PST) In-Reply-To: References: <2FA736F4-8D06-4BBC-81DC-3E3A646BD391@me.com> <20141114092726.GH3196@straylight.m.ringlet.net> Date: Fri, 14 Nov 2014 04:06:12 -0800 Message-ID: Subject: Re: comments on code-in tasks for FreeBSD (Re: FreeBSD + Google Code-In 2014 = we need ideas.) From: Mehmet Erol Sanliturk To: Mark Saad Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Alan Somers , Rui Paulo , "freebsd-hackers@freebsd.org" , "Wojciech A. Koszek" , FreeBSD CURRENT , Peter Pentchev , Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 14 Nov 2014 12:06:13 -0000 On Fri, Nov 14, 2014 at 3:38 AM, Mark Saad wrote: > > > > On Nov 14, 2014, at 4:27 AM, Peter Pentchev wrote: > > > >> On Thu, Nov 13, 2014 at 07:55:16PM -0800, Rui Paulo wrote: > >>> On Nov 13, 2014, at 17:40, Luigi Rizzo wrote: > >>> But please nuke the current list -- it is completely inadequate > >>> for the code-in candidates and misleading for whoever wants to > >>> suggest new tasks. Again i am not saying that the projects > >>> suggested there are not important, just belong somewhere else > >>> e.g. gsoc. > >> > > I have a few ideas for younger and or less experienced google code in > people > > 1. Analyze the CD/USB install process . > Does the actual process match the guide and or general docs . > > 2. Analyze / comment on the automated install process "jumpstart ". Does > the guide and general docs match the actual process . > > 3. Test the virtual machine images as vagrant box images , and create > vagrant box images from the official vm images . > > 4. Create a script for the installer "bsd install" to use glabel to label > gparts slices as /dev/label/$NAME > > 5. Test the ami images , again can the docs be improved are they accurate . > > The > > Now let me preface the docs tasks , by no means am I saying that the docs > team has made lots of mistakes and their work needs to be rechecked . The > tasks are small enough that most high school aged people could grasp the > issue, with out any prior experience in BSD world . Rechecking the docs is > always a good idea . > > They should allow the code in members to make some good contributions ; > and maybe even some good improvements . > > >> I refrained from voicing my opinion while the call for help was going > >> on, but I completely agree that the target age of this Google initiative > >> is inadequate to FreeBSD. The target population is 13 years to 17 years > >> old and I cannot even imagine a 13 year old knowing what FreeBSD is. > > > > ...and yet there was pat@ becoming a ports committer at the age of 16 > > and chris@ becoming a docs committer at the age of 14 :) I think hmp@, > > alepulver@, issyl0@ and jmallett@ were pretty young when they joined, > > too. > > > > Just an observation, I know that one or two isolated cases do not prove > > a point :) > > > > G'luck, > > Peter > > > > -- > > Peter Pentchev roam@ringlet.net roam@FreeBSD.org p.penchev@storpool.com > > PGP key: http://people.FreeBSD.org/~roam/roam.key.asc > > Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 > > Mark saad | mark.saad@longcount.org > One important program class for the less experienced people ( as users and programmers ) would be the following : (1) For the command line operating system programs , mostly it is necessary to give parameters on command line . For example : $ ifconfig displays the NIC information . To apply some operations , it is necessary to give parameters : $ ifconfig -... ... .... ... ... To give these parameters even by using man pages are very difficult even for the experienced users . Task : By using for selected OS programs , write a routine to the following : When a user enters only program name , display a form to get parameters for execution ( this requires some changes to programs doing operations just by giving its name by specifying a parameter for such cases ) in such a way that get parameters in an order by supplying form parts with respect to previously given parameter values , i.e. , do not present all of the items , let the user some values , and smash the user that such parameters are given incorrectly . Manual pages may be used , but sometimes it is necessary to read the source code of the program to isolate error cases and dependencies . (2) Some programs may use many parameters and every time giving them as command line parameters or by filling forms may not be a very convenient way . By using Expat libraries ( or any other suitable library ) , write a routine for a selected command line program to enter parameters from an XML file with the following structure : $ program_name @XML_parameters file_name Such a result may be obtained by using scripts for executing the programs with specific parameters , but using the above structure may be more convenient usage and they may be used in testing also more easily because some files may be output of other programs . (3) Many OS programs are given their outputs in an arbitrary text form . For automated tests , or input to other programs , these outputs are very difficult to use . For selected OS programs , give all of the output in XML ( or any other selected structured form ) .which they can be processed by using Expat library . To process these outputs , also write a routine by using Expat library to load it into a tree . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Fri Nov 14 03:55:31 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0A552EBC; Fri, 14 Nov 2014 03:55:31 +0000 (UTC) Received: from st11p02mm-asmtp002.mac.com (st11p02mm-asmtp002.mac.com [17.172.220.237]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D100A6C9; Fri, 14 Nov 2014 03:55:30 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NF0002AIG850V70@st11p02mm-asmtp002.mac.com>; Fri, 14 Nov 2014 03:55:19 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.28,0.0.0000 definitions=2014-11-14_01:2014-11-14,2014-11-13,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1411140033 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: comments on code-in tasks for FreeBSD (Re: FreeBSD + Google Code-In 2014 = we need ideas.) From: Rui Paulo In-reply-to: Date: Thu, 13 Nov 2014 19:55:16 -0800 Content-transfer-encoding: quoted-printable Message-id: <2FA736F4-8D06-4BBC-81DC-3E3A646BD391@me.com> References: To: Luigi Rizzo X-Mailer: Apple Mail (2.1990.1) X-Mailman-Approved-At: Fri, 14 Nov 2014 12:18:50 +0000 Cc: "freebsd-hackers@freebsd.org" , FreeBSD CURRENT , "Wojciech A. Koszek" , Alan Somers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 14 Nov 2014 03:55:31 -0000 On Nov 13, 2014, at 17:40, Luigi Rizzo wrote: > But please nuke the current list -- it is completely inadequate > for the code-in candidates and misleading for whoever wants to > suggest new tasks. Again i am not saying that the projects > suggested there are not important, just belong somewhere else > e.g. gsoc. I refrained from voicing my opinion while the call for help was going = on, but I completely agree that the target age of this Google initiative = is inadequate to FreeBSD. The target population is 13 years to 17 years = old and I cannot even imagine a 13 year old knowing what FreeBSD is. I'm not sure we should participate in Code In ever again and perhaps we = should focus our efforts on Summer of Code only. -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Fri Nov 14 11:43:56 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 823CFDA0 for ; Fri, 14 Nov 2014 11:43:56 +0000 (UTC) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3AFD0A01 for ; Fri, 14 Nov 2014 11:43:55 +0000 (UTC) Received: by mail-qg0-f48.google.com with SMTP id q108so11644160qgd.7 for ; Fri, 14 Nov 2014 03:43:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=un6M/jZg61JE1Rv3LFgN1u+cC6AJQJEoJqOivCN7Xv0=; b=aFKG9tNu9my0aiGm3soHgBwQO20P6GEw+Dohrwj4Wr0sFSkKLYIiS1CqgXkPoS1UYL DaN9ouKxbBloU+cnkv/nlgCh2mwUyngYDUU5Q1A2CF1hDmz9h2EHf9SRTk7Aw57lr8jX K+u8Rvqr8lTST9fA4srWOJQrfFr5ByHlp4RC/XpEX+x9QRvWvXCLg+dbsGnT9+O38viG zN+zN7OIdjkc4z7FPez11lWxj32iLqBIm2ERN5UDoYrdILHzm/BDgBR6+PNKUHA0BovK cJjoG4JycmmnlL3d+5v3vltn+HXcN8R4baAvsiRkA7Z5GCo5N1FSOwcFj4nhQKC5BUWa tmMw== X-Gm-Message-State: ALoCoQmNJKpcXvJ9PNOryYCSmOcYDwHdmsol0oraZ7Q25eHALSkNd64q9RGdbrDSgS6GjWYWOoIf X-Received: by 10.140.40.239 with SMTP id x102mr10511565qgx.69.1415965105573; Fri, 14 Nov 2014 03:38:25 -0800 (PST) Received: from [192.168.2.20] (ool-4351fb93.dyn.optonline.net. [67.81.251.147]) by mx.google.com with ESMTPSA id q90sm26623687qgd.4.2014.11.14.03.38.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Nov 2014 03:38:24 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: comments on code-in tasks for FreeBSD (Re: FreeBSD + Google Code-In 2014 = we need ideas.) From: Mark Saad X-Mailer: iPhone Mail (12B411) In-Reply-To: <20141114092726.GH3196@straylight.m.ringlet.net> Date: Fri, 14 Nov 2014 06:38:20 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2FA736F4-8D06-4BBC-81DC-3E3A646BD391@me.com> <20141114092726.GH3196@straylight.m.ringlet.net> To: Peter Pentchev X-Mailman-Approved-At: Fri, 14 Nov 2014 12:59:18 +0000 Cc: Alan Somers , Rui Paulo , "freebsd-hackers@freebsd.org" , "Wojciech A. Koszek" , FreeBSD CURRENT , Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 14 Nov 2014 11:43:56 -0000 > On Nov 14, 2014, at 4:27 AM, Peter Pentchev wrote: >=20 >> On Thu, Nov 13, 2014 at 07:55:16PM -0800, Rui Paulo wrote: >>> On Nov 13, 2014, at 17:40, Luigi Rizzo wrote: >>> But please nuke the current list -- it is completely inadequate >>> for the code-in candidates and misleading for whoever wants to >>> suggest new tasks. Again i am not saying that the projects >>> suggested there are not important, just belong somewhere else >>> e.g. gsoc. >>=20 I have a few ideas for younger and or less experienced google code in people= 1. Analyze the CD/USB install process .=20 Does the actual process match the guide and or general docs .=20 2. Analyze / comment on the automated install process "jumpstart ". Does the= guide and general docs match the actual process . 3. Test the virtual machine images as vagrant box images , and create vagran= t box images from the official vm images .=20 4. Create a script for the installer "bsd install" to use glabel to label gp= arts slices as /dev/label/$NAME=20 5. Test the ami images , again can the docs be improved are they accurate . The=20 Now let me preface the docs tasks , by no means am I saying that the docs te= am has made lots of mistakes and their work needs to be rechecked . The task= s are small enough that most high school aged people could grasp the issue, w= ith out any prior experience in BSD world . Rechecking the docs is always a g= ood idea .=20 They should allow the code in members to make some good contributions ; and m= aybe even some good improvements .=20 >> I refrained from voicing my opinion while the call for help was going >> on, but I completely agree that the target age of this Google initiative >> is inadequate to FreeBSD. The target population is 13 years to 17 years >> old and I cannot even imagine a 13 year old knowing what FreeBSD is. >=20 > ...and yet there was pat@ becoming a ports committer at the age of 16 > and chris@ becoming a docs committer at the age of 14 :) I think hmp@, > alepulver@, issyl0@ and jmallett@ were pretty young when they joined, > too. >=20 > Just an observation, I know that one or two isolated cases do not prove > a point :) >=20 > G'luck, > Peter >=20 > --=20 > Peter Pentchev roam@ringlet.net roam@FreeBSD.org p.penchev@storpool.com > PGP key: http://people.FreeBSD.org/~roam/roam.key.asc > Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 Mark saad | mark.saad@longcount.org=20= From owner-freebsd-current@FreeBSD.ORG Fri Nov 14 13:29:07 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9EBC4C35; Fri, 14 Nov 2014 13:29:07 +0000 (UTC) Received: from forward6l.mail.yandex.net (forward6l.mail.yandex.net [IPv6:2a02:6b8:0:1819::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 31508693; Fri, 14 Nov 2014 13:29:07 +0000 (UTC) Received: from smtp11.mail.yandex.net (smtp11.mail.yandex.net [95.108.130.67]) by forward6l.mail.yandex.net (Yandex) with ESMTP id 76CAF14E12B0; Fri, 14 Nov 2014 16:29:03 +0300 (MSK) Received: from smtp11.mail.yandex.net (localhost [127.0.0.1]) by smtp11.mail.yandex.net (Yandex) with ESMTP id E1B8B7E0A61; Fri, 14 Nov 2014 16:29:02 +0300 (MSK) Received: from 84.201.167.97-vpn.dhcp.yndx.net (84.201.167.97-vpn.dhcp.yndx.net [84.201.167.97]) by smtp11.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id J3REum5P3h-T2IuvCLl; Fri, 14 Nov 2014 16:29:02 +0300 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 5b7dc64c-f415-4133-84fc-460847e6c6a6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1415971742; bh=ggonNKHdkQhTMtFZBTq756Rut8VHredgrFzfnRVVeDg=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type; b=HUEZ7DCDYExpy7pT99vsise5MPdN2oAhO7xz7YQhjJIJcd0D2Al/Jm1QaOv3TEWWE opG011iWQFWqJ/5mm9kWzCuiQZs5vnLT21+Fa4zK1tmSvjNc57mEykawrI5a8LrKwX m4iL3N0Mo3/vK6renb+sD5GP4AHqR7w259JnBvNA= Authentication-Results: smtp11.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <54660389.9060409@yandex.ru> Date: Fri, 14 Nov 2014 16:28:41 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-security@FreeBSD.org, current@FreeBSD.org, John-Mark Gurney Subject: Re: CFR: AES-GCM and OpenCrypto work review References: <20141108042300.GA24601@funkthat.com> <54655257.8080705@yandex.ru> In-Reply-To: <54655257.8080705@yandex.ru> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tfN0oppBAS2no0GJKJEj0DM2SNr8NICgn" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 14 Nov 2014 13:29:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tfN0oppBAS2no0GJKJEj0DM2SNr8NICgn Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 14.11.2014 03:52, Andrey V. Elsukov wrote: > I tried your patch with my IPv4 forwarding test. When aesni module is > loaded and aes-cbc is used I see growing of `invalid outbound packets` > counter in `netstat -sp ipsec` output. And no packets are forwarded. > Also while testing I got a panic in aesni_encrypt_cbc(). >=20 > atal trap 9: general protection fault while in kernel mode > cpuid =3D 4; apic id =3D 04 > instruction pointer =3D 0x20:0xffffffff80d05c43 > stack pointer =3D 0x28:0xfffffe00003f7e70 > frame pointer =3D 0x28:0xfffffe00003f7eb0 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 12 (irq286: ix0:que 4) >=20 The full backtrace is here: http://paste.org.ru/?a3f8pw Screenshot from ddb: http://i.imgur.com/H5mbVi8.png?1 Also I noticed that on higher packet rate sometimes kernel reports about wrong source route attempts: kernel: attempted source route from 244.116.138.102 to 225.51.107.139 kernel: attempted source route from 19.120.181.94 to 238.17.74.139 kernel: attempted source route from 186.217.142.184 to 233.165.4.102 kernel: attempted source route from 134.41.78.248 to 231.122.242.144 probably there is mbuf's memory corruption somewhere. --=20 WBR, Andrey V. Elsukov --tfN0oppBAS2no0GJKJEj0DM2SNr8NICgn 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 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJUZgONAAoJEAHF6gQQyKF67yYIAISKqHBxmAfFipC3BBq97KkE hS+UanK9G9UTYh+4BOcxUs35eRV/gOtB1oVPe3OnlTHyvtLmDE0intWuDHLNQYlG fzhxPi3kREAE9K/EINBHguaWLq0PePtWj9HUyx4vhRcvEwjg1sBKgfdLGOILDDQY /1TyyMTa7B4Jnh6/8hfmjlRzbXGhAO2clhAA8S93oBSafyNsxs6hTn7M3UAzdrcp dcJbVjFMgmADwWLdHoIGDXz06fGN+BttdprTXKELg5iMsI8n5su2tipNfKpXUWF0 yYIWjw++MqjXCfURjTExdp6W8eDMgo9KWZKXWllVSciFQzc3erjRbVS/oieUzSE= =kMbH -----END PGP SIGNATURE----- --tfN0oppBAS2no0GJKJEj0DM2SNr8NICgn-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 14 15:26:05 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 23C06715 for ; Fri, 14 Nov 2014 15:26:05 +0000 (UTC) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) by mx1.freebsd.org (Postfix) with ESMTP id 0002461E for ; Fri, 14 Nov 2014 15:26:04 +0000 (UTC) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 668525A9F0C; Fri, 14 Nov 2014 15:25:58 +0000 (UTC) Date: Fri, 14 Nov 2014 15:25:58 +0000 From: Brooks Davis To: Beeblebrox Subject: Re: Is libLLVM-3.4.so: part of src or not? Message-ID: <20141114152558.GA89825@spindle.one-eyed-alien.net> References: <5465BA4A.8010205@berentweb.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V" Content-Disposition: inline In-Reply-To: <5465BA4A.8010205@berentweb.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 14 Nov 2014 15:26:05 -0000 --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 14, 2014 at 10:16:10AM +0200, Beeblebrox wrote: > When starting Xorg, AIGLX gets disabled and RadeonKMS complains: >=20 > (EE) AIGLX error: dlopen of /usr/local/lib/dri/r600_dri.so failed=20 > (Shared object "libLLVM-3.4.so" n > ot found, required by "r600_dri.so") > (EE) AIGLX: reverting to software rendering > (II) AIGLX: Screen 0 is not DRI capable > (EE) AIGLX error: dlopen of /usr/local/lib/dri/swrast_dri.so failed=20 > (Shared object "libLLVM-3.4.so" > not found, required by "swrast_dri.so") > (EE) GLX: could not load software renderer > (II) GLX: no usable GL providers found for screen 0 >=20 > A search on the system shows libLLVM-3.4.so only exists under=20 > /usr/local/lib32. > I built and installed devel/llvm34, re-started Xorg and the log shows=20 > AIGLX as starting normally (no error). libLLVM doesn't provide a stable interface and is thus not a public part of base. It sounds like there's a missing port depend. -- Brooks --xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlRmHwUACgkQXY6L6fI4GtS9hACgipX0Z16+AGZcHc3+2DdMigYl bKoAnjQhPJQAgx5SdndVPqFmSKMEsGjG =6r5U -----END PGP SIGNATURE----- --xHFwDpU9dbj6ez1V-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 14 16:42:56 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD770327; Fri, 14 Nov 2014 16:42:56 +0000 (UTC) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 96712FE9; Fri, 14 Nov 2014 16:42:56 +0000 (UTC) Received: by mail-qg0-f54.google.com with SMTP id q108so12063446qgd.41 for ; Fri, 14 Nov 2014 08:42:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=byIMqcljzdz8k7InB8UEMf+uL8S8dsWs0DjXIqw7Jec=; b=ZgrwoiKkQCuw9p8x/Qy/Nt9VuViFLSgaE8zBKHiVMwGDfPuPcYFlFy4tgMEw7pxc0v eowXK4FF5NZsNyBLn5yUvsmFjFqOc7D4SXOYC47swGKbct0TvMe8GPBmTZ+577cNzOtV +7oBacK0QhUXCoHciscdtAArRFH84v0LuCCtnA5ZewFV7VchCxC+N9WS4JuABhHbqrHL RDCjl7T2v8xoQwLdOSSQYyTxQo5HmqbPAwXS6IEWN5BreO0Ix1gBFbi9jE1GvlMiunfg MTXF72uE6tEgtxWTTSzTPnbPErBabUkCLlJroyJGsT/fDbn+lQGN1ZHfxjOU91iU3dYQ FCvA== MIME-Version: 1.0 X-Received: by 10.140.40.104 with SMTP id w95mr12730280qgw.14.1415983375438; Fri, 14 Nov 2014 08:42:55 -0800 (PST) Received: by 10.96.169.229 with HTTP; Fri, 14 Nov 2014 08:42:55 -0800 (PST) In-Reply-To: References: Date: Fri, 14 Nov 2014 17:42:55 +0100 Message-ID: Subject: Re: "geli: Wrong key" with a simple passphrase. Doesn't handle the keyboard input From: Aurelien Martin <01aurelien@gmail.com> To: freebsd-geom@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 14 Nov 2014 16:42:57 -0000 Hi all, Is there people that can try to geli an external USB disk with a simple passphrase on CURRENT and tell me if the passphrase prompt shown the input, and if it's possible to attach it ? Cheers,Aurelien -------- # uname -a FreeBSD 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r271779: Fri Sep 19 01:18:53 UTC 2014 root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI- B arm #kldstat 2 1 0xc2e49000 17000 geom_eli.ko 3 1 0xc2e60000 2a000 crypto.ko # sysctl kern.geom.eli.visible_passphrase=1 kern.geom.eli.visible_passphrase: 0 -> 1 #### Nothing print in the prompt #### # geli init da0 Enter new passphrase: Reenter new passphrase: #### Impossible to attach the device with a simple passphrase. Tried 20x #### geli attach da0 Enter passphrase: geli: Wrong key for da0 2014-11-08 21:26 GMT+01:00 Aurelien Martin <01aurelien@gmail.com>: > Dear all, > > I tried to geli my external USB drive da0 with a simple passphrase > But I'm getting "Wrong key for da0" when I want to attach it. > geli seems not to handle my keyboard input when I type my password. > > Let me know if I have forgot a step. > > Cheers,Aurelien > > Log > -- > > # uname -a > FreeBSD 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r271779: Fri Sep 19 01:18:53 > UTC 2014 root@grind.freebsd.org:/usr/ > obj/arm.armv6/usr/src/sys/RPI-B arm > > # sysctl kern.geom.eli.visible_passphrase=1 > kern.geom.eli.visible_passphrase: 0 -> 1 > > > What I have done : > The prompt doesn't handle my keyboard input, nothing printed > > # geli init da0 > Enter new passphrase: > Reenter new passphrase: > Metadata backup can be found in /var/backups/da0.eli and > ... > > # geli attach da0 > Enter passphrase: > geli: Wrong key for da0. > > > # cat /var/backups/da0.eli | hexdump -c | head -1 > 0000000 G E O M : : E L I \0 \0 \0 \0 \0 \0 \0 > From owner-freebsd-current@FreeBSD.ORG Fri Nov 14 17:23:48 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 971FAC85; Fri, 14 Nov 2014 17:23:48 +0000 (UTC) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 54325667; Fri, 14 Nov 2014 17:23:47 +0000 (UTC) Received: from [78.35.185.39] (helo=fabiankeil.de) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1XpKaw-0002zB-EC; Fri, 14 Nov 2014 18:23:38 +0100 Date: Fri, 14 Nov 2014 18:23:39 +0100 From: Fabian Keil To: Aurelien Martin <01aurelien@gmail.com> Subject: Re: "geli: Wrong key" with a simple passphrase. Doesn't handle the keyboard input Message-ID: <39ecf88b.74b1cd08@fabiankeil.de> In-Reply-To: References: Reply-To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/iygbGWC1EkNxlCl_vFnSMJH"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: freebsd-current@freebsd.org, freebsd-geom@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 14 Nov 2014 17:23:48 -0000 --Sig_/iygbGWC1EkNxlCl_vFnSMJH Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Aurelien Martin <01aurelien@gmail.com> wrote: > Is there people that can try to geli an external USB disk with a simple > passphrase on CURRENT and tell me if the passphrase prompt shown the inpu= t, > and if it's possible to attach it ? > -------- > # uname -a > FreeBSD 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r271779: Fri Sep 19 01:18:53 > UTC 2014 root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI- > B arm >=20 > #kldstat > 2 1 0xc2e49000 17000 geom_eli.ko > 3 1 0xc2e60000 2a000 crypto.ko >=20 >=20 > # sysctl kern.geom.eli.visible_passphrase=3D1 > kern.geom.eli.visible_passphrase: 0 -> 1 >=20 > #### Nothing print in the prompt #### >=20 > # geli init da0 > Enter new passphrase: > Reenter new passphrase: The sysctl only applies to the kernel, geli(8) doesn't use it. > #### Impossible to attach the device with a simple passphrase. Tried 20x > #### > geli attach da0 > Enter passphrase: > geli: Wrong key for da0 "geli attach" works for me on 11-CURRENT amd64, maybe it's an arm issue. Fabian --Sig_/iygbGWC1EkNxlCl_vFnSMJH Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRmOpsACgkQBYqIVf93VJ19ewCePNLVr7l7qauKS4cSN8eb9Lio paIAnRzzAIZ+3WM/Hb26QWaxW4+PTPWe =Bu3B -----END PGP SIGNATURE----- --Sig_/iygbGWC1EkNxlCl_vFnSMJH-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 14 17:35:10 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 438DB333; Fri, 14 Nov 2014 17:35:10 +0000 (UTC) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EFABF7E9; Fri, 14 Nov 2014 17:35:09 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id n8so11769372qaq.26 for ; Fri, 14 Nov 2014 09:35:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ITjce8AayyeAsMuX+iWNq9BcRCpauyOsCuEXdN/yyVI=; b=HK6k24/6btosza6oAhKu9VRnNqYEy+E+kVuDLwX641OPeKmAbVN/Xogg6AfyAdI0O5 v3bwy0Ae3Rv5YL6ccWKe/hSKnsYYMwjqJ7TK5JdQXoYbuzZCx6pwBqnkuf7vR+7tWPoJ AmI9xfJBG4B9F+I3aabHCPBIpb5x3LiKeeJK0bCcKFA7F4TWFnRpwSh2cSnT7yjNQIgZ qazHYz/Ph/kYVwvfWs0Fz8R9BpHdv1B341eIbiQgU5RHRUINN6ZtOOQ9jXtyZFN9W2XE CGcl4Nt/qFtgnsupuF1H7sNsb6RTBN82gp5ThmMJSmu5UPvK9lv7rVdLcxnstQgMCZez /yFw== MIME-Version: 1.0 X-Received: by 10.224.122.80 with SMTP id k16mr7357676qar.40.1415986509164; Fri, 14 Nov 2014 09:35:09 -0800 (PST) Received: by 10.96.169.229 with HTTP; Fri, 14 Nov 2014 09:35:09 -0800 (PST) In-Reply-To: <39ecf88b.74b1cd08@fabiankeil.de> References: <39ecf88b.74b1cd08@fabiankeil.de> Date: Fri, 14 Nov 2014 18:35:09 +0100 Message-ID: Subject: Re: "geli: Wrong key" with a simple passphrase. Doesn't handle the keyboard input From: Aurelien Martin <01aurelien@gmail.com> To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-arm@freebsd.org, freebsd-geom@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 14 Nov 2014 17:35:10 -0000 Many thanks Fabian for your feedbacks ! @freebsd-arm users: Can someone try to "geli init" and "geli attach" an USB external drive ? Cheers,Aurelien 2014-11-14 18:23 GMT+01:00 Fabian Keil : > Aurelien Martin <01aurelien@gmail.com> wrote: > > > Is there people that can try to geli an external USB disk with a simple > > passphrase on CURRENT and tell me if the passphrase prompt shown the > input, > > and if it's possible to attach it ? > > -------- > > # uname -a > > FreeBSD 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r271779: Fri Sep 19 > 01:18:53 > > UTC 2014 root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI- > > B arm > > > > #kldstat > > 2 1 0xc2e49000 17000 geom_eli.ko > > 3 1 0xc2e60000 2a000 crypto.ko > > > > > > # sysctl kern.geom.eli.visible_passphrase=1 > > kern.geom.eli.visible_passphrase: 0 -> 1 > > > > #### Nothing print in the prompt #### > > > > # geli init da0 > > Enter new passphrase: > > Reenter new passphrase: > > The sysctl only applies to the kernel, geli(8) doesn't use it. > > > #### Impossible to attach the device with a simple passphrase. Tried 20x > > #### > > geli attach da0 > > Enter passphrase: > > geli: Wrong key for da0 > > "geli attach" works for me on 11-CURRENT amd64, maybe it's an arm issue. > > Fabian > From owner-freebsd-current@FreeBSD.ORG Fri Nov 14 19:39:14 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07FE9B0D; Fri, 14 Nov 2014 19:39:14 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B298D7EB; Fri, 14 Nov 2014 19:39:13 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sAEJdBMB063368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Nov 2014 11:39:12 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAEJdBD2063367; Fri, 14 Nov 2014 11:39:11 -0800 (PST) (envelope-from jmg) Date: Fri, 14 Nov 2014 11:39:11 -0800 From: John-Mark Gurney To: "Andrey V. Elsukov" Subject: Re: CFR: AES-GCM and OpenCrypto work review Message-ID: <20141114193911.GR24601@funkthat.com> Mail-Followup-To: "Andrey V. Elsukov" , freebsd-security@FreeBSD.org, current@FreeBSD.org References: <20141108042300.GA24601@funkthat.com> <54655257.8080705@yandex.ru> <54660389.9060409@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54660389.9060409@yandex.ru> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 14 Nov 2014 11:39:12 -0800 (PST) Cc: freebsd-security@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 14 Nov 2014 19:39:14 -0000 Andrey V. Elsukov wrote this message on Fri, Nov 14, 2014 at 16:28 +0300: > On 14.11.2014 03:52, Andrey V. Elsukov wrote: > > I tried your patch with my IPv4 forwarding test. When aesni module is > > loaded and aes-cbc is used I see growing of `invalid outbound packets` > > counter in `netstat -sp ipsec` output. And no packets are forwarded. > > Also while testing I got a panic in aesni_encrypt_cbc(). > > > > atal trap 9: general protection fault while in kernel mode > > cpuid = 4; apic id = 04 > > instruction pointer = 0x20:0xffffffff80d05c43 > > stack pointer = 0x28:0xfffffe00003f7e70 > > frame pointer = 0x28:0xfffffe00003f7eb0 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 12 (irq286: ix0:que 4) > > > > The full backtrace is here: http://paste.org.ru/?a3f8pw > Screenshot from ddb: http://i.imgur.com/H5mbVi8.png?1 > Also I noticed that on higher packet rate sometimes kernel reports about > wrong source route attempts: > > kernel: attempted source route from 244.116.138.102 to 225.51.107.139 > kernel: attempted source route from 19.120.181.94 to 238.17.74.139 > kernel: attempted source route from 186.217.142.184 to 233.165.4.102 > kernel: attempted source route from 134.41.78.248 to 231.122.242.144 > > probably there is mbuf's memory corruption somewhere. Well.. It looks like IPSEC is still broken in head... I can get pings to pass, but now on IPv4 transport mode, I can't get syn's to be sent out... I see the output packet in the protocol stats, but no packets go out the interface... If you could provide me w/ a simple set of spdadd commands, or the dumps from the machine, that'd be good... Hmm.... I just ran ping -f so I could generate some traffic, and managed to get a: panic: System call sendto returing with kernel FPU ctx leaked I'll look into this... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Sat Nov 15 02:42:04 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C77BF54E; Sat, 15 Nov 2014 02:42:04 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 87B0B68E; Sat, 15 Nov 2014 02:42:03 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sAF2g1p8068009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Nov 2014 18:42:02 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAF2g1FC068008; Fri, 14 Nov 2014 18:42:01 -0800 (PST) (envelope-from jmg) Date: Fri, 14 Nov 2014 18:42:01 -0800 From: John-Mark Gurney To: "Andrey V. Elsukov" , freebsd-security@FreeBSD.org, current@FreeBSD.org Subject: Re: CFR: AES-GCM and OpenCrypto work review Message-ID: <20141115024201.GW24601@funkthat.com> Mail-Followup-To: "Andrey V. Elsukov" , freebsd-security@FreeBSD.org, current@FreeBSD.org References: <20141108042300.GA24601@funkthat.com> <54655257.8080705@yandex.ru> <54660389.9060409@yandex.ru> <20141114193911.GR24601@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141114193911.GR24601@funkthat.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 14 Nov 2014 18:42:02 -0800 (PST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 15 Nov 2014 02:42:04 -0000 John-Mark Gurney wrote this message on Fri, Nov 14, 2014 at 11:39 -0800: > Well.. It looks like IPSEC is still broken in head... I can get > pings to pass, but now on IPv4 transport mode, I can't get syn's to > be sent out... I see the output packet in the protocol stats, but > no packets go out the interface... > > If you could provide me w/ a simple set of spdadd commands, or the > dumps from the machine, that'd be good... > > Hmm.... I just ran ping -f so I could generate some traffic, and > managed to get a: > panic: System call sendto returing with kernel FPU ctx leaked > > I'll look into this... I just verified that this happens on a clean HEAD @ r274534: FreeBSD 11.0-CURRENT #0 r274534: Fri Nov 14 17:17:10 PST 2014 jmg@carbon.funkthat.com:/scratch/jmg/clean/sys/amd64/compile/IPSEC amd64 No modifications, nothing, and I got the same panic: panic: System call sendto returing with kernel FPU ctx leaked cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001de7a800 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe001de7a8b0 vpanic() at vpanic+0x189/frame 0xfffffe001de7a930 kassert_panic() at kassert_panic+0x139/frame 0xfffffe001de7a9a0 amd64_syscall() at amd64_syscall+0x616/frame 0xfffffe001de7aab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe001de7aab0 --- syscall (64, FreeBSD ELF64, nosys), rip = 0x8011975aa, rsp = 0x7ffffffee588, rbp = 0x7ffffffee5c0 --- KDB: enter: panic So, it's clearly not my patch that is causing the issue... Andrey, can you verify that you do not receive the same panic w/o my patches? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Sat Nov 15 08:48:42 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7DDA22AD; Sat, 15 Nov 2014 08:48:42 +0000 (UTC) Received: from forward8l.mail.yandex.net (forward8l.mail.yandex.net [IPv6:2a02:6b8:0:1819::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 27591C06; Sat, 15 Nov 2014 08:48:41 +0000 (UTC) Received: from smtp19.mail.yandex.net (smtp19.mail.yandex.net [95.108.252.19]) by forward8l.mail.yandex.net (Yandex) with ESMTP id 5C3CF1A4113C; Sat, 15 Nov 2014 11:48:36 +0300 (MSK) Received: from smtp19.mail.yandex.net (localhost [127.0.0.1]) by smtp19.mail.yandex.net (Yandex) with ESMTP id D7FC3BE00E1; Sat, 15 Nov 2014 11:48:35 +0300 (MSK) Received: from 84.201.165.9-vpn.dhcp.yndx.net (84.201.165.9-vpn.dhcp.yndx.net [84.201.165.9]) by smtp19.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id JK53Lvrmrn-mZE4w57u; Sat, 15 Nov 2014 11:48:35 +0300 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: fe6cbe72-41f4-4572-b52f-33c9ebf71ceb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1416041315; bh=S4S9cyEHVMb8+LzhOce0ix6CTyH4Lljfye0DLgzA86k=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type; b=QSiHCOUhgW3hRlEYi1juWO2Qa66zFw+2widFIoGI3+jLXOXR3mZ9fC7JTAS97dVFk 5xI1eEt2EvqV0TjZY8odY45TP4G6nUgwMIBQsSnJXUKxub9VyR+V4y9qkW/NtsVglL MsI9U7ItSpg6xGXOncqfXe/Nz9WZmKXk4if5AVVQ= Authentication-Results: smtp19.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <5467134A.70005@yandex.ru> Date: Sat, 15 Nov 2014 11:48:10 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-security@FreeBSD.org, current@FreeBSD.org Subject: Re: CFR: AES-GCM and OpenCrypto work review References: <20141108042300.GA24601@funkthat.com> <54655257.8080705@yandex.ru> <54660389.9060409@yandex.ru> <20141114193911.GR24601@funkthat.com> <20141115024201.GW24601@funkthat.com> In-Reply-To: <20141115024201.GW24601@funkthat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JHJuh6QQcG1kKIRAJEMv6E6o8teNfe88x" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 15 Nov 2014 08:48:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JHJuh6QQcG1kKIRAJEMv6E6o8teNfe88x Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 15.11.2014 05:42, John-Mark Gurney wrote: > John-Mark Gurney wrote this message on Fri, Nov 14, 2014 at 11:39 > -0800: >> Well.. It looks like IPSEC is still broken in head... I can get=20 >> pings to pass, but now on IPv4 transport mode, I can't get syn's >> to be sent out... I see the output packet in the protocol stats, >> but no packets go out the interface... >>=20 >> If you could provide me w/ a simple set of spdadd commands, or the=20 >> dumps from the machine, that'd be good... >>=20 >> Hmm.... I just ran ping -f so I could generate some traffic, and=20 >> managed to get a: panic: System call sendto returing with kernel >> FPU ctx leaked >>=20 >> I'll look into this... >=20 > I just verified that this happens on a clean HEAD @ r274534: FreeBSD > 11.0-CURRENT #0 r274534: Fri Nov 14 17:17:10 PST 2014=20 > jmg@carbon.funkthat.com:/scratch/jmg/clean/sys/amd64/compile/IPSEC > amd64 >=20 > No modifications, nothing, and I got the same panic: panic: System > call sendto returing with kernel FPU ctx leaked cpuid =3D 0 KDB: stack > backtrace: db_trace_self_wrapper() at > db_trace_self_wrapper+0x2b/frame 0xfffffe001de7a800 kdb_backtrace() > at kdb_backtrace+0x39/frame 0xfffffe001de7a8b0 vpanic() at > vpanic+0x189/frame 0xfffffe001de7a930 kassert_panic() at > kassert_panic+0x139/frame 0xfffffe001de7a9a0 amd64_syscall() at > amd64_syscall+0x616/frame 0xfffffe001de7aab0 Xfast_syscall() at > Xfast_syscall+0xfb/frame 0xfffffe001de7aab0 --- syscall (64, FreeBSD > ELF64, nosys), rip =3D 0x8011975aa, rsp =3D 0x7ffffffee588, rbp =3D > 0x7ffffffee5c0 --- KDB: enter: panic >=20 > So, it's clearly not my patch that is causing the issue... >=20 > Andrey, can you verify that you do not receive the same panic w/o my=20 > patches? 11.0-CURRENT r274469 after 20 minutes and # netstat -sp esp | grep out 424360710 packets out 17823149820 bytes out can't reproduce the panic. I'll update and retry on fresh CURRENT. My ipsec.conf: add 10.9.12.25 10.9.12.15 esp 15701 -E rijndael-cbc "1111111111111111" ; spdadd 192.168.0.0/16 192.168.0.0/16 any -P out ipsec esp/tunnel/10.9.12.25-10.9.12.15/default; aesni.ko is loaded and pmcstat shows that it is in use: PMC: [INSTR_RETIRED_ANY] Samples: 128994 (100.0%) , 7506 unresolved Key: q =3D> exiting... %SAMP IMAGE FUNCTION CALLERS 13.5 kernel cpu_search_highest cpu_search_highest:11.3 sched_idletd:2.2 4.6 kernel __mtx_unlock_flags ip_output:0.8 key_checkrequest:0.6 ip_rtaddr:0.6 key_allocsp:0.5 4.0 kernel __mtx_lock_flags _key_freesp:0.8 rtalloc1_fib:0.8 key_checkrequest:0.6 3.5 kernel cpu_search_lowest cpu_search_lowest:2.6 sched_pickcpu:0.9 3.2 kernel bcopy m_copydata:1.7 m_copyback:0.7 3.2 libc.so.7 bsearch 3.0 kernel __rw_rlock rtalloc1_fib 2.5 kernel uma_zalloc_arg malloc:0.8 crypto_getreq:0.6 2.4 kernel uma_zfree_arg m_freem:1.0 free:0.7 2.2 kernel bzero uma_zalloc_arg 2.1 kernel _rw_runlock_cookie rtalloc1_fib:0.7 arpresolve:0.5 2.0 kernel rn_match rtalloc1_fib 1.7 kernel __mtx_lock_sleep __mtx_lock_flags 1.7 kernel ip_output ipsec_process_done:1.1 ip_forward:0= =2E6 1.4 kernel critical_exit spinlock_exit 1.3 kernel spinlock_exit ether_nh_input 1.3 kernel ixgbe_rxeof ixgbe_msix_que 1.2 kernel malloc 1.2 kernel critical_enter 1.2 kernel ixgbe_xmit ixgbe_mq_start_locked 1.1 aesni.ko aesni_encrypt_cbc aesni_process 1.1 kernel esp_output ipsec4_process_packet 1.1 kernel key_allocsp ipsec_getpolicybyaddr 1.0 kernel __mtx_lock_spin_flag 1.0 kernel in_cksumdata in_cksum_skip 1.0 kernel free 1.0 kernel ip_input netisr_dispatch_src 1.0 kernel ether_nh_input netisr_dispatch_src 1.0 kernel bounce_bus_dmamap_lo bus_dmamap_load_mbuf_sg 0.9 kernel _mtx_lock_spin_cooki pmclog_reserve 0.8 kernel m_copydata 0.8 kernel ipsec4_process_packe ip_ipsec_output --=20 WBR, Andrey V. Elsukov --JHJuh6QQcG1kKIRAJEMv6E6o8teNfe88x 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 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJUZxNQAAoJEAHF6gQQyKF6fukIAJ35XlpYwXLQnEBxOGIJJtZa wW36xLPzUFEBmDjwJHgWyIUM0nYaKPJF97ehzJbQoI5XPo/iqPP27/YdcLKcVDmu hUGY/dAZwZKHw7LMa17yKw7MHQQ123wtZ/k8kWBjxXi5aqUuvOFOBzYWyOvqlPgk lB2aX9TZP+5lSgL9LSxef7LDYXvIm7Mr4UAOn1OAuTQm+NqvlpG9M/yH8LCB7jhV h/dEWjb5Xs+pQBxvK5Uhi/sn23+NeRlV5Az5wRyja6pobzPYBU5DWrI5LD3ZZyvd CpXojg+vzu8wKjyr8LcWGzwhx6kybfHObuFOtUYZlHGsXrIuk5VJ90Q2VnNs6tA= =Zivg -----END PGP SIGNATURE----- --JHJuh6QQcG1kKIRAJEMv6E6o8teNfe88x-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 15 12:19:34 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D9299F8F; Sat, 15 Nov 2014 12:19:33 +0000 (UTC) Received: from forward7l.mail.yandex.net (forward7l.mail.yandex.net [IPv6:2a02:6b8:0:1819::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6BC6FE2; Sat, 15 Nov 2014 12:19:33 +0000 (UTC) Received: from smtp16.mail.yandex.net (smtp16.mail.yandex.net [95.108.252.16]) by forward7l.mail.yandex.net (Yandex) with ESMTP id 73D0CBC0E74; Sat, 15 Nov 2014 15:19:29 +0300 (MSK) Received: from smtp16.mail.yandex.net (localhost [127.0.0.1]) by smtp16.mail.yandex.net (Yandex) with ESMTP id F16136A028D; Sat, 15 Nov 2014 15:19:28 +0300 (MSK) Received: from 84.201.165.9-vpn.dhcp.yndx.net (84.201.165.9-vpn.dhcp.yndx.net [84.201.165.9]) by smtp16.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id Ldq4u59ykF-JSUCPPZ3; Sat, 15 Nov 2014 15:19:28 +0300 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 35d83053-a040-4695-994f-748c4182bc4c DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1416053968; bh=1MI3JG/xqOIGlgHsDjjoP8YJrGsbxd7Dj18PCRjF2Zs=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type; b=izfyFY4BjJbN/QT38gSb6SANZZ11kA1/UwXhZLPrfNWBCozGq6rUSwebQAY13Ip8I Q4hEiLziXWrgD7Q+NSOv8mHvukYuhTE1PzLsgkOz2k+X8AKvPidKr+WGHf3Lu2jHga 6ADkwDDFaohsXtUEqCSalDA/k3ZK/QWsUzcB6B9o= Authentication-Results: smtp16.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <546744B6.8040504@yandex.ru> Date: Sat, 15 Nov 2014 15:19:02 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-security@FreeBSD.org, current@FreeBSD.org Subject: Re: CFR: AES-GCM and OpenCrypto work review References: <20141108042300.GA24601@funkthat.com> <54655257.8080705@yandex.ru> <54660389.9060409@yandex.ru> <20141114193911.GR24601@funkthat.com> <20141115024201.GW24601@funkthat.com> In-Reply-To: <20141115024201.GW24601@funkthat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="q1CohB3C3EibA2n1IwbbGWMNnaWPanSwD" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 15 Nov 2014 12:19:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --q1CohB3C3EibA2n1IwbbGWMNnaWPanSwD Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 15.11.2014 05:42, John-Mark Gurney wrote: > I just verified that this happens on a clean HEAD @ r274534: > FreeBSD 11.0-CURRENT #0 r274534: Fri Nov 14 17:17:10 PST 2014 > jmg@carbon.funkthat.com:/scratch/jmg/clean/sys/amd64/compile/IPSEC = amd64 >=20 > No modifications, nothing, and I got the same panic: > panic: System call sendto returing with kernel FPU ctx leaked > cpuid =3D 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001= de7a800 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe001de7a8b0 > vpanic() at vpanic+0x189/frame 0xfffffe001de7a930 > kassert_panic() at kassert_panic+0x139/frame 0xfffffe001de7a9a0 > amd64_syscall() at amd64_syscall+0x616/frame 0xfffffe001de7aab0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe001de7aab0 > --- syscall (64, FreeBSD ELF64, nosys), rip =3D 0x8011975aa, rsp =3D 0x= 7ffffffee588, rbp =3D 0x7ffffffee5c0 --- > KDB: enter: panic >=20 > So, it's clearly not my patch that is causing the issue... >=20 > Andrey, can you verify that you do not receive the same panic w/o my > patches? I tried 11.0-CURRENT r274549 with and without patches. Without patches all works as expected. System encrypts and forwards traffic with and without aesni module. With patches software rijndaelEncrypt also works. But when I load aesni.ko and restart setkey -f /etc/ipsec.conf forwarding stops, errors counter starts grow. And I see messages about wrong source route attempts from random addresses. --=20 WBR, Andrey V. Elsukov --q1CohB3C3EibA2n1IwbbGWMNnaWPanSwD 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 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJUZ0S8AAoJEAHF6gQQyKF6OHUIALW2z/ZBDLu2SsT6bes+DVsb F/VPwmTMiu00j+Nm435eQDKoD5ciK3H+O3bAMg/5642SQCVlqbKSiJb5Oi9JvulB B8T1X0YXDRQeMFTRQgZPckONJBP0RjIbXnjUxnbLDDabcEl5s7u/jyciQKcXpiL8 uGp5te24ORE6kbj8Rh+eCUuLfJTpVhc+izrDQX+ipFLqP1zstq7ZsdAFJfkPpC1w rjSSdBXeoAwHIcuM6zK7jVPp98XvMz6ZdqRJ6tUpylKyw5chZKhHdOtlF7CBmGmg ZvBuA0t6AE2Bi++B3KrvmdPsNjidG4RYnNCsE6qKe2Bv4Wdu3HyRIfvMz/uTbQE= =MPL8 -----END PGP SIGNATURE----- --q1CohB3C3EibA2n1IwbbGWMNnaWPanSwD-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 15 16:04:58 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E6750C9E for ; Sat, 15 Nov 2014 16:04:58 +0000 (UTC) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7A45790A for ; Sat, 15 Nov 2014 16:04:58 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id ex7so5375486wid.0 for ; Sat, 15 Nov 2014 08:04:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Po47zY48VhNTAq555hXZPxisHMeIuf4BX+DT2pt4Qh0=; b=aTaFOPLN3LeA//KMr3WY6gKOanL/FAl+sP6cnGvL+ZBVFl6BzayY8qUakOeyJUMGXV LDLHH6DHWVGiLZi5uTzP+WTpDEavgRuknmmr6aQFei2D75VcMA5EvC6cWxygsrw9qFo1 SrV0a+8zUTjM18LA2y9M3WbsWCxl92u1MpEkkyShU6yvV8DycnsxCAZR7pqo3v3yRU1c YAHFtehY2AFM4puApqkWSddIiAac6k1K/NrnPTg0iVaR/MMkkJuSjyVxHVTgvJglVlgq UH5y/Z4DU+pDJGmAO4sWO3rmNPLvNLF1J5HgPBljF72dBnfSL84yKpRPYNDVqy0OmECq 5rkA== MIME-Version: 1.0 X-Received: by 10.180.211.239 with SMTP id nf15mr13522382wic.9.1416067496817; Sat, 15 Nov 2014 08:04:56 -0800 (PST) Received: by 10.216.213.9 with HTTP; Sat, 15 Nov 2014 08:04:56 -0800 (PST) Date: Sat, 15 Nov 2014 17:04:56 +0100 Message-ID: Subject: [PATCH] gstat on SSD From: "Ranjan1018 ." <214748mv@gmail.com> To: FreeBSD CURRENT Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 15 Nov 2014 16:04:59 -0000 I am running a pair of servers with SSD. In gstat the default display of operation/ms is only one digit after the comma and there are a lot of R/W operation displayed with the 0.1 value. This simple patch displays the operation/ms with two decimal digit. What=E2=80=99s next ? After testing this patch for a day, recording the val= ues in a log file, I have found that some write operation are only 0.02 ms short, on a OCZ Vertex SSD. Probably the next patch is to display micro seconds instead of milli seconds. Maurizio FreeBSD 11 gstat.c.patch From owner-freebsd-current@FreeBSD.ORG Sat Nov 15 18:43:39 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C549BD28 for ; Sat, 15 Nov 2014 18:43:39 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B4D893C for ; Sat, 15 Nov 2014 18:43:39 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id sAFIhWgR030395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 15 Nov 2014 10:43:32 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id sAFIhWXB030394 for freebsd-current@freebsd.org; Sat, 15 Nov 2014 10:43:32 -0800 (PST) (envelope-from sgk) Date: Sat, 15 Nov 2014 10:43:32 -0800 From: Steve Kargl To: freebsd-current@freebsd.org Subject: Finding a rogue src/sys commit with bisection? Message-ID: <20141115184332.GA30344@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 15 Nov 2014 18:43:39 -0000 Before I totally hose by /usr/src directory, does anyone have some guidelines on doing a binary search for a rogue commit in /usr/src/sys?. Either cam or usb (or acpi?) has broken the ability to remove a external USB device once it is plugged into a usb port on my Dell Latitude D530 laptop. I know that a good kernel can be built with r271273 and a bad kernel comes from (nearly) top of tree at r274456. I assume I need to do somthing along the lines % cd /usr/src/sys % svn merge -r 274456:272864 (half way point between good and bad) (build kernel and test) % cd /usr/src/sys % svn revert -R . (assume 272864 builds working kernel) % svn merge -r 274456:273660 (1/2 point between 272864 and 274456). Rinse and repeat. -- Steve From owner-freebsd-current@FreeBSD.ORG Sat Nov 15 18:46:14 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7A1E8DD for ; Sat, 15 Nov 2014 18:46:14 +0000 (UTC) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0745E95E for ; Sat, 15 Nov 2014 18:46:14 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id k14so2524882wgh.38 for ; Sat, 15 Nov 2014 10:46:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=I3d29KOT71K0DD2+DpdztECeMJCV/tlnarMVJ3QovDo=; b=MfSGSv9BMwSsnSPOsZKWsPVaN2sct6yuHoQ1dSgKAjj8pySfIOQoIjtcfm8MnqJJ9w O6YGrD1OHYWk34HhpF77yH21MGQHKnyX3eqpOE4KmVhZaAxrcAIvTdwBjzcbus4dV39h M/W4+RII1q0OW1aNnUN/Y+fmPzmCr3S+g5MfxvFoQECmwj6wWuYcxsmrqp2haXQIhamm vf8g72vZCSSnLXCQvn/oJtX8tqXZlPquqxOkhBjUxbZ2SUNa5crv6TVwER4uYdHei0Ku 0BLg4/VpM5tjwwhR/fMLV1SFGYq9xocFzMopanbGLhDDEV0wxSeXxFFfxQmfhxtM96rA ugJA== X-Received: by 10.180.95.74 with SMTP id di10mr18367115wib.54.1416077172434; Sat, 15 Nov 2014 10:46:12 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id pl8sm3081001wic.1.2014.11.15.10.46.11 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 15 Nov 2014 10:46:11 -0800 (PST) Date: Sat, 15 Nov 2014 19:46:09 +0100 From: Mateusz Guzik To: Steve Kargl Subject: Re: Finding a rogue src/sys commit with bisection? Message-ID: <20141115184609.GB22467@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Steve Kargl , freebsd-current@freebsd.org References: <20141115184332.GA30344@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20141115184332.GA30344@troutmask.apl.washington.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 15 Nov 2014 18:46:14 -0000 On Sat, Nov 15, 2014 at 10:43:32AM -0800, Steve Kargl wrote: > Before I totally hose by /usr/src directory, does anyone > have some guidelines on doing a binary search for a rogue > commit in /usr/src/sys?. Either cam or usb (or acpi?) has > broken the ability to remove a external USB device once it > is plugged into a usb port on my Dell Latitude D530 laptop. > I know that a good kernel can be built with r271273 and > a bad kernel comes from (nearly) top of tree at r274456. > > I assume I need to do somthing along the lines > > % cd /usr/src/sys > % svn merge -r 274456:272864 (half way point between good and bad) > (build kernel and test) > % cd /usr/src/sys > % svn revert -R . > (assume 272864 builds working kernel) > % svn merge -r 274456:273660 (1/2 point between 272864 and 274456). > http://search.cpan.org/dist/App-SVN-Bisect/bin/svn-bisect Unteste though, they keyword to use bisect. In absolutely worst case yu can check out git tree and bisect that :-> -- Mateusz Guzik From owner-freebsd-current@FreeBSD.ORG Sat Nov 15 18:52:27 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 254FC267 for ; Sat, 15 Nov 2014 18:52:27 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DF4F7A22 for ; Sat, 15 Nov 2014 18:52:26 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id sAFIqQ6e030452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 15 Nov 2014 10:52:26 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id sAFIqQbI030451; Sat, 15 Nov 2014 10:52:26 -0800 (PST) (envelope-from sgk) Date: Sat, 15 Nov 2014 10:52:26 -0800 From: Steve Kargl To: Mateusz Guzik , freebsd-current@freebsd.org Subject: Re: Finding a rogue src/sys commit with bisection? Message-ID: <20141115185226.GA30440@troutmask.apl.washington.edu> References: <20141115184332.GA30344@troutmask.apl.washington.edu> <20141115184609.GB22467@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141115184609.GB22467@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 15 Nov 2014 18:52:27 -0000 On Sat, Nov 15, 2014 at 07:46:09PM +0100, Mateusz Guzik wrote: > On Sat, Nov 15, 2014 at 10:43:32AM -0800, Steve Kargl wrote: > > Before I totally hose by /usr/src directory, does anyone > > have some guidelines on doing a binary search for a rogue > > commit in /usr/src/sys?. Either cam or usb (or acpi?) has > > broken the ability to remove a external USB device once it > > is plugged into a usb port on my Dell Latitude D530 laptop. > > I know that a good kernel can be built with r271273 and > > a bad kernel comes from (nearly) top of tree at r274456. > > > > I assume I need to do somthing along the lines > > > > % cd /usr/src/sys > > % svn merge -r 274456:272864 (half way point between good and bad) > > (build kernel and test) > > % cd /usr/src/sys > > % svn revert -R . > > (assume 272864 builds working kernel) > > % svn merge -r 274456:273660 (1/2 point between 272864 and 274456). > > > > http://search.cpan.org/dist/App-SVN-Bisect/bin/svn-bisect > There's no instructions on how to install it. > > In absolutely worst case yu can check out git tree and bisect that :-> > Nope. Learning how to use git and github is well beyond any interest I have. -- Steve From owner-freebsd-current@FreeBSD.ORG Sat Nov 15 18:52:33 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CAD25363 for ; Sat, 15 Nov 2014 18:52:33 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9F63BA27 for ; Sat, 15 Nov 2014 18:52:33 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XpiSQ-0003Oa-Eg; Sat, 15 Nov 2014 18:52:26 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sAFIqPBI006433; Sat, 15 Nov 2014 11:52:25 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/0rFsDzHdx2DOuOMwbu6D5 X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Finding a rogue src/sys commit with bisection? From: Ian Lepore To: Steve Kargl In-Reply-To: <20141115184332.GA30344@troutmask.apl.washington.edu> References: <20141115184332.GA30344@troutmask.apl.washington.edu> Content-Type: text/plain; charset="us-ascii" Date: Sat, 15 Nov 2014 11:52:24 -0700 Message-ID: <1416077544.4781.148.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 15 Nov 2014 18:52:33 -0000 On Sat, 2014-11-15 at 10:43 -0800, Steve Kargl wrote: > Before I totally hose by /usr/src directory, does anyone > have some guidelines on doing a binary search for a rogue > commit in /usr/src/sys?. Either cam or usb (or acpi?) has > broken the ability to remove a external USB device once it > is plugged into a usb port on my Dell Latitude D530 laptop. > I know that a good kernel can be built with r271273 and > a bad kernel comes from (nearly) top of tree at r274456. > > I assume I need to do somthing along the lines > > % cd /usr/src/sys > % svn merge -r 274456:272864 (half way point between good and bad) > (build kernel and test) > % cd /usr/src/sys > % svn revert -R . > (assume 272864 builds working kernel) > % svn merge -r 274456:273660 (1/2 point between 272864 and 274456). > > Rinse and repeat. > I've always used 'svn up -rnnnnnn' to bisect. No need to revert, just repeatedly update to the next halfway point, and when you're all done, -rHEAD to get back to normal. I've also had very good results with using -DNO_CLEAN on kernel bisects, it lets you zoom in quickly then when you think you have a candidate you can do a more complete clean-and-rebuild to be sure. Sometimes build glitches will require a clean rebuild at some bisect points. -- Ian From owner-freebsd-current@FreeBSD.ORG Sat Nov 15 18:56:35 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D427056C; Sat, 15 Nov 2014 18:56:35 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B2A5AA4F; Sat, 15 Nov 2014 18:56:35 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id sAFIuZu4030500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 15 Nov 2014 10:56:35 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id sAFIuZYI030499; Sat, 15 Nov 2014 10:56:35 -0800 (PST) (envelope-from sgk) Date: Sat, 15 Nov 2014 10:56:35 -0800 From: Steve Kargl To: Ian Lepore Subject: Re: Finding a rogue src/sys commit with bisection? Message-ID: <20141115185635.GB30440@troutmask.apl.washington.edu> References: <20141115184332.GA30344@troutmask.apl.washington.edu> <1416077544.4781.148.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1416077544.4781.148.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 15 Nov 2014 18:56:35 -0000 On Sat, Nov 15, 2014 at 11:52:24AM -0700, Ian Lepore wrote: > On Sat, 2014-11-15 at 10:43 -0800, Steve Kargl wrote: > > Before I totally hose by /usr/src directory, does anyone > > have some guidelines on doing a binary search for a rogue > > commit in /usr/src/sys?. Either cam or usb (or acpi?) has > > broken the ability to remove a external USB device once it > > is plugged into a usb port on my Dell Latitude D530 laptop. > > I know that a good kernel can be built with r271273 and > > a bad kernel comes from (nearly) top of tree at r274456. > > > > I assume I need to do somthing along the lines > > > > % cd /usr/src/sys > > % svn merge -r 274456:272864 (half way point between good and bad) > > (build kernel and test) > > % cd /usr/src/sys > > % svn revert -R . > > (assume 272864 builds working kernel) > > % svn merge -r 274456:273660 (1/2 point between 272864 and 274456). > > > > Rinse and repeat. > > > > I've always used 'svn up -rnnnnnn' to bisect. No need to revert, just > repeatedly update to the next halfway point, and when you're all done, > -rHEAD to get back to normal. I've also had very good results with > using -DNO_CLEAN on kernel bisects, it lets you zoom in quickly then > when you think you have a candidate you can do a more complete > clean-and-rebuild to be sure. Sometimes build glitches will require a > clean rebuild at some bisect points. > Ian, Thanks! I, obviously, had not considered 'svn update' as a method to achieve what I wanti/need to do. -- Steve From owner-freebsd-current@FreeBSD.ORG Sat Nov 15 18:56:57 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA8E466F for ; Sat, 15 Nov 2014 18:56:57 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id AB224A59 for ; Sat, 15 Nov 2014 18:56:57 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 79CDE341F875; Sat, 15 Nov 2014 10:56:50 -0800 (PST) Message-ID: <5467A1F2.8000703@mu.org> Date: Sat, 15 Nov 2014 10:56:50 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org, Steve Kargl Subject: Re: Finding a rogue src/sys commit with bisection? References: <20141115184332.GA30344@troutmask.apl.washington.edu> In-Reply-To: <20141115184332.GA30344@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 15 Nov 2014 18:56:58 -0000 On 11/15/14, 10:43 AM, Steve Kargl wrote: > Before I totally hose by /usr/src directory, does anyone > have some guidelines on doing a binary search for a rogue > commit in /usr/src/sys?. Either cam or usb (or acpi?) has > broken the ability to remove a external USB device once it > is plugged into a usb port on my Dell Latitude D530 laptop. > I know that a good kernel can be built with r271273 and > a bad kernel comes from (nearly) top of tree at r274456. > > I assume I need to do somthing along the lines > > % cd /usr/src/sys > % svn merge -r 274456:272864 (half way point between good and bad) > (build kernel and test) > % cd /usr/src/sys > % svn revert -R . > (assume 272864 builds working kernel) > % svn merge -r 274456:273660 (1/2 point between 272864 and 274456). > > Rinse and repeat. > Use git, it has a built in bisector to shake this sort of thing out: git clone --config remote.origin.fetch='+refs/notes/*:refs/notes/*' https://github.com/freebsd/freebsd.git cd freebsd git log # find the hash of the commit for r271273 HASH=the git hash you found # then: git bisect start git bisect bad # Current version is bad git bisect good $HASH Now test compile / etc... Then as things work or don't work you keep running: git bisect good -or- git bisect bad Then compile and test.. you should converge on the problem. -Alfred From owner-freebsd-current@FreeBSD.ORG Sat Nov 15 18:57:56 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 19CEC780 for ; Sat, 15 Nov 2014 18:57:56 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 07410A66 for ; Sat, 15 Nov 2014 18:57:56 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id DFD6C341F83D; Sat, 15 Nov 2014 10:57:55 -0800 (PST) Message-ID: <5467A233.1040002@mu.org> Date: Sat, 15 Nov 2014 10:57:55 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org, Steve Kargl Subject: Re: Finding a rogue src/sys commit with bisection? References: <20141115184332.GA30344@troutmask.apl.washington.edu> <20141115184609.GB22467@dft-labs.eu> <20141115185226.GA30440@troutmask.apl.washington.edu> In-Reply-To: <20141115185226.GA30440@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 15 Nov 2014 18:57:56 -0000 On 11/15/14, 10:52 AM, Steve Kargl wrote: > On Sat, Nov 15, 2014 at 07:46:09PM +0100, Mateusz Guzik wrote: >> On Sat, Nov 15, 2014 at 10:43:32AM -0800, Steve Kargl wrote: >>> Before I totally hose by /usr/src directory, does anyone >>> have some guidelines on doing a binary search for a rogue >>> commit in /usr/src/sys?. Either cam or usb (or acpi?) has >>> broken the ability to remove a external USB device once it >>> is plugged into a usb port on my Dell Latitude D530 laptop. >>> I know that a good kernel can be built with r271273 and >>> a bad kernel comes from (nearly) top of tree at r274456. >>> >>> I assume I need to do somthing along the lines >>> >>> % cd /usr/src/sys >>> % svn merge -r 274456:272864 (half way point between good and bad) >>> (build kernel and test) >>> % cd /usr/src/sys >>> % svn revert -R . >>> (assume 272864 builds working kernel) >>> % svn merge -r 274456:273660 (1/2 point between 272864 and 274456). >>> >> http://search.cpan.org/dist/App-SVN-Bisect/bin/svn-bisect >> > There's no instructions on how to install it. > >> In absolutely worst case yu can check out git tree and bisect that :-> >> > Nope. Learning how to use git and github is well beyond any interest > I have. I just sent you a workflow that will take you about 10 minutes to sort out for git. If you want reply in private and I can send you my phone number to show how if you get stuck. -Alfred From owner-freebsd-current@FreeBSD.ORG Sat Nov 15 19:01:33 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BFCADCA2 for ; Sat, 15 Nov 2014 19:01:33 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9EED1B10 for ; Sat, 15 Nov 2014 19:01:33 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id sAFJ1XQb030586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 15 Nov 2014 11:01:33 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id sAFJ1Xof030585; Sat, 15 Nov 2014 11:01:33 -0800 (PST) (envelope-from sgk) Date: Sat, 15 Nov 2014 11:01:33 -0800 From: Steve Kargl To: Alfred Perlstein Subject: Re: Finding a rogue src/sys commit with bisection? Message-ID: <20141115190133.GA30576@troutmask.apl.washington.edu> References: <20141115184332.GA30344@troutmask.apl.washington.edu> <5467A1F2.8000703@mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5467A1F2.8000703@mu.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 15 Nov 2014 19:01:33 -0000 On Sat, Nov 15, 2014 at 10:56:50AM -0800, Alfred Perlstein wrote: > > On 11/15/14, 10:43 AM, Steve Kargl wrote: > > Before I totally hose by /usr/src directory, does anyone > > have some guidelines on doing a binary search for a rogue > > commit in /usr/src/sys?. Either cam or usb (or acpi?) has > > broken the ability to remove a external USB device once it > > is plugged into a usb port on my Dell Latitude D530 laptop. > > I know that a good kernel can be built with r271273 and > > a bad kernel comes from (nearly) top of tree at r274456. > > > > I assume I need to do somthing along the lines > > > > % cd /usr/src/sys > > % svn merge -r 274456:272864 (half way point between good and bad) > > (build kernel and test) > > % cd /usr/src/sys > > % svn revert -R . > > (assume 272864 builds working kernel) > > % svn merge -r 274456:273660 (1/2 point between 272864 and 274456). > > > > Rinse and repeat. > > > Use git, it has a built in bisector to shake this sort of thing out: > I won't be drawn into the git debate. -- Steve From owner-freebsd-current@FreeBSD.ORG Sat Nov 15 19:02:08 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD29FF3A for ; Sat, 15 Nov 2014 19:02:08 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D96CB24 for ; Sat, 15 Nov 2014 19:02:08 +0000 (UTC) Received: from [192.168.0.106] (cpc14-cmbg15-2-0-cust307.5-4.cable.virginm.net [82.26.1.52]) (authenticated bits=0) by theravensnest.org (8.14.9/8.14.9) with ESMTP id sAFJ1o1n087501 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 15 Nov 2014 19:01:54 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc14-cmbg15-2-0-cust307.5-4.cable.virginm.net [82.26.1.52] claimed to be [192.168.0.106] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Finding a rogue src/sys commit with bisection? From: David Chisnall In-Reply-To: <5467A1F2.8000703@mu.org> Date: Sat, 15 Nov 2014 19:01:46 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <8DB4FB58-BD0E-45CD-BC35-25F2E05012CC@FreeBSD.org> References: <20141115184332.GA30344@troutmask.apl.washington.edu> <5467A1F2.8000703@mu.org> To: Alfred Perlstein X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current@freebsd.org, Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 15 Nov 2014 19:02:08 -0000 On 15 Nov 2014, at 18:56, Alfred Perlstein wrote: > git clone --config remote.origin.fetch=3D'+refs/notes/*:refs/notes/*' = https://github.com/freebsd/freebsd.git You might want to add --depth 2000 (where 2000 is a guess at how many = commits there have been since when it broke and now), to avoid = downloading the entire history of the FreeBSD repo (not necessary if you = have loads of bandwidth and disk space). Just grabbing the last few = thousand revisions is faster than an svn checkout. David From owner-freebsd-current@FreeBSD.ORG Sat Nov 15 19:03:23 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A244CD for ; Sat, 15 Nov 2014 19:03:23 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 86C01B33 for ; Sat, 15 Nov 2014 19:03:23 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 6169F341F83D; Sat, 15 Nov 2014 11:03:23 -0800 (PST) Message-ID: <5467A37B.8010506@mu.org> Date: Sat, 15 Nov 2014 11:03:23 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Steve Kargl Subject: Re: Finding a rogue src/sys commit with bisection? References: <20141115184332.GA30344@troutmask.apl.washington.edu> <5467A1F2.8000703@mu.org> <20141115190133.GA30576@troutmask.apl.washington.edu> In-Reply-To: <20141115190133.GA30576@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 15 Nov 2014 19:03:23 -0000 On 11/15/14, 11:01 AM, Steve Kargl wrote: > On Sat, Nov 15, 2014 at 10:56:50AM -0800, Alfred Perlstein wrote: >> On 11/15/14, 10:43 AM, Steve Kargl wrote: >>> Before I totally hose by /usr/src directory, does anyone >>> have some guidelines on doing a binary search for a rogue >>> commit in /usr/src/sys?. Either cam or usb (or acpi?) has >>> broken the ability to remove a external USB device once it >>> is plugged into a usb port on my Dell Latitude D530 laptop. >>> I know that a good kernel can be built with r271273 and >>> a bad kernel comes from (nearly) top of tree at r274456. >>> >>> I assume I need to do somthing along the lines >>> >>> % cd /usr/src/sys >>> % svn merge -r 274456:272864 (half way point between good and bad) >>> (build kernel and test) >>> % cd /usr/src/sys >>> % svn revert -R . >>> (assume 272864 builds working kernel) >>> % svn merge -r 274456:273660 (1/2 point between 272864 and 274456). >>> >>> Rinse and repeat. >>> >> Use git, it has a built in bisector to shake this sort of thing out: >> > I won't be drawn into the git debate. > OK, so we don't want to use a tool purposefully built for the problem you are facing? Doesn't seem like a "git debate" more like hammering in screws... -Alfred From owner-freebsd-current@FreeBSD.ORG Sat Nov 15 19:19:00 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 90439337 for ; Sat, 15 Nov 2014 19:19:00 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E213C36 for ; Sat, 15 Nov 2014 19:19:00 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id sAFJIxv6030690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 15 Nov 2014 11:18:59 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id sAFJIxB5030689; Sat, 15 Nov 2014 11:18:59 -0800 (PST) (envelope-from sgk) Date: Sat, 15 Nov 2014 11:18:59 -0800 From: Steve Kargl To: Alfred Perlstein Subject: Re: Finding a rogue src/sys commit with bisection? Message-ID: <20141115191859.GA30664@troutmask.apl.washington.edu> References: <20141115184332.GA30344@troutmask.apl.washington.edu> <5467A1F2.8000703@mu.org> <20141115190133.GA30576@troutmask.apl.washington.edu> <5467A37B.8010506@mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5467A37B.8010506@mu.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 15 Nov 2014 19:19:00 -0000 On Sat, Nov 15, 2014 at 11:03:23AM -0800, Alfred Perlstein wrote: > > On 11/15/14, 11:01 AM, Steve Kargl wrote: > >> > > I won't be drawn into the git debate. > > > OK, so we don't want to use a tool purposefully built for the problem > you are facing? Doesn't seem like a "git debate" more like hammering in > screws... > In imy high school years, I worked little construction. More than one old timer told me that a hammer was the best screwdriver they owned. -- Steve From owner-freebsd-current@FreeBSD.ORG Sat Nov 15 19:32:33 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C77AE8B5 for ; Sat, 15 Nov 2014 19:32:33 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9AE74D99 for ; Sat, 15 Nov 2014 19:32:33 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Xpj5E-000LZk-1w; Sat, 15 Nov 2014 19:32:32 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sAFJWUPu006515; Sat, 15 Nov 2014 12:32:30 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/P4yZqqNJjZ+MpmjgrjRrN X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Finding a rogue src/sys commit with bisection? From: Ian Lepore To: Alfred Perlstein In-Reply-To: <5467A37B.8010506@mu.org> References: <20141115184332.GA30344@troutmask.apl.washington.edu> <5467A1F2.8000703@mu.org> <20141115190133.GA30576@troutmask.apl.washington.edu> <5467A37B.8010506@mu.org> Content-Type: text/plain; charset="us-ascii" Date: Sat, 15 Nov 2014 12:32:29 -0700 Message-ID: <1416079949.4781.156.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 15 Nov 2014 19:32:33 -0000 On Sat, 2014-11-15 at 11:03 -0800, Alfred Perlstein wrote: > On 11/15/14, 11:01 AM, Steve Kargl wrote: > > On Sat, Nov 15, 2014 at 10:56:50AM -0800, Alfred Perlstein wrote: > >> On 11/15/14, 10:43 AM, Steve Kargl wrote: > >>> Before I totally hose by /usr/src directory, does anyone > >>> have some guidelines on doing a binary search for a rogue > >>> commit in /usr/src/sys?. Either cam or usb (or acpi?) has > >>> broken the ability to remove a external USB device once it > >>> is plugged into a usb port on my Dell Latitude D530 laptop. > >>> I know that a good kernel can be built with r271273 and > >>> a bad kernel comes from (nearly) top of tree at r274456. > >>> > >>> I assume I need to do somthing along the lines > >>> > >>> % cd /usr/src/sys > >>> % svn merge -r 274456:272864 (half way point between good and bad) > >>> (build kernel and test) > >>> % cd /usr/src/sys > >>> % svn revert -R . > >>> (assume 272864 builds working kernel) > >>> % svn merge -r 274456:273660 (1/2 point between 272864 and 274456). > >>> > >>> Rinse and repeat. > >>> > >> Use git, it has a built in bisector to shake this sort of thing out: > >> > > I won't be drawn into the git debate. > > > OK, so we don't want to use a tool purposefully built for the problem > you are facing? Doesn't seem like a "git debate" more like hammering in > screws... > This in-your-face git evangelism is getting REALLY OLD, REALLY FAST. Please stop it. I have nothing in particular against git, I just have no interest in it. But that's rapidly transforming into active dislike in exact proportion to being repeatedly talked down to by someone with a different opinion, and apparently the belief that folks with other opinions just need more repetitious condescention to see the light. -- Ian From owner-freebsd-current@FreeBSD.ORG Sat Nov 15 19:39:33 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 97EFA9EE; Sat, 15 Nov 2014 19:39:33 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 8447ADC0; Sat, 15 Nov 2014 19:39:33 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 62E0B341F867; Sat, 15 Nov 2014 11:39:33 -0800 (PST) Message-ID: <5467ABF5.7070807@mu.org> Date: Sat, 15 Nov 2014 11:39:33 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Finding a rogue src/sys commit with bisection? References: <20141115184332.GA30344@troutmask.apl.washington.edu> <5467A1F2.8000703@mu.org> <20141115190133.GA30576@troutmask.apl.washington.edu> <5467A37B.8010506@mu.org> <1416079949.4781.156.camel@revolution.hippie.lan> In-Reply-To: <1416079949.4781.156.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 15 Nov 2014 19:39:33 -0000 On 11/15/14, 11:32 AM, Ian Lepore wrote: > On Sat, 2014-11-15 at 11:03 -0800, Alfred Perlstein wrote: >> On 11/15/14, 11:01 AM, Steve Kargl wrote: >>> On Sat, Nov 15, 2014 at 10:56:50AM -0800, Alfred Perlstein wrote: >>>> On 11/15/14, 10:43 AM, Steve Kargl wrote: >>>>> Before I totally hose by /usr/src directory, does anyone >>>>> have some guidelines on doing a binary search for a rogue >>>>> commit in /usr/src/sys?. Either cam or usb (or acpi?) has >>>>> broken the ability to remove a external USB device once it >>>>> is plugged into a usb port on my Dell Latitude D530 laptop. >>>>> I know that a good kernel can be built with r271273 and >>>>> a bad kernel comes from (nearly) top of tree at r274456. >>>>> >>>>> I assume I need to do somthing along the lines >>>>> >>>>> % cd /usr/src/sys >>>>> % svn merge -r 274456:272864 (half way point between good and bad) >>>>> (build kernel and test) >>>>> % cd /usr/src/sys >>>>> % svn revert -R . >>>>> (assume 272864 builds working kernel) >>>>> % svn merge -r 274456:273660 (1/2 point between 272864 and 274456). >>>>> >>>>> Rinse and repeat. >>>>> >>>> Use git, it has a built in bisector to shake this sort of thing out: >>>> >>> I won't be drawn into the git debate. >>> >> OK, so we don't want to use a tool purposefully built for the problem >> you are facing? Doesn't seem like a "git debate" more like hammering in >> screws... >> > This in-your-face git evangelism is getting REALLY OLD, REALLY FAST. > Please stop it. > > I have nothing in particular against git, I just have no interest in it. > But that's rapidly transforming into active dislike in exact proportion > to being repeatedly talked down to by someone with a different opinion, > and apparently the belief that folks with other opinions just need more > repetitious condescention to see the light. > This is really over the top. It's not evangelism, the guy asked "how do I do X?" I showed him how to do it in a few simple steps. If you take "git" out of the equation it would have been a simple "thank you". I could have just as simply replied with the steps needed, however s/git/frob/g and it wouldn't have "triggered" any reaction from people. -Alfred From owner-freebsd-current@FreeBSD.ORG Sat Nov 15 19:42:16 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9FD23C01; Sat, 15 Nov 2014 19:42:16 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 75C00E79; Sat, 15 Nov 2014 19:42:16 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id sAFJgFOb030784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 15 Nov 2014 11:42:15 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id sAFJgFaV030783; Sat, 15 Nov 2014 11:42:15 -0800 (PST) (envelope-from sgk) Date: Sat, 15 Nov 2014 11:42:15 -0800 From: Steve Kargl To: Alfred Perlstein Subject: Re: Finding a rogue src/sys commit with bisection? Message-ID: <20141115194215.GA30774@troutmask.apl.washington.edu> References: <20141115184332.GA30344@troutmask.apl.washington.edu> <5467A1F2.8000703@mu.org> <20141115190133.GA30576@troutmask.apl.washington.edu> <5467A37B.8010506@mu.org> <1416079949.4781.156.camel@revolution.hippie.lan> <5467ABF5.7070807@mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5467ABF5.7070807@mu.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@freebsd.org, Ian Lepore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 15 Nov 2014 19:42:16 -0000 On Sat, Nov 15, 2014 at 11:39:33AM -0800, Alfred Perlstein wrote: > > This is really over the top. > > It's not evangelism, the guy asked "how do I do X?" I showed him how to > do it in a few simple steps. The guy, that would be me, asked how to do it with svn. -- Steve From owner-freebsd-current@FreeBSD.ORG Sat Nov 15 19:48:08 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1E9FCE63; Sat, 15 Nov 2014 19:48:08 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id E1147EA6; Sat, 15 Nov 2014 19:48:07 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 6210F341F87B; Sat, 15 Nov 2014 11:48:07 -0800 (PST) Message-ID: <5467ADF7.1020503@mu.org> Date: Sat, 15 Nov 2014 11:48:07 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Steve Kargl Subject: Re: Finding a rogue src/sys commit with bisection? References: <20141115184332.GA30344@troutmask.apl.washington.edu> <5467A1F2.8000703@mu.org> <20141115190133.GA30576@troutmask.apl.washington.edu> <5467A37B.8010506@mu.org> <1416079949.4781.156.camel@revolution.hippie.lan> <5467ABF5.7070807@mu.org> <20141115194215.GA30774@troutmask.apl.washington.edu> In-Reply-To: <20141115194215.GA30774@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current@freebsd.org, Ian Lepore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 15 Nov 2014 19:48:08 -0000 On 11/15/14, 11:42 AM, Steve Kargl wrote: > On Sat, Nov 15, 2014 at 11:39:33AM -0800, Alfred Perlstein wrote: >> This is really over the top. >> >> It's not evangelism, the guy asked "how do I do X?" I showed him how to >> do it in a few simple steps. > The guy, that would be me, asked how to do it with svn. > Nope. You showed some svn commands to not do it, you weren't explicit in asking for ways to do it in svn, go ahead, look: ~ % grep -i svn > foo.out Before I totally hose by /usr/src directory, does anyone have some guidelines on doing a binary search for a rogue commit in /usr/src/sys?. Either cam or usb (or acpi?) has broken the ability to remove a external USB device once it is plugged into a usb port on my Dell Latitude D530 laptop. I know that a good kernel can be built with r271273 and a bad kernel comes from (nearly) top of tree at r274456. I assume I need to do somthing along the lines % cd /usr/src/sys % svn merge -r 274456:272864 (half way point between good and bad) (build kernel and test) % cd /usr/src/sys % svn revert -R . (assume 272864 builds working kernel) % svn merge -r 274456:273660 (1/2 point between 272864 and 274456). Rinse and repeat. .(11:46:36)(alfred@AlfredMacbookAir.local) ~ % cat foo.out % svn merge -r 274456:272864 (half way point between good and bad) % svn revert -R . % svn merge -r 274456:273660 (1/2 point between 272864 and 274456). .(11:46:38)(alfred@AlfredMacbookAir.local) ~ % From owner-freebsd-current@FreeBSD.ORG Sat Nov 15 19:51:14 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BDC54F81; Sat, 15 Nov 2014 19:51:14 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 80F5EEBB; Sat, 15 Nov 2014 19:51:13 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id D2C113BD2B; Sat, 15 Nov 2014 19:51:06 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id sAFJp2ca075019; Sat, 15 Nov 2014 19:51:05 GMT (envelope-from phk@phk.freebsd.dk) To: Alfred Perlstein Subject: Re: Finding a rogue src/sys commit with bisection? In-reply-to: <5467ADF7.1020503@mu.org> From: "Poul-Henning Kamp" References: <20141115184332.GA30344@troutmask.apl.washington.edu> <5467A1F2.8000703@mu.org> <20141115190133.GA30576@troutmask.apl.washington.edu> <5467A37B.8010506@mu.org> <1416079949.4781.156.camel@revolution.hippie.lan> <5467ABF5.7070807@mu.org> <20141115194215.GA30774@troutmask.apl.washington.edu> <5467ADF7.1020503@mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <75017.1416081062.1@critter.freebsd.dk> Date: Sat, 15 Nov 2014 19:51:02 +0000 Message-ID: <75018.1416081062@critter.freebsd.dk> Cc: freebsd-current@freebsd.org, Ian Lepore , Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 15 Nov 2014 19:51:14 -0000 -------- In message <5467ADF7.1020503@mu.org>, Alfred Perlstein writes: >Nope. You showed some svn commands to not do it, you weren't explicit >in asking for ways to do it in svn, go ahead, look: I didn't realize that the git-zealots also wanted us to adopt the petty and childish behaviour of the linux email-culture ? Can everybody please just shut up and code now ? Thankyou! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sat Nov 15 19:53:14 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DCD4F13C; Sat, 15 Nov 2014 19:53:14 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B8659F56; Sat, 15 Nov 2014 19:53:14 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id sAFJrDfx030867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 15 Nov 2014 11:53:13 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id sAFJrDw7030866; Sat, 15 Nov 2014 11:53:13 -0800 (PST) (envelope-from sgk) Date: Sat, 15 Nov 2014 11:53:13 -0800 From: Steve Kargl To: Alfred Perlstein Subject: Re: Finding a rogue src/sys commit with bisection? Message-ID: <20141115195313.GA30831@troutmask.apl.washington.edu> References: <20141115184332.GA30344@troutmask.apl.washington.edu> <5467A1F2.8000703@mu.org> <20141115190133.GA30576@troutmask.apl.washington.edu> <5467A37B.8010506@mu.org> <1416079949.4781.156.camel@revolution.hippie.lan> <5467ABF5.7070807@mu.org> <20141115194215.GA30774@troutmask.apl.washington.edu> <5467ADF7.1020503@mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5467ADF7.1020503@mu.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@freebsd.org, Ian Lepore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 15 Nov 2014 19:53:15 -0000 On Sat, Nov 15, 2014 at 11:48:07AM -0800, Alfred Perlstein wrote: > > On 11/15/14, 11:42 AM, Steve Kargl wrote: > > On Sat, Nov 15, 2014 at 11:39:33AM -0800, Alfred Perlstein wrote: > >> This is really over the top. > >> > >> It's not evangelism, the guy asked "how do I do X?" I showed him how to > >> do it in a few simple steps. > > The guy, that would be me, asked how to do it with svn. > > > > Nope. You showed some svn commands to not do it, you weren't explicit > in asking for ways to do it in svn, go ahead, look: I won't insult your intelligence. Oh what the hell, it is clear from the list of commands I meant how to do it with svn. Go ahead twist it however suits your needs. Ian's suggestion on using 'svn update -r#' was exactly what I was looking for. PS: 'svn up -r271000' has already shown to provide a "good" kernel. PPS: I currently building a -r272728 kernel. -- Steve From owner-freebsd-current@FreeBSD.ORG Sat Nov 15 19:54:34 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ADC9D245; Sat, 15 Nov 2014 19:54:34 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 97EBDF62; Sat, 15 Nov 2014 19:54:34 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 7CF0F341F87A; Sat, 15 Nov 2014 11:54:34 -0800 (PST) Message-ID: <5467AF7A.2080206@mu.org> Date: Sat, 15 Nov 2014 11:54:34 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Poul-Henning Kamp Subject: Re: Finding a rogue src/sys commit with bisection? References: <20141115184332.GA30344@troutmask.apl.washington.edu> <5467A1F2.8000703@mu.org> <20141115190133.GA30576@troutmask.apl.washington.edu> <5467A37B.8010506@mu.org> <1416079949.4781.156.camel@revolution.hippie.lan> <5467ABF5.7070807@mu.org> <20141115194215.GA30774@troutmask.apl.washington.edu> <5467ADF7.1020503@mu.org> <75018.1416081062@critter.freebsd.dk> In-Reply-To: <75018.1416081062@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Steve Kargl , Ian Lepore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 15 Nov 2014 19:54:34 -0000 On 11/15/14, 11:51 AM, Poul-Henning Kamp wrote: > -------- > In message <5467ADF7.1020503@mu.org>, Alfred Perlstein writes: > >> Nope. You showed some svn commands to not do it, you weren't explicit >> in asking for ways to do it in svn, go ahead, look: > I didn't realize that the git-zealots also wanted us to adopt the > petty and childish behaviour of the linux email-culture ? > > Can everybody please just shut up and code now ? > > Thankyou! > I resent your implications. Seriously I do. There was no intent to be childish or anything as such. He asked: "how do i bisect code". I gave a tool that can do it in a few easy steps? I didn't realize that git has become a trigger word for some people in the project. I will proceed to warn people going forward. -Alfred From owner-freebsd-current@FreeBSD.ORG Sat Nov 15 19:56:17 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B4BAC354; Sat, 15 Nov 2014 19:56:17 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 76A58F6E; Sat, 15 Nov 2014 19:56:17 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id B4B973BD37; Sat, 15 Nov 2014 19:56:16 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id sAFJuGve075055; Sat, 15 Nov 2014 19:56:16 GMT (envelope-from phk@phk.freebsd.dk) To: Alfred Perlstein Subject: Re: Finding a rogue src/sys commit with bisection? In-reply-to: <5467AF7A.2080206@mu.org> From: "Poul-Henning Kamp" References: <20141115184332.GA30344@troutmask.apl.washington.edu> <5467A1F2.8000703@mu.org> <20141115190133.GA30576@troutmask.apl.washington.edu> <5467A37B.8010506@mu.org> <1416079949.4781.156.camel@revolution.hippie.lan> <5467ABF5.7070807@mu.org> <20141115194215.GA30774@troutmask.apl.washington.edu> <5467ADF7.1020503@mu.org> <75018.1416081062@critter.freebsd.dk> <5467AF7A.2080206@mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <75053.1416081376.1@critter.freebsd.dk> Date: Sat, 15 Nov 2014 19:56:16 +0000 Message-ID: <75054.1416081376@critter.freebsd.dk> Cc: freebsd-current@freebsd.org, Steve Kargl , Ian Lepore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 15 Nov 2014 19:56:17 -0000 -------- In message <5467AF7A.2080206@mu.org>, Alfred Perlstein writes: >I resent your implications. Seriously I do. > >There was no intent to be childish or anything as such. Well, you were, and intentional or not, you're wasting a hell of a lot of peoples time right now. See also: www.bikeshed.org -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sat Nov 15 19:56:22 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 26A0C44E; Sat, 15 Nov 2014 19:56:22 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 10646F6F; Sat, 15 Nov 2014 19:56:22 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id E7E36341F87F; Sat, 15 Nov 2014 11:56:21 -0800 (PST) Message-ID: <5467AFE5.9050908@mu.org> Date: Sat, 15 Nov 2014 11:56:21 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Steve Kargl Subject: Re: Finding a rogue src/sys commit with bisection? References: <20141115184332.GA30344@troutmask.apl.washington.edu> <5467A1F2.8000703@mu.org> <20141115190133.GA30576@troutmask.apl.washington.edu> <5467A37B.8010506@mu.org> <1416079949.4781.156.camel@revolution.hippie.lan> <5467ABF5.7070807@mu.org> <20141115194215.GA30774@troutmask.apl.washington.edu> <5467ADF7.1020503@mu.org> <20141115195313.GA30831@troutmask.apl.washington.edu> In-Reply-To: <20141115195313.GA30831@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Ian Lepore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 15 Nov 2014 19:56:22 -0000 On 11/15/14, 11:53 AM, Steve Kargl wrote: > On Sat, Nov 15, 2014 at 11:48:07AM -0800, Alfred Perlstein wrote: >> On 11/15/14, 11:42 AM, Steve Kargl wrote: >>> On Sat, Nov 15, 2014 at 11:39:33AM -0800, Alfred Perlstein wrote: >>>> This is really over the top. >>>> >>>> It's not evangelism, the guy asked "how do I do X?" I showed him how to >>>> do it in a few simple steps. >>> The guy, that would be me, asked how to do it with svn. >>> >> Nope. You showed some svn commands to not do it, you weren't explicit >> in asking for ways to do it in svn, go ahead, look: > I won't insult your intelligence. Oh what the hell, it is > clear from the list of commands I meant how to do it with svn. > Go ahead twist it however suits your needs. > > Ian's suggestion on using 'svn update -r#' was exactly what > I was looking for. > > PS: 'svn up -r271000' has already shown to provide a "good" kernel. > PPS: I currently building a -r272728 kernel. > There was no intention to twist anything. Just intended to lend a hand. Steve, if there are other technologies you never want discussed, please just let me know I'll not reply with help if it involves those tools. My goal is to help, not to traumatize. -Alfred From owner-freebsd-current@FreeBSD.ORG Sat Nov 15 20:01:27 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 034C0736; Sat, 15 Nov 2014 20:01:27 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id E06F88C; Sat, 15 Nov 2014 20:01:26 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id B050F341F87A; Sat, 15 Nov 2014 12:01:26 -0800 (PST) Message-ID: <5467B116.6010103@mu.org> Date: Sat, 15 Nov 2014 12:01:26 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Poul-Henning Kamp Subject: Re: Finding a rogue src/sys commit with bisection? References: <20141115184332.GA30344@troutmask.apl.washington.edu> <5467A1F2.8000703@mu.org> <20141115190133.GA30576@troutmask.apl.washington.edu> <5467A37B.8010506@mu.org> <1416079949.4781.156.camel@revolution.hippie.lan> <5467ABF5.7070807@mu.org> <20141115194215.GA30774@troutmask.apl.washington.edu> <5467ADF7.1020503@mu.org> <75018.1416081062@critter.freebsd.dk> <5467AF7A.2080206@mu.org> <75054.1416081376@critter.freebsd.dk> In-Reply-To: <75054.1416081376@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Ian Lepore , Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 15 Nov 2014 20:01:27 -0000 On 11/15/14, 11:56 AM, Poul-Henning Kamp wrote: > -------- > In message <5467AF7A.2080206@mu.org>, Alfred Perlstein writes: > >> I resent your implications. Seriously I do. >> >> There was no intent to be childish or anything as such. > Well, you were, and intentional or not, you're wasting > a hell of a lot of peoples time right now. > > See also: www.bikeshed.org > I do not believe it wasteful of people's time to give them to tools to do the job they asked for. Poul, be careful, there comes a time that when everything minor seems childish, and you start slinging it as an insult left and right, that it is quite possible that you've gone too far in the opposite of the spectrum, that being a cantankerous old fart. Take inventory. -Alfred From owner-freebsd-current@FreeBSD.ORG Sat Nov 15 21:17:35 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D8C6CCCB; Sat, 15 Nov 2014 21:17:35 +0000 (UTC) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A0270923; Sat, 15 Nov 2014 21:17:35 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id rd18so19787901iec.21 for ; Sat, 15 Nov 2014 13:17:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9m3J4SV7UpugnaChDq+wmGQwsZ93V4II+DJ/ntmRxb8=; b=GWeiyiNSZjdy0xEjeWs5OIJ7k+unZ4Jk/dIEflDAMlUAqmlEABOcafACPEgJ/Jrak9 Znz/xfQOLlsdt7NQqCuyMDZRnpOR2dwvj6gXm3euGUKlxF5d3WaCEDHxaEZbDwXDjHue rfTlgASo4q8bMefNxnP2vYiQjWXiwgeLpW3Db8vXsQKSdaoZccX2ixVL8L6doBox088v OsdijRbO9t76IQ96LXuwpJfgEv9Az5gPjDGWsjObSflLvw+yH4couHg+z/ddRtRjSpWi 2ItV/zd1mNtmiH/JnIGmfDzafM0yon1ddCoDadKH0eHYaucns/beOGdHFeWhZoDaPd+Q 79lA== MIME-Version: 1.0 X-Received: by 10.50.56.15 with SMTP id w15mr15446262igp.39.1416086255082; Sat, 15 Nov 2014 13:17:35 -0800 (PST) Received: by 10.107.19.34 with HTTP; Sat, 15 Nov 2014 13:17:35 -0800 (PST) In-Reply-To: <20130916171016.GA1509@charmander> References: <52372362.10506@bitfrost.no> <20130916171016.GA1509@charmander> Date: Sat, 15 Nov 2014 16:17:35 -0500 Message-ID: Subject: Re: General Protection Fault in prelist_remove() From: Ryan Stone To: Mark Johnston Content-Type: text/plain; charset=UTF-8 Cc: Hans Petter Selasky , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 15 Nov 2014 21:17:35 -0000 On Mon, Sep 16, 2013 at 1:10 PM, Mark Johnston wrote: > I've partially fixed this at work by adding a rw lock to protect access > to the the prefix, default router, and DAD lists. The patch is here: > http://people.freebsd.org/~markj/patches/ndp-locking.diff Hi Mark, I've hit a bug in this patch today. The problem is in the locking of the DAD list. Many functions (e.g. nd6_dad_duplicated) call nd6_dad_find() to look up a dadq structure, and then manipulate the structure with no lock held. The problem that once nd6_dad_find() releases the ND lock there is nothing preventing another thread from going in and free'ing the structure. This causes a use-after-free in nd6_dad_duplicated. I have a setup which is somehow triggering DAD on link-local addresses (I don't understand why; I don't have duplicate mac addresses on the network as best that I can tell) and with INVARIANTS on I very frequently get a crash in nd6_dad_duplicated. It looks to me that the only way to fix it is either introduce referencing counting into the structure, or push the locking out of nd6_dad_find() and into the callers. Any opinions? From owner-freebsd-current@FreeBSD.ORG Sat Nov 15 21:36:02 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A662558; Sat, 15 Nov 2014 21:36:02 +0000 (UTC) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 61AE2AD9; Sat, 15 Nov 2014 21:36:02 +0000 (UTC) Received: by mail-pa0-f50.google.com with SMTP id eu11so19707839pac.37 for ; Sat, 15 Nov 2014 13:36:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=DXuBLeIDmmKYHscqgacJX9cqJcCbr4B7aCZ5zMiwHsQ=; b=z/8uHCKJY8lBHW7fkmXJPBM9khjydRkwLdxNAUfAQO/6rAGXxoDvcjHss3QseIsDqt 5TktdDH9CFwRMoVwq5fx2AwUuQ/Cb+ZPZLaJwKBooynYfVlh+Lx9lYbierGzU2LpX2S7 e3LbnafqjqsTCR8P9SrOVGzKi9b/IeDW9cXYenmqfF1Hy4a7sGcO4+Co7LWB+nS3k4rc SImCt8xbEK+z2FtJie5KM2zRtvIuSfyYH59H+WVwOIi+samelOneUn1NWUxiDfRUEcG4 Y4bDnwyzcA4WoWF24s1Zi8i7YRe1WzgkM9itUfdFF58fxObPkl4R2Mkfu5/sQm4J/0Vt KKjA== X-Received: by 10.70.38.232 with SMTP id j8mr2335692pdk.44.1416087361953; Sat, 15 Nov 2014 13:36:01 -0800 (PST) Received: from [192.168.20.5] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id s5sm8430237pdc.52.2014.11.15.13.36.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 15 Nov 2014 13:36:01 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_C47CA824-7345-4114-9584-37C626F3A3F1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [PATCH] gstat on SSD From: Garrett Cooper In-Reply-To: Date: Sat, 15 Nov 2014 13:35:59 -0800 Message-Id: <1263A474-E3B8-4942-A0AA-6692F509138F@gmail.com> References: To: "Ranjan1018 ." <214748mv@gmail.com> X-Mailer: Apple Mail (2.1878.6) Cc: Alexander Motin , FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 15 Nov 2014 21:36:02 -0000 --Apple-Mail=_C47CA824-7345-4114-9584-37C626F3A3F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 15, 2014, at 8:04, Ranjan1018 . <214748mv@gmail.com> wrote: > I am running a pair of servers with SSD. In gstat the default display = of > operation/ms is only one digit after the comma and there are a lot of = R/W > operation displayed with the 0.1 value. This simple patch displays = the > operation/ms with two decimal digit. >=20 > What=92s next ? After testing this patch for a day, recording the = values in a > log file, I have found that some write operation are only 0.02 ms = short, on > a OCZ Vertex SSD. Probably the next patch is to display micro seconds > instead of milli seconds. >=20 > Maurizio >=20 > FreeBSD 11 gstat.c.patch LGTM, but I don=92t have hardware capable of that precision so I can=92t = verify the patch other than build test it and run it for what existing = cases I have. What do you think Alexander? --Apple-Mail=_C47CA824-7345-4114-9584-37C626F3A3F1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUZ8c/AAoJEMZr5QU6S73e7ygH/1MScC4Ql3klFi3dpFETgXNR //yqTpjSig2sO/9c4MlWedq/pslApFekC2VgmpUQmJngzqnNpFU+iaR1Bw70y06H cX0MwlF8wFko6toRvG4oa9xPnY0gudSu2Fug+iajcVUUrzMRL0DCeNo2ORLpqEAU oi7FLs4oDElPKhEv4CSiV3EtRClYuZ038vor3wGeb4XHh31abFWlj+55A5F9ojYC sJWPa7MkYbhGaUNF7KtwykXsTpbQtMcwziAnq1kbMtYWO2L/Z2aJ4Nl6jjctF57A mpGUKMGtPHRDun2rYq7p076gGIpnpSWWTvxtf6CFY0F7szXOOPbm/JDTrA/pSEU= =la1x -----END PGP SIGNATURE----- --Apple-Mail=_C47CA824-7345-4114-9584-37C626F3A3F1-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 15 21:10:27 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C928C9DC for ; Sat, 15 Nov 2014 21:10:27 +0000 (UTC) Received: from orange.myspectrum.nl (unknown [IPv6:2a01:7c8:aab2:19e:5054:ff:fe1e:7dad]) by mx1.freebsd.org (Postfix) with ESMTP id 886E08DD for ; Sat, 15 Nov 2014 21:10:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by orange.myspectrum.nl (Postfix) with ESMTP id F22A185AA2 for ; Sat, 15 Nov 2014 22:10:26 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at myspectrum.nl Received: from orange.myspectrum.nl ([127.0.0.1]) by localhost (orange.myspectrum.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHXq8RRChEtd for ; Sat, 15 Nov 2014 22:10:26 +0100 (CET) Received: from [10.0.0.105] (ip136-5-208-87.adsl2.static.versatel.nl [87.208.5.136]) (Authenticated sender: jeroen@myspectrum.nl) by orange.myspectrum.nl (Postfix) with ESMTPSA id E749D85A6C for ; Sat, 15 Nov 2014 22:10:25 +0100 (CET) Message-ID: <5467C142.2000202@myspectrum.nl> Date: Sat, 15 Nov 2014 22:10:26 +0100 From: Jeroen Hofstee User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: fueword: update ENDPROC References: <5467C075.1040007@myspectrum.nl> In-Reply-To: <5467C075.1040007@myspectrum.nl> X-Forwarded-Message-Id: <5467C075.1040007@myspectrum.nl> Content-Type: multipart/mixed; boundary="------------030901080300050200020201" X-Mailman-Approved-At: Sat, 15 Nov 2014 22:05:21 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 15 Nov 2014 21:10:27 -0000 This is a multi-part message in MIME format. --------------030901080300050200020201 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, gcc on linux complains about the invalid ENDPROC. Attached (git formatted) patch should fix this. Regards, Jeroen --------------030901080300050200020201 Content-Type: text/x-patch; name="0001-fueword-update-ENDPROC.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-fueword-update-ENDPROC.patch" >From fe6337cec5fb16c90c2cdd73dd0d330397072145 Mon Sep 17 00:00:00 2001 From: Jeroen Hofstee Date: Sat, 15 Nov 2014 19:40:12 +0100 Subject: [PATCH] fueword: update ENDPROC commit 29a659e: "Add fueword(9) and casueword(9) functions. They are like fuword(9) and casuword(9), but do not mix value read and indication of fault.", introduced fueword, but gcc complains about the incorrect ENDPROC, fix this. --- mind it, not tested, nor do I know the details, encountered when compiling freebsd kernel on linux with gcc. --- sys/amd64/amd64/support.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sys/amd64/amd64/support.S b/sys/amd64/amd64/support.S index fe19f88..f8b75ff 100644 --- a/sys/amd64/amd64/support.S +++ b/sys/amd64/amd64/support.S @@ -426,8 +426,8 @@ ENTRY(fueword) movq %r11,(%rsi) POP_FRAME_POINTER ret -END(fuword64) -END(fuword) +END(fueword64) +END(fueword) ENTRY(fueword32) PUSH_FRAME_POINTER -- 2.1.0 --------------030901080300050200020201-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 15 22:25:59 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9FE8E19E for ; Sat, 15 Nov 2014 22:25:59 +0000 (UTC) Received: from gwave1.banym.de (gwave1.banym.de [212.72.74.40]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 60415EF6 for ; Sat, 15 Nov 2014 22:25:58 +0000 (UTC) Received: from tesla.banym.local (dslb-084-057-003-046.084.057.pools.vodafone-ip.de [84.57.3.46]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by gwave1.banym.de (Postfix) with ESMTP id 9BD481C003 for ; Sat, 15 Nov 2014 23:08:22 +0100 (CET) Message-ID: <5467CEE2.908@banym.de> Date: Sat, 15 Nov 2014 23:08:34 +0100 From: Dominik Zajac User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Changing makeoptions UKBD_DFLT_KEYMAP leads to kernel build fail X-Banym-MailScanner-Information: Please contact the ISP for more information X-Banym-MailScanner-ID: 9BD481C003.A4470 X-Banym-MailScanner: Found to be clean X-Banym-MailScanner-From: banym@banym.de X-Spam-Status: No Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 15 Nov 2014 22:25:59 -0000 Hi, I am trying to change the default keymap for my keyboard therefore I added the following options to my kernel configuration which leads to the error bellow. Added options: options KBD_INSTALL_CDEV options UKBD_DFLT_KEYMAP makeoptions UKBD_DFLT_KEYMAP=de.iso I tried it with this, too: makeoptions UKBD_DFLT_KEYMAP=german.iso Both leads to the following problem: /usr/src/sys/dev/usb/input/ukbd.c:1209:18: error: use of undeclared identifier 'key_map' sc->sc_keymap = key_map; ^ /usr/src/sys/dev/usb/input/ukbd.c:1210:18: error: use of undeclared identifier 'accent_map' sc->sc_accmap = accent_map; ^ 2 errors generated. *** Error code 1 Is there a dynamic way to change the keyboard layout at boot time to typ the zfs passphrase on my default keyboardlayout? Regards, Dominik