From owner-freebsd-stable@FreeBSD.ORG Sun Sep 14 00:17:39 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9143879; Sun, 14 Sep 2014 00:17:39 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 64D9ABB0; Sun, 14 Sep 2014 00:17:39 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.9/8.14.9) with ESMTP id s8E0HXeU007061; Sat, 13 Sep 2014 20:17:34 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <5414DEAA.1060009@sentex.net> Date: Sat, 13 Sep 2014 20:17:46 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Rick Macklem Subject: Re: svn commit: r267935 - head/sys/dev/e1000 (with work around?) References: <1737288805.35881978.1410642408202.JavaMail.root@uoguelph.ca> In-Reply-To: <1737288805.35881978.1410642408202.JavaMail.root@uoguelph.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 Cc: Glen Barber , ricera10@gmail.com, freebsd-stable , Jack Vogel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 00:17:39 -0000 Hi Eric, Any chance you can look at this em driver bug in Jack's absence ? ---Mike On 9/13/2014 5:06 PM, Rick Macklem wrote: > Mike Tansca wrote: >> On 9/12/2014 7:33 PM, Rick Macklem wrote: >>> I wrote: >>>> The patches are in 10.1. I thought his report said 10.0 in the message. >>>> >>>> If Mike is running a recent stable/10 or releng/10.1, then it has been >>>> patched for this and NFS should work with TSO enabled. If it doesn't, >>>> then something else is broken. >>> Oops, I looked and I see Mike was testing r270560 (which would have both >>> the patches). I don't have an explanation why TSO and 64K rsize, wsize >>> would cause a hang, but does appear it will exist in 10.1 unless it >>> gets resolved. >>> >>> Mike, one difference is that, even with the patches the driver will be >>> copying the transmit mbuf list via m_defrag() to 32 MCLBYTE clusters >>> when using 64K rsize, wsize. >>> If you can reproduce the hang, you might want to look at how many mbuf >>> clusters are allocated. If you've hit the limit, then I think that >>> would explain it. >> >> I have been running the test for a few hrs now and no lockups of the >> nic, so doing the nfs mount with -orsize=32768,wsize=32768 certainly > ? seems to work around the lockup. How do I check the mbuf clusters ? > > Btw, in the past when reducing the rsize,wsize has fixed a problem that > isn't fixed by disabling TSO, it has been a problem w.r.t. receiving a > burst of ethernet packets. > I believe this may be a problem with either the receive ring size or > interrupt latency (testers have reported cases where changing the way > the device driver uses interrupts have fixed the problem so that it > worked with 64K rsize, wsize). > > I have no familiarity with this hardware/driver so I can't suggest > anything specific to try except maybe how interrupts are handled, > if the driver has a sysctl for that. > > rick > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Sun Sep 14 06:58:21 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 37C61E6A for ; Sun, 14 Sep 2014 06:58:21 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 80599E2C for ; Sun, 14 Sep 2014 06:58:20 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA22749; Sun, 14 Sep 2014 09:58:08 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1XT3lA-000Ewo-Fn; Sun, 14 Sep 2014 09:58:08 +0300 Message-ID: <54153C48.2070707@FreeBSD.org> Date: Sun, 14 Sep 2014 09:57:12 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Shane Ambler , freebsd-stable@FreeBSD.org, amvandemore@gmail.com, killing@multiplay.co.uk Subject: Re: Snapshots that won't delete [was: Re: ZFS on root booting...] References: <7F008C560B48412AB66A1EBD9382DDAE@multiplay.co.uk> <9315C209-701A-49EF-85D3-ACCCD1513EC3@icloud.com> <959C54D2C8EB4AC8983DC1DA3CE042E3@multiplay.co.uk> <9F24DD48FBEA46C39F98DF600D46DA1A@multiplay.co.uk> <4450778127F4407EB6566A0FE11CD651@multiplay.co.uk> <090135D4-8B1F-42B4-82FC-6FD2F1DBDDA8@icloud.com> <20140911071233.GA50585@anubis.morrow.me.uk> <541280D8.9090500@ShaneWare.Biz> <541293D0.4080907@FreeBSD.org> <5413C4BA.7080302@ShaneWare.Biz> In-Reply-To: <5413C4BA.7080302@ShaneWare.Biz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 06:58:21 -0000 On 13/09/2014 07:14, Shane Ambler wrote: > On 12/09/2014 16:03, Andriy Gapon wrote: >> Look for it in `mount` output. > > There is no entry in mount or df for the snapshot Sorry, to see the mounted snapshots mount -v is needed. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sun Sep 14 09:14:54 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C96ACC1F; Sun, 14 Sep 2014 09:14:54 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (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 53CA8B86; Sun, 14 Sep 2014 09:14:54 +0000 (UTC) Received: from mh0.gentlemail.de (mh0.gentlemail.de [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s8E9EoqH051764; Sun, 14 Sep 2014 11:14:50 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id BE8DC37FA; Sun, 14 Sep 2014 11:14:49 +0200 (CEST) Message-ID: <54155C89.3040702@omnilan.de> Date: Sun, 14 Sep 2014 11:14:49 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Glen Barber Subject: Re: Open bug: heimdal patch for usr/bin/krb5-config in RELENG_10 [Was: Re: Some missong patches in 9.2-RC2] References: <520283A1.1070404@omnilan.de> <20130808145045.GA17282@glenbarber.us> <53F72E13.6090503@omnilan.de> <20140822143938.GH43778@hub.FreeBSD.org> In-Reply-To: <20140822143938.GH43778@hub.FreeBSD.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Sun, 14 Sep 2014 11:14:50 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 09:14:54 -0000 Bezüglich Glen Barber's Nachricht vom 22.08.2014 16:39 (localtime): > On Fri, Aug 22, 2014 at 01:48:35PM +0200, Harry Schmalzbauer wrote: >> Bezüglich Glen Barber's Nachricht vom 08.08.2013 16:50 (localtime): >>> On Wed, Aug 07, 2013 at 07:28:01PM +0200, freebsd@omnilan.de wrote: >> … >>>> - Regarding kerberized builds: >>>> http://lists.freebsd.org/pipermail/freebsd-bugs/2011-April/043902.html >>>> >>> >>> I'll take a look at this, but I do not see this change even committed to >>> head/ yet. >> >> This time, I'm in time before RELENG_10_1 :-) The fix is also applicable >> to RELENG_10, now found in bugzilla at >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=156245 >> >> Can someone please chek? >> > > Thank you for the reminder. We'll take a look. Thanks a lot, surpisingly local patchset failed, because fix comitted upstream: http://svnweb.freebsd.org/base?view=revision&revision=271284 :-) Good know it will be in 10.1 finally :-) -Harry From owner-freebsd-stable@FreeBSD.ORG Sun Sep 14 11:40:00 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7FF689F for ; Sun, 14 Sep 2014 11:40:00 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (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 5A6C2BF9 for ; Sun, 14 Sep 2014 11:39:59 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id E8D4E1534D2; Sun, 14 Sep 2014 13:39:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3_poFX4nv85; Sun, 14 Sep 2014 13:39:54 +0200 (CEST) Received: from [192.168.10.9] (vaio [192.168.10.9]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 399001534C4; Sun, 14 Sep 2014 13:39:54 +0200 (CEST) Message-ID: <54157E8A.9060301@digiware.nl> Date: Sun, 14 Sep 2014 13:39:54 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Steven Hartland , Shane Ambler , freebsd-stable@freebsd.org Subject: Re: Snapshots that won't delete [was: Re: ZFS on root booting...] References: <7F008C560B48412AB66A1EBD9382DDAE@multiplay.co.uk> <9315C209-701A-49EF-85D3-ACCCD1513EC3@icloud.com> <959C54D2C8EB4AC8983DC1DA3CE042E3@multiplay.co.uk> <9F24DD48FBEA46C39F98DF600D46DA1A@multiplay.co.uk> <4450778127F4407EB6566A0FE11CD651@multiplay.co.uk> <090135D4-8B1F-42B4-82FC-6FD2F1DBDDA8@icloud.com> <20140911071233.GA50585@anubis.morrow.me.uk> <541280D8.9090500@ShaneWare.Biz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 11:40:01 -0000 On 12-9-2014 10:19, Steven Hartland wrote: > Is there a hold on the snapshot? > > ----- Original Message ----- From: "Shane Ambler" > > >> On 11/09/2014 16:42, Ben Morrow wrote: >>> Quoth Adam McDougall : >>>> >>>> Were you running a newer kernel with an older format zpool? I heard >>>> ixsystems had customers doing that and ran into corruption when they >>>> tried to modify the zpool in some way (expand? I don't remember). >>>> http://www.bsdnow.tv/episodes/2014_07_09-zfs_war_stories >>> >>> Oh! Might this be what's causing a problem I've been meaning to ask >>> about? >>> >>> My desktop at home is running (a patched, but not anywhere to do with >>> ZFS) 10-STABLE from a while ago, with a zpool that was created under >>> 8.2-R and is still at version 15. I have been deliberately not upgrading >>> it, because I saw no reason to and it seemed safer to leave things as >>> they were. >>> >>> Recently, though, my dump script has started having occasional problems >>> with snapshots that won't delete. Pending further investigation I have >>> been renaming them to allow the recursive delete to succeed, and (so >>> far) rebooting has always made it possible to get rid of them. >> >> I have seen that issue with 9.2 and at least one other person mentioned >> it as well. I currently have a snapshot that I accessed at least 3 weeks >> ago and renamed to keep rotations working and have not accessed since, >> it still won't delete as it is busy. I can only delete these snapshots >> after a reboot. >> >> The only cause I know is accessing the snapshot. >> I can simply ls .zfs/snapshot/daily.01/somefolder to prevent it being >> deleted. With a manual zfs destroy I get "dataset is busy" and have not >> found a way to find any process that has hold of it. >> >> It seems that some aging of the snapshot needs to happen. Testing a >> rotate, access, rotate keeps working ok, but access last nights >> snapshot and then rotate and it blocks. >> >> I'm fairly sure that I was running 9.1 when I created this zpool and >> then later upgraded to 9.2. zpool upgrade says "This system supports >> ZFS pool feature flags" and "Pool 'zrpleader' already has all supported >> features enabled". I've had more or less the same happen to me in a backup-with-snapshot script... The solution that worked from me uptill now is: zfs unmount -f For me that is easy to do, since this pool holds a remote backup, and is only written at nighttime. So at other times there is no harm if I unmount.... But if you normally "live" in the pool, that might be somewhat harder. --WjW From owner-freebsd-stable@FreeBSD.ORG Sun Sep 14 12:22:09 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1F65560 for ; Sun, 14 Sep 2014 12:22:09 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (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 60025FDB for ; Sun, 14 Sep 2014 12:22:09 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s8ECM7S2053587 for ; Sun, 14 Sep 2014 14:22:07 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 31C793845; Sun, 14 Sep 2014 14:22:07 +0200 (CEST) Message-ID: <54158866.2050901@omnilan.de> Date: Sun, 14 Sep 2014 14:21:58 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: "freebsd-stable@freebsd.org" Subject: option *KB*_DFLT_KEYMAP and *map.h in sys/conf/files X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC8FDF0A0BB3BCA4F7BCB0FFF" X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Sun, 14 Sep 2014 14:22:07 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 12:22:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC8FDF0A0BB3BCA4F7BCB0FFF Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hello, currently I can't compile a kernel on a 10-stable machine with differtent default keymap. Reason is, that the k*map.h file gets generated at compile time, coded in sys/conf/files.arch. For any reason, on my 10-stable build machine, kbdcontrol(1) does look for maps in /usr/share/vt/keymaps, although usr.sbin/kbdcontrol/path.h ha= s #define KEYMAP_PATH "/usr/share/syscons/keymaps/ I guess it's because I have kern.vty=3Dvt Further guess is that I can build the kernel by setting 'env KEYMAP_PATH=3D/usr/share/syscons/keymaps' for kernel configs having *KB*_DFLT_KEYMAP set to syscons keymap name. But I see some problematic cases in the way the neccessarry header files gets generated. First, I think that reading keymaps from the machine's installed maps instead of the ones which are in the sources is not optimal. Maybe it was intentional set to read machine's keymaps to be able to compile a kernel without userland sources?!? But since 9k6 Modems and ctm are obsolete, I can see no good reason any more. Next is that buildkernel depends on kbdcontrol(1) on the build machine. Don't know actually how this can be improoved, one must be able to compile a kernel without userland, so there's most likely no obj tree where we could use another kbdcontrol(1). But my real problem is, that my building machine has to have the same console like the one, I build a kernel for. I guess searching in both paths (syscons/keymaps/ & vt/keymaps) if KEYMAP_PATH is not defined should be implemented (in ys/conf/files.arch) if the way the header files gets generated is the right one. What would habben if I compiled a syscons default keymap into the kernel and use vt? Or vice versa? Thanks, -Harry --------------enigC8FDF0A0BB3BCA4F7BCB0FFF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlQViG4ACgkQLDqVQ9VXb8h+CQCgiN/cBdVlF3r9KTvGas1frRwF 3toAnRCEyw41pv5cqWHcUno9ky7SW7Yl =jmOW -----END PGP SIGNATURE----- --------------enigC8FDF0A0BB3BCA4F7BCB0FFF-- From owner-freebsd-stable@FreeBSD.ORG Sun Sep 14 15:08:03 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C769AD1E for ; Sun, 14 Sep 2014 15:08:03 +0000 (UTC) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "NewFS.denninger.net", Issuer "NewFS.denninger.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 513C8FD5 for ; Sun, 14 Sep 2014 15:08:02 +0000 (UTC) Received: from [192.168.1.40] (localhost [127.0.0.1]) by fs.denninger.net (8.14.9/8.14.8) with ESMTP id s8EF7dQG012461 for ; Sun, 14 Sep 2014 10:07:42 -0500 (CDT) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (TLS/SSL) [192.168.1.40] by Spamblock-sys (LOCAL/AUTH); Sun Sep 14 10:07:42 2014 Message-ID: <5415AF30.9060209@denninger.net> Date: Sun, 14 Sep 2014 10:07:28 -0500 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Status update - ZFS "stalls" and other misbehavior Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010706000609040909030708" X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 15:08:04 -0000 This is a cryptographically signed message in MIME format. --------------ms010706000609040909030708 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Those of you who have seen misbehavior of various sorts while running=20 -STABLE w/ZFS filesystems may want to check out the developments in this = thread on Bugzilla. Work has continued on the candidate patch I posted back in March, and I=20 recently put forward an updated version incorporating changes made by=20 Steve as well that, at least in my testing and (thus far) on one=20 production system here, have completely eliminated the problem. More eyes looking at it and running it down are obvious better so if you = have an interest in this issue or have had problems in this area=20 (/*especially*/ if you have had system "stalls") please check it out. Those who are using my previous patch from back in March definitely want = to look at this; while the March changes did largely fix the issue they=20 did so by moving the "danger zone" further out but did not prevent the=20 ZFS code from invading system RAM to the point that it could produce=20 stalls -- it just made it much less likely. The most-recent patch, as=20 far as I've been able to determine, completely prevent it even when the=20 system is severely overstressed in terms of demanded I/O rate or when=20 the target pool is compromised (e.g. during a resilver operation.) Thanks. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D187594 --=20 Karl Denninger karl@denninger.net /The Market Ticker/ --------------ms010706000609040909030708 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFTzCC BUswggQzoAMCAQICAQgwDQYJKoZIhvcNAQEFBQAwgZ0xCzAJBgNVBAYTAlVTMRAwDgYDVQQI EwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkqhkiG9w0BCQEWIGN1c3Rv bWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0MB4XDTEzMDgyNDE5MDM0NFoXDTE4MDgyMzE5 MDM0NFowWzELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExFzAVBgNVBAMTDkthcmwg RGVubmluZ2VyMSEwHwYJKoZIhvcNAQkBFhJrYXJsQGRlbm5pbmdlci5uZXQwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC5n2KBrBmG22nVntVdvgKCB9UcnapNThrW1L+dq6th d9l4mj+qYMUpJ+8I0rTbY1dn21IXQBoBQmy8t1doKwmTdQ59F0FwZEPt/fGbRgBKVt3Quf6W 6n7kRk9MG6gdD7V9vPpFV41e+5MWYtqGWY3ScDP8SyYLjL/Xgr+5KFKkDfuubK8DeNqdLniV jHo/vqmIgO+6NgzPGPgmbutzFQXlxUqjiNAAKzF2+Tkddi+WKABrcc/EqnBb0X8GdqcIamO5 SyVmuM+7Zdns7D9pcV16zMMQ8LfNFQCDvbCuuQKMDg2F22x5ekYXpwjqTyfjcHBkWC8vFNoY 5aFMdyiN/Kkz0/kduP2ekYOgkRqcShfLEcG9SQ4LQZgqjMpTjSOGzBr3tOvVn5LkSJSHW2Z8 Q0dxSkvFG2/lsOWFbwQeeZSaBi5vRZCYCOf5tRd1+E93FyQfpt4vsrXshIAk7IK7f0qXvxP4 GDli5PKIEubD2Bn+gp3vB/DkfKySh5NBHVB+OPCoXRUWBkQxme65wBO02OZZt0k8Iq0i4Rci WV6z+lQHqDKtaVGgMsHn6PoeYhjf5Al5SP+U3imTjF2aCca1iDB5JOccX04MNljvifXgcbJN nkMgrzmm1ZgJ1PLur/ADWPlnz45quOhHg1TfUCLfI/DzgG7Z6u+oy4siQuFr9QT0MQIDAQAB o4HWMIHTMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIF4DAsBglg hkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHw4 +LnuALyLA5Cgy7T5ZAX1WzKPMB8GA1UdIwQYMBaAFF3U3hpBZq40HB5VM7B44/gmXiI0MDgG CWCGSAGG+EIBAwQrFilodHRwczovL2N1ZGFzeXN0ZW1zLm5ldDoxMTQ0My9yZXZva2VkLmNy bDANBgkqhkiG9w0BAQUFAAOCAQEAZ0L4tQbBd0hd4wuw/YVqEBDDXJ54q2AoqQAmsOlnoxLO 31ehM/LvrTIP4yK2u1VmXtUumQ4Ao15JFM+xmwqtEGsh70RRrfVBAGd7KOZ3GB39FP2TgN/c L5fJKVxOqvEnW6cL9QtvUlcM3hXg8kDv60OB+LIcSE/P3/s+0tEpWPjxm3LHVE7JmPbZIcJ1 YMoZvHh0NSjY5D0HZlwtbDO7pDz9sZf1QEOgjH828fhtborkaHaUI46pmrMjiBnY6ujXMcWD pxtikki0zY22nrxfTs5xDWGxyrc/cmucjxClJF6+OYVUSaZhiiHfa9Pr+41okLgsRB0AmNwE f6ItY3TI8DGCBQowggUGAgEBMIGjMIGdMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxvcmlk YTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRwwGgYD VQQDExNDdWRhIFN5c3RlbXMgTExDIENBMS8wLQYJKoZIhvcNAQkBFiBjdXN0b21lci1zZXJ2 aWNlQGN1ZGFzeXN0ZW1zLm5ldAIBCDAJBgUrDgMCGgUAoIICOzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA5MTQxNTA3MjhaMCMGCSqGSIb3DQEJBDEW BBQFUH0cUeP+Mh5BtMmadScnAASMOjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG0BgkrBgEEAYI3EAQxgaYwgaMwgZ0xCzAJBgNV BAYTAlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoT EEN1ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkq hkiG9w0BCQEWIGN1c3RvbWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0AgEIMIG2BgsqhkiG 9w0BCRACCzGBpqCBozCBnTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExEjAQBgNV BAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExMQzEcMBoGA1UEAxMTQ3Vk YSBTeXN0ZW1zIExMQyBDQTEvMC0GCSqGSIb3DQEJARYgY3VzdG9tZXItc2VydmljZUBjdWRh c3lzdGVtcy5uZXQCAQgwDQYJKoZIhvcNAQEBBQAEggIAkQ4PivEKPEQjLFTVNYY4S8++CfM0 fPsZpROuVZTHRnkWFLBCKQQlwLXVsFXtubBirXZvzdgAqQPIW7zoHIYOUObaP7PmxG+eBpid LdvdNL2Wh75KZtIuQAJKjE5RTpGEVdT1BTj3iCKs8ez9bLrhUd0kC37T4SW/ErfSHt3kuKQE LW2+JclWvvG/uxmBD8lptC18W/SW3YJ2RiXdGMG3PexyjNqE62UQyimoqdTe6bqGuymnwkVk OhQNwdRXYhlaPWtxtu2ZpnFcL+gQo3VxkFCcKKSilrIzwGtTkfe75h4rfUQ7yznZIln2JDpc 0826CFl5Ud0a2DE4M4j5315asVDnX+rMOeXdGU2Bejz3NQkUNd/G/gb6Ttc/zHnQB7ireQkm 4zRGDindAowHKw/dPYTNLlIGF0v31J4ieYkcQ2dfMAgSlDh9hRLs59mher7Fpf/vzwHdts2v YrBurFedfQMtcb1f5/snhXfs6qWT0pHG3yuXa4T1a6PlwzWFBFh7OgQZ5JoFtF98oK+Z/vYh 7y7wVozcSBYXoZjN+vAl0bBRFO/B4mOZ2ZhG0tgvGgryT4HDiO6XQYweFuRTT8YCB+I+rbZX NkWtSfVnUruMAM2DIxuUSXpOfyuIr6uoNekRLqof4+CuNTWTVlcrUl9Dvqe8BVoqUuq+v8/k pp24J3oAAAAAAAA= --------------ms010706000609040909030708-- From owner-freebsd-stable@FreeBSD.ORG Sun Sep 14 18:17:14 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E438C7D; Sun, 14 Sep 2014 18:17:13 +0000 (UTC) Date: Sun, 14 Sep 2014 14:17:08 -0400 From: Glen Barber To: freebsd-stable@FreeBSD.org Subject: FreeBSD 10.1-BETA1 Now Available Message-ID: <20140914181708.GF1198@hub.FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed 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 Release Engineering Team X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 18:17:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The first BETA build of the 10.1-RELEASE release cycle is now available on the FTP servers for the amd64, armv6, i386, ia64, powerpc, powerpc64 and sparc64 architectures. The image checksums follow at the end of this email. Installer images and memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.1/ If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system, use the "stable/10" branch. A list of changes since 10.0-RELEASE are available on the stable/10 release notes page here: http://www.freebsd.org/relnotes/10-STABLE/relnotes/article.html Pre-installed virtual machine images for 10.1-BETA1 are also available for amd64 and i386 architectures. The images are located here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/VM-IMAGES/10.1-BETA1/ The disk images are available in QCOW2, VHD, VMDK, and raw disk image formats. The image download size is approximately 135 MB, which decompress to a 20GB sparse image. The partition layout is: . 512k - freebsd-boot GPT partition type (bootfs GPT label) . 1GB - freebsd-swap GPT partition type (swapfs GPT label) . ~17GB - freebsd-ufs GPT partition type (rootfs GPT label) Note to consumers of the dvd1.iso image: The packages included on the dvd do not have a corresponding pkg(8) repository due to an incompatibility with pkg-1.2.x and pkg-1.3.x. This will be fixed for BETA2. The packages will not be recognized by bsdconfig(8), however can be installed manually. To install packages from the dvd1.iso installer, create and mount the /dist directory: # mkdir -p /dist # mount -t cd9660 /dev/cd0 /dist Next, install pkg(8) from the DVD: # env REPOS_DIR=/dist/packages/repos \ pkg add /dist/packages/freebsd:10:*:*/All/pkg-*.txz At this point, pkg-add(8) can be used to install additional packages from the DVD. Please note, the REPOS_DIR environment variable should be used each time using the DVD as the package repository, otherwise conflicts with packages from the upstream mirrors may occur when they are fetched. For example, to install the Subversion, Gnome, and Xorg, run: # env REPOS_DIR=/dist/packages/repos \ pkg add /dist/packages/freebsd:10:*:*/subversion [...] The freebsd-update(8) utility supports binary upgrades of amd64 and i386 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 10.1-BETA1 During this process, freebsd-update(8) may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install It is recommended to rebuild and install all applications if possible, especially if upgrading from an earlier FreeBSD release, for example, FreeBSD 8.x. Alternatively, the user can install misc/compat9x and other compatibility libraries, afterwards the system must be rebooted into the new userland: # shutdown -r now Finally, after rebooting, freebsd-update needs to be run again to remove stale files: # freebsd-update install == ISO CHECKSUMS == o 10.1-BETA1 amd64 GENERIC: SHA256 (FreeBSD-10.1-BETA1-amd64-bootonly.iso) = 614b7e44077f8612160941a65edba46376e94a8187127cb9712bd32af1640784 SHA256 (FreeBSD-10.1-BETA1-amd64-bootonly.iso.xz) = ccad4377f1ca159ce56d5d9fc5229523dd26e899bcddf55107ff48cac17723a0 SHA256 (FreeBSD-10.1-BETA1-amd64-disc1.iso) = 318f79d5f1822b73ed84c5f29f7a88a9fba6fceb4201a745e322f35a1d3fca72 SHA256 (FreeBSD-10.1-BETA1-amd64-disc1.iso.xz) = a735fdddb9827b92f00cf3fee90d3d4d6773173b4c4b10d659933447ffdea736 SHA256 (FreeBSD-10.1-BETA1-amd64-dvd1.iso) = 9d5857b77cf196ae706e159e48f3c9ada43279b15856ca630888a17f5e0530ea SHA256 (FreeBSD-10.1-BETA1-amd64-dvd1.iso.xz) = d68f5c80ba5eca76375dc4bc2db87283508f3ddd03eff367f88723c2c247f90c SHA256 (FreeBSD-10.1-BETA1-amd64-memstick.img) = 678c4601b09c3a6fa36c42ada23f0515eddc1ded182961a76726ec72bdc89b6f SHA256 (FreeBSD-10.1-BETA1-amd64-memstick.img.xz) = 57f7364feb67f3c1abd7dff3e00ffb03e8e5b4666abbcb45494aa91b9fe645ae SHA256 (FreeBSD-10.1-BETA1-amd64-mini-memstick.img) = cc47097f318b03ae957996ef0b4ea2c9db14c4e7a813883c09ec09e85e508a0a SHA256 (FreeBSD-10.1-BETA1-amd64-mini-memstick.img.xz) = 58e3511866a18683eb823d43dc14ed5749b63e536f372d3af75f0e2959729136 SHA256 (FreeBSD-10.1-BETA1-amd64-uefi-memstick.img) = 5e5572a8c82f788d0b5ae1b997b689bf08a01a474cd2fee9ac46c6763921814c SHA256 (FreeBSD-10.1-BETA1-amd64-uefi-memstick.img.xz) = f1cd5cfeb6f91535a73ff0eac09b4a8277025d4c7a154abd775d4350efae720c MD5 (FreeBSD-10.1-BETA1-amd64-bootonly.iso) = 2902a8b19a37d95e59cfd54ce48aedf0 MD5 (FreeBSD-10.1-BETA1-amd64-bootonly.iso.xz) = 8d59ce2fa86897f748f70c35ebdc6cd9 MD5 (FreeBSD-10.1-BETA1-amd64-disc1.iso) = 3376e98384f311a8730df84da2368a72 MD5 (FreeBSD-10.1-BETA1-amd64-disc1.iso.xz) = fd83dc8a8e62169ff1d727bc24cd8087 MD5 (FreeBSD-10.1-BETA1-amd64-dvd1.iso) = 59c509f807105831326db44e19f0a091 MD5 (FreeBSD-10.1-BETA1-amd64-dvd1.iso.xz) = fbf7ecab2d45ea22f478b3facac5f82d MD5 (FreeBSD-10.1-BETA1-amd64-memstick.img) = 151ca595c7417886f8911640e583ca7b MD5 (FreeBSD-10.1-BETA1-amd64-memstick.img.xz) = 3603162bae308824b2e26319fecb16bc MD5 (FreeBSD-10.1-BETA1-amd64-mini-memstick.img) = 2dfaf4aa156e3db886b285c0d6da0f28 MD5 (FreeBSD-10.1-BETA1-amd64-mini-memstick.img.xz) = e056559ae7993be6d163bf9762217160 MD5 (FreeBSD-10.1-BETA1-amd64-uefi-memstick.img) = 03db08beeecae6d204d95810117d3052 MD5 (FreeBSD-10.1-BETA1-amd64-uefi-memstick.img.xz) = d0b583f4787796f118949a30488b9e2b o 10.1-BETA1 i386 GENERIC: SHA256 (FreeBSD-10.1-BETA1-i386-bootonly.iso) = 1c04306303dfc5278426164c38866ec352a94def82a772c0b99a509955037494 SHA256 (FreeBSD-10.1-BETA1-i386-bootonly.iso.xz) = ca5fa7306fbcadd25830fbb385332084eb7f1841c610d0f158e238f6f0b2b116 SHA256 (FreeBSD-10.1-BETA1-i386-disc1.iso) = fd928fe28c02aa777138f740dba94ace4714c7c6ba5f3f17dd7e0ef55e6544a7 SHA256 (FreeBSD-10.1-BETA1-i386-disc1.iso.xz) = 48e3f346a58819f5db24e8e4f0d0f20a4b91235c90494ff0e005cafd8891855d SHA256 (FreeBSD-10.1-BETA1-i386-dvd1.iso) = df13040d03059ae101c337ee59c5596164e69741acfef9250d624c7afd93c6b5 SHA256 (FreeBSD-10.1-BETA1-i386-dvd1.iso.xz) = 05ac5153df5845409d195d4e320e41ff1ecabab2ee5e6f46f86b3203e971200b SHA256 (FreeBSD-10.1-BETA1-i386-memstick.img) = 730d78d947f721af475cea7d334f95689b9b31b72b3c760582abbc967489f24c SHA256 (FreeBSD-10.1-BETA1-i386-memstick.img.xz) = bd30d35b8309020ee15540ba61bbd5f818f9dccfc1310b9723d600f0eb73bb8f SHA256 (FreeBSD-10.1-BETA1-i386-mini-memstick.img) = 4e765fff7529c742822455de75bb41f25dae2f743b898c51b5e7ff5bb0460512 SHA256 (FreeBSD-10.1-BETA1-i386-mini-memstick.img.xz) = e5d4c497a2fcfac01f5049292f5e11083ea61093ff4e0ed0598173ea4bfd7ab0 MD5 (FreeBSD-10.1-BETA1-i386-bootonly.iso) = ef6a9176a55bf04444d6bcef8a392cc1 MD5 (FreeBSD-10.1-BETA1-i386-bootonly.iso.xz) = 5e32127cc77143340203bf313a24ab82 MD5 (FreeBSD-10.1-BETA1-i386-disc1.iso) = 225dbde89df2a3b39792e9910a91d990 MD5 (FreeBSD-10.1-BETA1-i386-disc1.iso.xz) = f8263ec01efd4d32fb0c04dfc5baab39 MD5 (FreeBSD-10.1-BETA1-i386-dvd1.iso) = fb7c6e8f02506754e37912640b6af314 MD5 (FreeBSD-10.1-BETA1-i386-dvd1.iso.xz) = 40d4d9875c02dc3d9fa541da88294cec MD5 (FreeBSD-10.1-BETA1-i386-memstick.img) = d8705fbc2c421780cc494896fbfe7e22 MD5 (FreeBSD-10.1-BETA1-i386-memstick.img.xz) = 1f26464c9af20339903e3d4e5de5a5fb MD5 (FreeBSD-10.1-BETA1-i386-mini-memstick.img) = ffb07edd23c75d6f3b1176be10350634 MD5 (FreeBSD-10.1-BETA1-i386-mini-memstick.img.xz) = 94cd78d7bca603cc570d459ebfcb2c9c o 10.1-BETA1 ia64 GENERIC: SHA256 (FreeBSD-10.1-BETA1-ia64-bootonly.iso) = c8ff82d3a5eb6de1208709f366e0a0c08a68013de4c3f67e7a22ebbf4c9e6ee6 SHA256 (FreeBSD-10.1-BETA1-ia64-bootonly.iso.xz) = f4210712af4abacd3e276a68d67d6f8929549064d7c95b52eb5ad678fe828093 SHA256 (FreeBSD-10.1-BETA1-ia64-disc1.iso) = bb9c0870c8b62f00742f10a3a739711ad8cd99aa964d4750fc53bff408e694f7 SHA256 (FreeBSD-10.1-BETA1-ia64-disc1.iso.xz) = bd4d4d3aea5d6a1018469ab7a7536d005c870b75a6931e6e5e7947512c29fabc SHA256 (FreeBSD-10.1-BETA1-ia64-memstick.img) = 0694891ae1eb182345229386a2f55624ffc102224da008bd3fb917958685e96c SHA256 (FreeBSD-10.1-BETA1-ia64-memstick.img.xz) = c44a40e1cacca3ed0aa8edbce3cb6985f31b2070b78a26f1a3435b74ca6091a5 SHA256 (FreeBSD-10.1-BETA1-ia64-mini-memstick.img) = e45a0cfc0cf339e6d56a7443419188b5447ba47e313f67f4e575007b36b53aca SHA256 (FreeBSD-10.1-BETA1-ia64-mini-memstick.img.xz) = 574bc2b59e05f67b8f5bea7f65d1103392c7270f3e162c95dad31b8e56925326 MD5 (FreeBSD-10.1-BETA1-ia64-bootonly.iso) = c6cbc77a8bc0a0f65aa38104d6d9a7cd MD5 (FreeBSD-10.1-BETA1-ia64-bootonly.iso.xz) = cfe6df8f2d8b9b70db329fbeb57e3eae MD5 (FreeBSD-10.1-BETA1-ia64-disc1.iso) = a5b4d4f54aa34f204eb7b000e76962b2 MD5 (FreeBSD-10.1-BETA1-ia64-disc1.iso.xz) = 17c090262cdef8aa3f0bf1d1e523355b MD5 (FreeBSD-10.1-BETA1-ia64-memstick.img) = f0fdcf67062ae5b8e7c7084902bc52a4 MD5 (FreeBSD-10.1-BETA1-ia64-memstick.img.xz) = 5de5acfe6c3ec57fc1355b50dc234177 MD5 (FreeBSD-10.1-BETA1-ia64-mini-memstick.img) = 66ae63c70ab6362e5aebbbbc0f5bce0a MD5 (FreeBSD-10.1-BETA1-ia64-mini-memstick.img.xz) = 52cee39e8c19e3b311b80370d3cfd086 o 10.1-BETA1 powerpc GENERIC: SHA256 (FreeBSD-10.1-BETA1-powerpc-bootonly.iso) = 97415aace047c79658d6119c652a91780b7e1b89700cab9f0a3889db07fdd381 SHA256 (FreeBSD-10.1-BETA1-powerpc-bootonly.iso.xz) = 51671537e2f37cc62fb7ca7a032f1a016f93d4fb6d29c6bd60b0fb1aaa7968c5 SHA256 (FreeBSD-10.1-BETA1-powerpc-disc1.iso) = 0bdfa4ba12230d3323147e3f4ba40b8d0e49e2a892e68cee97270380c97d66e0 SHA256 (FreeBSD-10.1-BETA1-powerpc-disc1.iso.xz) = 4721777c1c63ec54d327035e275515c70b737fe420e3ee30e021ce9b6f98c3d2 SHA256 (FreeBSD-10.1-BETA1-powerpc-memstick.img) = 7abc694ad245a87e245601d99c4c5c74063d01aa5ea402cd2ff7a31bdbc73af1 SHA256 (FreeBSD-10.1-BETA1-powerpc-memstick.img.xz) = 0c1132f73d13369c86f8c4a059a83cd80f3e2bb52b86ff697c8fd69dc270fb35 SHA256 (FreeBSD-10.1-BETA1-powerpc-mini-memstick.img) = 120d3a6c1409995b896314ae9ea7c6fd0895d21ac76dcba7d8df9ee9c0c59de8 SHA256 (FreeBSD-10.1-BETA1-powerpc-mini-memstick.img.xz) = 11426765781e2ac0f0ad48f278e80c31294f76634ed031b695c439ea1f0f7717 MD5 (FreeBSD-10.1-BETA1-powerpc-bootonly.iso) = 3a5b098e29db0fbf6bca1d9485991c9e MD5 (FreeBSD-10.1-BETA1-powerpc-bootonly.iso.xz) = 62ccc760e45cab434b5915ba3efd8020 MD5 (FreeBSD-10.1-BETA1-powerpc-disc1.iso) = f9c51f54071caeb3e1d0c54a2ea11070 MD5 (FreeBSD-10.1-BETA1-powerpc-disc1.iso.xz) = 4efa9c057630b39141e99627daa0b94d MD5 (FreeBSD-10.1-BETA1-powerpc-memstick.img) = 6225f275d95c4a01cc643a250095fab8 MD5 (FreeBSD-10.1-BETA1-powerpc-memstick.img.xz) = 966ef81424820bb6eb7675220d957b9f MD5 (FreeBSD-10.1-BETA1-powerpc-mini-memstick.img) = 4e2d2a86f84e67ff072f862bcbd6e217 MD5 (FreeBSD-10.1-BETA1-powerpc-mini-memstick.img.xz) = a3e870a8e66a3a2dedfbbc580d10a0dc o 10.1-BETA1 powerpc64 GENERIC64: SHA256 (FreeBSD-10.1-BETA1-powerpc-powerpc64-bootonly.iso) = 649bafdfd4397cf47140ca7f4331eae1cf62d81b47887aee87bda4d506cb4158 SHA256 (FreeBSD-10.1-BETA1-powerpc-powerpc64-bootonly.iso.xz) = bfb9d26a7c092d9064a399565612716d8602c63bb8548d90ded8b524af07598a SHA256 (FreeBSD-10.1-BETA1-powerpc-powerpc64-disc1.iso) = 73c1b4849ca77808cf6c528f95db75035f01e456f46ec604603b421f0626f967 SHA256 (FreeBSD-10.1-BETA1-powerpc-powerpc64-disc1.iso.xz) = 5494517acd2c0e0e6281b691a2c67e72274ec363ea5707601c4bb06cc6cc067a SHA256 (FreeBSD-10.1-BETA1-powerpc-powerpc64-memstick.img) = 13d6eeaaf61084cd700e145c99dd0ed44aeaac41e5472792c281ed59b2288b90 SHA256 (FreeBSD-10.1-BETA1-powerpc-powerpc64-memstick.img.xz) = de7603e1e7e0e83561f5b17d19f14f3b4b1cc18b595f5243521dd4786827bcbf SHA256 (FreeBSD-10.1-BETA1-powerpc-powerpc64-mini-memstick.img) = 2b984d971590ef7acce8caec13552fe458aa4e2648fb82cb07c294b38a68828b SHA256 (FreeBSD-10.1-BETA1-powerpc-powerpc64-mini-memstick.img.xz) = 02ec4f14edffc555df250501ea222c4cf3e5416f59f308d2818c290984ecd123 MD5 (FreeBSD-10.1-BETA1-powerpc-powerpc64-bootonly.iso) = 24bb5f8de75778e8b7732e9dba90d433 MD5 (FreeBSD-10.1-BETA1-powerpc-powerpc64-bootonly.iso.xz) = 832ad20802ae65d549b18aa8aa419f41 MD5 (FreeBSD-10.1-BETA1-powerpc-powerpc64-disc1.iso) = cb51da9990f34b4900c5425cab3e038e MD5 (FreeBSD-10.1-BETA1-powerpc-powerpc64-disc1.iso.xz) = 0d496c228d4198b5ec64b47594784fee MD5 (FreeBSD-10.1-BETA1-powerpc-powerpc64-memstick.img) = 13743f6c4af3012f0a87d975252d5219 MD5 (FreeBSD-10.1-BETA1-powerpc-powerpc64-memstick.img.xz) = 524e0c4a06a26ab49ac8918f03d56e74 MD5 (FreeBSD-10.1-BETA1-powerpc-powerpc64-mini-memstick.img) = 69c7d6636a17a413d7b5afb5e5027bae MD5 (FreeBSD-10.1-BETA1-powerpc-powerpc64-mini-memstick.img.xz) = 6ea64027518b805acbe2814c7d0a2613 o 10.1-BETA1 sparc64 GENERIC: SHA256 (FreeBSD-10.1-BETA1-sparc64-bootonly.iso) = d19a1b24f07f702da9fcfe057303d8375f8a6222c2168b23f473073cb5892114 SHA256 (FreeBSD-10.1-BETA1-sparc64-bootonly.iso.xz) = e1a9e21b69e570fb6e98585a99a13ec0a16cce498c95f4e9767352c10fc28384 SHA256 (FreeBSD-10.1-BETA1-sparc64-disc1.iso) = 25b932cf4554373c884ce00917f42aa0d5bfa83c15dd06b316af921a07b10b8d SHA256 (FreeBSD-10.1-BETA1-sparc64-disc1.iso.xz) = e6d14f57938df752d23c26a72769c62b2e33e886f274bff6edcdf4583fdb9eae MD5 (FreeBSD-10.1-BETA1-sparc64-bootonly.iso) = f6af2303179f794f48a2820fe35ef151 MD5 (FreeBSD-10.1-BETA1-sparc64-bootonly.iso.xz) = accb5936012f05d981f7483e28d58357 MD5 (FreeBSD-10.1-BETA1-sparc64-disc1.iso) = f59c225101e433a8c7914e569381d7e0 MD5 (FreeBSD-10.1-BETA1-sparc64-disc1.iso.xz) = 776ddcb806e104d871e3762e0d0b5c7b o 10.1-BETA1 armv6 BEAGLEBONE: SHA256 (FreeBSD-10.1-BETA1-arm-armv6-BEAGLEBONE.img.bz2) = 45c25870f33110ff7ff01ea5df4704c78c023463204a475beef906276ae2a6d6 MD5 (FreeBSD-10.1-BETA1-arm-armv6-BEAGLEBONE.img.bz2) = 78dfbb59e0ac0dc054874b23e773583e o 10.1-BETA1 armv6 RPI-B: SHA256 (FreeBSD-10.1-BETA1-arm-armv6-RPI-B.img.bz2) = 4bc649e963bf29f06a1a3fd21f91c0b5f298723c6d67ff8e353a1d2c85cbd7e5 MD5 (FreeBSD-10.1-BETA1-arm-armv6-RPI-B.img.bz2) = 283400b6cf7d495970390c4ece8834e6 o 10.1-BETA1 armv6 PANDABOARD: SHA256 (FreeBSD-10.1-BETA1-arm-armv6-PANDABOARD.img.bz2) = 75a48ea084ee9d867b80dabc4a23673b153e2a7f5ae7bfeb59acda05280f9176 MD5 (FreeBSD-10.1-BETA1-arm-armv6-PANDABOARD.img.bz2) = f68b529d05cbf566b4871e5ae6d77be4 o 10.1-BETA1 armv6 ZEDBOARD: SHA256 (FreeBSD-10.1-BETA1-arm-armv6-ZEDBOARD.img.bz2) = e606786f0ec1cd725d760b8ac8ab8543cd23fddde894ac81bacf558ad1777ade MD5 (FreeBSD-10.1-BETA1-arm-armv6-ZEDBOARD.img.bz2) = 024b044ef0a799eadd797c40f67d8175 == VM IMAGE CHECKSUMS == o 10.1-BETA1 amd64: SHA256 (FreeBSD-10.1-BETA1-amd64.qcow2.xz) = 0d59a751e802cb39588f1c3cdc0e5d8bd0a5dc969851d74d01dc2314e0afa0ac SHA256 (FreeBSD-10.1-BETA1-amd64.raw.xz) = 791382597bb39094c7b8b8c1fc5a3139b7ea61c64608f2f2c09971666766cdb2 SHA256 (FreeBSD-10.1-BETA1-amd64.vhd.xz) = 50ad6c6f4fd64f1b8de7ac8cadf129f98a74225a9c4939cdce90cbe0859ff4de SHA256 (FreeBSD-10.1-BETA1-amd64.vmdk.xz) = e91246c1320480b3cc951adc6cc0fa14b6f3322564bbf9b03045cddc6fd6407a MD5 (FreeBSD-10.1-BETA1-amd64.qcow2.xz) = c15d2116903b5e1d789ee2cb53b7e0f5 MD5 (FreeBSD-10.1-BETA1-amd64.raw.xz) = 1a0387304c87532319b8478b54cf9ca1 MD5 (FreeBSD-10.1-BETA1-amd64.vhd.xz) = b74825859e7d4d4e7947dba872a16709 MD5 (FreeBSD-10.1-BETA1-amd64.vmdk.xz) = e2af01d9392c6c45623ab1ecd3bbc8d4 o 10.1-BETA1 i386: SHA256 (FreeBSD-10.1-BETA1-i386.qcow2.xz) = 595ab545e158367653df45048cc693624fd353cd7328373767e6ae6d05729286 SHA256 (FreeBSD-10.1-BETA1-i386.raw.xz) = 99caeaa9ab574b328a5d3d29ec0fbff20a0012c21e17075c1030f5cf03aa5d0c SHA256 (FreeBSD-10.1-BETA1-i386.vhd.xz) = c15f007bd9b0e6558a8cc7d576a965a432fef36aed77cfd3948d82cb0ed176f3 SHA256 (FreeBSD-10.1-BETA1-i386.vmdk.xz) = 9c9ea14b4d2198361fc69e46a2c8024835283aa21a9bf3d6e89a04c68bf751f8 MD5 (FreeBSD-10.1-BETA1-i386.qcow2.xz) = 23af99126e5772f4acf25cbd252f4586 MD5 (FreeBSD-10.1-BETA1-i386.raw.xz) = 2519a0d6ba50554aee726c8a9f5ca6c1 MD5 (FreeBSD-10.1-BETA1-i386.vhd.xz) = 12e14dacaa9344328ff4043e24871ae5 MD5 (FreeBSD-10.1-BETA1-i386.vmdk.xz) = 03d2b5f145c0f627aafe4cd4a7f32dc1 Glen Love FreeBSD? Support this and future releases with a donation to the FreeBSD Foundation! https://www.freebsdfoundation.org/donate/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUFdukAAoJELls3eqvi17QKEgP/1QVQICKhjcJGR5pJdfz+hjQ AiKstrcWu0tAsPBCoom/D3CfocWCucv4KIjtmtPacG42RTwUZ2lbuyHOBhkfha4f dJ8KVNqyE9UxxDxiFBOoZn1ehF9a7pV63aL5IwZAlnzPq4YbTNkUCKtBpOyUcDAl iGV1yK42K68nZrDZ79bP/wP3PRZmqGb17mebyxTDoMp9E62tI/kdH8xqh+PI+b1s xPxYIBFj0cgrN+uCbI/kvBjDtkY9MRa39KDoH3HjBIl7+yPS+cTPeaaz9djmsoGF Ay9qYuzyyTeRNpDxLWIM4RiysW4KoxIK7TeWiUFHXBjy5peiMb/pJ3CKXV0RsmJH FkAo006vUSujrUdAxyyBCDeIIRf61/N0tSapOwT5QCESd+PKLyqlTarmlaw/d/Ca fNxKHjGrguIL1F8kTUuTtlvIs/FeOLeaHwxXulh12p/c7Tkxd7JO0Ujkgu72ZzPt 6LTyVYnIuae0zbjgyPIDY0NLOa54QrDJ/x4cH4wfbBEsjndopTB66cpPk4oJWVn7 LNr+icNq6mGATv5tZoo/8l/9XWdqmp94zfdb5B1qTdkLTEE4Cfn3Fe5ZGklGjI2e wUoSOfnxzqJwt2Av37zqdZUAzsl/Iv47cbFQKgcFj3+JhbWH7XtVf6MwKrVkTkO0 c53yd7Nh60ZKmB8ZHbTI =8BkT -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sun Sep 14 20:08:54 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 357DED21; Sun, 14 Sep 2014 20:08:54 +0000 (UTC) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::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 050CAA8; Sun, 14 Sep 2014 20:08:53 +0000 (UTC) Received: by mail-pd0-f177.google.com with SMTP id y10so4830894pdj.22 for ; Sun, 14 Sep 2014 13:08:53 -0700 (PDT) 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=V2H6OhVJ3+Oavj3nNA4G1co/mauzAVayq3fQkpTewXc=; b=RYBMI3C2bLEIzkPzElIXftq7ktOMDupzY4CnSJK+muqSWKfqk5v43rVgG3ZgeU8DDH mhPxYA6XdX7B3GrC1yBPBs6JT48L9i7bXCP8TkAVmgVrMO2tncdjBa842X37c7Vt/A32 viGBtjUgwapo1jSWHPKmniM10mNKCnDhFXx16vtLXeLdpIWzwDqjxoe+EQYcFGdVG3og qt0AVnAVmU+ed3PmLubwYQkAxgYFeCVtfVHogyRC0ljoRNFWHBfnLeg41GduJDY7EBK6 Fm5v+SdxqNIKr5V33b1XNKEa72l9a6zhmnYQgHgNOe2t0+gzwjV8c1z/U4V+vv7fjjSl AKVA== X-Received: by 10.70.119.97 with SMTP id kt1mr38148004pdb.54.1410725333355; Sun, 14 Sep 2014 13:08:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.55.162 with HTTP; Sun, 14 Sep 2014 13:08:13 -0700 (PDT) In-Reply-To: <5414DEAA.1060009@sentex.net> References: <1737288805.35881978.1410642408202.JavaMail.root@uoguelph.ca> <5414DEAA.1060009@sentex.net> From: Eric Joyner Date: Sun, 14 Sep 2014 13:08:13 -0700 Message-ID: Subject: Re: svn commit: r267935 - head/sys/dev/e1000 (with work around?) To: Mike Tancsa Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Glen Barber , Rick Macklem , freebsd-stable , Jack Vogel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 20:08:54 -0000 I'll try to, but I can't promise anything soon -- there's a lot of 10gig/40gig stuff to do. --- - Eric Joyner On Sat, Sep 13, 2014 at 5:17 PM, Mike Tancsa wrote: > > > Hi Eric, > Any chance you can look at this em driver bug in Jack's absence ? > > ---Mike > > > On 9/13/2014 5:06 PM, Rick Macklem wrote: > >> Mike Tansca wrote: >> >>> On 9/12/2014 7:33 PM, Rick Macklem wrote: >>> >>>> I wrote: >>>> >>>>> The patches are in 10.1. I thought his report said 10.0 in the message. >>>>> >>>>> If Mike is running a recent stable/10 or releng/10.1, then it has been >>>>> patched for this and NFS should work with TSO enabled. If it doesn't, >>>>> then something else is broken. >>>>> >>>> Oops, I looked and I see Mike was testing r270560 (which would have both >>>> the patches). I don't have an explanation why TSO and 64K rsize, wsize >>>> would cause a hang, but does appear it will exist in 10.1 unless it >>>> gets resolved. >>>> >>>> Mike, one difference is that, even with the patches the driver will be >>>> copying the transmit mbuf list via m_defrag() to 32 MCLBYTE clusters >>>> when using 64K rsize, wsize. >>>> If you can reproduce the hang, you might want to look at how many mbuf >>>> clusters are allocated. If you've hit the limit, then I think that >>>> would explain it. >>>> >>> >>> I have been running the test for a few hrs now and no lockups of the >>> nic, so doing the nfs mount with -orsize=32768,wsize=32768 certainly >>> >> ? seems to work around the lockup. How do I check the mbuf clusters ? >> >> Btw, in the past when reducing the rsize,wsize has fixed a problem that >> isn't fixed by disabling TSO, it has been a problem w.r.t. receiving a >> burst of ethernet packets. >> I believe this may be a problem with either the receive ring size or >> interrupt latency (testers have reported cases where changing the way >> the device driver uses interrupts have fixed the problem so that it >> worked with 64K rsize, wsize). >> >> I have no familiarity with this hardware/driver so I can't suggest >> anything specific to try except maybe how interrupts are handled, >> if the driver has a sysctl for that. >> >> rick >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> >> >> > > -- > ------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada http://www.tancsa.com/ > From owner-freebsd-stable@FreeBSD.ORG Sun Sep 14 20:23:08 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DEC3F16A; Sun, 14 Sep 2014 20:23:08 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A15A221C; Sun, 14 Sep 2014 20:23:08 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.9/8.14.9) with ESMTP id s8EKN4go004725; Sun, 14 Sep 2014 16:23:04 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <5415F926.80902@sentex.net> Date: Sun, 14 Sep 2014 16:23:02 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Eric Joyner Subject: Re: svn commit: r267935 - head/sys/dev/e1000 (with work around?) References: <1737288805.35881978.1410642408202.JavaMail.root@uoguelph.ca> <5414DEAA.1060009@sentex.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 Cc: Glen Barber , Rick Macklem , freebsd-stable , Jack Vogel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 20:23:09 -0000 On 9/14/2014 4:08 PM, Eric Joyner wrote: > I'll try to, but I can't promise anything soon -- there's a lot of > 10gig/40gig stuff to do. Thanks Eric. At first, I thought it was just a certain variant of the em, but I have found at least two that get wedged. Its pretty easy to reproduce. One other thing I noticed is that the README states, "TSO is not supported on 82547 and 82544-based adapters, as well as older adapters." Yet, by default its enabled with the driver. Perhaps a check to just disable TSO for NICs not supported automatically ? The other NIC I can recreate the problem with is root@backup3:/usr/home/mdtancsa # pciconf -lvcb em0 em0@pci0:0:25:0: class=0x020000 card=0x34ec8086 chip=0x10ef8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '82578DM Gigabit Network Connection' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xb1a00000, size 131072, enabled bar [14] = type Memory, range 32, base 0xb1a25000, size 4096, enabled bar [18] = type I/O Port, range 32, base 0x2040, size 32, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 13[e0] = PCI Advanced Features: FLR TP root@backup3:/usr/home/mdtancsa # The odd thing however is that all works fine with the previous rev that was in the tree. ---Mike > > --- > - Eric Joyner > > On Sat, Sep 13, 2014 at 5:17 PM, Mike Tancsa > wrote: > > > > Hi Eric, > Any chance you can look at this em driver bug in Jack's > absence ? > > ---Mike > > > On 9/13/2014 5:06 PM, Rick Macklem wrote: > > Mike Tansca wrote: > > On 9/12/2014 7:33 PM, Rick Macklem wrote: > > I wrote: > > The patches are in 10.1. I thought his report said > 10.0 in the message. > > If Mike is running a recent stable/10 or > releng/10.1, then it has been > patched for this and NFS should work with TSO > enabled. If it doesn't, > then something else is broken. > > Oops, I looked and I see Mike was testing r270560 (which > would have both > the patches). I don't have an explanation why TSO and > 64K rsize, wsize > would cause a hang, but does appear it will exist in > 10.1 unless it > gets resolved. > > Mike, one difference is that, even with the patches the > driver will be > copying the transmit mbuf list via m_defrag() to 32 > MCLBYTE clusters > when using 64K rsize, wsize. > If you can reproduce the hang, you might want to look at > how many mbuf > clusters are allocated. If you've hit the limit, then I > think that > would explain it. > > > I have been running the test for a few hrs now and no > lockups of the > nic, so doing the nfs mount with -orsize=32768,wsize=32768 > certainly > > ? seems to work around the lockup. How do I check the mbuf > clusters ? > > Btw, in the past when reducing the rsize,wsize has fixed a > problem that > isn't fixed by disabling TSO, it has been a problem w.r.t. > receiving a > burst of ethernet packets. > I believe this may be a problem with either the receive ring size or > interrupt latency (testers have reported cases where changing > the way > the device driver uses interrupts have fixed the problem so that it > worked with 64K rsize, wsize). > > I have no familiarity with this hardware/driver so I can't suggest > anything specific to try except maybe how interrupts are handled, > if the driver has a sysctl for that. > > rick > > _________________________________________________ > freebsd-stable@freebsd.org > mailing list > http://lists.freebsd.org/__mailman/listinfo/freebsd-__stable > > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@__freebsd.org > " > > > > > -- > ------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet services since 1994 www.sentex.net > > Cambridge, Ontario Canada http://www.tancsa.com/ > > -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Mon Sep 15 01:52:00 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B89275A for ; Mon, 15 Sep 2014 01:52:00 +0000 (UTC) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (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 323C339E for ; Mon, 15 Sep 2014 01:52:00 +0000 (UTC) Received: by mail-yk0-f180.google.com with SMTP id q9so1719171ykb.25 for ; Sun, 14 Sep 2014 18:51:58 -0700 (PDT) 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=v1jQAdRKbvYVUwXzEvt7QejM4veiyUGZyLTdAUke8wU=; b=WK6Lx/4jOPcJl3PuciLE/ZguSW2XfWy73dLaDIInyteE417PtooWBKosC7yd+wuJ1I wb26pRC7jlRUCKcmL6VcGHvMGYTMLaQauiP7sP6PmvE2Mn10Fx0/wR7Up7npL1nWe+x8 HZ9UnbeySv4a1+6LgKfhfvtopkg/4K/G+hSNu/3sqGI1L3AFhw/RUcUe8Pt6+W8xNzth HRhamVY2hgMxBOT80tmpZal8uXUrlCxQ51cnvem827CaTZr62MoJ4vmCJ5Ui2qnKOo23 DCkopNXMHpz0e8fAZOdgRfjJ/15AMZMQDAVZj16YISGfZKxfL9RgKKHfvn/EVPUI54Z/ 6pGQ== MIME-Version: 1.0 X-Received: by 10.236.123.228 with SMTP id v64mr29801953yhh.41.1410745918715; Sun, 14 Sep 2014 18:51:58 -0700 (PDT) Received: by 10.170.218.197 with HTTP; Sun, 14 Sep 2014 18:51:58 -0700 (PDT) Date: Sun, 14 Sep 2014 18:51:58 -0700 Message-ID: Subject: FreeBSD 10.1 amd64 Beta1 : No bootable device From: Mehmet Erol Sanliturk To: freebsd-stable Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 01:52:00 -0000 Dears All , I have installed FreeBSD 10.1 amd64 Beta 1 DVD .iso with only default selections . When the computer rebooted after installation , last message was the following : Intel(R) Boot Agent GE v1.2.42 . . . No bootable device -- insert boot disk and press any key . Many latest Linux distributions are able to boot in that computer after their installations . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-stable@FreeBSD.ORG Mon Sep 15 02:38:54 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C1A1CE7; Mon, 15 Sep 2014 02:38:54 +0000 (UTC) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::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 8C20F95A; Mon, 15 Sep 2014 02:38:54 +0000 (UTC) Received: by mail-pa0-f45.google.com with SMTP id rd3so5358358pab.32 for ; Sun, 14 Sep 2014 19:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=SLFbOORVXol8AqlgPCyZ/+2K7Duq0FUvyWMOXfbOr0g=; b=cFPw/8t/0UqkJtsDBKbNq236Hi5UxZCy+18dCcMdN1cdVBzBqiXmB/2sJXefC4HnZI PLaGnG9TUSfoKSz88CpOeCM5MjyeMFcXrzoboOSjJ/jFDfXrqein0Tbv8tFdOMNSCemb NCPTRQN6esGDjufCOvnYrCPW1WiwPAiEONSzCBpKl4ILDTCkGgyyp6nJHObFk6ONP2iW 2DDHheVT5vxyCLT9V96bfXuTdkzuZm+TBMzkqiR5Vml349WRGF6dKp1N1Ach2SGKV3K1 pxg8/7MBrz4waQI0qGMDiXOvKl7RKXKz7GMQIkkVqBQGl87vQ9Rue5m2fX29f+3ll5ZS Hoiw== X-Received: by 10.70.100.133 with SMTP id ey5mr465219pdb.153.1410748734061; Sun, 14 Sep 2014 19:38:54 -0700 (PDT) Received: from pyunyh@gmail.com ([106.247.248.2]) by mx.google.com with ESMTPSA id cu3sm9841995pbb.48.2014.09.14.19.38.49 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 14 Sep 2014 19:38:52 -0700 (PDT) From: Yonghyeon PYUN X-Google-Original-From: "Yonghyeon PYUN" Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 15 Sep 2014 11:38:42 +0900 Date: Mon, 15 Sep 2014 11:38:42 +0900 To: Mike Tancsa Subject: Re: svn commit: r267935 - head/sys/dev/e1000 (with work around?) Message-ID: <20140915023842.GA3440@michelle.fasterthan.com> Reply-To: pyunyh@gmail.com References: <1737288805.35881978.1410642408202.JavaMail.root@uoguelph.ca> <5414DEAA.1060009@sentex.net> <5415F926.80902@sentex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5415F926.80902@sentex.net> User-Agent: Mutt/1.4.2.3i Cc: Glen Barber , Eric Joyner , Rick Macklem , freebsd-stable , Jack Vogel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 02:38:54 -0000 On Sun, Sep 14, 2014 at 04:23:02PM -0400, Mike Tancsa wrote: > On 9/14/2014 4:08 PM, Eric Joyner wrote: > >I'll try to, but I can't promise anything soon -- there's a lot of > >10gig/40gig stuff to do. > > Thanks Eric. At first, I thought it was just a certain variant of the > em, but I have found at least two that get wedged. Its pretty easy to > reproduce. > > One other thing I noticed is that the README states, > > "TSO is not supported on 82547 and 82544-based adapters, as well as > older adapters." > If my memory serve me right, this is correct. > Yet, by default its enabled with the driver. Perhaps a check to just > disable TSO for NICs not supported automatically ? The other NIC I can Yes, it should. > recreate the problem with is > > root@backup3:/usr/home/mdtancsa # pciconf -lvcb em0 > em0@pci0:0:25:0: class=0x020000 card=0x34ec8086 chip=0x10ef8086 > rev=0x05 hdr=0x00 > vendor = 'Intel Corporation' > device = '82578DM Gigabit Network Connection' > class = network > subclass = ethernet > bar [10] = type Memory, range 32, base 0xb1a00000, size 131072, > enabled > bar [14] = type Memory, range 32, base 0xb1a25000, size 4096, enabled > bar [18] = type I/O Port, range 32, base 0x2040, size 32, enabled > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > cap 13[e0] = PCI Advanced Features: FLR TP > root@backup3:/usr/home/mdtancsa # > > The odd thing however is that all works fine with the previous rev that > was in the tree. > It looks like previous drivers have a code that conditionally enables TSO for 'MAC rev > 82544 && MAC rev != 82547'. It seems em(4) in CURRENT blindly set TSO for all controllers. From owner-freebsd-stable@FreeBSD.ORG Mon Sep 15 06:22:14 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B87B238C; Mon, 15 Sep 2014 06:22:14 +0000 (UTC) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by mx1.freebsd.org (Postfix) with ESMTP id 1DA55FA4; Mon, 15 Sep 2014 06:22:13 +0000 (UTC) Received: from ppp118-210-249-247.lns20.adl6.internode.on.net (HELO leader.local) ([118.210.249.247]) by ipmail05.adl6.internode.on.net with ESMTP; 15 Sep 2014 15:51:38 +0930 Message-ID: <5416856F.6040206@ShaneWare.Biz> Date: Mon, 15 Sep 2014 15:51:35 +0930 From: Shane Ambler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Andriy Gapon , freebsd-stable@FreeBSD.org, amvandemore@gmail.com, killing@multiplay.co.uk Subject: Re: Snapshots that won't delete [was: Re: ZFS on root booting...] References: <7F008C560B48412AB66A1EBD9382DDAE@multiplay.co.uk> <9315C209-701A-49EF-85D3-ACCCD1513EC3@icloud.com> <959C54D2C8EB4AC8983DC1DA3CE042E3@multiplay.co.uk> <9F24DD48FBEA46C39F98DF600D46DA1A@multiplay.co.uk> <4450778127F4407EB6566A0FE11CD651@multiplay.co.uk> <090135D4-8B1F-42B4-82FC-6FD2F1DBDDA8@icloud.com> <20140911071233.GA50585@anubis.morrow.me.uk> <541280D8.9090500@ShaneWare.Biz> <541293D0.4080907@FreeBSD.org> <5413C4BA.7080302@ShaneWare.Biz> <54153C48.2070707@FreeBSD.org> In-Reply-To: <54153C48.2070707@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 06:22:14 -0000 On 14/09/2014 16:27, Andriy Gapon wrote: > On 13/09/2014 07:14, Shane Ambler wrote: >> On 12/09/2014 16:03, Andriy Gapon wrote: >>> Look for it in `mount` output. >> >> There is no entry in mount or df for the snapshot > > Sorry, to see the mounted snapshots mount -v is needed. > > The first one is 3 or 4 weeks old, the second around a week and the third would be what blocked the snapshots night before last. That one I'm not sure about, while I moved some tarballs out of distfiles the other day I don't recall going to a snapshot copy. The snapshot names of the first two are the names in use when accessed not the now re-named un-destroyable snapshots. I'll keep the third around for a while if you want before and after data. It is still part of a full pool snapshot while the first two are now only one filesystem of a snapshot. zrpleader/home/shane@daily.01 on /home/shane/.zfs/snapshot/daily.01 (zfs, local, noatime, nosuid, read-only, nfsv4acls, fsid ddb4b4b8ded439f9) zrpleader/home/shane/tutorials@daily.01 on /home/shane/tutorials/.zfs/snapshot/daily.01 (zfs, local, noatime, nosuid, read-only, nfsv4acls, fsid 62f418bedebc38cb) zrpleader/usr/ports/distfiles@daily.01 on /usr/ports/distfiles/.zfs/snapshot/daily.01 (zfs, local, noatime, nosuid, read-only, nfsv4acls, fsid f88fb727de003ca6) -- FreeBSD - the place to B...Serving Data Shane Ambler From owner-freebsd-stable@FreeBSD.ORG Mon Sep 15 07:30:41 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5524655E for ; Mon, 15 Sep 2014 07:30:41 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (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 185E4892 for ; Mon, 15 Sep 2014 07:30:41 +0000 (UTC) Received: from 2a02-8428-011b-e000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11b:e000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83 (FreeBSD)) (envelope-from ) id 1XTQkB-000L1t-Bz for freebsd-stable@freebsd.org; Mon, 15 Sep 2014 09:30:39 +0200 Message-ID: <5416959B.2020106@dumbbell.fr> Date: Mon, 15 Sep 2014 09:30:35 +0200 From: =?windows-1252?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Failed to attach fbd device: 6 References: <20140913192554.188840nzwrt6v42s@webmail.raad.tartu.ee> In-Reply-To: <20140913192554.188840nzwrt6v42s@webmail.raad.tartu.ee> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rpT3uFLSvtSWGRRm9COGClQCVl6uiR8RX" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 07:30:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rpT3uFLSvtSWGRRm9COGClQCVl6uiR8RX Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 13.09.2014 18:25, Toomas Aas wrote: > error: [drm:pid0:drm_fb_helper_single_fb_probe] *ERROR* Failed to attac= h > fbd device: 6 >=20 > Other than this error message, I am not seeing any ill effects. I'm jus= t > curious if something could be done to fix this. Yes, this is a false positive, the attach did success. This was fixed in HEAD in r269779. This must have not been merged to stable/10 yet. My fault :) Thank you for the report! --=20 Jean-S=E9bastien P=E9dron --rpT3uFLSvtSWGRRm9COGClQCVl6uiR8RX 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 iQJ8BAEBCgBmBQJUFpWfXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMUBwP/2WU59l9ShW5lzP/qCkrEog6 1o9uy+Vw774CtSOabMdtthtzaB0cEtxKdGZr8vB1wSt8BA4B3MHhXjk1h6PXbjSX 2PkHzityFXvJbw3NNHLV2qaLsrZXEiroel6zKop5kVZGZk01Zeu/wCeGPnEpTEB/ m4lHUf0L41vKSICLH0wMpkjgAIBabdxZMjgqzWVJQtySkP2I9QoPAu33/CECDqsU FT6bPQ0OJwOoOXXMMgHg6N5BJokOkYWu60LAUQD3ol+7TbtfSaVgKoOEj7xxUTSA 1XoT7RYakaY65pk/Hi9jX8Tw/NtM7S3253ShMFXIZIDjZz/2UOm7uBQ8tQfXCTAl 8k07dkKyAJlTpd6Xfb/FoaeZEjhwS6a/Xm1pqsbKTM+Dn3qLK/k0khvJsgH9/Em2 KickmN/vPcvcM9xoWYXakSK5I/zC9UMoEIGe/7c/ibXtIjhJMm6dDKLas12f91UY UcQyFTLh84a4dGxe/IibCBu6WqnErRODpr0qKSEln3OhvDUC1YoNNb8KUC/nK/bF 80fJXZBd/Bx5LoXldwZvJeXdCIrYaso0hWSP3HFskoOkvTF4tlPYDZCoMVFiOGN3 8FQ5s1z42dQqtolAsXtjxWaTbfFamufr3QKdXykbAtnjB3grKOHNfUmQMfT8Qw8K Uhddru7SdeqMBIp/bH/I =9mPb -----END PGP SIGNATURE----- --rpT3uFLSvtSWGRRm9COGClQCVl6uiR8RX-- From owner-freebsd-stable@FreeBSD.ORG Mon Sep 15 07:39:21 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2C0776FC for ; Mon, 15 Sep 2014 07:39:21 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (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 079858FF for ; Mon, 15 Sep 2014 07:39:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=UL/aka4K82302LstBTsTMzK6qyvHG64J9Btzn37ZqZg=; b=fa7NNS5DAZbbKDDeRQu9XCdGx9/AuQzeUCmejrZHH5fDA46VIn4Jkg9GlEBHeQXocxfCUSWdXiZNg3c77aDePjahaGc0CiFYQhy9tRZEAU2nndDe+kah8BNHOIdmNJdPVCCr8Plw7ZcBzTxGH6aD+xl+uCmFXu5EjwfnaOrWNBs=; Received: from [39.249.182.93] (port=57521 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XTQFu-001eF9-MQ for freebsd-stable@freebsd.org; Mon, 15 Sep 2014 00:59:23 -0600 Date: Mon, 15 Sep 2014 14:59:12 +0800 From: Erich Dollansky To: freebsd-stable Subject: mq_open sets errno to 78 when queue does not exist Message-ID: <20140915145912.361a25e9@X220.alogt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 07:39:21 -0000 Hi, I have a very simple program. It basically tries to open a message queue which does not exists. mq_open returns then -1 but errno is set to 78 which is defined as this: #define ENOSYS 78 /* Function not implemented */ The line in question: res = mq_open ("/doesnotexist", O_RDWR); "/doesnotexists" is the non-existing message queue the program tests for. res will be set correctly to -1 but errno is set then to 78. If I want to create the message queue, I will get the same error. uname -a says: FreeBSD X220.alogt.com 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #45 r271420: Sat Sep 13 15:09:34 WITA 2014 erich@X220.alogt.com:/usr/obj/usr/src/sys/X220 amd64 Do I see or do something wrong or is this an error? Erich From owner-freebsd-stable@FreeBSD.ORG Mon Sep 15 08:15:09 2014 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 382C649A for ; Mon, 15 Sep 2014 08:15:09 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 20537D04 for ; Mon, 15 Sep 2014 08:15:09 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8F8F9F2070805 for ; Mon, 15 Sep 2014 08:15:09 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 193363] [panic] panic at reboot Date: Mon, 15 Sep 2014 08:15:08 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sasamotikomi@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 08:15:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193363 --- Comment #5 from sasamotikomi@gmail.com --- (In reply to John Baldwin from comment #4) > Ok, I guess the 9.1 kernel did not ship with debug symbols. You can do 'nm > -n /boot/kernel.old9.1/kernel | grep c0aae' which might narrow things down > some. nm -n /boot/kernel.old9.1/kernel | grep c0aae c0aae160 t idle_setup c0aae280 T intr_handler_source c0aae2a0 t swi_assign_cpu c0aae2b0 T intr_priority c0aae310 t sysctl_intrcnt c0aae340 t sysctl_intrnames c0aae370 t intr_event_schedule_thread c0aae470 T intr_event_execute_handlers c0aae630 t intr_lookup c0aae6f0 t ithread_update c0aae790 t intr_event_update c0aae8d0 T intr_event_remove_handler c0aaeae0 T swi_remove c0aaeb00 T intr_event_add_handler c0aaef10 T intr_event_bind nm -n /boot/kernel.old9.1/kernel | grep c0aae6 c0aae630 t intr_lookup c0aae6f0 t ithread_update -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-stable@FreeBSD.ORG Mon Sep 15 08:26:49 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C73B584C for ; Mon, 15 Sep 2014 08:26:49 +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 5F9B6DFB for ; Mon, 15 Sep 2014 08:26:49 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id bs8so3683800wib.14 for ; Mon, 15 Sep 2014 01:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=fXClUeAiorkb7cBvG3VhtTvuh8VcPRbgFUBcPf57EmY=; b=z4TU4M30g/Ix1410zjcxsbhyKULi0mKE/yK272OHr88wOAV1atemI6dZ+E4OvwMBil LOJZzUy5s2vOv46nKE2IaKBXGnmJELQskWC1xoQAtKfe/hCu9bTy6CZRxYN08wAu9VzX 5kGw1B+QYmv23JIdHeisTlMedyc9uMKI7puHD4SDPf2z6AUF1QL+XCc4Z9xVq0e46Xge crNJx0EX5s6FP6U5io9jZ36RuhteDJoONxfktLNrfyK3zEZf4Dlnwc03LJm0LsYX4JWH 6GmmRdzsnn5UvN9EAvXeU+g/90dSqgGHJLsQM+uC7veGnNgvB6ItuqnjvE1LfqQlBbRI fFlA== X-Received: by 10.194.90.233 with SMTP id bz9mr8880432wjb.94.1410769606430; Mon, 15 Sep 2014 01:26:46 -0700 (PDT) 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 bj7sm13929756wjc.33.2014.09.15.01.26.44 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 15 Sep 2014 01:26:45 -0700 (PDT) Date: Mon, 15 Sep 2014 10:26:35 +0200 From: Mateusz Guzik To: Erich Dollansky Subject: Re: mq_open sets errno to 78 when queue does not exist Message-ID: <20140915082635.GA3042@dft-labs.eu> References: <20140915145912.361a25e9@X220.alogt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20140915145912.361a25e9@X220.alogt.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 08:26:49 -0000 On Mon, Sep 15, 2014 at 02:59:12PM +0800, Erich Dollansky wrote: > Hi, > > I have a very simple program. It basically tries to open a message > queue which does not exists. mq_open returns then -1 but errno is set > to 78 which is defined as this: > > #define ENOSYS 78 /* Function not implemented */ > > The line in question: > > res = mq_open ("/doesnotexist", O_RDWR); > > "/doesnotexists" is the non-existing message queue the program tests > for. res will be set correctly to -1 but errno is set then to 78. > > If I want to create the message queue, I will get the same error. > > uname -a says: > > FreeBSD X220.alogt.com 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #45 > r271420: Sat Sep 13 15:09:34 WITA 2014 > erich@X220.alogt.com:/usr/obj/usr/src/sys/X220 amd64 > > Do I see or do something wrong or is this an error? > Do you have mqueuefs loaded? -- Mateusz Guzik From owner-freebsd-stable@FreeBSD.ORG Mon Sep 15 08:56:42 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F12CAB for ; Mon, 15 Sep 2014 08:56:42 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (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 DB4D6168 for ; Mon, 15 Sep 2014 08:56:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=A51p5+9e5+/6yOE2F2SIyKd7sqkkS77jU2Tc38xQVtA=; b=Z6weEUcXZqrr2SsuTUXOGZmWjEk0ainW5IvJbElOkpH+Pw5jPZgnUK7QqZV/XCQ+r7VajIjCchwPraiRKBQm8ecmMWT1xhW5LUWGL1TfhQh2VZjzmNjTWjwjC86YNrhwZcllfoDnBFWoZ5i+ml8HmGGecxlL6aYzRF94cCVAhaU=; Received: from [39.249.182.93] (port=36201 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XTS5Q-002ULC-1R; Mon, 15 Sep 2014 02:56:41 -0600 Date: Mon, 15 Sep 2014 16:56:34 +0800 From: Erich Dollansky To: Mateusz Guzik Subject: Re: mq_open sets errno to 78 when queue does not exist Message-ID: <20140915165634.30fe6e8a@X220.alogt.com> In-Reply-To: <20140915082635.GA3042@dft-labs.eu> References: <20140915145912.361a25e9@X220.alogt.com> <20140915082635.GA3042@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 08:56:42 -0000 Hi, On Mon, 15 Sep 2014 10:26:35 +0200 Mateusz Guzik wrote: > On Mon, Sep 15, 2014 at 02:59:12PM +0800, Erich Dollansky wrote: > > Hi, > > > > I have a very simple program. It basically tries to open a message > > queue which does not exists. mq_open returns then -1 but errno is > > set to 78 which is defined as this: > > > > #define ENOSYS 78 /* Function not implemented */ > > > > The line in question: > > > > res = mq_open ("/doesnotexist", O_RDWR); > > > > "/doesnotexists" is the non-existing message queue the program tests > > for. res will be set correctly to -1 but errno is set then to 78. > > > > If I want to create the message queue, I will get the same error. > > > > uname -a says: > > > > FreeBSD X220.alogt.com 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #45 > > r271420: Sat Sep 13 15:09:34 WITA 2014 > > erich@X220.alogt.com:/usr/obj/usr/src/sys/X220 amd64 > > > > Do I see or do something wrong or is this an error? > > > > Do you have mqueuefs loaded? > of course not. I was under the impression that options _KPOSIX_PRIORITY_SCHEDULING in the kernel configuration will do. Thanks for the hint. Erich From owner-freebsd-stable@FreeBSD.ORG Mon Sep 15 10:39:30 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E6D8FCFA; Mon, 15 Sep 2014 10:39:30 +0000 (UTC) Received: from mailout10.t-online.de (mailout10.t-online.de [194.25.134.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 92436DEB; Mon, 15 Sep 2014 10:39:30 +0000 (UTC) Received: from fwd32.aul.t-online.de (fwd32.aul.t-online.de [172.20.26.144]) by mailout10.t-online.de (Postfix) with SMTP id B0AE3362665; Mon, 15 Sep 2014 12:29:18 +0200 (CEST) Received: from [192.168.119.33] (VOjh4mZ1rhTpTE4pUyJdDqER2av4pC-4kfi0F8KlnFXfJ+0VPF03wUM+b+8Pf6SQ5Z@[84.154.101.219]) by fwd32.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XTTX4-3iCxXM0; Mon, 15 Sep 2014 12:29:18 +0200 Message-ID: <5416BF7A.1080301@freebsd.org> Date: Mon, 15 Sep 2014 12:29:14 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Harald Schmalzbauer , "freebsd-stable@freebsd.org" Subject: Re: option *KB*_DFLT_KEYMAP and *map.h in sys/conf/files References: <54158866.2050901@omnilan.de> In-Reply-To: <54158866.2050901@omnilan.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ID: VOjh4mZ1rhTpTE4pUyJdDqER2av4pC-4kfi0F8KlnFXfJ+0VPF03wUM+b+8Pf6SQ5Z X-TOI-MSGID: 559e642c-cb55-432c-8164-68f024f26844 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 10:39:31 -0000 Am 14.09.2014 um 14:21 schrieb Harald Schmalzbauer: > Hello, > > currently I can't compile a kernel on a 10-stable machine with > differtent default keymap. Reason is, that the k*map.h file gets > generated at compile time, coded in sys/conf/files.arch. > > For any reason, on my 10-stable build machine, kbdcontrol(1) does > look for maps in /usr/share/vt/keymaps, although > usr.sbin/kbdcontrol/path.h has #define KEYMAP_PATH > "/usr/share/syscons/keymaps/ I guess it's because I have > kern.vty=vt Hallo Harald, did you look for keymap files in vt/keymaps, recently? Most of the syscons keymap files have been converted for use with vt. Since vt uses unicode instead of locale dependent encodings, most keymap files got renamed (and the naming scheme got somewhat more regular). For ISO-8859-1 keymaps, the syscons keymaps can be used without any change (since the first 256 Unicode code points are just the ISO-8859-1 characters), but for other encodings a Perl script in tools/tools/vt/keymaps should be able to do the conversion. You should not assume, that syscons/keymaps files work with vt, but as said, for ISO-8859-1 (only!) they just work- > Further guess is that I can build the kernel by setting 'env > KEYMAP_PATH=/usr/share/syscons/keymaps' for kernel configs having > *KB*_DFLT_KEYMAP set to syscons keymap name. You could, but why don't you just use the correct keymap name as found in vt/keymaps? And BTW: Did you really use KB_DFLT_KEYMAP??? # config TEST # TEST: unknown option "KB_DFLT_KEYMAP" Valid keymap options are ATKBD_DFLT_KEYMAP and UKBD_DFLT_KEYMAP. > But I see some problematic cases in the way the neccessarry header > files gets generated. > > First, I think that reading keymaps from the machine's installed > maps instead of the ones which are in the sources is not optimal. > Maybe it was intentional set to read machine's keymaps to be able > to compile a kernel without userland sources?!? But since 9k6 > Modems and ctm are obsolete, I can see no good reason any more. The kbdcontrol command works without sources, and the "-L" option just loads the keymap definition as if it was to installed with "-l", but dumps it to stdout as a C struct, instead. > Next is that buildkernel depends on kbdcontrol(1) on the build > machine. Don't know actually how this can be improoved, one must be > able to compile a kernel without userland, so there's most likely > no obj tree where we could use another kbdcontrol(1). I do not see the problem, here. You can move the keymap file to the build machine, if it is not already there. You can even put it in any arbitrary directory, it does not need to be in vt/keymaps or in a source directory. > But my real problem is, that my building machine has to have the > same console like the one, I build a kernel for. Really? I think you can just put the keymap file you want included into the kernel at an arbitrary place, put e.g. options ATKBD_DFLT_KEYMAP="de" r, for a locally developed keymap at a non-standard place options ATKBD_DFLT_KEYMAP="/path/to/keymap/file.kbd" into the kernel configuration and build and install the kernel just as if it contained the default keymap definition. (But I just naively tried this on my system and the file atkbdmap.h did not get generated - while the command in /sys/conf/files.amd does work and can be used to generated the file by hand. I did not have time to look into this, yet. But this appears to be a problem with the options processing performed by config and there should not be any difference whether using syscons or vt.) > I guess searching in both paths (syscons/keymaps/ & vt/keymaps) if > KEYMAP_PATH is not defined should be implemented (in > ys/conf/files.arch) if the way the header files gets generated is > the right one. No, the syscons keymaps have been converted (but I forgot to install the fr.kbs and fr.acc.kbd - this will be fixed in 10.1-BETA2). If you find errors in any of the files in vt/keymaps then please report them to me, t get them fixed before 10.1 is released. > What would habben if I compiled a syscons default keymap into the > kernel and use vt? Or vice versa? For ISO-8859-1 keymaps, this should just work. For all other syscons encodings, you'll get wrong symbols on "special" keys (i.e., if the encoding includes ASCII in the first half of the map, then the ASCII characters will work and the rest will probably return garbage - for non-ISO encodings you'll probably just get garbage ...). Regards, STefan From owner-freebsd-stable@FreeBSD.ORG Mon Sep 15 13:59:40 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61D5CED5; Mon, 15 Sep 2014 13:59:40 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (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 CF8FB679; Mon, 15 Sep 2014 13:59:39 +0000 (UTC) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s8FDxanS068594; Mon, 15 Sep 2014 15:59:36 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 938D73AE1; Mon, 15 Sep 2014 15:59:35 +0200 (CEST) Message-ID: <5416F0B1.1020200@omnilan.de> Date: Mon, 15 Sep 2014 15:59:13 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Stefan Esser Subject: Re: option *KB*_DFLT_KEYMAP and *map.h in sys/conf/files References: <54158866.2050901@omnilan.de> <5416BF7A.1080301@freebsd.org> In-Reply-To: <5416BF7A.1080301@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2851DC6C1412F930EDD68781" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Mon, 15 Sep 2014 15:59:36 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 13:59:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2851DC6C1412F930EDD68781 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bez=C3=BCglich Stefan Esser's Nachricht vom 15.09.2014 12:29 (localtime)= : > Am 14.09.2014 um 14:21 schrieb Harald Schmalzbauer: >> Hello, >> >> currently I can't compile a kernel on a 10-stable machine with=20 >> differtent default keymap. Reason is, that the k*map.h file gets >> generated at compile time, coded in sys/conf/files.arch. >> >> For any reason, on my 10-stable build machine, kbdcontrol(1) does >> look for maps in /usr/share/vt/keymaps, although >> usr.sbin/kbdcontrol/path.h has #define KEYMAP_PATH >> "/usr/share/syscons/keymaps/ I guess it's because I have >> kern.vty=3Dvt > Hallo Harald, > > did you look for keymap files in vt/keymaps, recently? > > Most of the syscons keymap files have been converted for use with > vt. Since vt uses unicode instead of locale dependent encodings, > most keymap files got renamed (and the naming scheme got somewhat > more regular). > > For ISO-8859-1 keymaps, the syscons keymaps can be used without > any change (since the first 256 Unicode code points are just the > ISO-8859-1 characters), but for other encodings a Perl script in > tools/tools/vt/keymaps should be able to do the conversion. You > should not assume, that syscons/keymaps files work with vt, but > as said, for ISO-8859-1 (only!) they just work- Hello, I followed the keymap conversion for vt; thanks for your contribution! But I don't have any problems with vt keymaps or vt at all. >> Further guess is that I can build the kernel by setting 'env=20 >> KEYMAP_PATH=3D/usr/share/syscons/keymaps' for kernel configs having=20 >> *KB*_DFLT_KEYMAP set to syscons keymap name. > You could, but why don't you just use the correct keymap name > as found in vt/keymaps? > > And BTW: Did you really use KB_DFLT_KEYMAP??? I'm trying to compile a 9.2/9.3 kernel on 10-stable, so I want the _syscons_ keymaps, _not_ the vt one. That's why I leave them named like they've always been. But kbdcontrol doesn't find them on my vt-driven build host (which I'll get to after the following quote). > # config TEST > # TEST: unknown option "KB_DFLT_KEYMAP" > > Valid keymap options are ATKBD_DFLT_KEYMAP and UKBD_DFLT_KEYMAP. Actually I'm using KBDMUX_DFLT_KEYMAP, since UKBD_DFLT_KEYMAP and ATKBD_DFLT_KEYMAP don't make too much sense since kbdmux arose (and was enabled by default). It works just the way like UKBD_DFLT_KEYMAP. I'm using it for several years now. Seems nobody else uses any of the '^.*KBD.*_DFLT_KEYMAP$' (which I have incorrectly expressed with *KB*_DFLT_KEYMAP in my first post) option, otherwise KBDMUX_DFLT_KEYMAP would have been comitted (there are PRs about that, don't have them handy). >> But I see some problematic cases in the way the neccessarry header >> files gets generated. >> >> First, I think that reading keymaps from the machine's installed >> maps instead of the ones which are in the sources is not optimal.=20 >> Maybe it was intentional set to read machine's keymaps to be able >> to compile a kernel without userland sources?!? But since 9k6 >> Modems and ctm are obsolete, I can see no good reason any more. > The kbdcontrol command works without sources, and the "-L" option > just loads the keymap definition as if it was to installed with "-l", > but dumps it to stdout as a C struct, instead. Right, kbdcontrol works without sources, but compling FreeBSD doesn't work without sources ;-) And probably someone would like to cross-compile (like me, version related, not arch!). So since there must be sources available, I'd prefere to see #define KEYMAP_PATH "/usr/src/share/syscons/keymaps/" in "usr.sbin/kbdcontrol/path.h", instead of "/usr/share/syscons/keymaps/". What I'm wondering (and haven't checked yet) why 'kbdcontrol' does look at /usr/share/vt/keymaps on my 10-stable building machine. I guess it's looking at kern.vty to overried the quoted #define above. =E2=80=A6 > For ISO-8859-1 keymaps, this should just work. For all other syscons > encodings, you'll get wrong symbols on "special" keys (i.e., if the > encoding includes ASCII in the first half of the map, then the ASCII > characters will work and the rest will probably return garbage - for > non-ISO encodings you'll probably just get garbage ...). Sorry for my inappropriate expression of my problem. I do know workarrounds for it. But I thought the way the '^[a]*[tu]map.h$' header file gets generated (in sys/conf/files.$arch) could be modified in a way that it looks in both paths for the specified map name (since nobody can know which vty will be used later, so it's the pilot's responsibility to select the appropriate) and doesn't require/rely on the machine's installed keymaps. Instead, I think, it *should* use the ones which come with the source, which I need for the compile job anyway, which would eliminate possible mismatchings and would make more sense in my opinion. Thanks, -Harry --------------enig2851DC6C1412F930EDD68781 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlQW8LYACgkQLDqVQ9VXb8gligCfdWBje8OaSZrQPjFmLU6yKI3/ utMAn1SQV26ZATrw/3utv6Pta1zmApWg =Ju6G -----END PGP SIGNATURE----- --------------enig2851DC6C1412F930EDD68781-- From owner-freebsd-stable@FreeBSD.ORG Mon Sep 15 15:15:02 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B120BBB1; Mon, 15 Sep 2014 15:15:02 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 9F418F7F; Mon, 15 Sep 2014 15:15:02 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id E0C49C97; Mon, 15 Sep 2014 15:15:02 +0000 (UTC) Date: Mon, 15 Sep 2014 15:15:01 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-stable@freebsd.org, trasz@FreeBSD.org, brueffer@FreeBSD.org Message-ID: <343459318.2.1410794102743.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_stable_10 #753 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 15:15:02 -0000 See Changes: [trasz] MFC r271169: Turn two errors, which are possible to trigger only by bugs, into assertions. Approved by: re (gjb) Sponsored by: The FreeBSD Foundation [trasz] MFC r271157: Fix typo. Approved by: re (marius) Sponsored by: The FreeBSD Foundation [trasz] MFC r271436: Fix typo. Approved by: re (marius) Sponsored by: The FreeBSD Foundation [trasz] MFC r271317: Avoid unlocking unlocked mutex in RCTL jail code. Specific test case is attached to PR. PR: 193457 Approved by: re (kib) Sponsored by: The FreeBSD Foundation [brueffer] MFC: r271286 Use the right constants in comparisons. This is currently a nop, as MIN_RXD == MIN_TXD and MAX_RXD == MAX_TXD. Reviewed by: Eric Joyner @ Intel Approved by: re (kib) ------------------------------------------ [...truncated 6800 lines...] --- lib.cleandir__D --- --- cleandir_subdir_clang --- --- cleandir_subdir_libllvminstrumentation --- --- usr.bin.cleandir__D --- --- cleandir_subdir_bzip2 --- --- share.cleandir__D --- ===> share/examples/smbfs (cleandir) --- lib.cleandir__D --- ===> lib/clang/libllvminstrumentation (cleandir) --- usr.bin.cleandir__D --- ===> usr.bin/bzip2 (cleandir) --- lib.cleandir__D --- --- cleandir_subdir_libbsnmp --- --- cleanobj --- --- share.cleandir__D --- --- _sub.clean --- ===> share/examples/smbfs/print (clean) --- usr.bin.cleandir__D --- --- cleanobj --- --- lib.cleandir__D --- --- cleandir_subdir_libcam --- ===> lib/libcam (cleandir) --- cleandir_subdir_clang --- --- cleanobj --- --- usr.bin.cleandir__D --- --- cleandir_subdir_bzip2recover --- --- share.cleandir__D --- --- _sub.cleandepend --- --- usr.bin.cleandir__D --- ===> usr.bin/bzip2recover (cleandir) --- share.cleandir__D --- ===> share/examples/smbfs/print (cleandepend) --- _sub.cleandir --- ===> share/examples/smbfs/print (cleandir) --- lib.cleandir__D --- --- cleandir_subdir_libcam --- --- cleanobj --- --- share.cleandir__D --- --- cleanobj --- --- usr.bin.cleandir__D --- --- cleanobj --- --- lib.cleandir__D --- --- cleandir_subdir_clang --- --- cleandir_subdir_libllvmipa --- --- share.cleandir__D --- --- cleanobj --- --- lib.cleandir__D --- ===> lib/clang/libllvmipa (cleandir) --- share.cleandir__D --- ===> share/examples/ipfilter (cleandir) --- usr.bin.cleandir__D --- --- cleandir_subdir_c89 --- --- lib.cleandir__D --- --- cleandir_subdir_libllvmipo --- --- usr.bin.cleandir__D --- ===> usr.bin/c89 (cleandir) --- lib.cleandir__D --- ===> lib/clang/libllvmipo (cleandir) --- share.cleandir__D --- --- cleanobj --- ===> share/examples/pf (cleandir) --- lib.cleandir__D --- --- cleandir_subdir_libllvmipa --- --- cleanobj --- --- usr.bin.cleandir__D --- --- cleanobj --- --- share.cleandir__D --- --- cleanobj --- --- usr.bin.cleandir__D --- --- cleandir_subdir_c99 --- --- share.cleandir__D --- ===> share/i18n (cleandir) --- lib.cleandir__D --- --- cleandir_subdir_libgeom --- --- usr.bin.cleandir__D --- ===> usr.bin/c99 (cleandir) --- lib.cleandir__D --- ===> lib/libgeom (cleandir) --- share.cleandir__D --- --- _sub.cleandir --- --- lib.cleandir__D --- --- cleandir_subdir_clang --- --- cleandir_subdir_libllvmipo --- --- cleanobj --- --- share.cleandir__D --- ===> share/i18n/csmapper (cleandir) --- usr.bin.cleandir__D --- --- cleanobj --- --- lib.cleandir__D --- --- cleandir_subdir_libgeom --- --- cleanobj --- --- cleandir_subdir_clang --- --- cleandir_subdir_libllvmirreader --- --- usr.bin.cleandir__D --- --- cleandir_subdir_calendar --- --- lib.cleandir__D --- --- cleandir_subdir_libllvmlinker --- --- cleandir_subdir_libllvmirreader --- ===> lib/clang/libllvmirreader (cleandir) --- usr.bin.cleandir__D --- ===> usr.bin/calendar (cleandir) --- share.cleandir__D --- --- cleanobj --- --- lib.cleandir__D --- --- cleandir_subdir_libllvmlinker --- ===> lib/clang/libllvmlinker (cleandir) --- usr.bin.cleandir__D --- --- cleanobj --- --- lib.cleandir__D --- --- cleandir_subdir_libllvmirreader --- --- cleanobj --- --- usr.bin.cleandir__D --- --- cleandir_subdir_cap_mkdb --- --- lib.cleandir__D --- --- cleandir_subdir_libllvmlinker --- --- cleanobj --- --- usr.bin.cleandir__D --- ===> usr.bin/cap_mkdb (cleandir) --- share.cleandir__D --- --- _sub.cleandir --- ===> share/i18n/csmapper/APPLE (cleandir) --- lib.cleandir__D --- --- cleandir_subdir_libllvmmc --- --- usr.bin.cleandir__D --- --- cleanobj --- --- lib.cleandir__D --- ===> lib/clang/libllvmmc (cleandir) --- usr.bin.cleandir__D --- --- cleandir_subdir_catman --- ===> usr.bin/catman (cleandir) --- cleanobj --- --- cleandir_subdir_chat --- ===> usr.bin/chat (cleandir) --- share.cleandir__D --- --- cleanobj --- --- usr.bin.cleandir__D --- --- cleanobj --- --- share.cleandir__D --- ===> share/i18n/csmapper/AST (cleandir) --- lib.cleandir__D --- --- cleanobj --- --- usr.bin.cleandir__D --- --- cleandir_subdir_checknr --- ===> usr.bin/checknr (cleandir) --- lib.cleandir__D --- --- cleandir_subdir_libllvmmcparser --- --- share.cleandir__D --- --- clean --- --- lib.cleandir__D --- ===> lib/clang/libllvmmcparser (cleandir) --- share.cleandir__D --- rm -f mapper.dir.AST charset.pivot.AST ARMSCII-7%UCS.mps UCS%ARMSCII-7.mps ARMSCII-8%UCS.mps UCS%ARMSCII-8.mps ARMSCII-8A%UCS.mps UCS%ARMSCII-8A.mps --- usr.bin.cleandir__D --- --- cleanobj --- --- share.cleandir__D --- --- cleanobj --- ===> share/i18n/csmapper/BIG5 (cleandir) --- usr.bin.cleandir__D --- --- cleandir_subdir_chkey --- ===> usr.bin/chkey (cleandir) --- lib.cleandir__D --- --- cleanobj --- --- share.cleandir__D --- --- cleanobj --- ===> share/i18n/csmapper/CNS (cleandir) --- cleanobj --- rm: fts_read: No such file or directory *** [cleanobj] Error code 1 make[5]: stopped in --- lib.cleandir__D --- A failure has been detected in another branch of the parallel make make[5]: stopped in --- usr.bin.cleandir__D --- A failure has been detected in another branch of the parallel make make[4]: stopped in --- lib.cleandir__D --- *** [cleandir_subdir_libllvmmcparser] Error code 2 make[4]: stopped in 1 error make[4]: stopped in --- usr.bin.cleandir__D --- *** [cleandir_subdir_chkey] Error code 2 make[3]: stopped in 1 error make[3]: stopped in --- lib.cleandir__D --- *** [cleandir_subdir_clang] Error code 2 make[3]: stopped in --- usr.bin.cleandir__D --- *** [usr.bin.cleandir__D] Error code 2 make[2]: stopped in --- lib.cleandir__D --- 1 error make[3]: stopped in *** [lib.cleandir__D] Error code 2 make[2]: stopped in --- share.cleandir__D --- --- _sub.cleandir --- A failure has been detected in another branch of the parallel make make[6]: stopped in *** [_sub.cleandir] Error code 2 make[5]: stopped in 2 errors make[5]: stopped in *** [_sub.cleandir] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [_sub.cleandir] Error code 2 make[3]: stopped in 1 error make[3]: stopped in *** [share.cleandir__D] Error code 2 make[2]: stopped in 3 errors make[2]: stopped in *** [_cleanobj] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildworld] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-stable@FreeBSD.ORG Mon Sep 15 15:55:38 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7447555D for ; Mon, 15 Sep 2014 15:55:38 +0000 (UTC) Received: from nicandneal.net (nicandneal.net [194.231.42.198]) (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 CFC2D803 for ; Mon, 15 Sep 2014 15:55:37 +0000 (UTC) Received: from bollo2.home ([10.0.0.3]) (AUTH: LOGIN nealie, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by nicandneal.net with ESMTPSA; Mon, 15 Sep 2014 17:50:24 +0200 id 00005C19.0000000054170AC0.00017E52 Message-ID: <54170AB6.4010904@nicandneal.net> Date: Mon, 15 Sep 2014 17:50:14 +0200 From: Neal Nelson User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: FreeBSD 10.1 BETA 1 on MacBook Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 15:55:38 -0000 Hi all. I've been trying to install FreeBSD 10.1 BETA1 on a MacBook Pro as part of a dual boot environment. I used to be able to install FreeBSD before 10.0, but not since. I was told this was an EFI problem, so I have tried to make an EFI installation, which the installer doesn't seem to do. Anyway, I am able to do an EFI boot using rEFInd which loads the loader and kernel quite happily, but when it tried to boot the kernel I get: Booting [/boot/kernel/kernel]... Start @ 0xffffffff802d8990 ... And then nothing else happens. Has anyone got this working? Does it even make sense me trying to get this working, since I am unable to get a bootable system using the installer. Should dual booting on a Mac work these days >= 10.0? Thanks, Neal. From owner-freebsd-stable@FreeBSD.ORG Mon Sep 15 19:31:36 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A73EB4E2; Mon, 15 Sep 2014 19:31:36 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 96225348; Mon, 15 Sep 2014 19:31:36 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id D7BA6CF1; Mon, 15 Sep 2014 19:31:36 +0000 (UTC) Date: Mon, 15 Sep 2014 19:31:35 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-stable@freebsd.org, emaste@FreeBSD.org, trasz@FreeBSD.org, brueffer@FreeBSD.org Message-ID: <1162470040.4.1410809496857.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <343459318.2.1410794102743.JavaMail.jenkins@jenkins-9.freebsd.org> References: <343459318.2.1410794102743.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_stable_10 #754 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 19:31:36 -0000 See From owner-freebsd-stable@FreeBSD.ORG Tue Sep 16 03:32:54 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 82303D2D for ; Tue, 16 Sep 2014 03:32:54 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (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 5D434A52 for ; Tue, 16 Sep 2014 03:32:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=aG+bTZusbRd7CNeK44w0Qzfk0f7Dcp/gU36g8baZLn8=; b=Nbfs5DFzkaTCreucUkdrA5Z6mn6c6nxMDxDHRmQl+wi4zFkJmRBwravoXSsSs0W5ZgbprVjh153fnG6w0Ag4q6NP9aJEikPrfy0V3Ir+ngHbn1a6o8qkDJrQtppziTokGAmopaXAsfGFxLBVz72T4NJ3Y9pdeC//CDgW019Z0yc=; Received: from [114.121.128.87] (port=59337 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XTjVc-002mV8-A0 for freebsd-stable@freebsd.org; Mon, 15 Sep 2014 21:32:53 -0600 Date: Tue, 16 Sep 2014 11:32:47 +0800 From: Erich Dollansky To: freebsd-stable Subject: mq_open fails when message queue attributes are set Message-ID: <20140916113247.7158a96d@X220.alogt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 03:32:54 -0000 Hi, I try to use message queues but do not have much luck yet. I initialised Attributes like this: char Message [1024]; memset (&Attributes, 0, sizeof (Attributes)); Attributes.mq_maxmsg = 1024; Attributes.mq_msgsize = sizeof (Message); The following code fails: Queue = mq_open ("/testqueue", O_RDWR | O_CREAT | O_EXCL, 644, &Attributes); errno is set to 22 (Invalid argument). When I replace &Attributes with NULL, it will work. The size of Message does not matter. My old error not having the message queues in the kernel is corrected. What do I miss? Erich From owner-freebsd-stable@FreeBSD.ORG Tue Sep 16 03:52:12 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7A545FC3 for ; Tue, 16 Sep 2014 03:52:12 +0000 (UTC) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::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 12C90BFC for ; Tue, 16 Sep 2014 03:52:11 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id u56so4932854wes.10 for ; Mon, 15 Sep 2014 20:52:10 -0700 (PDT) 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=4tMEGAZUJj24SLc0eTeXzjy7oNQbIgghrbXeQw2WtKA=; b=lKd3JELSYl5RRb5GLgak5vYg1xJoB1fNQ82J7yWkQFlumaXethdhHR6NY7Kw4DWMlm zLk3I+ZxilrQHz9/8NL2Lms5dqrbBnDKYN8KbqN18ky5OnWUnuWEyU1TaqwWfwjXx59u vZ7DYBzVTVXe4o+jMAEMli08l8aFbvo/FljR723fY61EitNtKX78JZYrfvTrXIryt9mQ N1wCNN0lQDIv8dvLTF9PUtg/YW+Pp+UImpdkGFglEQHEaWD5gBzXFJTtE3N8uvpvPGOi efCztHvRpTVuA5YVr38tiREutpwe2O+S3iRNm3rpO5TTyxVmL4qvN2nzN9rVUpkAfjL7 8y9Q== MIME-Version: 1.0 X-Received: by 10.181.5.38 with SMTP id cj6mr29457971wid.53.1410839530237; Mon, 15 Sep 2014 20:52:10 -0700 (PDT) Received: by 10.217.2.18 with HTTP; Mon, 15 Sep 2014 20:52:10 -0700 (PDT) In-Reply-To: <20140916113247.7158a96d@X220.alogt.com> References: <20140916113247.7158a96d@X220.alogt.com> Date: Mon, 15 Sep 2014 23:52:10 -0400 Message-ID: Subject: Re: mq_open fails when message queue attributes are set From: Brandon Allbery To: Erich Dollansky Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 03:52:12 -0000 On Mon, Sep 15, 2014 at 11:32 PM, Erich Dollansky < erichsfreebsdlist@alogt.com> wrote: > Attributes.mq_maxmsg = 1024; > It looks like the maximum value allowed here is 100 by default. (sysctl kern.mqueue.maxmsg) -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From owner-freebsd-stable@FreeBSD.ORG Tue Sep 16 04:06:10 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 353F1468 for ; Tue, 16 Sep 2014 04:06:10 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (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 0E6FACEC for ; Tue, 16 Sep 2014 04:06:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=dZ1E2C36U82p5bEGNMs1zs5b+T3s+s8eyGXhbuzcxR8=; b=GglowUDYDD6ZQZHtKYbuf9cMGUBnadWVXcVYKj4ouCCKGKY0crUVG8+9zOrCnyA+OChQBMtnVR+zW0K5ArAAk4kCgXG/rqJzxkPgNt4r9dz463hw7Q0Zw0SvvbtBukdTq43NX/G73okRUzUKvLqDX5AtoV3y23bsQCthpRas4JM=; Received: from [114.121.128.87] (port=61125 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XTk1n-002ylx-1x; Mon, 15 Sep 2014 22:06:09 -0600 Date: Tue, 16 Sep 2014 12:06:02 +0800 From: Erich Dollansky To: Brandon Allbery Subject: Re: mq_open fails when message queue attributes are set Message-ID: <20140916120602.2f1dc123@X220.alogt.com> In-Reply-To: References: <20140916113247.7158a96d@X220.alogt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 04:06:10 -0000 Hi, On Mon, 15 Sep 2014 23:52:10 -0400 Brandon Allbery wrote: > On Mon, Sep 15, 2014 at 11:32 PM, Erich Dollansky < > erichsfreebsdlist@alogt.com> wrote: > > > Attributes.mq_maxmsg = 1024; > > > > It looks like the maximum value allowed here is 100 by default. > (sysctl kern.mqueue.maxmsg) > yes, this seems to be the problem. I have taken a very old program of mine from a different platform as the starting point. So, I took all changes I made as the possible cause without any result.Just this value was not changed. Anyway, thanks for your help. Erich From owner-freebsd-stable@FreeBSD.ORG Tue Sep 16 05:57:30 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE6D21CC; Tue, 16 Sep 2014 05:57:30 +0000 (UTC) Received: from mailout09.t-online.de (mailout09.t-online.de [194.25.134.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 891DF85C; Tue, 16 Sep 2014 05:57:30 +0000 (UTC) Received: from fwd25.aul.t-online.de (fwd25.aul.t-online.de [172.20.26.130]) by mailout09.t-online.de (Postfix) with SMTP id D64F4543553; Tue, 16 Sep 2014 07:57:27 +0200 (CEST) Received: from [192.168.119.33] (ThReDqZdrhUnmiL2jVstT5erYr1+IlBFebYUCZSkJ5Sa9GFK1RpL9Rs9+BG9arbg84@[84.154.101.219]) by fwd25.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XTllM-1mYlA80; Tue, 16 Sep 2014 07:57:16 +0200 Message-ID: <5417D137.6030303@freebsd.org> Date: Tue, 16 Sep 2014 07:57:11 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Harald Schmalzbauer Subject: Re: option *KB*_DFLT_KEYMAP and *map.h in sys/conf/files References: <54158866.2050901@omnilan.de> <5416BF7A.1080301@freebsd.org> <5416F0B1.1020200@omnilan.de> In-Reply-To: <5416F0B1.1020200@omnilan.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ID: ThReDqZdrhUnmiL2jVstT5erYr1+IlBFebYUCZSkJ5Sa9GFK1RpL9Rs9+BG9arbg84 X-TOI-MSGID: d2d2e81b-a9d6-4111-867d-67f1a8a1e7da Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 05:57:31 -0000 Am 15.09.2014 um 15:59 schrieb Harald Schmalzbauer: > Bezüglich Stefan Esser's Nachricht vom 15.09.2014 12:29 (localtime): > I'm trying to compile a 9.2/9.3 kernel on 10-stable, so I want the > _syscons_ keymaps, _not_ the vt one. That's why I leave them named like > they've always been. But kbdcontrol doesn't find them on my vt-driven > build host (which I'll get to after the following quote). > >> # config TEST >> # TEST: unknown option "KB_DFLT_KEYMAP" >> >> Valid keymap options are ATKBD_DFLT_KEYMAP and UKBD_DFLT_KEYMAP. > > Actually I'm using KBDMUX_DFLT_KEYMAP, since UKBD_DFLT_KEYMAP and > ATKBD_DFLT_KEYMAP don't make too much sense since kbdmux arose (and was > enabled by default). > It works just the way like UKBD_DFLT_KEYMAP. I'm using it for several > years now. Seems nobody else uses any of the '^.*KBD.*_DFLT_KEYMAP$' > (which I have incorrectly expressed with *KB*_DFLT_KEYMAP in my first > post) option, otherwise KBDMUX_DFLT_KEYMAP would have been comitted > (there are PRs about that, don't have them handy). Yes, it seems that nobody compiles non-standard keyboards into the kernel. I tried again, but neither the traditional way to build the kernel (with "config") nor "make buildkernel" in /usr/src created the required include file(s) "atkbdmap.h" or "ukbdmap.h" seem to work on -CURRENT. I do not have time to diagnose this problem, though. [...] > Right, kbdcontrol works without sources, but compling FreeBSD doesn't > work without sources ;-) > And probably someone would like to cross-compile (like me, version > related, not arch!). > So since there must be sources available, I'd prefere to see > #define KEYMAP_PATH "/usr/src/share/syscons/keymaps/" > in "usr.sbin/kbdcontrol/path.h", > instead of "/usr/share/syscons/keymaps/". > > What I'm wondering (and haven't checked yet) why 'kbdcontrol' does look > at /usr/share/vt/keymaps on my 10-stable building machine. I guess it's > looking at kern.vty to overried the quoted #define above. Yes, kbdcontrol checks sysctl kern.vty and selects the vt specific paths if this value is defined and is equal to "vt". While clearly correct for "kbdcontrol -l" (which loads and activates) the keymap, it is not correct in the scenario you describe (if you build a kernel to be used with syscons on a system that uses vt). While it is possible to add an option that overrides the automatic selection of syscons vs. vt paths, I rather think you use what's there and either use the KEYMAP_PATH environment variable or that you specify the full path name of the keymap file. Both methods allow you to specify a keymap file in a source directory. >> For ISO-8859-1 keymaps, this should just work. For all other syscons >> encodings, you'll get wrong symbols on "special" keys (i.e., if the >> encoding includes ASCII in the first half of the map, then the ASCII >> characters will work and the rest will probably return garbage - for >> non-ISO encodings you'll probably just get garbage ...). > > Sorry for my inappropriate expression of my problem. > I do know workarrounds for it. > But I thought the way the '^[a]*[tu]map.h$' header file gets generated > (in sys/conf/files.$arch) could be modified in a way that it looks in > both paths for the specified map name (since nobody can know which vty > will be used later, so it's the pilot's responsibility to select the > appropriate) and doesn't require/rely on the machine's installed > keymaps. Instead, I think, it *should* use the ones which come with the > source, which I need for the compile job anyway, which would eliminate > possible mismatchings and would make more sense in my opinion. IMHO the use cases for non-default compiled in keymaps are limited to special purpose or embedded systems, where you need to specify a very non-standard keyboard layout and require that to be available in single-user mode, or where you want to omit the kbdcontrol command in a stripped down custom build. In either case, the use of a full path name to the keymap file in the kernel config file seems to be the best way to select just the specific keymap file required. For "normal" systems, the loading of the keymap during startup seems to be the most flexible approach and the overhead is small. You just have to remember to load your keymap when booting into single-user mode. A fsck failure might lead to unexpected single-user mode and it may come as a surprise to novice a user, that his preferred keymap has not been loaded at that point in time (which may be a little bit annoying because of QWERTZ vs. QWERTY and questions that need to be answered with "y"), but the current mechanism works just fine, if you build your kernel on the system it is meant to be used on ... A fix could be to generate the header files separately for syscons and vt (f.e. specified as SYSCONS_DFLT_KEYMAP and VT_DFLT_KEYMAP) and to let the console driver use the appropriate one when it is activated during start-up. But I'm not convinced, that the effort would be well spent ... Regards, STefan From owner-freebsd-stable@FreeBSD.ORG Wed Sep 17 06:01:54 2014 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9AA96639; Wed, 17 Sep 2014 06:01:54 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 868DBA31; Wed, 17 Sep 2014 06:01:49 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA22736; Wed, 17 Sep 2014 09:01:47 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1XU8JH-0008p6-68; Wed, 17 Sep 2014 09:01:47 +0300 Message-ID: <5419238E.8050708@FreeBSD.org> Date: Wed, 17 Sep 2014 09:00:46 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: freebsd-stable List , FreeBSD Current Subject: Fwd: usb printer vs cups References: <54133325.9070302@FreeBSD.org> In-Reply-To: <54133325.9070302@FreeBSD.org> X-Forwarded-Message-Id: <54133325.9070302@FreeBSD.org> Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: freebsd-desktop@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 06:01:54 -0000 Soliciting help. -------- Forwarded Message -------- >From my experience I think that cupsd executes backend tools with all uids and gids set to cups and no supplementary groups. In the case of USB printers the backends need to access /dev/usbctl and /dev/usb/foobar that corresponds to a printer. That means that the access to those devices must be somehow granted to cups:cups. How do people solve this? What kind of permissions / configuration do you use? P.S. Maybe I over-generalized the issue to all USB printers. My personal experience is with an HP printer handled by hplip / hplip-plugin. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Sep 17 06:21:32 2014 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 27A07C39; Wed, 17 Sep 2014 06:21:32 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D73BCC35; Wed, 17 Sep 2014 06:21:31 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id AC2D524800B; Wed, 17 Sep 2014 08:21:28 +0200 (CEST) Message-ID: <5419285D.8020909@selasky.org> Date: Wed, 17 Sep 2014 08:21:17 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Andriy Gapon , freebsd-stable List , FreeBSD Current Subject: Re: Fwd: usb printer vs cups References: <54133325.9070302@FreeBSD.org> <5419238E.8050708@FreeBSD.org> In-Reply-To: <5419238E.8050708@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------040608000705010201090203" Cc: freebsd-desktop@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 06:21:32 -0000 This is a multi-part message in MIME format. --------------040608000705010201090203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/17/14 08:00, Andriy Gapon wrote: > > Soliciting help. > > -------- Forwarded Message -------- > >>From my experience I think that cupsd executes backend tools with all uids and > gids set to cups and no supplementary groups. In the case of USB printers the > backends need to access /dev/usbctl and /dev/usb/foobar that corresponds to a > printer. That means that the access to those devices must be somehow granted to > cups:cups. > How do people solve this? What kind of permissions / configuration do you use? > > P.S. > Maybe I over-generalized the issue to all USB printers. My personal experience > is with an HP printer handled by hplip / hplip-plugin. > Hi, The /usr/ports/print/cups-base should be updated. The pkg-message should not say that: # FreeBSD 8.x add path 'usb*' mode 0770 group cups add path 'ugen*' mode 0660 group cups add path 'usb/0.2.*' mode 0660 group cups Is needed. This is wrong. Instead make cups-base install the attached devd configuration file in /usr/local/etc/devd/ which does the needed chown for printers only. --HPS --------------040608000705010201090203 Content-Type: text/plain; charset=us-ascii; name="cups.conf.in" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cups.conf.in" # Generic USB printer devices notify 100 { match "system" "USB"; match "subsystem" "INTERFACE"; match "type" "ATTACH"; match "intclass" "0x07"; match "intsubclass" "0x01"; match "intprotocol" "(0x01|0x02|0x03)"; action "chown cups:cups /dev/$cdev"; }; --------------040608000705010201090203-- From owner-freebsd-stable@FreeBSD.ORG Wed Sep 17 06:57:21 2014 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C1DEF699; Wed, 17 Sep 2014 06:57:21 +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 871B3F4B; Wed, 17 Sep 2014 06:57:20 +0000 (UTC) Received: from [192.168.0.7] (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 s8H6vFed008803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Sep 2014 06:57:17 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.7] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: usb printer vs cups From: David Chisnall In-Reply-To: <5419238E.8050708@FreeBSD.org> Date: Wed, 17 Sep 2014 07:57:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54133325.9070302@FreeBSD.org> <5419238E.8050708@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-stable List , FreeBSD Current , freebsd-desktop@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 06:57:21 -0000 There are a couple of similar issues currently. The other one that = comes to mind is that every X11 application that needs to use OpenGL (or = similar) must open /dev/dri/{something}, but the default permissions = only permit root. The correct solution is probably to ship a devfs.conf that puts these = devices in the a sensible group. For USB printers, we should probably = have a printers group and make cupsd run with that group (or set the GUI = of cups and printers to the same number if that's too difficult). =20 David On 17 Sep 2014, at 07:00, Andriy Gapon wrote: >=20 > Soliciting help. >=20 > -------- Forwarded Message -------- >=20 > =46rom my experience I think that cupsd executes backend tools with = all uids and > gids set to cups and no supplementary groups. In the case of USB = printers the > backends need to access /dev/usbctl and /dev/usb/foobar that = corresponds to a > printer. That means that the access to those devices must be somehow = granted to > cups:cups. > How do people solve this? What kind of permissions / configuration do = you use? >=20 > P.S. > Maybe I over-generalized the issue to all USB printers. My personal = experience > is with an HP printer handled by hplip / hplip-plugin. > --=20 > Andriy Gapon >=20 >=20 > _______________________________________________ > 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-stable@FreeBSD.ORG Wed Sep 17 07:05:24 2014 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB2FBA46; Wed, 17 Sep 2014 07:05:24 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C8BE8C2; Wed, 17 Sep 2014 07:05:22 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA23590; Wed, 17 Sep 2014 10:05:21 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1XU9Im-0008tO-Ks; Wed, 17 Sep 2014 10:05:20 +0300 Message-ID: <54193273.6080709@FreeBSD.org> Date: Wed, 17 Sep 2014 10:04:19 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Hans Petter Selasky , freebsd-stable List , FreeBSD Current Subject: Re: Fwd: usb printer vs cups References: <54133325.9070302@FreeBSD.org> <5419238E.8050708@FreeBSD.org> <5419285D.8020909@selasky.org> In-Reply-To: <5419285D.8020909@selasky.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: freebsd-desktop@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 07:05:25 -0000 On 17/09/2014 09:21, Hans Petter Selasky wrote: > On 09/17/14 08:00, Andriy Gapon wrote: >> >> Soliciting help. >> >> -------- Forwarded Message -------- >> >>> From my experience I think that cupsd executes backend tools with all uids and >> gids set to cups and no supplementary groups. In the case of USB printers the >> backends need to access /dev/usbctl and /dev/usb/foobar that corresponds to a >> printer. That means that the access to those devices must be somehow granted to >> cups:cups. >> How do people solve this? What kind of permissions / configuration do you use? >> >> P.S. >> Maybe I over-generalized the issue to all USB printers. My personal experience >> is with an HP printer handled by hplip / hplip-plugin. >> > > Hi, > > The /usr/ports/print/cups-base should be updated. > > The pkg-message should not say that: > > > # FreeBSD 8.x > add path 'usb*' mode 0770 group cups > add path 'ugen*' mode 0660 group cups > > add path 'usb/0.2.*' mode 0660 group cups > > Is needed. This is wrong. > > Instead make cups-base install the attached devd configuration file in > /usr/local/etc/devd/ which does the needed chown for printers only. The problem is that my printer does not work if I also do not change permissions on /dev/usbctl. But I do not really want /dev/usbctl to be owned by cups as there can be other services / users that need access to usbctl. Is there anything smarter than mucking with device ownership? In other words, I have no problem granting cups user or group a full access to all USB devices. I have a problem with changing owner or group of USB devices to cups, because that interferes with other accesses to those devices. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Sep 17 07:25:05 2014 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 917CD320; Wed, 17 Sep 2014 07:25:05 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7C5E62DF; Wed, 17 Sep 2014 07:25:04 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA23826; Wed, 17 Sep 2014 10:25:03 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1XU9bq-0008ud-M1; Wed, 17 Sep 2014 10:25:02 +0300 Message-ID: <5419372A.2050509@FreeBSD.org> Date: Wed, 17 Sep 2014 10:24:26 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Hans Petter Selasky , freebsd-stable List , FreeBSD Current Subject: Re: Fwd: usb printer vs cups References: <54133325.9070302@FreeBSD.org> <5419238E.8050708@FreeBSD.org> <5419285D.8020909@selasky.org> <54193273.6080709@FreeBSD.org> In-Reply-To: <54193273.6080709@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: freebsd-desktop@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 07:25:05 -0000 On 17/09/2014 10:04, Andriy Gapon wrote: > On 17/09/2014 09:21, Hans Petter Selasky wrote: >> Instead make cups-base install the attached devd configuration file in >> /usr/local/etc/devd/ which does the needed chown for printers only. > > The problem is that my printer does not work if I also do not change permissions > on /dev/usbctl. But I do not really want /dev/usbctl to be owned by cups as > there can be other services / users that need access to usbctl. Actually I take this back. My /dev/usbctl was not world readable as it should be by default. Not sure why I changed its permissions from 0644 to 0660, probably a litle bit of paranoia. Now that I changed the permissions to 0664 and installed your script printing works without problems. Thanks! > Is there anything smarter than mucking with device ownership? > > In other words, I have no problem granting cups user or group a full access to > all USB devices. I have a problem with changing owner or group of USB devices > to cups, because that interferes with other accesses to those devices. > -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Sep 17 11:04:05 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6AA2BD01; Wed, 17 Sep 2014 11:04:05 +0000 (UTC) Received: from cu01176b.smtpx.saremail.com (cu01176b.smtpx.saremail.com [195.16.151.151]) (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 26D02D6C; Wed, 17 Sep 2014 11:04:04 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop04.sare.net (Postfix) with ESMTPSA id DB04A9DC717; Wed, 17 Sep 2014 13:04:00 +0200 (CEST) From: Borja Marcos Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Oce driver fixes Date: Wed, 17 Sep 2014 13:03:59 +0200 Message-Id: To: Stable Stable , freebsd-net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 11:04:05 -0000 Hello, Back in July there was a discussion on -current about serious problems = with the "oce" driver for Emulex 10 GbE cards. Stefano Garzarella supplied a patch that fixed the problems (at least = for me). Is this patch planned to go to -current and -stable, ideally = before 10.1? At least for me, these Emulex cards were virtually unusable until I = applied Stefano's patch. And from his description of the problem (lack = of proper locking) the errors are serious indeed. This is the link to the discussion. I assumed that someone would push = this so that the fixes would be applied to -stable (and hence the = upcoming 10.1) as well, but it hasn't happened. Sorry for my belated = heads up. The discussion is here: http://lists.freebsd.org/pipermail/freebsd-current/2014-July/050972.html and Stefano's message explaining what he saw is this: http://lists.freebsd.org/pipermail/freebsd-current/2014-July/051193.html Thanks! Borja. From owner-freebsd-stable@FreeBSD.ORG Wed Sep 17 13:37:00 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D722981D for ; Wed, 17 Sep 2014 13:37:00 +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 A5BAAE37 for ; Wed, 17 Sep 2014 13:37:00 +0000 (UTC) Received: by mail-ig0-f171.google.com with SMTP id hn15so139483igb.10 for ; Wed, 17 Sep 2014 06:37:00 -0700 (PDT) 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:cc:content-type; bh=Bv6Lc9TMA5iBDjUOiZ4HuTzqg517AzVMtyXF7gVNZQ0=; b=yD0Fc0hLLBo6VmUPlc1PRX31rbVPpS68tparUFk10LX4+smiV5p1stn3En7XE8c57x 2TCIqVyD6yjcjSzHdAskxWWBQIr5e/erXezmA0ZLeLOq0KjAvjL9MjDFmfSTSYkZTyY/ Fr08ZdHztWzTABr5YnJGfQSw/8dyjWg+LRB9301BnlKp3p42fFQ9iagYzzmXybSGW2ZI BgHKv5fO+8rHNmCBlj4e6e+uq8Cf6KCqKyX5AMKghbslhHuYIVdjs8RXiX27gFnGl6pp KLPXi9lne7vHlRXGb50ZlrK4A92Fpn6Wyk1RPz/gm9BbTXRYlzL2uFuap9bHVpjvSrUF 6VCw== X-Received: by 10.43.68.206 with SMTP id xz14mr4025040icb.33.1410961020003; Wed, 17 Sep 2014 06:37:00 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.44.196 with HTTP; Wed, 17 Sep 2014 06:36:39 -0700 (PDT) In-Reply-To: References: From: Ed Maste Date: Wed, 17 Sep 2014 09:36:39 -0400 X-Google-Sender-Auth: lak4ym7DU0Fm73i-MDo79yL8MnA Message-ID: Subject: Re: UEFI on -stable To: John Nielsen Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable stable , Jonathan Chen X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 13:37:00 -0000 On 5 September 2014 15:47, John Nielsen wrote: > On Sep 5, 2014, at 12:37 PM, Jonathan Chen wrote: > >> I notice that the UEFI code has now been merged to -stable, and I'm >> kinda keen on playing with it. Is there any documentation associated >> with it? >> >> There appears to be a few new files on /boot: boot1.efi, boot1.efifat, >> loader.efi. Since I've already got a system with an EFI System >> Partition, is it as simple as just copying boot1.efi onto it, eg: >> EFI/FreeBSD/boot1.efi >> and configuring the BIOS to use that to boot? > > There's some information on the wiki, including a walk-through of creating a USB image to test EFI booting: https://wiki.freebsd.org/UEFI > > Speaking from only minimal experience, I _think_ you can do what you're asking by copying the loader to the correct path a la > cp loader.efi /mnt/efi/boot/bootx64.efi > > (assuming the EFI partition is on /mnt). Assuming you want to use an EFI boot manager like rEFIt or rEFInd, you do want to install it as Jonathan suggested, and then configure the boot manager to offer it (if necessary). From owner-freebsd-stable@FreeBSD.ORG Thu Sep 18 04:55:02 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 332AF982; Thu, 18 Sep 2014 04:55:02 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 22B479CB; Thu, 18 Sep 2014 04:55:02 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 15A9A336; Thu, 18 Sep 2014 04:55:02 +0000 (UTC) Date: Thu, 18 Sep 2014 04:55:00 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-stable@freebsd.org, emaste@FreeBSD.org, allanjude@FreeBSD.org Message-ID: <1278768251.5.1411016101881.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_stable_10 #765 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 04:55:02 -0000 See Changes: [allanjude] MFC r271445,r271446,r271560: Improve markup and language throughout the ctl.conf man page MFC r271543: Add the new iscsi(4) man page Cross reference it from iscsid(8) and iscsictl(8) Approved by: re (gjb), bcr (mentor) [emaste] MFC Clang debuginfo crash fix r271432: Merge upstream Clang rev 205331 debuginfo crash fix: Debug info: fix a crash when emitting IndirectFieldDecls, which were previously not handled at all. rdar://problem/16348575 r271433: Add clang patch corresponding to r271432 Approved by: re Sponsored by: DARPA, AFRL ------------------------------------------ [...truncated 230567 lines...] --- cleandir_subdir_drm2 --- ===> drm2/radeonkmsfw/VERDE_ce (cleandir) --- cleandir_subdir_libalias --- --- _sub.cleandir --- --- cleandir_subdir_lge --- --- cleanobj --- --- cleandir_subdir_libalias --- ===> libalias/libalias (cleandir) --- cleandir_subdir_le --- --- cleanobj --- --- cleandir_subdir_libiconv --- --- cleandir_subdir_drm2 --- --- cleanobj --- --- cleandir_subdir_libmbpool --- ===> libmbpool (cleandir) --- cleandir_subdir_libiconv --- ===> libiconv (cleandir) --- cleandir_subdir_libalias --- --- cleanobj --- --- cleandir_subdir_drm2 --- ===> drm2/radeonkmsfw/VERDE_mc (cleandir) --- cleandir_subdir_libiconv --- --- cleanobj --- --- cleandir_subdir_libalias --- ===> libalias/modules (cleandir) --- cleandir_subdir_libmbpool --- --- cleanobj --- --- cleandir_subdir_drm2 --- --- cleanobj --- --- cleandir_subdir_libmchain --- --- cleandir_subdir_lindev --- --- cleandir_subdir_libalias --- --- _sub.cleandir --- --- cleandir_subdir_drm2 --- ===> drm2/radeonkmsfw/VERDE_me (cleandir) --- cleandir_subdir_libmchain --- ===> libmchain (cleandir) --- cleandir_subdir_libalias --- ===> libalias/modules/cuseeme (cleandir) --- cleandir_subdir_lindev --- ===> lindev (cleandir) --- cleandir_subdir_drm2 --- --- cleanobj --- --- cleandir_subdir_libalias --- --- cleanobj --- --- cleandir_subdir_libmchain --- --- cleanobj --- --- cleandir_subdir_libalias --- ===> libalias/modules/dummy (cleandir) --- cleandir_subdir_drm2 --- ===> drm2/radeonkmsfw/VERDE_pfp (cleandir) --- cleandir_subdir_linprocfs --- ===> linprocfs (cleandir) --- cleandir_subdir_lindev --- --- cleanobj --- --- cleandir_subdir_libalias --- --- cleanobj --- --- cleandir_subdir_drm2 --- --- cleanobj --- --- cleandir_subdir_linsysfs --- --- cleandir_subdir_libalias --- ===> libalias/modules/ftp (cleandir) --- cleandir_subdir_linsysfs --- ===> linsysfs (cleandir) --- cleandir_subdir_drm2 --- ===> drm2/radeonkmsfw/VERDE_rlc (cleandir) --- cleandir_subdir_linprocfs --- --- cleanobj --- --- cleandir_subdir_drm2 --- --- cleanobj --- --- cleandir_subdir_linux --- --- cleandir_subdir_libalias --- --- cleanobj --- ===> libalias/modules/irc (cleandir) --- cleandir_subdir_linsysfs --- --- cleanobj --- --- cleandir_subdir_linux --- ===> linux (cleandir) --- cleandir_subdir_lmc --- ===> lmc (cleandir) --- cleandir_subdir_libalias --- --- cleanobj --- --- cleandir_subdir_lpt --- ===> lpt (cleandir) --- cleandir_subdir_libalias --- ===> libalias/modules/nbt (cleandir) --- cleandir_subdir_lpt --- --- cleanobj --- --- cleandir_subdir_linux --- --- cleanobj --- --- cleandir_subdir_lmc --- --- cleanobj --- --- cleandir_subdir_libalias --- --- cleanobj --- --- cleandir_subdir_mac_biba --- ===> mac_biba (cleandir) --- cleandir_subdir_libalias --- ===> libalias/modules/pptp (cleandir) --- cleandir_subdir_mac_bsdextended --- ===> mac_bsdextended (cleandir) --- cleandir_subdir_libalias --- --- cleanobj --- --- cleandir_subdir_mac_biba --- --- cleanobj --- --- cleandir_subdir_mac_bsdextended --- --- cleanobj --- --- cleandir_subdir_libalias --- ===> libalias/modules/skinny (cleandir) --- cleandir_subdir_mac_ifoff --- --- cleandir_subdir_mac_lomac --- --- cleandir_subdir_mac_ifoff --- ===> mac_ifoff (cleandir) --- cleandir_subdir_mac_lomac --- ===> mac_lomac (cleandir) --- cleandir_subdir_mac_mls --- ===> mac_mls (cleandir) --- cleandir_subdir_libalias --- --- cleanobj --- ===> libalias/modules/smedia (cleandir) --- cleandir_subdir_mac_lomac --- --- cleanobj --- --- cleandir_subdir_mac_ifoff --- --- cleanobj --- --- cleandir_subdir_mac_mls --- --- cleanobj --- --- cleandir_subdir_mac_none --- --- cleandir_subdir_mac_partition --- --- cleandir_subdir_mac_portacl --- --- cleandir_subdir_libalias --- --- cleanobj --- --- cleandir_subdir_mac_partition --- ===> mac_partition (cleandir) --- cleandir_subdir_mac_none --- ===> mac_none (cleandir) --- cleandir_subdir_mac_portacl --- ===> mac_portacl (cleandir) --- cleandir_subdir_mac_seeotheruids --- ===> mac_seeotheruids (cleandir) --- cleandir_subdir_mac_partition --- --- cleanobj --- --- cleandir_subdir_mac_portacl --- --- cleanobj --- --- cleandir_subdir_mac_none --- --- cleanobj --- --- cleandir_subdir_mac_stub --- --- cleandir_subdir_mac_test --- --- cleandir_subdir_mac_stub --- ===> mac_stub (cleandir) --- cleandir_subdir_malo --- --- cleandir_subdir_mac_test --- ===> mac_test (cleandir) --- cleandir_subdir_malo --- ===> malo (cleandir) --- cleandir_subdir_mac_seeotheruids --- --- cleanobj --- --- cleandir_subdir_mac_stub --- --- cleanobj --- --- cleandir_subdir_malo --- --- cleanobj --- --- cleandir_subdir_mac_test --- --- cleanobj --- --- cleandir_subdir_mcd --- ===> mcd (cleandir) --- cleandir_subdir_md --- ===> md (cleandir) --- cleandir_subdir_mem --- --- cleandir_subdir_mfi --- --- cleandir_subdir_mem --- ===> mem (cleandir) --- cleandir_subdir_mcd --- --- cleanobj --- --- cleandir_subdir_mfi --- ===> mfi (cleandir) --- cleandir_subdir_md --- --- cleanobj --- --- cleandir_subdir_mii --- --- cleandir_subdir_mlx --- --- cleandir_subdir_mii --- ===> mii (cleandir) --- cleandir_subdir_mlx --- ===> mlx (cleandir) --- cleandir_subdir_mem --- --- cleanobj --- --- cleandir_subdir_mfi --- --- cleanobj --- --- _sub.cleandir --- ===> mfi/mfip (cleandir) --- cleandir_subdir_mii --- --- cleanobj --- --- cleandir_subdir_mlx --- --- cleanobj --- --- cleandir_subdir_mfi --- --- cleanobj --- ===> mfi/mfi_linux (cleandir) --- cleanobj --- rm: fts_read: No such file or directory *** [cleanobj] Error code 1 make[4]: stopped in --- cleandir_subdir_mlx --- A failure has been detected in another branch of the parallel make make[4]: stopped in *** [cleandir_subdir_mlx] Error code 2 make[3]: stopped in --- cleandir_subdir_mii --- A failure has been detected in another branch of the parallel make make[4]: stopped in *** [cleandir_subdir_mii] Error code 2 make[3]: stopped in --- cleandir_subdir_mfi --- --- _sub.cleandir --- A failure has been detected in another branch of the parallel make make[5]: stopped in *** [_sub.cleandir] Error code 2 make[4]: stopped in 2 errors make[4]: stopped in *** [cleandir_subdir_mfi] Error code 2 make[3]: stopped in 3 errors make[3]: stopped in *** [modules-cleandir] Error code 2 make[2]: stopped in /usr/obj 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-stable@FreeBSD.ORG Thu Sep 18 10:44:41 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AABBDC35 for ; Thu, 18 Sep 2014 10:44: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 669D3F16 for ; Thu, 18 Sep 2014 10:44:41 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XUZCS-000AGT-Nf for freebsd-stable@freebsd.org; Thu, 18 Sep 2014 14:44:32 +0400 Date: Thu, 18 Sep 2014 14:44:32 +0400 From: Slawa Olhovchenkov To: freebsd-stable@freebsd.org Subject: 10-STABLE r266808 crash Message-ID: <20140918104432.GA38593@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 10:44:41 -0000 Magic: FreeBSD Kernel Dump Version String: FreeBSD 10.0-STABLE #0 r266808: Wed May 28 19:13:24 MSK 2014 root@inter.trade.spb.ru:/usr/obj/usr/src/sys/TRADE Panic String: __lockmgr_args: downgrade a recursed lockmgr zfs @ /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1906 Dump Parity: 1636454732 Bounds: 1 Dump Status: good I have core.txt.1 and vmcore.1. I can run gdb on it or put on http server. From owner-freebsd-stable@FreeBSD.ORG Thu Sep 18 10:56:39 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5FDE17C; Thu, 18 Sep 2014 10:56: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 D30AFB4; Thu, 18 Sep 2014 10:56:39 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 564083B9; Thu, 18 Sep 2014 10:56:39 +0000 (UTC) Date: Thu, 18 Sep 2014 10:56:37 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-stable@freebsd.org, emaste@FreeBSD.org, dim@FreeBSD.org, allanjude@FreeBSD.org, tuexen@FreeBSD.org Message-ID: <1243312931.6.1411037798690.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1278768251.5.1411016101881.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1278768251.5.1411016101881.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_stable_10 #766 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 10:56:40 -0000 See From owner-freebsd-stable@FreeBSD.ORG Thu Sep 18 16:19:13 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94A6DB19 for ; Thu, 18 Sep 2014 16:19:13 +0000 (UTC) Received: from mail207.atl81.rsgsv.net (mail207.atl81.rsgsv.net [198.2.129.207]) by mx1.freebsd.org (Postfix) with ESMTP id 5A4B6F9F for ; Thu, 18 Sep 2014 16:19:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=k1; d=mail207.atl81.rsgsv.net; h=Subject:From:Reply-To:To:Date:Message-ID:List-Unsubscribe:Sender:Content-Type:MIME-Version; i=cisco-elaine=3Dhcyxxx.com@mail207.atl81.rsgsv.net; bh=M2XUBUoM2i3lZs7PK8g9UKM6eJ4=; b=O6iIgmzRfckXmrw31KRt/wgA0t5KryKbTiq9ikqWHwpn7W1kFEtmGFzM0wgS1+HRRS5Rv5QMErVz /YWcmCHJbafUAOdW4qKhGvZgQAFEC4JEhU6aqPkX4yucsX1OxtVO1NmytXd96MwFmWEi2eCajOwz TI/715VY5QF9l/uRbCw= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=k1; d=mail207.atl81.rsgsv.net; b=drml60mFtUQWHiwbyMnFi1ItURsZS+l3aC07aK1E9W0x/wYBne9o88x/pdCM36Z4yftivtI/tnZ4 QsFZ3DsPgzjszk+4V4r2bloRwM9/6JQAjUM8WvClgbhj7otd/2bE2AqYAEjLt0igaYr/LkuHTP17 +sAK6hmcOzvXXZgI2eo=; Received: from (127.0.0.1) by mail207.atl81.rsgsv.net id h3c3021ohk03 for ; Thu, 18 Sep 2014 16:19:11 +0000 (envelope-from ) Subject: =?utf-8?Q?Original=20New=20Cisco=20Switches=2CModules=20and=20Firewalls?= From: =?utf-8?Q?Elaine=20Hu?= Reply-To: =?utf-8?Q?Elaine=20Hu?= To: =?utf-8?Q??= Date: Thu, 18 Sep 2014 16:19:11 +0000 Message-ID: <854f51db1f0d3283a587450605059a51b63.20140918161904@mail207.atl81.rsgsv.net> X-Mailer: MailChimp Mailer - **CID475f664d325059a51b63** X-Campaign: mailchimp854f51db1f0d3283a58745060.475f664d32 X-campaignid: mailchimp854f51db1f0d3283a58745060.475f664d32 X-Report-Abuse: Please report abuse for this campaign here: http://www.mailchimp.com/abuse/abuse.phtml?u=854f51db1f0d3283a58745060&id=475f664d32&e=5059a51b63 X-MC-User: 854f51db1f0d3283a58745060 X-Feedback-ID: 33478249:33478249.548969:us9:mc X-Accounttype: ff Sender: "Elaine Hu" x-mcda: FALSE MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format="fixed" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 16:19:13 -0000 Original New Cisco Switches=2CModules and Firewalls available for sale now= =2E Hello dear=2C Good day ! Following is Original New Cisco Switches=2CModules and Firewalls available= for sale now. Any needs of them=2C please feel free to contact me. Skype: elaine.hu87 Part Number Unit Price Stock Qty WS-C2960-24TC-L $395 224 WS-C2960-24TT-L $395 20 WS-C2960-48TC-S $695 36 WS-C2960X-24TS-L $885 25 WS-C2960X-24PS-L $1=2C180 20 ASA5505-K8 $350 20 ASA5505-BUN-K9 $395 15 X2-10GB-LR $615 28 GLC-SX-MMD $68 100 GLC-LH-SMD $98 100 WS-C3560G-24PS-S $1=2C835 30 WS-C2960S-48FPD-L $2=2C450 12 WS-C3750X-24T-L $1=2C515 20 WS-C3750X-24S-S $6=2C220 3 WS-C3850-24P-S $3=2C010 10 WS-C3850-48T-S $4=2C725 10 WS-C3850-48P-S $5=2C260 10 WS-C3850-24T-S $2=2C675 10 PWR-C1-715WAC=3D $420 10 PWR-C1-350WAC=3D $235 10 C3850-NM-4-1G $235 10 Looking forward to your early reply ! Thanks & Regards=2C Elaine Hu / Sales Manager Asia Information Technology HK International Limited Tel: 86+ 01062669007 WhatsApp: 008613051026936 Skype ID: elaine.hu87 Email: cisco-elaine@hcyxxx.com (mailto:cisco-elaine@hcyxxx.com) elainehu.cisco@gmail.com (mailto:elainehu.cisco@gmail.com) Web: www.networkingcisco.com (http://alibaba.us9.list-manage1.com/track/cl= ick?u=3D854f51db1f0d3283a58745060&id=3D236e0a30c4&e=3D5059a51b63) www.hcyxxx.en.alibaba.com (http://alibaba.us9.list-manage.com/track/click?= u=3D854f51db1f0d3283a58745060&id=3D3bdbbd5968&e=3D5059a51b63) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This email was sent to freebsd-stable@freebsd.org (mailto:freebsd-stable@freebsd.org) why did I get this? (http://alibaba.us9.list-manage.com/about?u=3D854f51db= 1f0d3283a58745060&id=3D39280d73ae&e=3D5059a51b63&c=3D475f664d32) unsubsc= ribe from this list (http://alibaba.us9.list-manage.com/unsubscribe?u=3D85= 4f51db1f0d3283a58745060&id=3D39280d73ae&e=3D5059a51b63&c=3D475f664d32) u= pdate subscription preferences (http://alibaba.us9.list-manage.com/profile= ?u=3D854f51db1f0d3283a58745060&id=3D39280d73ae&e=3D5059a51b63) ASIA INFORMATION TECHNOLOGY HK INTERNATIONAL LIMITED =C2=B7 Room 1304 #5 b= uilding=2C No.1Yard. ShangDi Tenth street=2CHaiDian =C2=B7 District=2CBeiJ= ing100085 China =C2=B7 Beijing=2C NY 100085 =C2=B7 China Email Marketing Powered by MailChimp http://www.mailchimp.com/monkey-rewards/?utm_source=3Dfreemium_newsletter&= utm_medium=3Demail&utm_campaign=3Dmonkey_rewards&aid=3D854f51db1f0d3283a58= 745060&afl=3D1 From owner-freebsd-stable@FreeBSD.ORG Thu Sep 18 17:49:55 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD464C87 for ; Thu, 18 Sep 2014 17:49:55 +0000 (UTC) Received: from nm7-vm0.bullet.mail.bf1.yahoo.com (nm7-vm0.bullet.mail.bf1.yahoo.com [98.139.213.151]) (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 827A8BAD for ; Thu, 18 Sep 2014 17:49:54 +0000 (UTC) Received: from [98.139.215.140] by nm7.bullet.mail.bf1.yahoo.com with NNFMP; 18 Sep 2014 17:47:23 -0000 Received: from [98.139.212.231] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 18 Sep 2014 17:47:23 -0000 Received: from [127.0.0.1] by omp1040.mail.bf1.yahoo.com with NNFMP; 18 Sep 2014 17:47:23 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 171628.35897.bm@omp1040.mail.bf1.yahoo.com Received: (qmail 5036 invoked by uid 60001); 18 Sep 2014 17:47:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1411062443; bh=3qSI+OF4iLZxHUWHzpN+SKqYL1ar74W8p3Shrm9OD6U=; h=Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=at6q8GBJ6W9a7VyECkRX9f5KxqTIwei7WM7HFpzGFec7KoB/Wof2CZtHwZMePwPmu89t/PTaZyv4KBJPsK/F982ZzNhgYVpyZQEsOAGEyKvlED4kBxw40mqJI0Y8sXd+/IgoaPo0nIsy59E5QUEwZUMrAjJMcR+uwkHpSOsHaJY= X-YMail-OSG: WInEci4VM1mA7MdASaB0znw3x2XqeuK_lFQrW9btzbUjP_p Qj8ndukh_w8dAMFLa53Gc_AJla6Gx8AMFzyoLgatWJSRWYALGnZOGyo2tCuj 113HwUYv7ehKimTE8aCFi_Ss6VVZ8gp4_mJWUWQwrBg.rO6OgOBdAmxZ7Wnu ysTVSJIKsX5vdPP7vhCTq7sQIvd83s0HyxYMwixTs4hpAIETyvvPRQeHIKXb wWQFfJ7aRCMX_CymPN4a.Gka_DMqCqaIQ_Fz2WfIwuLV7HiSpHCsHwUEmFYl zetryfEt.0wxWrqCZKBOL3Oheg2Vor.3wWiMSHC2dQnYtVM2utzMq5rqxyJ6 xgAF91gdGgi7CCzOLAK5ueWzmiDlaToyzzZ_XFASIfy2T2iRavRKpg4LoY.J lp7B6aQ9W688XzrAsNrfncX0LeuM3Vj6gTtp0fmNht.t8LIiHAP2klExWcBW PZN.jt3S4XJ8h6jW_mL1oAVOxQ9SPtH4FEtcQ_uluc1uqW_ucGhVUd6GxgT4 uW4XgLZTsv2i6fTqpDVj6yUar1tC01u_XgpK8v0KUq5F3C5QKlbjVfgMLLKf x7FW1Up582YwmvNUj1OsJ2YpjfR9fTqheHvTt0xFT26NRyH7ppJZStPcWXei sy4Gggf1CtALhpejYWidpH2op88hcAtMRkwEjOnuCLL.Pm6B6z0bKRlAd_zM 0hnWr7j11qw-- Received: from [87.16.45.142] by web140903.mail.bf1.yahoo.com via HTTP; Thu, 18 Sep 2014 10:47:22 PDT X-Rocket-MIMEInfo: 002.001, SSBoYXZlIHRoZSBmb2xsb3dpbmcgcHJvYmxlbSBjb21waWxpbmcgRGJ1cyBvbiAxMC1TVEFCTEUgaTM4NjoKZ21ha2VbNF06IExlYXZpbmcgZGlyZWN0b3J5IGAvdXNyL3BvcnRzL2RldmVsL2RidXMvd29yay9kYnVzLTEuOC44L3Rvb2xzJwpNYWtpbmcgYWxsIGluIGRvYwpnbWFrZVs0XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvdXNyL3BvcnRzL2RldmVsL2RidXMvd29yay9kYnVzLTEuOC44L2RvYycKL3Vzci9sb2NhbC9iaW4veG1sdG8gbWFuIGRidXMtY2xlYW51cC1zb2NrZXRzLjEueG1sCi91c3IvbG9jYWwBMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.696 Message-ID: <1411062442.67188.YahooMailNeo@web140903.mail.bf1.yahoo.com> Date: Thu, 18 Sep 2014 10:47:22 -0700 From: Filippo Moretti Reply-To: Filippo Moretti Subject: Problem compiling Dbus To: "stable@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 17:49:55 -0000 I have the following problem compiling Dbus on 10-STABLE i386: gmake[4]: Leaving directory `/usr/ports/devel/dbus/work/dbus-1.8.8/tools' Making all in doc gmake[4]: Entering directory `/usr/ports/devel/dbus/work/dbus-1.8.8/doc' /usr/local/bin/xmlto man dbus-cleanup-sockets.1.xml /usr/local/bin/xmlto man dbus-daemon.1.xml I/O error : Attempt to load network entity http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl warning: failed to load external entity "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl" compilation error: file /tmp/xmlto-xsl.L8BOVn line 4 element import xsl:import : unable to load http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl I/O error : Attempt to load network entity http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl warning: failed to load external entity "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl" compilation error: file /tmp/xmlto-xsl.g7fal7 line 4 element import xsl:import : unable to load http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl gmake[4]: *** [dbus-daemon.1] Error 1 gmake[4]: *** Waiting for unfinished jobs.... gmake[4]: *** [dbus-cleanup-sockets.1] Error 1 gmake[4]: Leaving directory `/usr/ports/devel/dbus/work/dbus-1.8.8/doc' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/usr/ports/devel/dbus/work/dbus-1.8.8' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/ports/devel/dbus/work/dbus-1.8.8' ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Stop. make[1]: stopped in /usr/ports/devel/dbus *** Error code 1 Stop. make: stopped in /usr/ports/devel/dbus [root@sting /usr/ports/devel/dbus]# sincerely Filippo From owner-freebsd-stable@FreeBSD.ORG Thu Sep 18 20:15:54 2014 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D4D245B for ; Thu, 18 Sep 2014 20:15:54 +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 66908D99 for ; Thu, 18 Sep 2014 20:15:54 +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 s8IKFs3c054468 for ; Thu, 18 Sep 2014 20:15:54 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s8IKFrLL054466 for stable@FreeBSD.org; Thu, 18 Sep 2014 20:15:53 GMT (envelope-from bdrewery) Received: (qmail 34598 invoked from network); 18 Sep 2014 15:15:51 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 18 Sep 2014 15:15:51 -0500 Message-ID: <541B3D72.8050502@FreeBSD.org> Date: Thu, 18 Sep 2014 15:15:46 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: "pkg@freebsd.org" Subject: Poudriere code moved to https://github.com/freebsd/poudriere OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0LHHc7J1vB0qN7Vmm1Kj85xVc2Iin52N6" X-Mailman-Approved-At: Thu, 18 Sep 2014 20:38:53 +0000 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 20:15:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0LHHc7J1vB0qN7Vmm1Kj85xVc2Iin52N6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Poudriere's code no longer is based in fossil. It has moved to https://github.com/freebsd/poudriere. Fossil will not be kept synced. Please submit patches as pull requests and issues on github going forward (rather than the old fossil site). This conversion is not compatible with the existing repository that I had on github.com/bdrewery/poudriere. The one I had was only a convenience and did not have tickets/commit-hashes converted. The new conversion does have these migrated. There are no hashes in common. Any checkouts you have will need to have customizations rebased onto the new repository. If you have no modifications to your own local repository than you can just recheckout to the new one. Given the old had a 'trunk' head then this should work: # git remote add upstream https://github.com/freebsd/poudriere.git # git remote update upstream # git checkout -b master upstream/master If you have made modifications then you will need to rebase onto the new one. Look in your 'git log' and find the last upstream commit which I will call UPSTREAM_COMMIT. Then rebase all of your work onto the new mast= er: # git remote add upstream https://github.com/freebsd/poudriere.git # git remote update upstream # git rebase --onto upstream/master UPSTREAM_COMMIT Don't forget to git push -f to your own remote if needed. --=20 Regards, Bryan Drewery --0LHHc7J1vB0qN7Vmm1Kj85xVc2Iin52N6 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) iQEcBAEBAgAGBQJUGz1zAAoJEDXXcbtuRpfPRrIH/2fUts32GLxgAKKlTCno9C0P fno/0e+gRE3r2JkMrTa5TwYCuuFB4VS8aq8zsb7djJSMxQIPepEmip7wz16UBNy7 TMTt5hBlXtq6ViQLJrvMXSu56s+6HU2D9KGRMpO8wK1uDISy54idePqp8pQcV2HZ uWUf0NbZmQW+mZvyNiIQujS2DvyfGqhOFegPzUrxHqXHdtLJBM8lVc4gzwRRcyJz Wh/UTV0VThZHQ75Mr7cW+j3SnTazK0DgQlQ06OJPappxiP7oWCB0dcpXuPaOTQ5f JsNxsThv2PfIzta6jQJWAsIGli/whqdAEpk9M2ZZsAOmiIlXeTNA9uX+RfZqrws= =mBwn -----END PGP SIGNATURE----- --0LHHc7J1vB0qN7Vmm1Kj85xVc2Iin52N6-- From owner-freebsd-stable@FreeBSD.ORG Thu Sep 18 20:39:20 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D76E413 for ; Thu, 18 Sep 2014 20:39:20 +0000 (UTC) Received: from smtp.pobox.com (smtp.pobox.com [208.72.237.35]) by mx1.freebsd.org (Postfix) with ESMTP id DAE14D0 for ; Thu, 18 Sep 2014 20:39:19 +0000 (UTC) Received: from smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp0.pobox.com (Postfix) with ESMTP id F1C573ADC8 for ; Thu, 18 Sep 2014 16:35:44 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from:to :subject:message-id:references:mime-version:content-type :in-reply-to; s=sasl; bh=49EfWQvXld2M5ulKT0T22jSruuI=; b=FyHEFP1 io3bPFAVMdADLuzwfO30QnYWRUkiDmrcagW3JHDgOhX80kFCCTLeCohRLWWelCHf 9sZ+IK8qky/JMOhzPDuHMZJ8u//s2nDREsXXw7xsy+zzCuPLLf0awCFtnkxviXFM onIo9mWXFG7m7+MckVVlYRDQAuybSjzHrcvA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from:to :subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=sasl; b=WUj30b98eai/zLGuz2CtaZJGLZu0koaGq KTMNnnUDu+UG53jxtY59Y1YqGYzjWuqOa/4EOszQ+gNRdywr4GjaNT775Oiwpq6P kZxolzMcoL2a9KJwKoSiR/Gf3xx79Nn9qGmDGlkJKNd4cEg++lpA3DEX+65JmfOE VhWt2vB7eI= Received: from pb-smtp0. (unknown [127.0.0.1]) by pb-smtp0.pobox.com (Postfix) with ESMTP id E6EFF3ADC6 for ; Thu, 18 Sep 2014 16:35:44 -0400 (EDT) Received: from localhost (unknown [50.90.2.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-smtp0.pobox.com (Postfix) with ESMTPSA id 6BD263ADBF for ; Thu, 18 Sep 2014 16:35:44 -0400 (EDT) Date: Thu, 18 Sep 2014 16:35:43 -0400 From: Chris Nehren To: stable@freebsd.org Subject: Re: Problem compiling Dbus Message-ID: <20140918203543.GA19469@satori.lan> Mail-Followup-To: stable@freebsd.org References: <1411062442.67188.YahooMailNeo@web140903.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline In-Reply-To: <1411062442.67188.YahooMailNeo@web140903.mail.bf1.yahoo.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Pobox-Relay-ID: 5D25C63C-3F73-11E4-97DA-BD2DC4D60FE0-49531120!pb-smtp0.pobox.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 20:39:20 -0000 --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 18, 2014 at 10:47:22 -0700, Filippo Moretti via freebsd-stable = wrote: > I have the following problem compiling Dbus on 10-STABLE i386: > gmake[4]: Leaving directory `/usr/ports/devel/dbus/work/dbus-1.8.8/tools' > Making all in doc > gmake[4]: Entering directory `/usr/ports/devel/dbus/work/dbus-1.8.8/doc' > /usr/local/bin/xmlto man dbus-cleanup-sockets.1.xml > /usr/local/bin/xmlto man dbus-daemon.1.xml > I/O error : Attempt to load network entity http://docbook.sourceforge.net= /release/xsl/current/manpages/docbook.xsl > warning: failed to load external entity "http://docbook.sourceforge.net/r= elease/xsl/current/manpages/docbook.xsl" > compilation error: file /tmp/xmlto-xsl.L8BOVn line 4 element import This suggests that the machine was unable to fetch the URLs mentioned. Does it have a connection to the general Internet? If it does, do your logs indicate that the connection was down at the time the compilation failed? I can access the URLs without issue here. Another possibility is that the server itself was temporarily down. Try the build again and see if it works? --=20 Chris Nehren --0OAP2g/MAC+5xKAE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJbBAABAgBFBQJUG0IfPhSAAAAAABUAIHBrYS1hZGRyZXNzQGdudXBnLm9yZ2Nu ZWhyZW4rZnJlZWJzZC1zdGFibGVAcG9ib3guY29tAAoJEBHA+GJAM0vPKssP/i/8 lcYtDlMh8Q8Nnv0UWVS7F7Aqu7GRGl2vPlDfnDjHoaLaELtTD2yBaXylC2uUZsjH UhUT9ECqKyXsa2JR/CHld94G6K3Z/zFnwy63EHQdi+DRWnJSFOLfKATHblyUcQe7 u0xU4nTgLFsr69y1ec4Kfn6GrLKztT1lf21o4i4jE8iacA+Nl5Fu9YwOixuhBEa0 t7Qc96myry4CUoQKcCrrW8o1Mi8TLjdOTrQh+a3PrnenxsqUdUE/fEMTGWa7Y4u3 O7FL5K3c2Z7g2VT8GDSF56MjChB9zSpsdaJ3RbqJupkFkth/nlQ7/CxbnGFIR19a xDoNKfwjrLz/+wEMsDmbQcg6nZgAgxeIehzQiwg3BacysAu4B+LtB8jVSP3RFF+H w+axHgcW5QdEYtXwDLtjtgDLPeySNMky4a5JQAP7SBdSeQOL+rcG9/R0xmuUFGuZ ck6bUOgqN6a3xR/bO7dtttksgkVwp2+ELQEHEJ/rXb1FxPadhZcGk4fo3zWVQITc jIsoUSifdTgX0bVdd+ytqaeDjY5ovJMx4pnq8NXn8F66xy2AIIPY1HsyqlLc4J/5 fQW4AL5x3CBm2fDyNXdQu61Rtlb0mxB+cy/I99TGfsVe0T9l3yF/wFVCHMZMHnTQ DVZLWyVAtpvYbUP8muzRMD+yAY3Osdl01S9fhdVd =TFnK -----END PGP SIGNATURE----- --0OAP2g/MAC+5xKAE-- From owner-freebsd-stable@FreeBSD.ORG Thu Sep 18 22:49:29 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06CA8D83 for ; Thu, 18 Sep 2014 22:49:29 +0000 (UTC) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ozzie.tundraware.com", Issuer "ozzie.tundraware.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9AA48FEA for ; Thu, 18 Sep 2014 22:49:27 +0000 (UTC) Received: from [192.168.0.2] (viper.tundraware.com [192.168.0.2]) (authenticated bits=0) by ozzie.tundraware.com (8.14.9/8.14.9) with ESMTP id s8IMnBFB037638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 18 Sep 2014 17:49:11 -0500 (CDT) (envelope-from tundra@tundraware.com) Message-ID: <541B6167.3000703@tundraware.com> Date: Thu, 18 Sep 2014 17:49:11 -0500 From: Tim Daneliuk User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: FreeBSD Stable Subject: 10.1Beta - Ongoing Build Problems Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (ozzie.tundraware.com [75.145.138.73]); Thu, 18 Sep 2014 17:49:11 -0500 (CDT) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: s8IMnBFB037638 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 22:49:29 -0000 I continue to see problems as seen below if I attempt a parallel make. If I remove the '-j4' from my build script, this build completes fine, albeit much more slowly. Ideas anyone??: >>> Kernel build for MYFINEHOST started on Thu Sep 18 04:35:18 CDT 2014 -------------------------------------------------------------- ===> MYFINEHOST mkdir -p /usr/obj/usr/src/sys -------------------------------------------------------------- >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /usr/src/sys/amd64/conf; PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /usr/obj/usr/src/sys/MYFINEHOST -I '/usr/src/sys/amd64/conf' '/usr/src/sys/amd64/conf/MYFINEHOST' Kernel build directory is /usr/obj/usr/src/sys/MYFINEHOST Don't forget to do ``make cleandepend && make depend'' -------------------------------------------------------------- >>> stage 2.1: cleaning up the object tree -------------------------------------------------------------- cd /usr/obj/usr/src/sys/MYFINEHOST; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp _LDSCRIPTROOT= VERSION="FreeBSD 10.1-BETA1 amd64 1000716" INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin CC="cc " CXX="c++ " CPP="cpp " AS="as" AR="ar" LD="ld" NM=nm OBJDUMP= RANLIB=ranlib STRINGS= COMPILER_TYPE=clang make -j 4 -J 15,16 -m /usr/src/share/mk KERNEL=kernel cleandir --- kernel-clean --- --- kernel-cleandepend --- --- modules-cleandir --- --- kernel-cleandepend --- rm -f .depend machine x86 --- kernel-clean --- rm -f *.o *.so *.So *.ko *.s eddep errs kernel.debug kernel kernel.symbols linterrs tags vers.c vnode_if.c vnode_if.h vnode_if_newproto.h vnode_if_typedef.h agp_if.c ata_if.c eisa_if.c fb_if.c miibus_if.c mmcbr_if.c mmcbus_if.c mvs_if.c card_if.c power_if.c pci_if.c pcib_if.c ppbus_if.c sdhci_if.c hdac_if.c ac97_if.c channel_if.c feeder_if.c mixer_if.c mpu_if.c mpufoi_if.c synth_if.c uart_if.c usb_if.c g_part_if.c g_raid_md_if.c g_raid_tr_if.c isa_if.c bus_if.c clock_if.c cpufreq_if.c device_if.c linker_if.c serdev_if.c xenbus_if.c xenbusb_if.c acpi_if.c acpi_wmi_if.c virtio_bus_if.c virtio_if.c agp_if.h ata_if.h eisa_if.h fb_if.h miibus_if.h mmcbr_if.h mmcbus_if.h mvs_if.h card_if.h power_if.h pci_if.h pcib_if.h ppbus_if.h sdhci_if.h hdac_if.h ac97_if.h channel_if.h feeder_if.h mixer_if.h mpu_if.h mpufoi_if.h synth_if.h uart_if.h usb_if.h g_part_if.h g_raid_md_if.h g_raid_tr_if.h isa_if.h bus_if.h clock_if.h cpufreq_if.h device_if.h linker_if.h serdev_if.h xenbus_if.h xenbusb_if.h acpi_if.h acpi_wmi_if.h virtio_bus_if.h virtio_if.h acpi_quirks.h feeder_eq_gen.h feeder_rate_gen.h snd_fxdiv_gen.h miidevs.h pccarddevs.h teken_state.h usbdevs.h usbdevs_data.h ia32_genassym.o ia32_assym.h acpi_wakecode.o acpi_wakecode.bin acpi_wakecode.h acpi_wakedata.h --- modules-cleandir --- cd /usr/src/sys/modules; MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/MYFINEHOST/modules KMODDIR=/boot/kernel MACHINE_CPUARCH=amd64 DEBUG_FLAGS="-g" MACHINE=amd64 KERNBUILDDIR="/usr/obj/usr/src/sys/MYFINEHOST" SYSDIR="/usr/src/sys" WITH_CTF="1" make cleandir --- cleandir_subdir_aac --- --- cleandir_subdir_aacraid --- --- cleandir_subdir_accf_data --- --- cleandir_subdir_accf_dns --- --- cleandir_subdir_aac --- ===> aac (cleandir) --- cleandir_subdir_aacraid --- ===> aacraid (cleandir) --- cleandir_subdir_accf_data --- ===> accf_data (cleandir) --- cleandir_subdir_accf_dns --- ===> accf_dns (cleandir) --- cleandir_subdir_accf_data --- --- cleanobj --- --- cleandir_subdir_accf_dns --- --- cleanobj --- --- cleandir_subdir_aacraid --- --- cleanobj --- --- cleandir_subdir_aac --- --- cleanobj --- --- cleandir_subdir_accf_http --- --- cleandir_subdir_acl_nfs4 --- --- cleandir_subdir_accf_http --- ===> accf_http (cleandir) --- cleandir_subdir_acl_nfs4 --- ===> acl_nfs4 (cleandir) --- cleandir_subdir_acl_posix1e --- --- cleandir_subdir_acpi --- --- cleandir_subdir_acl_posix1e --- ===> acl_posix1e (cleandir) --- cleandir_subdir_acpi --- ===> acpi (cleandir) --- cleandir_subdir_accf_http --- --- cleanobj --- --- cleandir_subdir_acl_nfs4 --- --- cleanobj --- --- cleandir_subdir_acpi --- --- _sub.cleandir --- ===> acpi/acpi_asus (cleandir) --- cleandir_subdir_ae --- ===> ae (cleandir) --- cleandir_subdir_aesni --- ===> aesni (cleandir) --- cleandir_subdir_acl_posix1e --- --- cleanobj --- --- cleandir_subdir_acpi --- --- cleanobj --- --- cleandir_subdir_age --- ===> age (cleandir) --- cleandir_subdir_aesni --- --- cleanobj --- --- cleandir_subdir_ae --- --- cleanobj --- --- cleandir_subdir_acpi --- ===> acpi/acpi_asus_wmi (cleandir) --- cleandir_subdir_age --- --- cleanobj --- --- cleandir_subdir_acpi --- --- cleanobj --- --- cleandir_subdir_agp --- --- cleandir_subdir_aha --- --- cleandir_subdir_agp --- ===> agp (cleandir) --- cleandir_subdir_aha --- ===> aha (cleandir) --- cleanobj --- --- cleandir_subdir_ahci --- ===> ahci (cleandir) --- cleandir_subdir_aic7xxx --- ===> aic7xxx (cleandir) --- cleandir_subdir_ahci --- --- cleanobj --- --- cleandir_subdir_agp --- --- cleanobj --- --- cleandir_subdir_acpi --- ===> acpi/acpi_fujitsu (cleandir) --- cleandir_subdir_aic7xxx --- --- _sub.cleandir --- ===> aic7xxx/ahc (cleandir) --- cleandir_subdir_aio --- ===> aio (cleandir) --- cleandir_subdir_acpi --- --- cleanobj --- --- cleandir_subdir_aic7xxx --- --- cleanobj --- --- cleandir_subdir_alc --- ===> alc (cleandir) --- cleandir_subdir_aio --- --- cleanobj --- --- cleandir_subdir_acpi --- ===> acpi/acpi_hp (cleandir) --- cleandir_subdir_alc --- --- cleanobj --- --- cleandir_subdir_acpi --- --- cleanobj --- --- cleandir_subdir_aic7xxx --- --- _sub.cleandir --- ===> aic7xxx/ahc/ahc_eisa (cleandir) --- clean --- rm -f export_syms ahc_eisa.ko ahc_eisa.kld ahc_eisa.o ahc_eisa.ko.debug ahc_eisa.ko.symbols opt_scsi.h opt_cam.h opt_aic7xxx.h eisa_if.h pci_if.h bus_if.h device_if.h --- cleanilinks --- rm -f @ machine x86 --- cleandepend --- rm -f .depend GPATH GRTAGS GSYMS GTAGS --- cleanobj --- ===> aic7xxx/ahc/ahc_isa (cleandir) --- cleanobj --- ===> aic7xxx/ahc/ahc_pci (cleandir) --- cleandir_subdir_acpi --- ===> acpi/acpi_ibm (cleandir) --- cleandir_subdir_ale --- ===> ale (cleandir) --- cleandir_subdir_aic7xxx --- --- cleanobj --- --- cleandir_subdir_alq --- ===> alq (cleandir) --- cleandir_subdir_aic7xxx --- --- cleanobj --- rm: fts_read: No such file or directory *** [cleanobj] Error code 1 make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc 1 error make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc *** [_sub.cleandir] Error code 2 make[4]: stopped in /usr/src/sys/modules/aic7xxx 1 error make[4]: stopped in /usr/src/sys/modules/aic7xxx *** [cleandir_subdir_aic7xxx] Error code 2 make[3]: stopped in /usr/src/sys/modules --- cleandir_subdir_alq --- A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/sys/modules/alq --- cleandir_subdir_ale --- A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/sys/modules/ale --- cleandir_subdir_alq --- *** [cleandir_subdir_alq] Error code 2 make[3]: stopped in /usr/src/sys/modules --- cleandir_subdir_acpi --- --- cleanobj --- --- cleandir_subdir_ale --->>> Kernel build for OZZIE started on Thu Sep 18 04:35:18 CDT 2014 -------------------------------------------------------------- ===> OZZIE mkdir -p /usr/obj/usr/src/sys -------------------------------------------------------------- >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /usr/src/sys/amd64/conf; PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /usr/obj/usr/src/sys/OZZIE -I '/usr/src/sys/amd64/conf' '/usr/src/sys/amd64/conf/OZZIE' Kernel build directory is /usr/obj/usr/src/sys/OZZIE Don't forget to do ``make cleandepend && make depend'' -------------------------------------------------------------- >>> stage 2.1: cleaning up the object tree -------------------------------------------------------------- cd /usr/obj/usr/src/sys/OZZIE; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp _LDSCRIPTROOT= VERSION="FreeBSD 10.1-BETA1 amd64 1000716" INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin CC="cc " CXX="c++ " CPP="cpp " AS="as" AR="ar" LD="ld" NM=nm OBJDUMP= RANLIB=ranlib STRINGS= COMPILER_TYPE=clang make -j 4 -J 15,16 -m /usr/src/share/mk KERNEL=kernel cleandir --- kernel-clean --- --- kernel-cleandepend --- --- modules-cleandir --- --- kernel-cleandepend --- rm -f .depend machine x86 --- kernel-clean --- rm -f *.o *.so *.So *.ko *.s eddep errs kernel.debug kernel kernel.symbols linterrs tags vers.c vnode_if.c vnode_if.h vnode_if_newproto.h vnode_if_typedef.h agp_if.c ata_if.c eisa_if.c fb_if.c miibus_if.c mmcbr_if.c mmcbus_if.c mvs_if.c card_if.c power_if.c pci_if.c pcib_if.c ppbus_if.c sdhci_if.c hdac_if.c ac97_if.c channel_if.c feeder_if.c mixer_if.c mpu_if.c mpufoi_if.c synth_if.c uart_if.c usb_if.c g_part_if.c g_raid_md_if.c g_raid_tr_if.c isa_if.c bus_if.c clock_if.c cpufreq_if.c device_if.c linker_if.c serdev_if.c xenbus_if.c xenbusb_if.c acpi_if.c acpi_wmi_if.c virtio_bus_if.c virtio_if.c agp_if.h ata_if.h eisa_if.h fb_if.h miibus_if.h mmcbr_if.h mmcbus_if.h mvs_if.h card_if.h power_if.h pci_if.h pcib_if.h ppbus_if.h sdhci_if.h hdac_if.h ac97_if.h channel_if.h feeder_if.h mixer_if.h mpu_if.h mpufoi_if.h synth_if.h uart_if.h usb_if.h g_part_if.h g_raid_md_if.h g_raid_tr_if.h isa_if.h bus_if.h clock_if.h cpufreq_if.h device_if.h linker_if.h serdev_if.h xenbus_if.h xenbusb_if.h acpi_if.h acpi_wmi_if.h virtio_bus_if.h virtio_if.h acpi_quirks.h feeder_eq_gen.h feeder_rate_gen.h snd_fxdiv_gen.h miidevs.h pccarddevs.h teken_state.h usbdevs.h usbdevs_data.h ia32_genassym.o ia32_assym.h acpi_wakecode.o acpi_wakecode.bin acpi_wakecode.h acpi_wakedata.h --- modules-cleandir --- cd /usr/src/sys/modules; MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/OZZIE/modules KMODDIR=/boot/kernel MACHINE_CPUARCH=amd64 DEBUG_FLAGS="-g" MACHINE=amd64 KERNBUILDDIR="/usr/obj/usr/src/sys/OZZIE" SYSDIR="/usr/src/sys" WITH_CTF="1" make cleandir --- cleandir_subdir_aac --- --- cleandir_subdir_aacraid --- --- cleandir_subdir_accf_data --- --- cleandir_subdir_accf_dns --- --- cleandir_subdir_aac --- ===> aac (cleandir) --- cleandir_subdir_aacraid --- ===> aacraid (cleandir) --- cleandir_subdir_accf_data --- ===> accf_data (cleandir) --- cleandir_subdir_accf_dns --- ===> accf_dns (cleandir) --- cleandir_subdir_accf_data --- --- cleanobj --- --- cleandir_subdir_accf_dns --- --- cleanobj --- --- cleandir_subdir_aacraid --- --- cleanobj --- --- cleandir_subdir_aac --- --- cleanobj --- --- cleandir_subdir_accf_http --- --- cleandir_subdir_acl_nfs4 --- --- cleandir_subdir_accf_http --- ===> accf_http (cleandir) --- cleandir_subdir_acl_nfs4 --- ===> acl_nfs4 (cleandir) --- cleandir_subdir_acl_posix1e --- --- cleandir_subdir_acpi --- --- cleandir_subdir_acl_posix1e --- ===> acl_posix1e (cleandir) --- cleandir_subdir_acpi --- ===> acpi (cleandir) --- cleandir_subdir_accf_http --- --- cleanobj --- --- cleandir_subdir_acl_nfs4 --- --- cleanobj --- --- cleandir_subdir_acpi --- --- _sub.cleandir --- ===> acpi/acpi_asus (cleandir) --- cleandir_subdir_ae --- ===> ae (cleandir) --- cleandir_subdir_aesni --- ===> aesni (cleandir) --- cleandir_subdir_acl_posix1e --- --- cleanobj --- --- cleandir_subdir_acpi --- --- cleanobj --- --- cleandir_subdir_age --- ===> age (cleandir) --- cleandir_subdir_aesni --- --- cleanobj --- --- cleandir_subdir_ae --- --- cleanobj --- --- cleandir_subdir_acpi --- ===> acpi/acpi_asus_wmi (cleandir) --- cleandir_subdir_age --- --- cleanobj --- --- cleandir_subdir_acpi --- --- cleanobj --- --- cleandir_subdir_agp --- --- cleandir_subdir_aha --- --- cleandir_subdir_agp --- ===> agp (cleandir) --- cleandir_subdir_aha --- ===> aha (cleandir) --- cleanobj --- --- cleandir_subdir_ahci --- ===> ahci (cleandir) --- cleandir_subdir_aic7xxx --- ===> aic7xxx (cleandir) --- cleandir_subdir_ahci --- --- cleanobj --- --- cleandir_subdir_agp --- --- cleanobj --- --- cleandir_subdir_acpi --- ===> acpi/acpi_fujitsu (cleandir) --- cleandir_subdir_aic7xxx --- --- _sub.cleandir --- ===> aic7xxx/ahc (cleandir) --- cleandir_subdir_aio --- ===> aio (cleandir) --- cleandir_subdir_acpi --- --- cleanobj --- --- cleandir_subdir_aic7xxx --- --- cleanobj --- --- cleandir_subdir_alc --- ===> alc (cleandir) --- cleandir_subdir_aio --- --- cleanobj --- --- cleandir_subdir_acpi --- ===> acpi/acpi_hp (cleandir) --- cleandir_subdir_alc --- --- cleanobj --- --- cleandir_subdir_acpi --- --- cleanobj --- --- cleandir_subdir_aic7xxx --- --- _sub.cleandir --- ===> aic7xxx/ahc/ahc_eisa (cleandir) --- clean --- rm -f export_syms ahc_eisa.ko ahc_eisa.kld ahc_eisa.o ahc_eisa.ko.debug ahc_eisa.ko.symbols opt_scsi.h opt_cam.h opt_aic7xxx.h eisa_if.h pci_if.h bus_if.h device_if.h --- cleanilinks --- rm -f @ machine x86 --- cleandepend --- rm -f .depend GPATH GRTAGS GSYMS GTAGS --- cleanobj --- ===> aic7xxx/ahc/ahc_isa (cleandir) --- cleanobj --- ===> aic7xxx/ahc/ahc_pci (cleandir) --- cleandir_subdir_acpi --- ===> acpi/acpi_ibm (cleandir) --- cleandir_subdir_ale --- ===> ale (cleandir) --- cleandir_subdir_aic7xxx --- --- cleanobj --- --- cleandir_subdir_alq --- ===> alq (cleandir) --- cleandir_subdir_aic7xxx --- --- cleanobj --- rm: fts_read: No such file or directory *** [cleanobj] Error code 1 make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc 1 error make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc *** [_sub.cleandir] Error code 2 make[4]: stopped in /usr/src/sys/modules/aic7xxx 1 error make[4]: stopped in /usr/src/sys/modules/aic7xxx *** [cleandir_subdir_aic7xxx] Error code 2 make[3]: stopped in /usr/src/sys/modules --- cleandir_subdir_alq --- A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/sys/modules/alq --- cleandir_subdir_ale --- A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/sys/modules/ale --- cleandir_subdir_alq --- *** [cleandir_subdir_alq] Error code 2 make[3]: stopped in /usr/src/sys/modules --- cleandir_subdir_acpi --- --- cleanobj --- --- cleandir_subdir_ale --- *** [cleandir_subdir_ale] Error code 2 make[3]: stopped in /usr/src/sys/modules --- cleandir_subdir_acpi --- A failure has been detected in another branch of the parallel make >>> Kernel build for OZZIE started on Thu Sep 18 04:35:18 CDT 2014 -------------------------------------------------------------- ===> OZZIE mkdir -p /usr/obj/usr/src/sys -------------------------------------------------------------- >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /usr/src/sys/amd64/conf; PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /usr/obj/usr/src/sys/OZZIE -I '/usr/src/sys/amd64/conf' '/usr/src/sys/amd64/conf/OZZIE' Kernel build directory is /usr/obj/usr/src/sys/OZZIE Don't forget to do ``make cleandepend && make depend'' -------------------------------------------------------------- >>> stage 2.1: cleaning up the object tree -------------------------------------------------------------- cd /usr/obj/usr/src/sys/OZZIE; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp _LDSCRIPTROOT= VERSION="FreeBSD 10.1-BETA1 amd64 1000716" INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin CC="cc " CXX="c++ " CPP="cpp " AS="as" AR="ar" LD="ld" NM=nm OBJDUMP= RANLIB=ranlib STRINGS= COMPILER_TYPE=clang make -j 4 -J 15,16 -m /usr/src/share/mk KERNEL=kernel cleandir --- kernel-clean --- --- kernel-cleandepend --- --- modules-cleandir --- --- kernel-cleandepend --- rm -f .depend machine x86 --- kernel-clean --- rm -f *.o *.so *.So *.ko *.s eddep errs kernel.debug kernel kernel.symbols linterrs tags vers.c vnode_if.c vnode_if.h vnode_if_newproto.h vnode_if_typedef.h agp_if.c ata_if.c eisa_if.c fb_if.c miibus_if.c mmcbr_if.c mmcbus_if.c mvs_if.c card_if.c power_if.c pci_if.c pcib_if.c ppbus_if.c sdhci_if.c hdac_if.c ac97_if.c channel_if.c feeder_if.c mixer_if.c mpu_if.c mpufoi_if.c synth_if.c uart_if.c usb_if.c g_part_if.c g_raid_md_if.c g_raid_tr_if.c isa_if.c bus_if.c clock_if.c cpufreq_if.c device_if.c linker_if.c serdev_if.c xenbus_if.c xenbusb_if.c acpi_if.c acpi_wmi_if.c virtio_bus_if.c virtio_if.c agp_if.h ata_if.h eisa_if.h fb_if.h miibus_if.h mmcbr_if.h mmcbus_if.h mvs_if.h card_if.h power_if.h pci_if.h pcib_if.h ppbus_if.h sdhci_if.h hdac_if.h ac97_if.h channel_if.h feeder_if.h mixer_if.h mpu_if.h mpufoi_if.h synth_if.h uart_if.h usb_if.h g_part_if.h g_raid_md_if.h g_raid_tr_if.h isa_if.h bus_if.h clock_if.h cpufreq_if.h device_if.h linker_if.h serdev_if.h xenbus_if.h xenbusb_if.h acpi_if.h acpi_wmi_if.h virtio_bus_if.h virtio_if.h acpi_quirks.h feeder_eq_gen.h feeder_rate_gen.h snd_fxdiv_gen.h miidevs.h pccarddevs.h teken_state.h usbdevs.h usbdevs_data.h ia32_genassym.o ia32_assym.h acpi_wakecode.o acpi_wakecode.bin acpi_wakecode.h acpi_wakedata.h --- modules-cleandir --- cd /usr/src/sys/modules; MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/OZZIE/modules KMODDIR=/boot/kernel MACHINE_CPUARCH=amd64 DEBUG_FLAGS="-g" MACHINE=amd64 KERNBUILDDIR="/usr/obj/usr/src/sys/OZZIE" SYSDIR="/usr/src/sys" WITH_CTF="1" make cleandir --- cleandir_subdir_aac --- --- cleandir_subdir_aacraid --- --- cleandir_subdir_accf_data --- --- cleandir_subdir_accf_dns --- --- cleandir_subdir_aac --- ===> aac (cleandir) --- cleandir_subdir_aacraid --- ===> aacraid (cleandir) --- cleandir_subdir_accf_data --- ===> accf_data (cleandir) --- cleandir_subdir_accf_dns --- ===> accf_dns (cleandir) --- cleandir_subdir_accf_data --- --- cleanobj --- --- cleandir_subdir_accf_dns --- --- cleanobj --- --- cleandir_subdir_aacraid --- --- cleanobj --- --- cleandir_subdir_aac --- --- cleanobj --- --- cleandir_subdir_accf_http --- --- cleandir_subdir_acl_nfs4 --- --- cleandir_subdir_accf_http --- ===> accf_http (cleandir) --- cleandir_subdir_acl_nfs4 --- ===> acl_nfs4 (cleandir) --- cleandir_subdir_acl_posix1e --- --- cleandir_subdir_acpi --- --- cleandir_subdir_acl_posix1e --- ===> acl_posix1e (cleandir) --- cleandir_subdir_acpi --- ===> acpi (cleandir) --- cleandir_subdir_accf_http --- --- cleanobj --- --- cleandir_subdir_acl_nfs4 --- --- cleanobj --- --- cleandir_subdir_acpi --- --- _sub.cleandir --- ===> acpi/acpi_asus (cleandir) --- cleandir_subdir_ae --- ===> ae (cleandir) --- cleandir_subdir_aesni --- ===> aesni (cleandir) --- cleandir_subdir_acl_posix1e --- --- cleanobj --- --- cleandir_subdir_acpi --- --- cleanobj --- --- cleandir_subdir_age --- ===> age (cleandir) --- cleandir_subdir_aesni --- --- cleanobj --- --- cleandir_subdir_ae --- --- cleanobj --- --- cleandir_subdir_acpi --- ===> acpi/acpi_asus_wmi (cleandir) --- cleandir_subdir_age --- --- cleanobj --- --- cleandir_subdir_acpi --- --- cleanobj --- --- cleandir_subdir_agp --- --- cleandir_subdir_aha --- --- cleandir_subdir_agp --- ===> agp (cleandir) --- cleandir_subdir_aha --- ===> aha (cleandir) --- cleanobj --- --- cleandir_subdir_ahci --- ===> ahci (cleandir) --- cleandir_subdir_aic7xxx --- ===> aic7xxx (cleandir) --- cleandir_subdir_ahci --- --- cleanobj --- --- cleandir_subdir_agp --- --- cleanobj --- --- cleandir_subdir_acpi --- ===> acpi/acpi_fujitsu (cleandir) --- cleandir_subdir_aic7xxx --- --- _sub.cleandir --- ===> aic7xxx/ahc (cleandir) --- cleandir_subdir_aio --- ===> aio (cleandir) --- cleandir_subdir_acpi --- --- cleanobj --- --- cleandir_subdir_aic7xxx --- --- cleanobj --- --- cleandir_subdir_alc --- ===> alc (cleandir) --- cleandir_subdir_aio --- --- cleanobj --- --- cleandir_subdir_acpi --- ===> acpi/acpi_hp (cleandir) --- cleandir_subdir_alc --- --- cleanobj --- --- cleandir_subdir_acpi --- --- cleanobj --- --- cleandir_subdir_aic7xxx --- --- _sub.cleandir --- ===> aic7xxx/ahc/ahc_eisa (cleandir) --- clean --- rm -f export_syms ahc_eisa.ko ahc_eisa.kld ahc_eisa.o ahc_eisa.ko.debug ahc_eisa.ko.symbols opt_scsi.h opt_cam.h opt_aic7xxx.h eisa_if.h pci_if.h bus_if.h device_if.h --- cleanilinks --- rm -f @ machine x86 --- cleandepend --- rm -f .depend GPATH GRTAGS GSYMS GTAGS --- cleanobj --- ===> aic7xxx/ahc/ahc_isa (cleandir) --- cleanobj --- ===> aic7xxx/ahc/ahc_pci (cleandir) --- cleandir_subdir_acpi --- ===> acpi/acpi_ibm (cleandir) --- cleandir_subdir_ale --- ===> ale (cleandir) --- cleandir_subdir_aic7xxx --- --- cleanobj --- --- cleandir_subdir_alq --- ===> alq (cleandir) --- cleandir_subdir_aic7xxx --- --- cleanobj --- rm: fts_read: No such file or directory *** [cleanobj] Error code 1 make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc 1 error make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc *** [_sub.cleandir] Error code 2 make[4]: stopped in /usr/src/sys/modules/aic7xxx 1 error make[4]: stopped in /usr/src/sys/modules/aic7xxx *** [cleandir_subdir_aic7xxx] Error code 2 make[3]: stopped in /usr/src/sys/modules --- cleandir_subdir_alq --- A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/sys/modules/alq --- cleandir_subdir_ale --- A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/sys/modules/ale --- cleandir_subdir_alq --- *** [cleandir_subdir_alq] Error code 2 make[3]: stopped in /usr/src/sys/modules --- cleandir_subdir_acpi --- --- cleanobj --- --- cleandir_subdir_ale --- *** [cleandir_subdir_ale] Error code 2 make[3]: stopped in /usr/src/sys/modules --- cleandir_subdir_acpi --- A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/sys/modules/acpi/acpi_ibm *** [_sub.cleandir] Error code 2 make[4]: stopped in /usr/src/sys/modules/acpi 1 error make[4]: stopped in /usr/src/sys/modules/acpi *** [cleandir_subdir_acpi] Error code 2 make[3]: stopped in /usr/src/sys/modules 4 errors make[3]: stopped in /usr/src/sys/modules *** [modules-cleandir] Error code 2 make[2]: stopped in /usr/obj/usr/src/sys/OZZIE 1 error make[2]: stopped in /usr/obj/usr/src/sys/OZZIE *** [buildkernel] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildkernel] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src make[5]: stopped in /usr/src/sys/modules/acpi/acpi_ibm *** [_sub.cleandir] Error code 2 make[4]: stopped in /usr/src/sys/modules/acpi 1 error make[4]: stopped in /usr/src/sys/modules/acpi *** [cleandir_subdir_acpi] Error code 2 make[3]: stopped in /usr/src/sys/modules 4 errors make[3]: stopped in /usr/src/sys/modules *** [modules-cleandir] Error code 2 make[2]: stopped in /usr/obj/usr/src/sys/OZZIE 1 error make[2]: stopped in /usr/obj/usr/src/sys/OZZIE *** [buildkernel] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildkernel] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src *** [cleandir_subdir_ale] Error code 2 make[3]: stopped in /usr/src/sys/modules --- cleandir_subdir_acpi --- A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/sys/modules/acpi/acpi_ibm *** [_sub.cleandir] Error code 2 make[4]: stopped in /usr/src/sys/modules/acpi 1 error make[4]: stopped in /usr/src/sys/modules/acpi *** [cleandir_subdir_acpi] Error code 2 make[3]: stopped in /usr/src/sys/modules 4 errors make[3]: stopped in /usr/src/sys/modules *** [modules-cleandir] Error code 2 make[2]: stopped in /usr/obj/usr/src/sys/MYFINEHOST 1 error make[2]: stopped in /usr/obj/usr/src/sys/MYFINEHOST *** [buildkernel] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildkernel] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src -- ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/ From owner-freebsd-stable@FreeBSD.ORG Thu Sep 18 23:06:13 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54E41142 for ; Thu, 18 Sep 2014 23:06:13 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 718EB248 for ; Thu, 18 Sep 2014 23:06:12 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 9E21020E7088E; Thu, 18 Sep 2014 23:06:11 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: * X-Spam-Status: No, score=2.0 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,RDNS_DYNAMIC autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 7979D20E7088A; Thu, 18 Sep 2014 23:06:08 +0000 (UTC) Message-ID: From: "Steven Hartland" To: "Tim Daneliuk" , "FreeBSD Stable" References: <541B6167.3000703@tundraware.com> Subject: Re: 10.1Beta - Ongoing Build Problems Date: Fri, 19 Sep 2014 00:06:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 23:06:13 -0000 IIRC this can happen if your building on a box which is too old. I've been doing loads of stable/10 builds recently with -j24 and only had an issue a while back, updating the world on the box in question (using no -j) fixed it for me. Regards Steve ----- Original Message ----- From: "Tim Daneliuk" To: "FreeBSD Stable" Sent: Thursday, September 18, 2014 11:49 PM Subject: 10.1Beta - Ongoing Build Problems >I continue to see problems as seen below if I attempt a parallel make. > If I remove the '-j4' from my build script, this build completes fine, > albeit much more slowly. Ideas anyone??: > > >>>> Kernel build for MYFINEHOST started on Thu Sep 18 04:35:18 CDT 2014 > -------------------------------------------------------------- > ===> MYFINEHOST > mkdir -p /usr/obj/usr/src/sys > -------------------------------------------------------------- >>>> stage 1: configuring the kernel > -------------------------------------------------------------- > cd /usr/src/sys/amd64/conf; > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin > config -d /usr/obj/usr/src/sys/MYFINEHOST -I '/usr/src/sys/amd64/conf' '/usr/src/sys/amd64/conf/MYFINEHOST' > Kernel build directory is /usr/obj/usr/src/sys/MYFINEHOST > Don't forget to do ``make cleandepend && make depend'' > -------------------------------------------------------------- >>>> stage 2.1: cleaning up the object tree > -------------------------------------------------------------- > cd /usr/obj/usr/src/sys/MYFINEHOST; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= > GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font > GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp _LDSCRIPTROOT= VERSION="FreeBSD > 10.1-BETA1 amd64 1000716" INSTALL="sh /usr/src/tools/install.sh" > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin > CC="cc " CXX="c++ " CPP="cpp " AS="as" AR="ar" LD="ld" NM=nm OBJDUMP= RANLIB=ranlib STRINGS= COMPILER_TYPE=clang make -j 4 -J > 15,16 -m /usr/src/share/mk KERNEL=kernel cleandir > --- kernel-clean --- > --- kernel-cleandepend --- > --- modules-cleandir --- > --- kernel-cleandepend --- > rm -f .depend machine x86 > --- kernel-clean --- > rm -f *.o *.so *.So *.ko *.s eddep errs kernel.debug kernel kernel.symbols linterrs tags vers.c vnode_if.c vnode_if.h > vnode_if_newproto.h vnode_if_typedef.h agp_if.c ata_if.c eisa_if.c fb_if.c miibus_if.c mmcbr_if.c mmcbus_if.c mvs_if.c card_if.c > power_if.c pci_if.c pcib_if.c ppbus_if.c sdhci_if.c hdac_if.c ac97_if.c channel_if.c feeder_if.c mixer_if.c mpu_if.c mpufoi_if.c > synth_if.c uart_if.c usb_if.c g_part_if.c g_raid_md_if.c g_raid_tr_if.c isa_if.c bus_if.c clock_if.c cpufreq_if.c device_if.c > linker_if.c serdev_if.c xenbus_if.c xenbusb_if.c acpi_if.c acpi_wmi_if.c virtio_bus_if.c virtio_if.c agp_if.h ata_if.h eisa_if.h > fb_if.h miibus_if.h mmcbr_if.h mmcbus_if.h mvs_if.h card_if.h power_if.h pci_if.h pcib_if.h ppbus_if.h sdhci_if.h hdac_if.h > ac97_if.h channel_if.h feeder_if.h mixer_if.h mpu_if.h mpufoi_if.h synth_if.h uart_if.h usb_if.h g_part_if.h g_raid_md_if.h > g_raid_tr_if.h isa_if.h bus_if.h clock_if.h cpufreq_if.h device_if.h linker_if.h serdev_if.h xenbus_if.h xenbusb_if.h acpi_if.h > acpi_wmi_if.h virtio_bus_if.h virtio_if.h acpi_quirks.h feeder_eq_gen.h feeder_rate_gen.h snd_fxdiv_gen.h miidevs.h pccarddevs.h > teken_state.h usbdevs.h usbdevs_data.h ia32_genassym.o ia32_assym.h acpi_wakecode.o acpi_wakecode.bin acpi_wakecode.h > acpi_wakedata.h > --- modules-cleandir --- > cd /usr/src/sys/modules; MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/MYFINEHOST/modules KMODDIR=/boot/kernel MACHINE_CPUARCH=amd64 > DEBUG_FLAGS="-g" MACHINE=amd64 KERNBUILDDIR="/usr/obj/usr/src/sys/MYFINEHOST" SYSDIR="/usr/src/sys" WITH_CTF="1" make cleandir > --- cleandir_subdir_aac --- > --- cleandir_subdir_aacraid --- > --- cleandir_subdir_accf_data --- > --- cleandir_subdir_accf_dns --- > --- cleandir_subdir_aac --- > ===> aac (cleandir) > --- cleandir_subdir_aacraid --- > ===> aacraid (cleandir) > --- cleandir_subdir_accf_data --- > ===> accf_data (cleandir) > --- cleandir_subdir_accf_dns --- > ===> accf_dns (cleandir) > --- cleandir_subdir_accf_data --- > --- cleanobj --- > --- cleandir_subdir_accf_dns --- > --- cleanobj --- > --- cleandir_subdir_aacraid --- > --- cleanobj --- > --- cleandir_subdir_aac --- > --- cleanobj --- > --- cleandir_subdir_accf_http --- > --- cleandir_subdir_acl_nfs4 --- > --- cleandir_subdir_accf_http --- > ===> accf_http (cleandir) > --- cleandir_subdir_acl_nfs4 --- > ===> acl_nfs4 (cleandir) > --- cleandir_subdir_acl_posix1e --- > --- cleandir_subdir_acpi --- > --- cleandir_subdir_acl_posix1e --- > ===> acl_posix1e (cleandir) > --- cleandir_subdir_acpi --- > ===> acpi (cleandir) > --- cleandir_subdir_accf_http --- > --- cleanobj --- > --- cleandir_subdir_acl_nfs4 --- > --- cleanobj --- > --- cleandir_subdir_acpi --- > --- _sub.cleandir --- > ===> acpi/acpi_asus (cleandir) > --- cleandir_subdir_ae --- > ===> ae (cleandir) > --- cleandir_subdir_aesni --- > ===> aesni (cleandir) > --- cleandir_subdir_acl_posix1e --- > --- cleanobj --- > --- cleandir_subdir_acpi --- > --- cleanobj --- > --- cleandir_subdir_age --- > ===> age (cleandir) > --- cleandir_subdir_aesni --- > --- cleanobj --- > --- cleandir_subdir_ae --- > --- cleanobj --- > --- cleandir_subdir_acpi --- > ===> acpi/acpi_asus_wmi (cleandir) > --- cleandir_subdir_age --- > --- cleanobj --- > --- cleandir_subdir_acpi --- > --- cleanobj --- > --- cleandir_subdir_agp --- > --- cleandir_subdir_aha --- > --- cleandir_subdir_agp --- > ===> agp (cleandir) > --- cleandir_subdir_aha --- > ===> aha (cleandir) > --- cleanobj --- > --- cleandir_subdir_ahci --- > ===> ahci (cleandir) > --- cleandir_subdir_aic7xxx --- > ===> aic7xxx (cleandir) > --- cleandir_subdir_ahci --- > --- cleanobj --- > --- cleandir_subdir_agp --- > --- cleanobj --- > --- cleandir_subdir_acpi --- > ===> acpi/acpi_fujitsu (cleandir) > --- cleandir_subdir_aic7xxx --- > --- _sub.cleandir --- > ===> aic7xxx/ahc (cleandir) > --- cleandir_subdir_aio --- > ===> aio (cleandir) > --- cleandir_subdir_acpi --- > --- cleanobj --- > --- cleandir_subdir_aic7xxx --- > --- cleanobj --- > --- cleandir_subdir_alc --- > ===> alc (cleandir) > --- cleandir_subdir_aio --- > --- cleanobj --- > --- cleandir_subdir_acpi --- > ===> acpi/acpi_hp (cleandir) > --- cleandir_subdir_alc --- > --- cleanobj --- > --- cleandir_subdir_acpi --- > --- cleanobj --- > --- cleandir_subdir_aic7xxx --- > --- _sub.cleandir --- > ===> aic7xxx/ahc/ahc_eisa (cleandir) > --- clean --- > rm -f export_syms ahc_eisa.ko ahc_eisa.kld ahc_eisa.o ahc_eisa.ko.debug ahc_eisa.ko.symbols opt_scsi.h opt_cam.h opt_aic7xxx.h > eisa_if.h pci_if.h bus_if.h device_if.h > --- cleanilinks --- > rm -f @ machine x86 > --- cleandepend --- > rm -f .depend GPATH GRTAGS GSYMS GTAGS > --- cleanobj --- > ===> aic7xxx/ahc/ahc_isa (cleandir) > --- cleanobj --- > ===> aic7xxx/ahc/ahc_pci (cleandir) > --- cleandir_subdir_acpi --- > ===> acpi/acpi_ibm (cleandir) > --- cleandir_subdir_ale --- > ===> ale (cleandir) > --- cleandir_subdir_aic7xxx --- > --- cleanobj --- > --- cleandir_subdir_alq --- > ===> alq (cleandir) > --- cleandir_subdir_aic7xxx --- > --- cleanobj --- > rm: fts_read: No such file or directory > *** [cleanobj] Error code 1 > > make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc > 1 error > > make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc > *** [_sub.cleandir] Error code 2 > > make[4]: stopped in /usr/src/sys/modules/aic7xxx > 1 error > > make[4]: stopped in /usr/src/sys/modules/aic7xxx > *** [cleandir_subdir_aic7xxx] Error code 2 > > make[3]: stopped in /usr/src/sys/modules > --- cleandir_subdir_alq --- > A failure has been detected in another branch of the parallel make > > make[4]: stopped in /usr/src/sys/modules/alq > --- cleandir_subdir_ale --- > A failure has been detected in another branch of the parallel make > > make[4]: stopped in /usr/src/sys/modules/ale > --- cleandir_subdir_alq --- > *** [cleandir_subdir_alq] Error code 2 > > make[3]: stopped in /usr/src/sys/modules > --- cleandir_subdir_acpi --- > --- cleanobj --- > --- cleandir_subdir_ale --->>> Kernel build for OZZIE started on Thu Sep 18 04:35:18 CDT 2014 > -------------------------------------------------------------- > ===> OZZIE > mkdir -p /usr/obj/usr/src/sys > -------------------------------------------------------------- >>>> stage 1: configuring the kernel > -------------------------------------------------------------- > cd /usr/src/sys/amd64/conf; > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin > config -d /usr/obj/usr/src/sys/OZZIE -I '/usr/src/sys/amd64/conf' '/usr/src/sys/amd64/conf/OZZIE' > Kernel build directory is /usr/obj/usr/src/sys/OZZIE > Don't forget to do ``make cleandepend && make depend'' > -------------------------------------------------------------- >>>> stage 2.1: cleaning up the object tree > -------------------------------------------------------------- > cd /usr/obj/usr/src/sys/OZZIE; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= > GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font > GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp _LDSCRIPTROOT= VERSION="FreeBSD > 10.1-BETA1 amd64 1000716" INSTALL="sh /usr/src/tools/install.sh" > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin > CC="cc " CXX="c++ " CPP="cpp " AS="as" AR="ar" LD="ld" NM=nm OBJDUMP= RANLIB=ranlib STRINGS= COMPILER_TYPE=clang make -j 4 -J > 15,16 -m /usr/src/share/mk KERNEL=kernel cleandir > --- kernel-clean --- > --- kernel-cleandepend --- > --- modules-cleandir --- > --- kernel-cleandepend --- > rm -f .depend machine x86 > --- kernel-clean --- > rm -f *.o *.so *.So *.ko *.s eddep errs kernel.debug kernel kernel.symbols linterrs tags vers.c vnode_if.c vnode_if.h > vnode_if_newproto.h vnode_if_typedef.h agp_if.c ata_if.c eisa_if.c fb_if.c miibus_if.c mmcbr_if.c mmcbus_if.c mvs_if.c card_if.c > power_if.c pci_if.c pcib_if.c ppbus_if.c sdhci_if.c hdac_if.c ac97_if.c channel_if.c feeder_if.c mixer_if.c mpu_if.c mpufoi_if.c > synth_if.c uart_if.c usb_if.c g_part_if.c g_raid_md_if.c g_raid_tr_if.c isa_if.c bus_if.c clock_if.c cpufreq_if.c device_if.c > linker_if.c serdev_if.c xenbus_if.c xenbusb_if.c acpi_if.c acpi_wmi_if.c virtio_bus_if.c virtio_if.c agp_if.h ata_if.h eisa_if.h > fb_if.h miibus_if.h mmcbr_if.h mmcbus_if.h mvs_if.h card_if.h power_if.h pci_if.h pcib_if.h ppbus_if.h sdhci_if.h hdac_if.h > ac97_if.h channel_if.h feeder_if.h mixer_if.h mpu_if.h mpufoi_if.h synth_if.h uart_if.h usb_if.h g_part_if.h g_raid_md_if.h > g_raid_tr_if.h isa_if.h bus_if.h clock_if.h cpufreq_if.h device_if.h linker_if.h serdev_if.h xenbus_if.h xenbusb_if.h acpi_if.h > acpi_wmi_if.h virtio_bus_if.h virtio_if.h acpi_quirks.h feeder_eq_gen.h feeder_rate_gen.h snd_fxdiv_gen.h miidevs.h pccarddevs.h > teken_state.h usbdevs.h usbdevs_data.h ia32_genassym.o ia32_assym.h acpi_wakecode.o acpi_wakecode.bin acpi_wakecode.h > acpi_wakedata.h > --- modules-cleandir --- > cd /usr/src/sys/modules; MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/OZZIE/modules KMODDIR=/boot/kernel MACHINE_CPUARCH=amd64 > DEBUG_FLAGS="-g" MACHINE=amd64 KERNBUILDDIR="/usr/obj/usr/src/sys/OZZIE" SYSDIR="/usr/src/sys" WITH_CTF="1" make cleandir > --- cleandir_subdir_aac --- > --- cleandir_subdir_aacraid --- > --- cleandir_subdir_accf_data --- > --- cleandir_subdir_accf_dns --- > --- cleandir_subdir_aac --- > ===> aac (cleandir) > --- cleandir_subdir_aacraid --- > ===> aacraid (cleandir) > --- cleandir_subdir_accf_data --- > ===> accf_data (cleandir) > --- cleandir_subdir_accf_dns --- > ===> accf_dns (cleandir) > --- cleandir_subdir_accf_data --- > --- cleanobj --- > --- cleandir_subdir_accf_dns --- > --- cleanobj --- > --- cleandir_subdir_aacraid --- > --- cleanobj --- > --- cleandir_subdir_aac --- > --- cleanobj --- > --- cleandir_subdir_accf_http --- > --- cleandir_subdir_acl_nfs4 --- > --- cleandir_subdir_accf_http --- > ===> accf_http (cleandir) > --- cleandir_subdir_acl_nfs4 --- > ===> acl_nfs4 (cleandir) > --- cleandir_subdir_acl_posix1e --- > --- cleandir_subdir_acpi --- > --- cleandir_subdir_acl_posix1e --- > ===> acl_posix1e (cleandir) > --- cleandir_subdir_acpi --- > ===> acpi (cleandir) > --- cleandir_subdir_accf_http --- > --- cleanobj --- > --- cleandir_subdir_acl_nfs4 --- > --- cleanobj --- > --- cleandir_subdir_acpi --- > --- _sub.cleandir --- > ===> acpi/acpi_asus (cleandir) > --- cleandir_subdir_ae --- > ===> ae (cleandir) > --- cleandir_subdir_aesni --- > ===> aesni (cleandir) > --- cleandir_subdir_acl_posix1e --- > --- cleanobj --- > --- cleandir_subdir_acpi --- > --- cleanobj --- > --- cleandir_subdir_age --- > ===> age (cleandir) > --- cleandir_subdir_aesni --- > --- cleanobj --- > --- cleandir_subdir_ae --- > --- cleanobj --- > --- cleandir_subdir_acpi --- > ===> acpi/acpi_asus_wmi (cleandir) > --- cleandir_subdir_age --- > --- cleanobj --- > --- cleandir_subdir_acpi --- > --- cleanobj --- > --- cleandir_subdir_agp --- > --- cleandir_subdir_aha --- > --- cleandir_subdir_agp --- > ===> agp (cleandir) > --- cleandir_subdir_aha --- > ===> aha (cleandir) > --- cleanobj --- > --- cleandir_subdir_ahci --- > ===> ahci (cleandir) > --- cleandir_subdir_aic7xxx --- > ===> aic7xxx (cleandir) > --- cleandir_subdir_ahci --- > --- cleanobj --- > --- cleandir_subdir_agp --- > --- cleanobj --- > --- cleandir_subdir_acpi --- > ===> acpi/acpi_fujitsu (cleandir) > --- cleandir_subdir_aic7xxx --- > --- _sub.cleandir --- > ===> aic7xxx/ahc (cleandir) > --- cleandir_subdir_aio --- > ===> aio (cleandir) > --- cleandir_subdir_acpi --- > --- cleanobj --- > --- cleandir_subdir_aic7xxx --- > --- cleanobj --- > --- cleandir_subdir_alc --- > ===> alc (cleandir) > --- cleandir_subdir_aio --- > --- cleanobj --- > --- cleandir_subdir_acpi --- > ===> acpi/acpi_hp (cleandir) > --- cleandir_subdir_alc --- > --- cleanobj --- > --- cleandir_subdir_acpi --- > --- cleanobj --- > --- cleandir_subdir_aic7xxx --- > --- _sub.cleandir --- > ===> aic7xxx/ahc/ahc_eisa (cleandir) > --- clean --- > rm -f export_syms ahc_eisa.ko ahc_eisa.kld ahc_eisa.o ahc_eisa.ko.debug ahc_eisa.ko.symbols opt_scsi.h opt_cam.h opt_aic7xxx.h > eisa_if.h pci_if.h bus_if.h device_if.h > --- cleanilinks --- > rm -f @ machine x86 > --- cleandepend --- > rm -f .depend GPATH GRTAGS GSYMS GTAGS > --- cleanobj --- > ===> aic7xxx/ahc/ahc_isa (cleandir) > --- cleanobj --- > ===> aic7xxx/ahc/ahc_pci (cleandir) > --- cleandir_subdir_acpi --- > ===> acpi/acpi_ibm (cleandir) > --- cleandir_subdir_ale --- > ===> ale (cleandir) > --- cleandir_subdir_aic7xxx --- > --- cleanobj --- > --- cleandir_subdir_alq --- > ===> alq (cleandir) > --- cleandir_subdir_aic7xxx --- > --- cleanobj --- > rm: fts_read: No such file or directory > *** [cleanobj] Error code 1 > > make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc > 1 error > > make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc > *** [_sub.cleandir] Error code 2 > > make[4]: stopped in /usr/src/sys/modules/aic7xxx > 1 error > > make[4]: stopped in /usr/src/sys/modules/aic7xxx > *** [cleandir_subdir_aic7xxx] Error code 2 > > make[3]: stopped in /usr/src/sys/modules > --- cleandir_subdir_alq --- > A failure has been detected in another branch of the parallel make > > make[4]: stopped in /usr/src/sys/modules/alq > --- cleandir_subdir_ale --- > A failure has been detected in another branch of the parallel make > > make[4]: stopped in /usr/src/sys/modules/ale > --- cleandir_subdir_alq --- > *** [cleandir_subdir_alq] Error code 2 > > make[3]: stopped in /usr/src/sys/modules > --- cleandir_subdir_acpi --- > --- cleanobj --- > --- cleandir_subdir_ale --- > *** [cleandir_subdir_ale] Error code 2 > > make[3]: stopped in /usr/src/sys/modules > --- cleandir_subdir_acpi --- > A failure has been detected in another branch of the parallel make >>>> Kernel build for OZZIE started on Thu Sep 18 04:35:18 CDT 2014 > -------------------------------------------------------------- > ===> OZZIE > mkdir -p /usr/obj/usr/src/sys > -------------------------------------------------------------- >>>> stage 1: configuring the kernel > -------------------------------------------------------------- > cd /usr/src/sys/amd64/conf; > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin > config -d /usr/obj/usr/src/sys/OZZIE -I '/usr/src/sys/amd64/conf' '/usr/src/sys/amd64/conf/OZZIE' > Kernel build directory is /usr/obj/usr/src/sys/OZZIE > Don't forget to do ``make cleandepend && make depend'' > -------------------------------------------------------------- >>>> stage 2.1: cleaning up the object tree > -------------------------------------------------------------- > cd /usr/obj/usr/src/sys/OZZIE; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= > GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font > GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp _LDSCRIPTROOT= VERSION="FreeBSD > 10.1-BETA1 amd64 1000716" INSTALL="sh /usr/src/tools/install.sh" > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin > CC="cc " CXX="c++ " CPP="cpp " AS="as" AR="ar" LD="ld" NM=nm OBJDUMP= RANLIB=ranlib STRINGS= COMPILER_TYPE=clang make -j 4 -J > 15,16 -m /usr/src/share/mk KERNEL=kernel cleandir > --- kernel-clean --- > --- kernel-cleandepend --- > --- modules-cleandir --- > --- kernel-cleandepend --- > rm -f .depend machine x86 > --- kernel-clean --- > rm -f *.o *.so *.So *.ko *.s eddep errs kernel.debug kernel kernel.symbols linterrs tags vers.c vnode_if.c vnode_if.h > vnode_if_newproto.h vnode_if_typedef.h agp_if.c ata_if.c eisa_if.c fb_if.c miibus_if.c mmcbr_if.c mmcbus_if.c mvs_if.c card_if.c > power_if.c pci_if.c pcib_if.c ppbus_if.c sdhci_if.c hdac_if.c ac97_if.c channel_if.c feeder_if.c mixer_if.c mpu_if.c mpufoi_if.c > synth_if.c uart_if.c usb_if.c g_part_if.c g_raid_md_if.c g_raid_tr_if.c isa_if.c bus_if.c clock_if.c cpufreq_if.c device_if.c > linker_if.c serdev_if.c xenbus_if.c xenbusb_if.c acpi_if.c acpi_wmi_if.c virtio_bus_if.c virtio_if.c agp_if.h ata_if.h eisa_if.h > fb_if.h miibus_if.h mmcbr_if.h mmcbus_if.h mvs_if.h card_if.h power_if.h pci_if.h pcib_if.h ppbus_if.h sdhci_if.h hdac_if.h > ac97_if.h channel_if.h feeder_if.h mixer_if.h mpu_if.h mpufoi_if.h synth_if.h uart_if.h usb_if.h g_part_if.h g_raid_md_if.h > g_raid_tr_if.h isa_if.h bus_if.h clock_if.h cpufreq_if.h device_if.h linker_if.h serdev_if.h xenbus_if.h xenbusb_if.h acpi_if.h > acpi_wmi_if.h virtio_bus_if.h virtio_if.h acpi_quirks.h feeder_eq_gen.h feeder_rate_gen.h snd_fxdiv_gen.h miidevs.h pccarddevs.h > teken_state.h usbdevs.h usbdevs_data.h ia32_genassym.o ia32_assym.h acpi_wakecode.o acpi_wakecode.bin acpi_wakecode.h > acpi_wakedata.h > --- modules-cleandir --- > cd /usr/src/sys/modules; MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/OZZIE/modules KMODDIR=/boot/kernel MACHINE_CPUARCH=amd64 > DEBUG_FLAGS="-g" MACHINE=amd64 KERNBUILDDIR="/usr/obj/usr/src/sys/OZZIE" SYSDIR="/usr/src/sys" WITH_CTF="1" make cleandir > --- cleandir_subdir_aac --- > --- cleandir_subdir_aacraid --- > --- cleandir_subdir_accf_data --- > --- cleandir_subdir_accf_dns --- > --- cleandir_subdir_aac --- > ===> aac (cleandir) > --- cleandir_subdir_aacraid --- > ===> aacraid (cleandir) > --- cleandir_subdir_accf_data --- > ===> accf_data (cleandir) > --- cleandir_subdir_accf_dns --- > ===> accf_dns (cleandir) > --- cleandir_subdir_accf_data --- > --- cleanobj --- > --- cleandir_subdir_accf_dns --- > --- cleanobj --- > --- cleandir_subdir_aacraid --- > --- cleanobj --- > --- cleandir_subdir_aac --- > --- cleanobj --- > --- cleandir_subdir_accf_http --- > --- cleandir_subdir_acl_nfs4 --- > --- cleandir_subdir_accf_http --- > ===> accf_http (cleandir) > --- cleandir_subdir_acl_nfs4 --- > ===> acl_nfs4 (cleandir) > --- cleandir_subdir_acl_posix1e --- > --- cleandir_subdir_acpi --- > --- cleandir_subdir_acl_posix1e --- > ===> acl_posix1e (cleandir) > --- cleandir_subdir_acpi --- > ===> acpi (cleandir) > --- cleandir_subdir_accf_http --- > --- cleanobj --- > --- cleandir_subdir_acl_nfs4 --- > --- cleanobj --- > --- cleandir_subdir_acpi --- > --- _sub.cleandir --- > ===> acpi/acpi_asus (cleandir) > --- cleandir_subdir_ae --- > ===> ae (cleandir) > --- cleandir_subdir_aesni --- > ===> aesni (cleandir) > --- cleandir_subdir_acl_posix1e --- > --- cleanobj --- > --- cleandir_subdir_acpi --- > --- cleanobj --- > --- cleandir_subdir_age --- > ===> age (cleandir) > --- cleandir_subdir_aesni --- > --- cleanobj --- > --- cleandir_subdir_ae --- > --- cleanobj --- > --- cleandir_subdir_acpi --- > ===> acpi/acpi_asus_wmi (cleandir) > --- cleandir_subdir_age --- > --- cleanobj --- > --- cleandir_subdir_acpi --- > --- cleanobj --- > --- cleandir_subdir_agp --- > --- cleandir_subdir_aha --- > --- cleandir_subdir_agp --- > ===> agp (cleandir) > --- cleandir_subdir_aha --- > ===> aha (cleandir) > --- cleanobj --- > --- cleandir_subdir_ahci --- > ===> ahci (cleandir) > --- cleandir_subdir_aic7xxx --- > ===> aic7xxx (cleandir) > --- cleandir_subdir_ahci --- > --- cleanobj --- > --- cleandir_subdir_agp --- > --- cleanobj --- > --- cleandir_subdir_acpi --- > ===> acpi/acpi_fujitsu (cleandir) > --- cleandir_subdir_aic7xxx --- > --- _sub.cleandir --- > ===> aic7xxx/ahc (cleandir) > --- cleandir_subdir_aio --- > ===> aio (cleandir) > --- cleandir_subdir_acpi --- > --- cleanobj --- > --- cleandir_subdir_aic7xxx --- > --- cleanobj --- > --- cleandir_subdir_alc --- > ===> alc (cleandir) > --- cleandir_subdir_aio --- > --- cleanobj --- > --- cleandir_subdir_acpi --- > ===> acpi/acpi_hp (cleandir) > --- cleandir_subdir_alc --- > --- cleanobj --- > --- cleandir_subdir_acpi --- > --- cleanobj --- > --- cleandir_subdir_aic7xxx --- > --- _sub.cleandir --- > ===> aic7xxx/ahc/ahc_eisa (cleandir) > --- clean --- > rm -f export_syms ahc_eisa.ko ahc_eisa.kld ahc_eisa.o ahc_eisa.ko.debug ahc_eisa.ko.symbols opt_scsi.h opt_cam.h opt_aic7xxx.h > eisa_if.h pci_if.h bus_if.h device_if.h > --- cleanilinks --- > rm -f @ machine x86 > --- cleandepend --- > rm -f .depend GPATH GRTAGS GSYMS GTAGS > --- cleanobj --- > ===> aic7xxx/ahc/ahc_isa (cleandir) > --- cleanobj --- > ===> aic7xxx/ahc/ahc_pci (cleandir) > --- cleandir_subdir_acpi --- > ===> acpi/acpi_ibm (cleandir) > --- cleandir_subdir_ale --- > ===> ale (cleandir) > --- cleandir_subdir_aic7xxx --- > --- cleanobj --- > --- cleandir_subdir_alq --- > ===> alq (cleandir) > --- cleandir_subdir_aic7xxx --- > --- cleanobj --- > rm: fts_read: No such file or directory > *** [cleanobj] Error code 1 > > make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc > 1 error > > make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc > *** [_sub.cleandir] Error code 2 > > make[4]: stopped in /usr/src/sys/modules/aic7xxx > 1 error > > make[4]: stopped in /usr/src/sys/modules/aic7xxx > *** [cleandir_subdir_aic7xxx] Error code 2 > > make[3]: stopped in /usr/src/sys/modules > --- cleandir_subdir_alq --- > A failure has been detected in another branch of the parallel make > > make[4]: stopped in /usr/src/sys/modules/alq > --- cleandir_subdir_ale --- > A failure has been detected in another branch of the parallel make > > make[4]: stopped in /usr/src/sys/modules/ale > --- cleandir_subdir_alq --- > *** [cleandir_subdir_alq] Error code 2 > > make[3]: stopped in /usr/src/sys/modules > --- cleandir_subdir_acpi --- > --- cleanobj --- > --- cleandir_subdir_ale --- > *** [cleandir_subdir_ale] Error code 2 > > make[3]: stopped in /usr/src/sys/modules > --- cleandir_subdir_acpi --- > A failure has been detected in another branch of the parallel make > > make[5]: stopped in /usr/src/sys/modules/acpi/acpi_ibm > *** [_sub.cleandir] Error code 2 > > make[4]: stopped in /usr/src/sys/modules/acpi > 1 error > > make[4]: stopped in /usr/src/sys/modules/acpi > *** [cleandir_subdir_acpi] Error code 2 > > make[3]: stopped in /usr/src/sys/modules > 4 errors > > make[3]: stopped in /usr/src/sys/modules > *** [modules-cleandir] Error code 2 > > make[2]: stopped in /usr/obj/usr/src/sys/OZZIE > 1 error > > make[2]: stopped in /usr/obj/usr/src/sys/OZZIE > *** [buildkernel] Error code 2 > > make[1]: stopped in /usr/src > 1 error > > make[1]: stopped in /usr/src > *** [buildkernel] Error code 2 > > make: stopped in /usr/src > 1 error > > make: stopped in /usr/src > > make[5]: stopped in /usr/src/sys/modules/acpi/acpi_ibm > *** [_sub.cleandir] Error code 2 > > make[4]: stopped in /usr/src/sys/modules/acpi > 1 error > > make[4]: stopped in /usr/src/sys/modules/acpi > *** [cleandir_subdir_acpi] Error code 2 > > make[3]: stopped in /usr/src/sys/modules > 4 errors > > make[3]: stopped in /usr/src/sys/modules > *** [modules-cleandir] Error code 2 > > make[2]: stopped in /usr/obj/usr/src/sys/OZZIE > 1 error > > make[2]: stopped in /usr/obj/usr/src/sys/OZZIE > *** [buildkernel] Error code 2 > > make[1]: stopped in /usr/src > 1 error > > make[1]: stopped in /usr/src > *** [buildkernel] Error code 2 > > make: stopped in /usr/src > 1 error > > make: stopped in /usr/src > > *** [cleandir_subdir_ale] Error code 2 > > make[3]: stopped in /usr/src/sys/modules > --- cleandir_subdir_acpi --- > A failure has been detected in another branch of the parallel make > > make[5]: stopped in /usr/src/sys/modules/acpi/acpi_ibm > *** [_sub.cleandir] Error code 2 > > make[4]: stopped in /usr/src/sys/modules/acpi > 1 error > > make[4]: stopped in /usr/src/sys/modules/acpi > *** [cleandir_subdir_acpi] Error code 2 > > make[3]: stopped in /usr/src/sys/modules > 4 errors > > make[3]: stopped in /usr/src/sys/modules > *** [modules-cleandir] Error code 2 > > make[2]: stopped in /usr/obj/usr/src/sys/MYFINEHOST > 1 error > > make[2]: stopped in /usr/obj/usr/src/sys/MYFINEHOST > *** [buildkernel] Error code 2 > > make[1]: stopped in /usr/src > 1 error > > make[1]: stopped in /usr/src > *** [buildkernel] Error code 2 > > make: stopped in /usr/src > 1 error > > make: stopped in /usr/src > > -- > ---------------------------------------------------------------------------- > Tim Daneliuk tundra@tundraware.com > PGP Key: http://www.tundraware.com/PGP/ > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Thu Sep 18 23:27:54 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5DB19425 for ; Thu, 18 Sep 2014 23:27:54 +0000 (UTC) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ozzie.tundraware.com", Issuer "ozzie.tundraware.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 25FAD5FE for ; Thu, 18 Sep 2014 23:27:54 +0000 (UTC) Received: from [192.168.0.2] (viper.tundraware.com [192.168.0.2]) (authenticated bits=0) by ozzie.tundraware.com (8.14.9/8.14.9) with ESMTP id s8INRhOO038321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 18 Sep 2014 18:27:44 -0500 (CDT) (envelope-from tundra@tundraware.com) Message-ID: <541B6A6F.5010501@tundraware.com> Date: Thu, 18 Sep 2014 18:27:43 -0500 From: Tim Daneliuk User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Steven Hartland , FreeBSD Stable Subject: Re: 10.1Beta - Ongoing Build Problems References: <541B6167.3000703@tundraware.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (ozzie.tundraware.com [75.145.138.73]); Thu, 18 Sep 2014 18:27:44 -0500 (CDT) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: s8INRhOO038321 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 23:27:54 -0000 On 09/18/2014 06:06 PM, Steven Hartland wrote: > IIRC this can happen if your building on a box which is too old. > > I've been doing loads of stable/10 builds recently with -j24 and > only had an issue a while back, updating the world on the box > in question (using no -j) fixed it for me. > > Regards > Steve The hardware is pretty new and the OS was updated within the last several weeks to the then -STABLE branch. I've been seeing this on- and off for a while. > > ----- Original Message ----- From: "Tim Daneliuk" > To: "FreeBSD Stable" > Sent: Thursday, September 18, 2014 11:49 PM > Subject: 10.1Beta - Ongoing Build Problems > > >> I continue to see problems as seen below if I attempt a parallel make. >> If I remove the '-j4' from my build script, this build completes fine, >> albeit much more slowly. Ideas anyone??: >> >> >>>>> Kernel build for MYFINEHOST started on Thu Sep 18 04:35:18 CDT 2014 >> -------------------------------------------------------------- >> ===> MYFINEHOST >> mkdir -p /usr/obj/usr/src/sys >> -------------------------------------------------------------- >>>>> stage 1: configuring the kernel >> -------------------------------------------------------------- >> cd /usr/src/sys/amd64/conf; >> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin >> config -d /usr/obj/usr/src/sys/MYFINEHOST -I '/usr/src/sys/amd64/conf' >> '/usr/src/sys/amd64/conf/MYFINEHOST' >> Kernel build directory is /usr/obj/usr/src/sys/MYFINEHOST >> Don't forget to do ``make cleandepend && make depend'' >> -------------------------------------------------------------- >>>>> stage 2.1: cleaning up the object tree >> -------------------------------------------------------------- >> cd /usr/obj/usr/src/sys/MYFINEHOST; MAKEOBJDIRPREFIX=/usr/obj >> MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= >> GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin >> GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font >> GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac >> _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp _LDSCRIPTROOT= VERSION="FreeBSD >> 10.1-BETA1 amd64 1000716" INSTALL="sh /usr/src/tools/install.sh" >> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin >> CC="cc " CXX="c++ " CPP="cpp " AS="as" AR="ar" LD="ld" NM=nm OBJDUMP= >> RANLIB=ranlib STRINGS= COMPILER_TYPE=clang make -j 4 -J 15,16 -m >> /usr/src/share/mk KERNEL=kernel cleandir >> --- kernel-clean --- >> --- kernel-cleandepend --- >> --- modules-cleandir --- >> --- kernel-cleandepend --- >> rm -f .depend machine x86 >> --- kernel-clean --- >> rm -f *.o *.so *.So *.ko *.s eddep errs kernel.debug kernel kernel.symbols >> linterrs tags vers.c vnode_if.c vnode_if.h vnode_if_newproto.h >> vnode_if_typedef.h agp_if.c ata_if.c eisa_if.c fb_if.c miibus_if.c mmcbr_if.c >> mmcbus_if.c mvs_if.c card_if.c power_if.c pci_if.c pcib_if.c ppbus_if.c >> sdhci_if.c hdac_if.c ac97_if.c channel_if.c feeder_if.c mixer_if.c mpu_if.c >> mpufoi_if.c synth_if.c uart_if.c usb_if.c g_part_if.c g_raid_md_if.c >> g_raid_tr_if.c isa_if.c bus_if.c clock_if.c cpufreq_if.c device_if.c >> linker_if.c serdev_if.c xenbus_if.c xenbusb_if.c acpi_if.c acpi_wmi_if.c >> virtio_bus_if.c virtio_if.c agp_if.h ata_if.h eisa_if.h fb_if.h miibus_if.h >> mmcbr_if.h mmcbus_if.h mvs_if.h card_if.h power_if.h pci_if.h pcib_if.h >> ppbus_if.h sdhci_if.h hdac_if.h ac97_if.h channel_if.h feeder_if.h mixer_if.h >> mpu_if.h mpufoi_if.h synth_if.h uart_if.h usb_if.h g_part_if.h g_raid_md_if.h >> g_raid_tr_if.h isa_if.h bus_if.h clock_if.h cpufreq_if.h device_if.h >> linker_if.h serdev_if.h xenbus_if.h xenbusb_if.h acpi_if.h acpi_wmi_if.h >> virtio_bus_if.h virtio_if.h acpi_quirks.h feeder_eq_gen.h feeder_rate_gen.h >> snd_fxdiv_gen.h miidevs.h pccarddevs.h teken_state.h usbdevs.h usbdevs_data.h >> ia32_genassym.o ia32_assym.h acpi_wakecode.o acpi_wakecode.bin >> acpi_wakecode.h acpi_wakedata.h >> --- modules-cleandir --- >> cd /usr/src/sys/modules; >> MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/MYFINEHOST/modules KMODDIR=/boot/kernel >> MACHINE_CPUARCH=amd64 DEBUG_FLAGS="-g" MACHINE=amd64 >> KERNBUILDDIR="/usr/obj/usr/src/sys/MYFINEHOST" SYSDIR="/usr/src/sys" >> WITH_CTF="1" make cleandir >> --- cleandir_subdir_aac --- >> --- cleandir_subdir_aacraid --- >> --- cleandir_subdir_accf_data --- >> --- cleandir_subdir_accf_dns --- >> --- cleandir_subdir_aac --- >> ===> aac (cleandir) >> --- cleandir_subdir_aacraid --- >> ===> aacraid (cleandir) >> --- cleandir_subdir_accf_data --- >> ===> accf_data (cleandir) >> --- cleandir_subdir_accf_dns --- >> ===> accf_dns (cleandir) >> --- cleandir_subdir_accf_data --- >> --- cleanobj --- >> --- cleandir_subdir_accf_dns --- >> --- cleanobj --- >> --- cleandir_subdir_aacraid --- >> --- cleanobj --- >> --- cleandir_subdir_aac --- >> --- cleanobj --- >> --- cleandir_subdir_accf_http --- >> --- cleandir_subdir_acl_nfs4 --- >> --- cleandir_subdir_accf_http --- >> ===> accf_http (cleandir) >> --- cleandir_subdir_acl_nfs4 --- >> ===> acl_nfs4 (cleandir) >> --- cleandir_subdir_acl_posix1e --- >> --- cleandir_subdir_acpi --- >> --- cleandir_subdir_acl_posix1e --- >> ===> acl_posix1e (cleandir) >> --- cleandir_subdir_acpi --- >> ===> acpi (cleandir) >> --- cleandir_subdir_accf_http --- >> --- cleanobj --- >> --- cleandir_subdir_acl_nfs4 --- >> --- cleanobj --- >> --- cleandir_subdir_acpi --- >> --- _sub.cleandir --- >> ===> acpi/acpi_asus (cleandir) >> --- cleandir_subdir_ae --- >> ===> ae (cleandir) >> --- cleandir_subdir_aesni --- >> ===> aesni (cleandir) >> --- cleandir_subdir_acl_posix1e --- >> --- cleanobj --- >> --- cleandir_subdir_acpi --- >> --- cleanobj --- >> --- cleandir_subdir_age --- >> ===> age (cleandir) >> --- cleandir_subdir_aesni --- >> --- cleanobj --- >> --- cleandir_subdir_ae --- >> --- cleanobj --- >> --- cleandir_subdir_acpi --- >> ===> acpi/acpi_asus_wmi (cleandir) >> --- cleandir_subdir_age --- >> --- cleanobj --- >> --- cleandir_subdir_acpi --- >> --- cleanobj --- >> --- cleandir_subdir_agp --- >> --- cleandir_subdir_aha --- >> --- cleandir_subdir_agp --- >> ===> agp (cleandir) >> --- cleandir_subdir_aha --- >> ===> aha (cleandir) >> --- cleanobj --- >> --- cleandir_subdir_ahci --- >> ===> ahci (cleandir) >> --- cleandir_subdir_aic7xxx --- >> ===> aic7xxx (cleandir) >> --- cleandir_subdir_ahci --- >> --- cleanobj --- >> --- cleandir_subdir_agp --- >> --- cleanobj --- >> --- cleandir_subdir_acpi --- >> ===> acpi/acpi_fujitsu (cleandir) >> --- cleandir_subdir_aic7xxx --- >> --- _sub.cleandir --- >> ===> aic7xxx/ahc (cleandir) >> --- cleandir_subdir_aio --- >> ===> aio (cleandir) >> --- cleandir_subdir_acpi --- >> --- cleanobj --- >> --- cleandir_subdir_aic7xxx --- >> --- cleanobj --- >> --- cleandir_subdir_alc --- >> ===> alc (cleandir) >> --- cleandir_subdir_aio --- >> --- cleanobj --- >> --- cleandir_subdir_acpi --- >> ===> acpi/acpi_hp (cleandir) >> --- cleandir_subdir_alc --- >> --- cleanobj --- >> --- cleandir_subdir_acpi --- >> --- cleanobj --- >> --- cleandir_subdir_aic7xxx --- >> --- _sub.cleandir --- >> ===> aic7xxx/ahc/ahc_eisa (cleandir) >> --- clean --- >> rm -f export_syms ahc_eisa.ko ahc_eisa.kld ahc_eisa.o ahc_eisa.ko.debug >> ahc_eisa.ko.symbols opt_scsi.h opt_cam.h opt_aic7xxx.h eisa_if.h pci_if.h >> bus_if.h device_if.h >> --- cleanilinks --- >> rm -f @ machine x86 >> --- cleandepend --- >> rm -f .depend GPATH GRTAGS GSYMS GTAGS >> --- cleanobj --- >> ===> aic7xxx/ahc/ahc_isa (cleandir) >> --- cleanobj --- >> ===> aic7xxx/ahc/ahc_pci (cleandir) >> --- cleandir_subdir_acpi --- >> ===> acpi/acpi_ibm (cleandir) >> --- cleandir_subdir_ale --- >> ===> ale (cleandir) >> --- cleandir_subdir_aic7xxx --- >> --- cleanobj --- >> --- cleandir_subdir_alq --- >> ===> alq (cleandir) >> --- cleandir_subdir_aic7xxx --- >> --- cleanobj --- >> rm: fts_read: No such file or directory >> *** [cleanobj] Error code 1 >> >> make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc >> 1 error >> >> make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc >> *** [_sub.cleandir] Error code 2 >> >> make[4]: stopped in /usr/src/sys/modules/aic7xxx >> 1 error >> >> make[4]: stopped in /usr/src/sys/modules/aic7xxx >> *** [cleandir_subdir_aic7xxx] Error code 2 >> >> make[3]: stopped in /usr/src/sys/modules >> --- cleandir_subdir_alq --- >> A failure has been detected in another branch of the parallel make >> >> make[4]: stopped in /usr/src/sys/modules/alq >> --- cleandir_subdir_ale --- >> A failure has been detected in another branch of the parallel make >> >> make[4]: stopped in /usr/src/sys/modules/ale >> --- cleandir_subdir_alq --- >> *** [cleandir_subdir_alq] Error code 2 >> >> make[3]: stopped in /usr/src/sys/modules >> --- cleandir_subdir_acpi --- >> --- cleanobj --- >> --- cleandir_subdir_ale --->>> Kernel build for OZZIE started on Thu Sep 18 >> 04:35:18 CDT 2014 >> -------------------------------------------------------------- >> ===> OZZIE >> mkdir -p /usr/obj/usr/src/sys >> -------------------------------------------------------------- >>>>> stage 1: configuring the kernel >> -------------------------------------------------------------- >> cd /usr/src/sys/amd64/conf; >> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin >> config -d /usr/obj/usr/src/sys/OZZIE -I '/usr/src/sys/amd64/conf' >> '/usr/src/sys/amd64/conf/OZZIE' >> Kernel build directory is /usr/obj/usr/src/sys/OZZIE >> Don't forget to do ``make cleandepend && make depend'' >> -------------------------------------------------------------- >>>>> stage 2.1: cleaning up the object tree >> -------------------------------------------------------------- >> cd /usr/obj/usr/src/sys/OZZIE; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 >> MACHINE=amd64 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin >> GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font >> GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac >> _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp _LDSCRIPTROOT= VERSION="FreeBSD >> 10.1-BETA1 amd64 1000716" INSTALL="sh /usr/src/tools/install.sh" >> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin >> CC="cc " CXX="c++ " CPP="cpp " AS="as" AR="ar" LD="ld" NM=nm OBJDUMP= >> RANLIB=ranlib STRINGS= COMPILER_TYPE=clang make -j 4 -J 15,16 -m >> /usr/src/share/mk KERNEL=kernel cleandir >> --- kernel-clean --- >> --- kernel-cleandepend --- >> --- modules-cleandir --- >> --- kernel-cleandepend --- >> rm -f .depend machine x86 >> --- kernel-clean --- >> rm -f *.o *.so *.So *.ko *.s eddep errs kernel.debug kernel kernel.symbols >> linterrs tags vers.c vnode_if.c vnode_if.h vnode_if_newproto.h >> vnode_if_typedef.h agp_if.c ata_if.c eisa_if.c fb_if.c miibus_if.c mmcbr_if.c >> mmcbus_if.c mvs_if.c card_if.c power_if.c pci_if.c pcib_if.c ppbus_if.c >> sdhci_if.c hdac_if.c ac97_if.c channel_if.c feeder_if.c mixer_if.c mpu_if.c >> mpufoi_if.c synth_if.c uart_if.c usb_if.c g_part_if.c g_raid_md_if.c >> g_raid_tr_if.c isa_if.c bus_if.c clock_if.c cpufreq_if.c device_if.c >> linker_if.c serdev_if.c xenbus_if.c xenbusb_if.c acpi_if.c acpi_wmi_if.c >> virtio_bus_if.c virtio_if.c agp_if.h ata_if.h eisa_if.h fb_if.h miibus_if.h >> mmcbr_if.h mmcbus_if.h mvs_if.h card_if.h power_if.h pci_if.h pcib_if.h >> ppbus_if.h sdhci_if.h hdac_if.h ac97_if.h channel_if.h feeder_if.h mixer_if.h >> mpu_if.h mpufoi_if.h synth_if.h uart_if.h usb_if.h g_part_if.h g_raid_md_if.h >> g_raid_tr_if.h isa_if.h bus_if.h clock_if.h cpufreq_if.h device_if.h >> linker_if.h serdev_if.h xenbus_if.h xenbusb_if.h acpi_if.h acpi_wmi_if.h >> virtio_bus_if.h virtio_if.h acpi_quirks.h feeder_eq_gen.h feeder_rate_gen.h >> snd_fxdiv_gen.h miidevs.h pccarddevs.h teken_state.h usbdevs.h usbdevs_data.h >> ia32_genassym.o ia32_assym.h acpi_wakecode.o acpi_wakecode.bin >> acpi_wakecode.h acpi_wakedata.h >> --- modules-cleandir --- >> cd /usr/src/sys/modules; MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/OZZIE/modules >> KMODDIR=/boot/kernel MACHINE_CPUARCH=amd64 DEBUG_FLAGS="-g" MACHINE=amd64 >> KERNBUILDDIR="/usr/obj/usr/src/sys/OZZIE" SYSDIR="/usr/src/sys" WITH_CTF="1" >> make cleandir >> --- cleandir_subdir_aac --- >> --- cleandir_subdir_aacraid --- >> --- cleandir_subdir_accf_data --- >> --- cleandir_subdir_accf_dns --- >> --- cleandir_subdir_aac --- >> ===> aac (cleandir) >> --- cleandir_subdir_aacraid --- >> ===> aacraid (cleandir) >> --- cleandir_subdir_accf_data --- >> ===> accf_data (cleandir) >> --- cleandir_subdir_accf_dns --- >> ===> accf_dns (cleandir) >> --- cleandir_subdir_accf_data --- >> --- cleanobj --- >> --- cleandir_subdir_accf_dns --- >> --- cleanobj --- >> --- cleandir_subdir_aacraid --- >> --- cleanobj --- >> --- cleandir_subdir_aac --- >> --- cleanobj --- >> --- cleandir_subdir_accf_http --- >> --- cleandir_subdir_acl_nfs4 --- >> --- cleandir_subdir_accf_http --- >> ===> accf_http (cleandir) >> --- cleandir_subdir_acl_nfs4 --- >> ===> acl_nfs4 (cleandir) >> --- cleandir_subdir_acl_posix1e --- >> --- cleandir_subdir_acpi --- >> --- cleandir_subdir_acl_posix1e --- >> ===> acl_posix1e (cleandir) >> --- cleandir_subdir_acpi --- >> ===> acpi (cleandir) >> --- cleandir_subdir_accf_http --- >> --- cleanobj --- >> --- cleandir_subdir_acl_nfs4 --- >> --- cleanobj --- >> --- cleandir_subdir_acpi --- >> --- _sub.cleandir --- >> ===> acpi/acpi_asus (cleandir) >> --- cleandir_subdir_ae --- >> ===> ae (cleandir) >> --- cleandir_subdir_aesni --- >> ===> aesni (cleandir) >> --- cleandir_subdir_acl_posix1e --- >> --- cleanobj --- >> --- cleandir_subdir_acpi --- >> --- cleanobj --- >> --- cleandir_subdir_age --- >> ===> age (cleandir) >> --- cleandir_subdir_aesni --- >> --- cleanobj --- >> --- cleandir_subdir_ae --- >> --- cleanobj --- >> --- cleandir_subdir_acpi --- >> ===> acpi/acpi_asus_wmi (cleandir) >> --- cleandir_subdir_age --- >> --- cleanobj --- >> --- cleandir_subdir_acpi --- >> --- cleanobj --- >> --- cleandir_subdir_agp --- >> --- cleandir_subdir_aha --- >> --- cleandir_subdir_agp --- >> ===> agp (cleandir) >> --- cleandir_subdir_aha --- >> ===> aha (cleandir) >> --- cleanobj --- >> --- cleandir_subdir_ahci --- >> ===> ahci (cleandir) >> --- cleandir_subdir_aic7xxx --- >> ===> aic7xxx (cleandir) >> --- cleandir_subdir_ahci --- >> --- cleanobj --- >> --- cleandir_subdir_agp --- >> --- cleanobj --- >> --- cleandir_subdir_acpi --- >> ===> acpi/acpi_fujitsu (cleandir) >> --- cleandir_subdir_aic7xxx --- >> --- _sub.cleandir --- >> ===> aic7xxx/ahc (cleandir) >> --- cleandir_subdir_aio --- >> ===> aio (cleandir) >> --- cleandir_subdir_acpi --- >> --- cleanobj --- >> --- cleandir_subdir_aic7xxx --- >> --- cleanobj --- >> --- cleandir_subdir_alc --- >> ===> alc (cleandir) >> --- cleandir_subdir_aio --- >> --- cleanobj --- >> --- cleandir_subdir_acpi --- >> ===> acpi/acpi_hp (cleandir) >> --- cleandir_subdir_alc --- >> --- cleanobj --- >> --- cleandir_subdir_acpi --- >> --- cleanobj --- >> --- cleandir_subdir_aic7xxx --- >> --- _sub.cleandir --- >> ===> aic7xxx/ahc/ahc_eisa (cleandir) >> --- clean --- >> rm -f export_syms ahc_eisa.ko ahc_eisa.kld ahc_eisa.o ahc_eisa.ko.debug >> ahc_eisa.ko.symbols opt_scsi.h opt_cam.h opt_aic7xxx.h eisa_if.h pci_if.h >> bus_if.h device_if.h >> --- cleanilinks --- >> rm -f @ machine x86 >> --- cleandepend --- >> rm -f .depend GPATH GRTAGS GSYMS GTAGS >> --- cleanobj --- >> ===> aic7xxx/ahc/ahc_isa (cleandir) >> --- cleanobj --- >> ===> aic7xxx/ahc/ahc_pci (cleandir) >> --- cleandir_subdir_acpi --- >> ===> acpi/acpi_ibm (cleandir) >> --- cleandir_subdir_ale --- >> ===> ale (cleandir) >> --- cleandir_subdir_aic7xxx --- >> --- cleanobj --- >> --- cleandir_subdir_alq --- >> ===> alq (cleandir) >> --- cleandir_subdir_aic7xxx --- >> --- cleanobj --- >> rm: fts_read: No such file or directory >> *** [cleanobj] Error code 1 >> >> make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc >> 1 error >> >> make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc >> *** [_sub.cleandir] Error code 2 >> >> make[4]: stopped in /usr/src/sys/modules/aic7xxx >> 1 error >> >> make[4]: stopped in /usr/src/sys/modules/aic7xxx >> *** [cleandir_subdir_aic7xxx] Error code 2 >> >> make[3]: stopped in /usr/src/sys/modules >> --- cleandir_subdir_alq --- >> A failure has been detected in another branch of the parallel make >> >> make[4]: stopped in /usr/src/sys/modules/alq >> --- cleandir_subdir_ale --- >> A failure has been detected in another branch of the parallel make >> >> make[4]: stopped in /usr/src/sys/modules/ale >> --- cleandir_subdir_alq --- >> *** [cleandir_subdir_alq] Error code 2 >> >> make[3]: stopped in /usr/src/sys/modules >> --- cleandir_subdir_acpi --- >> --- cleanobj --- >> --- cleandir_subdir_ale --- >> *** [cleandir_subdir_ale] Error code 2 >> >> make[3]: stopped in /usr/src/sys/modules >> --- cleandir_subdir_acpi --- >> A failure has been detected in another branch of the parallel make >>>>> Kernel build for OZZIE started on Thu Sep 18 04:35:18 CDT 2014 >> -------------------------------------------------------------- >> ===> OZZIE >> mkdir -p /usr/obj/usr/src/sys >> -------------------------------------------------------------- >>>>> stage 1: configuring the kernel >> -------------------------------------------------------------- >> cd /usr/src/sys/amd64/conf; >> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin >> config -d /usr/obj/usr/src/sys/OZZIE -I '/usr/src/sys/amd64/conf' >> '/usr/src/sys/amd64/conf/OZZIE' >> Kernel build directory is /usr/obj/usr/src/sys/OZZIE >> Don't forget to do ``make cleandepend && make depend'' >> -------------------------------------------------------------- >>>>> stage 2.1: cleaning up the object tree >> -------------------------------------------------------------- >> cd /usr/obj/usr/src/sys/OZZIE; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 >> MACHINE=amd64 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin >> GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font >> GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac >> _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp _LDSCRIPTROOT= VERSION="FreeBSD >> 10.1-BETA1 amd64 1000716" INSTALL="sh /usr/src/tools/install.sh" >> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin >> CC="cc " CXX="c++ " CPP="cpp " AS="as" AR="ar" LD="ld" NM=nm OBJDUMP= >> RANLIB=ranlib STRINGS= COMPILER_TYPE=clang make -j 4 -J 15,16 -m >> /usr/src/share/mk KERNEL=kernel cleandir >> --- kernel-clean --- >> --- kernel-cleandepend --- >> --- modules-cleandir --- >> --- kernel-cleandepend --- >> rm -f .depend machine x86 >> --- kernel-clean --- >> rm -f *.o *.so *.So *.ko *.s eddep errs kernel.debug kernel kernel.symbols >> linterrs tags vers.c vnode_if.c vnode_if.h vnode_if_newproto.h >> vnode_if_typedef.h agp_if.c ata_if.c eisa_if.c fb_if.c miibus_if.c mmcbr_if.c >> mmcbus_if.c mvs_if.c card_if.c power_if.c pci_if.c pcib_if.c ppbus_if.c >> sdhci_if.c hdac_if.c ac97_if.c channel_if.c feeder_if.c mixer_if.c mpu_if.c >> mpufoi_if.c synth_if.c uart_if.c usb_if.c g_part_if.c g_raid_md_if.c >> g_raid_tr_if.c isa_if.c bus_if.c clock_if.c cpufreq_if.c device_if.c >> linker_if.c serdev_if.c xenbus_if.c xenbusb_if.c acpi_if.c acpi_wmi_if.c >> virtio_bus_if.c virtio_if.c agp_if.h ata_if.h eisa_if.h fb_if.h miibus_if.h >> mmcbr_if.h mmcbus_if.h mvs_if.h card_if.h power_if.h pci_if.h pcib_if.h >> ppbus_if.h sdhci_if.h hdac_if.h ac97_if.h channel_if.h feeder_if.h mixer_if.h >> mpu_if.h mpufoi_if.h synth_if.h uart_if.h usb_if.h g_part_if.h g_raid_md_if.h >> g_raid_tr_if.h isa_if.h bus_if.h clock_if.h cpufreq_if.h device_if.h >> linker_if.h serdev_if.h xenbus_if.h xenbusb_if.h acpi_if.h acpi_wmi_if.h >> virtio_bus_if.h virtio_if.h acpi_quirks.h feeder_eq_gen.h feeder_rate_gen.h >> snd_fxdiv_gen.h miidevs.h pccarddevs.h teken_state.h usbdevs.h usbdevs_data.h >> ia32_genassym.o ia32_assym.h acpi_wakecode.o acpi_wakecode.bin >> acpi_wakecode.h acpi_wakedata.h >> --- modules-cleandir --- >> cd /usr/src/sys/modules; MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/OZZIE/modules >> KMODDIR=/boot/kernel MACHINE_CPUARCH=amd64 DEBUG_FLAGS="-g" MACHINE=amd64 >> KERNBUILDDIR="/usr/obj/usr/src/sys/OZZIE" SYSDIR="/usr/src/sys" WITH_CTF="1" >> make cleandir >> --- cleandir_subdir_aac --- >> --- cleandir_subdir_aacraid --- >> --- cleandir_subdir_accf_data --- >> --- cleandir_subdir_accf_dns --- >> --- cleandir_subdir_aac --- >> ===> aac (cleandir) >> --- cleandir_subdir_aacraid --- >> ===> aacraid (cleandir) >> --- cleandir_subdir_accf_data --- >> ===> accf_data (cleandir) >> --- cleandir_subdir_accf_dns --- >> ===> accf_dns (cleandir) >> --- cleandir_subdir_accf_data --- >> --- cleanobj --- >> --- cleandir_subdir_accf_dns --- >> --- cleanobj --- >> --- cleandir_subdir_aacraid --- >> --- cleanobj --- >> --- cleandir_subdir_aac --- >> --- cleanobj --- >> --- cleandir_subdir_accf_http --- >> --- cleandir_subdir_acl_nfs4 --- >> --- cleandir_subdir_accf_http --- >> ===> accf_http (cleandir) >> --- cleandir_subdir_acl_nfs4 --- >> ===> acl_nfs4 (cleandir) >> --- cleandir_subdir_acl_posix1e --- >> --- cleandir_subdir_acpi --- >> --- cleandir_subdir_acl_posix1e --- >> ===> acl_posix1e (cleandir) >> --- cleandir_subdir_acpi --- >> ===> acpi (cleandir) >> --- cleandir_subdir_accf_http --- >> --- cleanobj --- >> --- cleandir_subdir_acl_nfs4 --- >> --- cleanobj --- >> --- cleandir_subdir_acpi --- >> --- _sub.cleandir --- >> ===> acpi/acpi_asus (cleandir) >> --- cleandir_subdir_ae --- >> ===> ae (cleandir) >> --- cleandir_subdir_aesni --- >> ===> aesni (cleandir) >> --- cleandir_subdir_acl_posix1e --- >> --- cleanobj --- >> --- cleandir_subdir_acpi --- >> --- cleanobj --- >> --- cleandir_subdir_age --- >> ===> age (cleandir) >> --- cleandir_subdir_aesni --- >> --- cleanobj --- >> --- cleandir_subdir_ae --- >> --- cleanobj --- >> --- cleandir_subdir_acpi --- >> ===> acpi/acpi_asus_wmi (cleandir) >> --- cleandir_subdir_age --- >> --- cleanobj --- >> --- cleandir_subdir_acpi --- >> --- cleanobj --- >> --- cleandir_subdir_agp --- >> --- cleandir_subdir_aha --- >> --- cleandir_subdir_agp --- >> ===> agp (cleandir) >> --- cleandir_subdir_aha --- >> ===> aha (cleandir) >> --- cleanobj --- >> --- cleandir_subdir_ahci --- >> ===> ahci (cleandir) >> --- cleandir_subdir_aic7xxx --- >> ===> aic7xxx (cleandir) >> --- cleandir_subdir_ahci --- >> --- cleanobj --- >> --- cleandir_subdir_agp --- >> --- cleanobj --- >> --- cleandir_subdir_acpi --- >> ===> acpi/acpi_fujitsu (cleandir) >> --- cleandir_subdir_aic7xxx --- >> --- _sub.cleandir --- >> ===> aic7xxx/ahc (cleandir) >> --- cleandir_subdir_aio --- >> ===> aio (cleandir) >> --- cleandir_subdir_acpi --- >> --- cleanobj --- >> --- cleandir_subdir_aic7xxx --- >> --- cleanobj --- >> --- cleandir_subdir_alc --- >> ===> alc (cleandir) >> --- cleandir_subdir_aio --- >> --- cleanobj --- >> --- cleandir_subdir_acpi --- >> ===> acpi/acpi_hp (cleandir) >> --- cleandir_subdir_alc --- >> --- cleanobj --- >> --- cleandir_subdir_acpi --- >> --- cleanobj --- >> --- cleandir_subdir_aic7xxx --- >> --- _sub.cleandir --- >> ===> aic7xxx/ahc/ahc_eisa (cleandir) >> --- clean --- >> rm -f export_syms ahc_eisa.ko ahc_eisa.kld ahc_eisa.o ahc_eisa.ko.debug >> ahc_eisa.ko.symbols opt_scsi.h opt_cam.h opt_aic7xxx.h eisa_if.h pci_if.h >> bus_if.h device_if.h >> --- cleanilinks --- >> rm -f @ machine x86 >> --- cleandepend --- >> rm -f .depend GPATH GRTAGS GSYMS GTAGS >> --- cleanobj --- >> ===> aic7xxx/ahc/ahc_isa (cleandir) >> --- cleanobj --- >> ===> aic7xxx/ahc/ahc_pci (cleandir) >> --- cleandir_subdir_acpi --- >> ===> acpi/acpi_ibm (cleandir) >> --- cleandir_subdir_ale --- >> ===> ale (cleandir) >> --- cleandir_subdir_aic7xxx --- >> --- cleanobj --- >> --- cleandir_subdir_alq --- >> ===> alq (cleandir) >> --- cleandir_subdir_aic7xxx --- >> --- cleanobj --- >> rm: fts_read: No such file or directory >> *** [cleanobj] Error code 1 >> >> make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc >> 1 error >> >> make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc >> *** [_sub.cleandir] Error code 2 >> >> make[4]: stopped in /usr/src/sys/modules/aic7xxx >> 1 error >> >> make[4]: stopped in /usr/src/sys/modules/aic7xxx >> *** [cleandir_subdir_aic7xxx] Error code 2 >> >> make[3]: stopped in /usr/src/sys/modules >> --- cleandir_subdir_alq --- >> A failure has been detected in another branch of the parallel make >> >> make[4]: stopped in /usr/src/sys/modules/alq >> --- cleandir_subdir_ale --- >> A failure has been detected in another branch of the parallel make >> >> make[4]: stopped in /usr/src/sys/modules/ale >> --- cleandir_subdir_alq --- >> *** [cleandir_subdir_alq] Error code 2 >> >> make[3]: stopped in /usr/src/sys/modules >> --- cleandir_subdir_acpi --- >> --- cleanobj --- >> --- cleandir_subdir_ale --- >> *** [cleandir_subdir_ale] Error code 2 >> >> make[3]: stopped in /usr/src/sys/modules >> --- cleandir_subdir_acpi --- >> A failure has been detected in another branch of the parallel make >> >> make[5]: stopped in /usr/src/sys/modules/acpi/acpi_ibm >> *** [_sub.cleandir] Error code 2 >> >> make[4]: stopped in /usr/src/sys/modules/acpi >> 1 error >> >> make[4]: stopped in /usr/src/sys/modules/acpi >> *** [cleandir_subdir_acpi] Error code 2 >> >> make[3]: stopped in /usr/src/sys/modules >> 4 errors >> >> make[3]: stopped in /usr/src/sys/modules >> *** [modules-cleandir] Error code 2 >> >> make[2]: stopped in /usr/obj/usr/src/sys/OZZIE >> 1 error >> >> make[2]: stopped in /usr/obj/usr/src/sys/OZZIE >> *** [buildkernel] Error code 2 >> >> make[1]: stopped in /usr/src >> 1 error >> >> make[1]: stopped in /usr/src >> *** [buildkernel] Error code 2 >> >> make: stopped in /usr/src >> 1 error >> >> make: stopped in /usr/src >> >> make[5]: stopped in /usr/src/sys/modules/acpi/acpi_ibm >> *** [_sub.cleandir] Error code 2 >> >> make[4]: stopped in /usr/src/sys/modules/acpi >> 1 error >> >> make[4]: stopped in /usr/src/sys/modules/acpi >> *** [cleandir_subdir_acpi] Error code 2 >> >> make[3]: stopped in /usr/src/sys/modules >> 4 errors >> >> make[3]: stopped in /usr/src/sys/modules >> *** [modules-cleandir] Error code 2 >> >> make[2]: stopped in /usr/obj/usr/src/sys/OZZIE >> 1 error >> >> make[2]: stopped in /usr/obj/usr/src/sys/OZZIE >> *** [buildkernel] Error code 2 >> >> make[1]: stopped in /usr/src >> 1 error >> >> make[1]: stopped in /usr/src >> *** [buildkernel] Error code 2 >> >> make: stopped in /usr/src >> 1 error >> >> make: stopped in /usr/src >> >> *** [cleandir_subdir_ale] Error code 2 >> >> make[3]: stopped in /usr/src/sys/modules >> --- cleandir_subdir_acpi --- >> A failure has been detected in another branch of the parallel make >> >> make[5]: stopped in /usr/src/sys/modules/acpi/acpi_ibm >> *** [_sub.cleandir] Error code 2 >> >> make[4]: stopped in /usr/src/sys/modules/acpi >> 1 error >> >> make[4]: stopped in /usr/src/sys/modules/acpi >> *** [cleandir_subdir_acpi] Error code 2 >> >> make[3]: stopped in /usr/src/sys/modules >> 4 errors >> >> make[3]: stopped in /usr/src/sys/modules >> *** [modules-cleandir] Error code 2 >> >> make[2]: stopped in /usr/obj/usr/src/sys/MYFINEHOST >> 1 error >> >> make[2]: stopped in /usr/obj/usr/src/sys/MYFINEHOST >> *** [buildkernel] Error code 2 >> >> make[1]: stopped in /usr/src >> 1 error >> >> make[1]: stopped in /usr/src >> *** [buildkernel] Error code 2 >> >> make: stopped in /usr/src >> 1 error >> >> make: stopped in /usr/src >> >> -- >> ---------------------------------------------------------------------------- >> Tim Daneliuk tundra@tundraware.com >> PGP Key: http://www.tundraware.com/PGP/ >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/ From owner-freebsd-stable@FreeBSD.ORG Thu Sep 18 23:37:07 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C8987D3 for ; Thu, 18 Sep 2014 23:37:07 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 9D6E06E9 for ; Thu, 18 Sep 2014 23:37:06 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 3DA0F20E7088E; Thu, 18 Sep 2014 23:37:05 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: * X-Spam-Status: No, score=2.0 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,RDNS_DYNAMIC autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id E971220E7088A; Thu, 18 Sep 2014 23:37:01 +0000 (UTC) Message-ID: <62E5543C34E048D5B454CD795ACAC495@multiplay.co.uk> From: "Steven Hartland" To: "Tim Daneliuk" , "FreeBSD Stable" References: <541B6167.3000703@tundraware.com> <541B6A6F.5010501@tundraware.com> Subject: Re: 10.1Beta - Ongoing Build Problems Date: Fri, 19 Sep 2014 00:36:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 23:37:07 -0000 I just noticed your error was rm: fts_read: No such file or directory This is a know issue with rewinddir. I believe the fix is: http://svnweb.freebsd.org/changeset/base/271048 Which was MFC'ed by: http://svnweb.freebsd.org/changeset/base/271263 So your build machine will need to be running r271263 or later. Regards Steve ----- Original Message ----- From: "Tim Daneliuk" To: "Steven Hartland" ; "FreeBSD Stable" Sent: Friday, September 19, 2014 12:27 AM Subject: Re: 10.1Beta - Ongoing Build Problems > On 09/18/2014 06:06 PM, Steven Hartland wrote: >> IIRC this can happen if your building on a box which is too old. >> >> I've been doing loads of stable/10 builds recently with -j24 and >> only had an issue a while back, updating the world on the box >> in question (using no -j) fixed it for me. >> >> Regards >> Steve > > The hardware is pretty new and the OS was updated within the last several > weeks to the then -STABLE branch. I've been seeing this on- and off > for a while. > > > >> >> ----- Original Message ----- From: "Tim Daneliuk" >> To: "FreeBSD Stable" >> Sent: Thursday, September 18, 2014 11:49 PM >> Subject: 10.1Beta - Ongoing Build Problems >> >> >>> I continue to see problems as seen below if I attempt a parallel make. >>> If I remove the '-j4' from my build script, this build completes fine, >>> albeit much more slowly. Ideas anyone??: >>> >>> >>>>>> Kernel build for MYFINEHOST started on Thu Sep 18 04:35:18 CDT 2014 >>> -------------------------------------------------------------- >>> ===> MYFINEHOST >>> mkdir -p /usr/obj/usr/src/sys >>> -------------------------------------------------------------- >>>>>> stage 1: configuring the kernel >>> -------------------------------------------------------------- >>> cd /usr/src/sys/amd64/conf; >>> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin >>> config -d /usr/obj/usr/src/sys/MYFINEHOST -I '/usr/src/sys/amd64/conf' >>> '/usr/src/sys/amd64/conf/MYFINEHOST' >>> Kernel build directory is /usr/obj/usr/src/sys/MYFINEHOST >>> Don't forget to do ``make cleandepend && make depend'' >>> -------------------------------------------------------------- >>>>>> stage 2.1: cleaning up the object tree >>> -------------------------------------------------------------- >>> cd /usr/obj/usr/src/sys/MYFINEHOST; MAKEOBJDIRPREFIX=/usr/obj >>> MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= >>> GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin >>> GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font >>> GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac >>> _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp _LDSCRIPTROOT= VERSION="FreeBSD >>> 10.1-BETA1 amd64 1000716" INSTALL="sh /usr/src/tools/install.sh" >>> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin >>> CC="cc " CXX="c++ " CPP="cpp " AS="as" AR="ar" LD="ld" NM=nm OBJDUMP= >>> RANLIB=ranlib STRINGS= COMPILER_TYPE=clang make -j 4 -J 15,16 -m >>> /usr/src/share/mk KERNEL=kernel cleandir >>> --- kernel-clean --- >>> --- kernel-cleandepend --- >>> --- modules-cleandir --- >>> --- kernel-cleandepend --- >>> rm -f .depend machine x86 >>> --- kernel-clean --- >>> rm -f *.o *.so *.So *.ko *.s eddep errs kernel.debug kernel kernel.symbols >>> linterrs tags vers.c vnode_if.c vnode_if.h vnode_if_newproto.h >>> vnode_if_typedef.h agp_if.c ata_if.c eisa_if.c fb_if.c miibus_if.c mmcbr_if.c >>> mmcbus_if.c mvs_if.c card_if.c power_if.c pci_if.c pcib_if.c ppbus_if.c >>> sdhci_if.c hdac_if.c ac97_if.c channel_if.c feeder_if.c mixer_if.c mpu_if.c >>> mpufoi_if.c synth_if.c uart_if.c usb_if.c g_part_if.c g_raid_md_if.c >>> g_raid_tr_if.c isa_if.c bus_if.c clock_if.c cpufreq_if.c device_if.c >>> linker_if.c serdev_if.c xenbus_if.c xenbusb_if.c acpi_if.c acpi_wmi_if.c >>> virtio_bus_if.c virtio_if.c agp_if.h ata_if.h eisa_if.h fb_if.h miibus_if.h >>> mmcbr_if.h mmcbus_if.h mvs_if.h card_if.h power_if.h pci_if.h pcib_if.h >>> ppbus_if.h sdhci_if.h hdac_if.h ac97_if.h channel_if.h feeder_if.h mixer_if.h >>> mpu_if.h mpufoi_if.h synth_if.h uart_if.h usb_if.h g_part_if.h g_raid_md_if.h >>> g_raid_tr_if.h isa_if.h bus_if.h clock_if.h cpufreq_if.h device_if.h >>> linker_if.h serdev_if.h xenbus_if.h xenbusb_if.h acpi_if.h acpi_wmi_if.h >>> virtio_bus_if.h virtio_if.h acpi_quirks.h feeder_eq_gen.h feeder_rate_gen.h >>> snd_fxdiv_gen.h miidevs.h pccarddevs.h teken_state.h usbdevs.h usbdevs_data.h >>> ia32_genassym.o ia32_assym.h acpi_wakecode.o acpi_wakecode.bin >>> acpi_wakecode.h acpi_wakedata.h >>> --- modules-cleandir --- >>> cd /usr/src/sys/modules; >>> MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/MYFINEHOST/modules KMODDIR=/boot/kernel >>> MACHINE_CPUARCH=amd64 DEBUG_FLAGS="-g" MACHINE=amd64 >>> KERNBUILDDIR="/usr/obj/usr/src/sys/MYFINEHOST" SYSDIR="/usr/src/sys" >>> WITH_CTF="1" make cleandir >>> --- cleandir_subdir_aac --- >>> --- cleandir_subdir_aacraid --- >>> --- cleandir_subdir_accf_data --- >>> --- cleandir_subdir_accf_dns --- >>> --- cleandir_subdir_aac --- >>> ===> aac (cleandir) >>> --- cleandir_subdir_aacraid --- >>> ===> aacraid (cleandir) >>> --- cleandir_subdir_accf_data --- >>> ===> accf_data (cleandir) >>> --- cleandir_subdir_accf_dns --- >>> ===> accf_dns (cleandir) >>> --- cleandir_subdir_accf_data --- >>> --- cleanobj --- >>> --- cleandir_subdir_accf_dns --- >>> --- cleanobj --- >>> --- cleandir_subdir_aacraid --- >>> --- cleanobj --- >>> --- cleandir_subdir_aac --- >>> --- cleanobj --- >>> --- cleandir_subdir_accf_http --- >>> --- cleandir_subdir_acl_nfs4 --- >>> --- cleandir_subdir_accf_http --- >>> ===> accf_http (cleandir) >>> --- cleandir_subdir_acl_nfs4 --- >>> ===> acl_nfs4 (cleandir) >>> --- cleandir_subdir_acl_posix1e --- >>> --- cleandir_subdir_acpi --- >>> --- cleandir_subdir_acl_posix1e --- >>> ===> acl_posix1e (cleandir) >>> --- cleandir_subdir_acpi --- >>> ===> acpi (cleandir) >>> --- cleandir_subdir_accf_http --- >>> --- cleanobj --- >>> --- cleandir_subdir_acl_nfs4 --- >>> --- cleanobj --- >>> --- cleandir_subdir_acpi --- >>> --- _sub.cleandir --- >>> ===> acpi/acpi_asus (cleandir) >>> --- cleandir_subdir_ae --- >>> ===> ae (cleandir) >>> --- cleandir_subdir_aesni --- >>> ===> aesni (cleandir) >>> --- cleandir_subdir_acl_posix1e --- >>> --- cleanobj --- >>> --- cleandir_subdir_acpi --- >>> --- cleanobj --- >>> --- cleandir_subdir_age --- >>> ===> age (cleandir) >>> --- cleandir_subdir_aesni --- >>> --- cleanobj --- >>> --- cleandir_subdir_ae --- >>> --- cleanobj --- >>> --- cleandir_subdir_acpi --- >>> ===> acpi/acpi_asus_wmi (cleandir) >>> --- cleandir_subdir_age --- >>> --- cleanobj --- >>> --- cleandir_subdir_acpi --- >>> --- cleanobj --- >>> --- cleandir_subdir_agp --- >>> --- cleandir_subdir_aha --- >>> --- cleandir_subdir_agp --- >>> ===> agp (cleandir) >>> --- cleandir_subdir_aha --- >>> ===> aha (cleandir) >>> --- cleanobj --- >>> --- cleandir_subdir_ahci --- >>> ===> ahci (cleandir) >>> --- cleandir_subdir_aic7xxx --- >>> ===> aic7xxx (cleandir) >>> --- cleandir_subdir_ahci --- >>> --- cleanobj --- >>> --- cleandir_subdir_agp --- >>> --- cleanobj --- >>> --- cleandir_subdir_acpi --- >>> ===> acpi/acpi_fujitsu (cleandir) >>> --- cleandir_subdir_aic7xxx --- >>> --- _sub.cleandir --- >>> ===> aic7xxx/ahc (cleandir) >>> --- cleandir_subdir_aio --- >>> ===> aio (cleandir) >>> --- cleandir_subdir_acpi --- >>> --- cleanobj --- >>> --- cleandir_subdir_aic7xxx --- >>> --- cleanobj --- >>> --- cleandir_subdir_alc --- >>> ===> alc (cleandir) >>> --- cleandir_subdir_aio --- >>> --- cleanobj --- >>> --- cleandir_subdir_acpi --- >>> ===> acpi/acpi_hp (cleandir) >>> --- cleandir_subdir_alc --- >>> --- cleanobj --- >>> --- cleandir_subdir_acpi --- >>> --- cleanobj --- >>> --- cleandir_subdir_aic7xxx --- >>> --- _sub.cleandir --- >>> ===> aic7xxx/ahc/ahc_eisa (cleandir) >>> --- clean --- >>> rm -f export_syms ahc_eisa.ko ahc_eisa.kld ahc_eisa.o ahc_eisa.ko.debug >>> ahc_eisa.ko.symbols opt_scsi.h opt_cam.h opt_aic7xxx.h eisa_if.h pci_if.h >>> bus_if.h device_if.h >>> --- cleanilinks --- >>> rm -f @ machine x86 >>> --- cleandepend --- >>> rm -f .depend GPATH GRTAGS GSYMS GTAGS >>> --- cleanobj --- >>> ===> aic7xxx/ahc/ahc_isa (cleandir) >>> --- cleanobj --- >>> ===> aic7xxx/ahc/ahc_pci (cleandir) >>> --- cleandir_subdir_acpi --- >>> ===> acpi/acpi_ibm (cleandir) >>> --- cleandir_subdir_ale --- >>> ===> ale (cleandir) >>> --- cleandir_subdir_aic7xxx --- >>> --- cleanobj --- >>> --- cleandir_subdir_alq --- >>> ===> alq (cleandir) >>> --- cleandir_subdir_aic7xxx --- >>> --- cleanobj --- >>> rm: fts_read: No such file or directory >>> *** [cleanobj] Error code 1 >>> >>> make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc >>> 1 error >>> >>> make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc >>> *** [_sub.cleandir] Error code 2 >>> >>> make[4]: stopped in /usr/src/sys/modules/aic7xxx >>> 1 error >>> >>> make[4]: stopped in /usr/src/sys/modules/aic7xxx >>> *** [cleandir_subdir_aic7xxx] Error code 2 >>> >>> make[3]: stopped in /usr/src/sys/modules >>> --- cleandir_subdir_alq --- >>> A failure has been detected in another branch of the parallel make >>> >>> make[4]: stopped in /usr/src/sys/modules/alq >>> --- cleandir_subdir_ale --- >>> A failure has been detected in another branch of the parallel make >>> >>> make[4]: stopped in /usr/src/sys/modules/ale >>> --- cleandir_subdir_alq --- >>> *** [cleandir_subdir_alq] Error code 2 >>> >>> make[3]: stopped in /usr/src/sys/modules >>> --- cleandir_subdir_acpi --- >>> --- cleanobj --- >>> --- cleandir_subdir_ale --->>> Kernel build for OZZIE started on Thu Sep 18 >>> 04:35:18 CDT 2014 >>> -------------------------------------------------------------- >>> ===> OZZIE >>> mkdir -p /usr/obj/usr/src/sys >>> -------------------------------------------------------------- >>>>>> stage 1: configuring the kernel >>> -------------------------------------------------------------- >>> cd /usr/src/sys/amd64/conf; >>> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin >>> config -d /usr/obj/usr/src/sys/OZZIE -I '/usr/src/sys/amd64/conf' >>> '/usr/src/sys/amd64/conf/OZZIE' >>> Kernel build directory is /usr/obj/usr/src/sys/OZZIE >>> Don't forget to do ``make cleandepend && make depend'' >>> -------------------------------------------------------------- >>>>>> stage 2.1: cleaning up the object tree >>> -------------------------------------------------------------- >>> cd /usr/obj/usr/src/sys/OZZIE; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 >>> MACHINE=amd64 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin >>> GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font >>> GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac >>> _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp _LDSCRIPTROOT= VERSION="FreeBSD >>> 10.1-BETA1 amd64 1000716" INSTALL="sh /usr/src/tools/install.sh" >>> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin >>> CC="cc " CXX="c++ " CPP="cpp " AS="as" AR="ar" LD="ld" NM=nm OBJDUMP= >>> RANLIB=ranlib STRINGS= COMPILER_TYPE=clang make -j 4 -J 15,16 -m >>> /usr/src/share/mk KERNEL=kernel cleandir >>> --- kernel-clean --- >>> --- kernel-cleandepend --- >>> --- modules-cleandir --- >>> --- kernel-cleandepend --- >>> rm -f .depend machine x86 >>> --- kernel-clean --- >>> rm -f *.o *.so *.So *.ko *.s eddep errs kernel.debug kernel kernel.symbols >>> linterrs tags vers.c vnode_if.c vnode_if.h vnode_if_newproto.h >>> vnode_if_typedef.h agp_if.c ata_if.c eisa_if.c fb_if.c miibus_if.c mmcbr_if.c >>> mmcbus_if.c mvs_if.c card_if.c power_if.c pci_if.c pcib_if.c ppbus_if.c >>> sdhci_if.c hdac_if.c ac97_if.c channel_if.c feeder_if.c mixer_if.c mpu_if.c >>> mpufoi_if.c synth_if.c uart_if.c usb_if.c g_part_if.c g_raid_md_if.c >>> g_raid_tr_if.c isa_if.c bus_if.c clock_if.c cpufreq_if.c device_if.c >>> linker_if.c serdev_if.c xenbus_if.c xenbusb_if.c acpi_if.c acpi_wmi_if.c >>> virtio_bus_if.c virtio_if.c agp_if.h ata_if.h eisa_if.h fb_if.h miibus_if.h >>> mmcbr_if.h mmcbus_if.h mvs_if.h card_if.h power_if.h pci_if.h pcib_if.h >>> ppbus_if.h sdhci_if.h hdac_if.h ac97_if.h channel_if.h feeder_if.h mixer_if.h >>> mpu_if.h mpufoi_if.h synth_if.h uart_if.h usb_if.h g_part_if.h g_raid_md_if.h >>> g_raid_tr_if.h isa_if.h bus_if.h clock_if.h cpufreq_if.h device_if.h >>> linker_if.h serdev_if.h xenbus_if.h xenbusb_if.h acpi_if.h acpi_wmi_if.h >>> virtio_bus_if.h virtio_if.h acpi_quirks.h feeder_eq_gen.h feeder_rate_gen.h >>> snd_fxdiv_gen.h miidevs.h pccarddevs.h teken_state.h usbdevs.h usbdevs_data.h >>> ia32_genassym.o ia32_assym.h acpi_wakecode.o acpi_wakecode.bin >>> acpi_wakecode.h acpi_wakedata.h >>> --- modules-cleandir --- >>> cd /usr/src/sys/modules; MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/OZZIE/modules >>> KMODDIR=/boot/kernel MACHINE_CPUARCH=amd64 DEBUG_FLAGS="-g" MACHINE=amd64 >>> KERNBUILDDIR="/usr/obj/usr/src/sys/OZZIE" SYSDIR="/usr/src/sys" WITH_CTF="1" >>> make cleandir >>> --- cleandir_subdir_aac --- >>> --- cleandir_subdir_aacraid --- >>> --- cleandir_subdir_accf_data --- >>> --- cleandir_subdir_accf_dns --- >>> --- cleandir_subdir_aac --- >>> ===> aac (cleandir) >>> --- cleandir_subdir_aacraid --- >>> ===> aacraid (cleandir) >>> --- cleandir_subdir_accf_data --- >>> ===> accf_data (cleandir) >>> --- cleandir_subdir_accf_dns --- >>> ===> accf_dns (cleandir) >>> --- cleandir_subdir_accf_data --- >>> --- cleanobj --- >>> --- cleandir_subdir_accf_dns --- >>> --- cleanobj --- >>> --- cleandir_subdir_aacraid --- >>> --- cleanobj --- >>> --- cleandir_subdir_aac --- >>> --- cleanobj --- >>> --- cleandir_subdir_accf_http --- >>> --- cleandir_subdir_acl_nfs4 --- >>> --- cleandir_subdir_accf_http --- >>> ===> accf_http (cleandir) >>> --- cleandir_subdir_acl_nfs4 --- >>> ===> acl_nfs4 (cleandir) >>> --- cleandir_subdir_acl_posix1e --- >>> --- cleandir_subdir_acpi --- >>> --- cleandir_subdir_acl_posix1e --- >>> ===> acl_posix1e (cleandir) >>> --- cleandir_subdir_acpi --- >>> ===> acpi (cleandir) >>> --- cleandir_subdir_accf_http --- >>> --- cleanobj --- >>> --- cleandir_subdir_acl_nfs4 --- >>> --- cleanobj --- >>> --- cleandir_subdir_acpi --- >>> --- _sub.cleandir --- >>> ===> acpi/acpi_asus (cleandir) >>> --- cleandir_subdir_ae --- >>> ===> ae (cleandir) >>> --- cleandir_subdir_aesni --- >>> ===> aesni (cleandir) >>> --- cleandir_subdir_acl_posix1e --- >>> --- cleanobj --- >>> --- cleandir_subdir_acpi --- >>> --- cleanobj --- >>> --- cleandir_subdir_age --- >>> ===> age (cleandir) >>> --- cleandir_subdir_aesni --- >>> --- cleanobj --- >>> --- cleandir_subdir_ae --- >>> --- cleanobj --- >>> --- cleandir_subdir_acpi --- >>> ===> acpi/acpi_asus_wmi (cleandir) >>> --- cleandir_subdir_age --- >>> --- cleanobj --- >>> --- cleandir_subdir_acpi --- >>> --- cleanobj --- >>> --- cleandir_subdir_agp --- >>> --- cleandir_subdir_aha --- >>> --- cleandir_subdir_agp --- >>> ===> agp (cleandir) >>> --- cleandir_subdir_aha --- >>> ===> aha (cleandir) >>> --- cleanobj --- >>> --- cleandir_subdir_ahci --- >>> ===> ahci (cleandir) >>> --- cleandir_subdir_aic7xxx --- >>> ===> aic7xxx (cleandir) >>> --- cleandir_subdir_ahci --- >>> --- cleanobj --- >>> --- cleandir_subdir_agp --- >>> --- cleanobj --- >>> --- cleandir_subdir_acpi --- >>> ===> acpi/acpi_fujitsu (cleandir) >>> --- cleandir_subdir_aic7xxx --- >>> --- _sub.cleandir --- >>> ===> aic7xxx/ahc (cleandir) >>> --- cleandir_subdir_aio --- >>> ===> aio (cleandir) >>> --- cleandir_subdir_acpi --- >>> --- cleanobj --- >>> --- cleandir_subdir_aic7xxx --- >>> --- cleanobj --- >>> --- cleandir_subdir_alc --- >>> ===> alc (cleandir) >>> --- cleandir_subdir_aio --- >>> --- cleanobj --- >>> --- cleandir_subdir_acpi --- >>> ===> acpi/acpi_hp (cleandir) >>> --- cleandir_subdir_alc --- >>> --- cleanobj --- >>> --- cleandir_subdir_acpi --- >>> --- cleanobj --- >>> --- cleandir_subdir_aic7xxx --- >>> --- _sub.cleandir --- >>> ===> aic7xxx/ahc/ahc_eisa (cleandir) >>> --- clean --- >>> rm -f export_syms ahc_eisa.ko ahc_eisa.kld ahc_eisa.o ahc_eisa.ko.debug >>> ahc_eisa.ko.symbols opt_scsi.h opt_cam.h opt_aic7xxx.h eisa_if.h pci_if.h >>> bus_if.h device_if.h >>> --- cleanilinks --- >>> rm -f @ machine x86 >>> --- cleandepend --- >>> rm -f .depend GPATH GRTAGS GSYMS GTAGS >>> --- cleanobj --- >>> ===> aic7xxx/ahc/ahc_isa (cleandir) >>> --- cleanobj --- >>> ===> aic7xxx/ahc/ahc_pci (cleandir) >>> --- cleandir_subdir_acpi --- >>> ===> acpi/acpi_ibm (cleandir) >>> --- cleandir_subdir_ale --- >>> ===> ale (cleandir) >>> --- cleandir_subdir_aic7xxx --- >>> --- cleanobj --- >>> --- cleandir_subdir_alq --- >>> ===> alq (cleandir) >>> --- cleandir_subdir_aic7xxx --- >>> --- cleanobj --- >>> rm: fts_read: No such file or directory >>> *** [cleanobj] Error code 1 >>> >>> make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc >>> 1 error >>> >>> make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc >>> *** [_sub.cleandir] Error code 2 >>> >>> make[4]: stopped in /usr/src/sys/modules/aic7xxx >>> 1 error >>> >>> make[4]: stopped in /usr/src/sys/modules/aic7xxx >>> *** [cleandir_subdir_aic7xxx] Error code 2 >>> >>> make[3]: stopped in /usr/src/sys/modules >>> --- cleandir_subdir_alq --- >>> A failure has been detected in another branch of the parallel make >>> >>> make[4]: stopped in /usr/src/sys/modules/alq >>> --- cleandir_subdir_ale --- >>> A failure has been detected in another branch of the parallel make >>> >>> make[4]: stopped in /usr/src/sys/modules/ale >>> --- cleandir_subdir_alq --- >>> *** [cleandir_subdir_alq] Error code 2 >>> >>> make[3]: stopped in /usr/src/sys/modules >>> --- cleandir_subdir_acpi --- >>> --- cleanobj --- >>> --- cleandir_subdir_ale --- >>> *** [cleandir_subdir_ale] Error code 2 >>> >>> make[3]: stopped in /usr/src/sys/modules >>> --- cleandir_subdir_acpi --- >>> A failure has been detected in another branch of the parallel make >>>>>> Kernel build for OZZIE started on Thu Sep 18 04:35:18 CDT 2014 >>> -------------------------------------------------------------- >>> ===> OZZIE >>> mkdir -p /usr/obj/usr/src/sys >>> -------------------------------------------------------------- >>>>>> stage 1: configuring the kernel >>> -------------------------------------------------------------- >>> cd /usr/src/sys/amd64/conf; >>> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin >>> config -d /usr/obj/usr/src/sys/OZZIE -I '/usr/src/sys/amd64/conf' >>> '/usr/src/sys/amd64/conf/OZZIE' >>> Kernel build directory is /usr/obj/usr/src/sys/OZZIE >>> Don't forget to do ``make cleandepend && make depend'' >>> -------------------------------------------------------------- >>>>>> stage 2.1: cleaning up the object tree >>> -------------------------------------------------------------- >>> cd /usr/obj/usr/src/sys/OZZIE; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 >>> MACHINE=amd64 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin >>> GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font >>> GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac >>> _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp _LDSCRIPTROOT= VERSION="FreeBSD >>> 10.1-BETA1 amd64 1000716" INSTALL="sh /usr/src/tools/install.sh" >>> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin >>> CC="cc " CXX="c++ " CPP="cpp " AS="as" AR="ar" LD="ld" NM=nm OBJDUMP= >>> RANLIB=ranlib STRINGS= COMPILER_TYPE=clang make -j 4 -J 15,16 -m >>> /usr/src/share/mk KERNEL=kernel cleandir >>> --- kernel-clean --- >>> --- kernel-cleandepend --- >>> --- modules-cleandir --- >>> --- kernel-cleandepend --- >>> rm -f .depend machine x86 >>> --- kernel-clean --- >>> rm -f *.o *.so *.So *.ko *.s eddep errs kernel.debug kernel kernel.symbols >>> linterrs tags vers.c vnode_if.c vnode_if.h vnode_if_newproto.h >>> vnode_if_typedef.h agp_if.c ata_if.c eisa_if.c fb_if.c miibus_if.c mmcbr_if.c >>> mmcbus_if.c mvs_if.c card_if.c power_if.c pci_if.c pcib_if.c ppbus_if.c >>> sdhci_if.c hdac_if.c ac97_if.c channel_if.c feeder_if.c mixer_if.c mpu_if.c >>> mpufoi_if.c synth_if.c uart_if.c usb_if.c g_part_if.c g_raid_md_if.c >>> g_raid_tr_if.c isa_if.c bus_if.c clock_if.c cpufreq_if.c device_if.c >>> linker_if.c serdev_if.c xenbus_if.c xenbusb_if.c acpi_if.c acpi_wmi_if.c >>> virtio_bus_if.c virtio_if.c agp_if.h ata_if.h eisa_if.h fb_if.h miibus_if.h >>> mmcbr_if.h mmcbus_if.h mvs_if.h card_if.h power_if.h pci_if.h pcib_if.h >>> ppbus_if.h sdhci_if.h hdac_if.h ac97_if.h channel_if.h feeder_if.h mixer_if.h >>> mpu_if.h mpufoi_if.h synth_if.h uart_if.h usb_if.h g_part_if.h g_raid_md_if.h >>> g_raid_tr_if.h isa_if.h bus_if.h clock_if.h cpufreq_if.h device_if.h >>> linker_if.h serdev_if.h xenbus_if.h xenbusb_if.h acpi_if.h acpi_wmi_if.h >>> virtio_bus_if.h virtio_if.h acpi_quirks.h feeder_eq_gen.h feeder_rate_gen.h >>> snd_fxdiv_gen.h miidevs.h pccarddevs.h teken_state.h usbdevs.h usbdevs_data.h >>> ia32_genassym.o ia32_assym.h acpi_wakecode.o acpi_wakecode.bin >>> acpi_wakecode.h acpi_wakedata.h >>> --- modules-cleandir --- >>> cd /usr/src/sys/modules; MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/OZZIE/modules >>> KMODDIR=/boot/kernel MACHINE_CPUARCH=amd64 DEBUG_FLAGS="-g" MACHINE=amd64 >>> KERNBUILDDIR="/usr/obj/usr/src/sys/OZZIE" SYSDIR="/usr/src/sys" WITH_CTF="1" >>> make cleandir >>> --- cleandir_subdir_aac --- >>> --- cleandir_subdir_aacraid --- >>> --- cleandir_subdir_accf_data --- >>> --- cleandir_subdir_accf_dns --- >>> --- cleandir_subdir_aac --- >>> ===> aac (cleandir) >>> --- cleandir_subdir_aacraid --- >>> ===> aacraid (cleandir) >>> --- cleandir_subdir_accf_data --- >>> ===> accf_data (cleandir) >>> --- cleandir_subdir_accf_dns --- >>> ===> accf_dns (cleandir) >>> --- cleandir_subdir_accf_data --- >>> --- cleanobj --- >>> --- cleandir_subdir_accf_dns --- >>> --- cleanobj --- >>> --- cleandir_subdir_aacraid --- >>> --- cleanobj --- >>> --- cleandir_subdir_aac --- >>> --- cleanobj --- >>> --- cleandir_subdir_accf_http --- >>> --- cleandir_subdir_acl_nfs4 --- >>> --- cleandir_subdir_accf_http --- >>> ===> accf_http (cleandir) >>> --- cleandir_subdir_acl_nfs4 --- >>> ===> acl_nfs4 (cleandir) >>> --- cleandir_subdir_acl_posix1e --- >>> --- cleandir_subdir_acpi --- >>> --- cleandir_subdir_acl_posix1e --- >>> ===> acl_posix1e (cleandir) >>> --- cleandir_subdir_acpi --- >>> ===> acpi (cleandir) >>> --- cleandir_subdir_accf_http --- >>> --- cleanobj --- >>> --- cleandir_subdir_acl_nfs4 --- >>> --- cleanobj --- >>> --- cleandir_subdir_acpi --- >>> --- _sub.cleandir --- >>> ===> acpi/acpi_asus (cleandir) >>> --- cleandir_subdir_ae --- >>> ===> ae (cleandir) >>> --- cleandir_subdir_aesni --- >>> ===> aesni (cleandir) >>> --- cleandir_subdir_acl_posix1e --- >>> --- cleanobj --- >>> --- cleandir_subdir_acpi --- >>> --- cleanobj --- >>> --- cleandir_subdir_age --- >>> ===> age (cleandir) >>> --- cleandir_subdir_aesni --- >>> --- cleanobj --- >>> --- cleandir_subdir_ae --- >>> --- cleanobj --- >>> --- cleandir_subdir_acpi --- >>> ===> acpi/acpi_asus_wmi (cleandir) >>> --- cleandir_subdir_age --- >>> --- cleanobj --- >>> --- cleandir_subdir_acpi --- >>> --- cleanobj --- >>> --- cleandir_subdir_agp --- >>> --- cleandir_subdir_aha --- >>> --- cleandir_subdir_agp --- >>> ===> agp (cleandir) >>> --- cleandir_subdir_aha --- >>> ===> aha (cleandir) >>> --- cleanobj --- >>> --- cleandir_subdir_ahci --- >>> ===> ahci (cleandir) >>> --- cleandir_subdir_aic7xxx --- >>> ===> aic7xxx (cleandir) >>> --- cleandir_subdir_ahci --- >>> --- cleanobj --- >>> --- cleandir_subdir_agp --- >>> --- cleanobj --- >>> --- cleandir_subdir_acpi --- >>> ===> acpi/acpi_fujitsu (cleandir) >>> --- cleandir_subdir_aic7xxx --- >>> --- _sub.cleandir --- >>> ===> aic7xxx/ahc (cleandir) >>> --- cleandir_subdir_aio --- >>> ===> aio (cleandir) >>> --- cleandir_subdir_acpi --- >>> --- cleanobj --- >>> --- cleandir_subdir_aic7xxx --- >>> --- cleanobj --- >>> --- cleandir_subdir_alc --- >>> ===> alc (cleandir) >>> --- cleandir_subdir_aio --- >>> --- cleanobj --- >>> --- cleandir_subdir_acpi --- >>> ===> acpi/acpi_hp (cleandir) >>> --- cleandir_subdir_alc --- >>> --- cleanobj --- >>> --- cleandir_subdir_acpi --- >>> --- cleanobj --- >>> --- cleandir_subdir_aic7xxx --- >>> --- _sub.cleandir --- >>> ===> aic7xxx/ahc/ahc_eisa (cleandir) >>> --- clean --- >>> rm -f export_syms ahc_eisa.ko ahc_eisa.kld ahc_eisa.o ahc_eisa.ko.debug >>> ahc_eisa.ko.symbols opt_scsi.h opt_cam.h opt_aic7xxx.h eisa_if.h pci_if.h >>> bus_if.h device_if.h >>> --- cleanilinks --- >>> rm -f @ machine x86 >>> --- cleandepend --- >>> rm -f .depend GPATH GRTAGS GSYMS GTAGS >>> --- cleanobj --- >>> ===> aic7xxx/ahc/ahc_isa (cleandir) >>> --- cleanobj --- >>> ===> aic7xxx/ahc/ahc_pci (cleandir) >>> --- cleandir_subdir_acpi --- >>> ===> acpi/acpi_ibm (cleandir) >>> --- cleandir_subdir_ale --- >>> ===> ale (cleandir) >>> --- cleandir_subdir_aic7xxx --- >>> --- cleanobj --- >>> --- cleandir_subdir_alq --- >>> ===> alq (cleandir) >>> --- cleandir_subdir_aic7xxx --- >>> --- cleanobj --- >>> rm: fts_read: No such file or directory >>> *** [cleanobj] Error code 1 >>> >>> make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc >>> 1 error >>> >>> make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc >>> *** [_sub.cleandir] Error code 2 >>> >>> make[4]: stopped in /usr/src/sys/modules/aic7xxx >>> 1 error >>> >>> make[4]: stopped in /usr/src/sys/modules/aic7xxx >>> *** [cleandir_subdir_aic7xxx] Error code 2 >>> >>> make[3]: stopped in /usr/src/sys/modules >>> --- cleandir_subdir_alq --- >>> A failure has been detected in another branch of the parallel make >>> >>> make[4]: stopped in /usr/src/sys/modules/alq >>> --- cleandir_subdir_ale --- >>> A failure has been detected in another branch of the parallel make >>> >>> make[4]: stopped in /usr/src/sys/modules/ale >>> --- cleandir_subdir_alq --- >>> *** [cleandir_subdir_alq] Error code 2 >>> >>> make[3]: stopped in /usr/src/sys/modules >>> --- cleandir_subdir_acpi --- >>> --- cleanobj --- >>> --- cleandir_subdir_ale --- >>> *** [cleandir_subdir_ale] Error code 2 >>> >>> make[3]: stopped in /usr/src/sys/modules >>> --- cleandir_subdir_acpi --- >>> A failure has been detected in another branch of the parallel make >>> >>> make[5]: stopped in /usr/src/sys/modules/acpi/acpi_ibm >>> *** [_sub.cleandir] Error code 2 >>> >>> make[4]: stopped in /usr/src/sys/modules/acpi >>> 1 error >>> >>> make[4]: stopped in /usr/src/sys/modules/acpi >>> *** [cleandir_subdir_acpi] Error code 2 >>> >>> make[3]: stopped in /usr/src/sys/modules >>> 4 errors >>> >>> make[3]: stopped in /usr/src/sys/modules >>> *** [modules-cleandir] Error code 2 >>> >>> make[2]: stopped in /usr/obj/usr/src/sys/OZZIE >>> 1 error >>> >>> make[2]: stopped in /usr/obj/usr/src/sys/OZZIE >>> *** [buildkernel] Error code 2 >>> >>> make[1]: stopped in /usr/src >>> 1 error >>> >>> make[1]: stopped in /usr/src >>> *** [buildkernel] Error code 2 >>> >>> make: stopped in /usr/src >>> 1 error >>> >>> make: stopped in /usr/src >>> >>> make[5]: stopped in /usr/src/sys/modules/acpi/acpi_ibm >>> *** [_sub.cleandir] Error code 2 >>> >>> make[4]: stopped in /usr/src/sys/modules/acpi >>> 1 error >>> >>> make[4]: stopped in /usr/src/sys/modules/acpi >>> *** [cleandir_subdir_acpi] Error code 2 >>> >>> make[3]: stopped in /usr/src/sys/modules >>> 4 errors >>> >>> make[3]: stopped in /usr/src/sys/modules >>> *** [modules-cleandir] Error code 2 >>> >>> make[2]: stopped in /usr/obj/usr/src/sys/OZZIE >>> 1 error >>> >>> make[2]: stopped in /usr/obj/usr/src/sys/OZZIE >>> *** [buildkernel] Error code 2 >>> >>> make[1]: stopped in /usr/src >>> 1 error >>> >>> make[1]: stopped in /usr/src >>> *** [buildkernel] Error code 2 >>> >>> make: stopped in /usr/src >>> 1 error >>> >>> make: stopped in /usr/src >>> >>> *** [cleandir_subdir_ale] Error code 2 >>> >>> make[3]: stopped in /usr/src/sys/modules >>> --- cleandir_subdir_acpi --- >>> A failure has been detected in another branch of the parallel make >>> >>> make[5]: stopped in /usr/src/sys/modules/acpi/acpi_ibm >>> *** [_sub.cleandir] Error code 2 >>> >>> make[4]: stopped in /usr/src/sys/modules/acpi >>> 1 error >>> >>> make[4]: stopped in /usr/src/sys/modules/acpi >>> *** [cleandir_subdir_acpi] Error code 2 >>> >>> make[3]: stopped in /usr/src/sys/modules >>> 4 errors >>> >>> make[3]: stopped in /usr/src/sys/modules >>> *** [modules-cleandir] Error code 2 >>> >>> make[2]: stopped in /usr/obj/usr/src/sys/MYFINEHOST >>> 1 error >>> >>> make[2]: stopped in /usr/obj/usr/src/sys/MYFINEHOST >>> *** [buildkernel] Error code 2 >>> >>> make[1]: stopped in /usr/src >>> 1 error >>> >>> make[1]: stopped in /usr/src >>> *** [buildkernel] Error code 2 >>> >>> make: stopped in /usr/src >>> 1 error >>> >>> make: stopped in /usr/src >>> >>> -- >>> ---------------------------------------------------------------------------- >>> Tim Daneliuk tundra@tundraware.com >>> PGP Key: http://www.tundraware.com/PGP/ >>> >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >>> >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > -- > ---------------------------------------------------------------------------- > Tim Daneliuk tundra@tundraware.com > PGP Key: http://www.tundraware.com/PGP/ > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Thu Sep 18 23:51:43 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 132EAB0E for ; Thu, 18 Sep 2014 23:51:43 +0000 (UTC) Received: from mta1.riverwillow.net.au (mta1.riverwillow.net.au [IPv6:2001:8000:1000:1801::36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mta1.riverwillow.net.au", Issuer "Riverwillow Root Certificate 2010-04-12" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 59B478E8 for ; Thu, 18 Sep 2014 23:51:42 +0000 (UTC) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [IPv6:2001:8000:1000:1801::46]) by mta1.riverwillow.net.au (8.14.9/8.14.9) with ESMTP id s8INpXAP073277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 19 Sep 2014 09:51:33 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=mta1002; t=1411084293; bh=gRdVZ3LAZVQYPdrzQWhid+3490rQ8PMH+5YGmQBhBSA=; h=Date:From:To:Subject; b=RoXD86S8G+sYK5kY5ghyiIcERCLRig1GgtIJo6hVoBfJrM0+vR6ZUhmAnTU9hTzx0 d+Ax0+NkLGQ1f136/hSFfFPLomLp9UACi61E2VWkHVU6oNimUr7PI2LO1jFhFygXqo 8WcKUo/jLNIYk/Prq3V/b2A6h34FGSi2IZacBINc= Received: from rwpc15.gfn.riverwillow.net.au (rwpc15.gfn.riverwillow.net.au [IPv6:2001:8000:1000:18e1:20c:76ff:fe0a:2117]) (authenticated bits=56) by mail1.riverwillow.net.au (8.14.9/8.14.9) with ESMTP id s8INpUMa073276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 19 Sep 2014 09:51:32 +1000 (AEST) Date: Fri, 19 Sep 2014 09:51:30 +1000 From: John Marshall To: freebsd-stable@freebsd.org Subject: MFC missing for mfiutil(8) in 10-STABLE Message-ID: <20140918235130.GA3070@rwpc15.gfn.riverwillow.net.au> Mail-Followup-To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline OpenPGP: id=A29A84A2; url=http://pki.riverwillow.com.au/pgp/johnmarshall.asc User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 23:51:43 -0000 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm wondering if this is a simple case of a forgotten MFC? ------------------------------------------------------------------------ r257820 | sbruno | 2013-11-08 08:47:59 +1100 (Fri, 08 Nov 2013) | 8 lines Changed paths: M /head/usr.sbin/mfiutil/Makefile A /head/usr.sbin/mfiutil/mfi_properties.c M /head/usr.sbin/mfiutil/mfiutil.8 M /head/usr.sbin/mfiutil/mfiutil.c Add support for controlling mfi(4) controller properties: allow user control of rebuild rate allow user control of silence/enable alarm MFC after: 2 weeks Sponsored by: Yahoo! Inc. ------------------------------------------------------------------------ Since the beginning of this year I have been applying this merge to 9.2-RELEASE, 9.3-RELEASE and 10-STABLE on an Intel server with the following hardware: mfi0@pci0:6:0:0: class=3D0x010400 card=3D0x92618086 chip=3D0x00791000 rev= =3D0x05 hdr=3D0x00 vendor =3D 'LSI Logic / Symbios Logic' device =3D 'MegaRAID SAS 2108 [Liberator]' class =3D mass storage subclass =3D RAID I'm wondering if this might be MFC'd before releng/10.1 is branched? It is a real bonus being able to silence the controller's audible alarm without having to shutdown FreeBSD! --=20 John Marshall --tThc/1wpZn/ma/RB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlQbcAIACgkQw/tAaKKahKJPiwCcCfUS3zRhAw8lZ52l9rXDCJlk KGwAnRCPOarNgJksXwvfygB+TGrLaP7t =RK0B -----END PGP SIGNATURE----- --tThc/1wpZn/ma/RB-- From owner-freebsd-stable@FreeBSD.ORG Fri Sep 19 00:05:21 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76134E3D for ; Fri, 19 Sep 2014 00:05:21 +0000 (UTC) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ozzie.tundraware.com", Issuer "ozzie.tundraware.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A0E89E3 for ; Fri, 19 Sep 2014 00:05:20 +0000 (UTC) Received: from [192.168.0.2] (viper.tundraware.com [192.168.0.2]) (authenticated bits=0) by ozzie.tundraware.com (8.14.9/8.14.9) with ESMTP id s8J05AGs098932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 18 Sep 2014 19:05:10 -0500 (CDT) (envelope-from tundra@tundraware.com) Message-ID: <541B7336.9070401@tundraware.com> Date: Thu, 18 Sep 2014 19:05:10 -0500 From: Tim Daneliuk User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Steven Hartland , FreeBSD Stable Subject: Re: 10.1Beta - Ongoing Build Problems References: <541B6167.3000703@tundraware.com> <541B6A6F.5010501@tundraware.com> <62E5543C34E048D5B454CD795ACAC495@multiplay.co.uk> In-Reply-To: <62E5543C34E048D5B454CD795ACAC495@multiplay.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (ozzie.tundraware.com [75.145.138.73]); Thu, 18 Sep 2014 19:05:10 -0500 (CDT) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: s8J05AGs098932 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 00:05:21 -0000 On 09/18/2014 06:36 PM, Steven Hartland wrote: > I just noticed your error was > > rm: fts_read: No such file or directory > > This is a know issue with rewinddir. > > I believe the fix is: > http://svnweb.freebsd.org/changeset/base/271048 > > Which was MFC'ed by: > http://svnweb.freebsd.org/changeset/base/271263 > > So your build machine will need to be running r271263 or later. Hmmm I am at: 10.1-PRERELEASE #27 r271419 > > Regards > Steve > > ----- Original Message ----- From: "Tim Daneliuk" > To: "Steven Hartland" ; "FreeBSD Stable" > > Sent: Friday, September 19, 2014 12:27 AM > Subject: Re: 10.1Beta - Ongoing Build Problems > > >> On 09/18/2014 06:06 PM, Steven Hartland wrote: >>> IIRC this can happen if your building on a box which is too old. >>> >>> I've been doing loads of stable/10 builds recently with -j24 and >>> only had an issue a while back, updating the world on the box >>> in question (using no -j) fixed it for me. >>> >>> Regards >>> Steve >> >> The hardware is pretty new and the OS was updated within the last several >> weeks to the then -STABLE branch. I've been seeing this on- and off >> for a while. >> >> >> >>> >>> ----- Original Message ----- From: "Tim Daneliuk" >>> To: "FreeBSD Stable" >>> Sent: Thursday, September 18, 2014 11:49 PM >>> Subject: 10.1Beta - Ongoing Build Problems >>> >>> >>>> I continue to see problems as seen below if I attempt a parallel make. >>>> If I remove the '-j4' from my build script, this build completes fine, >>>> albeit much more slowly. Ideas anyone??: >>>> >>>> >>>>>>> Kernel build for MYFINEHOST started on Thu Sep 18 04:35:18 CDT 2014 >>>> -------------------------------------------------------------- >>>> ===> MYFINEHOST >>>> mkdir -p /usr/obj/usr/src/sys >>>> -------------------------------------------------------------- >>>>>>> stage 1: configuring the kernel >>>> -------------------------------------------------------------- >>>> cd /usr/src/sys/amd64/conf; >>>> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin >>>> >>>> config -d /usr/obj/usr/src/sys/MYFINEHOST -I '/usr/src/sys/amd64/conf' >>>> '/usr/src/sys/amd64/conf/MYFINEHOST' >>>> Kernel build directory is /usr/obj/usr/src/sys/MYFINEHOST >>>> Don't forget to do ``make cleandepend && make depend'' >>>> -------------------------------------------------------------- >>>>>>> stage 2.1: cleaning up the object tree >>>> -------------------------------------------------------------- >>>> cd /usr/obj/usr/src/sys/MYFINEHOST; MAKEOBJDIRPREFIX=/usr/obj >>>> MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= >>>> GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin >>>> GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font >>>> GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac >>>> _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp _LDSCRIPTROOT= VERSION="FreeBSD >>>> 10.1-BETA1 amd64 1000716" INSTALL="sh /usr/src/tools/install.sh" >>>> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin >>>> >>>> CC="cc " CXX="c++ " CPP="cpp " AS="as" AR="ar" LD="ld" NM=nm OBJDUMP= >>>> RANLIB=ranlib STRINGS= COMPILER_TYPE=clang make -j 4 -J 15,16 -m >>>> /usr/src/share/mk KERNEL=kernel cleandir >>>> --- kernel-clean --- >>>> --- kernel-cleandepend --- >>>> --- modules-cleandir --- >>>> --- kernel-cleandepend --- >>>> rm -f .depend machine x86 >>>> --- kernel-clean --- >>>> rm -f *.o *.so *.So *.ko *.s eddep errs kernel.debug kernel kernel.symbols >>>> linterrs tags vers.c vnode_if.c vnode_if.h vnode_if_newproto.h >>>> vnode_if_typedef.h agp_if.c ata_if.c eisa_if.c fb_if.c miibus_if.c mmcbr_if.c >>>> mmcbus_if.c mvs_if.c card_if.c power_if.c pci_if.c pcib_if.c ppbus_if.c >>>> sdhci_if.c hdac_if.c ac97_if.c channel_if.c feeder_if.c mixer_if.c mpu_if.c >>>> mpufoi_if.c synth_if.c uart_if.c usb_if.c g_part_if.c g_raid_md_if.c >>>> g_raid_tr_if.c isa_if.c bus_if.c clock_if.c cpufreq_if.c device_if.c >>>> linker_if.c serdev_if.c xenbus_if.c xenbusb_if.c acpi_if.c acpi_wmi_if.c >>>> virtio_bus_if.c virtio_if.c agp_if.h ata_if.h eisa_if.h fb_if.h miibus_if.h >>>> mmcbr_if.h mmcbus_if.h mvs_if.h card_if.h power_if.h pci_if.h pcib_if.h >>>> ppbus_if.h sdhci_if.h hdac_if.h ac97_if.h channel_if.h feeder_if.h mixer_if.h >>>> mpu_if.h mpufoi_if.h synth_if.h uart_if.h usb_if.h g_part_if.h g_raid_md_if.h >>>> g_raid_tr_if.h isa_if.h bus_if.h clock_if.h cpufreq_if.h device_if.h >>>> linker_if.h serdev_if.h xenbus_if.h xenbusb_if.h acpi_if.h acpi_wmi_if.h >>>> virtio_bus_if.h virtio_if.h acpi_quirks.h feeder_eq_gen.h feeder_rate_gen.h >>>> snd_fxdiv_gen.h miidevs.h pccarddevs.h teken_state.h usbdevs.h usbdevs_data.h >>>> ia32_genassym.o ia32_assym.h acpi_wakecode.o acpi_wakecode.bin >>>> acpi_wakecode.h acpi_wakedata.h >>>> --- modules-cleandir --- >>>> cd /usr/src/sys/modules; >>>> MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/MYFINEHOST/modules KMODDIR=/boot/kernel >>>> MACHINE_CPUARCH=amd64 DEBUG_FLAGS="-g" MACHINE=amd64 >>>> KERNBUILDDIR="/usr/obj/usr/src/sys/MYFINEHOST" SYSDIR="/usr/src/sys" >>>> WITH_CTF="1" make cleandir >>>> --- cleandir_subdir_aac --- >>>> --- cleandir_subdir_aacraid --- >>>> --- cleandir_subdir_accf_data --- >>>> --- cleandir_subdir_accf_dns --- >>>> --- cleandir_subdir_aac --- >>>> ===> aac (cleandir) >>>> --- cleandir_subdir_aacraid --- >>>> ===> aacraid (cleandir) >>>> --- cleandir_subdir_accf_data --- >>>> ===> accf_data (cleandir) >>>> --- cleandir_subdir_accf_dns --- >>>> ===> accf_dns (cleandir) >>>> --- cleandir_subdir_accf_data --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_accf_dns --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_aacraid --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_aac --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_accf_http --- >>>> --- cleandir_subdir_acl_nfs4 --- >>>> --- cleandir_subdir_accf_http --- >>>> ===> accf_http (cleandir) >>>> --- cleandir_subdir_acl_nfs4 --- >>>> ===> acl_nfs4 (cleandir) >>>> --- cleandir_subdir_acl_posix1e --- >>>> --- cleandir_subdir_acpi --- >>>> --- cleandir_subdir_acl_posix1e --- >>>> ===> acl_posix1e (cleandir) >>>> --- cleandir_subdir_acpi --- >>>> ===> acpi (cleandir) >>>> --- cleandir_subdir_accf_http --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acl_nfs4 --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> --- _sub.cleandir --- >>>> ===> acpi/acpi_asus (cleandir) >>>> --- cleandir_subdir_ae --- >>>> ===> ae (cleandir) >>>> --- cleandir_subdir_aesni --- >>>> ===> aesni (cleandir) >>>> --- cleandir_subdir_acl_posix1e --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_age --- >>>> ===> age (cleandir) >>>> --- cleandir_subdir_aesni --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_ae --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> ===> acpi/acpi_asus_wmi (cleandir) >>>> --- cleandir_subdir_age --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_agp --- >>>> --- cleandir_subdir_aha --- >>>> --- cleandir_subdir_agp --- >>>> ===> agp (cleandir) >>>> --- cleandir_subdir_aha --- >>>> ===> aha (cleandir) >>>> --- cleanobj --- >>>> --- cleandir_subdir_ahci --- >>>> ===> ahci (cleandir) >>>> --- cleandir_subdir_aic7xxx --- >>>> ===> aic7xxx (cleandir) >>>> --- cleandir_subdir_ahci --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_agp --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> ===> acpi/acpi_fujitsu (cleandir) >>>> --- cleandir_subdir_aic7xxx --- >>>> --- _sub.cleandir --- >>>> ===> aic7xxx/ahc (cleandir) >>>> --- cleandir_subdir_aio --- >>>> ===> aio (cleandir) >>>> --- cleandir_subdir_acpi --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_aic7xxx --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_alc --- >>>> ===> alc (cleandir) >>>> --- cleandir_subdir_aio --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> ===> acpi/acpi_hp (cleandir) >>>> --- cleandir_subdir_alc --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_aic7xxx --- >>>> --- _sub.cleandir --- >>>> ===> aic7xxx/ahc/ahc_eisa (cleandir) >>>> --- clean --- >>>> rm -f export_syms ahc_eisa.ko ahc_eisa.kld ahc_eisa.o ahc_eisa.ko.debug >>>> ahc_eisa.ko.symbols opt_scsi.h opt_cam.h opt_aic7xxx.h eisa_if.h pci_if.h >>>> bus_if.h device_if.h >>>> --- cleanilinks --- >>>> rm -f @ machine x86 >>>> --- cleandepend --- >>>> rm -f .depend GPATH GRTAGS GSYMS GTAGS >>>> --- cleanobj --- >>>> ===> aic7xxx/ahc/ahc_isa (cleandir) >>>> --- cleanobj --- >>>> ===> aic7xxx/ahc/ahc_pci (cleandir) >>>> --- cleandir_subdir_acpi --- >>>> ===> acpi/acpi_ibm (cleandir) >>>> --- cleandir_subdir_ale --- >>>> ===> ale (cleandir) >>>> --- cleandir_subdir_aic7xxx --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_alq --- >>>> ===> alq (cleandir) >>>> --- cleandir_subdir_aic7xxx --- >>>> --- cleanobj --- >>>> rm: fts_read: No such file or directory >>>> *** [cleanobj] Error code 1 >>>> >>>> make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc >>>> 1 error >>>> >>>> make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc >>>> *** [_sub.cleandir] Error code 2 >>>> >>>> make[4]: stopped in /usr/src/sys/modules/aic7xxx >>>> 1 error >>>> >>>> make[4]: stopped in /usr/src/sys/modules/aic7xxx >>>> *** [cleandir_subdir_aic7xxx] Error code 2 >>>> >>>> make[3]: stopped in /usr/src/sys/modules >>>> --- cleandir_subdir_alq --- >>>> A failure has been detected in another branch of the parallel make >>>> >>>> make[4]: stopped in /usr/src/sys/modules/alq >>>> --- cleandir_subdir_ale --- >>>> A failure has been detected in another branch of the parallel make >>>> >>>> make[4]: stopped in /usr/src/sys/modules/ale >>>> --- cleandir_subdir_alq --- >>>> *** [cleandir_subdir_alq] Error code 2 >>>> >>>> make[3]: stopped in /usr/src/sys/modules >>>> --- cleandir_subdir_acpi --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_ale --->>> Kernel build for OZZIE started on Thu Sep 18 >>>> 04:35:18 CDT 2014 >>>> -------------------------------------------------------------- >>>> ===> OZZIE >>>> mkdir -p /usr/obj/usr/src/sys >>>> -------------------------------------------------------------- >>>>>>> stage 1: configuring the kernel >>>> -------------------------------------------------------------- >>>> cd /usr/src/sys/amd64/conf; >>>> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin >>>> >>>> config -d /usr/obj/usr/src/sys/OZZIE -I '/usr/src/sys/amd64/conf' >>>> '/usr/src/sys/amd64/conf/OZZIE' >>>> Kernel build directory is /usr/obj/usr/src/sys/OZZIE >>>> Don't forget to do ``make cleandepend && make depend'' >>>> -------------------------------------------------------------- >>>>>>> stage 2.1: cleaning up the object tree >>>> -------------------------------------------------------------- >>>> cd /usr/obj/usr/src/sys/OZZIE; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 >>>> MACHINE=amd64 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin >>>> GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font >>>> GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac >>>> _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp _LDSCRIPTROOT= VERSION="FreeBSD >>>> 10.1-BETA1 amd64 1000716" INSTALL="sh /usr/src/tools/install.sh" >>>> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin >>>> >>>> CC="cc " CXX="c++ " CPP="cpp " AS="as" AR="ar" LD="ld" NM=nm OBJDUMP= >>>> RANLIB=ranlib STRINGS= COMPILER_TYPE=clang make -j 4 -J 15,16 -m >>>> /usr/src/share/mk KERNEL=kernel cleandir >>>> --- kernel-clean --- >>>> --- kernel-cleandepend --- >>>> --- modules-cleandir --- >>>> --- kernel-cleandepend --- >>>> rm -f .depend machine x86 >>>> --- kernel-clean --- >>>> rm -f *.o *.so *.So *.ko *.s eddep errs kernel.debug kernel kernel.symbols >>>> linterrs tags vers.c vnode_if.c vnode_if.h vnode_if_newproto.h >>>> vnode_if_typedef.h agp_if.c ata_if.c eisa_if.c fb_if.c miibus_if.c mmcbr_if.c >>>> mmcbus_if.c mvs_if.c card_if.c power_if.c pci_if.c pcib_if.c ppbus_if.c >>>> sdhci_if.c hdac_if.c ac97_if.c channel_if.c feeder_if.c mixer_if.c mpu_if.c >>>> mpufoi_if.c synth_if.c uart_if.c usb_if.c g_part_if.c g_raid_md_if.c >>>> g_raid_tr_if.c isa_if.c bus_if.c clock_if.c cpufreq_if.c device_if.c >>>> linker_if.c serdev_if.c xenbus_if.c xenbusb_if.c acpi_if.c acpi_wmi_if.c >>>> virtio_bus_if.c virtio_if.c agp_if.h ata_if.h eisa_if.h fb_if.h miibus_if.h >>>> mmcbr_if.h mmcbus_if.h mvs_if.h card_if.h power_if.h pci_if.h pcib_if.h >>>> ppbus_if.h sdhci_if.h hdac_if.h ac97_if.h channel_if.h feeder_if.h mixer_if.h >>>> mpu_if.h mpufoi_if.h synth_if.h uart_if.h usb_if.h g_part_if.h g_raid_md_if.h >>>> g_raid_tr_if.h isa_if.h bus_if.h clock_if.h cpufreq_if.h device_if.h >>>> linker_if.h serdev_if.h xenbus_if.h xenbusb_if.h acpi_if.h acpi_wmi_if.h >>>> virtio_bus_if.h virtio_if.h acpi_quirks.h feeder_eq_gen.h feeder_rate_gen.h >>>> snd_fxdiv_gen.h miidevs.h pccarddevs.h teken_state.h usbdevs.h usbdevs_data.h >>>> ia32_genassym.o ia32_assym.h acpi_wakecode.o acpi_wakecode.bin >>>> acpi_wakecode.h acpi_wakedata.h >>>> --- modules-cleandir --- >>>> cd /usr/src/sys/modules; MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/OZZIE/modules >>>> KMODDIR=/boot/kernel MACHINE_CPUARCH=amd64 DEBUG_FLAGS="-g" MACHINE=amd64 >>>> KERNBUILDDIR="/usr/obj/usr/src/sys/OZZIE" SYSDIR="/usr/src/sys" WITH_CTF="1" >>>> make cleandir >>>> --- cleandir_subdir_aac --- >>>> --- cleandir_subdir_aacraid --- >>>> --- cleandir_subdir_accf_data --- >>>> --- cleandir_subdir_accf_dns --- >>>> --- cleandir_subdir_aac --- >>>> ===> aac (cleandir) >>>> --- cleandir_subdir_aacraid --- >>>> ===> aacraid (cleandir) >>>> --- cleandir_subdir_accf_data --- >>>> ===> accf_data (cleandir) >>>> --- cleandir_subdir_accf_dns --- >>>> ===> accf_dns (cleandir) >>>> --- cleandir_subdir_accf_data --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_accf_dns --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_aacraid --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_aac --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_accf_http --- >>>> --- cleandir_subdir_acl_nfs4 --- >>>> --- cleandir_subdir_accf_http --- >>>> ===> accf_http (cleandir) >>>> --- cleandir_subdir_acl_nfs4 --- >>>> ===> acl_nfs4 (cleandir) >>>> --- cleandir_subdir_acl_posix1e --- >>>> --- cleandir_subdir_acpi --- >>>> --- cleandir_subdir_acl_posix1e --- >>>> ===> acl_posix1e (cleandir) >>>> --- cleandir_subdir_acpi --- >>>> ===> acpi (cleandir) >>>> --- cleandir_subdir_accf_http --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acl_nfs4 --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> --- _sub.cleandir --- >>>> ===> acpi/acpi_asus (cleandir) >>>> --- cleandir_subdir_ae --- >>>> ===> ae (cleandir) >>>> --- cleandir_subdir_aesni --- >>>> ===> aesni (cleandir) >>>> --- cleandir_subdir_acl_posix1e --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_age --- >>>> ===> age (cleandir) >>>> --- cleandir_subdir_aesni --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_ae --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> ===> acpi/acpi_asus_wmi (cleandir) >>>> --- cleandir_subdir_age --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_agp --- >>>> --- cleandir_subdir_aha --- >>>> --- cleandir_subdir_agp --- >>>> ===> agp (cleandir) >>>> --- cleandir_subdir_aha --- >>>> ===> aha (cleandir) >>>> --- cleanobj --- >>>> --- cleandir_subdir_ahci --- >>>> ===> ahci (cleandir) >>>> --- cleandir_subdir_aic7xxx --- >>>> ===> aic7xxx (cleandir) >>>> --- cleandir_subdir_ahci --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_agp --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> ===> acpi/acpi_fujitsu (cleandir) >>>> --- cleandir_subdir_aic7xxx --- >>>> --- _sub.cleandir --- >>>> ===> aic7xxx/ahc (cleandir) >>>> --- cleandir_subdir_aio --- >>>> ===> aio (cleandir) >>>> --- cleandir_subdir_acpi --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_aic7xxx --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_alc --- >>>> ===> alc (cleandir) >>>> --- cleandir_subdir_aio --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> ===> acpi/acpi_hp (cleandir) >>>> --- cleandir_subdir_alc --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_aic7xxx --- >>>> --- _sub.cleandir --- >>>> ===> aic7xxx/ahc/ahc_eisa (cleandir) >>>> --- clean --- >>>> rm -f export_syms ahc_eisa.ko ahc_eisa.kld ahc_eisa.o ahc_eisa.ko.debug >>>> ahc_eisa.ko.symbols opt_scsi.h opt_cam.h opt_aic7xxx.h eisa_if.h pci_if.h >>>> bus_if.h device_if.h >>>> --- cleanilinks --- >>>> rm -f @ machine x86 >>>> --- cleandepend --- >>>> rm -f .depend GPATH GRTAGS GSYMS GTAGS >>>> --- cleanobj --- >>>> ===> aic7xxx/ahc/ahc_isa (cleandir) >>>> --- cleanobj --- >>>> ===> aic7xxx/ahc/ahc_pci (cleandir) >>>> --- cleandir_subdir_acpi --- >>>> ===> acpi/acpi_ibm (cleandir) >>>> --- cleandir_subdir_ale --- >>>> ===> ale (cleandir) >>>> --- cleandir_subdir_aic7xxx --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_alq --- >>>> ===> alq (cleandir) >>>> --- cleandir_subdir_aic7xxx --- >>>> --- cleanobj --- >>>> rm: fts_read: No such file or directory >>>> *** [cleanobj] Error code 1 >>>> >>>> make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc >>>> 1 error >>>> >>>> make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc >>>> *** [_sub.cleandir] Error code 2 >>>> >>>> make[4]: stopped in /usr/src/sys/modules/aic7xxx >>>> 1 error >>>> >>>> make[4]: stopped in /usr/src/sys/modules/aic7xxx >>>> *** [cleandir_subdir_aic7xxx] Error code 2 >>>> >>>> make[3]: stopped in /usr/src/sys/modules >>>> --- cleandir_subdir_alq --- >>>> A failure has been detected in another branch of the parallel make >>>> >>>> make[4]: stopped in /usr/src/sys/modules/alq >>>> --- cleandir_subdir_ale --- >>>> A failure has been detected in another branch of the parallel make >>>> >>>> make[4]: stopped in /usr/src/sys/modules/ale >>>> --- cleandir_subdir_alq --- >>>> *** [cleandir_subdir_alq] Error code 2 >>>> >>>> make[3]: stopped in /usr/src/sys/modules >>>> --- cleandir_subdir_acpi --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_ale --- >>>> *** [cleandir_subdir_ale] Error code 2 >>>> >>>> make[3]: stopped in /usr/src/sys/modules >>>> --- cleandir_subdir_acpi --- >>>> A failure has been detected in another branch of the parallel make >>>>>>> Kernel build for OZZIE started on Thu Sep 18 04:35:18 CDT 2014 >>>> -------------------------------------------------------------- >>>> ===> OZZIE >>>> mkdir -p /usr/obj/usr/src/sys >>>> -------------------------------------------------------------- >>>>>>> stage 1: configuring the kernel >>>> -------------------------------------------------------------- >>>> cd /usr/src/sys/amd64/conf; >>>> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin >>>> >>>> config -d /usr/obj/usr/src/sys/OZZIE -I '/usr/src/sys/amd64/conf' >>>> '/usr/src/sys/amd64/conf/OZZIE' >>>> Kernel build directory is /usr/obj/usr/src/sys/OZZIE >>>> Don't forget to do ``make cleandepend && make depend'' >>>> -------------------------------------------------------------- >>>>>>> stage 2.1: cleaning up the object tree >>>> -------------------------------------------------------------- >>>> cd /usr/obj/usr/src/sys/OZZIE; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 >>>> MACHINE=amd64 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin >>>> GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font >>>> GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac >>>> _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp _LDSCRIPTROOT= VERSION="FreeBSD >>>> 10.1-BETA1 amd64 1000716" INSTALL="sh /usr/src/tools/install.sh" >>>> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin >>>> >>>> CC="cc " CXX="c++ " CPP="cpp " AS="as" AR="ar" LD="ld" NM=nm OBJDUMP= >>>> RANLIB=ranlib STRINGS= COMPILER_TYPE=clang make -j 4 -J 15,16 -m >>>> /usr/src/share/mk KERNEL=kernel cleandir >>>> --- kernel-clean --- >>>> --- kernel-cleandepend --- >>>> --- modules-cleandir --- >>>> --- kernel-cleandepend --- >>>> rm -f .depend machine x86 >>>> --- kernel-clean --- >>>> rm -f *.o *.so *.So *.ko *.s eddep errs kernel.debug kernel kernel.symbols >>>> linterrs tags vers.c vnode_if.c vnode_if.h vnode_if_newproto.h >>>> vnode_if_typedef.h agp_if.c ata_if.c eisa_if.c fb_if.c miibus_if.c mmcbr_if.c >>>> mmcbus_if.c mvs_if.c card_if.c power_if.c pci_if.c pcib_if.c ppbus_if.c >>>> sdhci_if.c hdac_if.c ac97_if.c channel_if.c feeder_if.c mixer_if.c mpu_if.c >>>> mpufoi_if.c synth_if.c uart_if.c usb_if.c g_part_if.c g_raid_md_if.c >>>> g_raid_tr_if.c isa_if.c bus_if.c clock_if.c cpufreq_if.c device_if.c >>>> linker_if.c serdev_if.c xenbus_if.c xenbusb_if.c acpi_if.c acpi_wmi_if.c >>>> virtio_bus_if.c virtio_if.c agp_if.h ata_if.h eisa_if.h fb_if.h miibus_if.h >>>> mmcbr_if.h mmcbus_if.h mvs_if.h card_if.h power_if.h pci_if.h pcib_if.h >>>> ppbus_if.h sdhci_if.h hdac_if.h ac97_if.h channel_if.h feeder_if.h mixer_if.h >>>> mpu_if.h mpufoi_if.h synth_if.h uart_if.h usb_if.h g_part_if.h g_raid_md_if.h >>>> g_raid_tr_if.h isa_if.h bus_if.h clock_if.h cpufreq_if.h device_if.h >>>> linker_if.h serdev_if.h xenbus_if.h xenbusb_if.h acpi_if.h acpi_wmi_if.h >>>> virtio_bus_if.h virtio_if.h acpi_quirks.h feeder_eq_gen.h feeder_rate_gen.h >>>> snd_fxdiv_gen.h miidevs.h pccarddevs.h teken_state.h usbdevs.h usbdevs_data.h >>>> ia32_genassym.o ia32_assym.h acpi_wakecode.o acpi_wakecode.bin >>>> acpi_wakecode.h acpi_wakedata.h >>>> --- modules-cleandir --- >>>> cd /usr/src/sys/modules; MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/OZZIE/modules >>>> KMODDIR=/boot/kernel MACHINE_CPUARCH=amd64 DEBUG_FLAGS="-g" MACHINE=amd64 >>>> KERNBUILDDIR="/usr/obj/usr/src/sys/OZZIE" SYSDIR="/usr/src/sys" WITH_CTF="1" >>>> make cleandir >>>> --- cleandir_subdir_aac --- >>>> --- cleandir_subdir_aacraid --- >>>> --- cleandir_subdir_accf_data --- >>>> --- cleandir_subdir_accf_dns --- >>>> --- cleandir_subdir_aac --- >>>> ===> aac (cleandir) >>>> --- cleandir_subdir_aacraid --- >>>> ===> aacraid (cleandir) >>>> --- cleandir_subdir_accf_data --- >>>> ===> accf_data (cleandir) >>>> --- cleandir_subdir_accf_dns --- >>>> ===> accf_dns (cleandir) >>>> --- cleandir_subdir_accf_data --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_accf_dns --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_aacraid --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_aac --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_accf_http --- >>>> --- cleandir_subdir_acl_nfs4 --- >>>> --- cleandir_subdir_accf_http --- >>>> ===> accf_http (cleandir) >>>> --- cleandir_subdir_acl_nfs4 --- >>>> ===> acl_nfs4 (cleandir) >>>> --- cleandir_subdir_acl_posix1e --- >>>> --- cleandir_subdir_acpi --- >>>> --- cleandir_subdir_acl_posix1e --- >>>> ===> acl_posix1e (cleandir) >>>> --- cleandir_subdir_acpi --- >>>> ===> acpi (cleandir) >>>> --- cleandir_subdir_accf_http --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acl_nfs4 --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> --- _sub.cleandir --- >>>> ===> acpi/acpi_asus (cleandir) >>>> --- cleandir_subdir_ae --- >>>> ===> ae (cleandir) >>>> --- cleandir_subdir_aesni --- >>>> ===> aesni (cleandir) >>>> --- cleandir_subdir_acl_posix1e --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_age --- >>>> ===> age (cleandir) >>>> --- cleandir_subdir_aesni --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_ae --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> ===> acpi/acpi_asus_wmi (cleandir) >>>> --- cleandir_subdir_age --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_agp --- >>>> --- cleandir_subdir_aha --- >>>> --- cleandir_subdir_agp --- >>>> ===> agp (cleandir) >>>> --- cleandir_subdir_aha --- >>>> ===> aha (cleandir) >>>> --- cleanobj --- >>>> --- cleandir_subdir_ahci --- >>>> ===> ahci (cleandir) >>>> --- cleandir_subdir_aic7xxx --- >>>> ===> aic7xxx (cleandir) >>>> --- cleandir_subdir_ahci --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_agp --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> ===> acpi/acpi_fujitsu (cleandir) >>>> --- cleandir_subdir_aic7xxx --- >>>> --- _sub.cleandir --- >>>> ===> aic7xxx/ahc (cleandir) >>>> --- cleandir_subdir_aio --- >>>> ===> aio (cleandir) >>>> --- cleandir_subdir_acpi --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_aic7xxx --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_alc --- >>>> ===> alc (cleandir) >>>> --- cleandir_subdir_aio --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> ===> acpi/acpi_hp (cleandir) >>>> --- cleandir_subdir_alc --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_aic7xxx --- >>>> --- _sub.cleandir --- >>>> ===> aic7xxx/ahc/ahc_eisa (cleandir) >>>> --- clean --- >>>> rm -f export_syms ahc_eisa.ko ahc_eisa.kld ahc_eisa.o ahc_eisa.ko.debug >>>> ahc_eisa.ko.symbols opt_scsi.h opt_cam.h opt_aic7xxx.h eisa_if.h pci_if.h >>>> bus_if.h device_if.h >>>> --- cleanilinks --- >>>> rm -f @ machine x86 >>>> --- cleandepend --- >>>> rm -f .depend GPATH GRTAGS GSYMS GTAGS >>>> --- cleanobj --- >>>> ===> aic7xxx/ahc/ahc_isa (cleandir) >>>> --- cleanobj --- >>>> ===> aic7xxx/ahc/ahc_pci (cleandir) >>>> --- cleandir_subdir_acpi --- >>>> ===> acpi/acpi_ibm (cleandir) >>>> --- cleandir_subdir_ale --- >>>> ===> ale (cleandir) >>>> --- cleandir_subdir_aic7xxx --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_alq --- >>>> ===> alq (cleandir) >>>> --- cleandir_subdir_aic7xxx --- >>>> --- cleanobj --- >>>> rm: fts_read: No such file or directory >>>> *** [cleanobj] Error code 1 >>>> >>>> make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc >>>> 1 error >>>> >>>> make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc >>>> *** [_sub.cleandir] Error code 2 >>>> >>>> make[4]: stopped in /usr/src/sys/modules/aic7xxx >>>> 1 error >>>> >>>> make[4]: stopped in /usr/src/sys/modules/aic7xxx >>>> *** [cleandir_subdir_aic7xxx] Error code 2 >>>> >>>> make[3]: stopped in /usr/src/sys/modules >>>> --- cleandir_subdir_alq --- >>>> A failure has been detected in another branch of the parallel make >>>> >>>> make[4]: stopped in /usr/src/sys/modules/alq >>>> --- cleandir_subdir_ale --- >>>> A failure has been detected in another branch of the parallel make >>>> >>>> make[4]: stopped in /usr/src/sys/modules/ale >>>> --- cleandir_subdir_alq --- >>>> *** [cleandir_subdir_alq] Error code 2 >>>> >>>> make[3]: stopped in /usr/src/sys/modules >>>> --- cleandir_subdir_acpi --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_ale --- >>>> *** [cleandir_subdir_ale] Error code 2 >>>> >>>> make[3]: stopped in /usr/src/sys/modules >>>> --- cleandir_subdir_acpi --- >>>> A failure has been detected in another branch of the parallel make >>>> >>>> make[5]: stopped in /usr/src/sys/modules/acpi/acpi_ibm >>>> *** [_sub.cleandir] Error code 2 >>>> >>>> make[4]: stopped in /usr/src/sys/modules/acpi >>>> 1 error >>>> >>>> make[4]: stopped in /usr/src/sys/modules/acpi >>>> *** [cleandir_subdir_acpi] Error code 2 >>>> >>>> make[3]: stopped in /usr/src/sys/modules >>>> 4 errors >>>> >>>> make[3]: stopped in /usr/src/sys/modules >>>> *** [modules-cleandir] Error code 2 >>>> >>>> make[2]: stopped in /usr/obj/usr/src/sys/OZZIE >>>> 1 error >>>> >>>> make[2]: stopped in /usr/obj/usr/src/sys/OZZIE >>>> *** [buildkernel] Error code 2 >>>> >>>> make[1]: stopped in /usr/src >>>> 1 error >>>> >>>> make[1]: stopped in /usr/src >>>> *** [buildkernel] Error code 2 >>>> >>>> make: stopped in /usr/src >>>> 1 error >>>> >>>> make: stopped in /usr/src >>>> >>>> make[5]: stopped in /usr/src/sys/modules/acpi/acpi_ibm >>>> *** [_sub.cleandir] Error code 2 >>>> >>>> make[4]: stopped in /usr/src/sys/modules/acpi >>>> 1 error >>>> >>>> make[4]: stopped in /usr/src/sys/modules/acpi >>>> *** [cleandir_subdir_acpi] Error code 2 >>>> >>>> make[3]: stopped in /usr/src/sys/modules >>>> 4 errors >>>> >>>> make[3]: stopped in /usr/src/sys/modules >>>> *** [modules-cleandir] Error code 2 >>>> >>>> make[2]: stopped in /usr/obj/usr/src/sys/OZZIE >>>> 1 error >>>> >>>> make[2]: stopped in /usr/obj/usr/src/sys/OZZIE >>>> *** [buildkernel] Error code 2 >>>> >>>> make[1]: stopped in /usr/src >>>> 1 error >>>> >>>> make[1]: stopped in /usr/src >>>> *** [buildkernel] Error code 2 >>>> >>>> make: stopped in /usr/src >>>> 1 error >>>> >>>> make: stopped in /usr/src >>>> >>>> *** [cleandir_subdir_ale] Error code 2 >>>> >>>> make[3]: stopped in /usr/src/sys/modules >>>> --- cleandir_subdir_acpi --- >>>> A failure has been detected in another branch of the parallel make >>>> >>>> make[5]: stopped in /usr/src/sys/modules/acpi/acpi_ibm >>>> *** [_sub.cleandir] Error code 2 >>>> >>>> make[4]: stopped in /usr/src/sys/modules/acpi >>>> 1 error >>>> >>>> make[4]: stopped in /usr/src/sys/modules/acpi >>>> *** [cleandir_subdir_acpi] Error code 2 >>>> >>>> make[3]: stopped in /usr/src/sys/modules >>>> 4 errors >>>> >>>> make[3]: stopped in /usr/src/sys/modules >>>> *** [modules-cleandir] Error code 2 >>>> >>>> make[2]: stopped in /usr/obj/usr/src/sys/MYFINEHOST >>>> 1 error >>>> >>>> make[2]: stopped in /usr/obj/usr/src/sys/MYFINEHOST >>>> *** [buildkernel] Error code 2 >>>> >>>> make[1]: stopped in /usr/src >>>> 1 error >>>> >>>> make[1]: stopped in /usr/src >>>> *** [buildkernel] Error code 2 >>>> >>>> make: stopped in /usr/src >>>> 1 error >>>> >>>> make: stopped in /usr/src >>>> >>>> -- >>>> ---------------------------------------------------------------------------- >>>> Tim Daneliuk tundra@tundraware.com >>>> PGP Key: http://www.tundraware.com/PGP/ >>>> >>>> _______________________________________________ >>>> freebsd-stable@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >>>> >>> >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> >> -- >> ---------------------------------------------------------------------------- >> Tim Daneliuk tundra@tundraware.com >> PGP Key: http://www.tundraware.com/PGP/ >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/ From owner-freebsd-stable@FreeBSD.ORG Fri Sep 19 08:50:59 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5971C196; Fri, 19 Sep 2014 08:50:59 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 1C222E06; Fri, 19 Sep 2014 08:50:58 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 14C1720E7088F; Fri, 19 Sep 2014 08:50:58 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: * X-Spam-Status: No, score=2.0 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,RDNS_DYNAMIC autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id B0A5B20E7088A; Fri, 19 Sep 2014 08:50:54 +0000 (UTC) Message-ID: <9E5B7FEE1D0C4ED59757220997CA7D9A@multiplay.co.uk> From: "Steven Hartland" To: "Tim Daneliuk" , "FreeBSD Stable" , "John Baldwin" References: <541B6167.3000703@tundraware.com> <541B6A6F.5010501@tundraware.com> <62E5543C34E048D5B454CD795ACAC495@multiplay.co.uk> <541B7336.9070401@tundraware.com> Subject: Re: 10.1Beta - Ongoing Build Problems Date: Fri, 19 Sep 2014 09:50:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 08:50:59 -0000 ----- Original Message ----- From: "Tim Daneliuk" > On 09/18/2014 06:36 PM, Steven Hartland wrote: >> I just noticed your error was >> >> rm: fts_read: No such file or directory >> >> This is a know issue with rewinddir. >> >> I believe the fix is: >> http://svnweb.freebsd.org/changeset/base/271048 >> >> Which was MFC'ed by: >> http://svnweb.freebsd.org/changeset/base/271263 >> >> So your build machine will need to be running r271263 or later. > > Hmmm I am at: 10.1-PRERELEASE #27 r271419 John are there any outstanding issues with the rewind fix that you know of or should it all be fixed? Tim can you double check that you see the following change in your source tree: https://svnweb.freebsd.org/base/head/lib/libc/gen/rewinddir.c?r1=271048&r2=271047&pathrev=271048 Regards Steve From owner-freebsd-stable@FreeBSD.ORG Fri Sep 19 08:53:14 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC56632C for ; Fri, 19 Sep 2014 08:53:14 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 909D5EF3 for ; Fri, 19 Sep 2014 08:53:14 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id C018B20E7088F; Fri, 19 Sep 2014 08:53:13 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.2 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,RDNS_DYNAMIC,STOX_REPLY_TYPE autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 4589F20E7088A; Fri, 19 Sep 2014 08:53:11 +0000 (UTC) Message-ID: <362BC551B1534C3D87CDB842C822DB5A@multiplay.co.uk> From: "Steven Hartland" To: "John Marshall" , References: <20140918235130.GA3070@rwpc15.gfn.riverwillow.net.au> Subject: Re: MFC missing for mfiutil(8) in 10-STABLE Date: Fri, 19 Sep 2014 09:53:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 08:53:14 -0000 Can't see any reason that can't be MFC'ed if on one picks it up before hand I'll have a look tonight. ----- Original Message ----- From: "John Marshall" I'm wondering if this is a simple case of a forgotten MFC? ------------------------------------------------------------------------ r257820 | sbruno | 2013-11-08 08:47:59 +1100 (Fri, 08 Nov 2013) | 8 lines Changed paths: M /head/usr.sbin/mfiutil/Makefile A /head/usr.sbin/mfiutil/mfi_properties.c M /head/usr.sbin/mfiutil/mfiutil.8 M /head/usr.sbin/mfiutil/mfiutil.c Add support for controlling mfi(4) controller properties: allow user control of rebuild rate allow user control of silence/enable alarm MFC after: 2 weeks Sponsored by: Yahoo! Inc. ------------------------------------------------------------------------ Since the beginning of this year I have been applying this merge to 9.2-RELEASE, 9.3-RELEASE and 10-STABLE on an Intel server with the following hardware: mfi0@pci0:6:0:0: class=0x010400 card=0x92618086 chip=0x00791000 rev=0x05 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = 'MegaRAID SAS 2108 [Liberator]' class = mass storage subclass = RAID I'm wondering if this might be MFC'd before releng/10.1 is branched? It is a real bonus being able to silence the controller's audible alarm without having to shutdown FreeBSD! -- John Marshall From owner-freebsd-stable@FreeBSD.ORG Fri Sep 19 13:16:45 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D8E24FF; Fri, 19 Sep 2014 13:16:45 +0000 (UTC) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ozzie.tundraware.com", Issuer "ozzie.tundraware.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F56910F; Fri, 19 Sep 2014 13:16:44 +0000 (UTC) Received: from [192.168.0.2] (viper.tundraware.com [192.168.0.2]) (authenticated bits=0) by ozzie.tundraware.com (8.14.9/8.14.9) with ESMTP id s8JDGYm8097603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 19 Sep 2014 08:16:34 -0500 (CDT) (envelope-from tundra@tundraware.com) Message-ID: <541C2CB2.7070007@tundraware.com> Date: Fri, 19 Sep 2014 08:16:34 -0500 From: Tim Daneliuk User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Steven Hartland , FreeBSD Stable , John Baldwin Subject: Re: 10.1Beta - Ongoing Build Problems References: <541B6167.3000703@tundraware.com> <541B6A6F.5010501@tundraware.com> <62E5543C34E048D5B454CD795ACAC495@multiplay.co.uk> <541B7336.9070401@tundraware.com> <9E5B7FEE1D0C4ED59757220997CA7D9A@multiplay.co.uk> In-Reply-To: <9E5B7FEE1D0C4ED59757220997CA7D9A@multiplay.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (ozzie.tundraware.com [75.145.138.73]); Fri, 19 Sep 2014 08:16:34 -0500 (CDT) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: s8JDGYm8097603 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 13:16:45 -0000 On 09/19/2014 03:50 AM, Steven Hartland wrote: > ----- Original Message ----- From: "Tim Daneliuk" > > >> On 09/18/2014 06:36 PM, Steven Hartland wrote: >>> I just noticed your error was >>> >>> rm: fts_read: No such file or directory >>> >>> This is a know issue with rewinddir. >>> >>> I believe the fix is: >>> http://svnweb.freebsd.org/changeset/base/271048 >>> >>> Which was MFC'ed by: >>> http://svnweb.freebsd.org/changeset/base/271263 >>> >>> So your build machine will need to be running r271263 or later. >> >> Hmmm I am at: 10.1-PRERELEASE #27 r271419 > > John are there any outstanding issues with the rewind fix > that you know of or should it all be fixed? > > Tim can you double check that you see the following change > in your source tree: > https://svnweb.freebsd.org/base/head/lib/libc/gen/rewinddir.c?r1=271048&r2=271047&pathrev=271048 > > > Regards > Steve Interestingly, I did a recompile with no parallelization and got to this: FreeBSD 10.1-BETA1 #5 r271742 When the nightly build job ran later (that has a -j4 in the make line) it ran fine to completion. Perhaps I just needed to get to a slightly new rev? Anyway, I'll keep an eye on this and let you know if I see this issue again. Thanks, -- ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/ From owner-freebsd-stable@FreeBSD.ORG Fri Sep 19 14:01:06 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 37644115 for ; Fri, 19 Sep 2014 14:01:06 +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 0DD6D7DD for ; Fri, 19 Sep 2014 14:01:06 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 84776B946; Fri, 19 Sep 2014 10:01:04 -0400 (EDT) From: John Baldwin To: Steven Hartland Subject: Re: 10.1Beta - Ongoing Build Problems Date: Fri, 19 Sep 2014 10:00:31 -0400 Message-ID: <2072426.zA4beYHhHD@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: <9E5B7FEE1D0C4ED59757220997CA7D9A@multiplay.co.uk> References: <541B6167.3000703@tundraware.com> <541B7336.9070401@tundraware.com> <9E5B7FEE1D0C4ED59757220997CA7D9A@multiplay.co.uk> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 19 Sep 2014 10:01:04 -0400 (EDT) Cc: Tim Daneliuk , FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 14:01:06 -0000 On Friday, September 19, 2014 09:50:54 AM Steven Hartland wrote: > ----- Original Message ----- > From: "Tim Daneliuk" > > > On 09/18/2014 06:36 PM, Steven Hartland wrote: > >> I just noticed your error was > >> > >> rm: fts_read: No such file or directory > >> > >> This is a know issue with rewinddir. > >> > >> I believe the fix is: > >> http://svnweb.freebsd.org/changeset/base/271048 > >> > >> Which was MFC'ed by: > >> http://svnweb.freebsd.org/changeset/base/271263 > >> > >> So your build machine will need to be running r271263 or later. > > > > Hmmm I am at: 10.1-PRERELEASE #27 r271419 > > John are there any outstanding issues with the rewind fix > that you know of or should it all be fixed? It should all be fixed by 271263. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Sep 19 14:46:53 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E2572C5A for ; Fri, 19 Sep 2014 14:46:53 +0000 (UTC) Received: from list.sco.com (list.sco.com [69.36.163.214]) by mx1.freebsd.org (Postfix) with SMTP id B83B9CC4 for ; Fri, 19 Sep 2014 14:46:53 +0000 (UTC) Received: (qmail 5353 invoked from network); 19 Sep 2014 14:40:11 -0000 Received: from nimbus.nj.sco.com (69.36.163.214) by tasmania.ut.sco.com with SMTP; 19 Sep 2014 14:40:11 -0000 Received: from [127.0.0.1] (host12.nj.vpn.unxisco.com [10.147.73.12]) by nimbus.nj.sco.com (8.12.9/UW7.1.3) with ESMTP id s8JEe5U1013131; Fri, 19 Sep 2014 10:40:09 -0400 (EDT) Message-ID: <541C403F.40705@xinuos.com> Date: Fri, 19 Sep 2014 10:39:59 -0400 From: John Wolfe User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Baldwin , Steven Hartland Subject: Re: 10.1Beta - Ongoing Build Problems References: <541B6167.3000703@tundraware.com> <541B7336.9070401@tundraware.com> <9E5B7FEE1D0C4ED59757220997CA7D9A@multiplay.co.uk> <2072426.zA4beYHhHD@ralph.baldwin.cx> In-Reply-To: <2072426.zA4beYHhHD@ralph.baldwin.cx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tim Daneliuk , FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 14:46:54 -0000 I too have noticed that identical but intermittent build problem and just this week the Jenkins 10/STABLE build hit the same failure (again). Just to clarify what is being said in this e-mail thread, a build of 10/STABLE on a FreeBSD 10 (release) kernel may encounter this intermittent failures. Only a running kernel at r271263 or later should NOT encounter the failure; the fix must be in the running kernel, not just in the source code being built. Just wondering if everyone is looking at the issue from the same perspective. -- John On 9/19/2014 10:00 AM, John Baldwin wrote: > On Friday, September 19, 2014 09:50:54 AM Steven Hartland wrote: >> ----- Original Message ----- >> From: "Tim Daneliuk" >> >>> On 09/18/2014 06:36 PM, Steven Hartland wrote: >>>> I just noticed your error was >>>> >>>> rm: fts_read: No such file or directory >>>> >>>> This is a know issue with rewinddir. >>>> >>>> I believe the fix is: >>>> http://svnweb.freebsd.org/changeset/base/271048 >>>> >>>> Which was MFC'ed by: >>>> http://svnweb.freebsd.org/changeset/base/271263 >>>> >>>> So your build machine will need to be running r271263 or later. >>> Hmmm I am at: 10.1-PRERELEASE #27 r271419 >> John are there any outstanding issues with the rewind fix >> that you know of or should it all be fixed? > It should all be fixed by 271263. > From owner-freebsd-stable@FreeBSD.ORG Fri Sep 19 14:52:37 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3FCAFF7F; Fri, 19 Sep 2014 14:52:37 +0000 (UTC) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ozzie.tundraware.com", Issuer "ozzie.tundraware.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DC7EEDD6; Fri, 19 Sep 2014 14:52:36 +0000 (UTC) Received: from www.tundraware.com (localhost [127.0.0.1]) by ozzie.tundraware.com (8.14.9/8.14.9) with ESMTP id s8JEqP0K016632; Fri, 19 Sep 2014 09:52:25 -0500 (CDT) (envelope-from tundra@tundraware.com) Received: from 192.168.0.2 (SquirrelMail authenticated user tundra) by www.tundraware.com with HTTP; Fri, 19 Sep 2014 09:52:26 -0500 Message-ID: In-Reply-To: <541C403F.40705@xinuos.com> References: <541B6167.3000703@tundraware.com> <541B7336.9070401@tundraware.com> <9E5B7FEE1D0C4ED59757220997CA7D9A@multiplay.co.uk> <2072426.zA4beYHhHD@ralph.baldwin.cx> <541C403F.40705@xinuos.com> Date: Fri, 19 Sep 2014 09:52:26 -0500 Subject: Re: 10.1Beta - Ongoing Build Problems From: "Tim Daneliuk" To: "John Wolfe" Reply-To: tundra@tundraware.com User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (ozzie.tundraware.com [127.0.0.1]); Fri, 19 Sep 2014 09:52:26 -0500 (CDT) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: s8JEqP0K016632 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No Cc: FreeBSD Stable , Steven Hartland , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 14:52:37 -0000 On Fri, September 19, 2014 9:39 am, John Wolfe wrote: > I too have noticed that identical but intermittent build problem and > just this week the Jenkins 10/STABLE build hit the same failure (again). > > Just to clarify what is being said in this e-mail thread, a build of > 10/STABLE on a FreeBSD 10 (release) kernel may encounter this > intermittent failures. Only a running kernel at r271263 or later > should NOT encounter the failure; the fix must be in the running kernel, > not just in the source code being built. > > Just wondering if everyone is looking at the issue from the same > perspective. > > -- John I am still seeing it after installing this SVN rev for both world and kernel: FreeBSD 10.1-BETA2 #0 r271853: > > On 9/19/2014 10:00 AM, John Baldwin wrote: >> On Friday, September 19, 2014 09:50:54 AM Steven Hartland wrote: >>> ----- Original Message ----- >>> From: "Tim Daneliuk" >>> >>>> On 09/18/2014 06:36 PM, Steven Hartland wrote: >>>>> I just noticed your error was >>>>> >>>>> rm: fts_read: No such file or directory >>>>> >>>>> This is a know issue with rewinddir. >>>>> >>>>> I believe the fix is: >>>>> http://svnweb.freebsd.org/changeset/base/271048 >>>>> >>>>> Which was MFC'ed by: >>>>> http://svnweb.freebsd.org/changeset/base/271263 >>>>> >>>>> So your build machine will need to be running r271263 or later. >>>> Hmmm I am at: 10.1-PRERELEASE #27 r271419 >>> John are there any outstanding issues with the rewind fix >>> that you know of or should it all be fixed? >> It should all be fixed by 271263. >> > > > -- Tim Daneliuk tundra@tundraware.com From owner-freebsd-stable@FreeBSD.ORG Fri Sep 19 14:58:15 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B19F295; Fri, 19 Sep 2014 14:58:15 +0000 (UTC) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e: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 56035E3B; Fri, 19 Sep 2014 14:58:15 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id et14so262012pad.1 for ; Fri, 19 Sep 2014 07:58:14 -0700 (PDT) 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=WZsoa9NkSOJC3WJuT7jRPFdhnL//s6hQK+j0aXQt7tc=; b=AdX12qlIYtsVAV3jQSZiUmf91lF241fNIDk2FZiXvLs7pVa+QwQtF4R41hQtzqBJtj +EMAW/Yw+Keo12pkXlByPA05PTb0t7XxV74+VZKZhBbv+q4ssoKq0x/Gzp2F3C5q9E+f HG4OaSTzky6geZhsjXQkabyQw+sbjct11YkyHOL9je+TvTtfu31jyVCyT91syAuAhNJp t505fAozpl9n4hh0/gMr0pzITye3heLQL9dyC2BuphswJXRi4sLMIFPe5LMQP/WWetT3 Hya4T15nEk8PTn+BQCH8fMLtVHj2YwK2xD6BEXJSDZKC+s92OY6YiTConF0LLCMAY9H2 UQmw== X-Received: by 10.66.182.227 with SMTP id eh3mr2526944pac.68.1411138694519; Fri, 19 Sep 2014 07:58:14 -0700 (PDT) Received: from ox ([24.6.44.228]) by mx.google.com with ESMTPSA id qy1sm2125448pbc.27.2014.09.19.07.58.12 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 19 Sep 2014 07:58:13 -0700 (PDT) Date: Fri, 19 Sep 2014 07:58:08 -0700 From: Navdeep Parhar To: John Wolfe Subject: Re: 10.1Beta - Ongoing Build Problems Message-ID: <20140919145808.GA23707@ox> Mail-Followup-To: John Wolfe , John Baldwin , Steven Hartland , Tim Daneliuk , FreeBSD Stable References: <541B6167.3000703@tundraware.com> <541B7336.9070401@tundraware.com> <9E5B7FEE1D0C4ED59757220997CA7D9A@multiplay.co.uk> <2072426.zA4beYHhHD@ralph.baldwin.cx> <541C403F.40705@xinuos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <541C403F.40705@xinuos.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Stable , Tim Daneliuk , Steven Hartland , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 14:58:15 -0000 If the rm that runs during "make clean" has r268376 then it shouldn't error on fts_read. That fixed all of the fts_read errors that I used to get while building head with large -j values. I'm not sure if the fix is in stable/10. https://lists.freebsd.org/pipermail/svn-src-head/2014-July/060201.html Regards, Navdeep On Fri, Sep 19, 2014 at 10:39:59AM -0400, John Wolfe wrote: > I too have noticed that identical but intermittent build problem > and just this week the Jenkins 10/STABLE build hit the same failure > (again). > > Just to clarify what is being said in this e-mail thread, a build of > 10/STABLE on a FreeBSD 10 (release) kernel may encounter this > intermittent failures. Only a running kernel at r271263 or later > should NOT encounter the failure; the fix must be in the running > kernel, not just in the source code being built. > > Just wondering if everyone is looking at the issue from the same > perspective. > > -- John > > On 9/19/2014 10:00 AM, John Baldwin wrote: > >On Friday, September 19, 2014 09:50:54 AM Steven Hartland wrote: > >>----- Original Message ----- > >>From: "Tim Daneliuk" > >> > >>>On 09/18/2014 06:36 PM, Steven Hartland wrote: > >>>>I just noticed your error was > >>>> > >>>>rm: fts_read: No such file or directory > >>>> > >>>>This is a know issue with rewinddir. > >>>> > >>>>I believe the fix is: > >>>>http://svnweb.freebsd.org/changeset/base/271048 > >>>> > >>>>Which was MFC'ed by: > >>>>http://svnweb.freebsd.org/changeset/base/271263 > >>>> > >>>>So your build machine will need to be running r271263 or later. > >>>Hmmm I am at: 10.1-PRERELEASE #27 r271419 > >>John are there any outstanding issues with the rewind fix > >>that you know of or should it all be fixed? > >It should all be fixed by 271263. > > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Fri Sep 19 15:05:13 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2AA45530; Fri, 19 Sep 2014 15:05:13 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id E02DDF33; Fri, 19 Sep 2014 15:05:12 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id DFF4D20E7088F; Fri, 19 Sep 2014 15:05:10 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.2 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,RDNS_DYNAMIC,STOX_REPLY_TYPE autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 552B420E7088A; Fri, 19 Sep 2014 15:05:09 +0000 (UTC) Message-ID: From: "Steven Hartland" To: "Navdeep Parhar" , "John Wolfe" References: <541B6167.3000703@tundraware.com> <541B7336.9070401@tundraware.com> <9E5B7FEE1D0C4ED59757220997CA7D9A@multiplay.co.uk> <2072426.zA4beYHhHD@ralph.baldwin.cx> <541C403F.40705@xinuos.com> <20140919145808.GA23707@ox> Subject: Re: 10.1Beta - Ongoing Build Problems Date: Fri, 19 Sep 2014 16:05:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: Tim Daneliuk , FreeBSD Stable , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 15:05:13 -0000 ----- Original Message ----- From: "Navdeep Parhar" > If the rm that runs during "make clean" has r268376 then it shouldn't > error on fts_read. That fixed all of the fts_read errors that I used to > get while building head with large -j values. I'm not sure if the fix > is in stable/10. > > https://lists.freebsd.org/pipermail/svn-src-head/2014-July/060201.html Thanks Navdeep, I see no mention of that being MFC'ed to stable/10 as yet. Tim if you manually apply the following to your stable/10 tree and install it do the failures stop? https://svnweb.freebsd.org/base/head/bin/rm/rm.c?view=patch&r1=268376&r2=268375&pathrev=268376 Regards Steve From owner-freebsd-stable@FreeBSD.ORG Fri Sep 19 15:41:25 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 37C31D5F for ; Fri, 19 Sep 2014 15:41:25 +0000 (UTC) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ozzie.tundraware.com", Issuer "ozzie.tundraware.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F36F15E7 for ; Fri, 19 Sep 2014 15:41:24 +0000 (UTC) Received: from [192.168.0.2] (viper.tundraware.com [192.168.0.2]) (authenticated bits=0) by ozzie.tundraware.com (8.14.9/8.14.9) with ESMTP id s8JFf6B5004074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 19 Sep 2014 10:41:15 -0500 (CDT) (envelope-from tundra@tundraware.com) Message-ID: <541B71E5.9000505@tundraware.com> Date: Thu, 18 Sep 2014 18:59:33 -0500 From: Tim Daneliuk User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Steven Hartland , FreeBSD Stable Subject: Re: 10.1Beta - Ongoing Build Problems References: <541B6167.3000703@tundraware.com> <541B6A6F.5010501@tundraware.com> <62E5543C34E048D5B454CD795ACAC495@multiplay.co.uk> In-Reply-To: <62E5543C34E048D5B454CD795ACAC495@multiplay.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (ozzie.tundraware.com [75.145.138.73]); Fri, 19 Sep 2014 10:41:15 -0500 (CDT) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: s8JFf6B5004074 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 15:41:25 -0000 On 09/18/2014 06:36 PM, Steven Hartland wrote: > I just noticed your error was > > rm: fts_read: No such file or directory > > This is a know issue with rewinddir. > > I believe the fix is: > http://svnweb.freebsd.org/changeset/base/271048 > > Which was MFC'ed by: > http://svnweb.freebsd.org/changeset/base/271263 > > So your build machine will need to be running r271263 or later. > > Regards > Steve Well ... I am at 10.1-PRERELEASE #27 r271419 and seeing the problem. > > ----- Original Message ----- From: "Tim Daneliuk" > To: "Steven Hartland" ; "FreeBSD Stable" > > Sent: Friday, September 19, 2014 12:27 AM > Subject: Re: 10.1Beta - Ongoing Build Problems > > >> On 09/18/2014 06:06 PM, Steven Hartland wrote: >>> IIRC this can happen if your building on a box which is too old. >>> >>> I've been doing loads of stable/10 builds recently with -j24 and >>> only had an issue a while back, updating the world on the box >>> in question (using no -j) fixed it for me. >>> >>> Regards >>> Steve >> >> The hardware is pretty new and the OS was updated within the last several >> weeks to the then -STABLE branch. I've been seeing this on- and off >> for a while. >> >> >> >>> >>> ----- Original Message ----- From: "Tim Daneliuk" >>> To: "FreeBSD Stable" >>> Sent: Thursday, September 18, 2014 11:49 PM >>> Subject: 10.1Beta - Ongoing Build Problems >>> >>> >>>> I continue to see problems as seen below if I attempt a parallel make. >>>> If I remove the '-j4' from my build script, this build completes fine, >>>> albeit much more slowly. Ideas anyone??: >>>> >>>> >>>>>>> Kernel build for MYFINEHOST started on Thu Sep 18 04:35:18 CDT 2014 >>>> -------------------------------------------------------------- >>>> ===> MYFINEHOST >>>> mkdir -p /usr/obj/usr/src/sys >>>> -------------------------------------------------------------- >>>>>>> stage 1: configuring the kernel >>>> -------------------------------------------------------------- >>>> cd /usr/src/sys/amd64/conf; >>>> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin >>>> >>>> config -d /usr/obj/usr/src/sys/MYFINEHOST -I '/usr/src/sys/amd64/conf' >>>> '/usr/src/sys/amd64/conf/MYFINEHOST' >>>> Kernel build directory is /usr/obj/usr/src/sys/MYFINEHOST >>>> Don't forget to do ``make cleandepend && make depend'' >>>> -------------------------------------------------------------- >>>>>>> stage 2.1: cleaning up the object tree >>>> -------------------------------------------------------------- >>>> cd /usr/obj/usr/src/sys/MYFINEHOST; MAKEOBJDIRPREFIX=/usr/obj >>>> MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= >>>> GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin >>>> GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font >>>> GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac >>>> _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp _LDSCRIPTROOT= VERSION="FreeBSD >>>> 10.1-BETA1 amd64 1000716" INSTALL="sh /usr/src/tools/install.sh" >>>> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin >>>> >>>> CC="cc " CXX="c++ " CPP="cpp " AS="as" AR="ar" LD="ld" NM=nm OBJDUMP= >>>> RANLIB=ranlib STRINGS= COMPILER_TYPE=clang make -j 4 -J 15,16 -m >>>> /usr/src/share/mk KERNEL=kernel cleandir >>>> --- kernel-clean --- >>>> --- kernel-cleandepend --- >>>> --- modules-cleandir --- >>>> --- kernel-cleandepend --- >>>> rm -f .depend machine x86 >>>> --- kernel-clean --- >>>> rm -f *.o *.so *.So *.ko *.s eddep errs kernel.debug kernel kernel.symbols >>>> linterrs tags vers.c vnode_if.c vnode_if.h vnode_if_newproto.h >>>> vnode_if_typedef.h agp_if.c ata_if.c eisa_if.c fb_if.c miibus_if.c mmcbr_if.c >>>> mmcbus_if.c mvs_if.c card_if.c power_if.c pci_if.c pcib_if.c ppbus_if.c >>>> sdhci_if.c hdac_if.c ac97_if.c channel_if.c feeder_if.c mixer_if.c mpu_if.c >>>> mpufoi_if.c synth_if.c uart_if.c usb_if.c g_part_if.c g_raid_md_if.c >>>> g_raid_tr_if.c isa_if.c bus_if.c clock_if.c cpufreq_if.c device_if.c >>>> linker_if.c serdev_if.c xenbus_if.c xenbusb_if.c acpi_if.c acpi_wmi_if.c >>>> virtio_bus_if.c virtio_if.c agp_if.h ata_if.h eisa_if.h fb_if.h miibus_if.h >>>> mmcbr_if.h mmcbus_if.h mvs_if.h card_if.h power_if.h pci_if.h pcib_if.h >>>> ppbus_if.h sdhci_if.h hdac_if.h ac97_if.h channel_if.h feeder_if.h mixer_if.h >>>> mpu_if.h mpufoi_if.h synth_if.h uart_if.h usb_if.h g_part_if.h g_raid_md_if.h >>>> g_raid_tr_if.h isa_if.h bus_if.h clock_if.h cpufreq_if.h device_if.h >>>> linker_if.h serdev_if.h xenbus_if.h xenbusb_if.h acpi_if.h acpi_wmi_if.h >>>> virtio_bus_if.h virtio_if.h acpi_quirks.h feeder_eq_gen.h feeder_rate_gen.h >>>> snd_fxdiv_gen.h miidevs.h pccarddevs.h teken_state.h usbdevs.h usbdevs_data.h >>>> ia32_genassym.o ia32_assym.h acpi_wakecode.o acpi_wakecode.bin >>>> acpi_wakecode.h acpi_wakedata.h >>>> --- modules-cleandir --- >>>> cd /usr/src/sys/modules; >>>> MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/MYFINEHOST/modules KMODDIR=/boot/kernel >>>> MACHINE_CPUARCH=amd64 DEBUG_FLAGS="-g" MACHINE=amd64 >>>> KERNBUILDDIR="/usr/obj/usr/src/sys/MYFINEHOST" SYSDIR="/usr/src/sys" >>>> WITH_CTF="1" make cleandir >>>> --- cleandir_subdir_aac --- >>>> --- cleandir_subdir_aacraid --- >>>> --- cleandir_subdir_accf_data --- >>>> --- cleandir_subdir_accf_dns --- >>>> --- cleandir_subdir_aac --- >>>> ===> aac (cleandir) >>>> --- cleandir_subdir_aacraid --- >>>> ===> aacraid (cleandir) >>>> --- cleandir_subdir_accf_data --- >>>> ===> accf_data (cleandir) >>>> --- cleandir_subdir_accf_dns --- >>>> ===> accf_dns (cleandir) >>>> --- cleandir_subdir_accf_data --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_accf_dns --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_aacraid --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_aac --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_accf_http --- >>>> --- cleandir_subdir_acl_nfs4 --- >>>> --- cleandir_subdir_accf_http --- >>>> ===> accf_http (cleandir) >>>> --- cleandir_subdir_acl_nfs4 --- >>>> ===> acl_nfs4 (cleandir) >>>> --- cleandir_subdir_acl_posix1e --- >>>> --- cleandir_subdir_acpi --- >>>> --- cleandir_subdir_acl_posix1e --- >>>> ===> acl_posix1e (cleandir) >>>> --- cleandir_subdir_acpi --- >>>> ===> acpi (cleandir) >>>> --- cleandir_subdir_accf_http --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acl_nfs4 --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> --- _sub.cleandir --- >>>> ===> acpi/acpi_asus (cleandir) >>>> --- cleandir_subdir_ae --- >>>> ===> ae (cleandir) >>>> --- cleandir_subdir_aesni --- >>>> ===> aesni (cleandir) >>>> --- cleandir_subdir_acl_posix1e --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_age --- >>>> ===> age (cleandir) >>>> --- cleandir_subdir_aesni --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_ae --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> ===> acpi/acpi_asus_wmi (cleandir) >>>> --- cleandir_subdir_age --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_agp --- >>>> --- cleandir_subdir_aha --- >>>> --- cleandir_subdir_agp --- >>>> ===> agp (cleandir) >>>> --- cleandir_subdir_aha --- >>>> ===> aha (cleandir) >>>> --- cleanobj --- >>>> --- cleandir_subdir_ahci --- >>>> ===> ahci (cleandir) >>>> --- cleandir_subdir_aic7xxx --- >>>> ===> aic7xxx (cleandir) >>>> --- cleandir_subdir_ahci --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_agp --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> ===> acpi/acpi_fujitsu (cleandir) >>>> --- cleandir_subdir_aic7xxx --- >>>> --- _sub.cleandir --- >>>> ===> aic7xxx/ahc (cleandir) >>>> --- cleandir_subdir_aio --- >>>> ===> aio (cleandir) >>>> --- cleandir_subdir_acpi --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_aic7xxx --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_alc --- >>>> ===> alc (cleandir) >>>> --- cleandir_subdir_aio --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> ===> acpi/acpi_hp (cleandir) >>>> --- cleandir_subdir_alc --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_aic7xxx --- >>>> --- _sub.cleandir --- >>>> ===> aic7xxx/ahc/ahc_eisa (cleandir) >>>> --- clean --- >>>> rm -f export_syms ahc_eisa.ko ahc_eisa.kld ahc_eisa.o ahc_eisa.ko.debug >>>> ahc_eisa.ko.symbols opt_scsi.h opt_cam.h opt_aic7xxx.h eisa_if.h pci_if.h >>>> bus_if.h device_if.h >>>> --- cleanilinks --- >>>> rm -f @ machine x86 >>>> --- cleandepend --- >>>> rm -f .depend GPATH GRTAGS GSYMS GTAGS >>>> --- cleanobj --- >>>> ===> aic7xxx/ahc/ahc_isa (cleandir) >>>> --- cleanobj --- >>>> ===> aic7xxx/ahc/ahc_pci (cleandir) >>>> --- cleandir_subdir_acpi --- >>>> ===> acpi/acpi_ibm (cleandir) >>>> --- cleandir_subdir_ale --- >>>> ===> ale (cleandir) >>>> --- cleandir_subdir_aic7xxx --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_alq --- >>>> ===> alq (cleandir) >>>> --- cleandir_subdir_aic7xxx --- >>>> --- cleanobj --- >>>> rm: fts_read: No such file or directory >>>> *** [cleanobj] Error code 1 >>>> >>>> make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc >>>> 1 error >>>> >>>> make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc >>>> *** [_sub.cleandir] Error code 2 >>>> >>>> make[4]: stopped in /usr/src/sys/modules/aic7xxx >>>> 1 error >>>> >>>> make[4]: stopped in /usr/src/sys/modules/aic7xxx >>>> *** [cleandir_subdir_aic7xxx] Error code 2 >>>> >>>> make[3]: stopped in /usr/src/sys/modules >>>> --- cleandir_subdir_alq --- >>>> A failure has been detected in another branch of the parallel make >>>> >>>> make[4]: stopped in /usr/src/sys/modules/alq >>>> --- cleandir_subdir_ale --- >>>> A failure has been detected in another branch of the parallel make >>>> >>>> make[4]: stopped in /usr/src/sys/modules/ale >>>> --- cleandir_subdir_alq --- >>>> *** [cleandir_subdir_alq] Error code 2 >>>> >>>> make[3]: stopped in /usr/src/sys/modules >>>> --- cleandir_subdir_acpi --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_ale --->>> Kernel build for OZZIE started on Thu Sep 18 >>>> 04:35:18 CDT 2014 >>>> -------------------------------------------------------------- >>>> ===> OZZIE >>>> mkdir -p /usr/obj/usr/src/sys >>>> -------------------------------------------------------------- >>>>>>> stage 1: configuring the kernel >>>> -------------------------------------------------------------- >>>> cd /usr/src/sys/amd64/conf; >>>> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin >>>> >>>> config -d /usr/obj/usr/src/sys/OZZIE -I '/usr/src/sys/amd64/conf' >>>> '/usr/src/sys/amd64/conf/OZZIE' >>>> Kernel build directory is /usr/obj/usr/src/sys/OZZIE >>>> Don't forget to do ``make cleandepend && make depend'' >>>> -------------------------------------------------------------- >>>>>>> stage 2.1: cleaning up the object tree >>>> -------------------------------------------------------------- >>>> cd /usr/obj/usr/src/sys/OZZIE; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 >>>> MACHINE=amd64 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin >>>> GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font >>>> GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac >>>> _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp _LDSCRIPTROOT= VERSION="FreeBSD >>>> 10.1-BETA1 amd64 1000716" INSTALL="sh /usr/src/tools/install.sh" >>>> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin >>>> >>>> CC="cc " CXX="c++ " CPP="cpp " AS="as" AR="ar" LD="ld" NM=nm OBJDUMP= >>>> RANLIB=ranlib STRINGS= COMPILER_TYPE=clang make -j 4 -J 15,16 -m >>>> /usr/src/share/mk KERNEL=kernel cleandir >>>> --- kernel-clean --- >>>> --- kernel-cleandepend --- >>>> --- modules-cleandir --- >>>> --- kernel-cleandepend --- >>>> rm -f .depend machine x86 >>>> --- kernel-clean --- >>>> rm -f *.o *.so *.So *.ko *.s eddep errs kernel.debug kernel kernel.symbols >>>> linterrs tags vers.c vnode_if.c vnode_if.h vnode_if_newproto.h >>>> vnode_if_typedef.h agp_if.c ata_if.c eisa_if.c fb_if.c miibus_if.c mmcbr_if.c >>>> mmcbus_if.c mvs_if.c card_if.c power_if.c pci_if.c pcib_if.c ppbus_if.c >>>> sdhci_if.c hdac_if.c ac97_if.c channel_if.c feeder_if.c mixer_if.c mpu_if.c >>>> mpufoi_if.c synth_if.c uart_if.c usb_if.c g_part_if.c g_raid_md_if.c >>>> g_raid_tr_if.c isa_if.c bus_if.c clock_if.c cpufreq_if.c device_if.c >>>> linker_if.c serdev_if.c xenbus_if.c xenbusb_if.c acpi_if.c acpi_wmi_if.c >>>> virtio_bus_if.c virtio_if.c agp_if.h ata_if.h eisa_if.h fb_if.h miibus_if.h >>>> mmcbr_if.h mmcbus_if.h mvs_if.h card_if.h power_if.h pci_if.h pcib_if.h >>>> ppbus_if.h sdhci_if.h hdac_if.h ac97_if.h channel_if.h feeder_if.h mixer_if.h >>>> mpu_if.h mpufoi_if.h synth_if.h uart_if.h usb_if.h g_part_if.h g_raid_md_if.h >>>> g_raid_tr_if.h isa_if.h bus_if.h clock_if.h cpufreq_if.h device_if.h >>>> linker_if.h serdev_if.h xenbus_if.h xenbusb_if.h acpi_if.h acpi_wmi_if.h >>>> virtio_bus_if.h virtio_if.h acpi_quirks.h feeder_eq_gen.h feeder_rate_gen.h >>>> snd_fxdiv_gen.h miidevs.h pccarddevs.h teken_state.h usbdevs.h usbdevs_data.h >>>> ia32_genassym.o ia32_assym.h acpi_wakecode.o acpi_wakecode.bin >>>> acpi_wakecode.h acpi_wakedata.h >>>> --- modules-cleandir --- >>>> cd /usr/src/sys/modules; MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/OZZIE/modules >>>> KMODDIR=/boot/kernel MACHINE_CPUARCH=amd64 DEBUG_FLAGS="-g" MACHINE=amd64 >>>> KERNBUILDDIR="/usr/obj/usr/src/sys/OZZIE" SYSDIR="/usr/src/sys" WITH_CTF="1" >>>> make cleandir >>>> --- cleandir_subdir_aac --- >>>> --- cleandir_subdir_aacraid --- >>>> --- cleandir_subdir_accf_data --- >>>> --- cleandir_subdir_accf_dns --- >>>> --- cleandir_subdir_aac --- >>>> ===> aac (cleandir) >>>> --- cleandir_subdir_aacraid --- >>>> ===> aacraid (cleandir) >>>> --- cleandir_subdir_accf_data --- >>>> ===> accf_data (cleandir) >>>> --- cleandir_subdir_accf_dns --- >>>> ===> accf_dns (cleandir) >>>> --- cleandir_subdir_accf_data --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_accf_dns --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_aacraid --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_aac --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_accf_http --- >>>> --- cleandir_subdir_acl_nfs4 --- >>>> --- cleandir_subdir_accf_http --- >>>> ===> accf_http (cleandir) >>>> --- cleandir_subdir_acl_nfs4 --- >>>> ===> acl_nfs4 (cleandir) >>>> --- cleandir_subdir_acl_posix1e --- >>>> --- cleandir_subdir_acpi --- >>>> --- cleandir_subdir_acl_posix1e --- >>>> ===> acl_posix1e (cleandir) >>>> --- cleandir_subdir_acpi --- >>>> ===> acpi (cleandir) >>>> --- cleandir_subdir_accf_http --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acl_nfs4 --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> --- _sub.cleandir --- >>>> ===> acpi/acpi_asus (cleandir) >>>> --- cleandir_subdir_ae --- >>>> ===> ae (cleandir) >>>> --- cleandir_subdir_aesni --- >>>> ===> aesni (cleandir) >>>> --- cleandir_subdir_acl_posix1e --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_age --- >>>> ===> age (cleandir) >>>> --- cleandir_subdir_aesni --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_ae --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> ===> acpi/acpi_asus_wmi (cleandir) >>>> --- cleandir_subdir_age --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_agp --- >>>> --- cleandir_subdir_aha --- >>>> --- cleandir_subdir_agp --- >>>> ===> agp (cleandir) >>>> --- cleandir_subdir_aha --- >>>> ===> aha (cleandir) >>>> --- cleanobj --- >>>> --- cleandir_subdir_ahci --- >>>> ===> ahci (cleandir) >>>> --- cleandir_subdir_aic7xxx --- >>>> ===> aic7xxx (cleandir) >>>> --- cleandir_subdir_ahci --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_agp --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> ===> acpi/acpi_fujitsu (cleandir) >>>> --- cleandir_subdir_aic7xxx --- >>>> --- _sub.cleandir --- >>>> ===> aic7xxx/ahc (cleandir) >>>> --- cleandir_subdir_aio --- >>>> ===> aio (cleandir) >>>> --- cleandir_subdir_acpi --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_aic7xxx --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_alc --- >>>> ===> alc (cleandir) >>>> --- cleandir_subdir_aio --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> ===> acpi/acpi_hp (cleandir) >>>> --- cleandir_subdir_alc --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_aic7xxx --- >>>> --- _sub.cleandir --- >>>> ===> aic7xxx/ahc/ahc_eisa (cleandir) >>>> --- clean --- >>>> rm -f export_syms ahc_eisa.ko ahc_eisa.kld ahc_eisa.o ahc_eisa.ko.debug >>>> ahc_eisa.ko.symbols opt_scsi.h opt_cam.h opt_aic7xxx.h eisa_if.h pci_if.h >>>> bus_if.h device_if.h >>>> --- cleanilinks --- >>>> rm -f @ machine x86 >>>> --- cleandepend --- >>>> rm -f .depend GPATH GRTAGS GSYMS GTAGS >>>> --- cleanobj --- >>>> ===> aic7xxx/ahc/ahc_isa (cleandir) >>>> --- cleanobj --- >>>> ===> aic7xxx/ahc/ahc_pci (cleandir) >>>> --- cleandir_subdir_acpi --- >>>> ===> acpi/acpi_ibm (cleandir) >>>> --- cleandir_subdir_ale --- >>>> ===> ale (cleandir) >>>> --- cleandir_subdir_aic7xxx --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_alq --- >>>> ===> alq (cleandir) >>>> --- cleandir_subdir_aic7xxx --- >>>> --- cleanobj --- >>>> rm: fts_read: No such file or directory >>>> *** [cleanobj] Error code 1 >>>> >>>> make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc >>>> 1 error >>>> >>>> make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc >>>> *** [_sub.cleandir] Error code 2 >>>> >>>> make[4]: stopped in /usr/src/sys/modules/aic7xxx >>>> 1 error >>>> >>>> make[4]: stopped in /usr/src/sys/modules/aic7xxx >>>> *** [cleandir_subdir_aic7xxx] Error code 2 >>>> >>>> make[3]: stopped in /usr/src/sys/modules >>>> --- cleandir_subdir_alq --- >>>> A failure has been detected in another branch of the parallel make >>>> >>>> make[4]: stopped in /usr/src/sys/modules/alq >>>> --- cleandir_subdir_ale --- >>>> A failure has been detected in another branch of the parallel make >>>> >>>> make[4]: stopped in /usr/src/sys/modules/ale >>>> --- cleandir_subdir_alq --- >>>> *** [cleandir_subdir_alq] Error code 2 >>>> >>>> make[3]: stopped in /usr/src/sys/modules >>>> --- cleandir_subdir_acpi --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_ale --- >>>> *** [cleandir_subdir_ale] Error code 2 >>>> >>>> make[3]: stopped in /usr/src/sys/modules >>>> --- cleandir_subdir_acpi --- >>>> A failure has been detected in another branch of the parallel make >>>>>>> Kernel build for OZZIE started on Thu Sep 18 04:35:18 CDT 2014 >>>> -------------------------------------------------------------- >>>> ===> OZZIE >>>> mkdir -p /usr/obj/usr/src/sys >>>> -------------------------------------------------------------- >>>>>>> stage 1: configuring the kernel >>>> -------------------------------------------------------------- >>>> cd /usr/src/sys/amd64/conf; >>>> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin >>>> >>>> config -d /usr/obj/usr/src/sys/OZZIE -I '/usr/src/sys/amd64/conf' >>>> '/usr/src/sys/amd64/conf/OZZIE' >>>> Kernel build directory is /usr/obj/usr/src/sys/OZZIE >>>> Don't forget to do ``make cleandepend && make depend'' >>>> -------------------------------------------------------------- >>>>>>> stage 2.1: cleaning up the object tree >>>> -------------------------------------------------------------- >>>> cd /usr/obj/usr/src/sys/OZZIE; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 >>>> MACHINE=amd64 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin >>>> GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font >>>> GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac >>>> _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp _LDSCRIPTROOT= VERSION="FreeBSD >>>> 10.1-BETA1 amd64 1000716" INSTALL="sh /usr/src/tools/install.sh" >>>> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin >>>> >>>> CC="cc " CXX="c++ " CPP="cpp " AS="as" AR="ar" LD="ld" NM=nm OBJDUMP= >>>> RANLIB=ranlib STRINGS= COMPILER_TYPE=clang make -j 4 -J 15,16 -m >>>> /usr/src/share/mk KERNEL=kernel cleandir >>>> --- kernel-clean --- >>>> --- kernel-cleandepend --- >>>> --- modules-cleandir --- >>>> --- kernel-cleandepend --- >>>> rm -f .depend machine x86 >>>> --- kernel-clean --- >>>> rm -f *.o *.so *.So *.ko *.s eddep errs kernel.debug kernel kernel.symbols >>>> linterrs tags vers.c vnode_if.c vnode_if.h vnode_if_newproto.h >>>> vnode_if_typedef.h agp_if.c ata_if.c eisa_if.c fb_if.c miibus_if.c mmcbr_if.c >>>> mmcbus_if.c mvs_if.c card_if.c power_if.c pci_if.c pcib_if.c ppbus_if.c >>>> sdhci_if.c hdac_if.c ac97_if.c channel_if.c feeder_if.c mixer_if.c mpu_if.c >>>> mpufoi_if.c synth_if.c uart_if.c usb_if.c g_part_if.c g_raid_md_if.c >>>> g_raid_tr_if.c isa_if.c bus_if.c clock_if.c cpufreq_if.c device_if.c >>>> linker_if.c serdev_if.c xenbus_if.c xenbusb_if.c acpi_if.c acpi_wmi_if.c >>>> virtio_bus_if.c virtio_if.c agp_if.h ata_if.h eisa_if.h fb_if.h miibus_if.h >>>> mmcbr_if.h mmcbus_if.h mvs_if.h card_if.h power_if.h pci_if.h pcib_if.h >>>> ppbus_if.h sdhci_if.h hdac_if.h ac97_if.h channel_if.h feeder_if.h mixer_if.h >>>> mpu_if.h mpufoi_if.h synth_if.h uart_if.h usb_if.h g_part_if.h g_raid_md_if.h >>>> g_raid_tr_if.h isa_if.h bus_if.h clock_if.h cpufreq_if.h device_if.h >>>> linker_if.h serdev_if.h xenbus_if.h xenbusb_if.h acpi_if.h acpi_wmi_if.h >>>> virtio_bus_if.h virtio_if.h acpi_quirks.h feeder_eq_gen.h feeder_rate_gen.h >>>> snd_fxdiv_gen.h miidevs.h pccarddevs.h teken_state.h usbdevs.h usbdevs_data.h >>>> ia32_genassym.o ia32_assym.h acpi_wakecode.o acpi_wakecode.bin >>>> acpi_wakecode.h acpi_wakedata.h >>>> --- modules-cleandir --- >>>> cd /usr/src/sys/modules; MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/OZZIE/modules >>>> KMODDIR=/boot/kernel MACHINE_CPUARCH=amd64 DEBUG_FLAGS="-g" MACHINE=amd64 >>>> KERNBUILDDIR="/usr/obj/usr/src/sys/OZZIE" SYSDIR="/usr/src/sys" WITH_CTF="1" >>>> make cleandir >>>> --- cleandir_subdir_aac --- >>>> --- cleandir_subdir_aacraid --- >>>> --- cleandir_subdir_accf_data --- >>>> --- cleandir_subdir_accf_dns --- >>>> --- cleandir_subdir_aac --- >>>> ===> aac (cleandir) >>>> --- cleandir_subdir_aacraid --- >>>> ===> aacraid (cleandir) >>>> --- cleandir_subdir_accf_data --- >>>> ===> accf_data (cleandir) >>>> --- cleandir_subdir_accf_dns --- >>>> ===> accf_dns (cleandir) >>>> --- cleandir_subdir_accf_data --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_accf_dns --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_aacraid --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_aac --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_accf_http --- >>>> --- cleandir_subdir_acl_nfs4 --- >>>> --- cleandir_subdir_accf_http --- >>>> ===> accf_http (cleandir) >>>> --- cleandir_subdir_acl_nfs4 --- >>>> ===> acl_nfs4 (cleandir) >>>> --- cleandir_subdir_acl_posix1e --- >>>> --- cleandir_subdir_acpi --- >>>> --- cleandir_subdir_acl_posix1e --- >>>> ===> acl_posix1e (cleandir) >>>> --- cleandir_subdir_acpi --- >>>> ===> acpi (cleandir) >>>> --- cleandir_subdir_accf_http --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acl_nfs4 --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> --- _sub.cleandir --- >>>> ===> acpi/acpi_asus (cleandir) >>>> --- cleandir_subdir_ae --- >>>> ===> ae (cleandir) >>>> --- cleandir_subdir_aesni --- >>>> ===> aesni (cleandir) >>>> --- cleandir_subdir_acl_posix1e --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_age --- >>>> ===> age (cleandir) >>>> --- cleandir_subdir_aesni --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_ae --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> ===> acpi/acpi_asus_wmi (cleandir) >>>> --- cleandir_subdir_age --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_agp --- >>>> --- cleandir_subdir_aha --- >>>> --- cleandir_subdir_agp --- >>>> ===> agp (cleandir) >>>> --- cleandir_subdir_aha --- >>>> ===> aha (cleandir) >>>> --- cleanobj --- >>>> --- cleandir_subdir_ahci --- >>>> ===> ahci (cleandir) >>>> --- cleandir_subdir_aic7xxx --- >>>> ===> aic7xxx (cleandir) >>>> --- cleandir_subdir_ahci --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_agp --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> ===> acpi/acpi_fujitsu (cleandir) >>>> --- cleandir_subdir_aic7xxx --- >>>> --- _sub.cleandir --- >>>> ===> aic7xxx/ahc (cleandir) >>>> --- cleandir_subdir_aio --- >>>> ===> aio (cleandir) >>>> --- cleandir_subdir_acpi --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_aic7xxx --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_alc --- >>>> ===> alc (cleandir) >>>> --- cleandir_subdir_aio --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> ===> acpi/acpi_hp (cleandir) >>>> --- cleandir_subdir_alc --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_acpi --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_aic7xxx --- >>>> --- _sub.cleandir --- >>>> ===> aic7xxx/ahc/ahc_eisa (cleandir) >>>> --- clean --- >>>> rm -f export_syms ahc_eisa.ko ahc_eisa.kld ahc_eisa.o ahc_eisa.ko.debug >>>> ahc_eisa.ko.symbols opt_scsi.h opt_cam.h opt_aic7xxx.h eisa_if.h pci_if.h >>>> bus_if.h device_if.h >>>> --- cleanilinks --- >>>> rm -f @ machine x86 >>>> --- cleandepend --- >>>> rm -f .depend GPATH GRTAGS GSYMS GTAGS >>>> --- cleanobj --- >>>> ===> aic7xxx/ahc/ahc_isa (cleandir) >>>> --- cleanobj --- >>>> ===> aic7xxx/ahc/ahc_pci (cleandir) >>>> --- cleandir_subdir_acpi --- >>>> ===> acpi/acpi_ibm (cleandir) >>>> --- cleandir_subdir_ale --- >>>> ===> ale (cleandir) >>>> --- cleandir_subdir_aic7xxx --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_alq --- >>>> ===> alq (cleandir) >>>> --- cleandir_subdir_aic7xxx --- >>>> --- cleanobj --- >>>> rm: fts_read: No such file or directory >>>> *** [cleanobj] Error code 1 >>>> >>>> make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc >>>> 1 error >>>> >>>> make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc >>>> *** [_sub.cleandir] Error code 2 >>>> >>>> make[4]: stopped in /usr/src/sys/modules/aic7xxx >>>> 1 error >>>> >>>> make[4]: stopped in /usr/src/sys/modules/aic7xxx >>>> *** [cleandir_subdir_aic7xxx] Error code 2 >>>> >>>> make[3]: stopped in /usr/src/sys/modules >>>> --- cleandir_subdir_alq --- >>>> A failure has been detected in another branch of the parallel make >>>> >>>> make[4]: stopped in /usr/src/sys/modules/alq >>>> --- cleandir_subdir_ale --- >>>> A failure has been detected in another branch of the parallel make >>>> >>>> make[4]: stopped in /usr/src/sys/modules/ale >>>> --- cleandir_subdir_alq --- >>>> *** [cleandir_subdir_alq] Error code 2 >>>> >>>> make[3]: stopped in /usr/src/sys/modules >>>> --- cleandir_subdir_acpi --- >>>> --- cleanobj --- >>>> --- cleandir_subdir_ale --- >>>> *** [cleandir_subdir_ale] Error code 2 >>>> >>>> make[3]: stopped in /usr/src/sys/modules >>>> --- cleandir_subdir_acpi --- >>>> A failure has been detected in another branch of the parallel make >>>> >>>> make[5]: stopped in /usr/src/sys/modules/acpi/acpi_ibm >>>> *** [_sub.cleandir] Error code 2 >>>> >>>> make[4]: stopped in /usr/src/sys/modules/acpi >>>> 1 error >>>> >>>> make[4]: stopped in /usr/src/sys/modules/acpi >>>> *** [cleandir_subdir_acpi] Error code 2 >>>> >>>> make[3]: stopped in /usr/src/sys/modules >>>> 4 errors >>>> >>>> make[3]: stopped in /usr/src/sys/modules >>>> *** [modules-cleandir] Error code 2 >>>> >>>> make[2]: stopped in /usr/obj/usr/src/sys/OZZIE >>>> 1 error >>>> >>>> make[2]: stopped in /usr/obj/usr/src/sys/OZZIE >>>> *** [buildkernel] Error code 2 >>>> >>>> make[1]: stopped in /usr/src >>>> 1 error >>>> >>>> make[1]: stopped in /usr/src >>>> *** [buildkernel] Error code 2 >>>> >>>> make: stopped in /usr/src >>>> 1 error >>>> >>>> make: stopped in /usr/src >>>> >>>> make[5]: stopped in /usr/src/sys/modules/acpi/acpi_ibm >>>> *** [_sub.cleandir] Error code 2 >>>> >>>> make[4]: stopped in /usr/src/sys/modules/acpi >>>> 1 error >>>> >>>> make[4]: stopped in /usr/src/sys/modules/acpi >>>> *** [cleandir_subdir_acpi] Error code 2 >>>> >>>> make[3]: stopped in /usr/src/sys/modules >>>> 4 errors >>>> >>>> make[3]: stopped in /usr/src/sys/modules >>>> *** [modules-cleandir] Error code 2 >>>> >>>> make[2]: stopped in /usr/obj/usr/src/sys/OZZIE >>>> 1 error >>>> >>>> make[2]: stopped in /usr/obj/usr/src/sys/OZZIE >>>> *** [buildkernel] Error code 2 >>>> >>>> make[1]: stopped in /usr/src >>>> 1 error >>>> >>>> make[1]: stopped in /usr/src >>>> *** [buildkernel] Error code 2 >>>> >>>> make: stopped in /usr/src >>>> 1 error >>>> >>>> make: stopped in /usr/src >>>> >>>> *** [cleandir_subdir_ale] Error code 2 >>>> >>>> make[3]: stopped in /usr/src/sys/modules >>>> --- cleandir_subdir_acpi --- >>>> A failure has been detected in another branch of the parallel make >>>> >>>> make[5]: stopped in /usr/src/sys/modules/acpi/acpi_ibm >>>> *** [_sub.cleandir] Error code 2 >>>> >>>> make[4]: stopped in /usr/src/sys/modules/acpi >>>> 1 error >>>> >>>> make[4]: stopped in /usr/src/sys/modules/acpi >>>> *** [cleandir_subdir_acpi] Error code 2 >>>> >>>> make[3]: stopped in /usr/src/sys/modules >>>> 4 errors >>>> >>>> make[3]: stopped in /usr/src/sys/modules >>>> *** [modules-cleandir] Error code 2 >>>> >>>> make[2]: stopped in /usr/obj/usr/src/sys/MYFINEHOST >>>> 1 error >>>> >>>> make[2]: stopped in /usr/obj/usr/src/sys/MYFINEHOST >>>> *** [buildkernel] Error code 2 >>>> >>>> make[1]: stopped in /usr/src >>>> 1 error >>>> >>>> make[1]: stopped in /usr/src >>>> *** [buildkernel] Error code 2 >>>> >>>> make: stopped in /usr/src >>>> 1 error >>>> >>>> make: stopped in /usr/src >>>> >>>> -- >>>> ---------------------------------------------------------------------------- >>>> Tim Daneliuk tundra@tundraware.com >>>> PGP Key: http://www.tundraware.com/PGP/ >>>> >>>> _______________________________________________ >>>> freebsd-stable@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >>>> >>> >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> >> -- >> ---------------------------------------------------------------------------- >> Tim Daneliuk tundra@tundraware.com >> PGP Key: http://www.tundraware.com/PGP/ >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > -- ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/ From owner-freebsd-stable@FreeBSD.ORG Fri Sep 19 15:58:07 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B031F461 for ; Fri, 19 Sep 2014 15:58:07 +0000 (UTC) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F5907A5 for ; Fri, 19 Sep 2014 15:58:06 +0000 (UTC) Received: from GBL007106 (hydrus.plus.com [212.159.122.116]) by mrelayeu.kundenserver.de (node=mreue105) with ESMTP (Nemesis) id 0LmLB4-1Y4tX40hBi-00ZtbQ; Fri, 19 Sep 2014 17:52:28 +0200 From: Sender: "Mark Willson" To: "'Tim Daneliuk'" , "'Steven Hartland'" , "'FreeBSD Stable'" References: <541B6167.3000703@tundraware.com> <541B6A6F.5010501@tundraware.com> <62E5543C34E048D5B454CD795ACAC495@multiplay.co.uk> <541B71E5.9000505@tundraware.com> In-Reply-To: <541B71E5.9000505@tundraware.com> Subject: RE: 10.1Beta - Ongoing Build Problems Date: Fri, 19 Sep 2014 16:52:30 +0100 Message-ID: <003401cfd421$b8a8c030$29fa4090$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIueGWkRFNcgwTV/cahSXFaq7rtkQHSnjC8AmsX6/4ByUMvvAIOql85mwqkKhA= Content-Language: en-gb X-Provags-ID: V02:K0:6JM0qZg/sQ0KPKHH37qJKOM8VPtNNnKEs7uQCfkC8jo rKzB273mQPU+EPLUSiSY+B3+tejK0SPhR/c3MUabb8/xiVuCJd /YU//2odBryww/vqJ5fSO9cLOo0yVRnByQ5fmDCZdZ6/W/F8nP 0v6MIdlUiFt/32fOOwp9jVODdNpmqtPEzjybc2ceVy1k6S8gob 6Uu67dxOKET9WadgZnXW8acut/pK1N/u798HqsYGfpmOVP/RJA UOWJEiG2SOEqAofJ+jLZ/qdTRan/hvUxXgAr8CPV0Ec/QiC7t2 C9ixtlQlOl+LI7bb/V9UyeArXf50RTKReh/lb8LrZbDdnNXuWn S1US/xSjVTqcacwncUE+l+BLCnfaS4GvzF+So/XYH X-UI-Out-Filterresults: notjunk:1; X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 15:58:07 -0000 > -----Original Message----- > From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > stable@freebsd.org] On Behalf Of Tim Daneliuk > Sent: 19 September 2014 01:00 > To: Steven Hartland; FreeBSD Stable > Subject: Re: 10.1Beta - Ongoing Build Problems > > On 09/18/2014 06:36 PM, Steven Hartland wrote: > > I just noticed your error was > > > > rm: fts_read: No such file or directory > > > > This is a know issue with rewinddir. > > > > I believe the fix is: > > http://svnweb.freebsd.org/changeset/base/271048 > > > > Which was MFC'ed by: > > http://svnweb.freebsd.org/changeset/base/271263 > > > > So your build machine will need to be running r271263 or later. > > > > Regards > > Steve > > > Well ... I am at 10.1-PRERELEASE #27 r271419 and seeing the problem. > > Tim, The issue might be that the rev number shown by uname is actually the rev number of the last head update, not the 10-STABLE branch. Running "svn info" in /usr/src will provide a "Last Changed Rev" which shows where you really are. -mark From owner-freebsd-stable@FreeBSD.ORG Fri Sep 19 16:05:44 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8279C6D8 for ; Fri, 19 Sep 2014 16:05:44 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 3F0D088B for ; Fri, 19 Sep 2014 16:05:43 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id s8JG5aMn040914 for ; Fri, 19 Sep 2014 09:05:36 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id s8JG5aql040913 for stable@freebsd.org; Fri, 19 Sep 2014 09:05:36 -0700 (PDT) (envelope-from david) Date: Fri, 19 Sep 2014 09:05:36 -0700 From: David Wolfskill To: stable@freebsd.org Subject: Re: 10.1Beta - Ongoing Build Problems Message-ID: <20140919160536.GZ1196@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , stable@freebsd.org References: <541B6167.3000703@tundraware.com> <541B6A6F.5010501@tundraware.com> <62E5543C34E048D5B454CD795ACAC495@multiplay.co.uk> <541B71E5.9000505@tundraware.com> <003401cfd421$b8a8c030$29fa4090$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="quagH4H09id5XL2e" Content-Disposition: inline In-Reply-To: <003401cfd421$b8a8c030$29fa4090$@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 16:05:44 -0000 --quagH4H09id5XL2e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 19, 2014 at 04:52:30PM +0100, cdr.nil@gmail.com wrote: > ... > The issue might be that the rev number shown by uname is actually the rev > number of the last head update, not the 10-STABLE branch. Running "svn > info" in /usr/src will provide a "Last Changed Rev" which shows where you > really are. > .... Which source of confusion is why I modified src/syc/conf/newvers.sh on my systems as described in -- e.g.: FreeBSD 9.3-STABLE #101 r271842M/271869:903504: Fri Sep 19 05:09:06 PDT 20= 14 root@g1-235.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 FreeBSD 10.1-BETA2 #1337 r271848M/271869:1000717: Fri Sep 19 06:31:45 PDT = 2014 root@g1-235.catwhisker.org:/common/S3/obj/usr/src/sys/CANARY i386 FreeBSD 11.0-CURRENT #1372 r271869M/271869:1100036: Fri Sep 19 07:38:14 PD= T 2014 root@g1-235.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i3= 86 (different slices from the same drive on teh same hardware, each built using a local private mirror of the svn repository that I updated just prior to starting those builds). Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --quagH4H09id5XL2e Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUHFRPXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7UmAP/3MMyC5GZv6XRt/oRS7oSvZD FagH9BCUCthhafKFqdHASa2V6nl4nwJ1eJOiIsnpB5scZ/e8KcLPMEl+lsBqrx/Y Bl3zV178m72CyCbvhWQosX+8uzLL7tfvBI7bmBYnkaKyJEYG3hQU4UUkfD36Ia7f jvVLDUiucp41gSK1Xmm3oleCHLoUDCfsKLkyPQpTGwXN4Kx+mE5ZszavCL4kSu+q 11Z4G18dL9yf0LwifBfBFKJZPPsPQC1RgXOlaiedKGG+pr7HJ1RS7HWunzxhuQTy vhDWENQsinbjZemOPD17jN0cg7xR8YPSg4jZMTy6Uee40GYrMDwURkX0Rd7zvsf6 FcwX/5os35rAOpXKRwmXEQwqYmJfSSmb93q8lu6HdgCkH2zkHkQIGs5YEPu2II2P B4UbwybtjPsAE43pXwP9pYRUXY4u/sRsXvo2xHfrsSza4R1wBKj+09mGZeVWjFKy Yz2t7OmJSdqr9jMcZrlluc+PsdA4xV0Zvyq4eeB3i0x//wtks4/uvdA8si6Fdnj5 d0+tjSU2bulpvJzIwc1Rqp47kmgCASXPMzsSATEES1zVg+E3seyu8e+qNWG+q8kk yVX93+rwDZ5z4B9y+AjKOZPn8Bm/ccfgoJzrX6buk3sQlW9CDGfUItvyPkNbQ16R GKtD9H9739dstEqiAunx =WCas -----END PGP SIGNATURE----- --quagH4H09id5XL2e-- From owner-freebsd-stable@FreeBSD.ORG Fri Sep 19 16:05:51 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87D8B7C0 for ; Fri, 19 Sep 2014 16:05:51 +0000 (UTC) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ozzie.tundraware.com", Issuer "ozzie.tundraware.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 331F288C for ; Fri, 19 Sep 2014 16:05:50 +0000 (UTC) Received: from [192.168.0.2] (viper.tundraware.com [192.168.0.2]) (authenticated bits=0) by ozzie.tundraware.com (8.14.9/8.14.9) with ESMTP id s8JG5dcc005763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 19 Sep 2014 11:05:39 -0500 (CDT) (envelope-from tundra@tundraware.com) Message-ID: <541C5453.8030704@tundraware.com> Date: Fri, 19 Sep 2014 11:05:39 -0500 From: Tim Daneliuk User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: cdr.nil@gmail.com, "'Steven Hartland'" , "'FreeBSD Stable'" Subject: Re: 10.1Beta - Ongoing Build Problems References: <541B6167.3000703@tundraware.com> <541B6A6F.5010501@tundraware.com> <62E5543C34E048D5B454CD795ACAC495@multiplay.co.uk> <541B71E5.9000505@tundraware.com> <003401cfd421$b8a8c030$29fa4090$@gmail.com> In-Reply-To: <003401cfd421$b8a8c030$29fa4090$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (ozzie.tundraware.com [75.145.138.73]); Fri, 19 Sep 2014 11:05:39 -0500 (CDT) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: s8JG5dcc005763 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 16:05:51 -0000 On 09/19/2014 10:52 AM, cdr.nil@gmail.com wrote: >> -----Original Message----- >> From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- >> stable@freebsd.org] On Behalf Of Tim Daneliuk >> Sent: 19 September 2014 01:00 >> To: Steven Hartland; FreeBSD Stable >> Subject: Re: 10.1Beta - Ongoing Build Problems >> >> On 09/18/2014 06:36 PM, Steven Hartland wrote: >>> I just noticed your error was >>> >>> rm: fts_read: No such file or directory >>> >>> This is a know issue with rewinddir. >>> >>> I believe the fix is: >>> http://svnweb.freebsd.org/changeset/base/271048 >>> >>> Which was MFC'ed by: >>> http://svnweb.freebsd.org/changeset/base/271263 >>> >>> So your build machine will need to be running r271263 or later. >>> >>> Regards >>> Steve >> >> >> Well ... I am at 10.1-PRERELEASE #27 r271419 and seeing the problem. >> >> > > Tim, > > The issue might be that the rev number shown by uname is actually the rev > number of the last head update, not the 10-STABLE branch. Running "svn > info" in /usr/src will provide a "Last Changed Rev" which shows where you > really are. > > -mark Thanks Mark, good to know. All - I ran into a bit of a snag with the testing. Bear with me, the machine in question is - among other things - our mail server. When I installed last night's build, it broke saslauth horribly, so outbound mail was failing. I had to fall the machine back to yesterday morning's backups which means: A) I lost a bunch of emails from this morning B) I am now backleveled somewhat to 10.1-PRERELEASE #27 r271419 At the moment, I don't dare update to latest BETA sources until this sasl business get sorted out. So, it will be a day or two before I get back to this. One think I did note before all this nonsense it that the tendency for buildkernel to fail is somewhat lower if I do a make clean first.... ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/ From owner-freebsd-stable@FreeBSD.ORG Fri Sep 19 23:07:49 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 174C84DD; Fri, 19 Sep 2014 23:07:49 +0000 (UTC) Received: from aslan.scsiguy.com (mail.scsiguy.com [70.89.174.89]) (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 D859487F; Fri, 19 Sep 2014 23:07:48 +0000 (UTC) Received: from [192.168.6.121] (slboulder.spectralogic.com [192.30.190.3] (may be forged)) (authenticated bits=0) by aslan.scsiguy.com (8.14.9/8.14.9) with ESMTP id s8JN7YwK060738 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Sep 2014 17:07:36 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: getting to 4K disk blocks in ZFS From: "Justin T. Gibbs" In-Reply-To: <541230F1.3060402@digiware.nl> Date: Fri, 19 Sep 2014 17:07:29 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <7D0869A9-C114-4C4F-877A-3FB26AD7737D@scsiguy.com> References: <540FF3C4.6010305@ish.com.au> <54114029.3060507@FreeBSD.org> <2128347.Ah5i0RTCvp@overcee.wemm.org> <541230F1.3060402@digiware.nl> To: Willem Jan Withagen X-Mailer: Apple Mail (2.1878.6) Cc: Steven Hartland , freebsd-stable@freebsd.org, Andriy Gapon , Peter Wemm , Aristedes Maniatis X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 23:07:49 -0000 On Sep 11, 2014, at 5:32 PM, Willem Jan Withagen = wrote: > On 11-9-2014 19:49, Peter Wemm wrote: >>> Another downside is 1/4th of uberblocks, 32 vs 128. >>> Also, automatic sector size detection works great for me and I've = never had >>> a need to manually tweak ashift. >>=20 >> Unfortunately, I have. Same drive connected two different ways: >>=20 >> da12 at mps1 bus 0 scbus1 target 11 lun 0 >> da12: Fixed Direct Access SCSI-6 device=20= >> da12: 600.000MB/s transfers >> da12: Command Queueing enabled >> da12: 3815447MB (7814037168 512 byte sectors: 255H 63S/T 486401C) >>=20 >> ada1 at ahcich1 bus 0 scbus3 target 0 lun 0 >> ada1: ATA-8 SATA 3.x device >> ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) >> ada1: Command Queueing enabled >> ada1: 3815447MB (7814037168 512 byte sectors: 16H 63S/T 16383C) >> ada1: quirks=3D0x1<4K> >>=20 >> The 4k flag is missing when it's on the sas controller. The Ident = strings are=20 >> changed. >>=20 >> This came up elsewhere recently. >=20 > I reported the same fact for the new set of WD REDs I installed. > Seems that ada and da have different quirks tables... > So disks on SATA connectors on the motherboard are diagnosed as being = 4Kb. > The disks on my twa don't get the quirk and are considered 512b >=20 > =97WjW I=92m surprised that we have to constantly add quirks. Are these drives = really failing to report their ata params correctly? Is there a reason = we don=92t currently utilize the ata params data (which is already = fetched for trim/unmap detection) to also set lbppbe (logical block per = physical block exponent) and lalba (lowest aligned lba)? We may find = that many of the existing quirks are unnecessary if we fix the probe = code. =97 Justin= From owner-freebsd-stable@FreeBSD.ORG Fri Sep 19 23:23:37 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C127E7D5; Fri, 19 Sep 2014 23:23:37 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 81BAD9FE; Fri, 19 Sep 2014 23:23:37 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 8A40120E7088F; Fri, 19 Sep 2014 23:23:36 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.8 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,RDNS_DYNAMIC,STOX_REPLY_TYPE,TVD_FINGER_02 autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id C5B9E20E7088A; Fri, 19 Sep 2014 23:23:34 +0000 (UTC) Message-ID: <607F83CE25104CE09C74935BA9E26485@multiplay.co.uk> From: "Steven Hartland" To: "Justin T. Gibbs" , "Willem Jan Withagen" References: <540FF3C4.6010305@ish.com.au> <54114029.3060507@FreeBSD.org> <2128347.Ah5i0RTCvp@overcee.wemm.org> <541230F1.3060402@digiware.nl> <7D0869A9-C114-4C4F-877A-3FB26AD7737D@scsiguy.com> Subject: Re: getting to 4K disk blocks in ZFS Date: Sat, 20 Sep 2014 00:23:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-stable@freebsd.org, Peter Wemm , Andriy Gapon , Aristedes Maniatis X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 23:23:37 -0000 ----- Original Message ----- > From: "Justin T. Gibbs" > To: "Willem Jan Withagen" > Cc: "Steven Hartland" ; ; "Andriy Gapon" ; "Peter Wemm" > ; "Aristedes Maniatis" > Sent: Saturday, September 20, 2014 12:07 AM > Subject: Re: getting to 4K disk blocks in ZFS > > > On Sep 11, 2014, at 5:32 PM, Willem Jan Withagen wrote: > > > On 11-9-2014 19:49, Peter Wemm wrote: > >>> Another downside is 1/4th of uberblocks, 32 vs 128. > >>> Also, automatic sector size detection works great for me and I've never had > >>> a need to manually tweak ashift. > >> > >> Unfortunately, I have. Same drive connected two different ways: > >> > >> da12 at mps1 bus 0 scbus1 target 11 lun 0 > >> da12: Fixed Direct Access SCSI-6 device > >> da12: 600.000MB/s transfers > >> da12: Command Queueing enabled > >> da12: 3815447MB (7814037168 512 byte sectors: 255H 63S/T 486401C) > >> > >> ada1 at ahcich1 bus 0 scbus3 target 0 lun 0 > >> ada1: ATA-8 SATA 3.x device > >> ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > >> ada1: Command Queueing enabled > >> ada1: 3815447MB (7814037168 512 byte sectors: 16H 63S/T 16383C) > >> ada1: quirks=0x1<4K> > >> > >> The 4k flag is missing when it's on the sas controller. The Ident strings are > >> changed. > >> > >> This came up elsewhere recently. > > > > I reported the same fact for the new set of WD REDs I installed. > > Seems that ada and da have different quirks tables... > > So disks on SATA connectors on the motherboard are diagnosed as being 4Kb. > > The disks on my twa don't get the quirk and are considered 512b > > > > —WjW > > I’m surprised that we have to constantly add quirks. Are these drives really > failing to report their ata params correctly? Is there a reason we don’t > currently utilize the ata params data (which is already fetched for trim/unmap > detection) to also set lbppbe (logical block per physical block exponent) and > lalba (lowest aligned lba)? We may find that many of the existing quirks are > unnecessary if we fix the probe code. On the contary I've not found a single drive which reports 4k sectors on its own, every single one that I've seen report 4k is because we've added a quirk for it :( Regards Steve From owner-freebsd-stable@FreeBSD.ORG Fri Sep 19 23:34:21 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7FD195C for ; Fri, 19 Sep 2014 23:34:21 +0000 (UTC) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "NewFS.denninger.net", Issuer "NewFS.denninger.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7183AACF for ; Fri, 19 Sep 2014 23:34:20 +0000 (UTC) Received: from [192.168.1.40] (localhost [127.0.0.1]) by fs.denninger.net (8.14.9/8.14.8) with ESMTP id s8JNY7iW003801 for ; Fri, 19 Sep 2014 18:34:08 -0500 (CDT) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (TLS/SSL) [192.168.1.40] by Spamblock-sys (LOCAL/AUTH); Fri Sep 19 18:34:07 2014 Message-ID: <541CBD5B.8050603@denninger.net> Date: Fri, 19 Sep 2014 18:33:47 -0500 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: getting to 4K disk blocks in ZFS References: <540FF3C4.6010305@ish.com.au> <54114029.3060507@FreeBSD.org> <2128347.Ah5i0RTCvp@overcee.wemm.org> <541230F1.3060402@digiware.nl> <7D0869A9-C114-4C4F-877A-3FB26AD7737D@scsiguy.com> <607F83CE25104CE09C74935BA9E26485@multiplay.co.uk> In-Reply-To: <607F83CE25104CE09C74935BA9E26485@multiplay.co.uk> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050806050102070608030701" X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 23:34:21 -0000 This is a cryptographically signed message in MIME format. --------------ms050806050102070608030701 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 9/19/2014 6:23 PM, Steven Hartland wrote: > > ----- Original Message ----- >> From: "Justin T. Gibbs" >> To: "Willem Jan Withagen" >> Cc: "Steven Hartland" ; >> ; "Andriy Gapon" ; >> "Peter Wemm" ; "Aristedes Maniatis" >> Sent: Saturday, September 20, 2014 12:07 AM >> Subject: Re: getting to 4K disk blocks in ZFS >> >> >> On Sep 11, 2014, at 5:32 PM, Willem Jan Withagen >> wrote: >> >> > On 11-9-2014 19:49, Peter Wemm wrote: >> >>> Another downside is 1/4th of uberblocks, 32 vs 128. >> >>> Also, automatic sector size detection works great for me and I've >> never had >> >>> a need to manually tweak ashift. >> >> >> >> Unfortunately, I have. Same drive connected two different ways: >> >> >> >> da12 at mps1 bus 0 scbus1 target 11 lun 0 >> >> da12: Fixed Direct Access SCSI-6 device= >> >> da12: 600.000MB/s transfers >> >> da12: Command Queueing enabled >> >> da12: 3815447MB (7814037168 512 byte sectors: 255H 63S/T 486401C) >> >> >> >> ada1 at ahcich1 bus 0 scbus3 target 0 lun 0 >> >> ada1: ATA-8 SATA 3.x device >> >> ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) >> >> ada1: Command Queueing enabled >> >> ada1: 3815447MB (7814037168 512 byte sectors: 16H 63S/T 16383C) >> >> ada1: quirks=3D0x1<4K> >> >> >> >> The 4k flag is missing when it's on the sas controller. The Ident >> strings are >> >> changed. >> >> >> >> This came up elsewhere recently. >> > >> > I reported the same fact for the new set of WD REDs I installed. >> > Seems that ada and da have different quirks tables... >> > So disks on SATA connectors on the motherboard are diagnosed as >> being 4Kb. >> > The disks on my twa don't get the quirk and are considered 512b >> > >> > =97WjW >> >> I=92m surprised that we have to constantly add quirks. Are these >> drives really >> failing to report their ata params correctly? Is there a reason we >> don=92t >> currently utilize the ata params data (which is already fetched for >> trim/unmap >> detection) to also set lbppbe (logical block per physical block >> exponent) and >> lalba (lowest aligned lba)? We may find that many of the existing >> quirks are >> unnecessary if we fix the probe code. > > On the contary I've not found a single drive which reports 4k sectors > on its > own, every single one that I've seen report 4k is because we've added a= > quirk for it :( > > Where is Smartctl getting it from? smartctl -i /dev/da2 smartctl 6.3 2014-07-26 r3976 [FreeBSD 10.1-BETA1 amd64] (local build) Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.o= rg =3D=3D=3D START OF INFORMATION SECTION =3D=3D=3D Device Model: HGST HDN724040ALE640 Serial Number: PK2334PCG6NA0B LU WWN Device Id: 5 000cca 24cc30684 Firmware Version: MJAOA5E0 User Capacity: 4,000,787,030,016 bytes [4.00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Rotation Rate: 7200 rpm Form Factor: 3.5 inches Device is: Not in smartctl database [for details use: -P showall] ATA Version is: ATA8-ACS T13/1699-D revision 4 SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is: Fri Sep 19 18:33:16 2014 CDT SMART support is: Available - device has SMART capability. SMART support is: Enabled It's not coming from a database, as Smartctl doesn't know about these (yet); they're too new. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ --------------ms050806050102070608030701 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFTzCC BUswggQzoAMCAQICAQgwDQYJKoZIhvcNAQEFBQAwgZ0xCzAJBgNVBAYTAlVTMRAwDgYDVQQI EwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkqhkiG9w0BCQEWIGN1c3Rv bWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0MB4XDTEzMDgyNDE5MDM0NFoXDTE4MDgyMzE5 MDM0NFowWzELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExFzAVBgNVBAMTDkthcmwg RGVubmluZ2VyMSEwHwYJKoZIhvcNAQkBFhJrYXJsQGRlbm5pbmdlci5uZXQwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC5n2KBrBmG22nVntVdvgKCB9UcnapNThrW1L+dq6th d9l4mj+qYMUpJ+8I0rTbY1dn21IXQBoBQmy8t1doKwmTdQ59F0FwZEPt/fGbRgBKVt3Quf6W 6n7kRk9MG6gdD7V9vPpFV41e+5MWYtqGWY3ScDP8SyYLjL/Xgr+5KFKkDfuubK8DeNqdLniV jHo/vqmIgO+6NgzPGPgmbutzFQXlxUqjiNAAKzF2+Tkddi+WKABrcc/EqnBb0X8GdqcIamO5 SyVmuM+7Zdns7D9pcV16zMMQ8LfNFQCDvbCuuQKMDg2F22x5ekYXpwjqTyfjcHBkWC8vFNoY 5aFMdyiN/Kkz0/kduP2ekYOgkRqcShfLEcG9SQ4LQZgqjMpTjSOGzBr3tOvVn5LkSJSHW2Z8 Q0dxSkvFG2/lsOWFbwQeeZSaBi5vRZCYCOf5tRd1+E93FyQfpt4vsrXshIAk7IK7f0qXvxP4 GDli5PKIEubD2Bn+gp3vB/DkfKySh5NBHVB+OPCoXRUWBkQxme65wBO02OZZt0k8Iq0i4Rci WV6z+lQHqDKtaVGgMsHn6PoeYhjf5Al5SP+U3imTjF2aCca1iDB5JOccX04MNljvifXgcbJN nkMgrzmm1ZgJ1PLur/ADWPlnz45quOhHg1TfUCLfI/DzgG7Z6u+oy4siQuFr9QT0MQIDAQAB o4HWMIHTMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIF4DAsBglg hkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHw4 +LnuALyLA5Cgy7T5ZAX1WzKPMB8GA1UdIwQYMBaAFF3U3hpBZq40HB5VM7B44/gmXiI0MDgG CWCGSAGG+EIBAwQrFilodHRwczovL2N1ZGFzeXN0ZW1zLm5ldDoxMTQ0My9yZXZva2VkLmNy bDANBgkqhkiG9w0BAQUFAAOCAQEAZ0L4tQbBd0hd4wuw/YVqEBDDXJ54q2AoqQAmsOlnoxLO 31ehM/LvrTIP4yK2u1VmXtUumQ4Ao15JFM+xmwqtEGsh70RRrfVBAGd7KOZ3GB39FP2TgN/c L5fJKVxOqvEnW6cL9QtvUlcM3hXg8kDv60OB+LIcSE/P3/s+0tEpWPjxm3LHVE7JmPbZIcJ1 YMoZvHh0NSjY5D0HZlwtbDO7pDz9sZf1QEOgjH828fhtborkaHaUI46pmrMjiBnY6ujXMcWD pxtikki0zY22nrxfTs5xDWGxyrc/cmucjxClJF6+OYVUSaZhiiHfa9Pr+41okLgsRB0AmNwE f6ItY3TI8DGCBQowggUGAgEBMIGjMIGdMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxvcmlk YTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRwwGgYD VQQDExNDdWRhIFN5c3RlbXMgTExDIENBMS8wLQYJKoZIhvcNAQkBFiBjdXN0b21lci1zZXJ2 aWNlQGN1ZGFzeXN0ZW1zLm5ldAIBCDAJBgUrDgMCGgUAoIICOzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA5MTkyMzMzNDdaMCMGCSqGSIb3DQEJBDEW BBSkQ8EmyYhUkqJnSIix9XGLJOTm9zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG0BgkrBgEEAYI3EAQxgaYwgaMwgZ0xCzAJBgNV BAYTAlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoT EEN1ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkq hkiG9w0BCQEWIGN1c3RvbWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0AgEIMIG2BgsqhkiG 9w0BCRACCzGBpqCBozCBnTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExEjAQBgNV BAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExMQzEcMBoGA1UEAxMTQ3Vk YSBTeXN0ZW1zIExMQyBDQTEvMC0GCSqGSIb3DQEJARYgY3VzdG9tZXItc2VydmljZUBjdWRh c3lzdGVtcy5uZXQCAQgwDQYJKoZIhvcNAQEBBQAEggIANBfQ6uLNK3dXOScbHJP5DDWzoqV1 AcsCmgz8K5NFgBfu49q5HPUnHYMWBa00y9I6gJ3fna+qjoy+UQSKfn9Eqll9l8AYtrPH7cOu 2Lsza1KSjGE4Z2HKxvxQyyX8h2UVEOmicydz3o/hsvRmDEmXIyo4MGzzSmbZZxNr8nJApeLD U4akXG9Fq05LIzI/bkop/uwD4iZf8gyn+nhHKHVc8jSJBm7aagUGG9MoTylHW1GN9I4bV5R9 Kl6PIGFaMGsjPlkWPsyh9ydcgwxaJqk+51E9HxFAKPmc+RvsiUlswL2j0j8uiNULl+EDFrKN IWzob+FJ0NxnueQxNMRWsN+O4z4/aS4659/DtQKydeDz+KQU8JXphtJtGzGBz25c5mOpCNdB xnbQ3kbZhsIWC7qkkJu813WIW0GxnvbOR/FALbYbSQyA0Zxzn92dIycQyaWXIjA1oUoKCTFB CWxiSv9zjxgjbQqVSsyu2r+DY9cGG7GYfJpxkrCQgJwkV69qq21KQPLlCNAmc69b4wQi+W0U B0x+WQNxw6U2ZwFDOnIDSiwYzp1DPhaxjV8fKShdKvj8exmMFOHlq/gST32J1tQrRHowNQki TvrxiIGS8sqE0L3/AnWdUhna00ocaOSJQ5nbSYzw/Cy7qKC2Y4dnrazqPKTfgxXobMrliy0m 3qptdwIAAAAAAAA= --------------ms050806050102070608030701-- From owner-freebsd-stable@FreeBSD.ORG Fri Sep 19 23:43:57 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 948A5CFB for ; Fri, 19 Sep 2014 23:43:57 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 55698BB2 for ; Fri, 19 Sep 2014 23:43:56 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id D189620E7088E; Fri, 19 Sep 2014 23:43:54 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.2 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,RDNS_DYNAMIC,STOX_REPLY_TYPE autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 029B220E7088A; Fri, 19 Sep 2014 23:43:52 +0000 (UTC) Message-ID: From: "Steven Hartland" To: "Karl Denninger" , References: <540FF3C4.6010305@ish.com.au> <54114029.3060507@FreeBSD.org> <2128347.Ah5i0RTCvp@overcee.wemm.org> <541230F1.3060402@digiware.nl> <7D0869A9-C114-4C4F-877A-3FB26AD7737D@scsiguy.com> <607F83CE25104CE09C74935BA9E26485@multiplay.co.uk> <541CBD5B.8050603@denninger.net> Subject: Re: getting to 4K disk blocks in ZFS Date: Sat, 20 Sep 2014 00:43:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 23:43:57 -0000 ----- Original Message ----- From: "Karl Denninger" > >> I'm surprised that we have to constantly add quirks. Are these > >> drives really > >> failing to report their ata params correctly? Is there a reason we > >> don't > >> currently utilize the ata params data (which is already fetched for > >> trim/unmap > >> detection) to also set lbppbe (logical block per physical block > >> exponent) and > >> lalba (lowest aligned lba)? We may find that many of the existing > >> quirks are > >> unnecessary if we fix the probe code. > > > > On the contary I've not found a single drive which reports 4k sectors > > on its > > own, every single one that I've seen report 4k is because we've added a > > quirk for it :( > > > > > Where is Smartctl getting it from? > > smartctl -i /dev/da2 > smartctl 6.3 2014-07-26 r3976 [FreeBSD 10.1-BETA1 amd64] (local build) > Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org > > === START OF INFORMATION SECTION === > Device Model: HGST HDN724040ALE640 > Serial Number: PK2334PCG6NA0B > LU WWN Device Id: 5 000cca 24cc30684 > Firmware Version: MJAOA5E0 > User Capacity: 4,000,787,030,016 bytes [4.00 TB] > Sector Sizes: 512 bytes logical, 4096 bytes physical > Rotation Rate: 7200 rpm > Form Factor: 3.5 inches > Device is: Not in smartctl database [for details use: -P showall] > ATA Version is: ATA8-ACS T13/1699-D revision 4 > SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s) > Local Time is: Fri Sep 19 18:33:16 2014 CDT > SMART support is: Available - device has SMART capability. > SMART support is: Enabled > > It's not coming from a database, as Smartctl doesn't know about these > (yet); they're too new. Exception to prove the rule? What to "camcontrol identify da2" report? Regards Steve From owner-freebsd-stable@FreeBSD.ORG Fri Sep 19 23:56:42 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9AD4CF15 for ; Fri, 19 Sep 2014 23:56:42 +0000 (UTC) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "NewFS.denninger.net", Issuer "NewFS.denninger.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 33C76CA5 for ; Fri, 19 Sep 2014 23:56:41 +0000 (UTC) Received: from [192.168.1.40] (localhost [127.0.0.1]) by fs.denninger.net (8.14.9/8.14.8) with ESMTP id s8JNueXW009797 for ; Fri, 19 Sep 2014 18:56:40 -0500 (CDT) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (TLS/SSL) [192.168.1.40] by Spamblock-sys (LOCAL/AUTH); Fri Sep 19 18:56:40 2014 Message-ID: <541CC2A4.2060509@denninger.net> Date: Fri, 19 Sep 2014 18:56:20 -0500 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: getting to 4K disk blocks in ZFS References: <540FF3C4.6010305@ish.com.au> <54114029.3060507@FreeBSD.org> <2128347.Ah5i0RTCvp@overcee.wemm.org> <541230F1.3060402@digiware.nl> <7D0869A9-C114-4C4F-877A-3FB26AD7737D@scsiguy.com> <607F83CE25104CE09C74935BA9E26485@multiplay.co.uk> <541CBD5B.8050603@denninger.net> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000506050801090705010103" X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 23:56:42 -0000 This is a cryptographically signed message in MIME format. --------------ms000506050801090705010103 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 9/19/2014 6:43 PM, Steven Hartland wrote: > > ----- Original Message ----- From: "Karl Denninger" > >> >> I'm surprised that we have to constantly add quirks. Are these >> >> drives really >> >> failing to report their ata params correctly? Is there a reason we= >> >> don't >> >> currently utilize the ata params data (which is already fetched for= >> >> trim/unmap >> >> detection) to also set lbppbe (logical block per physical block >> >> exponent) and >> >> lalba (lowest aligned lba)? We may find that many of the existing >> >> quirks are >> >> unnecessary if we fix the probe code. >> > >> > On the contary I've not found a single drive which reports 4k sector= s >> > on its >> > own, every single one that I've seen report 4k is because we've >> added a >> > quirk for it :( >> > >> > >> Where is Smartctl getting it from? >> >> smartctl -i /dev/da2 >> smartctl 6.3 2014-07-26 r3976 [FreeBSD 10.1-BETA1 amd64] (local build)= >> Copyright (C) 2002-14, Bruce Allen, Christian Franke, >> www.smartmontools.org >> >> =3D=3D=3D START OF INFORMATION SECTION =3D=3D=3D >> Device Model: HGST HDN724040ALE640 >> Serial Number: PK2334PCG6NA0B >> LU WWN Device Id: 5 000cca 24cc30684 >> Firmware Version: MJAOA5E0 >> User Capacity: 4,000,787,030,016 bytes [4.00 TB] >> Sector Sizes: 512 bytes logical, 4096 bytes physical >> Rotation Rate: 7200 rpm >> Form Factor: 3.5 inches >> Device is: Not in smartctl database [for details use: -P showal= l] >> ATA Version is: ATA8-ACS T13/1699-D revision 4 >> SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s) >> Local Time is: Fri Sep 19 18:33:16 2014 CDT >> SMART support is: Available - device has SMART capability. >> SMART support is: Enabled >> >> It's not coming from a database, as Smartctl doesn't know about these >> (yet); they're too new. > > Exception to prove the rule? > > What to "camcontrol identify da2" report? > > Regards > Steve Not an exception! _*All*_ of my 4k block drives report so on smartctl. It was possible some of those were in the database that way (they say they are) but these are not, and I have a number of them from different vendors and series. (Seagates, HGSTs, etc.) [root@NewFS /disk/karl]# camcontrol identify da2 pass2: ATA-8 SATA 3.x device pass2: 600.000MB/s transfers, Command Queueing Enabled protocol ATA/ATAPI-8 SATA 3.x device model HGST HDN724040ALE640 firmware revision MJAOA5E0 serial number PK2334PCG6NA0B WWN 5000cca24cc30684 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 4096, offset 0 LBA supported 268435455 sectors LBA48 supported 7814037168 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM 7200 Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags NCQ Queue Management no NCQ Streaming no Receive & Send FPDMA Queued no SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management yes no 0/0x00 automatic acoustic management no no media status notification no no power-up in Standby yes no write-read-verify no no unload no no general purpose logging yes yes free-fall no no Data Set Management (DSM/TRIM) no Host Protected Area (HPA) yes no 7814037168/7814037168 HPA - Security no NEXT! --=20 Karl Denninger karl@denninger.net /The Market Ticker/ --------------ms000506050801090705010103 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFTzCC BUswggQzoAMCAQICAQgwDQYJKoZIhvcNAQEFBQAwgZ0xCzAJBgNVBAYTAlVTMRAwDgYDVQQI EwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkqhkiG9w0BCQEWIGN1c3Rv bWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0MB4XDTEzMDgyNDE5MDM0NFoXDTE4MDgyMzE5 MDM0NFowWzELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExFzAVBgNVBAMTDkthcmwg RGVubmluZ2VyMSEwHwYJKoZIhvcNAQkBFhJrYXJsQGRlbm5pbmdlci5uZXQwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC5n2KBrBmG22nVntVdvgKCB9UcnapNThrW1L+dq6th d9l4mj+qYMUpJ+8I0rTbY1dn21IXQBoBQmy8t1doKwmTdQ59F0FwZEPt/fGbRgBKVt3Quf6W 6n7kRk9MG6gdD7V9vPpFV41e+5MWYtqGWY3ScDP8SyYLjL/Xgr+5KFKkDfuubK8DeNqdLniV jHo/vqmIgO+6NgzPGPgmbutzFQXlxUqjiNAAKzF2+Tkddi+WKABrcc/EqnBb0X8GdqcIamO5 SyVmuM+7Zdns7D9pcV16zMMQ8LfNFQCDvbCuuQKMDg2F22x5ekYXpwjqTyfjcHBkWC8vFNoY 5aFMdyiN/Kkz0/kduP2ekYOgkRqcShfLEcG9SQ4LQZgqjMpTjSOGzBr3tOvVn5LkSJSHW2Z8 Q0dxSkvFG2/lsOWFbwQeeZSaBi5vRZCYCOf5tRd1+E93FyQfpt4vsrXshIAk7IK7f0qXvxP4 GDli5PKIEubD2Bn+gp3vB/DkfKySh5NBHVB+OPCoXRUWBkQxme65wBO02OZZt0k8Iq0i4Rci WV6z+lQHqDKtaVGgMsHn6PoeYhjf5Al5SP+U3imTjF2aCca1iDB5JOccX04MNljvifXgcbJN nkMgrzmm1ZgJ1PLur/ADWPlnz45quOhHg1TfUCLfI/DzgG7Z6u+oy4siQuFr9QT0MQIDAQAB o4HWMIHTMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIF4DAsBglg hkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHw4 +LnuALyLA5Cgy7T5ZAX1WzKPMB8GA1UdIwQYMBaAFF3U3hpBZq40HB5VM7B44/gmXiI0MDgG CWCGSAGG+EIBAwQrFilodHRwczovL2N1ZGFzeXN0ZW1zLm5ldDoxMTQ0My9yZXZva2VkLmNy bDANBgkqhkiG9w0BAQUFAAOCAQEAZ0L4tQbBd0hd4wuw/YVqEBDDXJ54q2AoqQAmsOlnoxLO 31ehM/LvrTIP4yK2u1VmXtUumQ4Ao15JFM+xmwqtEGsh70RRrfVBAGd7KOZ3GB39FP2TgN/c L5fJKVxOqvEnW6cL9QtvUlcM3hXg8kDv60OB+LIcSE/P3/s+0tEpWPjxm3LHVE7JmPbZIcJ1 YMoZvHh0NSjY5D0HZlwtbDO7pDz9sZf1QEOgjH828fhtborkaHaUI46pmrMjiBnY6ujXMcWD pxtikki0zY22nrxfTs5xDWGxyrc/cmucjxClJF6+OYVUSaZhiiHfa9Pr+41okLgsRB0AmNwE f6ItY3TI8DGCBQowggUGAgEBMIGjMIGdMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxvcmlk YTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRwwGgYD VQQDExNDdWRhIFN5c3RlbXMgTExDIENBMS8wLQYJKoZIhvcNAQkBFiBjdXN0b21lci1zZXJ2 aWNlQGN1ZGFzeXN0ZW1zLm5ldAIBCDAJBgUrDgMCGgUAoIICOzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA5MTkyMzU2MjBaMCMGCSqGSIb3DQEJBDEW BBTl6lyV5ujrz8e3hJynVTE7F0TIszBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG0BgkrBgEEAYI3EAQxgaYwgaMwgZ0xCzAJBgNV BAYTAlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoT EEN1ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkq hkiG9w0BCQEWIGN1c3RvbWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0AgEIMIG2BgsqhkiG 9w0BCRACCzGBpqCBozCBnTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExEjAQBgNV BAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExMQzEcMBoGA1UEAxMTQ3Vk YSBTeXN0ZW1zIExMQyBDQTEvMC0GCSqGSIb3DQEJARYgY3VzdG9tZXItc2VydmljZUBjdWRh c3lzdGVtcy5uZXQCAQgwDQYJKoZIhvcNAQEBBQAEggIAH+yxyOyK85SS69sribAdFR0ir1X4 Z5w0zhCSvt6QuqPWCc0GcpX4vXjuIPp2+nj/CytaSjnebAZSpIH6Xba/5Xv+6f45TFO8Vxa8 J8BbqcL9AxfcXMROXjZ70vZOxiolFm7FPUB4da4rJEKZaUb2yQf1Lgem5yiy8n3kWJ+Op2BP OooeKznVSwygJtr2jzM+STRG6jxbtyVB4NPV+4AAJE2PQjSjdQZfH5qCHVQUbaxTVRXb84Zj y1MJy+6Xu6OjtpdpzSnmy9VEr8kYMjOQejQ21tBGJmwtMoOmf07rNuRm7neXTYhGXTMwo84P qJ3FGnRHzhydyNG+0lHTSxN+VKEnWdJSaaM4vKxOolpp9WqQobKL/85rlWbGx6qXKdvFVBnd OcOUB6YHdHHeziN1VlG9DH88niPAyHbHNza2bI+wuCACi6Io1QtG6yaJrdz0/yUv+qAs++NA oSJtjIfaiHHcV0y2VeT6bRJ4vKr3yreGsdlCUAWimuAE5nnDMjgKxcvwKF69x+MSBTYJE/CM SDLmwGO0nNBqJ6wpFOZfKpWg7/cQyvLm60XdZh7svA3Cr0GpYBveGd95nVsWTGdREfcZgxno EAIJbcW+dWK/ZmYzy+iXMhyjpS+H6aFjFtmvtDJ1CzxwSiJ9JWZItE4ArFwHdzhq3vpWRHlJ v7Eu5zgAAAAAAAA= --------------ms000506050801090705010103-- From owner-freebsd-stable@FreeBSD.ORG Fri Sep 19 23:59:33 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04C16F8 for ; Fri, 19 Sep 2014 23:59:33 +0000 (UTC) Received: from aslan.scsiguy.com (mail.scsiguy.com [70.89.174.89]) (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 AA487CC9 for ; Fri, 19 Sep 2014 23:59:31 +0000 (UTC) Received: from jt-mbp.sldomain.com (slboulder.spectralogic.com [192.30.190.3] (may be forged)) (authenticated bits=0) by aslan.scsiguy.com (8.14.9/8.14.9) with ESMTP id s8JNxIVV060969 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Sep 2014 17:59:20 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Subject: Re: getting to 4K disk blocks in ZFS Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: "Justin T. Gibbs" X-Priority: 3 In-Reply-To: Date: Fri, 19 Sep 2014 17:59:12 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <82FFB2B2-F1D7-422A-BA92-9AFE95678390@scsiguy.com> References: <540FF3C4.6010305@ish.com.au> <54114029.3060507@FreeBSD.org> <2128347.Ah5i0RTCvp@overcee.wemm.org> <541230F1.3060402@digiware.nl> <7D0869A9-C114-4C4F-877A-3FB26AD7737D@scsiguy.com> <607F83CE25104CE09C74935BA9E26485@multiplay.co.uk> <541CBD5B.8050603@denninger.net> To: Steven Hartland X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-stable@freebsd.org, Karl Denninger X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 23:59:33 -0000 On Sep 19, 2014, at 5:43 PM, Steven Hartland = wrote: >=20 > ----- Original Message ----- From: "Karl Denninger" = >=20 >> >> I'm surprised that we have to constantly add quirks. Are these >> >> drives really >> >> failing to report their ata params correctly? Is there a reason = we >> >> don't >> >> currently utilize the ata params data (which is already fetched = for >> >> trim/unmap >> >> detection) to also set lbppbe (logical block per physical block >> >> exponent) and >> >> lalba (lowest aligned lba)? We may find that many of the existing >> >> quirks are >> >> unnecessary if we fix the probe code. >> > >> > On the contary I've not found a single drive which reports 4k = sectors >> > on its >> > own, every single one that I've seen report 4k is because we've = added a >> > quirk for it :( >> > >> > >> Where is Smartctl getting it from? >> smartctl -i /dev/da2 >> smartctl 6.3 2014-07-26 r3976 [FreeBSD 10.1-BETA1 amd64] (local = build) >> Copyright (C) 2002-14, Bruce Allen, Christian Franke, = www.smartmontools.org >> =3D=3D=3D START OF INFORMATION SECTION =3D=3D=3D >> Device Model: HGST HDN724040ALE640 >> Serial Number: PK2334PCG6NA0B >> LU WWN Device Id: 5 000cca 24cc30684 >> Firmware Version: MJAOA5E0 >> User Capacity: 4,000,787,030,016 bytes [4.00 TB] >> Sector Sizes: 512 bytes logical, 4096 bytes physical >> Rotation Rate: 7200 rpm >> Form Factor: 3.5 inches >> Device is: Not in smartctl database [for details use: -P = showall] >> ATA Version is: ATA8-ACS T13/1699-D revision 4 >> SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s) >> Local Time is: Fri Sep 19 18:33:16 2014 CDT >> SMART support is: Available - device has SMART capability. >> SMART support is: Enabled >> It's not coming from a database, as Smartctl doesn't know about these >> (yet); they're too new. >=20 > Exception to prove the rule? >=20 > What to "camcontrol identify da2" report? Was there some recent change made to have that command report sector = size information? Last I checked, it didn=92t. =97 Justin= From owner-freebsd-stable@FreeBSD.ORG Sat Sep 20 00:04:50 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DED622B0; Sat, 20 Sep 2014 00:04:50 +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 AC4B4D81; Sat, 20 Sep 2014 00:04:50 +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=fIBYr9f3/z3gPSvhYoZdAZe4RA25xj2UypTcwxnKsyw=; b=ufWKjHFAqOIPSFNyhbNjOh8yBoLjApwdBS8e58LVnEWEUs4lq2Itkdrtt3tVpKRa/NO/7DSQTYd2Tp4dRh9BJ0AetLHEBYuYzERt0nFmMtCcsZ5jZc38GZhWH5X0TMHh/xGQspe/I4gK08HYGSPoSw+MysfiiQb0sBtr1em2pyQ=; Received: from localhost.lerctr.org ([127.0.0.1]:62031 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XV8AQ-0002XT-Gm; Fri, 19 Sep 2014 19:04:48 -0500 Received: from 104-54-221-134.lightspeed.austtx.sbcglobal.net ([104.54.221.134]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Fri, 19 Sep 2014 19:04:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 19 Sep 2014 19:04:46 -0500 From: Larry Rosenman To: "Justin T. Gibbs" Subject: Re: getting to 4K disk blocks in ZFS In-Reply-To: <82FFB2B2-F1D7-422A-BA92-9AFE95678390@scsiguy.com> References: <540FF3C4.6010305@ish.com.au> <54114029.3060507@FreeBSD.org> <2128347.Ah5i0RTCvp@overcee.wemm.org> <541230F1.3060402@digiware.nl> <7D0869A9-C114-4C4F-877A-3FB26AD7737D@scsiguy.com> <607F83CE25104CE09C74935BA9E26485@multiplay.co.uk> <541CBD5B.8050603@denninger.net> <82FFB2B2-F1D7-422A-BA92-9AFE95678390@scsiguy.com> Message-ID: <5fe62fbb45ec5fa66776266e9985915c@thebighonker.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.0.2 X-Spam-Score: -3.6 (---) X-LERCTR-Spam-Score: -3.6 (---) X-Spam-Report: SpamScore (-3.6/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.655 X-LERCTR-Spam-Report: SpamScore (-3.6/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.655 Cc: owner-freebsd-stable@freebsd.org, freebsd-stable@freebsd.org, Steven Hartland , Karl Denninger X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 00:04:51 -0000 On 2014-09-19 18:59, Justin T. Gibbs wrote: > On Sep 19, 2014, at 5:43 PM, Steven Hartland > wrote: > >> >> ----- Original Message ----- From: "Karl Denninger" >> >> >>> >> I'm surprised that we have to constantly add quirks. Are these >>> >> drives really >>> >> failing to report their ata params correctly? Is there a reason we >>> >> don't >>> >> currently utilize the ata params data (which is already fetched for >>> >> trim/unmap >>> >> detection) to also set lbppbe (logical block per physical block >>> >> exponent) and >>> >> lalba (lowest aligned lba)? We may find that many of the existing >>> >> quirks are >>> >> unnecessary if we fix the probe code. >>> > >>> > On the contary I've not found a single drive which reports 4k sectors >>> > on its >>> > own, every single one that I've seen report 4k is because we've added a >>> > quirk for it :( >>> > >>> > >>> Where is Smartctl getting it from? >>> smartctl -i /dev/da2 >>> smartctl 6.3 2014-07-26 r3976 [FreeBSD 10.1-BETA1 amd64] (local >>> build) >>> Copyright (C) 2002-14, Bruce Allen, Christian Franke, >>> www.smartmontools.org >>> === START OF INFORMATION SECTION === >>> Device Model: HGST HDN724040ALE640 >>> Serial Number: PK2334PCG6NA0B >>> LU WWN Device Id: 5 000cca 24cc30684 >>> Firmware Version: MJAOA5E0 >>> User Capacity: 4,000,787,030,016 bytes [4.00 TB] >>> Sector Sizes: 512 bytes logical, 4096 bytes physical >>> Rotation Rate: 7200 rpm >>> Form Factor: 3.5 inches >>> Device is: Not in smartctl database [for details use: -P >>> showall] >>> ATA Version is: ATA8-ACS T13/1699-D revision 4 >>> SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s) >>> Local Time is: Fri Sep 19 18:33:16 2014 CDT >>> SMART support is: Available - device has SMART capability. >>> SMART support is: Enabled >>> It's not coming from a database, as Smartctl doesn't know about these >>> (yet); they're too new. >> >> Exception to prove the rule? >> >> What to "camcontrol identify da2" report? > > Was there some recent change made to have that command report sector > size information? Last I checked, it didn’t. borg.lerctr.org /home/ler $ sudo camcontrol identify ada0 pass1: ATA-8 SATA 3.x device pass1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) protocol ATA/ATAPI-8 SATA 3.x device model ST2000DL003-9VT166 firmware revision CC32 serial number 5YDA1ZL4 WWN 5000c50053825268 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 268435455 sectors LBA48 supported 3907029168 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM 5900 Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags NCQ Queue Management no NCQ Streaming no Receive & Send FPDMA Queued no SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no automatic acoustic management yes yes 0/0x00 254/0xFE media status notification no no power-up in Standby no no write-read-verify yes no 0/0x0 unload no no general purpose logging yes yes free-fall no no Data Set Management (DSM/TRIM) no Host Protected Area (HPA) yes no 3907029168/3907029168 HPA - Security no borg.lerctr.org /home/ler $ sudo camcontrol identify ada1 pass2: ATA-8 SATA 3.x device pass2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) protocol ATA/ATAPI-8 SATA 3.x device model ST2000DL003-9VT166 firmware revision CC3D serial number 5YD6FPLG WWN 5000c500469a1d07 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 4096, offset 0 LBA supported 268435455 sectors LBA48 supported 3907029168 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM 5900 Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags NCQ Queue Management no NCQ Streaming no Receive & Send FPDMA Queued no SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no automatic acoustic management yes yes 0/0x00 254/0xFE media status notification no no power-up in Standby no no write-read-verify yes no 0/0x0 unload no no general purpose logging yes yes free-fall no no Data Set Management (DSM/TRIM) no Host Protected Area (HPA) yes no 3907029168/3907029168 HPA - Security no borg.lerctr.org /home/ler $ > > — > Justin > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org" -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-stable@FreeBSD.ORG Sat Sep 20 00:06:40 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B2C03E5; Sat, 20 Sep 2014 00:06:40 +0000 (UTC) Received: from mail.in-addr.com (mail.in-addr.com [IPv6:2a01:4f8:191:61e8::2525:2525]) (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 96233DA5; Sat, 20 Sep 2014 00:06:39 +0000 (UTC) Received: from gjp by mail.in-addr.com with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XV8CC-0003GW-Jd; Sat, 20 Sep 2014 01:06:36 +0100 Date: Sat, 20 Sep 2014 01:06:36 +0100 From: Gary Palmer To: Steven Hartland Subject: Re: getting to 4K disk blocks in ZFS Message-ID: <20140920000636.GD51285@in-addr.com> References: <540FF3C4.6010305@ish.com.au> <54114029.3060507@FreeBSD.org> <2128347.Ah5i0RTCvp@overcee.wemm.org> <541230F1.3060402@digiware.nl> <7D0869A9-C114-4C4F-877A-3FB26AD7737D@scsiguy.com> <607F83CE25104CE09C74935BA9E26485@multiplay.co.uk> <541CBD5B.8050603@denninger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on mail.in-addr.com); SAEximRunCond expanded to false Cc: freebsd-stable@freebsd.org, Karl Denninger X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 00:06:40 -0000 On Sat, Sep 20, 2014 at 12:43:46AM +0100, Steven Hartland wrote: > > ----- Original Message ----- > From: "Karl Denninger" > > > >> I'm surprised that we have to constantly add quirks. Are these > > >> drives really > > >> failing to report their ata params correctly? Is there a reason we > > >> don't > > >> currently utilize the ata params data (which is already fetched for > > >> trim/unmap > > >> detection) to also set lbppbe (logical block per physical block > > >> exponent) and > > >> lalba (lowest aligned lba)? We may find that many of the existing > > >> quirks are > > >> unnecessary if we fix the probe code. > > > > > > On the contary I've not found a single drive which reports 4k sectors > > > on its > > > own, every single one that I've seen report 4k is because we've added a > > > quirk for it :( > > > > > > > > Where is Smartctl getting it from? > > > > smartctl -i /dev/da2 > > smartctl 6.3 2014-07-26 r3976 [FreeBSD 10.1-BETA1 amd64] (local build) > > Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org > > > > === START OF INFORMATION SECTION === > > Device Model: HGST HDN724040ALE640 > > Serial Number: PK2334PCG6NA0B > > LU WWN Device Id: 5 000cca 24cc30684 > > Firmware Version: MJAOA5E0 > > User Capacity: 4,000,787,030,016 bytes [4.00 TB] > > Sector Sizes: 512 bytes logical, 4096 bytes physical > > Rotation Rate: 7200 rpm > > Form Factor: 3.5 inches > > Device is: Not in smartctl database [for details use: -P showall] > > ATA Version is: ATA8-ACS T13/1699-D revision 4 > > SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s) > > Local Time is: Fri Sep 19 18:33:16 2014 CDT > > SMART support is: Available - device has SMART capability. > > SMART support is: Enabled > > > > It's not coming from a database, as Smartctl doesn't know about these > > (yet); they're too new. > > Exception to prove the rule? > > What to "camcontrol identify da2" report? I have some WD Red drives: ada2 at ahcich2 bus 0 scbus2 target 0 lun 0 ada2: ATA-9 SATA 3.x device ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: Command Queueing enabled ada2: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C) ada2: quirks=0x1<4K> Note the quirk. If I tell smartctl to ignore it's database it still says it's a 4k AF drive $ smartctl -B /dev/null -i /dev/ada2 smartctl 6.3 2014-07-26 r3976 [FreeBSD 9.2-RELEASE-p10 amd64] (local build) Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Device Model: WDC WD30EFRX-68AX9N0 Serial Number: WD-WMC1T1329542 LU WWN Device Id: 5 0014ee 058cdc1f7 Firmware Version: 80.00A80 User Capacity: 3,000,592,982,016 bytes [3.00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Device is: Not in smartctl database [for details use: -P showall] ATA Version is: ACS-2 (minor revision not indicated) SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s) Local Time is: Sat Sep 20 01:01:41 2014 BST SMART support is: Available - device has SMART capability. SMART support is: Enabled $ camcontrol identify ada2 pass2: ATA-9 SATA 3.x device pass2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) protocol ATA/ATAPI-9 SATA 3.x device model WDC WD30EFRX-68AX9N0 firmware revision 80.00A80 serial number WD-WMC1T1329542 WWN 50014ee058cdc1f7 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 4096, offset 0 LBA supported 268435455 sectors LBA48 supported 5860533168 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no automatic acoustic management no no media status notification no no power-up in Standby yes no write-read-verify no no unload no no free-fall no no Data Set Management (DSM/TRIM) no Host Protected Area (HPA) yes no 5860533168/5860533168 HPA - Security no I'm not sure if camcontrol is getting it's data from the kernel (and therefore may be affected by the quirk) or not? I've got a similar story for some WD Green AF drives on a different box ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: Serial Number WD-WCAWZ2071970 ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C) ada0: quirks=0x1<4K> $ smartctl -B /dev/null -i /dev/ada0 smartctl 6.3 2014-07-26 r3976 [FreeBSD 9.3-RELEASE-p1 amd64] (local build) Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Device Model: WDC WD30EZRX-00MMMB0 Serial Number: WD-WCAWZ2071970 LU WWN Device Id: 5 0014ee 2b17b776d Firmware Version: 80.00A80 User Capacity: 3,000,592,982,016 bytes [3.00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Device is: Not in smartctl database [for details use: -P showall] ATA Version is: ATA8-ACS (minor revision not indicated) SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s) Local Time is: Sat Sep 20 01:04:44 2014 BST SMART support is: Available - device has SMART capability. SMART support is: Enabled $ camcontrol identify ada0 pass0: ATA-8 SATA 3.x device pass0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) protocol ATA/ATAPI-8 SATA 3.x device model WDC WD30EZRX-00MMMB0 firmware revision 80.00A80 serial number WD-WCAWZ2071970 WWN 50014ee2b17b776d cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 4096, offset 0 LBA supported 268435455 sectors LBA48 supported 5860533168 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags NCQ Queue Management no NCQ Streaming no Receive & Send FPDMA Queued no SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no automatic acoustic management no no media status notification no no power-up in Standby yes no write-read-verify no no unload no no general purpose logging yes yes free-fall no no Data Set Management (DSM/TRIM) no Host Protected Area (HPA) yes no 5860533168/5860533168 HPA - Security no Regards, Gary From owner-freebsd-stable@FreeBSD.ORG Sat Sep 20 00:16:03 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 98B2E5B9; Sat, 20 Sep 2014 00:16:03 +0000 (UTC) Received: from mail.in-addr.com (mail.in-addr.com [IPv6:2a01:4f8:191:61e8::2525:2525]) (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 29F3DE7C; Sat, 20 Sep 2014 00:16:03 +0000 (UTC) Received: from gjp by mail.in-addr.com with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XV8LJ-0003IZ-Bd; Sat, 20 Sep 2014 01:16:01 +0100 Date: Sat, 20 Sep 2014 01:16:01 +0100 From: Gary Palmer To: Steven Hartland Subject: Re: getting to 4K disk blocks in ZFS Message-ID: <20140920001601.GE51285@in-addr.com> References: <540FF3C4.6010305@ish.com.au> <54114029.3060507@FreeBSD.org> <2128347.Ah5i0RTCvp@overcee.wemm.org> <541230F1.3060402@digiware.nl> <7D0869A9-C114-4C4F-877A-3FB26AD7737D@scsiguy.com> <607F83CE25104CE09C74935BA9E26485@multiplay.co.uk> <541CBD5B.8050603@denninger.net> <20140920000636.GD51285@in-addr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140920000636.GD51285@in-addr.com> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on mail.in-addr.com); SAEximRunCond expanded to false Cc: freebsd-stable@freebsd.org, Karl Denninger X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 00:16:03 -0000 On Sat, Sep 20, 2014 at 01:06:36AM +0100, Gary Palmer wrote: > On Sat, Sep 20, 2014 at 12:43:46AM +0100, Steven Hartland wrote: > > > > ----- Original Message ----- > > From: "Karl Denninger" > > > > > >> I'm surprised that we have to constantly add quirks. Are these > > > >> drives really > > > >> failing to report their ata params correctly? Is there a reason we > > > >> don't > > > >> currently utilize the ata params data (which is already fetched for > > > >> trim/unmap > > > >> detection) to also set lbppbe (logical block per physical block > > > >> exponent) and > > > >> lalba (lowest aligned lba)? We may find that many of the existing > > > >> quirks are > > > >> unnecessary if we fix the probe code. > > > > > > > > On the contary I've not found a single drive which reports 4k sectors > > > > on its > > > > own, every single one that I've seen report 4k is because we've added a > > > > quirk for it :( > > > > > > > > > > > Where is Smartctl getting it from? > > > > > > smartctl -i /dev/da2 > > > smartctl 6.3 2014-07-26 r3976 [FreeBSD 10.1-BETA1 amd64] (local build) > > > Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org > > > > > > === START OF INFORMATION SECTION === > > > Device Model: HGST HDN724040ALE640 > > > Serial Number: PK2334PCG6NA0B > > > LU WWN Device Id: 5 000cca 24cc30684 > > > Firmware Version: MJAOA5E0 > > > User Capacity: 4,000,787,030,016 bytes [4.00 TB] > > > Sector Sizes: 512 bytes logical, 4096 bytes physical > > > Rotation Rate: 7200 rpm > > > Form Factor: 3.5 inches > > > Device is: Not in smartctl database [for details use: -P showall] > > > ATA Version is: ATA8-ACS T13/1699-D revision 4 > > > SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s) > > > Local Time is: Fri Sep 19 18:33:16 2014 CDT > > > SMART support is: Available - device has SMART capability. > > > SMART support is: Enabled > > > > > > It's not coming from a database, as Smartctl doesn't know about these > > > (yet); they're too new. > > > > Exception to prove the rule? > > > > What to "camcontrol identify da2" report? > > I have some WD Red drives: > > ada2 at ahcich2 bus 0 scbus2 target 0 lun 0 > ada2: ATA-9 SATA 3.x device > ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada2: Command Queueing enabled > ada2: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C) > ada2: quirks=0x1<4K> > > Note the quirk. > > If I tell smartctl to ignore it's database it still says it's a 4k > AF drive > > $ smartctl -B /dev/null -i /dev/ada2 > smartctl 6.3 2014-07-26 r3976 [FreeBSD 9.2-RELEASE-p10 amd64] (local build) > Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org > > === START OF INFORMATION SECTION === > Device Model: WDC WD30EFRX-68AX9N0 > Serial Number: WD-WMC1T1329542 > LU WWN Device Id: 5 0014ee 058cdc1f7 > Firmware Version: 80.00A80 > User Capacity: 3,000,592,982,016 bytes [3.00 TB] > Sector Sizes: 512 bytes logical, 4096 bytes physical > Device is: Not in smartctl database [for details use: -P showall] > ATA Version is: ACS-2 (minor revision not indicated) > SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s) > Local Time is: Sat Sep 20 01:01:41 2014 BST > SMART support is: Available - device has SMART capability. > SMART support is: Enabled > > $ camcontrol identify ada2 > pass2: ATA-9 SATA 3.x device > pass2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > > protocol ATA/ATAPI-9 SATA 3.x > device model WDC WD30EFRX-68AX9N0 > firmware revision 80.00A80 > serial number WD-WMC1T1329542 > WWN 50014ee058cdc1f7 > cylinders 16383 > heads 16 > sectors/track 63 > sector size logical 512, physical 4096, offset 0 > LBA supported 268435455 sectors > LBA48 supported 5860533168 sectors > PIO supported PIO4 > DMA supported WDMA2 UDMA6 > > Feature Support Enabled Value Vendor > read ahead yes yes > write cache yes yes > flush cache yes yes > overlap no > Tagged Command Queuing (TCQ) no no > Native Command Queuing (NCQ) yes 32 tags > SMART yes yes > microcode download yes yes > security yes no > power management yes yes > advanced power management no no > automatic acoustic management no no > media status notification no no > power-up in Standby yes no > write-read-verify no no > unload no no > free-fall no no > Data Set Management (DSM/TRIM) no > Host Protected Area (HPA) yes no 5860533168/5860533168 > HPA - Security no > > I'm not sure if camcontrol is getting it's data from the kernel > (and therefore may be affected by the quirk) or not? > > I've got a similar story for some WD Green AF drives on a different box > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-8 SATA 3.x device > ada0: Serial Number WD-WCAWZ2071970 > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C) > ada0: quirks=0x1<4K> > > $ smartctl -B /dev/null -i /dev/ada0 > smartctl 6.3 2014-07-26 r3976 [FreeBSD 9.3-RELEASE-p1 amd64] (local build) > Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org > > === START OF INFORMATION SECTION === > Device Model: WDC WD30EZRX-00MMMB0 > Serial Number: WD-WCAWZ2071970 > LU WWN Device Id: 5 0014ee 2b17b776d > Firmware Version: 80.00A80 > User Capacity: 3,000,592,982,016 bytes [3.00 TB] > Sector Sizes: 512 bytes logical, 4096 bytes physical > Device is: Not in smartctl database [for details use: -P showall] > ATA Version is: ATA8-ACS (minor revision not indicated) > SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s) > Local Time is: Sat Sep 20 01:04:44 2014 BST > SMART support is: Available - device has SMART capability. > SMART support is: Enabled > > $ camcontrol identify ada0 > pass0: ATA-8 SATA 3.x device > pass0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > > protocol ATA/ATAPI-8 SATA 3.x > device model WDC WD30EZRX-00MMMB0 > firmware revision 80.00A80 > serial number WD-WCAWZ2071970 > WWN 50014ee2b17b776d > cylinders 16383 > heads 16 > sectors/track 63 > sector size logical 512, physical 4096, offset 0 > LBA supported 268435455 sectors > LBA48 supported 5860533168 sectors > PIO supported PIO4 > DMA supported WDMA2 UDMA6 > > Feature Support Enabled Value Vendor > read ahead yes yes > write cache yes yes > flush cache yes yes > overlap no > Tagged Command Queuing (TCQ) no no > Native Command Queuing (NCQ) yes 32 tags > NCQ Queue Management no > NCQ Streaming no > Receive & Send FPDMA Queued no > SMART yes yes > microcode download yes yes > security yes no > power management yes yes > advanced power management no no > automatic acoustic management no no > media status notification no no > power-up in Standby yes no > write-read-verify no no > unload no no > general purpose logging yes yes > free-fall no no > Data Set Management (DSM/TRIM) no > Host Protected Area (HPA) yes no 5860533168/5860533168 > HPA - Security no Actually, just found another couple of drives I didn't check were AF, and aren't detected as such by the 9.2 kernel - so my zpool is now ashift=9 and wrong :-( Explains some of the performance I was seeing. ada0: ATA-8 SATA 3.x device ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 % camcontrol identify ada0 pass0: ATA-8 SATA 3.x device pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) protocol ATA/ATAPI-8 SATA 3.x device model TOSHIBA DT01ACA300 firmware revision MX6OABB0 serial number 13F7R9BGS WWN 5000039ff4c38251 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 4096, offset 0 LBA supported 268435455 sectors LBA48 supported 5860533168 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM 7200 Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management yes no 0/0x00 automatic acoustic management no no media status notification no no power-up in Standby yes no write-read-verify no no unload no no free-fall no no Data Set Management (DSM/TRIM) no Host Protected Area (HPA) yes no 5860533168/5860533168 HPA - Security no % smartctl -B /dev/null -i /dev/ada0 smartctl 6.3 2014-07-26 r3976 [FreeBSD 9.2-RELEASE-p10 amd64] (local build) Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Device Model: TOSHIBA DT01ACA300 Serial Number: 13F7R9BGS LU WWN Device Id: 5 000039 ff4c38251 Firmware Version: MX6OABB0 User Capacity: 3,000,592,982,016 bytes [3.00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Rotation Rate: 7200 rpm Form Factor: 3.5 inches Device is: Not in smartctl database [for details use: -P showall] ATA Version is: ATA8-ACS T13/1699-D revision 4 SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is: Sat Sep 20 01:14:36 2014 BST SMART support is: Available - device has SMART capability. SMART support is: Enabled Regards, Gary From owner-freebsd-stable@FreeBSD.ORG Sat Sep 20 00:21:09 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9D0C8AC for ; Sat, 20 Sep 2014 00:21:09 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 79910F37 for ; Sat, 20 Sep 2014 00:21:09 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id D5A2920E7088F; Sat, 20 Sep 2014 00:21:08 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.8 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,RDNS_DYNAMIC,STOX_REPLY_TYPE,TVD_FINGER_02 autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 8593520E7088A; Sat, 20 Sep 2014 00:21:07 +0000 (UTC) Message-ID: <29D09E99DD8F46ECBB973FDAE7741B0C@multiplay.co.uk> From: "Steven Hartland" To: "Justin T. Gibbs" References: <540FF3C4.6010305@ish.com.au> <54114029.3060507@FreeBSD.org> <2128347.Ah5i0RTCvp@overcee.wemm.org> <541230F1.3060402@digiware.nl> <7D0869A9-C114-4C4F-877A-3FB26AD7737D@scsiguy.com> <607F83CE25104CE09C74935BA9E26485@multiplay.co.uk> <541CBD5B.8050603@denninger.net> <82FFB2B2-F1D7-422A-BA92-9AFE95678390@scsiguy.com> Subject: Re: getting to 4K disk blocks in ZFS Date: Sat, 20 Sep 2014 01:21:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-stable@freebsd.org, Karl Denninger X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 00:21:09 -0000 ----- Original Message ----- > From: "Justin T. Gibbs" > >> Where is Smartctl getting it from? > >> smartctl -i /dev/da2 > >> smartctl 6.3 2014-07-26 r3976 [FreeBSD 10.1-BETA1 amd64] (local build) > >> Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org > >> === START OF INFORMATION SECTION === > >> Device Model: HGST HDN724040ALE640 > >> Serial Number: PK2334PCG6NA0B > >> LU WWN Device Id: 5 000cca 24cc30684 > >> Firmware Version: MJAOA5E0 > >> User Capacity: 4,000,787,030,016 bytes [4.00 TB] > >> Sector Sizes: 512 bytes logical, 4096 bytes physical > >> Rotation Rate: 7200 rpm > >> Form Factor: 3.5 inches > >> Device is: Not in smartctl database [for details use: -P showall] > >> ATA Version is: ATA8-ACS T13/1699-D revision 4 > >> SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s) > >> Local Time is: Fri Sep 19 18:33:16 2014 CDT > >> SMART support is: Available - device has SMART capability. > >> SMART support is: Enabled > >> It's not coming from a database, as Smartctl doesn't know about these > >> (yet); they're too new. > > > > Exception to prove the rule? > > > > What to "camcontrol identify da2" report? > > Was there some recent change made to have that command report sector size > information? Last I checked, it didn’t. camcontrol identify has always done that, but added support for Pass-Through ATA commands so you can use identify on SATA disks attached to SAS controllers a while back now. Regards Steve From owner-freebsd-stable@FreeBSD.ORG Sat Sep 20 06:21:46 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E685C3A8; Sat, 20 Sep 2014 06:21:46 +0000 (UTC) Received: from aslan.scsiguy.com (www.scsiguy.com [70.89.174.89]) (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 B642F171; Sat, 20 Sep 2014 06:21:46 +0000 (UTC) Received: from [192.168.0.61] (jt-mbp.home.scsiguy.org [192.168.0.61]) (authenticated bits=0) by aslan.scsiguy.com (8.14.9/8.14.9) with ESMTP id s8K6LZhF062711 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 20 Sep 2014 00:21:37 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: getting to 4K disk blocks in ZFS From: "Justin T. Gibbs" In-Reply-To: <7D0869A9-C114-4C4F-877A-3FB26AD7737D@scsiguy.com> Date: Sat, 20 Sep 2014 00:21:36 -0600 Message-Id: <9F3CB84B-E0F1-4343-8E37-4E4A9F252C52@scsiguy.com> References: <540FF3C4.6010305@ish.com.au> <54114029.3060507@FreeBSD.org> <2128347.Ah5i0RTCvp@overcee.wemm.org> <541230F1.3060402@digiware.nl> <7D0869A9-C114-4C4F-877A-3FB26AD7737D@scsiguy.com> To: Willem Jan Withagen X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Steven Hartland , freebsd-stable@freebsd.org, Andriy Gapon , Peter Wemm , Aristedes Maniatis X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 06:21:47 -0000 On Sep 19, 2014, at 5:07 PM, Justin T. Gibbs wrote: > On Sep 11, 2014, at 5:32 PM, Willem Jan Withagen = wrote: >=20 >> On 11-9-2014 19:49, Peter Wemm wrote: >>>> Another downside is 1/4th of uberblocks, 32 vs 128. >>>> Also, automatic sector size detection works great for me and I've = never had >>>> a need to manually tweak ashift. >>>=20 >>> Unfortunately, I have. Same drive connected two different ways: >>>=20 >>> da12 at mps1 bus 0 scbus1 target 11 lun 0 >>> da12: Fixed Direct Access SCSI-6 device=20= >>> da12: 600.000MB/s transfers >>> da12: Command Queueing enabled >>> da12: 3815447MB (7814037168 512 byte sectors: 255H 63S/T 486401C) >>>=20 >>> ada1 at ahcich1 bus 0 scbus3 target 0 lun 0 >>> ada1: ATA-8 SATA 3.x device >>> ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) >>> ada1: Command Queueing enabled >>> ada1: 3815447MB (7814037168 512 byte sectors: 16H 63S/T 16383C) >>> ada1: quirks=3D0x1<4K> >>>=20 >>> The 4k flag is missing when it's on the sas controller. The Ident = strings are=20 >>> changed. >>>=20 >>> This came up elsewhere recently. >>=20 >> I reported the same fact for the new set of WD REDs I installed. >> Seems that ada and da have different quirks tables... >> So disks on SATA connectors on the motherboard are diagnosed as being = 4Kb. >> The disks on my twa don't get the quirk and are considered 512b >>=20 >> =97WjW >=20 > I=92m surprised that we have to constantly add quirks. Are these = drives really failing to report their ata params correctly? Is there a = reason we don=92t currently utilize the ata params data (which is = already fetched for trim/unmap detection) to also set lbppbe (logical = block per physical block exponent) and lalba (lowest aligned lba)? We = may find that many of the existing quirks are unnecessary if we fix the = probe code. >=20 > =97 > Justin Here=92s a start at using the ata_params sector size data. I think it = needs to go a bit further and detect situations where the SCSI = controller=92s emulation gets the logical sector size wrong and fail to = attach - but I=92m out of steam for tonight. Note that this patch is against Spectra Logic=92s FreeBSD/stable/10=92ish = tree, so may not apply cleanly for you as is. I can rebase it against = head tomorrow if there is interest and someone else doesn=92t beat me to = it. From owner-freebsd-stable@FreeBSD.ORG Sat Sep 20 07:15:52 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BFD8CB41; Sat, 20 Sep 2014 07:15:52 +0000 (UTC) Received: from aslan.scsiguy.com (www.scsiguy.com [70.89.174.89]) (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 95A6184D; Sat, 20 Sep 2014 07:15:52 +0000 (UTC) Received: from [192.168.0.61] (jt-mbp.home.scsiguy.org [192.168.0.61]) (authenticated bits=0) by aslan.scsiguy.com (8.14.9/8.14.9) with ESMTP id s8K7FkbQ062982 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 20 Sep 2014 01:15:47 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: getting to 4K disk blocks in ZFS From: "Justin T. Gibbs" In-Reply-To: <9F3CB84B-E0F1-4343-8E37-4E4A9F252C52@scsiguy.com> Date: Sat, 20 Sep 2014 01:15:46 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <05BBE286-A6B6-4F82-A06E-57002EFCA4DE@scsiguy.com> References: <540FF3C4.6010305@ish.com.au> <54114029.3060507@FreeBSD.org> <2128347.Ah5i0RTCvp@overcee.wemm.org> <541230F1.3060402@digiware.nl> <7D0869A9-C114-4C4F-877A-3FB26AD7737D@scsiguy.com> <9F3CB84B-E0F1-4343-8E37-4E4A9F252C52@scsiguy.com> To: Willem Jan Withagen X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-stable@freebsd.org, Steven Hartland , Peter Wemm , Andriy Gapon , Aristedes Maniatis X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 07:15:52 -0000 On Sep 20, 2014, at 12:21 AM, Justin T. Gibbs wrote: > On Sep 19, 2014, at 5:07 PM, Justin T. Gibbs = wrote: >=20 >> On Sep 11, 2014, at 5:32 PM, Willem Jan Withagen = wrote: >>=20 >>> On 11-9-2014 19:49, Peter Wemm wrote: >>>>> Another downside is 1/4th of uberblocks, 32 vs 128. >>>>> Also, automatic sector size detection works great for me and I've = never had >>>>> a need to manually tweak ashift. >>>>=20 >>>> Unfortunately, I have. Same drive connected two different ways: >>>>=20 >>>> da12 at mps1 bus 0 scbus1 target 11 lun 0 >>>> da12: Fixed Direct Access SCSI-6 device=20= >>>> da12: 600.000MB/s transfers >>>> da12: Command Queueing enabled >>>> da12: 3815447MB (7814037168 512 byte sectors: 255H 63S/T 486401C) >>>>=20 >>>> ada1 at ahcich1 bus 0 scbus3 target 0 lun 0 >>>> ada1: ATA-8 SATA 3.x device >>>> ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) >>>> ada1: Command Queueing enabled >>>> ada1: 3815447MB (7814037168 512 byte sectors: 16H 63S/T 16383C) >>>> ada1: quirks=3D0x1<4K> >>>>=20 >>>> The 4k flag is missing when it's on the sas controller. The Ident = strings are=20 >>>> changed. >>>>=20 >>>> This came up elsewhere recently. >>>=20 >>> I reported the same fact for the new set of WD REDs I installed. >>> Seems that ada and da have different quirks tables... >>> So disks on SATA connectors on the motherboard are diagnosed as = being 4Kb. >>> The disks on my twa don't get the quirk and are considered 512b >>>=20 >>> =97WjW >>=20 >> I=92m surprised that we have to constantly add quirks. Are these = drives really failing to report their ata params correctly? Is there a = reason we don=92t currently utilize the ata params data (which is = already fetched for trim/unmap detection) to also set lbppbe (logical = block per physical block exponent) and lalba (lowest aligned lba)? We = may find that many of the existing quirks are unnecessary if we fix the = probe code. >>=20 >> =97 >> Justin >=20 >=20 > Here=92s a start at using the ata_params sector size data. I think it = needs to go a bit further and detect situations where the SCSI = controller=92s emulation gets the logical sector size wrong and fail to = attach - but I=92m out of steam for tonight. >=20 > Note that this patch is against Spectra Logic=92s = FreeBSD/stable/10=92ish tree, so may not apply cleanly for you as is. I = can rebase it against head tomorrow if there is interest and someone = else doesn=92t beat me to it. Hmm. Attachments aren=92t allowed? Here=92s the inlined diff. = Hopefully Apple Mail won=92t mangle it. =97 Justin --- //SpectraBSD/stable/sys/cam/ata/ata_all.c 2014-08-01 = 21:08:39.000000000 -0600 +++ /usr/home/justing/perforce/SpectraBSD/sys/cam/ata/ata_all.c = 2014-08-01 21:08:39.000000000 -0600 @@ -335,7 +335,25 @@ printf("<%s %s %s %s>", vendor, product, revision, fw); } =20 +/* (L)ogical (B)locks (P)er (P)hysical (B)lock (E)xponent. */ +uint8_t +ata_lbppbe(struct ata_params *ident_data) +{ + if ((ident_data->pss & ATA_PSS_VALID_MASK) !=3D = ATA_PSS_VALID_VALUE) + return (0); + return (ident_data->pss & ATA_PSS_LSPPS); +} + +/* (L)owest (A)ligned (L)ogical (B)lock (A)ddress. */ uint32_t +ata_lalba(struct ata_params *ident_data) +{ + if ((ident_data->lsalign & 0xc000) !=3D 0x4000) + return (0); + return (ident_data->lsalign & 0x3fff); +} + +uint32_t ata_logical_sector_size(struct ata_params *ident_data) { if ((ident_data->pss & ATA_PSS_VALID_MASK) =3D=3D = ATA_PSS_VALID_VALUE && @@ -346,28 +364,17 @@ return (512); } =20 -uint64_t +uint32_t ata_physical_sector_size(struct ata_params *ident_data) { - if ((ident_data->pss & ATA_PSS_VALID_MASK) =3D=3D = ATA_PSS_VALID_VALUE) { - if (ident_data->pss & ATA_PSS_MULTLS) { - return = ((uint64_t)ata_logical_sector_size(ident_data) * - (1 << (ident_data->pss & ATA_PSS_LSPPS))); - } else { - return = (uint64_t)ata_logical_sector_size(ident_data); - } - } - return (512); + return (ata_logical_sector_size(ident_data) << = ata_lbppbe(ident_data)); } =20 uint64_t ata_logical_sector_offset(struct ata_params *ident_data) { - if ((ident_data->lsalign & 0xc000) =3D=3D 0x4000) { - return ((uint64_t)ata_logical_sector_size(ident_data) * - (ident_data->lsalign & 0x3fff)); - } - return (0); + return ((uint64_t)ata_logical_sector_size(ident_data) * + ata_lalba(ident_data)); } =20 void --- //SpectraBSD/stable/sys/cam/ata/ata_all.h 2014-08-01 = 21:08:39.000000000 -0600 +++ /usr/home/justing/perforce/SpectraBSD/sys/cam/ata/ata_all.h = 2014-08-01 21:08:39.000000000 -0600 @@ -111,8 +111,10 @@ void ata_print_ident(struct ata_params *ident_data); void ata_print_ident_short(struct ata_params *ident_data); =20 +uint8_t ata_lbppbe(struct ata_params *ident_data); +uint32_t ata_lalba(struct ata_params *ident_data); uint32_t ata_logical_sector_size(struct ata_params *ident_data); -uint64_t ata_physical_sector_size(struct ata_params *ident_data); +uint32_t ata_physical_sector_size(struct ata_params *ident_data); uint64_t ata_logical_sector_offset(struct ata_params = *ident_data); =20 void ata_28bit_cmd(struct ccb_ataio *ataio, uint8_t cmd, uint8_t = features, --- //SpectraBSD/stable/sys/cam/scsi/scsi_da.c 2014-09-19 = 23:21:40.000000000 -0600 +++ /usr/home/justing/perforce/SpectraBSD/sys/cam/scsi/scsi_da.c = 2014-09-19 23:21:40.000000000 -0600 @@ -2039,6 +2041,24 @@ daschedule(periph); wakeup(&softc->disk->d_mediasize); if ((softc->flags & DA_FLAG_ANNOUNCED) =3D=3D 0) { + + /* + * Create our sysctl variables, now that we know + * we have successfully attached. + */ + /* increase the refcount */ + if (cam_periph_acquire(periph) =3D=3D CAM_REQ_CMP) { + taskqueue_enqueue(taskqueue_thread, + &softc->sysctl_task); + xpt_announce_periph(periph, + softc->announce_buf); + xpt_announce_quirks(periph, softc->quirks.flags, + DA_Q_BIT_STRING); + } else { + xpt_print(periph->path, "fatal error, " + "could not acquire reference count\n"); + } + softc->flags |=3D DA_FLAG_ANNOUNCED; cam_periph_unhold(periph); } else @@ -3360,26 +3381,6 @@ } } free(csio->data_ptr, M_SCSIDA); - if (softc->announce_buf[0] !=3D '\0' && - ((softc->flags & DA_FLAG_ANNOUNCED) =3D=3D 0)) { - /* - * Create our sysctl variables, now that we know - * we have successfully attached. - */ - /* increase the refcount */ - if (cam_periph_acquire(periph) =3D=3D = CAM_REQ_CMP) { - taskqueue_enqueue(taskqueue_thread, - &softc->sysctl_task); - xpt_announce_periph(periph, - = softc->announce_buf); - xpt_announce_quirks(periph, = softc->quirks.flags, - DA_Q_BIT_STRING); - } else { - xpt_print(periph->path, "fatal error, " - "could not acquire reference = count\n"); - } - } - /* We already probed the device. */ if (softc->flags & DA_FLAG_PROBED) { daprobedone(periph, done_ccb); @@ -3633,10 +3578,13 @@ } case DA_CCB_PROBE_ATA: { - int i; + struct scsi_read_capacity_data_long rcaplong; struct ata_params *ata_params; + struct disk_params *dp; int16_t *ptr; + int i; =20 + dp =3D &softc->params; ata_params =3D (struct ata_params *)csio->data_ptr; ptr =3D (uint16_t *)ata_params; =20 @@ -3658,6 +3606,27 @@ */ if (ata_params->media_rotation_rate =3D=3D 1) softc->sort_io_queue =3D 0; + + /* + * Perform our own emulation of read capacity = data + * rather than rely on the SCSI controller to = get + * it right. + */ + memset(&rcaplong, 0, sizeof(rcaplong)); + rcaplong.prot_lbppbe =3D ata_lbppbe(ata_params); + scsi_ulto2b(ata_lalba(ata_params), + rcaplong.lalba_lbp); + dasetgeom(periph, = ata_logical_sector_size(ata_params), + dp->sectors - 1, &rcaplong, = sizeof(rcaplong)); + snprintf(softc->announce_buf, + sizeof(softc->announce_buf), + "%juMB (%ju %u byte sectors: %dH %dS/T " + "%dC)", (uintmax_t) + (((uintmax_t)dp->secsize * + dp->sectors) / (1024*1024)), + (uintmax_t)dp->sectors, + dp->secsize, dp->heads, + dp->secs_per_track, dp->cylinders); } else { int error; error =3D daerror(done_ccb, CAM_RETRY_SELTO, From owner-freebsd-stable@FreeBSD.ORG Sat Sep 20 16:12:08 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B0B27B99 for ; Sat, 20 Sep 2014 16:12:08 +0000 (UTC) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001: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 7FEADC19 for ; Sat, 20 Sep 2014 16:12:08 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id x19so2361166ier.15 for ; Sat, 20 Sep 2014 09:12:07 -0700 (PDT) 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=wwHxuZl2C5tCMOSqz5dzofhoVR5dbiQWdoTbpa9rRq4=; b=qn8vvLS6a5Rna/klNtvVGReYqOudBGUFHSB+e3CYzvqNpv3Us8XRBMut0LzdQfuowU J9ya7DYbQnfBSplVcbQR/6GlXtSc+1vMHSDXcfBf3EfH4fJEIDD/4MaOI3Lh0ZyxTVDB NWrEusmZgUjYklYKmKnb8jfP4H5PD9mFuELBmbcPN8GKQz/kIMbjqCipE5qt9fzPOoEx ZYuWiew9+oZIslteWY93OT4lmjYOM1Sqt+MK90vAAdnmODItkytcM+aDrrH1wbOJMZ0h QqNi3pU1KOqv1tmhay9ujAUmeJVgWkmBDNeob+Sd4+hPrjh2gOJFNkop3JcbeTT5oBSL XPVQ== MIME-Version: 1.0 X-Received: by 10.42.60.7 with SMTP id o7mr7412090ich.28.1411229527502; Sat, 20 Sep 2014 09:12:07 -0700 (PDT) Received: by 10.50.87.130 with HTTP; Sat, 20 Sep 2014 09:12:07 -0700 (PDT) Date: Sat, 20 Sep 2014 09:12:07 -0700 Message-ID: Subject: FreeBSD 10 network performance problems From: Rumen Telbizov To: "freebsd-stable@freebsd.org" 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-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 16:12:08 -0000 Hello everyone, I am in the process of upgrading our main PF firewalls from 9.2-RC4 to 10.1-BETA1 (r271684) and as part of the process I have been testing the forwarding capability of FreeBSD 10 (pf firewall disabled) to have a base-line and find any bottlenecks on a 10GbE network. My tests show that for the first 3-4Gbit/s of traffic things are great and then the machine simply "hits the wall" at around 4-5Gbit/s of traffic. There's no gradual degradation but a hard drop to 0% idle and 50-50% split of system and interrupt CPU load. I ran some diagnostics and I was hoping someone could point me in the right direction as to what is happening and what I could do to improve the situation. The details I have collected so far are below: I run multiple iperf tcp multithreaded instances to generate traffic which traverses the firewall. As mentioned above for the first 3-4Gbit/s traffic the machine doesn't even break a sweat. *top header* during this load when things are good: CPU 0: 0.0% user, 0.0% nice, 0.0% system, 27.6% interrupt, 72.4% idle CPU 1: 0.0% user, 0.0% nice, 0.0% system, 27.6% interrupt, 72.4% idle CPU 2: 0.0% user, 0.0% nice, 0.0% system, 8.7% interrupt, 91.3% idle CPU 3: 0.0% user, 0.0% nice, 0.0% system, 17.3% interrupt, 82.7% idle CPU 4: 0.0% user, 0.0% nice, 0.0% system, 12.6% interrupt, 87.4% idle CPU 5: 0.0% user, 0.0% nice, 0.0% system, 4.7% interrupt, 95.3% idle CPU 6: 0.0% user, 0.0% nice, 0.0% system, 13.4% interrupt, 86.6% idle CPU 7: 0.0% user, 0.0% nice, 0.0% system, 26.0% interrupt, 74.0% idle CPU 8: 0.0% user, 0.0% nice, 0.0% system, 16.5% interrupt, 83.5% idle CPU 9: 0.0% user, 0.0% nice, 0.0% system, 1.6% interrupt, 98.4% idle CPU 10: 0.0% user, 0.0% nice, 0.0% system, 19.7% interrupt, 80.3% idle CPU 11: 0.0% user, 0.0% nice, 0.0% system, 7.1% interrupt, 92.9% idle Full output at http://pastebin.com/gaaisXV8 *bmon* at the same time: Interfaces =E2=94=82 RX bps pps %=E2=94=82 TX= bps pps % ix0 =E2=94=82 240.33MiB 242.20K =E2=94=82 22= 1.41MiB 236.68K ix1 =E2=94=82 246.51MiB 248.80K =E2=94=82 26= 1.61MiB 250.95K >lagg0 =E2=94=82 483.45MiB 492.42K =E2=94=82 47= 9.54MiB 488.02K MiB (RX Bytes/second) MiB (TX Bytes/second) 499.17 |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 496.49 |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 415.98 |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 413.74 |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 332.78 |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 331.00 |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 249.59 |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 248.25 |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 166.39 |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 165.50 |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 83.20 |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 82.75 |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 1 5 10 15 20 25 30 35 40 45 50 55 60 1 5 10 15 20 25 30 35 40 45 50 55 6= 0 K (RX Packets/second) K (TX Packets/second) 508.27 |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 505.14 |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 423.56 |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 420.95 |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 338.85 |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 336.76 |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 254.14 |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 252.57 |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 169.42 |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 168.38 |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 84.71 |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 84.19 |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 1 5 10 15 20 25 30 35 40 45 50 55 60 1 5 10 15 20 25 30 35 40 45 50 55 6= 0 To profile it without having it degrade sooner I reduced traffic to 2Gbit/s and ran dtrace hotkernel and lock profiling. Here are the results: */usr/share/dtrace/toolkit/hotkernel* for 60 seconds: kernel`__mtx_lock_flags 5812 0.8% kernel`__mtx_unlock_flags 7200 1.0% kernel`acpi_cpu_c1 7799 1.1% kernel`__rw_rlock 11196 1.5% kernel`spinlock_exit 14547 2.0% kernel`cpu_idle 166700 22.8% kernel`sched_idletd 461883 63.1% Full output at http://pastebin.com/w7WfFwPG *lock profiling* for 60 seconds: $ head -n 2 good-locks ; cat good-locks | sort -n -k 4 | tail -n6 debug.lock.prof.stats: max wait_max total wait_total count avg wait_avg cnt_hold cnt_lock name 22 24 94378 18481 264549 0 0 0 18639 /usr/src/sys/kern/sched_ule.c:886 (spin mutex:sched lock 10) 22 24 112366 20360 219179 0 0 0 17220 /usr/src/sys/kern/sched_ule.c:888 (spin mutex:sched lock 2) 18 319 3486 22352 4233 0 5 0 1640 /usr/src/sys/kern/subr_taskqueue.c:344 (sleep mutex:taskqueue) 26 66 3219768 204875 14616220 0 0 0 133154 /usr/src/sys/net/route.c:439 (sleep mutex:rtentry) 25 90 1923012 2353820 14615738 0 0 0 1562097 /usr/src/sys/netinet/ip_fastfwd.c:593 (sleep mutex:rtentry) 26 91 1398443 2391458 14616137 0 0 0 1604332 /usr/src/sys/netinet/in_rmx.c:114 (sleep mutex:rtentry) Full output at http://pastebin.com/qiG3ZuAH Again, above measurements demonstrate the state of the good/healthy system under moderate traffic load of 3-4Gbit/s with pf disabled and fast forwarding enabled. Here are the same measurements when I add an additional 1Gbit/s of traffic. The point when performance tanks varies between 4-5Gbit/s but it's always sudden, without any gradual degradation but instead idle simply drops down to 0. Let's take a look: *top header* during this load when things are bad: CPU 0: 0.0% user, 0.0% nice, 44.6% system, 55.4% interrupt, 0.0% idle CPU 1: 0.0% user, 0.0% nice, 15.1% system, 84.9% interrupt, 0.0% idle CPU 2: 0.0% user, 0.0% nice, 59.0% system, 40.3% interrupt, 0.7% idle CPU 3: 0.0% user, 0.0% nice, 57.6% system, 42.4% interrupt, 0.0% idle CPU 4: 0.0% user, 0.0% nice, 34.5% system, 63.3% interrupt, 2.2% idle CPU 5: 0.0% user, 0.0% nice, 51.8% system, 48.2% interrupt, 0.0% idle CPU 6: 0.0% user, 0.0% nice, 33.8% system, 66.2% interrupt, 0.0% idle CPU 7: 0.7% user, 0.0% nice, 49.6% system, 49.6% interrupt, 0.0% idle CPU 8: 0.0% user, 0.0% nice, 66.2% system, 33.8% interrupt, 0.0% idle CPU 9: 0.0% user, 0.0% nice, 35.3% system, 64.7% interrupt, 0.0% idle CPU 10: 0.0% user, 0.0% nice, 54.7% system, 45.3% interrupt, 0.0% idle CPU 11: 0.0% user, 0.0% nice, 34.5% system, 65.5% interrupt, 0.0% idle Full output at http://pastebin.com/9an9ZWv2 *bmon *at the same time shows inconsistent performance with big dips: Interfaces =E2=94=82 RX bps pps %=E2=94=82 TX= bps pps % ix0 =E2=94=82 153.89MiB 151.53K =E2=94=82 17= 9.69MiB 159.91K ix1 =E2=94=82 176.56MiB 161.29K =E2=94=82 14= 5.17MiB 148.13K >lagg0 =E2=94=82 327.23MiB 333.05K =E2=94=82 32= 2.14MiB 328.13K MiB (RX Bytes/second) MiB (TX Bytes/second) 657.86 ..............|............................................. 648.60 ..............|............................................. 548.21 ..............|............................................. 540.50 ..............|............................................. 438.57 ...........|..|.........................|.....|.......|..|.. 432.40 ...........|..|.........................|.....|.......|..|.. 328.93 |..||||..||||.||...||..|||.||.|.|||||||||.|||||||||.||||||.. 324.30 |..||||..||||.||...||..|||.||.|.|||||||||.|||||||||.||||||.. 219.29 |..||||..||||.||..|||.||||.||.|||||||||||.|||||||||.||||||.. 216.20 |..||||..||||.||..|||.||||.||.|||||||||||.|||||||||.||||||.. 109.64 |.|||||..||||.||..|||.||||.||.|||||||||||.|||||||||.||||||.. 108.10 |.|||||..||||.||..|||.||||.||.|||||||||||.|||||||||.||||||.. 1 5 10 15 20 25 30 35 40 45 50 55 60 1 5 10 15 20 25 30 35 40 45 50 55 60 K (RX Packets/second) K (TX Packets/second) 670.41 ..............|............................................. 660.27 ..............|............................................. 558.67 ..............|............................................. 550.22 ..............|............................................. 446.94 ...........|..|.........................|.....|.......|..|.. 440.18 ...........|..|.........................|.....|.......|..|.. 335.20 |..||||..||||.||...||..|||.||.|.|||||||||.|||||||||.||||||.. 330.13 |..||||..||||.||...||..|||.||.|.|||||||||.|||||||||.||||||.. 223.47 |..||||..||||.||..|||.||||.||.|||||||||||.|||||||||.||||||.. 220.09 |..||||..||||.||..|||.||||.||.|||||||||||.|||||||||.||||||.. 111.73 |.|||||..||||.||..|||.||||.||.|||||||||||.|||||||||.||||||.. 110.04 |.|||||..||||.||..|||.||||.||.|||||||||||.|||||||||.||||||.. 1 5 10 15 20 25 30 35 40 45 50 55 60 1 5 10 15 20 25 30 35 40 45 50 55 60 */usr/share/dtrace/toolkit/hotkernel* for 60 seconds: kernel`_rw_runlock_cookie 7709 1.1% kernel`__rw_rlock 11182 1.6% kernel`ip_fastforward 12231 1.7% kernel`__mtx_lock_flags 22004 3.1% kernel`__mtx_unlock_flags 35614 5.0% kernel`__mtx_lock_sleep 560768 78.5% Full output at http://pastebin.com/NurKwkWL *lock profiling* for 60 seconds: $ head -n 2 bad-locks ; cat bad-locks | sort -n -k 4 | tail -n6 debug.lock.prof.stats: max wait_max total wait_total count avg wait_avg cnt_hold cnt_lock name 401766 191987 1857397 194162 179 10376 1084 0 2 /usr/src/sys/kern/kern_sysctl.c:1601 (sx:sysctl mem) 21064 207907 62556 249066 396 157 628 0 3 /usr/src/sys/kern/kern_sysctl.c:1499 (sleep mutex:Giant) 1 370663 17 372573 86 0 4332 0 2 /usr/src/sys/kern/kern_exit.c:429 (sx:allproc) 14 648 8856844 46296098 15513956 0 2 0 1467849 /usr/src/sys/net/route.c:439 (sleep mutex:rtentry) 15 958 13107581 252445472 15513486 0 16 0 9444644 /usr/src/sys/netinet/ip_fastfwd.c:593 (sleep mutex:rtentry) 12 779 12500816 286324556 15513872 0 18 0 9788497 /usr/src/sys/netinet/in_rmx.c:114 (sleep mutex:rtentry) Full output at http://pastebin.com/d54QmP13 System hardware is: 12 x E5-2440 @ 2.40GHz, 24GB RAM, Dual port fiber Intel(R) PRO/10GbE in lacp lagg System configuration details available at http://pastebin.com/tPvs1MeD It seems to me like heavy lock contention but I don't understand why it happens in such an abrupt manner after a given threshold. Other things I tried: - Upgrade ix (ixgbe) driver to the latest from Intel (2.5.25) - for some reason I cannot send any packets out - enable flowtables - no difference Any help is highly appreciated. I could provide further details and run additional tests upon request. Regrads, --=20 Rumen Telbizov Unix Systems Administrator From owner-freebsd-stable@FreeBSD.ORG Sat Sep 20 20:31:49 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3EC96D73 for ; Sat, 20 Sep 2014 20:31:49 +0000 (UTC) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::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 CD7CA81F for ; Sat, 20 Sep 2014 20:31:48 +0000 (UTC) Received: by mail-we0-f172.google.com with SMTP id p10so764446wes.31 for ; Sat, 20 Sep 2014 13:31:46 -0700 (PDT) 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=ur2hgV93hWeuGfE2FMUn3a22osZoe2PNU4LN3rz+cB8=; b=Ur2ut/fjfgj6MfXdsNeLzCC94iIOPT2hW5LDCm2OMbs2tYPRQ080zzPM6Y7dDz505p cyDA3z3ioTQzF0YGbjMrqfTP7Rejb5ZPst5lodqbFiWJWDoddIXB0tCmW8onShw3WtcY gj8mf8D2uNCRIYDa/8t9eee6+mLfCgnnAWCziAdxNTtfaa5NwkV15vjaOiK4KUbcfkWM HZRwO4qqONtY9Mk+4Tryrce1XjI8+nVQd/5g//fvEVo7SqK/2VhA0+MpAl+6QdNJuGGb LHdN4svsvm7S9sBlN1UICmrXH5T1aoJh900JWLdk5rkwf3IGA/7jLUi1zA9qmm6Wm/h+ LakQ== MIME-Version: 1.0 X-Received: by 10.180.101.129 with SMTP id fg1mr5115892wib.20.1411245106045; Sat, 20 Sep 2014 13:31:46 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.199 with HTTP; Sat, 20 Sep 2014 13:31:45 -0700 (PDT) In-Reply-To: References: Date: Sat, 20 Sep 2014 13:31:45 -0700 X-Google-Sender-Auth: EHYWrLV_FjslSJV5Yq9NZ2k_6tI Message-ID: Subject: Re: FreeBSD 10 network performance problems From: Adrian Chadd To: Rumen Telbizov Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 20:31:49 -0000 Hi, The forwarding paths don't 100% use flowtable, so there's still routing table lookups. All those highly contended locks are the rtentry locking because the forwarding and fast forwarding paths don't use flowtable. This shouldn't be a difficult problem to solve; someone just has to go through those places above, figure out what code is doing the lookups and convert them to use flowtable. The one place that's currently a pain is how IPv4 redirects are handled; you can turn them off with a sysctl. -a From owner-freebsd-stable@FreeBSD.ORG Sat Sep 20 20:56:39 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F7E2553 for ; Sat, 20 Sep 2014 20:56:39 +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 1AED49E1 for ; Sat, 20 Sep 2014 20:56:38 +0000 (UTC) Received: from walrus.pepperland ([81.217.76.60]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LjJCt-1Y1Tbf0zZX-00daKE for ; Sat, 20 Sep 2014 22:56:36 +0200 Message-ID: <541DE9FC.2090003@gmx.net> Date: Sat, 20 Sep 2014 22:56:28 +0200 From: Stefan Ehmann User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: xzgrep: incomplete results on larger files Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ilS1y92Q/azHxyf35qlcRpRwunvod2ICJXFCVPOfRoUYzv9s1iE W1PnGOiR2ZY9EivHfprKleCGtoMbo5kxWOl4ZbKI0V6x+2N7viA/yHythYm18CAcf5kYrqy FWUVPVoGKK2wB3cu38cKtGdPpfXMkewiNCr7BDDzBfXnbhnXSXOeLS/pT5zhVT41dUDe3cg LSe2SmTWg1wtOk8G+P6uA== X-UI-Out-Filterresults: notjunk:1; X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 20:56:39 -0000 I observed the following behavior on 10.1-BETA1 r271683M (amd64): xzgrep doesn't search the complete file: $ seq 10000 | xz > seq.xz $ xzgrep -c . seq.xz 6775 Using regular grep works as expected: $ xzcat seq.xz | grep -c . 10000 Processing seems to stop after 32KB (uncompressed). From owner-freebsd-stable@FreeBSD.ORG Sat Sep 20 21:03:39 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6EC44966 for ; Sat, 20 Sep 2014 21:03:39 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (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 03E47AB7 for ; Sat, 20 Sep 2014 21:03:38 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 513D5153A8D; Sat, 20 Sep 2014 23:03:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dpnkl9cXuEx; Sat, 20 Sep 2014 23:02:56 +0200 (CEST) Received: from [192.168.10.9] (vaio [192.168.10.9]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 46882153A8B; Sat, 20 Sep 2014 23:02:56 +0200 (CEST) Message-ID: <541DEB82.3020709@digiware.nl> Date: Sat, 20 Sep 2014 23:02:58 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Karl Denninger , freebsd-stable@freebsd.org Subject: Re: getting to 4K disk blocks in ZFS References: <540FF3C4.6010305@ish.com.au> <54114029.3060507@FreeBSD.org> <2128347.Ah5i0RTCvp@overcee.wemm.org> <541230F1.3060402@digiware.nl> <7D0869A9-C114-4C4F-877A-3FB26AD7737D@scsiguy.com> <607F83CE25104CE09C74935BA9E26485@multiplay.co.uk> <541CBD5B.8050603@denninger.net> In-Reply-To: <541CBD5B.8050603@denninger.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 21:03:39 -0000 On 20-9-2014 1:33, Karl Denninger wrote: > > On 9/19/2014 6:23 PM, Steven Hartland wrote: >> >> ----- Original Message ----- >>> From: "Justin T. Gibbs" >>> To: "Willem Jan Withagen" >>> Cc: "Steven Hartland" ; >>> ; "Andriy Gapon" ; >>> "Peter Wemm" ; "Aristedes Maniatis" >>> Sent: Saturday, September 20, 2014 12:07 AM >>> Subject: Re: getting to 4K disk blocks in ZFS >>> >>> >>> On Sep 11, 2014, at 5:32 PM, Willem Jan Withagen >>> wrote: >>> >>>> On 11-9-2014 19:49, Peter Wemm wrote: >>>>>> Another downside is 1/4th of uberblocks, 32 vs 128. >>>>>> Also, automatic sector size detection works great for me and I've >>> never had >>>>>> a need to manually tweak ashift. >>>>> >>>>> Unfortunately, I have. Same drive connected two different ways: >>>>> >>>>> da12 at mps1 bus 0 scbus1 target 11 lun 0 >>>>> da12: Fixed Direct Access SCSI-6 device >>>>> da12: 600.000MB/s transfers >>>>> da12: Command Queueing enabled >>>>> da12: 3815447MB (7814037168 512 byte sectors: 255H 63S/T 486401C) >>>>> >>>>> ada1 at ahcich1 bus 0 scbus3 target 0 lun 0 >>>>> ada1: ATA-8 SATA 3.x device >>>>> ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) >>>>> ada1: Command Queueing enabled >>>>> ada1: 3815447MB (7814037168 512 byte sectors: 16H 63S/T 16383C) >>>>> ada1: quirks=0x1<4K> >>>>> >>>>> The 4k flag is missing when it's on the sas controller. The Ident >>> strings are >>>>> changed. >>>>> >>>>> This came up elsewhere recently. >>>> >>>> I reported the same fact for the new set of WD REDs I installed. >>>> Seems that ada and da have different quirks tables... >>>> So disks on SATA connectors on the motherboard are diagnosed as >>> being 4Kb. >>>> The disks on my twa don't get the quirk and are considered 512b >>>> >>>> —WjW >>> >>> I’m surprised that we have to constantly add quirks. Are these >>> drives really >>> failing to report their ata params correctly? Is there a reason we >>> don’t >>> currently utilize the ata params data (which is already fetched for >>> trim/unmap >>> detection) to also set lbppbe (logical block per physical block >>> exponent) and >>> lalba (lowest aligned lba)? We may find that many of the existing >>> quirks are >>> unnecessary if we fix the probe code. >> >> On the contary I've not found a single drive which reports 4k sectors >> on its >> own, every single one that I've seen report 4k is because we've added a >> quirk for it :( >> >> > Where is Smartctl getting it from? > > smartctl -i /dev/da2 > smartctl 6.3 2014-07-26 r3976 [FreeBSD 10.1-BETA1 amd64] (local build) > Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org > > === START OF INFORMATION SECTION === > Device Model: HGST HDN724040ALE640 > Serial Number: PK2334PCG6NA0B > LU WWN Device Id: 5 000cca 24cc30684 > Firmware Version: MJAOA5E0 > User Capacity: 4,000,787,030,016 bytes [4.00 TB] > Sector Sizes: 512 bytes logical, 4096 bytes physical > Rotation Rate: 7200 rpm > Form Factor: 3.5 inches > Device is: Not in smartctl database [for details use: -P showall] > ATA Version is: ATA8-ACS T13/1699-D revision 4 > SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s) > Local Time is: Fri Sep 19 18:33:16 2014 CDT > SMART support is: Available - device has SMART capability. > SMART support is: Enabled > > It's not coming from a database, as Smartctl doesn't know about these > (yet); they're too new. I really need to add the fact that it is on a Areca controller, other it does not show. (The 3ware was the server before that) ====================== [~wjw] root@zfs.digiware.nl# smartctl -a /dev/da2 smartctl 6.2 2013-07-26 r3841 [FreeBSD 9.3-STABLE amd64] (local build) Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Vendor: WDC Product: WD30EFRX-68AX9N0 Revision: R001 User Capacity: 3,000,592,982,016 bytes [3.00 TB] Logical block size: 512 bytes Rotation Rate: 10000 rpm Logical Unit id: 0x0004d927fffff820 Serial number: WD-WMC1T4088786 Device type: disk Transport protocol: Fibre channel (FCP-2) Local Time is: Sat Sep 20 22:49:27 2014 CEST SMART support is: Available - device has SMART capability. SMART support is: Enabled Temperature Warning: Disabled or Not Supported ====================== So that does not give any other blocksize. And with additional controller knowledge: ====================== [~wjw] root@zfs.digiware.nl# smartctl -a -d areca,1 -T permissive /dev/arcmsr0 smartctl 6.2 2013-07-26 r3841 [FreeBSD 9.3-STABLE amd64] (local build) Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Family: Western Digital Red (AF) Device Model: WDC WD30EFRX-68AX9N0 Serial Number: WD-WMC1T4081674 LU WWN Device Id: 5 0014ee 60377e6b2 Firmware Version: 80.00A80 User Capacity: 3,000,592,982,016 bytes [3.00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Device is: In smartctl database [for details use: -P show] ATA Version is: ACS-2 (minor revision not indicated) SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s) Local Time is: Sat Sep 20 22:58:04 2014 CEST SMART support is: Available - device has SMART capability. SMART support is: Enabled ====================== --WjW From owner-freebsd-stable@FreeBSD.ORG Sat Sep 20 21:10:13 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1EA59BD5 for ; Sat, 20 Sep 2014 21:10:13 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id D272CAFC for ; Sat, 20 Sep 2014 21:10:12 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 07AE020E7088F; Sat, 20 Sep 2014 21:10:04 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.8 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,RDNS_DYNAMIC,STOX_REPLY_TYPE,TVD_FINGER_02 autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id AAAB320E7088A; Sat, 20 Sep 2014 21:10:00 +0000 (UTC) Message-ID: <37FACC8F487E4D93B014BD28B2A09935@multiplay.co.uk> From: "Steven Hartland" To: "Willem Jan Withagen" , "Karl Denninger" , References: <540FF3C4.6010305@ish.com.au> <54114029.3060507@FreeBSD.org> <2128347.Ah5i0RTCvp@overcee.wemm.org> <541230F1.3060402@digiware.nl> <7D0869A9-C114-4C4F-877A-3FB26AD7737D@scsiguy.com> <607F83CE25104CE09C74935BA9E26485@multiplay.co.uk> <541CBD5B.8050603@denninger.net> <541DEB82.3020709@digiware.nl> Subject: Re: getting to 4K disk blocks in ZFS Date: Sat, 20 Sep 2014 22:09:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 21:10:13 -0000 And what does camcontrol report for that? I'm gonna guess that identify doesn't work as areca's typically don't implement passthrough support, but would be insterested to confirm. ----- Original Message ----- From: "Willem Jan Withagen" I really need to add the fact that it is on a Areca controller, other it does not show. (The 3ware was the server before that) ====================== [~wjw] root@zfs.digiware.nl# smartctl -a /dev/da2 smartctl 6.2 2013-07-26 r3841 [FreeBSD 9.3-STABLE amd64] (local build) Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Vendor: WDC Product: WD30EFRX-68AX9N0 Revision: R001 User Capacity: 3,000,592,982,016 bytes [3.00 TB] Logical block size: 512 bytes Rotation Rate: 10000 rpm Logical Unit id: 0x0004d927fffff820 Serial number: WD-WMC1T4088786 Device type: disk Transport protocol: Fibre channel (FCP-2) Local Time is: Sat Sep 20 22:49:27 2014 CEST SMART support is: Available - device has SMART capability. SMART support is: Enabled Temperature Warning: Disabled or Not Supported ====================== So that does not give any other blocksize. And with additional controller knowledge: ====================== [~wjw] root@zfs.digiware.nl# smartctl -a -d areca,1 -T permissive /dev/arcmsr0 smartctl 6.2 2013-07-26 r3841 [FreeBSD 9.3-STABLE amd64] (local build) Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Family: Western Digital Red (AF) Device Model: WDC WD30EFRX-68AX9N0 Serial Number: WD-WMC1T4081674 LU WWN Device Id: 5 0014ee 60377e6b2 Firmware Version: 80.00A80 User Capacity: 3,000,592,982,016 bytes [3.00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Device is: In smartctl database [for details use: -P show] ATA Version is: ACS-2 (minor revision not indicated) SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s) Local Time is: Sat Sep 20 22:58:04 2014 CEST SMART support is: Available - device has SMART capability. SMART support is: Enabled ====================== --WjW _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Sat Sep 20 22:23:41 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7ACADBFB for ; Sat, 20 Sep 2014 22:23:41 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (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 0DE541D9 for ; Sat, 20 Sep 2014 22:23:40 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 76D7B1534EC; Sun, 21 Sep 2014 00:23:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23_ZW04l5gDD; Sun, 21 Sep 2014 00:23:26 +0200 (CEST) Received: from [192.168.10.9] (vaio [192.168.10.9]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 95DEF1534C4; Sun, 21 Sep 2014 00:23:26 +0200 (CEST) Message-ID: <541DFE60.5070508@digiware.nl> Date: Sun, 21 Sep 2014 00:23:28 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Steven Hartland , Karl Denninger , freebsd-stable@freebsd.org Subject: Re: getting to 4K disk blocks in ZFS References: <540FF3C4.6010305@ish.com.au> <54114029.3060507@FreeBSD.org> <2128347.Ah5i0RTCvp@overcee.wemm.org> <541230F1.3060402@digiware.nl> <7D0869A9-C114-4C4F-877A-3FB26AD7737D@scsiguy.com> <607F83CE25104CE09C74935BA9E26485@multiplay.co.uk> <541CBD5B.8050603@denninger.net> <541DEB82.3020709@digiware.nl> <37FACC8F487E4D93B014BD28B2A09935@multiplay.co.uk> In-Reply-To: <37FACC8F487E4D93B014BD28B2A09935@multiplay.co.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 22:23:41 -0000 On 20-9-2014 23:09, Steven Hartland wrote: > And what does camcontrol report for that? > > I'm gonna guess that identify doesn't work as areca's typically don't > implement passthrough support, but would be insterested to confirm. Something like?? root@zfs.digiware.nl# camcontrol identify /dev/da1 camcontrol: ATA ATAPI_IDENTIFY via pass_16 failed --WjW > > ----- Original Message ----- From: "Willem Jan Withagen" > > I really need to add the fact that it is on a Areca controller, other it > does not show. > (The 3ware was the server before that) > > ====================== > [~wjw] root@zfs.digiware.nl# smartctl -a /dev/da2 > smartctl 6.2 2013-07-26 r3841 [FreeBSD 9.3-STABLE amd64] (local build) > Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org > > === START OF INFORMATION SECTION === > Vendor: WDC > Product: WD30EFRX-68AX9N0 > Revision: R001 > User Capacity: 3,000,592,982,016 bytes [3.00 TB] > Logical block size: 512 bytes > Rotation Rate: 10000 rpm > Logical Unit id: 0x0004d927fffff820 > Serial number: WD-WMC1T4088786 > Device type: disk > Transport protocol: Fibre channel (FCP-2) > Local Time is: Sat Sep 20 22:49:27 2014 CEST > SMART support is: Available - device has SMART capability. > SMART support is: Enabled > Temperature Warning: Disabled or Not Supported > ====================== > > So that does not give any other blocksize. > And with additional controller knowledge: > > ====================== > [~wjw] root@zfs.digiware.nl# smartctl -a -d areca,1 -T permissive > /dev/arcmsr0 > smartctl 6.2 2013-07-26 r3841 [FreeBSD 9.3-STABLE amd64] (local build) > Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org > > === START OF INFORMATION SECTION === > Model Family: Western Digital Red (AF) > Device Model: WDC WD30EFRX-68AX9N0 > Serial Number: WD-WMC1T4081674 > LU WWN Device Id: 5 0014ee 60377e6b2 > Firmware Version: 80.00A80 > User Capacity: 3,000,592,982,016 bytes [3.00 TB] > Sector Sizes: 512 bytes logical, 4096 bytes physical > Device is: In smartctl database [for details use: -P show] > ATA Version is: ACS-2 (minor revision not indicated) > SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s) > Local Time is: Sat Sep 20 22:58:04 2014 CEST > SMART support is: Available - device has SMART capability. > SMART support is: Enabled > ====================== > > > --WjW > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >