From owner-freebsd-current@FreeBSD.ORG Sun Aug 24 02:14:21 2014 Return-Path: Delivered-To: freebsd-current@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 57F41199 for ; Sun, 24 Aug 2014 02:14:21 +0000 (UTC) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::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 D30AF37B3 for ; Sun, 24 Aug 2014 02:14:20 +0000 (UTC) Received: by mail-lb0-f173.google.com with SMTP id u10so10829450lbd.32 for ; Sat, 23 Aug 2014 19:14:17 -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=4UnFHoJg7+6c/8AyljyzqJu0nYKK3DYNVpDFFoxbrUo=; b=cSBFHPTrYXTE7PpNbBaQxOoBsOTEU0DlzzSalP2+4esIOlkNG16ajlyz9BIZTcPkTa q2IoBT9l4Yn5vFmZksLoWuEaFcON1+FyGCRuMaRHfYgpBsoMsC45EId/hP2KQyLnh3Ui hLmvCFmBvwq+8hHYfD27p2LqRsioyk92vIpCFpxMIeSGkEE80ACQ/staRw9tnKS7iQPZ mtUV8gsPM4BEV2fR2r5TB2xs0cdau2+JithQEMCz8o3FLAcleSsj+S6Xe5nCy4hPxYpJ D+hDptIfkP5q3yBddbcBJTWMWxQMajqrCGFcDFeR5qDHLVVrVvvOEIrZCGXZ3MeSJfkt yFxw== MIME-Version: 1.0 X-Received: by 10.112.76.230 with SMTP id n6mr8372916lbw.8.1408846457641; Sat, 23 Aug 2014 19:14:17 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.197.107 with HTTP; Sat, 23 Aug 2014 19:14:17 -0700 (PDT) In-Reply-To: References: <853B0396-2C19-49DF-A8E8-8EB43D107597@xcllnt.net> <7CE168C1-6AF3-4AD2-80DB-192AEC49FD2B@xcllnt.net> Date: Sat, 23 Aug 2014 19:14:17 -0700 X-Google-Sender-Auth: Ffo2XSaCYGkx2RRl92M7JR3ECEE Message-ID: Subject: Re: mkimg used to create gpt image, problem booting From: Craig Rodrigues To: Marcel Moolenaar Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 02:14:21 -0000 Hi, I did some more experiments, and found that after /boot/loader runs, if I break into the loader prompt and type "lsdev", I would get this: (1) GPT Disk image which boots under QEMU, made by bsdinstall ================================================== View from loader ============ OK lsdev cd devices: disk devices: disk0: BIOS drive A: disk1: BIOS drive C: disk1p1: FreeBSD boot disk1p2: FreeBSD UFS disk1p3: FreeBSD swap pxe devices: View from gpart, after we mdconfig the disk image ==================================== => 34 10485693 md0 GPT (5.0G) 34 128 1 freebsd-boot (64K) 162 9959296 2 freebsd-ufs (4.7G) 9959458 524288 3 freebsd-swap (256M) 10483746 1981 - free - (991K) (2) GPT Disk image which fails to boot under QEMU, made by mkimg =================================================== View from loader ============ OK lsdev cd devices: disk devices: disk0: BIOS drive A: disk1: BIOS drive C: pxe devices: View from gpart, after we mdconfig the disk image ==================================== => 3 1784944 md1 GPT (872M) 3 32 1 freebsd-boot (16K) 35 1784912 2 freebsd-ufs (872M) This leads me to believe that there is logic in /boot/loader, which is not in GEOM, that fails to parse the GPT produced by mkimg. I did some further debugging inside the loader by doing the following. -> I added "CFLAGS += -DPART_DEBUG" to sys/boot/common/Makefile.inc -> I added DEBUG() statements all over sys/boot/common/part.c I observed that in sys/boot/common/part.c in the ptbl_gptread() function, that in this section: 305 ent = (struct gpt_ent *)tbl; 306 size = MIN(hdr.hdr_entries * hdr.hdr_entsz, 307 MAXTBLSZ * table->sectorsize); 308 for (i = 0; i < size / hdr.hdr_entsz; i++, ent++) { 309 if (uuid_equal(&ent->ent_type, &gpt_uuid_unused, NULL)) 310 continue; ent->ent_type is all 0's, which matches gpt_uuid_unused, so it bails out of the loop and never adds the gpt partitions to the list of partitions that the loader can access. I'm not familiar with the GPT format, nor am I familiar with the gpt code inside the loader, and how it differs from GEOM. Do you have any further ideas of where to hunt for the root cause of the problem? Thanks. -- Craig From owner-freebsd-current@FreeBSD.ORG Sun Aug 24 09:12:59 2014 Return-Path: Delivered-To: freebsd-current@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 73E41435; Sun, 24 Aug 2014 09:12:59 +0000 (UTC) Received: from forward3l.mail.yandex.net (forward3l.mail.yandex.net [IPv6:2a02:6b8:0:1819::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1CB6E38B7; Sun, 24 Aug 2014 09:12:59 +0000 (UTC) Received: from smtp19.mail.yandex.net (smtp19.mail.yandex.net [95.108.252.19]) by forward3l.mail.yandex.net (Yandex) with ESMTP id 642261500CAA; Sun, 24 Aug 2014 13:12:47 +0400 (MSK) Received: from smtp19.mail.yandex.net (localhost [127.0.0.1]) by smtp19.mail.yandex.net (Yandex) with ESMTP id D632CBE0021; Sun, 24 Aug 2014 13:12:46 +0400 (MSK) Received: from 84.201.167.70-vpn.dhcp.yndx.net (84.201.167.70-vpn.dhcp.yndx.net [84.201.167.70]) by smtp19.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id Qy2iT03wqv-CkROTsss; Sun, 24 Aug 2014 13:12:46 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 51b45e1d-c12e-42b5-b556-a3f0de073605 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1408871566; bh=KRT/oTy7tWb2c4Q9xEYyZwEpq0RlimMRURqz0ul6hmI=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type; b=SJeh2uCNVDe/EaSfFyAbjPiE3Sk6j0FwcjlMPuG2HkSqjfRdL/oz+ejUFN5YpeNpH U2/Lq976GHi1D8ocVADOPwzoP1lPmLad/9+tCAVPI0zDXhgjx7T77obJ8mF4sx7/Qa kl7LIIaq69Pe2bzAgzhJZLxvF/b4W72eZXapTr2Y= Authentication-Results: smtp19.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <53F9AC50.1000000@yandex.ru> Date: Sun, 24 Aug 2014 13:11:44 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Craig Rodrigues , Marcel Moolenaar Subject: Re: mkimg used to create gpt image, problem booting References: <853B0396-2C19-49DF-A8E8-8EB43D107597@xcllnt.net> <7CE168C1-6AF3-4AD2-80DB-192AEC49FD2B@xcllnt.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3CjR4WAJlF1aep8D2WqV7Xk1mehf7P342" Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 09:12:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3CjR4WAJlF1aep8D2WqV7Xk1mehf7P342 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 24.08.2014 06:14, Craig Rodrigues wrote: > Hi, >=20 > I did some more experiments, and found that after /boot/loader runs, > if I break into the loader prompt and type "lsdev", I would get this: >=20 > (1) GPT Disk image which boots under QEMU, made by bsdinstall > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > View from loader > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > OK lsdev > cd devices: > disk devices: > disk0: BIOS drive A: > disk1: BIOS drive C: > disk1p1: FreeBSD boot > disk1p2: FreeBSD UFS > disk1p3: FreeBSD swap > pxe devices: >=20 >=20 > View from gpart, after we mdconfig the disk image > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D> 34 10485693 md0 GPT (5.0G) > 34 128 1 freebsd-boot (64K) > 162 9959296 2 freebsd-ufs (4.7G) > 9959458 524288 3 freebsd-swap (256M) > 10483746 1981 - free - (991K) >=20 >=20 > (2) GPT Disk image which fails to boot under QEMU, made by mkimg > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > View from loader > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > OK lsdev > cd devices: > disk devices: > disk0: BIOS drive A: > disk1: BIOS drive C: > pxe devices: >=20 > View from gpart, after we mdconfig the disk image > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > =3D> 3 1784944 md1 GPT (872M) > 3 32 1 freebsd-boot (16K) > 35 1784912 2 freebsd-ufs (872M) >=20 >=20 >=20 > This leads me to believe that there is logic in /boot/loader, > which is not in GEOM, that fails to parse the GPT produced by mkimg. >=20 >=20 > I did some further debugging inside the loader by doing the following. > -> I added "CFLAGS +=3D -DPART_DEBUG" to sys/boot/common/Makefile.inc= > -> I added DEBUG() statements all over sys/boot/common/part.c >=20 > I observed that in sys/boot/common/part.c in the ptbl_gptread() functio= n, > that in this section: >=20 > 305 ent =3D (struct gpt_ent *)tbl; > 306 size =3D MIN(hdr.hdr_entries * hdr.hdr_entsz, > 307 MAXTBLSZ * table->sectorsize); > 308 for (i =3D 0; i < size / hdr.hdr_entsz; i++, ent++) { > 309 if (uuid_equal(&ent->ent_type, &gpt_uuid_unused= , NULL)) > 310 continue; >=20 > ent->ent_type is all 0's, which matches gpt_uuid_unused, so it bails > out of the loop and never adds the gpt partitions to the list of partit= ions > that the loader can access. >=20 > I'm not familiar with the GPT format, nor am I familiar with the > gpt code inside the loader, and how it differs from GEOM. >=20 > Do you have any further ideas of where to hunt for the root cause of > the problem? Yes, the problem is in the ptable_gptread() function. I'll commit the fix= =2E --=20 WBR, Andrey V. Elsukov --3CjR4WAJlF1aep8D2WqV7Xk1mehf7P342 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJT+axWAAoJEAHF6gQQyKF6n7YH/A2govCmT58wOKPHY41fWLSQ H+QG+CwrPZjYk+kSHwvtER3I6LMjID59XBc6NsKRQ3fYwmtRgZHiRSs0lelFpv60 5/7WZURmLvLIAdihc8v1TjIm5xdxNZSYVC5AkZwzjbHmp0KoU5MfN8up98OqsnoY TkuXGCVaGtqqT2ybCyggUyBEyyua6Wi58/sLF2ArzTMU8bwQIqSwjD+P/P61FurV ZzHxnYHjD8vkhhj8EFfzkt4mxAssyEihaARsjaLQ+F1GuTLWEW4XGf2oonfcJ4XS XsHWbCFGmi4aEgF1BEo3zoiRIzJpTgQZyTSIT6kVEPo+vPHXL2n+gSu2P5Hjl14= =+zgW -----END PGP SIGNATURE----- --3CjR4WAJlF1aep8D2WqV7Xk1mehf7P342-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 24 09:21:35 2014 Return-Path: Delivered-To: current@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 BFDE6A70; Sun, 24 Aug 2014 09:21:35 +0000 (UTC) Received: from mtaout.vnode.se (mtaout.vnode.se [192.121.62.130]) by mx1.freebsd.org (Postfix) with ESMTP id 7ED123991; Sun, 24 Aug 2014 09:21:35 +0000 (UTC) Received: from [10.10.10.103] (h60n6-th-c-d4.ias.bredband.telia.com [217.208.44.60]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout.vnode.se (Postfix) with ESMTPSA id 64CEAB059B; Sun, 24 Aug 2014 11:19:11 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Boot loader too large with Aug-11 FreeBSD/i386 11-CURRENT snapshot From: Joel Dahl In-Reply-To: Date: Sun, 24 Aug 2014 11:21:26 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <06EAD266-05B9-4BC3-B99B-400534336533@vnode.se> <20140823071718.GA46031@over-yonder.net> <34C87683-51C4-4EE2-AA01-C100F06178F7@vnode.se> To: Adrian Chadd X-Mailer: Apple Mail (2.1878.6) Cc: "current@freebsd.org" , "Matthew D. Fuller" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 09:21:35 -0000 23 aug 2014 kl. 20:45 skrev Adrian Chadd : > I thought there was a recent discussion about this. > > Would you mind filing a bug so this gets looked at? Done. See Bug 192962. Joel From owner-freebsd-current@FreeBSD.ORG Sun Aug 24 15:23:39 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6AFEF4F5; Sun, 24 Aug 2014 15:23:39 +0000 (UTC) Received: from mail.xcllnt.net (mail.xcllnt.net [50.0.150.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 20A543789; Sun, 24 Aug 2014 15:23:38 +0000 (UTC) Received: from [192.168.2.22] (atc.xcllnt.net [50.0.150.213]) (authenticated bits=0) by mail.xcllnt.net (8.14.9/8.14.9) with ESMTP id s7OFNUx7004207 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 24 Aug 2014 08:23:31 -0700 (PDT) (envelope-from marcel@xcllnt.net) Content-Type: multipart/signed; boundary="Apple-Mail=_27D13418-8280-41EF-A4BB-5C390C423C70"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: mkimg used to create gpt image, problem booting From: Marcel Moolenaar In-Reply-To: <53F9AC50.1000000@yandex.ru> Date: Sun, 24 Aug 2014 08:23:29 -0700 Message-Id: <5003BFAC-D472-47CE-803B-F1AF8BF961B0@xcllnt.net> References: <853B0396-2C19-49DF-A8E8-8EB43D107597@xcllnt.net> <7CE168C1-6AF3-4AD2-80DB-192AEC49FD2B@xcllnt.net> <53F9AC50.1000000@yandex.ru> To: "Andrey V. Elsukov" X-Mailer: Apple Mail (2.1878.6) Cc: Craig Rodrigues , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 15:23:39 -0000 --Apple-Mail=_27D13418-8280-41EF-A4BB-5C390C423C70 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Aug 24, 2014, at 2:11 AM, Andrey V. Elsukov = wrote: > On 24.08.2014 06:14, Craig Rodrigues wrote: >> I did some further debugging inside the loader by doing the = following. >> -> I added "CFLAGS +=3D -DPART_DEBUG" to = sys/boot/common/Makefile.inc >> -> I added DEBUG() statements all over sys/boot/common/part.c >>=20 >> I observed that in sys/boot/common/part.c in the ptbl_gptread() = function, >> that in this section: >>=20 >> 305 ent =3D (struct gpt_ent *)tbl; >> 306 size =3D MIN(hdr.hdr_entries * hdr.hdr_entsz, >> 307 MAXTBLSZ * table->sectorsize); >> 308 for (i =3D 0; i < size / hdr.hdr_entsz; i++, ent++) { >> 309 if (uuid_equal(&ent->ent_type, = &gpt_uuid_unused, NULL)) >> 310 continue; >>=20 >> ent->ent_type is all 0's, which matches gpt_uuid_unused, so it bails >> out of the loop and never adds the gpt partitions to the list of = partitions >> that the loader can access. >=20 > Yes, the problem is in the ptable_gptread() function. I'll commit the = fix. >=20 Actually, no. There is *a* problem in that function: The function does not respect hdr.hdr_entsz when it needs the next entry. It simply uses "ent++", which is fixed our definition of struct gpt_ent and may not match the definition of the writer. I don't see how the loader is responsible for *the* problem. All I see in qemu is that the loader, when it reads a sector, isn't getting the actual sector data that's in the image. Just do a ktrace on qemu and you'll see what I mean. YMMV of course, --=20 Marcel Moolenaar marcel@xcllnt.net --Apple-Mail=_27D13418-8280-41EF-A4BB-5C390C423C70 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlP6A3EACgkQpgWlLWHuifYgfwCeIvzM+vFk32RyHMamcWFwZXJ0 qrgAn2pnmotXNp6y41y3lZ/RaJnyLWTt =kYWo -----END PGP SIGNATURE----- --Apple-Mail=_27D13418-8280-41EF-A4BB-5C390C423C70-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 24 16:59:13 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92499AE2 for ; Sun, 24 Aug 2014 16:59:13 +0000 (UTC) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 165C73F5A for ; Sun, 24 Aug 2014 16:59:12 +0000 (UTC) Received: by mail-la0-f43.google.com with SMTP id gi9so9198276lab.2 for ; Sun, 24 Aug 2014 09:59:10 -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=Y1mEJhft7+E8ISVsMg3TsgPm2W/M12vkjlCxPNa7dLE=; b=D42UaAGQ7pmdofeeMzkp8l/OgSmF4nq/OxaFn6FMWryqtrhnv+Sc9uK01IWHG+l3D6 jaK8fVlPXnhY8HWwre9SmDYBjnQdTADttyYhGDIcUlNhAiZLp0lgw0sIe7OCZwqQBkIt zAB2K8uGEPALa8eT0gxd9bAP3xjkh6SZpNJWgPD1sfbZ34s2otTIgh5B5kF13wODKuZC CaQ7dJUt1S0vE35/uXDqyBlPdEGHZTAwsh9Ry+Ofn7sLe+2mAl/XiTltK7NRxtwEyMOM F8mVn4KM5/Dqms+Ka+TYaxFCiQqSmvXwH7+jMwcHr7QqpsbbfeRD27NkZpHoeyKWWZMX BrSQ== MIME-Version: 1.0 X-Received: by 10.112.163.103 with SMTP id yh7mr8140787lbb.73.1408899550808; Sun, 24 Aug 2014 09:59:10 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.197.107 with HTTP; Sun, 24 Aug 2014 09:59:10 -0700 (PDT) In-Reply-To: <53F9AC50.1000000@yandex.ru> References: <853B0396-2C19-49DF-A8E8-8EB43D107597@xcllnt.net> <7CE168C1-6AF3-4AD2-80DB-192AEC49FD2B@xcllnt.net> <53F9AC50.1000000@yandex.ru> Date: Sun, 24 Aug 2014 09:59:10 -0700 X-Google-Sender-Auth: qK0-V2khIohpDe58l-E5aClSFsw Message-ID: Subject: Re: mkimg used to create gpt image, problem booting From: Craig Rodrigues To: "Andrey V. Elsukov" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current Current , Marcel Moolenaar X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 16:59:13 -0000 On Sun, Aug 24, 2014 at 2:11 AM, Andrey V. Elsukov wrote: > > Yes, the problem is in the ptable_gptread() function. I'll commit the fix. Index: head/sys/boot/common/part.c =================================================================== --- head/sys/boot/common/part.c (revision 270444) +++ head/sys/boot/common/part.c (revision 270445) @@ -254,8 +254,8 @@ table->sectorsize); if (phdr != NULL) { /* Read the primary GPT table. */ - size = MIN(MAXTBLSZ, - phdr->hdr_entries * phdr->hdr_entsz / table->sectorsize); + size = MIN(MAXTBLSZ, (phdr->hdr_entries * phdr->hdr_entsz + + table->sectorsize - 1) / table->sectorsize); if (dread(dev, tbl, size, phdr->hdr_lba_table) == 0 && gpt_checktbl(phdr, tbl, size * table->sectorsize, table->sectors - 1) == 0) { I can confirm that r270445 fixes the problem for me, where I can now QEMU boot a GPT partitioned image created with mkimg. I put some more debugging in the code, and found this: (1) GPT IMAGE CREATED WITH MKIMG =============================== phdr->hdr_entries = 2, phdr->hdr_entsz = 128, table->sectorsize = 512 (2) GPT IMAGE CREATED WITH BSDINSTALL =================================== phdr->hdr_entries = 128, phdr->hdr_entsz = 128, table->sectorsize = 512 Does gpart create a fixed partition table with 128 entries? That would explain a lot. Also, in the gptboot man page, it mentions that gptboot can only boot on systems with 128 partitions or less. This seems like an artificial restriction. Does the gptboot code really enforce this? Not that I have a system with more than 128 partitions. :) Should mkimg be changed to create a partition table with 128 entries by default, to match older versions of FreeBSD which do not have this fix? Thanks for the fix! -- Craig From owner-freebsd-current@FreeBSD.ORG Sun Aug 24 17:08:52 2014 Return-Path: Delivered-To: freebsd-current@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 2884B6A9 for ; Sun, 24 Aug 2014 17:08:52 +0000 (UTC) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A0C2E3057 for ; Sun, 24 Aug 2014 17:08:51 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id z11so11246559lbi.31 for ; Sun, 24 Aug 2014 10:08:49 -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=GX+ffKya+VwekCqOSSDGdYz1e/Bedt+JIgaqLzK6Gto=; b=H92+b6tx1YVMbaTP5VXC7/G2itshuQgBwhbh74OQpT5OmcxtW0kdzo9yCmXVUlxxW/ 7TTf3jNZ+mv/IFyCOKUWBunYSvfe70ENZfKtE9bro4vpQdW2jsnIcG/eYeaJupaAyXe9 YEXpMMXJds7aHExUSwfvbVTJioxRmAXITNNO9yOmBXKCwkrobpp2PISgHawmv6JU07Y8 AVD8O9YrN9JTM2T0zk5OfliuZjNxHFc9is7NM/hqr2j9VgbZkKzisFzsrN+c2GiiLBHO CcsIsWo0ygB1WVnsUwoUsjxPDfeuSDtrEKX2RWGzGmOpQo6mk8a0g6h1wmPS0XX7hozz 9Qtw== MIME-Version: 1.0 X-Received: by 10.152.22.165 with SMTP id e5mr16095579laf.57.1408900129446; Sun, 24 Aug 2014 10:08:49 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.197.107 with HTTP; Sun, 24 Aug 2014 10:08:49 -0700 (PDT) In-Reply-To: <5003BFAC-D472-47CE-803B-F1AF8BF961B0@xcllnt.net> References: <853B0396-2C19-49DF-A8E8-8EB43D107597@xcllnt.net> <7CE168C1-6AF3-4AD2-80DB-192AEC49FD2B@xcllnt.net> <53F9AC50.1000000@yandex.ru> <5003BFAC-D472-47CE-803B-F1AF8BF961B0@xcllnt.net> Date: Sun, 24 Aug 2014 10:08:49 -0700 X-Google-Sender-Auth: S52pMNfnde2fi9U8KV42BoAGcks Message-ID: Subject: Re: mkimg used to create gpt image, problem booting From: Craig Rodrigues To: Marcel Moolenaar Content-Type: text/plain; charset=ISO-8859-1 Cc: "Andrey V. Elsukov" , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 17:08:52 -0000 On Sun, Aug 24, 2014 at 8:23 AM, Marcel Moolenaar wrote: > > On Aug 24, 2014, at 2:11 AM, Andrey V. Elsukov wrote: > >> On 24.08.2014 06:14, Craig Rodrigues wrote: > >>> I did some further debugging inside the loader by doing the following. >>> -> I added "CFLAGS += -DPART_DEBUG" to sys/boot/common/Makefile.inc >>> -> I added DEBUG() statements all over sys/boot/common/part.c >>> >>> I observed that in sys/boot/common/part.c in the ptbl_gptread() function, >>> that in this section: >>> >>> 305 ent = (struct gpt_ent *)tbl; >>> 306 size = MIN(hdr.hdr_entries * hdr.hdr_entsz, >>> 307 MAXTBLSZ * table->sectorsize); >>> 308 for (i = 0; i < size / hdr.hdr_entsz; i++, ent++) { >>> 309 if (uuid_equal(&ent->ent_type, &gpt_uuid_unused, NULL)) >>> 310 continue; >>> >>> ent->ent_type is all 0's, which matches gpt_uuid_unused, so it bails >>> out of the loop and never adds the gpt partitions to the list of partitions >>> that the loader can access. >> >> Yes, the problem is in the ptable_gptread() function. I'll commit the fix. >> > > Actually, no. There is *a* problem in that function: > The function does not respect hdr.hdr_entsz when it > needs the next entry. It simply uses "ent++", which > is fixed our definition of struct gpt_ent and may > not match the definition of the writer. Yes, you are correct. I looked at the GPT format here: http://en.wikipedia.org/wiki/GUID_Partition_Table Although the default size in the specification for a gpt entry is 128 bytes, which matches the size of our "struct gpt_entry", technically, the gpt header could specify a gpt entry size that is something other than 128 bytes. I guess the only restriction seems to be that you cannot have variable sized gpt entries.....they have to match the size of the gpt entry specified in the gpt header. I guess we haven't hit this yet because there are probably very few peopel creating gpt tables with entry sizes other than 128, but in the future, who knows? -- Craig From owner-freebsd-current@FreeBSD.ORG Sun Aug 24 19:05:21 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 15655A33; Sun, 24 Aug 2014 19:05:21 +0000 (UTC) Received: from mail.xcllnt.net (mail.xcllnt.net [50.0.150.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BE3CB3AA3; Sun, 24 Aug 2014 19:05:20 +0000 (UTC) Received: from [192.168.2.22] (atc.xcllnt.net [50.0.150.213]) (authenticated bits=0) by mail.xcllnt.net (8.14.9/8.14.9) with ESMTP id s7OJ5GOl004820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 24 Aug 2014 12:05:17 -0700 (PDT) (envelope-from marcel@xcllnt.net) Content-Type: multipart/signed; boundary="Apple-Mail=_51B92DC2-C176-461C-B6E6-FEA56311AFAB"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: mkimg used to create gpt image, problem booting From: Marcel Moolenaar In-Reply-To: Date: Sun, 24 Aug 2014 12:05:15 -0700 Message-Id: <82000B55-10E5-4348-9F35-38962965A63C@xcllnt.net> References: <853B0396-2C19-49DF-A8E8-8EB43D107597@xcllnt.net> <7CE168C1-6AF3-4AD2-80DB-192AEC49FD2B@xcllnt.net> <53F9AC50.1000000@yandex.ru> To: Craig Rodrigues X-Mailer: Apple Mail (2.1878.6) Cc: "Andrey V. Elsukov" , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 19:05:21 -0000 --Apple-Mail=_51B92DC2-C176-461C-B6E6-FEA56311AFAB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Aug 24, 2014, at 9:59 AM, Craig Rodrigues = wrote: > On Sun, Aug 24, 2014 at 2:11 AM, Andrey V. Elsukov = wrote: >>=20 >> Yes, the problem is in the ptable_gptread() function. I'll commit the = fix. >=20 > Should mkimg be changed to create a partition table with 128 entries > by default, to match older versions of FreeBSD which do not have this = fix? Maybe. 128 is the suggested default. It's not a hard lower limit. Technically speaking, it's perfectly fine to create just enough entries to fill a single sector. Then again, code makes all kinds of assumptions or has all kinds of bugs -- just like the logic in the loader apparently. By having mkimg create a large table, even if it's knows up front that it doesn't have to may prevent broken code from tripping over, bit it surely bloats the image for no reason. --=20 Marcel Moolenaar marcel@xcllnt.net --Apple-Mail=_51B92DC2-C176-461C-B6E6-FEA56311AFAB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlP6N2sACgkQpgWlLWHuifb8MQCghAhFOuY+CJ/VldhoNGXwOktM 5n0AnjAsPVijsT0j7dnvXgPsZPpLF3zs =LCRJ -----END PGP SIGNATURE----- --Apple-Mail=_51B92DC2-C176-461C-B6E6-FEA56311AFAB-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 24 19:17:34 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC80BF2A for ; Sun, 24 Aug 2014 19:17:34 +0000 (UTC) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7AD543B98 for ; Sun, 24 Aug 2014 19:17:34 +0000 (UTC) Received: by mail-qc0-f178.google.com with SMTP id x3so12690463qcv.23 for ; Sun, 24 Aug 2014 12:17:33 -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=Wjfx+qlnT3hxUs99R68tHRveP8KKSlrGxm/vorAbsYs=; b=eL7B5LfTMdUK4Jp0XERmYoz35CW+O+Z4ce+YTXCD/InHNRWgjNdM9OZnT1tr/BFO30 UrEbrDRMsuJVntfdX8AdCtfCZNXCInGfzR23WOv0zqbvWaAGRm3Ep6VPV6itEXyEUWtn 8Zeg91XoaVWdVRiGQjP6jfR9ncyupIcwJZMcxhTglpj2Zzl/n7dHICIzFE7pxgae1TTr b1ZdTlExtuW4N/ZOkxBcZwHUmk0mOVdv82nZW9Xa6sRl8MReJr8wiY3OnlleMX6q9tey Eq++CVXdeELZZX5RoZwqDxrCPfNRqp49E2FUWHX4wkZ5v6uMLtAa5wckZsCj9mg4d3r0 91EQ== MIME-Version: 1.0 X-Received: by 10.229.136.133 with SMTP id r5mr28054616qct.31.1408907853513; Sun, 24 Aug 2014 12:17:33 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.39.139 with HTTP; Sun, 24 Aug 2014 12:17:33 -0700 (PDT) In-Reply-To: References: <06EAD266-05B9-4BC3-B99B-400534336533@vnode.se> <20140823071718.GA46031@over-yonder.net> <34C87683-51C4-4EE2-AA01-C100F06178F7@vnode.se> Date: Sun, 24 Aug 2014 12:17:33 -0700 X-Google-Sender-Auth: Omk82ysZANuyM36Fa1AIRQyVN1U Message-ID: Subject: Re: Boot loader too large with Aug-11 FreeBSD/i386 11-CURRENT snapshot From: Adrian Chadd To: Joel Dahl Content-Type: text/plain; charset=UTF-8 Cc: "current@freebsd.org" , "Matthew D. Fuller" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 19:17:34 -0000 Thanks! -a On 24 August 2014 02:21, Joel Dahl wrote: > > 23 aug 2014 kl. 20:45 skrev Adrian Chadd : > >> I thought there was a recent discussion about this. >> >> Would you mind filing a bug so this gets looked at? > > Done. See Bug 192962. > > Joel > From owner-freebsd-current@FreeBSD.ORG Sun Aug 24 21:42:09 2014 Return-Path: Delivered-To: freebsd-current@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 BB476CBF for ; Sun, 24 Aug 2014 21:42:09 +0000 (UTC) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::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 873153804 for ; Sun, 24 Aug 2014 21:42:09 +0000 (UTC) Received: by mail-ig0-f180.google.com with SMTP id l13so1944412iga.1 for ; Sun, 24 Aug 2014 14:42:08 -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:content-type; bh=D665sF6+VGwA+Z/7pZKm7TNtX2kvqUGTZtXuum2GDJs=; b=q6LkIPxUuMTKOkDqpg31aFrWotNtMMFi6n2xdwio/1iCGOMudDfZr/WwqQhmx09M/R 7RR+tH7ImXDkrcXCHOZJyBT2DXQLi6GoX6tKz5V0FiKrCC/AI0DzFZLip0ACvltXWJ4X 34J5DzLniUUe6fKV3YS6LICLzYgcyHwaJy6Xj+Ohs5/qQQX6O+3GNQ8KN/3AIEGodmae Fg+3YJKxJHo4Lp08PoNbzN3yY0t5fNC8qlH2PY7a/883yyT0O1EYYe1vuVqUG+bx6kHk mX1n1sKDq6JcPn6uLBiA+azaaJ4PHIh/3+r+kybtLa8I5eCK6sRqBOtw5ETMWxD+nVCo 0obA== X-Received: by 10.50.55.68 with SMTP id q4mr11565628igp.44.1408916528819; Sun, 24 Aug 2014 14:42:08 -0700 (PDT) MIME-Version: 1.0 Sender: fedor.indutny@gmail.com Received: by 10.107.148.66 with HTTP; Sun, 24 Aug 2014 14:41:48 -0700 (PDT) In-Reply-To: References: From: Fedor Indutny Date: Mon, 25 Aug 2014 01:41:48 +0400 X-Google-Sender-Auth: 4nH1z46SVZTPaSTEuJJd3ATa9wA Message-ID: Subject: Re: KQueue 0-length UDP packet To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 21:42:09 -0000 Hello again! I just realized that the wording was probably a bit off. What I wanted to ask is: why does FreeBSD kqueue implementation treat `SO_RCVLOWAT` as a raw packet size watermark, and not using the actual data size for filtering out events? I am totally fine with the fact that it triggers event on 0-size udp packets, but the behavior itself seems a bit odd, right? Please let me know if this is a bug, and I'll submit a patch. Cheers, Fedor. On Sat, Aug 2, 2014 at 2:57 PM, Fedor Indutny wrote: > After reading that line more carefully, I wonder if this behavior is > really intentional here. > > It seems to me that `SO_RCVLOWAT` is supposed to set watermark value in > terms of > packet data bytes, not just raw packet size. And this is how `NOTE_LOWAT` > actually > works there, right? > > Could anyone please comment on this? Is it a bug? > > ---------------------- > > Regarding OSX: > > Submitted Apple Bug # 17894467 , with a patch. > > If anyone has friends at Apple who could help getting this in, please let > me know! > > Cheers, > Fedor. > > > On Sat, Aug 2, 2014 at 2:41 PM, Fedor Indutny wrote: > >> Guess I know the answer: >> >> https://cloudup.com/cCkjLhI4M2r >> >> Basically, OSX is checking `kn_data` and FreeBSD is using >> `so->so_rcv.sb_cc`. >> >> Thank you anyway! >> >> >> On Sat, Aug 2, 2014 at 1:39 PM, Fedor Indutny wrote: >> >>> Hello! >>> >>> I'm trying to figure out, why this code: >>> >>> https://github.com/indutny/0-udp >>> >>> Which basically sends a 0-length UDP packet to a server and polls >>> kqueue events on the server fd. >>> >>> Return 1 kevent on FreeBSD, and blocks indefinitely without >>> returning any events on OSX. >>> >>> So far I could see that FreeBSD and OSX are treating NOTE_LOWAT >>> differently: >>> >>> * >>> https://github.com/opensource-apple/xnu/blob/2fa84067f6cdeb23267f877ca4fd26201316da1b/bsd/kern/uipc_socket.c#L4461 >>> * >>> https://github.com/freebsd/freebsd/blob/6901832d8588537c81afbdb91d1a22deb5582c47/sys/kern/uipc_socket.c#L3163-L3164 >>> >>> FreeBSD's NOTE_LOWAT is overriding SO_RCVLOWAT, and OSX is using >>> SO_RVCLOWAT as a minimum value. But, since NOTE_LOWAT is not >>> involved here by default, I'm failing to see where exactly this >>> event could pass through kqueue filter. >>> >>> Could anyone with UDP and/or KQueue implementation knowledge >>> share some insights with me? >>> >>> Thank you very much! >>> Fedor. >>> >>> (NOTE: Duplicate, first email wasn't posted, because I wasn't subscribed >>> to the ML) >>> >> >> > From owner-freebsd-current@FreeBSD.ORG Sun Aug 24 22:37:58 2014 Return-Path: Delivered-To: freebsd-current@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 BA6C296F for ; Sun, 24 Aug 2014 22:37:58 +0000 (UTC) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (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 3EB1D3BF0 for ; Sun, 24 Aug 2014 22:37:58 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id mc6so11788598lab.6 for ; Sun, 24 Aug 2014 15:37:56 -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=R+KxdUqh69NoM+fAVX7Q11XGfkP96OUAsopBdwjap4o=; b=YqdapJW3lFNPJzWDRXV7YvEVA2mRrpRyGjhfHCVT6Gv3Wc5CMSkPJ7U8wzloVvWqj2 L8axeSNvCLQSuak8AZgWsiK6koL4/sizz4OXFIB0MIW4zlYPI8PEZ0BbS4Dinel5+Sj5 3oBC9L4o1Ww90U7Aqj/50IEH2jgcaxIwVX8/wb+nug/OkDptLRAoFW0E4OaQGWHbNC1q mVd75564umg03DUwp6Ik80Axz/O4Q1RAc0QeyvDAgR/gaAaJw45MxpPmd1FzLLsaj6yF IG3kKKY52Wi+jLXoGY3vt7t7NmQ0Lwo8m9LRvGw8hNXos7YrAI7SMjxsyeLVoUN1dkz2 akvQ== MIME-Version: 1.0 X-Received: by 10.112.184.161 with SMTP id ev1mr4043523lbc.82.1408919875925; Sun, 24 Aug 2014 15:37:55 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.197.107 with HTTP; Sun, 24 Aug 2014 15:37:55 -0700 (PDT) In-Reply-To: <82000B55-10E5-4348-9F35-38962965A63C@xcllnt.net> References: <853B0396-2C19-49DF-A8E8-8EB43D107597@xcllnt.net> <7CE168C1-6AF3-4AD2-80DB-192AEC49FD2B@xcllnt.net> <53F9AC50.1000000@yandex.ru> <82000B55-10E5-4348-9F35-38962965A63C@xcllnt.net> Date: Sun, 24 Aug 2014 15:37:55 -0700 X-Google-Sender-Auth: gd-4TOY0Dr-oro6rIP7Y4SgmOZ0 Message-ID: Subject: Re: mkimg used to create gpt image, problem booting From: Craig Rodrigues To: Marcel Moolenaar Content-Type: text/plain; charset=ISO-8859-1 Cc: "Andrey V. Elsukov" , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 22:37:58 -0000 On Sun, Aug 24, 2014 at 12:05 PM, Marcel Moolenaar wrote: > > On Aug 24, 2014, at 9:59 AM, Craig Rodrigues wrote: > >> On Sun, Aug 24, 2014 at 2:11 AM, Andrey V. Elsukov wrote: >>> >>> Yes, the problem is in the ptable_gptread() function. I'll commit the fix. >> > >> Should mkimg be changed to create a partition table with 128 entries >> by default, to match older versions of FreeBSD which do not have this fix? > > Maybe. 128 is the suggested default. It's not a hard lower > limit. Technically speaking, it's perfectly fine to create > just enough entries to fill a single sector. Then again, > code makes all kinds of assumptions or has all kinds of > bugs -- just like the logic in the loader apparently. > > By having mkimg create a large table, even if it's knows > up front that it doesn't have to may prevent broken code > from tripping over, bit it surely bloats the image for > no reason. I see what you are saying. If you have a new device and do "gpart create -s GPT", then this value in sys/geom/part/g_part_gpt.c: .gps_minent = 128, causes the logic in the g_part_ctl_create() function in sys/geom/part/g_part.c to set the number of partitions to 128, and then it calls g_part_ctl_create() which creates the partition table with 128 empty entries. "gpart create" doesn't know how many partitions you want, so it needs to allocate some space up front for the partition table, and then you can do "gpart add" to add the partitions later. With mkimg, you know exactly how many partitions you are creating , so you don't need to specify 128 as the number of partitions. Since only gpart was available for creating GPT partitions, the side-effect of always having 128 partitions hid the bug in the loader. Hopefully Andrey's fix can be backported to at least stable/9, because the loader bug seems to have been there since at least 2012. -- Craig From owner-freebsd-current@FreeBSD.ORG Sun Aug 24 23:10:23 2014 Return-Path: Delivered-To: freebsd-current@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 E67B1724; Sun, 24 Aug 2014 23:10:23 +0000 (UTC) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (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 455503E96; Sun, 24 Aug 2014 23:10:23 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id mc6so11857995lab.20 for ; Sun, 24 Aug 2014 16:10:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=pn2Lwd8ttbhrlQu6T6cd+5CBHz8//0uDF6ia8nxZLPE=; b=DPuvTrYVUyi3lhZ2P4LYy49yTP+wIhX5hpgcIae1/8FH8WbZpOGTJ3DGXVbV4ZNZ6x pDV46tuu6WNSLllyeyj+Typr19bLZXsVcTcZ8Z4bzTHMPyX6R08EDQ9U1hw4qHkoxByf 2KfWqEWsjp7X+Qc/xtQKNTHVL2UJXoVRpFw5U0gdeqOXqJese9FElJvLTQmhshEZeJM9 NunPtmCIK0V6ox2cfFYEUEboKx4LlJTocJFCGiMXClxkB4wEYoh5j5k65Dzh4Ac2GTmh 7aIKs80T6TfPHs/FLwRPhrauduGLc/QGlg7t8IEtlIgRbcpvsGNy4TshubyHLR5u3V6W g8Hw== MIME-Version: 1.0 X-Received: by 10.152.9.170 with SMTP id a10mr4423885lab.79.1408921821206; Sun, 24 Aug 2014 16:10:21 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.197.107 with HTTP; Sun, 24 Aug 2014 16:10:21 -0700 (PDT) Date: Sun, 24 Aug 2014 16:10:21 -0700 X-Google-Sender-Auth: DdTX38kZjTDuyYCMui0lEuugcf0 Message-ID: Subject: "make installworld" commands used to generate manifest for makefs? From: Craig Rodrigues To: freebsd-current Current Content-Type: text/plain; charset=ISO-8859-1 Cc: Brooks Davis X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 23:10:24 -0000 Hi, Is there an easy way to take most of the commands performed during "make installworld" and create a manifest file which is compatible with makefs? That would be very handy for creating file system images. -- Craig From owner-freebsd-current@FreeBSD.ORG Sun Aug 24 23:31:52 2014 Return-Path: Delivered-To: freebsd-current@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 079F1A8B; Sun, 24 Aug 2014 23:31:52 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CDA333076; Sun, 24 Aug 2014 23:31:51 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s7ONVibc087487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Aug 2014 16:31:44 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s7ONVhdX087486; Sun, 24 Aug 2014 16:31:43 -0700 (PDT) (envelope-from jmg) Date: Sun, 24 Aug 2014 16:31:43 -0700 From: John-Mark Gurney To: Craig Rodrigues Subject: Re: mkimg used to create gpt image, problem booting Message-ID: <20140824233143.GQ71691@funkthat.com> Mail-Followup-To: Craig Rodrigues , Marcel Moolenaar , "Andrey V. Elsukov" , freebsd-current Current References: <853B0396-2C19-49DF-A8E8-8EB43D107597@xcllnt.net> <7CE168C1-6AF3-4AD2-80DB-192AEC49FD2B@xcllnt.net> <53F9AC50.1000000@yandex.ru> <82000B55-10E5-4348-9F35-38962965A63C@xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 24 Aug 2014 16:31:44 -0700 (PDT) Cc: "Andrey V. Elsukov" , freebsd-current Current , Marcel Moolenaar X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 23:31:52 -0000 Craig Rodrigues wrote this message on Sun, Aug 24, 2014 at 15:37 -0700: > On Sun, Aug 24, 2014 at 12:05 PM, Marcel Moolenaar wrote: > > > > On Aug 24, 2014, at 9:59 AM, Craig Rodrigues wrote: > > > >> On Sun, Aug 24, 2014 at 2:11 AM, Andrey V. Elsukov wrote: > >>> > >>> Yes, the problem is in the ptable_gptread() function. I'll commit the fix. > >> > > > >> Should mkimg be changed to create a partition table with 128 entries > >> by default, to match older versions of FreeBSD which do not have this fix? > > > > Maybe. 128 is the suggested default. It's not a hard lower > > limit. Technically speaking, it's perfectly fine to create > > just enough entries to fill a single sector. Then again, > > code makes all kinds of assumptions or has all kinds of > > bugs -- just like the logic in the loader apparently. > > > > By having mkimg create a large table, even if it's knows > > up front that it doesn't have to may prevent broken code > > from tripping over, bit it surely bloats the image for > > no reason. > > I see what you are saying. If you have a new device > and do "gpart create -s GPT", then this value in sys/geom/part/g_part_gpt.c: > > .gps_minent = 128, > > causes the logic in the g_part_ctl_create() function in sys/geom/part/g_part.c > to set the number of partitions to 128, and then it calls g_part_ctl_create() > which creates the partition table with 128 empty entries. > > "gpart create" doesn't know how many partitions you want, so it > needs to allocate some space up front for the partition table, > and then you can do "gpart add" to add the partitions later. > > With mkimg, you know exactly how many partitions you are creating > , so you don't need to specify 128 as the number of partitions. Though, w/ people dd'ing images onto disks, and using growfs to grow as necessary, we might want to allocate a few more more than the minimum... I do agree that we want to keep sizes to a minimum... > Since only gpart was available for creating GPT partitions, the side-effect > of always having 128 partitions hid the bug in the loader. > > Hopefully Andrey's fix can be backported to at least stable/9, because > the loader bug seems to have been there since at least 2012. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Sun Aug 24 23:53:37 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E28F3D1B for ; Sun, 24 Aug 2014 23:53:37 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A0B1B3211 for ; Sun, 24 Aug 2014 23:53:37 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s7ONraIJ087816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Aug 2014 16:53:36 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s7ONrac9087815; Sun, 24 Aug 2014 16:53:36 -0700 (PDT) (envelope-from jmg) Date: Sun, 24 Aug 2014 16:53:36 -0700 From: John-Mark Gurney To: Eric van Gyzen Subject: Re: ktrace -c behavior Message-ID: <20140824235336.GR71691@funkthat.com> Mail-Followup-To: Eric van Gyzen , freebsd-current@freebsd.org References: <53F79710.6090700@vangyzen.net> <20140822192034.GA71691@funkthat.com> <53F79971.4050802@vangyzen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53F79971.4050802@vangyzen.net> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 24 Aug 2014 16:53:36 -0700 (PDT) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 23:53:38 -0000 Eric van Gyzen wrote this message on Fri, Aug 22, 2014 at 15:26 -0400: > On 08/22/2014 15:20, John-Mark Gurney wrote: > > Eric van Gyzen wrote this message on Fri, Aug 22, 2014 at 15:16 -0400: > >> What behavior would you expect from this sequence of commands? > >> > >> ktrace -tw -p 1234 > >> ktrace -c -p 1234 > >> > >> Based on this... > >> > >> -c Clear the trace points associated with the specified file > >> or processes. > > and/or just add specified: > > Clear the specified trace points ... > > But what if I didn't specify them? You specified the default by not specificly specifing any different ones.. :) Confused? :) or maybe selected? > >> ...I would expect the second command to clear the trace point for > >> context switches. It doesn't. I have to specify -tw with the -c to get > >> that behavior. This makes sense; it's just not what I was expecting. > >> > >> Assuming we want to keep this behavior, can we clarify the -c flag in > >> man page? I would suggest: > >> > >> If the -t flag is not specified, clear the default set of trace points. > > Maybe we should add a new trace point string that is a (for all).. so > > you can do ktrace -ta -c? > > That would be handy. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Sun Aug 24 23:55:12 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 462F6F2E; Sun, 24 Aug 2014 23:55:12 +0000 (UTC) Received: from mail.xcllnt.net (mail.xcllnt.net [50.0.150.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EEED23232; Sun, 24 Aug 2014 23:55:11 +0000 (UTC) Received: from [192.168.2.22] (atc.xcllnt.net [50.0.150.213]) (authenticated bits=0) by mail.xcllnt.net (8.14.9/8.14.9) with ESMTP id s7ONt8WB005892 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 24 Aug 2014 16:55:09 -0700 (PDT) (envelope-from marcel@xcllnt.net) Content-Type: multipart/signed; boundary="Apple-Mail=_E2489F12-D285-481C-B2A7-772E14078DD9"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: mkimg used to create gpt image, problem booting From: Marcel Moolenaar In-Reply-To: <20140824233143.GQ71691@funkthat.com> Date: Sun, 24 Aug 2014 16:55:08 -0700 Message-Id: <3AC10D0D-2BD8-4D30-A033-7EE9D923F408@xcllnt.net> References: <853B0396-2C19-49DF-A8E8-8EB43D107597@xcllnt.net> <7CE168C1-6AF3-4AD2-80DB-192AEC49FD2B@xcllnt.net> <53F9AC50.1000000@yandex.ru> <82000B55-10E5-4348-9F35-38962965A63C@xcllnt.net> <20140824233143.GQ71691@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1878.6) Cc: Craig Rodrigues , "Andrey V. Elsukov" , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 23:55:12 -0000 --Apple-Mail=_E2489F12-D285-481C-B2A7-772E14078DD9 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Aug 24, 2014, at 4:31 PM, John-Mark Gurney wrote: >> >> With mkimg, you know exactly how many partitions you are creating >> , so you don't need to specify 128 as the number of partitions. > > Though, w/ people dd'ing images onto disks, and using growfs to grow > as necessary, we might want to allocate a few more more than the > minimum... I do agree that we want to keep sizes to a minimum... One thing I can maybe do is simply fill the empty sectors that are there because of alignment. If you add -P 4K to mkimg, then the first partition will by 4K aligned and you have about 5 sectors unused between the end of the GPT table and the first sector of the first partition. I may as well extend the table to cover those unued sectors. However, this is a pretty side-ways way to end up with a GPT table that has some extra room. Maybe having scheme- specific options for this kind of thing is not bad. At least EBR and APM have the same "problem" and the BSD disk label can also be created with more than just 8 partitions. Related: o Is there a need to create images with empty space at the end of in between partitions? o Is there a need to create partitions with specific indices (i.e. index 6 for a typical 'f' partition)? Answers to these questions could help figure this out... -- Marcel Moolenaar marcel@xcllnt.net --Apple-Mail=_E2489F12-D285-481C-B2A7-772E14078DD9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlP6e1wACgkQpgWlLWHuifasOQCfVAZDuKbMjOgAoWEvs6LXWH0D cjMAn3brCREMpfWRzwWBxwXsv7LRXkbq =wCbk -----END PGP SIGNATURE----- --Apple-Mail=_E2489F12-D285-481C-B2A7-772E14078DD9-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 25 00:28:42 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79D255FA for ; Mon, 25 Aug 2014 00:28:42 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 181833550 for ; Mon, 25 Aug 2014 00:28:41 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id m15so12437028wgh.5 for ; Sun, 24 Aug 2014 17:28:40 -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=lqIDh6/ZJzQbyCBXJku0ondmm8aeja8gLO3QTaf4334=; b=diOv12xxVL1M0Mco10G3Zv7PTGTwMaLZIrevOXnZdxNpFPi8M5AlkrKWS7vSoMzqiP +gphv/T4vs3YTZ0/CS1Yg4HA/BjLbN+AHMlet9AtmST6DzUQImDgkupnmsy6G7sGXZEn pPAavIPLtgN83wdZBtAHOoKT1366fFxehadXnlE9GfiiagrNKJoodhNVZbxrdBhBjtRU 2Tw6aQwOUYV693H1oGjikHUKZN8J/F1RIpXRJ1qP8jgXGE+k9KZwAKiYNBS2R06HhpXz f4tchxsJDwE2Fg8HrX43unFCX4VXwe9BPVKAv6xRoTGmrbpNqKteMy/UFeI3LIPS+xH5 BIJg== MIME-Version: 1.0 X-Received: by 10.194.77.35 with SMTP id p3mr19789514wjw.56.1408926519983; Sun, 24 Aug 2014 17:28:39 -0700 (PDT) Received: by 10.216.160.9 with HTTP; Sun, 24 Aug 2014 17:28:39 -0700 (PDT) Date: Sun, 24 Aug 2014 20:28:39 -0400 Message-ID: Subject: Crash on xen/amd64 From: Shawn Webb To: FreeBSD-current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 00:28:42 -0000 I've been getting these occasional kernel panics in my VM: http://imgur.com/BYes0gj,Ay8iDar This time around pkg-static seemed to cause the crash. Thanks, Shawn From owner-freebsd-current@FreeBSD.ORG Mon Aug 25 00:48:02 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7BC74B56 for ; Mon, 25 Aug 2014 00:48:02 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 554EA3817 for ; Mon, 25 Aug 2014 00:48:01 +0000 (UTC) Received: from [192.168.1.2] (senat1-01.HML3.ScaleEngine.net [209.51.186.5]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 4265C3D312 for ; Mon, 25 Aug 2014 00:47:53 +0000 (UTC) Message-ID: <53FA87B8.8030901@freebsd.org> Date: Sun, 24 Aug 2014 20:47:52 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Crash on xen/amd64 References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4K8p9qaQ6lgeIEWIFmAWjjXAoEIlBo7Td" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 00:48:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4K8p9qaQ6lgeIEWIFmAWjjXAoEIlBo7Td Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-08-24 20:28, Shawn Webb wrote: > I've been getting these occasional kernel panics in my VM: > http://imgur.com/BYes0gj,Ay8iDar > This time around pkg-static seemed to cause the crash. >=20 > Thanks, >=20 > Shawn > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 How big is your disk? Is the LBA range listed before the panic the very end of the disk? --=20 Allan Jude --4K8p9qaQ6lgeIEWIFmAWjjXAoEIlBo7Td Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJT+oe6AAoJEJrBFpNRJZKfsRYP/3QZ0P8n2G2vdhAAouiIOSeR WwyquLsFPxPB33zeRevDWhP41xjr5s1nnJzXh+mYowPl1kV5Bbut81aZPokXSm1s k6hlTnNBie7u4JhM1pvmS04LuJA8x2cTqdKFkmgxUQSZ7VVaEkqsKlDrSo2oQvjd lpqwC5yDoTFYL2zd4C0p1Sw68Yt/GdSiYHEqAbxKFq18TCij3OU3tPbjIZ0kpT6r HAsVjvJxcADVBvYY+JkQ37MA1Q/i08uJpYJUAH4+TBHhg/M4P8PEXadcAS2DucOj X/vcGwPqEtfqunJsL4/OynnHTwyYiJKhBxA6oga9EJ62LyDm8MObpw16fOw8jImy necWhxMRgLl/BWHjO6cEp93HepKNi6df6zPuIrLOPBrL90YHFvS9m1YNPFPWAiSt 1iU+krSxuRtEZsxI+8eapmW7ACR/AOqfYFYzzBEfulmLCwzLv1f7sIlM2ZKebfac UPEcLX+QTPw1xZ5NnimLEOh8LHrQS/pQHW/JIlHSrcSGBvIT8krDbbgSNPT4eBjP +cnYg6TMTCGUR96Uc4yT1+JV0cwShw6Lm99nPwJJHWAPyWwTwZ5P3jwq03T/Bg2Y Yv9aK7ErF1RXCteXien/TP21t/oPM5m1V5WzlghLqp3mxnH0b6VdpKhyeB0/nGfF D0wcL8ZZs8guVjMJ1RSB =fyTj -----END PGP SIGNATURE----- --4K8p9qaQ6lgeIEWIFmAWjjXAoEIlBo7Td-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 25 00:51:34 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BBB56DCA; Mon, 25 Aug 2014 00:51:34 +0000 (UTC) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (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 33D85387F; Mon, 25 Aug 2014 00:51:34 +0000 (UTC) Received: by mail-we0-f175.google.com with SMTP id t60so12617084wes.20 for ; Sun, 24 Aug 2014 17:51:32 -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=Ju5O1crM9lxWjYrfgD2W5N5e2qkT1taePDpSixM/TTE=; b=ddlgpj/RrCDmhAJq+6QgRN4sPwMhada+QhiaKLDSWrwEqpZjBCqRAGPIzI575tIBQd O1hj2ts6edmTABX+/qv5/ulL2TL7qCo0wkd2ouRxHZheeGc15PMl7CoYP+6Stp/KraLZ xSWWVHqRAgOBphPQzJi4dpyAYInHV6bSorx9bVs8vcR1PKDuEg1JHTM5N3U0ZqTnifnT R90w+geqy9uyFxc8uJH+U5ANuT84DOWFYwJJYLF/brJ+Q00USwP+7+XzHH/ERvrM6Z4y TRZpNhZ6h3Z3DDH4FXlJ3uh3folxMHQcizPyA9erJub3j9kkDrNmPRCi6Ck8RHkCFdjm KFrw== MIME-Version: 1.0 X-Received: by 10.194.71.210 with SMTP id x18mr18750551wju.6.1408927892311; Sun, 24 Aug 2014 17:51:32 -0700 (PDT) Received: by 10.216.160.9 with HTTP; Sun, 24 Aug 2014 17:51:32 -0700 (PDT) In-Reply-To: <53FA87B8.8030901@freebsd.org> References: <53FA87B8.8030901@freebsd.org> Date: Sun, 24 Aug 2014 20:51:32 -0400 Message-ID: Subject: Re: Crash on xen/amd64 From: Shawn Webb To: Allan Jude Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 00:51:34 -0000 On Sun, Aug 24, 2014 at 8:47 PM, Allan Jude wrote: > On 2014-08-24 20:28, Shawn Webb wrote: > > I've been getting these occasional kernel panics in my VM: > > http://imgur.com/BYes0gj,Ay8iDar > > This time around pkg-static seemed to cause the crash. > > > > Thanks, > > > > Shawn > > _______________________________________________ > > 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" > > > > How big is your disk? Is the LBA range listed before the panic the very > end of the disk? Paste of `gpart list`: http://ix.io/e0X I'm a little unsure how to answer your second question. And I'm unsure if the disk error is related, but it might be. For what it's worth, this is a brand new VPS instance on RootBSD. Thanks, Shawn From owner-freebsd-current@FreeBSD.ORG Mon Aug 25 07:01:29 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D263EA; Mon, 25 Aug 2014 07:01:29 +0000 (UTC) Received: from forward8l.mail.yandex.net (forward8l.mail.yandex.net [IPv6:2a02:6b8:0:1819::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 946B2377D; Mon, 25 Aug 2014 07:01:28 +0000 (UTC) Received: from smtp3h.mail.yandex.net (smtp3h.mail.yandex.net [84.201.186.20]) by forward8l.mail.yandex.net (Yandex) with ESMTP id D161F1A41160; Mon, 25 Aug 2014 11:01:17 +0400 (MSK) Received: from smtp3h.mail.yandex.net (localhost [127.0.0.1]) by smtp3h.mail.yandex.net (Yandex) with ESMTP id 2237E1B44CC4; Mon, 25 Aug 2014 11:01:16 +0400 (MSK) Received: from 5.255.232.27-red.dhcp.yndx.net (5.255.232.27-red.dhcp.yndx.net [5.255.232.27]) by smtp3h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id f28ypVFTyW-1GU8xL7o; Mon, 25 Aug 2014 11:01:16 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 71018a18-88e2-4d3d-a846-7356904fd634 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1408950076; bh=7sPW1zZVuRLYifKzcBF85kgckJ2Ju00U2R5H8KKkhtY=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=qq5Q2GLL1h14qxDTS+ytDBgBxQ7MrFwTSAB8QgpFh7fpLWmrEgi3y0mXA+bjjhaRb ZsbqHweKXX0qFdTwWbKzKjVZRFNMCljICpZF/oGKrdiZL4jrS2qzUxcaOShhIcqqUd Aq5c0WiVepSNKefIk4/nywRR1312dMt29vyf7Vyo= Authentication-Results: smtp3h.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <53FADF14.80904@yandex.ru> Date: Mon, 25 Aug 2014 11:00:36 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Marcel Moolenaar Subject: Re: mkimg used to create gpt image, problem booting References: <853B0396-2C19-49DF-A8E8-8EB43D107597@xcllnt.net> <7CE168C1-6AF3-4AD2-80DB-192AEC49FD2B@xcllnt.net> <53F9AC50.1000000@yandex.ru> <5003BFAC-D472-47CE-803B-F1AF8BF961B0@xcllnt.net> In-Reply-To: <5003BFAC-D472-47CE-803B-F1AF8BF961B0@xcllnt.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Craig Rodrigues , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 07:01:29 -0000 On 24.08.2014 19:23, Marcel Moolenaar wrote: > > On Aug 24, 2014, at 2:11 AM, Andrey V. Elsukov wrote: > >> On 24.08.2014 06:14, Craig Rodrigues wrote: > >>> I did some further debugging inside the loader by doing the following. >>> -> I added "CFLAGS += -DPART_DEBUG" to sys/boot/common/Makefile.inc >>> -> I added DEBUG() statements all over sys/boot/common/part.c >>> >>> I observed that in sys/boot/common/part.c in the ptbl_gptread() function, >>> that in this section: >>> >>> 305 ent = (struct gpt_ent *)tbl; >>> 306 size = MIN(hdr.hdr_entries * hdr.hdr_entsz, >>> 307 MAXTBLSZ * table->sectorsize); >>> 308 for (i = 0; i < size / hdr.hdr_entsz; i++, ent++) { >>> 309 if (uuid_equal(&ent->ent_type, &gpt_uuid_unused, NULL)) >>> 310 continue; >>> >>> ent->ent_type is all 0's, which matches gpt_uuid_unused, so it bails >>> out of the loop and never adds the gpt partitions to the list of partitions >>> that the loader can access. >> >> Yes, the problem is in the ptable_gptread() function. I'll commit the fix. >> > > Actually, no. There is *a* problem in that function: > The function does not respect hdr.hdr_entsz when it > needs the next entry. It simply uses "ent++", which > is fixed our definition of struct gpt_ent and may > not match the definition of the writer. Yes, you are right. I'll fix this. Thanks. > I don't see how the loader is responsible for *the* > problem. All I see in qemu is that the loader, when > it reads a sector, isn't getting the actual sector > data that's in the image. > > Just do a ktrace on qemu and you'll see what I mean. > YMMV of course, Also there is bootparttest utility in the tools/tools/bootparttest. I think it can be useful for debugging. -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Mon Aug 25 07:30:32 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B264A43; Mon, 25 Aug 2014 07:30:32 +0000 (UTC) Received: from forward2l.mail.yandex.net (forward2l.mail.yandex.net [IPv6:2a02:6b8:0:1819::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D1AF53971; Mon, 25 Aug 2014 07:30:31 +0000 (UTC) Received: from smtp2h.mail.yandex.net (smtp2h.mail.yandex.net [84.201.187.145]) by forward2l.mail.yandex.net (Yandex) with ESMTP id 517321AC11DE; Mon, 25 Aug 2014 11:30:22 +0400 (MSK) Received: from smtp2h.mail.yandex.net (localhost [127.0.0.1]) by smtp2h.mail.yandex.net (Yandex) with ESMTP id AC9D017055F6; Mon, 25 Aug 2014 11:30:21 +0400 (MSK) Received: from 5.255.232.27-red.dhcp.yndx.net (5.255.232.27-red.dhcp.yndx.net [5.255.232.27]) by smtp2h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id fQ6xVVucuc-ULMKGvtS; Mon, 25 Aug 2014 11:30:21 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 4b2e2b04-55dd-4fe8-930f-86bcf678fd47 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1408951821; bh=Qf/uH7L8nLNdd18qvW4mq6llCOeuVM6xssGy32HKoPA=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=XfaMDEtz0ehuVS7LEaoMKEMWTk+azLA7ozC+wZgCznjHvY7szKHN3GW115h0L0ijK jgI82u1TfD897Hl/Wpzv7hSRu5UKc2CX1yt2zwUHKO/Gy7IznrbFYvBiiLPqcWJ4i7 mft7u2hosvpHOsGLPBlMd2c4PlIhMS4bnZsmrZ2M= Authentication-Results: smtp2h.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <53FAE5E5.2010005@yandex.ru> Date: Mon, 25 Aug 2014 11:29:41 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Craig Rodrigues Subject: Re: mkimg used to create gpt image, problem booting References: <853B0396-2C19-49DF-A8E8-8EB43D107597@xcllnt.net> <7CE168C1-6AF3-4AD2-80DB-192AEC49FD2B@xcllnt.net> <53F9AC50.1000000@yandex.ru> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current Current , Marcel Moolenaar X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 07:30:32 -0000 On 24.08.2014 20:59, Craig Rodrigues wrote: > Also, in the gptboot man page, it mentions that gptboot can only boot > on systems with 128 partitions or less. This seems like an artificial > restriction. > Does the gptboot code really enforce this? Not that I have a system with more > than 128 partitions. :) It's because gptboot uses static buffer to read and write GPT table. -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Mon Aug 25 07:48:45 2014 Return-Path: Delivered-To: freebsd-current@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 D03EAEAE; Mon, 25 Aug 2014 07:48:45 +0000 (UTC) Received: from forward7l.mail.yandex.net (forward7l.mail.yandex.net [IPv6:2a02:6b8:0:1819::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 627223B04; Mon, 25 Aug 2014 07:48:45 +0000 (UTC) Received: from smtp3h.mail.yandex.net (smtp3h.mail.yandex.net [84.201.186.20]) by forward7l.mail.yandex.net (Yandex) with ESMTP id E94FBBC118C; Mon, 25 Aug 2014 11:48:41 +0400 (MSK) Received: from smtp3h.mail.yandex.net (localhost [127.0.0.1]) by smtp3h.mail.yandex.net (Yandex) with ESMTP id 363FF1B44EC1; Mon, 25 Aug 2014 11:48:41 +0400 (MSK) Received: from 5.255.232.27-red.dhcp.yndx.net (5.255.232.27-red.dhcp.yndx.net [5.255.232.27]) by smtp3h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id OfuJFoxDWM-meUitK4r; Mon, 25 Aug 2014 11:48:40 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: b1060a7f-a0c1-4c1f-b0fa-8bd88b795716 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1408952920; bh=aS+yhRxigrW4ZIbwdktGpuuj9WszxJ1V8rhsBusdZF4=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=QFuIBU+ZwiKAkCfGEYMOvmWARgU1QuOGCfAcZ2xszonKFf9hmmWqaoiZIfb9y+Yik 6FyWOe/Z8mQjQBsxQUnBsxVYxTZrMen+hMepirNPwHl+Dsfv+0L0q7GKb5mGl0x8Jz /h3A+0c7UI+nHLB5qskyldBmcbKLhxgcmK1WWhl8= Authentication-Results: smtp3h.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <53FAEA31.1070108@yandex.ru> Date: Mon, 25 Aug 2014 11:48:01 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Marcel Moolenaar , John-Mark Gurney Subject: Re: mkimg used to create gpt image, problem booting References: <853B0396-2C19-49DF-A8E8-8EB43D107597@xcllnt.net> <7CE168C1-6AF3-4AD2-80DB-192AEC49FD2B@xcllnt.net> <53F9AC50.1000000@yandex.ru> <82000B55-10E5-4348-9F35-38962965A63C@xcllnt.net> <20140824233143.GQ71691@funkthat.com> <3AC10D0D-2BD8-4D30-A033-7EE9D923F408@xcllnt.net> In-Reply-To: <3AC10D0D-2BD8-4D30-A033-7EE9D923F408@xcllnt.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Craig Rodrigues , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 07:48:46 -0000 On 25.08.2014 03:55, Marcel Moolenaar wrote: >> Though, w/ people dd'ing images onto disks, and using growfs to grow >> as necessary, we might want to allocate a few more more than the >> minimum... I do agree that we want to keep sizes to a minimum... > > One thing I can maybe do is simply fill the empty sectors > that are there because of alignment. If you add -P 4K to > mkimg, then the first partition will by 4K aligned and you > have about 5 sectors unused between the end of the GPT > table and the first sector of the first partition. I may > as well extend the table to cover those unued sectors. IMHO, mkimg should behave like gpart and create images in gpart-compatible way. Some users may want to copy the partition layout from the image to real hardware and they will not be able to do it. Also, now FreeBSD 11.0 uses different first usable LBA. By default it is 4k aligned. And this creates some incompatibility with older versions. You can't do `gpart restore` and get the same table, as you had on older system. > However, this is a pretty side-ways way to end up with a > GPT table that has some extra room. Maybe having scheme- > specific options for this kind of thing is not bad. At > least EBR and APM have the same "problem" and the BSD > disk label can also be created with more than just 8 > partitions. I thought about implementing `gpart modify` or `gpart set` -n entries to change number of entries when it is possible (i.e. disklabel(8) can do it, but gpart doesn't). Also in r228076 I changed APM code to calculate maximum number of entries depending from available free space. -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Mon Aug 25 10:50:46 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C0B1C8A; Mon, 25 Aug 2014 10:50:46 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id ED7B43C88; Mon, 25 Aug 2014 10:50:45 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 50D41ADB; Mon, 25 Aug 2014 10:50:46 +0000 (UTC) Date: Mon, 25 Aug 2014 10:50:45 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, rdivacky@FreeBSD.org, ae@FreeBSD.org Message-ID: <960579364.9.1408963846291.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #1311 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 10:50:46 -0000 See Changes: [rdivacky] The standard we compile libc++ with is called c++11 not c++0x. [ae] Since the size of GPT entry may differ from the sizeof(struct gpt_ent)= , use the size from GPT header to iterate entries. Suggested by:=09marcel@ MFC after:=091 week ------------------------------------------ [...truncated 229878 lines...] --- bus_if.h --- awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h --- depend_subdir_dtrace --- --- /usr/obj = --- @ -> --- /usr/obj --- machine -> --- /usr/obj --- --- depend_subdir_et --- --- pci_if.h --- awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h --- depend_subdir_dtrace --- x86 -> --- vnode_if_newproto.h --- awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p --- depend_subdir_et --- --- device_if.h --- awk -f @/tools/makeobjops.awk @/kern/device_if.m -h --- depend_subdir_dtrace --- --- vnode_if_typedef.h --- awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q --- depend_subdir_et --- --- miibus_if.h --- --- depend_subdir_dtrace --- --- vnode_if.h --- --- depend_subdir_et --- awk -f @/tools/makeobjops.awk @/dev/mii/miibus_if.m -h --- depend_subdir_dtrace --- awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h --- depend_subdir_et --- --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KE= RNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj -std=3Diso9899:1999 --- depend_subdir_dtrace --- --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -nostdinc -DFREEBSD32_SYSTRACE -D_KERNEL -= DKLD_MODULE -I -I -I -DHAVE_KERNEL_OPTION_HEADERS -I. -I@= -I@/contrib/altq -I/usr/obj -std=3Diso9899:1999 --- depend_subdir_exca --- =3D=3D=3D> exca (depend) --- /usr/obj --- @ -> --- /usr/obj --- machine -> --- /usr/obj --- x86 -> --- depend_subdir_ext2fs --- --- depend_subdir_exca --- --- device_if.h --- awk -f @/tools/makeobjops.awk @/kern/device_if.m -h --- depend_subdir_ext2fs --- =3D=3D=3D> ext2fs (depend) --- depend_subdir_exca --- --- bus_if.h --- awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h --- depend_subdir_ext2fs --- --- /usr/obj --- @ -> --- depend_subdir_exca --- --- power_if.h --- awk -f @/tools/makeobjops.awk @/dev/pccard/power_if.m -h --- depend_subdir_ext2fs --- --- /usr/obj --- machine -> --- /usr/obj --- x86 -> --- depend_subdir_exca --- --- card_if.h --- awk -f @/tools/makeobjops.awk @/dev/pccard/card_if.m -h --- depend_subdir_ext2fs --- --- opt_ddb.h --- ln -sf /usr/obj opt_ddb.h --- opt_directio.h --- ln -sf /usr/obj opt_directio.h --- opt_quota.h --- ln -sf /usr/obj opt_quota.h --- depend_subdir_exca --- --- pccarddevs.h --- --- depend_subdir_ext2fs --- --- opt_suiddir.h --- --- depend_subdir_exca --- awk -f @/tools/pccarddevs2h.awk @/dev/pccard/pccarddevs --- depend_subdir_ext2fs --- ln -sf /usr/obj opt_suiddir.h --- vnode_if_newproto.h --- awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p --- vnode_if_typedef.h --- awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q --- vnode_if.h --- awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h --- depend_subdir_drm2 --- In file included from :37: @/dev/acpica/acpivar.h:36:10: fatal error: 'acpi_if.h' file not found #include "acpi_if.h" ^ 1 error generated. --- depend_subdir_exca --- --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KE= RNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj -std=3Diso9899:1999 --- depend_subdir_ext2fs --- --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KE= RNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj -std=3Diso9899:1999 --- depend_subdir_fatm --- =3D=3D=3D> fatm (depend) --- /usr/obj --- @ -> --- /usr/obj --- machine -> --- /usr/obj --- x86 -> --- device_if.h --- awk -f @/tools/makeobjops.awk @/kern/device_if.m -h --- bus_if.h --- awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h --- depend_subdir_fdc --- =3D=3D=3D> fdc (depend) --- depend_subdir_fatm --- --- pci_if.h --- awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h --- depend_subdir_fdc --- --- /usr/obj --- @ -> --- depend_subdir_fatm --- --- opt_inet.h --- ln -sf /usr/obj opt_inet.h --- depend_subdir_fdc --- --- /usr/obj --- --- depend_subdir_fatm --- --- opt_natm.h --- ln -sf /usr/obj opt_natm.h --- depend_subdir_fdc --- machine -> --- /usr/obj --- --- depend_subdir_fatm --- --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KE= RNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj -std=3Diso9899:1999 --- depend_subdir_fdc --- x86 -> --- opt_acpi.h --- ln -sf /usr/obj opt_acpi.h --- acpi_if.h --- awk -f @/tools/makeobjops.awk @/dev/acpica/acpi_if.m -h --- opt_fdc.h --- ln -sf /usr/obj opt_fdc.h --- bus_if.h --- awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h --- card_if.h --- awk -f @/tools/makeobjops.awk @/dev/pccard/card_if.m -h --- device_if.h --- awk -f @/tools/makeobjops.awk @/kern/device_if.m -h --- isa_if.h --- awk -f @/tools/makeobjops.awk @/isa/isa_if.m -h --- depend_subdir_fdescfs --- =3D=3D=3D> fdescfs (depend) --- depend_subdir_fdc --- --- pccarddevs.h --- awk -f @/tools/pccarddevs2h.awk @/dev/pccard/pccarddevs --- depend_subdir_fdescfs --- --- /usr/obj --- @ -> --- /usr/obj --- machine -> --- /usr/obj --- x86 -> --- vnode_if_newproto.h --- awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p --- vnode_if_typedef.h --- awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q --- depend_subdir_fdc --- --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KE= RNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj -std=3Diso9899:1999 --- depend_subdir_fdescfs --- --- vnode_if.h --- awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KE= RNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj -std=3Diso9899:1999 --- depend_subdir_filemon --- =3D=3D=3D> filemon (depend) --- depend_subdir_firewire --- =3D=3D=3D> firewire (depend) --- depend_subdir_filemon --- --- /usr/obj --- --- depend_subdir_drm2 --- mkdep: compile failed --- depend_subdir_filemon --- @ -> --- depend_subdir_drm2 --- *** [.depend] Error code 1 make[5]: stopped in 1 error make[5]: stopped in *** [_sub.depend] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [depend_subdir_drm2] Error code 2 make[3]: stopped in --- depend_subdir_filemon --- A failure has been detected in another branch of the parallel make make[4]: stopped in *** [depend_subdir_filemon] Error code 2 make[3]: stopped in --- depend_subdir_firewire --- A failure has been detected in another branch of the parallel make make[4]: stopped in *** [depend_subdir_firewire] Error code 2 make[3]: stopped in --- depend_subdir_ext2fs --- A failure has been detected in another branch of the parallel make make[4]: stopped in *** [depend_subdir_ext2fs] Error code 2 make[3]: stopped in 4 errors make[3]: stopped in *** [modules-depend] 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-current@FreeBSD.ORG Mon Aug 25 13:21:50 2014 Return-Path: Delivered-To: freebsd-current@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 342019D4 for ; Mon, 25 Aug 2014 13:21:50 +0000 (UTC) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id 1645B3AE3 for ; Mon, 25 Aug 2014 13:21:50 +0000 (UTC) Received: from marvin.lab.vangyzen.net (c-24-125-214-90.hsd1.va.comcast.net [24.125.214.90]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 3094456436 for ; Mon, 25 Aug 2014 08:21:49 -0500 (CDT) Message-ID: <53FB386C.9030800@vangyzen.net> Date: Mon, 25 Aug 2014 09:21:48 -0400 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: ktrace -c behavior References: <53F79710.6090700@vangyzen.net> <20140822192034.GA71691@funkthat.com> <53F79971.4050802@vangyzen.net> <20140824235336.GR71691@funkthat.com> In-Reply-To: <20140824235336.GR71691@funkthat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 13:21:50 -0000 On 08/24/2014 19:53, John-Mark Gurney wrote: > Eric van Gyzen wrote this message on Fri, Aug 22, 2014 at 15:26 -0400: >> On 08/22/2014 15:20, John-Mark Gurney wrote: >>> Eric van Gyzen wrote this message on Fri, Aug 22, 2014 at 15:16 -0400: >>>> What behavior would you expect from this sequence of commands? >>>> >>>> ktrace -tw -p 1234 >>>> ktrace -c -p 1234 >>>> >>>> Based on this... >>>> >>>> -c Clear the trace points associated with the specified file >>>> or processes. >>> and/or just add specified: >>> Clear the specified trace points ... >> But what if I didn't specify them? > You specified the default by not specificly specifing any different > ones.. :) Confused? :) Amused. :) > or maybe selected? Perhaps, but I didn't select them, either. My original suggestion is more--dare I use this word again--specific. It explains exactly how the command behaves. Eric From owner-freebsd-current@FreeBSD.ORG Mon Aug 25 14:04:36 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7058B1F for ; Mon, 25 Aug 2014 14:04:36 +0000 (UTC) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Cybertrust Public SureServer SV CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E7B9F3F26 for ; Mon, 25 Aug 2014 14:04:35 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.04,397,1406592000"; d="scan'208";a="164872263" Received: from [IPv6:::1] (10.80.16.47) by smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id 14.3.181.6; Mon, 25 Aug 2014 10:04:12 -0400 Message-ID: <53FB4259.1000705@citrix.com> Date: Mon, 25 Aug 2014 16:04:09 +0200 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Shawn Webb , FreeBSD-current Subject: Re: Crash on xen/amd64 References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-DLP: MIA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 14:04:36 -0000 On 25/08/14 02:28, Shawn Webb wrote: > I've been getting these occasional kernel panics in my VM: > http://imgur.com/BYes0gj,Ay8iDar > This time around pkg-static seemed to cause the crash. Hello, AFAICT this doesn't seem to be related to the other crash you posted on: http://lists.freebsd.org/pipermail/freebsd-xen/2014-July/002159.html Can you get a backtrace? Roger. From owner-freebsd-current@FreeBSD.ORG Mon Aug 25 14:41:01 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 186245DD; Mon, 25 Aug 2014 14:41:01 +0000 (UTC) Received: from mail.xcllnt.net (mail.xcllnt.net [50.0.150.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D8372333D; Mon, 25 Aug 2014 14:41:00 +0000 (UTC) Received: from [172.23.227.91] ([66.129.246.4]) (authenticated bits=0) by mail.xcllnt.net (8.14.9/8.14.9) with ESMTP id s7PEeuGv008784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Aug 2014 07:40:58 -0700 (PDT) (envelope-from marcel@xcllnt.net) Content-Type: multipart/signed; boundary="Apple-Mail=_757AD842-0A21-49E3-9AC8-2B78A23C85C6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: mkimg used to create gpt image, problem booting From: Marcel Moolenaar In-Reply-To: <53FAEA31.1070108@yandex.ru> Date: Mon, 25 Aug 2014 07:40:50 -0700 Message-Id: References: <853B0396-2C19-49DF-A8E8-8EB43D107597@xcllnt.net> <7CE168C1-6AF3-4AD2-80DB-192AEC49FD2B@xcllnt.net> <53F9AC50.1000000@yandex.ru> <82000B55-10E5-4348-9F35-38962965A63C@xcllnt.net> <20140824233143.GQ71691@funkthat.com> <3AC10D0D-2BD8-4D30-A033-7EE9D923F408@xcllnt.net> <53FAEA31.1070108@yandex.ru> To: "Andrey V. Elsukov" X-Mailer: Apple Mail (2.1878.6) Cc: Craig Rodrigues , John-Mark Gurney , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 14:41:01 -0000 --Apple-Mail=_757AD842-0A21-49E3-9AC8-2B78A23C85C6 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 On Aug 25, 2014, at 12:48 AM, Andrey V. Elsukov wrote: > On 25.08.2014 03:55, Marcel Moolenaar wrote: >>> Though, w/ people dd'ing images onto disks, and using growfs to grow >>> as necessary, we might want to allocate a few more more than the >>> minimum... I do agree that we want to keep sizes to a minimum... >> >> One thing I can maybe do is simply fill the empty sectors >> that are there because of alignment. If you add -P 4K to >> mkimg, then the first partition will by 4K aligned and you >> have about 5 sectors unused between the end of the GPT >> table and the first sector of the first partition. I may >> as well extend the table to cover those unued sectors. > > IMHO, mkimg should behave like gpart and create images in > gpart-compatible way. It already does. There's s difference between behaving like something else or behaving exactly identical to that something. The same applies to compatible. It is not the same as identical. There is no compatibility issue. mkimg follows the GPT specification (modulo bugs) and gpart happily groks the partition table. > Some users may want to copy the partition layout > from the image to real hardware and they will not be able to do it. I'm inclined to say that generally speaking this is not possible. The GPT has metadata in the first few sectors *and* the last few sectors and LBAs of these sectors are part of the metadata. You cannot blindly copy an image onto a physical medium unless the image and the physical medium are of exactly the same size. Odds are they are not. To reliably transfer or convert an image (e.g. RAW->VHD) one must modify the image as part of the process. Not a hard rule, but best to assume as a rule of thumb. This seems to warrant a utility all by itself. > Also, now FreeBSD 11.0 uses different first usable LBA. By default it is > 4k aligned. And this creates some incompatibility with older versions. > You can't do `gpart restore` and get the same table, as you had on older > system. It sounds restore is broken then. The restore command cannot ever assume anything about the GPT. Including the tool that created the GPT. In order to restore a GPT, it must be properly backed-up. The backup header and table should suffice most of the time for that purpose as it's a replica, but as soon as meta-data is missing and the restore command has to guess, things will go wrong. -- Marcel Moolenaar marcel@xcllnt.net --Apple-Mail=_757AD842-0A21-49E3-9AC8-2B78A23C85C6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlP7SvIACgkQpgWlLWHuifZl5wCeOzKi+goy+G3DWYgpyaYHX+Mp nOcAmwQXh+tDRxxUcw+vWkCvlSgB5jij =/jUa -----END PGP SIGNATURE----- --Apple-Mail=_757AD842-0A21-49E3-9AC8-2B78A23C85C6-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 25 15:03:39 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF62D29C; Mon, 25 Aug 2014 15:03:39 +0000 (UTC) Received: from forward9l.mail.yandex.net (forward9l.mail.yandex.net [IPv6:2a02:6b8:0:1819::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7C5B135D4; Mon, 25 Aug 2014 15:03:39 +0000 (UTC) Received: from smtp2h.mail.yandex.net (smtp2h.mail.yandex.net [84.201.187.145]) by forward9l.mail.yandex.net (Yandex) with ESMTP id 00796E60CB7; Mon, 25 Aug 2014 19:03:26 +0400 (MSK) Received: from smtp2h.mail.yandex.net (localhost [127.0.0.1]) by smtp2h.mail.yandex.net (Yandex) with ESMTP id 2D321170569F; Mon, 25 Aug 2014 19:03:26 +0400 (MSK) Received: from 5.255.232.27-red.dhcp.yndx.net (5.255.232.27-red.dhcp.yndx.net [5.255.232.27]) by smtp2h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 3HqVXSOlvW-3PMapNL4; Mon, 25 Aug 2014 19:03:25 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 9a8b763c-7d9c-4e8b-bec4-acaee4fe2879 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1408979005; bh=4GYq00Jy1ZyKcpLtt5fsj13TeHTrYLT5Q/Gb5BV9zqY=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=aCfVIaVPCvqlIHSH/lpKoedijGnFiepafg+cS0fajYvD3HS19L0AjLc1lGz7ffE5x yqaDvEdS35nFzf1/T19frBD7I4ggnhpCOba11ggmL8pmQ9lOZh9B6mZmWus42lqn/W CxEpdwubl30vj4Sy0cqBfKpE8nOc2PKLf0BbhwBs= Authentication-Results: smtp2h.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <53FB5014.40402@yandex.ru> Date: Mon, 25 Aug 2014 19:02:44 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Marcel Moolenaar Subject: Re: mkimg used to create gpt image, problem booting References: <853B0396-2C19-49DF-A8E8-8EB43D107597@xcllnt.net> <7CE168C1-6AF3-4AD2-80DB-192AEC49FD2B@xcllnt.net> <53F9AC50.1000000@yandex.ru> <82000B55-10E5-4348-9F35-38962965A63C@xcllnt.net> <20140824233143.GQ71691@funkthat.com> <3AC10D0D-2BD8-4D30-A033-7EE9D923F408@xcllnt.net> <53FAEA31.1070108@yandex.ru> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Craig Rodrigues , John-Mark Gurney , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 15:03:39 -0000 On 25.08.2014 18:40, Marcel Moolenaar wrote: >> Also, now FreeBSD 11.0 uses different first usable LBA. By default it is >> 4k aligned. And this creates some incompatibility with older versions. >> You can't do `gpart restore` and get the same table, as you had on older >> system. > > It sounds restore is broken then. The restore command > cannot ever assume anything about the GPT. Including > the tool that created the GPT. In order to restore a > GPT, it must be properly backed-up. The backup header > and table should suffice most of the time for that > purpose as it's a replica, but as soon as meta-data is > missing and the restore command has to guess, things > will go wrong. `gpart restore` just uses a number of commands to geom_part(4) to create partition table similar to what was backed up. If your partition table on the old system had a partition that starts from LBA 34, now `gpart create` isn't able to create such partition table. Because by default the first usable LBA is 40. -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Mon Aug 25 15:06:59 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 28ABE5F6 for ; Mon, 25 Aug 2014 15:06:59 +0000 (UTC) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B57773608 for ; Mon, 25 Aug 2014 15:06:58 +0000 (UTC) Received: by mail-we0-f169.google.com with SMTP id u56so13500556wes.0 for ; Mon, 25 Aug 2014 08:06:55 -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=c7AiCenHOx4s/7UvVZs/3EXosdJwk3ij4C5JnlAX9i0=; b=QvuXYFfi54sRIKWRoxawL9OCRqSKXDmcZCumYvngbzilxgDXBeBRh6iPisaaaiXEwa XB4bY+iCxMwd5b7tc7aSqfbQJTc/mlEiTxZLLPie6HFhu4jkLd13aZ/7dBvHB7TqWkIx 8DIqBk3n+vrSqdLIc4uipot1OV/8ZplQ9HIHenKz1Hi9ft6id2rX/kzonmaaiLj536z7 VsSLViAw9wi9fHDcK1q8pcKub6rEDf6+b7+ZDJ6yXmtHbUv8XFBzo26lNnVHJHJAJlrD Byl9eFTryHeJRoiOLx8wN5Vqe8+d/DEXXo6gSHFn8lKCBBsSPQmQoBSR0Bk1eo06gopU AIEg== MIME-Version: 1.0 X-Received: by 10.180.106.8 with SMTP id gq8mr15921984wib.56.1408979215917; Mon, 25 Aug 2014 08:06:55 -0700 (PDT) Received: by 10.216.160.9 with HTTP; Mon, 25 Aug 2014 08:06:55 -0700 (PDT) In-Reply-To: <53FB4259.1000705@citrix.com> References: <53FB4259.1000705@citrix.com> Date: Mon, 25 Aug 2014 11:06:55 -0400 Message-ID: Subject: Re: Crash on xen/amd64 From: Shawn Webb To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 15:06:59 -0000 Mon, Aug 25, 2014 at 10:04 AM, Roger Pau Monn=C3=A9 = wrote: > On 25/08/14 02:28, Shawn Webb wrote: > > I've been getting these occasional kernel panics in my VM: > > http://imgur.com/BYes0gj,Ay8iDar > > This time around pkg-static seemed to cause the crash. > > Hello, > > AFAICT this doesn't seem to be related to the other crash you posted on: > > http://lists.freebsd.org/pipermail/freebsd-xen/2014-July/002159.html > > Can you get a backtrace? Backtrace is shown in the second image here: http://imgur.com/BYes0gj,Ay8iDar Thanks, Shawn From owner-freebsd-current@FreeBSD.ORG Mon Aug 25 17:00:26 2014 Return-Path: Delivered-To: freebsd-current@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 57764E8A; Mon, 25 Aug 2014 17:00:26 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 451EF3164; Mon, 25 Aug 2014 17:00:26 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 73B44B4A; Mon, 25 Aug 2014 17:00:26 +0000 (UTC) Date: Mon, 25 Aug 2014 17:00:25 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, rdivacky@FreeBSD.org, ae@FreeBSD.org, dumbbell@FreeBSD.org Message-ID: <2056110852.10.1408986026393.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <960579364.9.1408963846291.JavaMail.jenkins@jenkins-9.freebsd.org> References: <960579364.9.1408963846291.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD #1312 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 17:00:26 -0000 See From owner-freebsd-current@FreeBSD.ORG Mon Aug 25 17:04:53 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E8E91CA; Mon, 25 Aug 2014 17:04:53 +0000 (UTC) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) by mx1.freebsd.org (Postfix) with ESMTP id 674A731C5; Mon, 25 Aug 2014 17:04:53 +0000 (UTC) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 804385A9F24; Mon, 25 Aug 2014 16:55:22 +0000 (UTC) Date: Mon, 25 Aug 2014 16:55:22 +0000 From: Brooks Davis To: Craig Rodrigues Subject: Re: "make installworld" commands used to generate manifest for makefs? Message-ID: <20140825165522.GC91673@spindle.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f+W+jCU1fRNres8c" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 17:04:53 -0000 --f+W+jCU1fRNres8c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 24, 2014 at 04:10:21PM -0700, Craig Rodrigues wrote: > Hi, >=20 > Is there an easy way to take most of the commands performed > during "make installworld" and create a manifest file > which is compatible with makefs? make -DNO_ROOT -DDB_FROM_SRC DESTDIR=3D installworld should result in a /METALOG file suitable for passing to makefs. You may also want the distribution target if you want a populated /etc. -- Broks --f+W+jCU1fRNres8c Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlP7ankACgkQXY6L6fI4GtQWBwCfV+AJlkipOCDJThwUpNC2BCzA VQkAniL7bxSbJcdqSd671VYaahRK5f9L =Q1Mr -----END PGP SIGNATURE----- --f+W+jCU1fRNres8c-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 25 17:38:16 2014 Return-Path: Delivered-To: freebsd-current@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 DCDE31B8; Mon, 25 Aug 2014 17:38:15 +0000 (UTC) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::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 38F2535FA; Mon, 25 Aug 2014 17:38:15 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id w7so24035lbi.2 for ; Mon, 25 Aug 2014 10:38:13 -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:content-transfer-encoding; bh=XH7naPgDTUPA0T6evfOtZc/xPEsPAjH78jcrND5STP0=; b=OdO7BP/WcIPLCl7S4IMEMJvQf5WtrULXK0FWZ3FndvRt4mpU8vYjDR7xtvZZC2MI15 pNiimNnqAplnDL3dAocGCr35tGW02pqrDIa33eJAd4EgmkM2/9Emk6wlEfP/UO4gJx0O 3BeovKDZ3u9j3Fq75e4GIXpr8/VyRozg2te1AS0+VICxcBC+IxFqJZercloSnwiXW+ju XKSfQMkJJ3M0qQ/EZeAq8dDFHIUgbVbqbMK/edJXEvPDGLrC6q89t3Doalk90z5YJZAY UM6nvliiCuom7doblyeMxlpS5Cg3ITLIkN3DfXFw+Nkds1wglvi7M3EomDGbW4CuHxoK x/YA== MIME-Version: 1.0 X-Received: by 10.152.19.167 with SMTP id g7mr22720642lae.46.1408988292986; Mon, 25 Aug 2014 10:38:12 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.197.107 with HTTP; Mon, 25 Aug 2014 10:38:12 -0700 (PDT) In-Reply-To: <20140825165522.GC91673@spindle.one-eyed-alien.net> References: <20140825165522.GC91673@spindle.one-eyed-alien.net> Date: Mon, 25 Aug 2014 10:38:12 -0700 X-Google-Sender-Auth: SzyaFGm2dN3vXQ_RpzKXg4h-fzk Message-ID: Subject: Re: "make installworld" commands used to generate manifest for makefs? From: Craig Rodrigues To: Brooks Davis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 17:38:16 -0000 On Mon, Aug 25, 2014 at 9:55 AM, Brooks Davis wrote: > On Sun, Aug 24, 2014 at 04:10:21PM -0700, Craig Rodrigues wrote: >> Hi, >> >> Is there an easy way to take most of the commands performed >> during "make installworld" and create a manifest file >> which is compatible with makefs? > > make -DNO_ROOT -DDB_FROM_SRC DESTDIR=3D installworld > > should result in a /METALOG file suitable for passing to makefs. > You may also want the distribution target if you want a populated /etc. > > -- Broks Hi, I got this: # make -DNO_ROOT -DDB_FROM_SRC DESTDIR=3D/tmp installworld mkdir -p /tmp/install.hEJfJDhM progs=3D$(for prog in [ awk cap_mkdb cat chflags chmod chown date echo egrep find grep id install ln lockf make mkdir mtree mv pwd_mkdb rm sed services_mkdb sh sysctl test true uname wc zic tzsetup ; do if progpath=3D`which $prog`; then echo $progpath; else echo "Required tool $prog not found in PATH." >&2; exit 1; fi; done); libs=3D$(ldd -f "%o %p\n" -f "%o %p\n" $progs 2>/dev/null | sort -u | while read line; do set -- $line; if [ "$2 $3" !=3D "not found" ]; then echo $2; else echo "Required library $1 not found." >&2; exit 1; fi; done); cp $libs $progs /tmp/install.hEJfJDhM cp -R ${PATH_LOCALE:-"/usr/share/locale"} /tmp/install.hEJfJDhM/locale echo "#mtree 2.0" > /tmp//METALOG cd /usr/src; MAKEOBJDIRPREFIX=3D/usr/obj MACHINE_ARCH=3Damd64 MACHINE=3Damd64 CPUTYPE=3D GROFF_BIN_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/tmac PATH=3D/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:/tmp/install.hEJfJDhM LD_LIBRARY_PATH=3D/tmp/install.hEJfJDhM PATH_LOCALE=3D/tmp/install.hEJfJDhM/locale make -DWITH_ATF -f Makefile.inc1 INSTALL=3D"install -N /usr/src/etc -U -M /tmp//METALOG -D /tmp" MTREE_CMD=3D"mtree -N /usr/src/etc -W" __MAKE_SHELL=3D/tmp/install.hEJfJDhM/sh -DNO_ROOT METALOG=3D/tmp//METALOG reinstall; MAKEOBJDIRPREFIX=3D/usr/obj MACHINE_ARCH=3Damd64 MACHINE=3Damd6= 4 CPUTYPE=3D GROFF_BIN_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/tmac PATH=3D/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:/tmp/install.hEJfJDhM LD_LIBRARY_PATH=3D/tmp/install.hEJfJDhM PATH_LOCALE=3D/tmp/install.hEJfJDhM/locale rm -rf /tmp/install.hEJfJDhM make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 37: Unable to determine compiler type for cc. Consider setting COMPILER_TYPE. *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src From owner-freebsd-current@FreeBSD.ORG Mon Aug 25 17:38:43 2014 Return-Path: Delivered-To: freebsd-current@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 3B0FA2BF; Mon, 25 Aug 2014 17:38:43 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 112D93608; Mon, 25 Aug 2014 17:38:42 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s7PHcfCo004996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Aug 2014 10:38:41 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s7PHceHc004995; Mon, 25 Aug 2014 10:38:40 -0700 (PDT) (envelope-from jmg) Date: Mon, 25 Aug 2014 10:38:40 -0700 From: John-Mark Gurney To: "Andrey V. Elsukov" Subject: Re: mkimg used to create gpt image, problem booting Message-ID: <20140825173840.GT71691@funkthat.com> Mail-Followup-To: "Andrey V. Elsukov" , Marcel Moolenaar , Craig Rodrigues , freebsd-current Current References: <53F9AC50.1000000@yandex.ru> <82000B55-10E5-4348-9F35-38962965A63C@xcllnt.net> <20140824233143.GQ71691@funkthat.com> <3AC10D0D-2BD8-4D30-A033-7EE9D923F408@xcllnt.net> <53FAEA31.1070108@yandex.ru> <53FB5014.40402@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53FB5014.40402@yandex.ru> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 25 Aug 2014 10:38:41 -0700 (PDT) Cc: Craig Rodrigues , freebsd-current Current , Marcel Moolenaar X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 17:38:43 -0000 Andrey V. Elsukov wrote this message on Mon, Aug 25, 2014 at 19:02 +0400: > On 25.08.2014 18:40, Marcel Moolenaar wrote: > >> Also, now FreeBSD 11.0 uses different first usable LBA. By default it is > >> 4k aligned. And this creates some incompatibility with older versions. > >> You can't do `gpart restore` and get the same table, as you had on older > >> system. > > > > It sounds restore is broken then. The restore command > > cannot ever assume anything about the GPT. Including > > the tool that created the GPT. In order to restore a > > GPT, it must be properly backed-up. The backup header > > and table should suffice most of the time for that > > purpose as it's a replica, but as soon as meta-data is > > missing and the restore command has to guess, things > > will go wrong. > > `gpart restore` just uses a number of commands to geom_part(4) to create > partition table similar to what was backed up. If your partition table > on the old system had a partition that starts from LBA 34, now `gpart > create` isn't able to create such partition table. Because by default > the first usable LBA is 40. Luckily, gpart restore won't work: # gpart backup /dev/md0 GPT 4 1 freebsd-ufs 8 262144 # gpart restore md1 < /tmp/foob.gpt.back gpart: entries '4': Invalid argument So, we're somewhat safe, guess gpart restore needs to learn how to handle entries properly.... We should fix this, since other OS's might not use 128 for entries.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Mon Aug 25 19:36:30 2014 Return-Path: Delivered-To: freebsd-current@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 A72F0427; Mon, 25 Aug 2014 19:36:30 +0000 (UTC) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) by mx1.freebsd.org (Postfix) with ESMTP id 63301332D; Mon, 25 Aug 2014 19:36:30 +0000 (UTC) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 5B1195A9F25; Mon, 25 Aug 2014 19:36:29 +0000 (UTC) Date: Mon, 25 Aug 2014 19:36:29 +0000 From: Brooks Davis To: Craig Rodrigues Subject: Re: "make installworld" commands used to generate manifest for makefs? Message-ID: <20140825193629.GD91673@spindle.one-eyed-alien.net> References: <20140825165522.GC91673@spindle.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eheScQNz3K90DVRs" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 19:36:30 -0000 --eheScQNz3K90DVRs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 25, 2014 at 10:38:12AM -0700, Craig Rodrigues wrote: > On Mon, Aug 25, 2014 at 9:55 AM, Brooks Davis wrote: > > On Sun, Aug 24, 2014 at 04:10:21PM -0700, Craig Rodrigues wrote: > >> Hi, > >> > >> Is there an easy way to take most of the commands performed > >> during "make installworld" and create a manifest file > >> which is compatible with makefs? > > > > make -DNO_ROOT -DDB_FROM_SRC DESTDIR=3D installworld > > > > should result in a /METALOG file suitable for passing to makefs. > > You may also want the distribution target if you want a populated /etc. > > > > -- Broks >=20 > Hi, >=20 > I got this: >=20 >=20 > # make -DNO_ROOT -DDB_FROM_SRC DESTDIR=3D/tmp installworld you really don't want DESTDIR=3D/tmp, it will install a full OS in that directory along with the METALOG file. > mkdir -p /tmp/install.hEJfJDhM > progs=3D$(for prog in [ awk cap_mkdb cat chflags chmod chown date echo > egrep find grep id install ln lockf make mkdir mtree mv pwd_mkdb rm > sed services_mkdb sh sysctl test true uname wc zic tzsetup ; do if > progpath=3D`which $prog`; then echo $progpath; else echo "Required > tool $prog not found in PATH." >&2; exit 1; fi; done); libs=3D$(ldd > -f "%o %p\n" -f "%o %p\n" $progs 2>/dev/null | sort -u | while read > line; do set -- $line; if [ "$2 $3" !=3D "not found" ]; then echo $2; > else echo "Required library $1 not found." >&2; exit 1; fi; > done); cp $libs $progs /tmp/install.hEJfJDhM > cp -R ${PATH_LOCALE:-"/usr/share/locale"} /tmp/install.hEJfJDhM/locale > echo "#mtree 2.0" > /tmp//METALOG > cd /usr/src; MAKEOBJDIRPREFIX=3D/usr/obj MACHINE_ARCH=3Damd64 > MACHINE=3Damd64 CPUTYPE=3D > GROFF_BIN_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/bin > GROFF_FONT_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/groff_font > GROFF_TMAC_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/tmac > PATH=3D/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/u= sr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bi= n:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/s= rc/tmp/usr/games:/tmp/install.hEJfJDhM > LD_LIBRARY_PATH=3D/tmp/install.hEJfJDhM > PATH_LOCALE=3D/tmp/install.hEJfJDhM/locale make -DWITH_ATF -f > Makefile.inc1 INSTALL=3D"install -N /usr/src/etc -U -M /tmp//METALOG -D > /tmp" MTREE_CMD=3D"mtree -N /usr/src/etc -W" > __MAKE_SHELL=3D/tmp/install.hEJfJDhM/sh -DNO_ROOT METALOG=3D/tmp//METALOG > reinstall; MAKEOBJDIRPREFIX=3D/usr/obj MACHINE_ARCH=3Damd64 MACHINE=3Dam= d64 > CPUTYPE=3D GROFF_BIN_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/bin > GROFF_FONT_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/groff_font > GROFF_TMAC_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/tmac > PATH=3D/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/u= sr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bi= n:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/s= rc/tmp/usr/games:/tmp/install.hEJfJDhM > LD_LIBRARY_PATH=3D/tmp/install.hEJfJDhM > PATH_LOCALE=3D/tmp/install.hEJfJDhM/locale rm -rf /tmp/install.hEJfJDhM > make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 37: Unable to > determine compiler type for cc. Consider setting COMPILER_TYPE. You need to build world before you can install it. -- Brooks --eheScQNz3K90DVRs Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlP7kDwACgkQXY6L6fI4GtQXUgCggMW+4lSQJbDaCXY6zebtl6I4 PtcAoL8C03ghZhQZUBY4MD1zFT1lzQkG =u702 -----END PGP SIGNATURE----- --eheScQNz3K90DVRs-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 25 19:39:44 2014 Return-Path: Delivered-To: freebsd-current@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 64AA5704; Mon, 25 Aug 2014 19:39:44 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3BEE43365; Mon, 25 Aug 2014 19:39:44 +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 60314B986; Mon, 25 Aug 2014 15:39:42 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: RFC: Remove pty(4) Date: Mon, 25 Aug 2014 15:37:24 -0400 Message-ID: <1471750.VzNR6ldJSe@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: References: 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); Mon, 25 Aug 2014 15:39:42 -0400 (EDT) Cc: Davide Italiano , Ed Schouten X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 19:39:44 -0000 On Wednesday, August 20, 2014 11:00:14 AM Davide Italiano wrote: > One of my personal goals for 11 is to get rid of cloning mechanism > entirely, and pty(4) is one of the few in-kernel drivers still relying > on such mechanism. > It's not possible, at least to my understanding, converting pty(4) to > cdevpriv(9) as happened with other drivers. This is mainly because we > always need a pair of devices (/dev/ptyXX and /dev/ttyXX) and > userspace loops over ptyXX and after it successfully opens it tries to > open the other one with the same suffix. So, having a single device is > not really enough. > My option, instead, is that of removing pty(4), which is nothing more > than a compatibility driver, and move pmtx(4) code somewhere else. > The main drawback of the removal of this is that it makes impossible > to run FreeBSD <= 7 jails and SSH into them. I personally don't > consider this a huge issue, in light of the fact that FreeBSD-7 has > been EOL for a long time, but I would like to hear other people > comments. > > The code review for the proposed change can be found here: > https://reviews.freebsd.org/D659 > > If I won't get any objection I'll commit this in one week time, i.e. > August 27th. Why not just statically create the pairs in /dev? Use some loader tunable (kern.ptymax) to set a count on the number of pre-created device pairs to create and then just explicitly create them in the mod_event handler? It could default to 100 or so. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Aug 25 20:18:22 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6435DBD7 for ; Mon, 25 Aug 2014 20:18:22 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3674737CD for ; Mon, 25 Aug 2014 20:18:22 +0000 (UTC) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.5/8.14.5) with ESMTP id s7PKJM3T014885 for ; Mon, 25 Aug 2014 13:19:28 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimatedns.net (8.14.5/8.14.5/Submit) id s7PKJH7C014884; Mon, 25 Aug 2014 13:19:17 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Mon, 25 Aug 2014 13:19:17 -0700 (PDT) Message-ID: <5ea87439fdbc8f6ddf6cdc411b74a03b.authenticated@ultimatedns.net> Date: Mon, 25 Aug 2014 13:19:17 -0700 (PDT) Subject: Is LOR a new feature in 11-CURRENT? From: "Chris H" To: "freebsd current" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 20:18:22 -0000 Greetings, all. I'm testing 11 current, and booting && installing from the 2014-08-11-r269824-disc1.iso returns the following, via dmesg(8): kernel: lock order reversal: kernel: 1st 0xfffff80002fa37c8 isofs (isofs) @ /usr/src/sys/kern/vfs_mount.c:1219 kernel: 2nd 0xfffff80002fe7240 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1375 Further info: kernel: FreeBSD 11.0-CURRENT #0 r269824: Mon Aug 11 20:18:52 UTC 2014 kernel: root@grind.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 kernel: FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 kernel: WARNING: WITNESS option enabled, expect reduced performance. Operation of FreeBSD will feel as tho it's running off of a 5/14 floppy disk! kernel: CPU: AMD Athlon(tm) ... Of course, an svn checkout of src && ports followed by a make && install of world && kernel reconciled the matter. I thought it worth mentioning. All the best. --Chris From owner-freebsd-current@FreeBSD.ORG Mon Aug 25 20:57:40 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4819CF2D; Mon, 25 Aug 2014 20:57:40 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0C2BB3B6E; Mon, 25 Aug 2014 20:57:39 +0000 (UTC) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.5/8.14.5) with ESMTP id s7PKwe1F018958; Mon, 25 Aug 2014 13:58:46 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimatedns.net (8.14.5/8.14.5/Submit) id s7PKwZ0V018957; Mon, 25 Aug 2014 13:58:35 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Mon, 25 Aug 2014 13:58:35 -0700 (PDT) Message-ID: Date: Mon, 25 Aug 2014 13:58:35 -0700 (PDT) Subject: How to get a mouse in vt(4) -- NEWCONS From: "Chris H" To: "freebsd current" , "freebsd hackers" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 20:57:40 -0000 Greetings, I'm testing 11-CURRENT, and have build/installed a kernel, and world. The KERNCONF includes both sc, and vt. As I understand it. If both are included, I get sc, not vt. But all previous kerns I've built that had sc, provided a mouse upon boot. However, in 11, I don't get one. What must be done? I'd like to try vt(4), and I've read the man page for it, and have added: kern.vty="vt" in /boot/loader.conf having done so, does NOT enable mouse support, and turns OFF cursor="blink" which is defined in rc.conf(5). I also read that hw.vga.textmode is available. However sysctl hw.vga.textmode returns unknown oid. I would choose graphics (0) if it was available. But appears not. Thank you for all your time, and consideration. --Chris From owner-freebsd-current@FreeBSD.ORG Mon Aug 25 21:08:42 2014 Return-Path: Delivered-To: freebsd-current@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 E48B0491 for ; Mon, 25 Aug 2014 21:08:42 +0000 (UTC) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::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 B56903C69 for ; Mon, 25 Aug 2014 21:08:42 +0000 (UTC) Received: by mail-ig0-f173.google.com with SMTP id h18so3490144igc.0 for ; Mon, 25 Aug 2014 14:08:42 -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=iS9XsjvSPTf4FtIGfWCYCcywKgMueY49X1DW6nkBOv8=; b=RwCDb2kB/zEKJm18wsg19uZbn0XGyGL/DaWxdBWyWHDUuIJRHhn+ws68LlcopLc6kR Hgl+2zT2grzD5wf3G5aDgrdDWGFv0mxjCG7PF5tBRTt5A9LjTXNZ1GSKkC3ti9+iufVe qHN1gMqYUhL/ZM4goQkEmht62fgYx1YaxEZwSkGvHMnlv766tEno/9+HOS2ZEEFhsye8 GKBnLSk2YbQXPMlxvg0B6xfmZM0qdZaml7J0LMuXyYRYYkZVPjAlVDCdTvnwqWP3Wvs+ XOzAL1ZbYFFcUcjv4EmqcfIpQsYnieVNQ22W7wJy5UafDXpBqunhRyv/JIc2MANXIcMU yTzg== MIME-Version: 1.0 X-Received: by 10.42.84.9 with SMTP id j9mr4333085icl.60.1409000922130; Mon, 25 Aug 2014 14:08:42 -0700 (PDT) Received: by 10.50.72.69 with HTTP; Mon, 25 Aug 2014 14:08:42 -0700 (PDT) In-Reply-To: <5ea87439fdbc8f6ddf6cdc411b74a03b.authenticated@ultimatedns.net> References: <5ea87439fdbc8f6ddf6cdc411b74a03b.authenticated@ultimatedns.net> Date: Mon, 25 Aug 2014 14:08:42 -0700 Message-ID: Subject: Re: Is LOR a new feature in 11-CURRENT? From: Garrett Cooper To: Chris H Content-Type: text/plain; charset=UTF-8 Cc: freebsd current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 21:08:43 -0000 Hi Chris, On Mon, Aug 25, 2014 at 1:19 PM, Chris H wrote: > Greetings, all. > I'm testing 11 current, and booting && installing from the > 2014-08-11-r269824-disc1.iso > returns the following, via dmesg(8): > > kernel: lock order reversal: > kernel: 1st 0xfffff80002fa37c8 isofs (isofs) @ /usr/src/sys/kern/vfs_mount.c:1219 > kernel: 2nd 0xfffff80002fe7240 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1375 I'm pretty sure this is one of the "known LORs" (introduced around 8.x/9.x?), but I could be wrong. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Aug 25 21:19:24 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43220B13 for ; Mon, 25 Aug 2014 21:19:24 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 030F13D78 for ; Mon, 25 Aug 2014 21:19:23 +0000 (UTC) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.5/8.14.5) with ESMTP id s7PLKOPS021146; Mon, 25 Aug 2014 14:20:30 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimatedns.net (8.14.5/8.14.5/Submit) id s7PLKJUo021142; Mon, 25 Aug 2014 14:20:19 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Mon, 25 Aug 2014 14:20:19 -0700 (PDT) Message-ID: <9510e84321efb008d853bc3915b7d63e.authenticated@ultimatedns.net> In-Reply-To: References: <5ea87439fdbc8f6ddf6cdc411b74a03b.authenticated@ultimatedns.net> Date: Mon, 25 Aug 2014 14:20:19 -0700 (PDT) Subject: Re: Is LOR a new feature in 11-CURRENT? From: "Chris H" To: "Garrett Cooper" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 21:19:24 -0000 > Hi Chris, > > On Mon, Aug 25, 2014 at 1:19 PM, Chris H wrote: >> Greetings, all. >> I'm testing 11 current, and booting && installing from the >> 2014-08-11-r269824-disc1.iso >> returns the following, via dmesg(8): >> >> kernel: lock order reversal: >> kernel: 1st 0xfffff80002fa37c8 isofs (isofs) @ /usr/src/sys/kern/vfs_mount.c:1219 >> kernel: 2nd 0xfffff80002fe7240 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1375 > > I'm pretty sure this is one of the "known LORs" (introduced around > 8.x/9.x?), but I could be wrong. > Thanks! > -Garrett Ahh, I see. Well, it wasn't a show stopper, or anything. But thought it worth mentioning. Thanks for the reply, Garrett. --Chris > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Aug 25 22:28:57 2014 Return-Path: Delivered-To: freebsd-current@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 63CF0B6A; Mon, 25 Aug 2014 22:28:57 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3EEC33478; Mon, 25 Aug 2014 22:28:56 +0000 (UTC) Received: from julian-mbp3.pixel8networks.com (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s7PMSnfp087988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 25 Aug 2014 15:28:50 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <53FBB89B.2020501@freebsd.org> Date: Mon, 25 Aug 2014 15:28:43 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brooks Davis , Craig Rodrigues Subject: Re: "make installworld" commands used to generate manifest for makefs? References: <20140825165522.GC91673@spindle.one-eyed-alien.net> <20140825193629.GD91673@spindle.one-eyed-alien.net> In-Reply-To: <20140825193629.GD91673@spindle.one-eyed-alien.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 22:28:57 -0000 On 8/25/14, 12:36 PM, Brooks Davis wrote: > On Mon, Aug 25, 2014 at 10:38:12AM -0700, Craig Rodrigues wrote: >> On Mon, Aug 25, 2014 at 9:55 AM, Brooks Davis wrote: >>> On Sun, Aug 24, 2014 at 04:10:21PM -0700, Craig Rodrigues wrote: >>>> Hi, >>>> >>>> Is there an easy way to take most of the commands performed >>>> during "make installworld" and create a manifest file >>>> which is compatible with makefs? >>> make -DNO_ROOT -DDB_FROM_SRC DESTDIR= installworld if you haven't already this should be documented in the base makefiles along with the other -DXXXX values. >>> >>> should result in a /METALOG file suitable for passing to makefs. >>> You may also want the distribution target if you want a populated /etc. >>> >>> -- Broks >> Hi, >> >> I got this: >> >> >> # make -DNO_ROOT -DDB_FROM_SRC DESTDIR=/tmp installworld > you really don't want DESTDIR=/tmp, it will install a full OS in that > directory along with the METALOG file. > >> mkdir -p /tmp/install.hEJfJDhM >> progs=$(for prog in [ awk cap_mkdb cat chflags chmod chown date echo >> egrep find grep id install ln lockf make mkdir mtree mv pwd_mkdb rm >> sed services_mkdb sh sysctl test true uname wc zic tzsetup ; do if >> progpath=`which $prog`; then echo $progpath; else echo "Required >> tool $prog not found in PATH." >&2; exit 1; fi; done); libs=$(ldd >> -f "%o %p\n" -f "%o %p\n" $progs 2>/dev/null | sort -u | while read >> line; do set -- $line; if [ "$2 $3" != "not found" ]; then echo $2; >> else echo "Required library $1 not found." >&2; exit 1; fi; >> done); cp $libs $progs /tmp/install.hEJfJDhM >> cp -R ${PATH_LOCALE:-"/usr/share/locale"} /tmp/install.hEJfJDhM/locale >> echo "#mtree 2.0" > /tmp//METALOG >> cd /usr/src; 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 >> 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:/tmp/install.hEJfJDhM >> LD_LIBRARY_PATH=/tmp/install.hEJfJDhM >> PATH_LOCALE=/tmp/install.hEJfJDhM/locale make -DWITH_ATF -f >> Makefile.inc1 INSTALL="install -N /usr/src/etc -U -M /tmp//METALOG -D >> /tmp" MTREE_CMD="mtree -N /usr/src/etc -W" >> __MAKE_SHELL=/tmp/install.hEJfJDhM/sh -DNO_ROOT METALOG=/tmp//METALOG >> reinstall; 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 >> 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:/tmp/install.hEJfJDhM >> LD_LIBRARY_PATH=/tmp/install.hEJfJDhM >> PATH_LOCALE=/tmp/install.hEJfJDhM/locale rm -rf /tmp/install.hEJfJDhM >> make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 37: Unable to >> determine compiler type for cc. Consider setting COMPILER_TYPE. > You need to build world before you can install it. > > -- Brooks From owner-freebsd-current@FreeBSD.ORG Mon Aug 25 22:39:42 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9981D9; Mon, 25 Aug 2014 22:39:42 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8C733355E; Mon, 25 Aug 2014 22:39:42 +0000 (UTC) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.5/8.14.5) with ESMTP id s7PMehkB028109; Mon, 25 Aug 2014 15:40:49 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimatedns.net (8.14.5/8.14.5/Submit) id s7PMecxV028108; Mon, 25 Aug 2014 15:40:38 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Mon, 25 Aug 2014 15:40:38 -0700 (PDT) Message-ID: <0cab774cc83f724aef4cf6ad2ed78090.authenticated@ultimatedns.net> Date: Mon, 25 Aug 2014 15:40:38 -0700 (PDT) Subject: vt(4) -- vidcontrol: setting cursor type: Inappropriate ioctl for device From: "Chris H" To: "freebsd current" , "freebsd hackers" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 22:39:42 -0000 Greetings, On 11-CURRENT, and with vt(4) chosen. I receive the following at boot: vidcontrol: setting cursor type: Inappropriate ioctl for device I _believe_ this is caused by the entry in rc.conf(5) cursor="blink" This entry has always worked fine with sc(4), and as I read it, [should] in vt(4) as well. But the vt(4) man pages seem to be lagging. They discuss oid(s) that don't seem to exist, and I'm unable to determine _what_ I should be doing to get a similar terminal/console as I get w/sc(4). Are there any other docs, or links available to help me with this? Thank you for all your time, and consideration. --Chris P.S. I'm using an Nvidia 8400, w/512Mb ram onboard, as well as the Nvidia blob. If that makes any difference. Thanks again. From owner-freebsd-current@FreeBSD.ORG Mon Aug 25 22:41:16 2014 Return-Path: Delivered-To: freebsd-current@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 040622C9; Mon, 25 Aug 2014 22:41:16 +0000 (UTC) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) by mx1.freebsd.org (Postfix) with ESMTP id B486935F4; Mon, 25 Aug 2014 22:41:15 +0000 (UTC) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 5DFEB5A9F25; Mon, 25 Aug 2014 22:41:14 +0000 (UTC) Date: Mon, 25 Aug 2014 22:41:14 +0000 From: Brooks Davis To: Julian Elischer Subject: Re: "make installworld" commands used to generate manifest for makefs? Message-ID: <20140825224114.GE91673@spindle.one-eyed-alien.net> References: <20140825165522.GC91673@spindle.one-eyed-alien.net> <20140825193629.GD91673@spindle.one-eyed-alien.net> <53FBB89B.2020501@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tMbDGjvJuJijemkf" Content-Disposition: inline In-Reply-To: <53FBB89B.2020501@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Craig Rodrigues , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 22:41:16 -0000 --tMbDGjvJuJijemkf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 25, 2014 at 03:28:43PM -0700, Julian Elischer wrote: > On 8/25/14, 12:36 PM, Brooks Davis wrote: > > On Mon, Aug 25, 2014 at 10:38:12AM -0700, Craig Rodrigues wrote: > >> On Mon, Aug 25, 2014 at 9:55 AM, Brooks Davis wro= te: > >>> On Sun, Aug 24, 2014 at 04:10:21PM -0700, Craig Rodrigues wrote: > >>>> Hi, > >>>> > >>>> Is there an easy way to take most of the commands performed > >>>> during "make installworld" and create a manifest file > >>>> which is compatible with makefs? > >>> make -DNO_ROOT -DDB_FROM_SRC DESTDIR=3D installworld >=20 > if you haven't already this should be documented in the base makefiles=20 > along with the other -DXXXX > values. It was documented in the initial commit. -- Brooks > >>> > >>> should result in a /METALOG file suitable for passing to makefs. > >>> You may also want the distribution target if you want a populated /et= c. > >>> > >>> -- Broks > >> Hi, > >> > >> I got this: > >> > >> > >> # make -DNO_ROOT -DDB_FROM_SRC DESTDIR=3D/tmp installworld > > you really don't want DESTDIR=3D/tmp, it will install a full OS in that > > directory along with the METALOG file. > > > >> mkdir -p /tmp/install.hEJfJDhM > >> progs=3D$(for prog in [ awk cap_mkdb cat chflags chmod chown date echo > >> egrep find grep id install ln lockf make mkdir mtree mv pwd_mkdb rm > >> sed services_mkdb sh sysctl test true uname wc zic tzsetup ; do if > >> progpath=3D`which $prog`; then echo $progpath; else echo "Required > >> tool $prog not found in PATH." >&2; exit 1; fi; done); libs=3D$(ldd > >> -f "%o %p\n" -f "%o %p\n" $progs 2>/dev/null | sort -u | while read > >> line; do set -- $line; if [ "$2 $3" !=3D "not found" ]; then echo $= 2; > >> else echo "Required library $1 not found." >&2; exit 1; fi; > >> done); cp $libs $progs /tmp/install.hEJfJDhM > >> cp -R ${PATH_LOCALE:-"/usr/share/locale"} /tmp/install.hEJfJDhM/locale > >> echo "#mtree 2.0" > /tmp//METALOG > >> cd /usr/src; MAKEOBJDIRPREFIX=3D/usr/obj MACHINE_ARCH=3Damd64 > >> MACHINE=3Damd64 CPUTYPE=3D > >> GROFF_BIN_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/bin > >> GROFF_FONT_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/groff_font > >> GROFF_TMAC_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/tmac > >> PATH=3D/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legac= y/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/us= r/src/tmp/usr/games:/tmp/install.hEJfJDhM > >> LD_LIBRARY_PATH=3D/tmp/install.hEJfJDhM > >> PATH_LOCALE=3D/tmp/install.hEJfJDhM/locale make -DWITH_ATF -f > >> Makefile.inc1 INSTALL=3D"install -N /usr/src/etc -U -M /tmp//METALOG = -D > >> /tmp" MTREE_CMD=3D"mtree -N /usr/src/etc -W" > >> __MAKE_SHELL=3D/tmp/install.hEJfJDhM/sh -DNO_ROOT METALOG=3D/tmp//META= LOG > >> reinstall; MAKEOBJDIRPREFIX=3D/usr/obj MACHINE_ARCH=3Damd64 MACHINE= =3Damd64 > >> CPUTYPE=3D GROFF_BIN_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/bin > >> GROFF_FONT_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/groff_font > >> GROFF_TMAC_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/tmac > >> PATH=3D/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legac= y/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/us= r/src/tmp/usr/games:/tmp/install.hEJfJDhM > >> LD_LIBRARY_PATH=3D/tmp/install.hEJfJDhM > >> PATH_LOCALE=3D/tmp/install.hEJfJDhM/locale rm -rf /tmp/install.hEJfJDhM > >> make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 37: Unable to > >> determine compiler type for cc. Consider setting COMPILER_TYPE. > > You need to build world before you can install it. > > > > -- Brooks >=20 --tMbDGjvJuJijemkf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlP7u4kACgkQXY6L6fI4GtQoMQCgz1A/aIC8BW1/St4ZbPpNpZFK 5SYAn0LJjZZuXo43YsbGZhgKG/H6Gqfq =j+Al -----END PGP SIGNATURE----- --tMbDGjvJuJijemkf-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 25 23:26:08 2014 Return-Path: Delivered-To: freebsd-current@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 B06D3DBC; Mon, 25 Aug 2014 23:26:08 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5E9C439B0; Mon, 25 Aug 2014 23:26:08 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id s7PNPr1C084263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 25 Aug 2014 17:25:53 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id s7PNPraA084260; Mon, 25 Aug 2014 17:25:53 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Mon, 25 Aug 2014 17:25:53 -0600 (MDT) From: Warren Block To: Chris H Subject: Re: How to get a mouse in vt(4) -- NEWCONS In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Mon, 25 Aug 2014 17:25:53 -0600 (MDT) Cc: freebsd hackers , freebsd current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 23:26:08 -0000 On Mon, 25 Aug 2014, Chris H wrote: > I also read that hw.vga.textmode is available. However sysctl > hw.vga.textmode returns unknown oid. It is a boot-time-only setting for loader.conf. hw.vga.textmode=1 boots in text mode. From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 00:53:42 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF016ADA; Tue, 26 Aug 2014 00:53:42 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BD56C3099; Tue, 26 Aug 2014 00:53:42 +0000 (UTC) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.5/8.14.5) with ESMTP id s7Q0saIR040032; Mon, 25 Aug 2014 17:54:42 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimatedns.net (8.14.5/8.14.5/Submit) id s7Q0sVsL040015; Mon, 25 Aug 2014 17:54:31 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Mon, 25 Aug 2014 17:54:31 -0700 (PDT) Message-ID: In-Reply-To: References: Date: Mon, 25 Aug 2014 17:54:31 -0700 (PDT) Subject: Re: How to get a mouse in vt(4) -- NEWCONS From: "Chris H" To: "Warren Block" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd hackers , freebsd current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 00:53:43 -0000 > On Mon, 25 Aug 2014, Chris H wrote: > >> I also read that hw.vga.textmode is available. However sysctl >> hw.vga.textmode returns unknown oid. > > It is a boot-time-only setting for loader.conf. > > hw.vga.textmode=1 > > boots in text mode. Ahh, I see. Thank you very much, Warren, for the reply. :) --Chris > From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 03:07:39 2014 Return-Path: Delivered-To: freebsd-current@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 6ED4FB68 for ; Tue, 26 Aug 2014 03:07:39 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 414593C17 for ; Tue, 26 Aug 2014 03:07:39 +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 0A0A1B93B; Mon, 25 Aug 2014 23:07:38 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: ktrace -c behavior Date: Mon, 25 Aug 2014 16:23:27 -0400 Message-ID: <9285902.gXIcESz31I@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: <53FB386C.9030800@vangyzen.net> References: <53F79710.6090700@vangyzen.net> <20140824235336.GR71691@funkthat.com> <53FB386C.9030800@vangyzen.net> 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); Mon, 25 Aug 2014 23:07:38 -0400 (EDT) Cc: Eric van Gyzen X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 03:07:39 -0000 On Monday, August 25, 2014 09:21:48 AM Eric van Gyzen wrote: > On 08/24/2014 19:53, John-Mark Gurney wrote: > > Eric van Gyzen wrote this message on Fri, Aug 22, 2014 at 15:26 -0400: > >> On 08/22/2014 15:20, John-Mark Gurney wrote: > >>> Eric van Gyzen wrote this message on Fri, Aug 22, 2014 at 15:16 -0400: > >>>> What behavior would you expect from this sequence of commands? > >>>> > >>>> ktrace -tw -p 1234 > >>>> ktrace -c -p 1234 > >>>> > >>>> Based on this... > >>>> > >>>> -c Clear the trace points associated with the specified file > >>>> > >>>> or processes. > >>> > >>> and/or just add specified: > >>> Clear the specified trace points ... > >> > >> But what if I didn't specify them? > > > > You specified the default by not specificly specifing any different > > ones.. :) Confused? :) > > Amused. :) Adding "specified" is the first thing that came to my mind as well. > > or maybe selected? > > Perhaps, but I didn't select them, either. My original suggestion is > more--dare I use this word again--specific. It explains exactly how the > command behaves. But then do we need to annotate every place that uses "trace points" to add this language? Note that the 'command' description uses the language John- mark suggested: command Execute command with the specified trace flags. My vote would be to add "specified" to the description of "-c", but to improve the the description of "-t" itself from: -t trstr The string argument represents the kernel trace points, one per letter. The following table equates the letters with the trace- points: to: -t trstr Specify the list of trace points to enable or disable, one per letter. If an explicit list is not specified, the default set of trace points is used. The following trace points are supported: -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 03:07:40 2014 Return-Path: Delivered-To: current@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 282E0B69 for ; Tue, 26 Aug 2014 03:07:40 +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 DDBF43C18 for ; Tue, 26 Aug 2014 03:07:39 +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 C49F1B986; Mon, 25 Aug 2014 23:07:38 -0400 (EDT) From: John Baldwin To: Poul-Henning Kamp Subject: Re: gbde destroy doesn't match man page? Date: Mon, 25 Aug 2014 16:10:50 -0400 Message-ID: <2945485.ZemF81RAkB@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: <23149.1408789002@critter.freebsd.dk> References: <20140820215522.GA92455@bewilderbeast.blackhelicopters.org> <23149.1408789002@critter.freebsd.dk> 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); Mon, 25 Aug 2014 23:07:38 -0400 (EDT) Cc: current@freebsd.org, "Michael W. Lucas" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 03:07:40 -0000 On Saturday, August 23, 2014 10:16:42 AM Poul-Henning Kamp wrote: > -------- > In message <20140820215522.GA92455@bewilderbeast.blackhelicopters.org>, > "Michae > l W. Lucas" writes: > >Playing with GBDE for my FreeBSD disk book, on: > > > ># uname -a > >FreeBSD storm 11.0-CURRENT FreeBSD 11.0-CURRENT #6 r269010: Wed Jul 23 > >11:13:17 EDT 2014 mwlucas@storm:/usr/obj/usr/src/sys/GENERIC amd64 > > > >According to the man page, I should be able to destroy all copies of > >the key with gbde destroy -n -1. It's in the examples. When I > > >try it I get: > I think that is an oversight in the code. Can you expand on this? I.e. what should the code do if it is fixed? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 03:07:41 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 528E9CF9; Tue, 26 Aug 2014 03:07:41 +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 1DED43C19; Tue, 26 Aug 2014 03:07:41 +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 E9496B987; Mon, 25 Aug 2014 23:07:39 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: [PATCH] Packet loss when 'control' messages are present with large data (sendmsg(2)) Date: Mon, 25 Aug 2014 15:52:29 -0400 Message-ID: <2204059.7tqSNWvxzC@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: <53F72AC4.7040108@omnilan.de> References: <522300E3.6050303@rawbw.com> <522419F4.5010605@rawbw.com> <53F72AC4.7040108@omnilan.de> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 25 Aug 2014 23:07:40 -0400 (EDT) Cc: Harald Schmalzbauer , net@freebsd.org, current@freebsd.org, asomers@freebsd.org, Yuri X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 03:07:41 -0000 On Friday, August 22, 2014 01:34:28 PM Harald Schmalzbauer wrote: > Bez=FCglich Yuri's Nachricht vom 02.09.2013 06:54 (localtime): > > Please check in this patch: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D181741 > > Please MFC into 9.X > >=20 > > Description of the problem is within PR. > >=20 > > Thanks, > > Yuri >=20 > Hello, >=20 > I guess this fix should make it into 10.1. > Can someone check please? A fix has to make into HEAD first. I've cc'd Alan who responded to the= bug. =20 Alan, note that glebius@ already committed the test case to HEAD a whil= e ago. --=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 03:24:48 2014 Return-Path: Delivered-To: freebsd-current@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 C9B9E85D; Tue, 26 Aug 2014 03:24:48 +0000 (UTC) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C31E3E7E; Tue, 26 Aug 2014 03:24:48 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id rl12so10947535iec.38 for ; Mon, 25 Aug 2014 20:24:48 -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=HcWYHBe7l8Th+z2gkMe7ZUMyAMcpfgaEDLFjW8NKC3U=; b=ojRIw8LoMHPp+kKmgPd0fbw7vHAzp9acSbSmBSTbkFVDRBMOwbePikw9aOTOpV/EbI LPfTVLX2pJngA4Knp6ghCI7ubvaRPcUKXtcRff40tpHoVkSvJVvPHuCeTeeeLcPhAg5T nVJ1v6zdiw5bbcnQCXQD9zr6D4WodHHmPoitCmLhITvBOCYAkLaaVagp1Jxcp/u51Vsq bptuW9zqSnQ9+hLIISlSUZyvErJZnPzjHmjJav21eYWScggsaMr9uRcWikXA0qoTr1yL Wb0fGvMWjT1XqDiDDZKXhTarVkaZOf4zG8wRDpjhTAa+GEMqW2Lp5M7A1Vpjt+dApE7u 6/uw== MIME-Version: 1.0 X-Received: by 10.43.149.200 with SMTP id kl8mr9730726icc.52.1409023487580; Mon, 25 Aug 2014 20:24:47 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.163.148 with HTTP; Mon, 25 Aug 2014 20:24:47 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Aug 2014 20:24:47 -0700 X-Google-Sender-Auth: jXoUn-Rtj787sMLPu6cw29ecYFs Message-ID: Subject: Re: How to get a mouse in vt(4) -- NEWCONS From: Kevin Oberman To: Chris H Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Warren Block , freebsd hackers , freebsd current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 03:24:49 -0000 On Mon, Aug 25, 2014 at 5:54 PM, Chris H wrote: > > On Mon, 25 Aug 2014, Chris H wrote: > > > >> I also read that hw.vga.textmode is available. However sysctl > >> hw.vga.textmode returns unknown oid. > > > > It is a boot-time-only setting for loader.conf. > > > > hw.vga.textmode=1 > > > > boots in text mode. > Ahh, I see. Thank you very much, Warren, for the reply. :) > > --Chris > > But the mouse should work fine with vt(4). It does for me. You do need to run moused, though that was the case with cs(4), as well. The lack of "blink" support was just noted in the last post to this list, so we can hope to hear a bit about the status of blink soon. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 04:49:24 2014 Return-Path: Delivered-To: freebsd-current@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 95A6E7B7; Tue, 26 Aug 2014 04:49:24 +0000 (UTC) Received: from kefka.worrbase.com (unknown [IPv6:2620:8d:8000:e49:f435:9b0c:255b:e411]) (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 32A01351F; Tue, 26 Aug 2014 04:49:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]); by kefka.worrbase.com (OpenSMTPD) with ESMTP id 49d76b64; Mon, 25 Aug 2014 21:49:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=worrbase.com; h= content-transfer-encoding:content-type:content-type:in-reply-to :references:subject:subject:mime-version:user-agent:from:from :date:date:message-id:received:received; s=mail; t=1409028554; x=1410842955; bh=/4W5Ebf31tZy/x8OfApTYkgfriBM6WqCM5qVlHBY/FI=; b= BV6IvN1r35VEwDGfYneIu1anDYgUkpPEsFNSGqrKUz7lyfSmT3PE1FxbgWUv6s57 Ns1u0F3z0ispGvWlEBMY9TN4cn7SsJvOuw7uAmEsDYp6o6xAORbupQTfoHCan9Nd N3aYxyvFTxyU+YsVh52ESUmaEkQgZh2cC4Qqg/ycA4jij6K783nTnHgt3rO9Z0OA KjyTGf0kLkDmaqBthKefLfF9PNbUkY6yLUYJyNYqT1Qn1TWAH+NIsVDbwZB1rjL1 1nw8zrt3D4mTkl2LSw59sc0OwGukFiPVkoidLCb83aer++HIDyfYvElHxoygszaE bH8f3nt+OJDFNBkROm+QNqWmZw9OQZjix75viiQdHRVJX4KGGuTRcJeEIjBUhOWR BJZ7zjCNO1lCsCxBxp4MpwmE/OWy7+aYN13SeyNGfEo7BUPQT+0/+XqGJOlnKfmR cVac70V9Em5i9c2oou+IwrvKCAV/cpCJz+/7VtnbR23Kup3BNqUqTdb6izYpOHLL OHC46lPtAq7Ier7e82xjLXSBQmzptwVraMiMnjM3RNuodAYi3qnZXhts4mviSteS ptdXUJwkwSae6qrwAdfSSvTPVTIdSk0SdI/Xc+pESpOiT4OZVP4LLVlAcmyY70ib pNZ593RJrT2w+fC7KMIyqxnfgZWEVEI727RiDXKWhtM= X-Virus-Scanned: amavisd-new at worrbase.com Received: from kefka.worrbase.com ([IPv6:::1]) by localhost (kefka.worrbase.com [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id drtLKmETIofO; Mon, 25 Aug 2014 21:49:14 -0700 (PDT) Received: from [10.0.1.3] (c-50-161-97-206.hsd1.ca.comcast.net [50.161.97.206]); by kefka.worrbase.com (OpenSMTPD) with ESMTPSA id 1e53ee64; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO; Mon, 25 Aug 2014 21:49:14 -0700 (PDT) Message-ID: <53FC11C8.5050803@worrbase.com> Date: Mon, 25 Aug 2014 21:49:12 -0700 From: William Orr User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Alan Somers , FreeBSD CURRENT Subject: Re: Inconsistent behavior with dd(1) References: <3C86F281-D618-4B93-BBA3-2DA33AC407EC@worrbase.com> <20140816173439.GZ83475@funkthat.com> <53F24D60.4080107@worrbase.com> In-Reply-To: <53F24D60.4080107@worrbase.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 04:49:24 -0000 On 8/18/14 12:00 PM, William Orr wrote: > Reply inline. > > On 08/16/2014 10:34 AM, John-Mark Gurney wrote: >> Alan Somers wrote this message on Fri, Aug 15, 2014 at 10:42 -0600: >>> On Thu, Aug 14, 2014 at 11:55 PM, William Orr wrote: >>>> Hey, >>>> >>>> I found some inconsistent behavior with dd(1) when it comes to specifying arguments in -CURRENT. >>>> >>>> [ worr on terra ] ( ~ ) % dd if=/dev/zero of=/dev/null count=18446744073709551616 >>>> dd: count: Result too large >>>> [ worr on terra ] ( ~ ) % dd if=/dev/zero of=/dev/null count=18446744073709551617 >>>> dd: count: Result too large >>>> [ worr on terra ] ( ~ ) % dd if=/dev/zero of=/dev/null count=18446744073709551615 >>>> dd: count cannot be negative >>>> [ worr on terra ] ( ~ ) % dd if=/dev/zero of=/dev/null count=-18446744073709551615 >>>> 1+0 records in >>>> 1+0 records out >>>> 512 bytes transferred in 0.000373 secs (1373071 bytes/sec) >>>> [ worr on terra ] ( ~ ) % dd if=/dev/zero of=/dev/null count=-1 >>>> dd: count cannot be negative >>>> >>>> ??? >>>> >>>> Any chance someone has the time and could take a look? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191263 >>>> >>>> Thanks, >>>> William Orr >>>> >>>> ??? >>> >>> IMHO, this is a bug in strtouq(3), not in dd(1). Why should it parse >>> negative numbers at all, when there is stroq(3) for that purpose? The >>> standard is clear that it must, though. Oddly enough, stroq would >>> probably not accept -18446744073709551615, even though strtouq does. >>> Specific comments on your patch below: >>> >>> >>>> Here???s the patch: >>>> >>>> Index: bin/dd/args.c >>>> =================================================================== >>>> --- bin/dd/args.c (revision 267712) >>>> +++ bin/dd/args.c (working copy) >>>> @@ -186,46 +186,31 @@ >>>> static void >>>> f_bs(char *arg) >>>> { >>>> - uintmax_t res; >>>> - >>>> - res = get_num(arg); >>>> - if (res < 1 || res > SSIZE_MAX) >>>> - errx(1, "bs must be between 1 and %jd", (intmax_t)SSIZE_MAX); >>>> - in.dbsz = out.dbsz = (size_t)res; >>>> + in.dbsz = out.dbsz = get_num(arg); >>>> + if (in.dbsz < 1 || out.dbsz < 1) >>> Why do you need to check both in and out? Aren't they the same? >>> Also, you eliminated the check for overflowing SSIZE_MAX. That's not >>> ok, because these values get passed to places that expect signed >>> numbers, for example in dd.c:303. >> The type of dbsz is size_t, so really: >> >>>> + errx(1, "bs must be between 1 and %ju", (uintmax_t)-1); >> This should be SIZE_MAX, except there isn't a define for this? So maybe >> the code really should be: >> (uintmax_t)(size_t)-1 >> >> to get the correct value for SIZE_MAX... >> >> Otherwise on systems that uintmax_t is >32bits and size_t is 32bits, >> the error message will be wrong... > Yes, this should probably be SIZE_MAX rather than that cast. Same with > the others > >>>> } >>>> >>>> static void >>>> f_cbs(char *arg) >>>> { >>>> - uintmax_t res; >>>> - >>>> - res = get_num(arg); >>>> - if (res < 1 || res > SSIZE_MAX) >>>> - errx(1, "cbs must be between 1 and %jd", (intmax_t)SSIZE_MAX); >>>> - cbsz = (size_t)res; >>>> + cbsz = get_num(arg); >>>> + if (cbsz < 1) >>>> + errx(1, "cbs must be between 1 and %ju", (uintmax_t)-1); >>>> } >>> Again, you eliminated the check for SSIZE_MAX, but cbsz must be signed. >> What do you mean by this? cbsz is size_t which is unsigned... > I believe he's referring to this use of cbsz/in.dbsz/out.dbsz: > > https://svnweb.freebsd.org/base/head/bin/dd/dd.c?revision=265698&view=markup#l171 > > Really, this is more wrong since there is math inside of a malloc(3) > call without any overflow handling. By virtue of making this max out at > a ssize_t, it becomes more unlikely that you'll have overflow. > > This math should probably be done ahead of time with proper overflow > handling. I'll include that in my next patch, if there's no objection. > > I don't see any other reason why in.dbsz, out.dbsz or cbsz should be > signed, but it's very possible that I didn't look hard enough. > >> Again, the cast above is wrong... Maybe we should add a SIZE_MAX >> define so we don't have to see the double cast... >> >>>> static void >>>> f_count(char *arg) >>>> { >>>> - intmax_t res; >>>> - >>>> - res = (intmax_t)get_num(arg); >>>> - if (res < 0) >>>> - errx(1, "count cannot be negative"); >>>> - if (res == 0) >>>> - cpy_cnt = (uintmax_t)-1; >>> This is a special case. See dd_in(). I think that eliminating this >>> special case will have the unintended effect of breaking count=0. >>> >>>> - else >>>> - cpy_cnt = (uintmax_t)res; >>>> + cpy_cnt = get_num(arg); >>>> } >>>> >>>> static void >>>> f_files(char *arg) >>>> { >>>> - >> Don't eliminate these blank lines.. they are intentional per style(9): >> /* Insert an empty line if the function has no local variables. */ >> >>>> files_cnt = get_num(arg); >>>> if (files_cnt < 1) >>>> - errx(1, "files must be between 1 and %jd", (uintmax_t)-1); >>>> + errx(1, "files must be between 1 and %ju", (uintmax_t)-1); >>> Good catch. >>> >>>> } >>>> >>>> static void >>>> @@ -241,14 +226,10 @@ >>>> static void >>>> f_ibs(char *arg) >>>> { >>>> - uintmax_t res; >>>> - >>>> if (!(ddflags & C_BS)) { >>>> - res = get_num(arg); >>>> - if (res < 1 || res > SSIZE_MAX) >>>> - errx(1, "ibs must be between 1 and %jd", >>>> - (intmax_t)SSIZE_MAX); >>>> - in.dbsz = (size_t)res; >>>> + in.dbsz = get_num(arg); >>>> + if (in.dbsz < 1) >>>> + errx(1, "ibs must be between 1 and %ju", (uintmax_t)-1); >>> Again, you eliminated the check for SSIZE_MAX, but dbsz must be signed. >> If dbsz must be signed, we should change it's definition to ssize_t >> instead of size_t... Can you point to the line that says this? >> >> In investigating this, it looks like we may have a bug in ftruncate in >> that out.offset * out.dbsz may overflow and return incorrect results... >> We should probably check that the output (cast to off_t) is greater than >> both the inputs before calling ftruncate... This is safe as both are >> unsigned... > Yeah, there probably ought to be integer overflow handling here as well. > >>>> } >>>> } >>>> >>>> @@ -262,14 +243,10 @@ >>>> static void >>>> f_obs(char *arg) >>>> { >>>> - uintmax_t res; >>>> - >>>> if (!(ddflags & C_BS)) { >>>> - res = get_num(arg); >>>> - if (res < 1 || res > SSIZE_MAX) >>>> - errx(1, "obs must be between 1 and %jd", >>>> - (intmax_t)SSIZE_MAX); >>>> - out.dbsz = (size_t)res; >>>> + out.dbsz = get_num(arg); >>>> + if (out.dbsz < 1) >>>> + errx(1, "obs must be between 1 and %ju", (uintmax_t)-1); >>>> } >>>> } >>> Again, you eliminated the check for SSIZE_MAX, but dbsz must be signed. >>> >>>> @@ -378,11 +355,14 @@ >>>> uintmax_t num, mult, prevnum; >>>> char *expr; >>>> >>>> + if (val[0] == '-') >>>> + errx(1, "%s: cannot be negative", oper); >>>> + >>> In general, I like this part of the diff. Every user of get_num >>> checks for negative values, so why not move the check into get_num >>> itself? But you changed it from a numeric check to a text check, and >>> writing text parsers makes me nervous. I can't see any problems, >>> though. > Funnily enough this part of the diff was wrong. I didn't account for > spaces, so I'll add that in my upcoming diff. > >>>> errno = 0; >>>> num = strtouq(val, &expr, 0); >>>> if (errno != 0) /* Overflow or underflow. */ >>>> err(1, "%s", oper); >>>> - >>>> + >>>> if (expr == val) /* No valid digits. */ >>>> errx(1, "%s: illegal numeric value", oper); >>>> >>>> Index: bin/dd/dd.c >>>> =================================================================== >>>> --- bin/dd/dd.c (revision 267712) >>>> +++ bin/dd/dd.c (working copy) >>>> @@ -284,8 +284,6 @@ >>>> >>>> for (;;) { >>>> switch (cpy_cnt) { >>>> - case -1: /* count=0 was specified */ >>>> - return; >>> Again, I don't think this will do what you want it to do. Previously, >>> leaving count unspecified resulted in cpy_cnt being 0, and specifying >>> count=0 set cpy_cnt to -1. With your patch, setting count=0 will have >>> the same effect as leaving it unspecified. > Nope. It didn't do what I wanted. I'll submit an updated diff with this > fixed as well as the other things I mentioned, provided there's no > objection to my direction. > >>>> case 0: >>>> break; >>>> default: >>>> >>>> Here is a new version of this patch. I've now changed the members of the struct that are used as ssize_ts to ssize_ts, and have fixed casts appropriately. I have also opted for strtoull over the deprecated strtouq. I changed some struct members that were declared as uintmax_t's to size_t's. Any comments? Criticisms? Gross attacks on my character? Index: args.c =================================================================== --- args.c (revision 270645) +++ args.c (working copy) @@ -41,6 +41,7 @@ #include +#include #include #include #include @@ -171,8 +172,7 @@ */ if (in.offset > OFF_MAX / (ssize_t)in.dbsz || out.offset > OFF_MAX / (ssize_t)out.dbsz) - errx(1, "seek offsets cannot be larger than %jd", - (intmax_t)OFF_MAX); + errx(1, "seek offsets cannot be larger than %jd", OFF_MAX); } static int @@ -186,37 +186,28 @@ static void f_bs(char *arg) { - uintmax_t res; - res = get_num(arg); - if (res < 1 || res > SSIZE_MAX) - errx(1, "bs must be between 1 and %jd", (intmax_t)SSIZE_MAX); - in.dbsz = out.dbsz = (size_t)res; + in.dbsz = out.dbsz = get_num(arg); + if (out.dbsz < 1 || out.dbsz > SSIZE_MAX) + errx(1, "bs must be between 1 and %jd", SSIZE_MAX); } static void f_cbs(char *arg) { - uintmax_t res; - res = get_num(arg); - if (res < 1 || res > SSIZE_MAX) - errx(1, "cbs must be between 1 and %jd", (intmax_t)SSIZE_MAX); - cbsz = (size_t)res; + cbsz = get_num(arg); + if (cbsz < 1 || cbsz > SSIZE_MAX) + errx(1, "cbs must be between 1 and %jd", SSIZE_MAX); } static void f_count(char *arg) { - intmax_t res; - res = (intmax_t)get_num(arg); - if (res < 0) - errx(1, "count cannot be negative"); - if (res == 0) - cpy_cnt = (uintmax_t)-1; - else - cpy_cnt = (uintmax_t)res; + cpy_cnt = get_num(arg); + if (cpy_cnt == 0) + cpy_cnt = -1; } static void @@ -225,7 +216,7 @@ files_cnt = get_num(arg); if (files_cnt < 1) - errx(1, "files must be between 1 and %jd", (uintmax_t)-1); + errx(1, "files must be between 1 and %ju", SIZE_MAX); } static void @@ -241,14 +232,11 @@ static void f_ibs(char *arg) { - uintmax_t res; if (!(ddflags & C_BS)) { - res = get_num(arg); - if (res < 1 || res > SSIZE_MAX) - errx(1, "ibs must be between 1 and %jd", - (intmax_t)SSIZE_MAX); - in.dbsz = (size_t)res; + in.dbsz = get_num(arg); + if (in.dbsz < 1 || in.dbsz > SSIZE_MAX) + errx(1, "ibs must be between 1 and %ju", SSIZE_MAX); } } @@ -262,14 +250,11 @@ static void f_obs(char *arg) { - uintmax_t res; if (!(ddflags & C_BS)) { - res = get_num(arg); - if (res < 1 || res > SSIZE_MAX) - errx(1, "obs must be between 1 and %jd", - (intmax_t)SSIZE_MAX); - out.dbsz = (size_t)res; + out.dbsz = get_num(arg); + if (out.dbsz < 1 || out.dbsz > SSIZE_MAX) + errx(1, "obs must be between 1 and %jd", SSIZE_MAX); } } @@ -378,11 +363,17 @@ uintmax_t num, mult, prevnum; char *expr; + while (isspace(val[0])) + val++; + + if (val[0] == '-') + errx(1, "%s: cannot be negative", oper); + errno = 0; - num = strtouq(val, &expr, 0); + num = strtoull(val, &expr, 0); if (errno != 0) /* Overflow or underflow. */ err(1, "%s", oper); - + if (expr == val) /* No valid digits. */ errx(1, "%s: illegal numeric value", oper); Index: conv.c =================================================================== --- conv.c (revision 270645) +++ conv.c (working copy) @@ -133,7 +133,7 @@ */ ch = 0; for (inp = in.dbp - in.dbcnt, outp = out.dbp; in.dbcnt;) { - maxlen = MIN(cbsz, in.dbcnt); + maxlen = MIN(cbsz, (size_t)in.dbcnt); if ((t = ctab) != NULL) for (cnt = 0; cnt < maxlen && (ch = *inp++) != '\n'; ++cnt) @@ -146,7 +146,7 @@ * Check for short record without a newline. Reassemble the * input block. */ - if (ch != '\n' && in.dbcnt < cbsz) { + if (ch != '\n' && (size_t)in.dbcnt < cbsz) { (void)memmove(in.db, in.dbp - in.dbcnt, in.dbcnt); break; } @@ -228,7 +228,7 @@ * translation has to already be done or we might not recognize the * spaces. */ - for (inp = in.db; in.dbcnt >= cbsz; inp += cbsz, in.dbcnt -= cbsz) { + for (inp = in.db; (size_t)in.dbcnt >= cbsz; inp += cbsz, in.dbcnt -= cbsz) { for (t = inp + cbsz - 1; t >= inp && *t == ' '; --t) ; if (t >= inp) { Index: dd.c =================================================================== --- dd.c (revision 270645) +++ dd.c (working copy) @@ -168,10 +168,10 @@ * record oriented I/O, only need a single buffer. */ if (!(ddflags & (C_BLOCK | C_UNBLOCK))) { - if ((in.db = malloc(out.dbsz + in.dbsz - 1)) == NULL) + if ((in.db = malloc((size_t)out.dbsz + in.dbsz - 1)) == NULL) err(1, "input buffer"); out.db = in.db; - } else if ((in.db = malloc(MAX(in.dbsz, cbsz) + cbsz)) == NULL || + } else if ((in.db = malloc(MAX((size_t)in.dbsz, cbsz) + cbsz)) == NULL || (out.db = malloc(out.dbsz + cbsz)) == NULL) err(1, "output buffer"); @@ -343,7 +343,7 @@ ++st.in_full; /* Handle full input blocks. */ - } else if ((size_t)n == in.dbsz) { + } else if ((size_t)n == (size_t)in.dbsz) { in.dbcnt += in.dbrcnt = n; ++st.in_full; @@ -493,7 +493,7 @@ outp += nw; st.bytes += nw; - if ((size_t)nw == n && n == out.dbsz) + if ((size_t)nw == n && n == (size_t)out.dbsz) ++st.out_full; else ++st.out_part; Index: dd.h =================================================================== --- dd.h (revision 270645) +++ dd.h (working copy) @@ -38,10 +38,9 @@ typedef struct { u_char *db; /* buffer address */ u_char *dbp; /* current buffer I/O address */ - /* XXX ssize_t? */ - size_t dbcnt; /* current buffer byte count */ - size_t dbrcnt; /* last read byte count */ - size_t dbsz; /* block size */ + ssize_t dbcnt; /* current buffer byte count */ + ssize_t dbrcnt; /* last read byte count */ + ssize_t dbsz; /* block size */ #define ISCHR 0x01 /* character device (warn on short) */ #define ISPIPE 0x02 /* pipe-like (see position.c) */ @@ -57,13 +56,13 @@ } IO; typedef struct { - uintmax_t in_full; /* # of full input blocks */ - uintmax_t in_part; /* # of partial input blocks */ - uintmax_t out_full; /* # of full output blocks */ - uintmax_t out_part; /* # of partial output blocks */ - uintmax_t trunc; /* # of truncated records */ - uintmax_t swab; /* # of odd-length swab blocks */ - uintmax_t bytes; /* # of bytes written */ + size_t in_full; /* # of full input blocks */ + size_t in_part; /* # of partial input blocks */ + size_t out_full; /* # of full output blocks */ + size_t out_part; /* # of partial output blocks */ + size_t trunc; /* # of truncated records */ + size_t swab; /* # of odd-length swab blocks */ + size_t bytes; /* # of bytes written */ struct timespec start; /* start time of dd */ } STAT; Index: position.c =================================================================== --- position.c (revision 270645) +++ position.c (working copy) @@ -178,7 +178,7 @@ n = write(out.fd, out.db, out.dbsz); if (n == -1) err(1, "%s", out.name); - if ((size_t)n != out.dbsz) + if (n != out.dbsz) errx(1, "%s: write failure", out.name); } break; From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 06:23:15 2014 Return-Path: Delivered-To: current@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 6ABF6337; Tue, 26 Aug 2014 06:23:15 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 2D6453C98; Tue, 26 Aug 2014 06:23:15 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id 9DB211598; Tue, 26 Aug 2014 06:23:13 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id s7Q6NCOu098223; Tue, 26 Aug 2014 06:23:12 GMT (envelope-from phk@phk.freebsd.dk) To: John Baldwin Subject: Re: gbde destroy doesn't match man page? In-reply-to: <2945485.ZemF81RAkB@ralph.baldwin.cx> From: "Poul-Henning Kamp" References: <20140820215522.GA92455@bewilderbeast.blackhelicopters.org> <23149.1408789002@critter.freebsd.dk> <2945485.ZemF81RAkB@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <98221.1409034192.1@critter.freebsd.dk> Date: Tue, 26 Aug 2014 06:23:12 +0000 Message-ID: <98222.1409034192@critter.freebsd.dk> Cc: current@freebsd.org, "Michael W. Lucas" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 06:23:15 -0000 -------- In message <2945485.ZemF81RAkB@ralph.baldwin.cx>, John Baldwin writes: >On Saturday, August 23, 2014 10:16:42 AM Poul-Henning Kamp wrote: >> -------- >> In message <20140820215522.GA92455@bewilderbeast.blackhelicopters.org>, >> "Michae >> l W. Lucas" writes: >> >Playing with GBDE for my FreeBSD disk book, on: >> > >> ># uname -a >> >FreeBSD storm 11.0-CURRENT FreeBSD 11.0-CURRENT #6 r269010: Wed Jul 23 >> >11:13:17 EDT 2014 mwlucas@storm:/usr/obj/usr/src/sys/GENERIC amd64 >> > >> >According to the man page, I should be able to destroy all copies of >> >the key with gbde destroy -n -1. It's in the examples. When I >> >> >try it I get: >> I think that is an oversight in the code. > >Can you expand on this? I.e. what should the code do if it is fixed? Hmm, now that I think about it, -n doesn't make sense because any one of the four keys can open the volume as needed to blow away the masterkey. The manual page should just be fixed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 07:23:23 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5DD261A; Tue, 26 Aug 2014 07:23:23 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 81E183291; Tue, 26 Aug 2014 07:23:23 +0000 (UTC) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.5/8.14.5) with ESMTP id s7Q7OPK6077611; Tue, 26 Aug 2014 00:24:31 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimatedns.net (8.14.5/8.14.5/Submit) id s7Q7OJRg077607; Tue, 26 Aug 2014 00:24:19 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Tue, 26 Aug 2014 00:24:19 -0700 (PDT) Message-ID: In-Reply-To: References: Date: Tue, 26 Aug 2014 00:24:19 -0700 (PDT) Subject: Re: How to get a mouse in vt(4) -- NEWCONS From: "Chris H" To: "Kevin Oberman" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Warren Block , freebsd hackers , freebsd current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 07:23:23 -0000 > On Mon, Aug 25, 2014 at 5:54 PM, Chris H wrote: > >> > On Mon, 25 Aug 2014, Chris H wrote: >> > >> >> I also read that hw.vga.textmode is available. However sysctl >> >> hw.vga.textmode returns unknown oid. >> > >> > It is a boot-time-only setting for loader.conf. >> > >> > hw.vga.textmode=1 >> > >> > boots in text mode. >> Ahh, I see. Thank you very much, Warren, for the reply. :) >> >> --Chris >> >> > But the mouse should work fine with vt(4). It does for me. You do need to > run moused, though that was the case with cs(4), as well. D'OH! Sorry my bad. I overlooked the entry in loader.conf(5) on my other box. Sorry for the noise. > The lack of > "blink" support was just noted in the last post to this list, so we can > hope to hear a bit about the status of blink soon. That would be good to know. Thank you for taking the time to respond, Kevin. --Chris > -- > R. Kevin Oberman, Network Engineer, Retired > E-mail: rkoberman@gmail.com > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 09:48:32 2014 Return-Path: Delivered-To: freebsd-current@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 5A351906 for ; Tue, 26 Aug 2014 09:48:32 +0000 (UTC) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::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 E4798310F for ; Tue, 26 Aug 2014 09:48:31 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id m15so14023840wgh.3 for ; Tue, 26 Aug 2014 02:48:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=79209HSGt7D0aj2xfpLLd8qq8MABVEoLhTTPONH1KHU=; b=UWIn8OxFDpJDuIbLoOyHP4p0eKkg42YCNfIfE9jdhqfmDr+3KT+/9vG1sGRaGQMQb9 NsAhTfWtSoKRVeV6cmodx33r4plSNVFD7nfpt6NxKWdw8E8bCzG1OB84hjP7vpBTwVEM 6fy3UEU3sqXc2KRw+K79ZZu9RgAfJ/u0fNX4S2k8o2zxt0/eYfOQkxmOoLhf0u4KaJ4D vuSMEIM+brykUzQdEx/uyaSDoag5XBTvIa1LJl+gORSKFY32hr/4KQZ5otQ9Nj/qU2oS JQoHbZW7TdQqphshBYZUrwRCF31G4WeNYaW4cR4IMXUEm3u7+0jnBTtJB6J8S00VHN1g g+jg== X-Received: by 10.195.12.4 with SMTP id em4mr8792785wjd.98.1409046510176; Tue, 26 Aug 2014 02:48:30 -0700 (PDT) Received: from [192.168.178.121] (p5B36D7F5.dip0.t-ipconnect.de. [91.54.215.245]) by mx.google.com with ESMTPSA id l3sm10364916wib.11.2014.08.26.02.48.28 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Aug 2014 02:48:29 -0700 (PDT) Message-ID: <53FC57EC.2000107@gmail.com> Date: Tue, 26 Aug 2014 11:48:28 +0200 From: =?windows-1252?Q?Jan_Kokem=FCller?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Fedor Indutny , freebsd-current@freebsd.org Subject: Re: KQueue 0-length UDP packet References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 09:48:32 -0000 Hi, > What I wanted to ask is: why does FreeBSD kqueue implementation treat > `SO_RCVLOWAT` as a raw packet size watermark, and not using the actual > data size for filtering out events? It looks like SO_RCVLOWAT refers to the number of bytes in the socket buffer, not raw packet bytes. In the case of an arriving UDP packet there is always a 'struct sockaddr' in the buffer that contains the source address/port of the message. For IPv4 this is 16 bytes and for IPv6 28 bytes. I think this is intended behavior, as this is data you can "read" with recvfrom or recvmsg. POSIX says "Receive calls may still return less than the low water mark if an error occurs, a signal is caught, or the type of data next in the receive queue is different from that returned (for example, out-of-band data)." So in this case this data is address data. On the other hand, NOTE_LOWAT from kevent refers to data/protocol bytes. The semantics were changed in 2002: http://marc.info/?l=freebsd-arch&m=103587526507822&w=2 The value you get in 'data' also refers to the number of protocol data bytes available. I've had a look at how OpenBSD handles this. It returns the number of protocol data bytes with "ioctl(s, FIONREAD, &len)" but the number of bytes in the socket buffer in the 'data' member of kevent, so exactly the other way around compared to FreeBSD. SO_RCVLOWAT works still the same, though. Cheers, Jan From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 10:16:53 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6823F53 for ; Tue, 26 Aug 2014 10:16:53 +0000 (UTC) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A0D5F3438 for ; Tue, 26 Aug 2014 10:16:53 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id y20so11280171ier.41 for ; Tue, 26 Aug 2014 03:16:53 -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=2tlSmFODec+2wi2/EBCKLyte2emPSfzkytFDSF0rhjQ=; b=Ycw5W3saTvLbMsrrTNhb1H9By8w2+b+aWQcq0b0wedzUoMBo/WPRyYkcf5mDuHh4UA 74GhRXsTRfOWrcLHP2W8VmGsZvXiX+uWPtFbb93PtNgWWSd5Xqrlxvdzrnz+GAV5CKsl x6jKYZsPlg9TpQDdA6YNkhyiQL6hH+7PT2jkkx8AFJgXZ7WmeZyF+6hZtvsfO8yan2vY oR6J36BAEUaRALm27y/GnzZy7YhOWA5MmGBqVLctLsQVoMh55t2OCYnXeTg3x3Ajj3K7 fGEC+OkcvdpdNiIFELMjeUhl5aCzYLc8AncLM9u/SafwPwo3RLpE40xytGcqrIOUPh/y tszg== X-Received: by 10.50.55.68 with SMTP id q4mr21093083igp.44.1409048212982; Tue, 26 Aug 2014 03:16:52 -0700 (PDT) MIME-Version: 1.0 Sender: fedor.indutny@gmail.com Received: by 10.107.28.20 with HTTP; Tue, 26 Aug 2014 03:16:32 -0700 (PDT) In-Reply-To: <53FC57EC.2000107@gmail.com> References: <53FC57EC.2000107@gmail.com> From: Fedor Indutny Date: Tue, 26 Aug 2014 14:16:32 +0400 X-Google-Sender-Auth: UHjPWn3hdl-hNXzEVBqnvEbBYjM Message-ID: Subject: Re: KQueue 0-length UDP packet To: =?UTF-8?Q?Jan_Kokem=C3=BCller?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 10:16:53 -0000 Ok, thanks for a clarification! On Tue, Aug 26, 2014 at 1:48 PM, Jan Kokem=C3=BCller wrote: > Hi, > > > What I wanted to ask is: why does FreeBSD kqueue implementation treat >> `SO_RCVLOWAT` as a raw packet size watermark, and not using the actual >> data size for filtering out events? >> > > It looks like SO_RCVLOWAT refers to the number of bytes in the socket > buffer, not raw packet bytes. In the case of an arriving UDP packet there > is always a 'struct sockaddr' in the buffer that contains the source > address/port of the message. For IPv4 this is 16 bytes and for IPv6 28 > bytes. I think this is intended behavior, as this is data you can "read" > with recvfrom or recvmsg. > > POSIX says "Receive calls may still return less than the low water mark i= f > an error occurs, a signal is caught, or the type of data next in the > receive queue is different from that returned (for example, out-of-band > data)." So in this case this data is address data. > > On the other hand, NOTE_LOWAT from kevent refers to data/protocol bytes. > The semantics were changed in 2002: > http://marc.info/?l=3Dfreebsd-arch&m=3D103587526507822&w=3D2 > The value you get in 'data' also refers to the number of protocol data > bytes available. > > I've had a look at how OpenBSD handles this. It returns the number of > protocol data bytes with "ioctl(s, FIONREAD, &len)" but the number of byt= es > in the socket buffer in the 'data' member of kevent, so exactly the other > way around compared to FreeBSD. SO_RCVLOWAT works still the same, though. > > Cheers, > Jan > From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 12:21:52 2014 Return-Path: Delivered-To: freebsd-current@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 C2BC5C02; Tue, 26 Aug 2014 12:21:52 +0000 (UTC) Received: from mail.feld.me (mail.feld.me [66.170.3.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.feld.me", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 524C83066; Tue, 26 Aug 2014 12:21:52 +0000 (UTC) Received: from mail.feld.me (mail.feld.me [66.170.3.6]); by mail.feld.me (OpenSMTPD) with ESMTP id a31722ba; Tue, 26 Aug 2014 07:21:41 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=feld.me; h=mime-version :date:content-type:message-id:from:subject:to:cc:in-reply-to :references:sender; s=blargle2; bh=ilfNqKioY0RsbmKS+bAWi4we4ho=; b= womcQ+U7nwqP6j9qtxAWJt43NzJd1tgIQ91gRe/9ZH73KTkUFJqJdKnDL8XVb2t9 czbkRoJhML1TQqhEJgZqJYffDE7+xkgQvP0ySWhpJmD8EJvp3Vdv2SZUROJLA96c orJ71uZm82MsAPTKswZ9/bT1nLVZAIawlVvvXXiHk+G3QzpTMOl+EHgebVp1GiVt NLdZYBzBTpCfYel63IlxCy6QXdPNR/KnTFg4j5mf+iZbNuBGmYTiQP5DfmexopDU rllhwyLPbYLfQNtKkvlDrnXiGApbT1GCADv9Wcte1grpH3Nq7tL0fJL7dttX1tad HsPTEQygs1aXOLljH+dQKA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=feld.me; h=mime-version:date :content-type:message-id:from:subject:to:cc:in-reply-to :references:sender; q=dns; s=blargle2; b=bI5TI7wehz7UpqWRjBl5Dbw x5NnS0iRCwEWuv4R3mkZbAKNz5y+cxn6N/KduGpLTQvaW5bRPCrH4XwlN19R4p9E srUnIIYZqdrlrzUblvRm3fbOQ8uEhN2EsG1qUU2cjwUPWXL7XkHuvTL5efmQWH71 xy0ffRT0zfY1vWl4Y7WgDf+MyxQrbuvQjNQbyYu052Uetc/YVta6DktLi0U+Nry6 IxJp75jFtjp6/Hbpc0XPhapHWHIYk7mytSOuW5hB0GFneDZk3IIFuRVEAyjbQ8f2 MB/2WUZnyKQ6rm3DRRNYy2HV50C0jjqk4pUsyfSfoSFJbR+ZLVU6vw7biEyMl9w= = Received: from mail.feld.me (mail.feld.me [66.170.3.6]); by mail.feld.me (OpenSMTPD) with ESMTP id c8474759; Tue, 26 Aug 2014 07:21:41 -0500 (CDT) Received: from feld@feld.me by mail.feld.me (Archiveopteryx 3.2.0) with esmtpa id 1409055699-26245-26241/5/84; Tue, 26 Aug 2014 12:21:39 +0000 Mime-Version: 1.0 Date: Tue, 26 Aug 2014 12:21:39 +0000 Content-Type: text/plain; charset=utf-8 Message-Id: <3757c98effd644bcf0b6f7cb0572a4f2@mail.feld.me> X-Mailer: RainLoop/1.6.8.153 From: Mark Felder Subject: Re: FreeBSD 10 and zfsd To: Alan Somers In-Reply-To: References: <5256B761.4050301@gmail.com> <1381421583.19140.32451849.084D8E32@webmail.messagingengine.com> <5256E2D5.4060101@allanjude.com> <1387388390.28188.61199633.413D38F8@webmail.messagingengine.com> Sender: feld@feld.me Cc: Outback Dingo , FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 12:21:52 -0000 Any hope of zfsd before the freeze for 10.1-RELEASE? Thanks! From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 13:25:21 2014 Return-Path: Delivered-To: freebsd-current@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 74218D18; Tue, 26 Aug 2014 13:25:21 +0000 (UTC) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id 55BCF366D; Tue, 26 Aug 2014 13:25:21 +0000 (UTC) Received: from marvin.lab.vangyzen.net (c-24-125-214-90.hsd1.va.comcast.net [24.125.214.90]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 2FB7156436; Tue, 26 Aug 2014 08:25:20 -0500 (CDT) Message-ID: <53FC8ABF.7000201@vangyzen.net> Date: Tue, 26 Aug 2014 09:25:19 -0400 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: John Baldwin , freebsd-current@freebsd.org Subject: Re: ktrace -c behavior References: <53F79710.6090700@vangyzen.net> <20140824235336.GR71691@funkthat.com> <53FB386C.9030800@vangyzen.net> <9285902.gXIcESz31I@ralph.baldwin.cx> In-Reply-To: <9285902.gXIcESz31I@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 13:25:21 -0000 On 08/25/2014 16:23, John Baldwin wrote: > On Monday, August 25, 2014 09:21:48 AM Eric van Gyzen wrote: >> On 08/24/2014 19:53, John-Mark Gurney wrote: >>> Eric van Gyzen wrote this message on Fri, Aug 22, 2014 at 15:26 -0400: >>>> On 08/22/2014 15:20, John-Mark Gurney wrote: >>>>> Eric van Gyzen wrote this message on Fri, Aug 22, 2014 at 15:16 -0400: >>>>>> What behavior would you expect from this sequence of commands? >>>>>> >>>>>> ktrace -tw -p 1234 >>>>>> ktrace -c -p 1234 >>>>>> >>>>>> Based on this... >>>>>> >>>>>> -c Clear the trace points associated with the specified file >>>>>> >>>>>> or processes. >>>>> and/or just add specified: >>>>> Clear the specified trace points ... >>>> But what if I didn't specify them? >>> You specified the default by not specificly specifing any different >>> ones.. :) Confused? :) >> Amused. :) > Adding "specified" is the first thing that came to my mind as well. > >>> or maybe selected? >> Perhaps, but I didn't select them, either. My original suggestion is >> more--dare I use this word again--specific. It explains exactly how the >> command behaves. > But then do we need to annotate every place that uses "trace points" to add > this language? Note that the 'command' description uses the language John- > mark suggested: > > command > Execute command with the specified trace flags. > > My vote would be to add "specified" to the description of "-c", but to improve > the the description of "-t" itself from: > > -t trstr > The string argument represents the kernel trace points, one per > letter. The following table equates the letters with the trace- > points: > > > to: > > -t trstr > Specify the list of trace points to enable or disable, one per > letter. If an explicit list is not specified, the default set > of trace points is used. > > The following trace points are supported: Okay, that would work. Minor note: You might avoid repeating "specified" in the -c description: Clear the specified trace points associated with the /given/ file or processes. Thanks, guys. Eric From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 15:05:15 2014 Return-Path: Delivered-To: freebsd-current@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 657491F7; Tue, 26 Aug 2014 15:05:15 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 603CA3164; Tue, 26 Aug 2014 15:05:14 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id ho1so4318435wib.10 for ; Tue, 26 Aug 2014 08:05:12 -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:content-transfer-encoding; bh=RLaX85PPJoWyaPS4wgKa7U0HfRh49cQXxgIy38g1tMY=; b=WpHAo/nNeiFq9qiV8ptenxdtSXQvWFLYwMLm5nIQ47Y9jCH7CtW5PvwPwn5Sh/RihL cMm3HE+nQylTcjTKjSaOQprhqve68yQdPX+NwVuvJp7qFS8hTScFgjvVrwKSm5nGE4d+ 5JZIBKABU4CCeeMItrX1oUPj4KhO6oj6aPVtyLDeAv1GwpDtePHV5CXTPqsGK9iOVn0g 2thIbpQ7PewA/NllPyVGvtKJc/jbhurq592Gwf4Q1sd6jg6WVyeUapek20CXJNp9Nbrf z0udZrEGTkZxrJCzINROpyNIchabB2zj5Eb1h+Jkox8cnFZ0rjNvh84He0lcNltTETM6 bnvA== MIME-Version: 1.0 X-Received: by 10.180.188.35 with SMTP id fx3mr22721051wic.82.1409065512690; Tue, 26 Aug 2014 08:05:12 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.194.126.1 with HTTP; Tue, 26 Aug 2014 08:05:12 -0700 (PDT) In-Reply-To: <2204059.7tqSNWvxzC@ralph.baldwin.cx> References: <522300E3.6050303@rawbw.com> <522419F4.5010605@rawbw.com> <53F72AC4.7040108@omnilan.de> <2204059.7tqSNWvxzC@ralph.baldwin.cx> Date: Tue, 26 Aug 2014 09:05:12 -0600 X-Google-Sender-Auth: hsoD8G7YDHZdwmMoK7tAn0BpGKM Message-ID: Subject: Re: [PATCH] Packet loss when 'control' messages are present with large data (sendmsg(2)) From: Alan Somers To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org, Alan Somers , Harald Schmalzbauer , FreeBSD CURRENT , "net@freebsd.org" , Yuri X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 15:05:15 -0000 On Mon, Aug 25, 2014 at 1:52 PM, John Baldwin wrote: > On Friday, August 22, 2014 01:34:28 PM Harald Schmalzbauer wrote: >> Bez=C3=BCglich Yuri's Nachricht vom 02.09.2013 06:54 (localtime): >> > Please check in this patch: >> > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D181741 >> > Please MFC into 9.X >> > >> > Description of the problem is within PR. >> > >> > Thanks, >> > Yuri >> >> Hello, >> >> I guess this fix should make it into 10.1. >> Can someone check please? > > A fix has to make into HEAD first. I've cc'd Alan who responded to the b= ug. > Alan, note that glebius@ already committed the test case to HEAD a while = ago. First, Gleb's testcase needs to be converted to ATF. This would be a good exercise for anybody who's new to ATF and wants some practice. Anybody interested? > > -- > John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 15:21:00 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B90CF6F6; Tue, 26 Aug 2014 15:21:00 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 23CDA3361; Tue, 26 Aug 2014 15:20:59 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id m15so14672444wgh.5 for ; Tue, 26 Aug 2014 08:20:58 -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=l0laE4Nq+KuwdsNb0eaODjP35UUGoViiQtko9GompdU=; b=RjLPPkfZdTGM7sQCCbF+FlPku7G4vXm80aPQ3EPza/qtMW4uj57FGses4m7225duyC bK9m8502aeTR2vt6eto11K5Srcs/BqYXPvsHOO3fqWm6dbVRkbvT7CGZiUsW5LWPY0jF ZfcB7NDvcs4ZN0CrGu8IMHOyJ4HTLLJfsvQHAvm6cf4NjfRWNE9O6MGroNVB/xqPcqqA GbaOkeMHmSWNql+9No47HnK7ei26wvZowcmH+k84bU3Hdd9Z/t9Um/FNejo0N/HzXuhg T1HDbdkz5WUhg/xi4owvkGVMS2iYwWjNyYIWQt5YDRTDeAQsaePBt1GQpy39gIQnmyJA 5oiw== MIME-Version: 1.0 X-Received: by 10.180.81.103 with SMTP id z7mr21958438wix.23.1409066458263; Tue, 26 Aug 2014 08:20:58 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.194.126.1 with HTTP; Tue, 26 Aug 2014 08:20:58 -0700 (PDT) In-Reply-To: References: <5256B761.4050301@gmail.com> <1381421583.19140.32451849.084D8E32@webmail.messagingengine.com> <5256E2D5.4060101@allanjude.com> <1387388390.28188.61199633.413D38F8@webmail.messagingengine.com> <53A7CE1B.7090400@gmail.com> Date: Tue, 26 Aug 2014 09:20:58 -0600 X-Google-Sender-Auth: FnYrXRveBAkjAtVsX0m1b71B1YM Message-ID: Subject: Re: FreeBSD 10 and zfsd From: Alan Somers To: Alan Somers Content-Type: text/plain; charset=UTF-8 Cc: Johan Hendriks , FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 15:21:00 -0000 Status update below: > > The projects/zfsd project branch is up to date. Merging it to CURRENT > is blocked on these tasks. > > 1) (The biggie) We must resolve the issue with multiple geom opens. > Geom tries to prevent any two consumers from simultaneously opening > the same provider. This is why, for example, you can't do dd > if=/dev/zero of=/dev/ada0 if your ada0 has a mounted file system. > However, ZFS internally opens spare devices multiple times. The only > way that geom will allow that is if ZFS opens devices non-exclusively. > That means that you will lose your protection. Fixing this correctly > requires deep changes to ZFS to remove the multiple opens. > > 2) Need to merge in zfsd's functional tests. I'm currently working on > this issue as time allows. Merged into the projects/zfsd/head branch by change 270604. Merging to head is blocked by three issues: a) The atf-ksh93 hack. The correct solution is to modify all the test programs (not the test cases) so they can run under /bin/sh. That will take some effort. b) Some test cases reference Spectra Logic internal bug numbers. We need to file FreeBSD PRs for all of them and change the references. c) It uses some ATF config variables that are not yet documented in tests(7). > > 3) It needs a manpage. > > 4) Various bug fixes need to be merged to the kernel and to LibZFS. > Coordinating with Illumos makes that process slow. will@ is working > on it as time allows. gibbs@ has been making progress here, with mahrens@ providing code review. But it is still slow. > > 5) libdevctl needs to be made private > > 6) The sequential packet feature added to devd in the zfsd project > branch at revision r266519 must be merged to head. It's currently > waiting for review from imp@ and ian@. Merged by r270004. To answer Mark's question: no, we can't finish all of this in time for 10.1. Sorry. -Alan From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 18:04:23 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0FEA9C77; Tue, 26 Aug 2014 18:04:23 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D7F7534CB; Tue, 26 Aug 2014 18:04:22 +0000 (UTC) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.5/8.14.5) with ESMTP id s7QI5Q1Y024844; Tue, 26 Aug 2014 11:05:32 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimatedns.net (8.14.5/8.14.5/Submit) id s7QI5LcY024843; Tue, 26 Aug 2014 11:05:21 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from unavailable01.ultimatedns.net ([209.180.214.227]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Tue, 26 Aug 2014 11:05:21 -0700 (PDT) Message-ID: Date: Tue, 26 Aug 2014 11:05:21 -0700 (PDT) Subject: did tar(1) loose xz compression support in 11? From: "Chris H" To: "freebsd current" , "freebsd hackers" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 18:04:23 -0000 Greetings, I'm currently testing 11. My build / install is from about 2 days ago. I generally use xz compression, when creating archives. But when I attempt the following: tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file it returns the following: tar: Undefined option: `xz:9' This has always worked in previous versions. Has the syntax changed, and the man(1) pages just haven't caught up? Thank you for all your time, and consideration. --Chris From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 18:53:47 2014 Return-Path: Delivered-To: freebsd-current@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 04005222 for ; Tue, 26 Aug 2014 18:53:47 +0000 (UTC) Received: from smtp2.wemm.org (smtp2.wemm.org [IPv6:2001:470:67:39d::78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp2.wemm.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CF5E13A5B for ; Tue, 26 Aug 2014 18:53:46 +0000 (UTC) Received: from hater-dm.corp.yahoo.com (nat-dip4.cfw-a-gci.corp.yahoo.com [209.131.62.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: peter) by smtp2.wemm.org (Postfix) with ESMTPSA id BD152468 for ; Tue, 26 Aug 2014 11:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=m20140428; t=1409079225; bh=MI8aWx2sHlqZzabq0IUVgnxpcXrr2v8d0UjgXgLpFic=; h=Date:From:To:Subject:References:In-Reply-To; b=gbxIHzn6jdzJdGrFSU+p2zhleeRS0FEfHo/YsIcvBcmrKv0eiE1SQZDhvLWD96Dyg 9QUI70Dz90Gq40ah3ythXWIQg9IANWT28WbZ2FilAjnBBRdsY3chXdz2AgiEDHxJ+l 9zfQbis9AvCOErj3Bu8Tttxf9srJbCQLHIXdVEfc= Message-ID: <53FCD7B8.5060300@wemm.org> Date: Tue, 26 Aug 2014 11:53:44 -0700 From: Peter Wemm User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: did tar(1) loose xz compression support in 11? References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="c8j408gkVOxn0uqqi14SET8NBF6cIoSAh" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 18:53:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --c8j408gkVOxn0uqqi14SET8NBF6cIoSAh Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 8/26/14 11:05 AM, Chris H wrote: > Greetings, > I'm currently testing 11. My build / install is from about 2 days ago. > I generally use xz compression, when creating archives. But when I > attempt the following: >=20 > tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file >=20 > it returns the following: >=20 > tar: Undefined option: `xz:9' >=20 > This has always worked in previous versions. Has the syntax changed, > and the man(1) pages just haven't caught up? I use: tar -cJ --options xz:compression-level=3D1 =2E. on head. Are you using the right syntax? --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6F= JV --c8j408gkVOxn0uqqi14SET8NBF6cIoSAh 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.13 (Darwin) iQEcBAEBAgAGBQJT/Ne4AAoJEDXWlwnsgJ4E1tEH/2zy4RURWe/H9L8Nza/HOMVS n/+59PK3n1AWDGjSTQbrTrcYUU6KsPHXqGYViOFI71o1+VVPqtLvlJypsMGf4WlN C8XwaMTj6yOa51LlGsZriCQ2xaIEfb1Dv6hyJj1EzHcF6hpjfZAK1hXKTF8RLE6q HMyQVqi4u6df1o/lD4fXyLtnEX2i2GHsAiQq23949f25CpvecqiXikd9xSfTGC/J Jn3h0Zk2XQrWlNM//ylf9TzOSNnWidzrWZXR2lpnv9hL3iXh2kFL1OV+ZVR09vmW O9KBg4VV06dTvHGdKuw+lfPfD5rgxagbZ2+scf+O/QO25w5uvRL7+uE+vG4VK54= =evUA -----END PGP SIGNATURE----- --c8j408gkVOxn0uqqi14SET8NBF6cIoSAh-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 19:27:15 2014 Return-Path: Delivered-To: freebsd-current@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 05D269C1 for ; Tue, 26 Aug 2014 19:27:15 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C9D483F2D for ; Tue, 26 Aug 2014 19:27:14 +0000 (UTC) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.5/8.14.5) with ESMTP id s7QJSJfo035343; Tue, 26 Aug 2014 12:28:25 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimatedns.net (8.14.5/8.14.5/Submit) id s7QJSB5H035337; Tue, 26 Aug 2014 12:28:11 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from unavailable01.ultimatedns.net ([209.180.214.227]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Tue, 26 Aug 2014 12:28:13 -0700 (PDT) Message-ID: In-Reply-To: <53FCD7B8.5060300@wemm.org> References: <53FCD7B8.5060300@wemm.org> Date: Tue, 26 Aug 2014 12:28:13 -0700 (PDT) Subject: Re: did tar(1) loose xz compression support in 11? From: "Chris H" To: "Peter Wemm" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 19:27:15 -0000 > On 8/26/14 11:05 AM, Chris H wrote: >> Greetings, >> I'm currently testing 11. My build / install is from about 2 days ago. >> I generally use xz compression, when creating archives. But when I >> attempt the following: >> >> tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file >> >> it returns the following: >> >> tar: Undefined option: `xz:9' >> >> This has always worked in previous versions. Has the syntax changed, >> and the man(1) pages just haven't caught up? > > I use: > tar -cJ --options xz:compression-level=1 > .. on head. Are you using the right syntax? Apparently not. Using your example works as expected. RELENG_8, and RELENG_9 use short-hand; tar -cvJ --options xz:9 Why/when the change to long-hand? Seems a shame. Now I get to modify all my scripts, and such. :P Altho I don't suppose it'd be a big deal to back out (revert) the changes made to tar(1). :) Thank you, very much, Peter. For taking the time to respond. --Chris > > -- > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV > > From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 19:29:02 2014 Return-Path: Delivered-To: freebsd-current@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 8C2DDD3B; Tue, 26 Aug 2014 19:29:02 +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 21BAF3F58; Tue, 26 Aug 2014 19:29:02 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1B9F7B98D; Tue, 26 Aug 2014 15:29:01 -0400 (EDT) From: John Baldwin To: Alan Somers Subject: Re: [PATCH] Packet loss when 'control' messages are present with large data (sendmsg(2)) Date: Tue, 26 Aug 2014 15:15:31 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <522300E3.6050303@rawbw.com> <2204059.7tqSNWvxzC@ralph.baldwin.cx> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201408261515.32146.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 26 Aug 2014 15:29:01 -0400 (EDT) Cc: Harald Schmalzbauer , FreeBSD CURRENT , "net@freebsd.org" , current@freebsd.org, Yuri X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 19:29:02 -0000 On Tuesday, August 26, 2014 11:05:12 am Alan Somers wrote: > On Mon, Aug 25, 2014 at 1:52 PM, John Baldwin wrote: > > On Friday, August 22, 2014 01:34:28 PM Harald Schmalzbauer wrote: > >> Bez=C3=BCglich Yuri's Nachricht vom 02.09.2013 06:54 (localtime): > >> > Please check in this patch: > >> > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D181741 > >> > Please MFC into 9.X > >> > > >> > Description of the problem is within PR. > >> > > >> > Thanks, > >> > Yuri > >> > >> Hello, > >> > >> I guess this fix should make it into 10.1. > >> Can someone check please? > > > > A fix has to make into HEAD first. I've cc'd Alan who responded to the= bug. > > Alan, note that glebius@ already committed the test case to HEAD a whil= e ago. >=20 > First, Gleb's testcase needs to be converted to ATF. This would be a > good exercise for anybody who's new to ATF and wants some practice. > Anybody interested? While that would be nice, I don't know that it's quite fair to require the test to be converted before working on a possible fix. The existing test doesn't seem that hard to run by hand: % cd work/freebsd/head/tools/regression/sockets/unix_passfd/ % make =2E.. % > ./unix_passfd=20 beginning test1-simplesendfd test1-simplesendfd passed =2E.. beginning test8-rigths+creds+payload unix_passfd: test8-rigths+creds+payload: recvmsg: 24 bytes received I only say this because in the bug followup you seemed to have described a possible solution so it seems that you would be able to develop a fix quick= er than other folks since you are already familiar with the issues involved. (Also, you've fixed other related issues recently.) =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 19:39:29 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3F363D52; Tue, 26 Aug 2014 19:39:29 +0000 (UTC) Received: from mail.feld.me (mail.feld.me [66.170.3.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.feld.me", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AB93D310A; Tue, 26 Aug 2014 19:39:28 +0000 (UTC) Received: from mail.feld.me (mail.feld.me [66.170.3.6]); by mail.feld.me (OpenSMTPD) with ESMTP id f97ba12b; Tue, 26 Aug 2014 14:39:24 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=feld.me; h=mime-version :date:content-type:message-id:from:subject:to:cc:in-reply-to :references:sender; s=blargle2; bh=IfsOhHbj3qPf3JJ91fAqCXtpxQA=; b= MK7q7bG+6+fx69BaCnv3mxvfUtDtKhdJtZ8pZlsMAEQgODABWVfymS/ox4DfhEAl A9160DZTBquDamwoGdQzbVrPCH5kTGwjI2aXPhq1+j3HjnFUVAK66/kKtAdjAhiZ GEZZV2RVOpbTicUBD7IjTo9JdktatvBN/huIgiNGEGzc1XmnQQhDRRkUT5jHrZ6P OgkcpP3zCiw7+fU6g6kW4139+yKm40+WYOQNXwcbkzfrnZ8GbL7dAk9pvzTxB2Gs EXrRFyVOOxq0qef8tF0L1vdJLIHosUKmDxVdjhfcBuvVw6E1/z1zrDe401D6V3Wg 3oimTzWBJX6URxd+3bnOHA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=feld.me; h=mime-version:date :content-type:message-id:from:subject:to:cc:in-reply-to :references:sender; q=dns; s=blargle2; b=algAT9up779t1FmW+I/tKYK lKuDiFcZEst65sDz7quGu0Ghup5qTn7k8w9la9g5BNIOZncUjDODPgGSnErhm5ZQ BoN44o9pNjJUW0SRL4MC2ErC+3s8V+ran47/FDmW2mzPLkxy42GgV3+IVqw/4NI+ zeY9mtg4QUxCHKjumWLafXZLC6TtDcVw8jZ8sn6H00qIeGK5ZF07VHCPbK3JZMdB r9jpwAAjpA9WFvLICLfLT1BIcPpkHG/l57Gi+IGbLCNFI0C/x0zUgdc+rsOHmyrR WAPgUJBS02P2zT4r2RUEYMFgqSiPdryWG8r35TZRK/u9NJ730qzZnrxpFfV8H5Q= = Received: from mail.feld.me (mail.feld.me [66.170.3.6]); by mail.feld.me (OpenSMTPD) with ESMTP id dda48ac7; Tue, 26 Aug 2014 14:39:24 -0500 (CDT) Received: from feld@feld.me by mail.feld.me (Archiveopteryx 3.2.0) with esmtpa id 1409081963-26244-26241/5/76; Tue, 26 Aug 2014 19:39:23 +0000 Mime-Version: 1.0 Date: Tue, 26 Aug 2014 19:39:22 +0000 Content-Type: text/plain; charset=utf-8 Message-Id: <8e598a07cf5bc8690749120295936c40@mail.feld.me> X-Mailer: RainLoop/1.6.8.153 From: Mark Felder Subject: Re: FreeBSD 10 and zfsd To: Alan Somers In-Reply-To: References: <5256B761.4050301@gmail.com> <1381421583.19140.32451849.084D8E32@webmail.messagingengine.com> <5256E2D5.4060101@allanjude.com> <1387388390.28188.61199633.413D38F8@webmail.messagingengine.com> <53A7CE1B.7090400@gmail.com> Sender: feld@feld.me Cc: Johan Hendriks , FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 19:39:29 -0000 August 26 2014 10:21 AM, "Alan Somers" wrote: > > Merged into the projects/zfsd/head branch by change 270604. Merging > to head is blocked by three issues: > a) The atf-ksh93 hack. The correct solution is to modify all the test > programs (not the test cases) so they can run under /bin/sh. That > will take some effort. Can you provide a link to the atf-ksh93 code? From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 19:45:14 2014 Return-Path: Delivered-To: freebsd-current@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 8656528F; Tue, 26 Aug 2014 19:45:14 +0000 (UTC) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C1757329B; Tue, 26 Aug 2014 19:45:13 +0000 (UTC) Received: by mail-we0-f169.google.com with SMTP id u56so15162118wes.28 for ; Tue, 26 Aug 2014 12:45:12 -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=JxCPFPdqaeTa/QlFfQjxH0ghjyEI72IIxXRoWWQtOSI=; b=I5r6sZnhNDwmfGvZciUgZYyYBY00Ukf+3MrUu+tW8tsPjcCLVdB9zrVOuM3f+Xc1Dv sEYwjFxS8+kHLnTyTGf8RWK5V/GgXBZMmPp8lTp1KPFmHuBMPJkTgH2UX1LpunXPgwWs /UJRbNjty60FQBA1bVEREQFA4yDlEA/+kLYFjW8pg1nf6rOpbbqsruK6A5HXQ/7n9S8j ShHxPIe9gAHQnY4Tj2zAGkWAGLXXG5H2iCZnzeEuuDMhpphI5VLNhkfGYHqAx5eiRTrX HmReCgnfDwBb03lB+Aoz3w6cL2uiuJbK9mnNPAjWQ4MI57SedAzRcScMe6nY7okvAKcH vZHA== MIME-Version: 1.0 X-Received: by 10.194.81.230 with SMTP id d6mr24272757wjy.49.1409082312002; Tue, 26 Aug 2014 12:45:12 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.194.126.1 with HTTP; Tue, 26 Aug 2014 12:45:11 -0700 (PDT) In-Reply-To: <8e598a07cf5bc8690749120295936c40@mail.feld.me> References: <5256B761.4050301@gmail.com> <1381421583.19140.32451849.084D8E32@webmail.messagingengine.com> <5256E2D5.4060101@allanjude.com> <1387388390.28188.61199633.413D38F8@webmail.messagingengine.com> <53A7CE1B.7090400@gmail.com> <8e598a07cf5bc8690749120295936c40@mail.feld.me> Date: Tue, 26 Aug 2014 13:45:11 -0600 X-Google-Sender-Auth: xKuwF7iELCc3-1PUIeutgnLlR7E Message-ID: Subject: Re: FreeBSD 10 and zfsd From: Alan Somers To: Mark Felder Content-Type: text/plain; charset=UTF-8 Cc: Johan Hendriks , FreeBSD CURRENT , Alan Somers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 19:45:14 -0000 On Tue, Aug 26, 2014 at 1:39 PM, Mark Felder wrote: > August 26 2014 10:21 AM, "Alan Somers" wrote: >> >> Merged into the projects/zfsd/head branch by change 270604. Merging >> to head is blocked by three issues: >> a) The atf-ksh93 hack. The correct solution is to modify all the test >> programs (not the test cases) so they can run under /bin/sh. That >> will take some effort. > > Can you provide a link to the atf-ksh93 code? There's not much to it. It simply sets an environment variable and calls atf-sh. What's more interesting is libtest.kshlib. In order to eliminate atf-ksh93, we would need to modify libtest.kshlib to run under /bin/sh. Alternatively, it may be easier to split libtest.kshlib into two files: a small /bin/sh-compatible that can be sourced by the ATF test programs, and a ksh93 script that only needs to be sourced by the ATF test cases. https://svnweb.freebsd.org/base/projects/zfsd/head/libexec/atf/atf-ksh93/ https://svnweb.freebsd.org/base/projects/zfsd/head/tests/sys/cddl/zfs/include/libtest.kshlib From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 19:49:00 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A42885EC; Tue, 26 Aug 2014 19:49:00 +0000 (UTC) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 609AF337E; Tue, 26 Aug 2014 19:49:00 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id hz1so23738768pad.8 for ; Tue, 26 Aug 2014 12:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=2OrYwMLOoRJqRh4kRsgKoMv8eWVh5lbpNWAOdFiFTEM=; b=Uyc/kYx0YtUVh7/kOaIt0KxzHldVmki0emZPXvwBPxj3PZM2T3A8OUWXRugRU61YxT /lRBA/BA8V8NKXRKDzuWUSf/1AmtWfAOZsnS0IeKbUw1oNsiEGg/N0ozokp6TRLToRPm DQP31axsiaN9OOmpNjtrrGh8hf/mp7FH0w0ONUp68cSo3UHavR+jcGTgQP6wQkNXsdQw MXgIvF2N/ltn8rjZPAT5VWhiiinz9NEvE3Yko5KtwtDfWVI5kWuOrLWfTSrndeArkvPj f1zLjXmjhrWdY4xnc5OuOYLuJ10LkPc/ZJfaeDWi6BrNS4Pt9wRSJF5wQ4oizlai1JN2 x0Uw== X-Received: by 10.66.222.97 with SMTP id ql1mr22932850pac.119.1409082539986; Tue, 26 Aug 2014 12:48:59 -0700 (PDT) Received: from [192.168.20.11] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id d8sm6045659pdl.94.2014.08.26.12.48.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Aug 2014 12:48:59 -0700 (PDT) References: <5256B761.4050301@gmail.com> <1381421583.19140.32451849.084D8E32@webmail.messagingengine.com> <5256E2D5.4060101@allanjude.com> <1387388390.28188.61199633.413D38F8@webmail.messagingengine.com> <53A7CE1B.7090400@gmail.com> <8e598a07cf5bc8690749120295936c40@mail.feld.me> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <73E03261-8087-415A-BD04-EAADFF90C080@gmail.com> X-Mailer: iPhone Mail (11D257) From: Garrett Cooper Subject: Re: FreeBSD 10 and zfsd Date: Tue, 26 Aug 2014 12:48:57 -0700 To: Alan Somers Cc: Johan Hendriks , FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 19:49:00 -0000 > On Aug 26, 2014, at 12:45, Alan Somers wrote: >=20 >> On Tue, Aug 26, 2014 at 1:39 PM, Mark Felder wrote: >> August 26 2014 10:21 AM, "Alan Somers" wrote: >>>=20 >>> Merged into the projects/zfsd/head branch by change 270604. Merging >>> to head is blocked by three issues: >>> a) The atf-ksh93 hack. The correct solution is to modify all the test >>> programs (not the test cases) so they can run under /bin/sh. That >>> will take some effort. >>=20 >> Can you provide a link to the atf-ksh93 code? >=20 > There's not much to it. It simply sets an environment variable and > calls atf-sh. What's more interesting is libtest.kshlib. In order to > eliminate atf-ksh93, we would need to modify libtest.kshlib to run > under /bin/sh. Alternatively, it may be easier to split > libtest.kshlib into two files: a small /bin/sh-compatible that can be > sourced by the ATF test programs, and a ksh93 script that only needs > to be sourced by the ATF test cases. I'm working on integrating the dtrace testcases into kyua, then atf under Ky= ua as time permits, but I'm not rewriting the core test code (yet), because I= want to reduce divergence with upstream. Why not just require ksh93 from ports? Cheers! -Garrett= From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 19:52:20 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D0CA8992; Tue, 26 Aug 2014 19:52:20 +0000 (UTC) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::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 47BFB34A4; Tue, 26 Aug 2014 19:52:20 +0000 (UTC) Received: by mail-qc0-f172.google.com with SMTP id i8so16230906qcq.31 for ; Tue, 26 Aug 2014 12:52:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=J1InMtZnkzQ/WuX4+N9gZo1O/wy0+f6D5hznLe+Szvs=; b=E5zzIpBngIQnMDB9NF2MjjSk8FNzNBAw8C5sk8MlZPSTgpWw6OtqOoVlwyZ2R60mhV K1ZG1mbTPUyU8N6+bJWKCBl+GDTxvvFmVTiydmd9GwO6rkKyaslR+vgeCLR5sNWgQ09V PuUJOM5yoJJYkGkPWsyMFiOY81ZtCF2KC/PVmqOTI6Xntc2ZNwBwYGtixjRrucv0zWdG 2+kQ+XkdtIP4W+x3iDXTRxxkaZ4B0dSbIKLEwzpZ3f+giZSjG448V5Ir8aIylYid973e tYK/yMBvOWMQw8MmjHA7/Uc8HqkMRHWgQ8SnD1m2SujVPhv08jXmNhPBl8C2seziWf1o lD8g== X-Received: by 10.140.89.5 with SMTP id u5mr47597909qgd.14.1409082739298; Tue, 26 Aug 2014 12:52:19 -0700 (PDT) Received: from charmander.home ([64.229.13.35]) by mx.google.com with ESMTPSA id k4sm12392362qaf.0.2014.08.26.12.52.18 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Aug 2014 12:52:18 -0700 (PDT) Sender: Mark Johnston Date: Tue, 26 Aug 2014 15:51:40 -0400 From: Mark Johnston To: John Baldwin Subject: Re: [PATCH] Packet loss when 'control' messages are present with large data (sendmsg(2)) Message-ID: <20140826195140.GA10143@charmander.home> References: <522300E3.6050303@rawbw.com> <2204059.7tqSNWvxzC@ralph.baldwin.cx> <201408261515.32146.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201408261515.32146.jhb@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: current@freebsd.org, Alan Somers , Harald Schmalzbauer , FreeBSD CURRENT , "net@freebsd.org" , Yuri X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 19:52:21 -0000 On Tue, Aug 26, 2014 at 03:15:31PM -0400, John Baldwin wrote: > On Tuesday, August 26, 2014 11:05:12 am Alan Somers wrote: > > On Mon, Aug 25, 2014 at 1:52 PM, John Baldwin wrote: > > > On Friday, August 22, 2014 01:34:28 PM Harald Schmalzbauer wrote: > > >> Bezüglich Yuri's Nachricht vom 02.09.2013 06:54 (localtime): > > >> > Please check in this patch: > > >> > http://www.freebsd.org/cgi/query-pr.cgi?pr=181741 > > >> > Please MFC into 9.X > > >> > > > >> > Description of the problem is within PR. > > >> > > > >> > Thanks, > > >> > Yuri > > >> > > >> Hello, > > >> > > >> I guess this fix should make it into 10.1. > > >> Can someone check please? > > > > > > A fix has to make into HEAD first. I've cc'd Alan who responded to the bug. > > > Alan, note that glebius@ already committed the test case to HEAD a while ago. > > > > First, Gleb's testcase needs to be converted to ATF. This would be a > > good exercise for anybody who's new to ATF and wants some practice. > > Anybody interested? > > While that would be nice, I don't know that it's quite fair to require the > test to be converted before working on a possible fix. The existing test > doesn't seem that hard to run by hand: > > % cd work/freebsd/head/tools/regression/sockets/unix_passfd/ > % make > ... > % > ./unix_passfd > beginning test1-simplesendfd > test1-simplesendfd passed > ... > beginning test8-rigths+creds+payload > unix_passfd: test8-rigths+creds+payload: recvmsg: 24 bytes received > > I only say this because in the bug followup you seemed to have described a > possible solution so it seems that you would be able to develop a fix quicker > than other folks since you are already familiar with the issues involved. > (Also, you've fixed other related issues recently.) As it happens, I went ahead and did this anyway: https://reviews.freebsd.org/D689 From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 20:01:20 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A293B312; Tue, 26 Aug 2014 20:01:20 +0000 (UTC) Received: from mail.feld.me (mail.feld.me [66.170.3.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.feld.me", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1AA3936B3; Tue, 26 Aug 2014 20:01:20 +0000 (UTC) Received: from mail.feld.me (mail.feld.me [66.170.3.6]); by mail.feld.me (OpenSMTPD) with ESMTP id 4d1c14b4; Tue, 26 Aug 2014 15:01:17 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=feld.me; h=mime-version :date:content-type:content-transfer-encoding:message-id:from :subject:to:cc:in-reply-to:references:sender; s=blargle2; bh=AfL 6clfw8Ya5JDGM/N2dJWhrxMg=; b=GdZ+gMjc5cUetuVxVEq6BXzCXFS6FRL03AM WixT2LHelJupT2u5qci4Ax6+8WbWtmYKt75wm5t2tCtIprya4OXdwjCT4MDT+aPB ZXZxlfvA/KDU/XOtifLSwOFnknWlKVl61sYC2POnbvjQDVpyvCeT+6lq6XZLJgWP IV2wALzcrlC47/hmmF0etGgLo2viiziYemlbWZs6pXk3W3xQ3SY3zMxZxyHjwWc4 /rTM6iuDgGdNFBDVPU+b91yjEFfPiBlwSPF48Qw6ImFNT2lDKrqNigt1O8XFZM/e Myhj/qiyikrrPl1HfyjEa7um7GQzeTtaqUA5Ea6ezePiT3CN4WQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=feld.me; h=mime-version:date :content-type:content-transfer-encoding:message-id:from:subject :to:cc:in-reply-to:references:sender; q=dns; s=blargle2; b=WWUav mczrbJNcbwrCijDaQ4qOtbUWVvfZh0f58L4uDKmqrw+Cbo6t2dXP1JF17gPt/pKh 30+OOnbBHMUbZMkzMxIbZiEke+4J1166ec8xFyWlBJwdS2DTqi2xAfg/GmPr8Zsc gRm3xZo1TzUeI1gvVR+FU9HQPY71mIpMvmjXO1NGmji1ChoxFjSmsu8Fw8e5USVV f+QOFGgzvtauGFsiWEMQ9pPUiTRF9CVvkim4xlX7ee1u0hFlPAuO2stonOH3uz30 +ycVLq3qnD6r0cyyH5gTwai89Ay4Uqy931r6Z66y8gC8IrRRRir6R8q20OLoRKFy ffqLs5Jzrz1nyGOIA== Received: from mail.feld.me (mail.feld.me [66.170.3.6]); by mail.feld.me (OpenSMTPD) with ESMTP id ced9c831; Tue, 26 Aug 2014 15:01:17 -0500 (CDT) Received: from feld@feld.me by mail.feld.me (Archiveopteryx 3.2.0) with esmtpa id 1409083276-26245-26241/5/86; Tue, 26 Aug 2014 20:01:16 +0000 Mime-Version: 1.0 Date: Tue, 26 Aug 2014 20:01:15 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: RainLoop/1.6.8.153 From: Mark Felder Subject: Re: FreeBSD 10 and zfsd To: Alan Somers In-Reply-To: References: <5256B761.4050301@gmail.com> <1381421583.19140.32451849.084D8E32@webmail.messagingengine.com> <5256E2D5.4060101@allanjude.com> <1387388390.28188.61199633.413D38F8@webmail.messagingengine.com> <53A7CE1B.7090400@gmail.com> <8e598a07cf5bc8690749120295936c40@mail.feld.me> Sender: feld@feld.me Cc: Johan Hendriks , FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 20:01:20 -0000 August 26 2014 2:45 PM, "Alan Somers" wrote:=20 > On Tue, Aug 26, 2014 at 1:39 PM, Mark Felder wrote: >=20 >> August 26 2014 10:21 AM, "Alan Somers" wrote:=20 >>> Merged into the projects/zfsd/head branch by change 270604. Merging >>> to head is blocked by three issues: >>> a) The atf-ksh93 hack. The correct solution is to modify all the test >>> programs (not the test cases) so they can run under /bin/sh. That >>> will take some effort. >>=20 >> Can you provide a link to the atf-ksh93 code? >=20 > There's not much to it. It simply sets an environment variable and > calls atf-sh. What's more interesting is libtest.kshlib. In order to > eliminate atf-ksh93, we would need to modify libtest.kshlib to run > under /bin/sh. Alternatively, it may be easier to split > libtest.kshlib into two files: a small /bin/sh-compatible that can be > sourced by the ATF test programs, and a ksh93 script that only needs > to be sourced by the ATF test cases. >=20 > https://svnweb.freebsd.org/base/projects/zfsd/head/libexec/atf/atf-ksh9= 3/ > https://svnweb.freebsd.org/base/projects/zfsd/head/tests/sys/cddl/zfs/i= nclude/libtest.kshlib Depending on how complicated it is we might be able to coerce dteske = into checking it out. He could write an sh mastery book... I'm sure he = could assist with this. :-) From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 20:04:17 2014 Return-Path: Delivered-To: freebsd-current@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 39759A90; Tue, 26 Aug 2014 20:04:17 +0000 (UTC) Received: from mail.feld.me (mail.feld.me [66.170.3.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.feld.me", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C9B7A3784; Tue, 26 Aug 2014 20:04:16 +0000 (UTC) Received: from mail.feld.me (mail.feld.me [66.170.3.6]); by mail.feld.me (OpenSMTPD) with ESMTP id 648d1a6c; Tue, 26 Aug 2014 15:04:15 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=feld.me; h=mime-version :date:content-type:content-transfer-encoding:message-id:from :subject:to:cc:in-reply-to:references:sender; s=blargle2; bh=AjJ h9UKE6BVtpmPMPs8cQwDfcLs=; b=0382DS5aLACmJQRmjqOsvD/5VfUcTkqf1xQ CxsZo0LkQpEu7Kqo3V4ByNwhicfUkJkBnJz/qCTKZ6geZLXUSIraNqzFypf0+/RM u9XU4rP76lIVq537Z7e1GyqvOxK145fc1PQd/BtiFKPMnjh6cA955WGXUca70Cwt MaUf5QHwUbx2CD3Lb61V0LNBrYeVrwXVadgPMHoJo0ZoppQSKg/VC2dXKyCCrJC3 7qjzp+SW4i5zSFhEZu+23fKWHbhlxk5fYlhytYoKdDTXWm6XcVQ0n5CkoVDxa4xg pD2vuANoR7jegdJNgVVEEBymQvNmBTxEFkbCsdjOhb5FD5GDS+g== DomainKey-Signature: a=rsa-sha1; c=nofws; d=feld.me; h=mime-version:date :content-type:content-transfer-encoding:message-id:from:subject :to:cc:in-reply-to:references:sender; q=dns; s=blargle2; b=tZlVu AHNovKm3+4J/pM8VpxOvvQrwccOUICfYkkBfrVVv2u6+LzPpEq1yIiLzwyF8iO0m KwMJr55UCArsaPslo46mHc/Q04bP15BpSTk12PAN8acDzvmKokfpy5KnZdlnnvtY aUU66P2lwxa0I8hGBJgvNHiuxNkCDETbY1XcBNyU77fZgctIVB+mS4woIVHYSiEq 1pPXGokc9c9ju08/an5cbVrslNDcULaUurXwxBmXaqsfmcgTSio5Jewh/nvgt/ji 8/+V7nzZ6NflQf2qGIAHVTuYU2MKsY+IFxGfaJD8/P5g/IFHxC/ic6ML3sV/LYi6 SrXMosU//C4xHmCJA== Received: from mail.feld.me (mail.feld.me [66.170.3.6]); by mail.feld.me (OpenSMTPD) with ESMTP id 2246eeb3; Tue, 26 Aug 2014 15:04:15 -0500 (CDT) Received: from feld@feld.me by mail.feld.me (Archiveopteryx 3.2.0) with esmtpa id 1409083454-26244-26241/5/77; Tue, 26 Aug 2014 20:04:14 +0000 Mime-Version: 1.0 Date: Tue, 26 Aug 2014 20:04:14 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: RainLoop/1.6.8.153 From: Mark Felder Subject: Re: FreeBSD 10 and zfsd To: Garrett Cooper , Alan Somers In-Reply-To: <73E03261-8087-415A-BD04-EAADFF90C080@gmail.com> References: <73E03261-8087-415A-BD04-EAADFF90C080@gmail.com> <5256B761.4050301@gmail.com> <1381421583.19140.32451849.084D8E32@webmail.messagingengine.com> <5256E2D5.4060101@allanjude.com> <1387388390.28188.61199633.413D38F8@webmail.messagingengine.com> <53A7CE1B.7090400@gmail.com> <8e598a07cf5bc8690749120295936c40@mail.feld.me> Sender: feld@feld.me Cc: Johan Hendriks , FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 20:04:17 -0000 August 26 2014 2:49 PM, "Garrett Cooper" wrote:=20 > > Why not just require ksh93 from ports? >=20 Because zfsd is going to be in base, not in ports. Everything in base = needs to work without any ports requirements. Also ksh93 has been... = problematic. It has a history of breaking on i386, sparc64, current, = etc. It's not exactly a reliable dependency. From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 20:23:47 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3B6DF75 for ; Tue, 26 Aug 2014 20:23:47 +0000 (UTC) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id 9A7E83987 for ; Tue, 26 Aug 2014 20:23:47 +0000 (UTC) Received: by be-well.ilk.org (Postfix, from userid 1147) id 98FBA33C22; Tue, 26 Aug 2014 16:23:40 -0400 (EDT) From: Lowell Gilbert To: "Chris H" Subject: Re: did tar(1) loose xz compression support in 11? References: <53FCD7B8.5060300@wemm.org> Date: Tue, 26 Aug 2014 16:23:40 -0400 In-Reply-To: (Chris H.'s message of "Tue, 26 Aug 2014 12:28:13 -0700 (PDT)") Message-ID: <44sikjvw37.fsf@be-well.ilk.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-current@freebsd.org, Peter Wemm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 20:23:47 -0000 "Chris H" writes: >> On 8/26/14 11:05 AM, Chris H wrote: >>> Greetings, >>> I'm currently testing 11. My build / install is from about 2 days ago. >>> I generally use xz compression, when creating archives. But when I >>> attempt the following: >>> >>> tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file >>> >>> it returns the following: >>> >>> tar: Undefined option: `xz:9' >>> >>> This has always worked in previous versions. Has the syntax changed, >>> and the man(1) pages just haven't caught up? >> >> I use: >> tar -cJ --options xz:compression-level=1 >> .. on head. Are you using the right syntax? > Apparently not. Using your example works as expected. > RELENG_8, and RELENG_9 use short-hand; > tar -cvJ --options xz:9 > > Why/when the change to long-hand? Seems a shame. Now I > get to modify all my scripts, and such. :P Altho I > don't suppose it'd be a big deal to back out (revert) the > changes made to tar(1). :) I can't find any changes that would make the syntax change. At least, not in quite a long while. Therefore, this change may not be intentional. However, I looked at the the manual page from 9.3, and its description of the features looks the same as on the latest HEAD, and *doesn't* look like leaving out a "key" (in this case, "compression-level") is ever compliant. You might try the latest (or older) libarchive from the ports, and compare its behaviour. Also, there are a number (amusingly many, in fact) of other ways of specifying these parameters that may be more convenient for you, so another look throught the tar(1) manual might save you a few minutes. Good luck. From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 20:51:31 2014 Return-Path: Delivered-To: freebsd-current@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 390B7C8A; Tue, 26 Aug 2014 20:51:31 +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 728D63BDB; Tue, 26 Aug 2014 20:51:30 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id bs8so4797551wib.2 for ; Tue, 26 Aug 2014 13:51:28 -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=mbXN0NPlb8ZtJwUCrWXjIOdjrtvEcRpPQ0km1JM+BMM=; b=T7ldodnj4tyjgzcmS/jr4+vOREaJQZpJ9B3AbX8kZ0TH5pn9bFM29eJLsNTkqgUeGQ JJorsR5mLhopoHYbPrUqXemtIGa8V6SpPqpmXNjW5NPjt3hp+WhWk2C8DilZKzu1oLoB jhxFRBHYmkKt0yFEp4WUir8IRov6u90a6loDc4qpbNHLAnObVcHw/43WGxwC1CDFGeN+ ZJc9VXgph/Dk+MsAIlLlsEqM5A7NUoyjjRwNZ3xXCf0rgxhwuQETNV9MgWK0wZuxufzG jLG4z996/ypyOnDnY8BwEWjYRi0Lke8nSJ8gq6imRBYJ0ohUYCBzlzmPft57XcYtik+z xOqw== MIME-Version: 1.0 X-Received: by 10.180.14.2 with SMTP id l2mr24451416wic.50.1409086288665; Tue, 26 Aug 2014 13:51:28 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.194.126.1 with HTTP; Tue, 26 Aug 2014 13:51:28 -0700 (PDT) In-Reply-To: <73E03261-8087-415A-BD04-EAADFF90C080@gmail.com> References: <5256B761.4050301@gmail.com> <1381421583.19140.32451849.084D8E32@webmail.messagingengine.com> <5256E2D5.4060101@allanjude.com> <1387388390.28188.61199633.413D38F8@webmail.messagingengine.com> <53A7CE1B.7090400@gmail.com> <8e598a07cf5bc8690749120295936c40@mail.feld.me> <73E03261-8087-415A-BD04-EAADFF90C080@gmail.com> Date: Tue, 26 Aug 2014 14:51:28 -0600 X-Google-Sender-Auth: wDVnq66r5QNxJiMzyRbxBesHe44 Message-ID: Subject: Re: FreeBSD 10 and zfsd From: Alan Somers To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Cc: Johan Hendriks , FreeBSD CURRENT , Alan Somers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 20:51:31 -0000 On Tue, Aug 26, 2014 at 1:48 PM, Garrett Cooper wrote: > >> On Aug 26, 2014, at 12:45, Alan Somers wrote: >> >>> On Tue, Aug 26, 2014 at 1:39 PM, Mark Felder wrote: >>> August 26 2014 10:21 AM, "Alan Somers" wrote: >>>> >>>> Merged into the projects/zfsd/head branch by change 270604. Merging >>>> to head is blocked by three issues: >>>> a) The atf-ksh93 hack. The correct solution is to modify all the test >>>> programs (not the test cases) so they can run under /bin/sh. That >>>> will take some effort. >>> >>> Can you provide a link to the atf-ksh93 code? >> >> There's not much to it. It simply sets an environment variable and >> calls atf-sh. What's more interesting is libtest.kshlib. In order to >> eliminate atf-ksh93, we would need to modify libtest.kshlib to run >> under /bin/sh. Alternatively, it may be easier to split >> libtest.kshlib into two files: a small /bin/sh-compatible that can be >> sourced by the ATF test programs, and a ksh93 script that only needs >> to be sourced by the ATF test cases. > > I'm working on integrating the dtrace testcases into kyua, then atf under Kyua as time permits, but I'm not rewriting the core test code (yet), because I want to reduce divergence with upstream. > > Why not just require ksh93 from ports? It's not that simple. It's certainly possible to put a "require.progs ksh93" in the test case header. But you also need to use ksh93 features before invoking the test case script. For example, see zpool_upgrade_004_pos_body in tests/sys/cddl/zfs/tests/cli_root/zpool_upgrade/zpool_upgrade_test.sh . Notice how it sources some .kshlib scripts, then checks the $KEEP variable. Other tests do similar things. Perhaps they could be fixed by wrapping those lines in a here document that gets fed to ksh93. But that's very ugly. I'd rather fix all the tests to not require ksh93 before invoking the separate test case script. If you change the interpreter script from atf-ksh93 to atf-sh, you'll see errors like this: # kyua debug zfsd_test:zfsd_import_001_pos set: Illegal option -A set: Illegal option -A zfsd_test:zfsd_import_001_pos -> broken: Premature exit; test case exited with code 2 -Alan From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 21:22:27 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD769D6E; Tue, 26 Aug 2014 21:22:26 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B51013FA9; Tue, 26 Aug 2014 21:22:25 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id ho1so4830465wib.4 for ; Tue, 26 Aug 2014 14:22:24 -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:content-transfer-encoding; bh=fEdO38MZwrU+pMfm4QOGZL2b8o5RfvgS8MFkZRVCmxA=; b=g3XqtREEh3x/an2SIwXIuga94t79I/zhc+6wDMT0z0y4fPx8adP0yqSwMDh5AfMrPN OeI/iT8AVeND07bc63+IeqSxeXm8cxRGoa7QuYWbl8X8PsyP+5nnb+AVU7jj/bwfM5Wo Zu541TiEHsl0nj22bDlC6wSBmaTbuCdHrdlIILI/ZJzunnrc+atWvwVD2L2R6+fzzhTv s40+Ma6f+Is7xN1VPDe0bjQ4h/IXdhP5/l7Vqr22JZpYwh0vEe/CYm3lKMXlY2oGAI2d GAaEROfmCoLBVLJ0ZurvZyVrNsPHEhm47om8rlFr++NWsAndSqNncqfgJvnGIfVouwYw lEuw== MIME-Version: 1.0 X-Received: by 10.180.189.195 with SMTP id gk3mr8849488wic.82.1409088143887; Tue, 26 Aug 2014 14:22:23 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.194.126.1 with HTTP; Tue, 26 Aug 2014 14:22:23 -0700 (PDT) In-Reply-To: <20140826195140.GA10143@charmander.home> References: <522300E3.6050303@rawbw.com> <2204059.7tqSNWvxzC@ralph.baldwin.cx> <201408261515.32146.jhb@freebsd.org> <20140826195140.GA10143@charmander.home> Date: Tue, 26 Aug 2014 15:22:23 -0600 X-Google-Sender-Auth: fVlBnlL5R2Oy1gKYHY9bbsfFbWc Message-ID: Subject: Re: [PATCH] Packet loss when 'control' messages are present with large data (sendmsg(2)) From: Alan Somers To: Mark Johnston Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org, Alan Somers , Harald Schmalzbauer , FreeBSD CURRENT , "net@freebsd.org" , Yuri X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 21:22:27 -0000 On Tue, Aug 26, 2014 at 1:51 PM, Mark Johnston wrote: > On Tue, Aug 26, 2014 at 03:15:31PM -0400, John Baldwin wrote: >> On Tuesday, August 26, 2014 11:05:12 am Alan Somers wrote: >> > On Mon, Aug 25, 2014 at 1:52 PM, John Baldwin wrote: >> > > On Friday, August 22, 2014 01:34:28 PM Harald Schmalzbauer wrote: >> > >> Bez=C3=BCglich Yuri's Nachricht vom 02.09.2013 06:54 (localtime): >> > >> > Please check in this patch: >> > >> > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D181741 >> > >> > Please MFC into 9.X >> > >> > >> > >> > Description of the problem is within PR. >> > >> > >> > >> > Thanks, >> > >> > Yuri >> > >> >> > >> Hello, >> > >> >> > >> I guess this fix should make it into 10.1. >> > >> Can someone check please? >> > > >> > > A fix has to make into HEAD first. I've cc'd Alan who responded to = the bug. >> > > Alan, note that glebius@ already committed the test case to HEAD a w= hile ago. >> > >> > First, Gleb's testcase needs to be converted to ATF. This would be a >> > good exercise for anybody who's new to ATF and wants some practice. >> > Anybody interested? >> >> While that would be nice, I don't know that it's quite fair to require t= he >> test to be converted before working on a possible fix. The existing tes= t >> doesn't seem that hard to run by hand: >> >> % cd work/freebsd/head/tools/regression/sockets/unix_passfd/ >> % make >> ... >> % > ./unix_passfd >> beginning test1-simplesendfd >> test1-simplesendfd passed >> ... >> beginning test8-rigths+creds+payload >> unix_passfd: test8-rigths+creds+payload: recvmsg: 24 bytes received >> >> I only say this because in the bug followup you seemed to have described= a >> possible solution so it seems that you would be able to develop a fix qu= icker >> than other folks since you are already familiar with the issues involved= . >> (Also, you've fixed other related issues recently.) > > As it happens, I went ahead and did this anyway: > https://reviews.freebsd.org/D689 BTW, is it just me, or is arcanist insanely slow? Usually "arc diff --create" or "arc diff --update" take many minutes to complete. Like, 30 minutes. I've been trying to do "arc patch" for nearly an hour now, but it hasn't completed yet. From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 21:24:02 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BBAB1F53 for ; Tue, 26 Aug 2014 21:24:02 +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 8CC973FDB for ; Tue, 26 Aug 2014 21:24:02 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 73BD7B94C; Tue, 26 Aug 2014 17:24:01 -0400 (EDT) From: John Baldwin To: "Poul-Henning Kamp" Subject: Re: gbde destroy doesn't match man page? Date: Tue, 26 Aug 2014 17:23:53 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <20140820215522.GA92455@bewilderbeast.blackhelicopters.org> <2945485.ZemF81RAkB@ralph.baldwin.cx> <98222.1409034192@critter.freebsd.dk> In-Reply-To: <98222.1409034192@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201408261723.53428.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 26 Aug 2014 17:24:01 -0400 (EDT) Cc: current@freebsd.org, "Michael W. Lucas" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 21:24:02 -0000 On Tuesday, August 26, 2014 2:23:12 am Poul-Henning Kamp wrote: > -------- > In message <2945485.ZemF81RAkB@ralph.baldwin.cx>, John Baldwin writes: > >On Saturday, August 23, 2014 10:16:42 AM Poul-Henning Kamp wrote: > >> -------- > >> In message <20140820215522.GA92455@bewilderbeast.blackhelicopters.org>, > >> "Michae > >> l W. Lucas" writes: > >> >Playing with GBDE for my FreeBSD disk book, on: > >> > > >> ># uname -a > >> >FreeBSD storm 11.0-CURRENT FreeBSD 11.0-CURRENT #6 r269010: Wed Jul 23 > >> >11:13:17 EDT 2014 mwlucas@storm:/usr/obj/usr/src/sys/GENERIC amd64 > >> > > >> >According to the man page, I should be able to destroy all copies of > >> >the key with gbde destroy -n -1. It's in the examples. When I > >> > >> >try it I get: > >> I think that is an oversight in the code. > > > >Can you expand on this? I.e. what should the code do if it is fixed? > > Hmm, now that I think about it, -n doesn't make sense because any > one of the four keys can open the volume as needed to blow away the > masterkey. > > The manual page should just be fixed. Should the '-n -1' just be removed? I.e., is 'gbde destroy' sufficient to destroy all copies of the key? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 21:29:05 2014 Return-Path: Delivered-To: freebsd-current@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 E709E53A; Tue, 26 Aug 2014 21:29:04 +0000 (UTC) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 966193026; Tue, 26 Aug 2014 21:29:04 +0000 (UTC) Received: by mail-ig0-f174.google.com with SMTP id c1so5230083igq.13 for ; Tue, 26 Aug 2014 14:29:03 -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=xtO341yYlyZslLfxsof+iC/f1vZJneSXNqRbVMXZC3E=; b=QgWHwAYRWz+o9UXMCFzPXJjNY5U317mKvzgElgH5PbQCNennuRBirtJGfTZqqa8lCH YvVeAYpxGIcI1O4G2ILS/GV/93KrHPCrz5idT0xI5Pl5hCYDIkBUnWYrgn/BXzqP47g9 9UKomwwFFFkxIJIBDg2yPARaV0APqHpbBUTmxUFHsFwBn2PIRAj9KBoXGCDHBp6bHJAZ IXEEWvX2FcM6bb6y+I7wG4ROAtfw9imKfVKxud/ZU/76c/WMjy2ZydlA+R5s/vYIuPMS vimf81hQLhacUboMfHzhjSDjdi84geJWO5js+c9uXs6VXF5ec/get5MN0WPo2/hbcdVN oEXQ== MIME-Version: 1.0 X-Received: by 10.50.32.10 with SMTP id e10mr25477298igi.7.1409088543461; Tue, 26 Aug 2014 14:29:03 -0700 (PDT) Received: by 10.50.72.69 with HTTP; Tue, 26 Aug 2014 14:29:03 -0700 (PDT) In-Reply-To: References: <5256B761.4050301@gmail.com> <1381421583.19140.32451849.084D8E32@webmail.messagingengine.com> <5256E2D5.4060101@allanjude.com> <1387388390.28188.61199633.413D38F8@webmail.messagingengine.com> <53A7CE1B.7090400@gmail.com> <8e598a07cf5bc8690749120295936c40@mail.feld.me> <73E03261-8087-415A-BD04-EAADFF90C080@gmail.com> Date: Tue, 26 Aug 2014 14:29:03 -0700 Message-ID: Subject: Re: FreeBSD 10 and zfsd From: Garrett Cooper To: Mark Felder Content-Type: text/plain; charset=UTF-8 Cc: Johan Hendriks , FreeBSD CURRENT , Alan Somers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 21:29:05 -0000 On Tue, Aug 26, 2014 at 1:04 PM, Mark Felder wrote: > August 26 2014 2:49 PM, "Garrett Cooper" wrote: >> >> Why not just require ksh93 from ports? > > Because zfsd is going to be in base, not in ports. Everything in base needs to work without any ports requirements. We have tests in base that require perl, and kyua itself comes from ports. Granted it's not ideal, but it works and it gives developers and test infrastructure people more flexibility with software instead of having to key it into a particular version in the base system. > Also ksh93 has been... problematic. It has a history of breaking on i386, sparc64, current, etc. It's not exactly a reliable dependency. That's really unfortunate :(. If you have bug reports it'll provide ammunition for why this should be converted over to something more portable when I'm contributing patches back to IllumOS. I really didn't want to do it because the process for contributing back to IllumOS is so heavyweight, but reliability when running the tests is a must. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 21:32:54 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 979FF6AE; Tue, 26 Aug 2014 21:32:54 +0000 (UTC) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3C2F930DD; Tue, 26 Aug 2014 21:32:54 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id at20so11754740iec.8 for ; Tue, 26 Aug 2014 14:32: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:date:message-id:subject:from:to :cc:content-type; bh=QccBbx1DmrCoHb3KCg/QwMMNFHkK6hfW1lpNd6ZuO+c=; b=QeUCar1GlbXOsCc97VvoiKsW/GSGnQI7vOhinkRyJOmvYYUJOYoyf2rs2oTD05RG5X 3LLojCpXFN7yw/akW3ZVoVKI5lDsKeYpyIwmmovKtGNash2TOHbKZLbsGCQhTKReWyVj sgPbP2wKk6ZUBTNE2IqT3Px7ngip/Nc1QIocUtkW1NXA6fGKQi+0gngowHDoRNT62WbF qQKMseistg4o7r1u+os5qQvVmZrl+PqXYXzDf01icLBv/fiFEV/GPAnTrWjza30z+Exd DCeJjpt6GcO/W3+hZG9+uAD7SVQ516Pn5DcYBiPRMl1fzUr/44PP6vMDFKk96oRNT1Ir qOqg== MIME-Version: 1.0 X-Received: by 10.50.80.45 with SMTP id o13mr25488884igx.7.1409088773581; Tue, 26 Aug 2014 14:32:53 -0700 (PDT) Received: by 10.50.72.69 with HTTP; Tue, 26 Aug 2014 14:32:53 -0700 (PDT) In-Reply-To: References: <5256B761.4050301@gmail.com> <1381421583.19140.32451849.084D8E32@webmail.messagingengine.com> <5256E2D5.4060101@allanjude.com> <1387388390.28188.61199633.413D38F8@webmail.messagingengine.com> <53A7CE1B.7090400@gmail.com> <8e598a07cf5bc8690749120295936c40@mail.feld.me> <73E03261-8087-415A-BD04-EAADFF90C080@gmail.com> Date: Tue, 26 Aug 2014 14:32:53 -0700 Message-ID: Subject: Re: FreeBSD 10 and zfsd From: Garrett Cooper To: Alan Somers Content-Type: text/plain; charset=UTF-8 Cc: Johan Hendriks , Julio Merino , FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 21:32:54 -0000 On Tue, Aug 26, 2014 at 1:51 PM, Alan Somers wrote: > On Tue, Aug 26, 2014 at 1:48 PM, Garrett Cooper wrote: >> >>> On Aug 26, 2014, at 12:45, Alan Somers wrote: >>> >>>> On Tue, Aug 26, 2014 at 1:39 PM, Mark Felder wrote: >>>> August 26 2014 10:21 AM, "Alan Somers" wrote: >>>>> >>>>> Merged into the projects/zfsd/head branch by change 270604. Merging >>>>> to head is blocked by three issues: >>>>> a) The atf-ksh93 hack. The correct solution is to modify all the test >>>>> programs (not the test cases) so they can run under /bin/sh. That >>>>> will take some effort. >>>> >>>> Can you provide a link to the atf-ksh93 code? >>> >>> There's not much to it. It simply sets an environment variable and >>> calls atf-sh. What's more interesting is libtest.kshlib. In order to >>> eliminate atf-ksh93, we would need to modify libtest.kshlib to run >>> under /bin/sh. Alternatively, it may be easier to split >>> libtest.kshlib into two files: a small /bin/sh-compatible that can be >>> sourced by the ATF test programs, and a ksh93 script that only needs >>> to be sourced by the ATF test cases. >> >> I'm working on integrating the dtrace testcases into kyua, then atf under Kyua as time permits, but I'm not rewriting the core test code (yet), because I want to reduce divergence with upstream. >> >> Why not just require ksh93 from ports? > > It's not that simple. It's certainly possible to put a "require.progs > ksh93" in the test case header. But you also need to use ksh93 > features before invoking the test case script. For example, see > zpool_upgrade_004_pos_body in > tests/sys/cddl/zfs/tests/cli_root/zpool_upgrade/zpool_upgrade_test.sh > . Notice how it sources some .kshlib scripts, then checks the $KEEP > variable. Other tests do similar things. Perhaps they could be fixed > by wrapping those lines in a here document that gets fed to ksh93. > But that's very ugly. I'd rather fix all the tests to not require > ksh93 before invoking the separate test case script. > > If you change the interpreter script from atf-ksh93 to atf-sh, you'll > see errors like this: > > # kyua debug zfsd_test:zfsd_import_001_pos > set: Illegal option -A > set: Illegal option -A > zfsd_test:zfsd_import_001_pos -> broken: Premature exit; test case > exited with code 2 This should be plugged into kyua-testers though instead of hacking around ATF -- even if it's mostly a thin layer on top of the ATF tester; we should work towards a common goal with the DTrace/ZFS testing though because they sort of follow the same design patterns. My mentor jmmv@ might have valuable input to provide here in what should be done (I've CCed him). Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 21:34:34 2014 Return-Path: Delivered-To: freebsd-current@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 090A97CC; Tue, 26 Aug 2014 21:34:34 +0000 (UTC) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C233830F3; Tue, 26 Aug 2014 21:34:33 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id rd18so11933805iec.23 for ; Tue, 26 Aug 2014 14:34:33 -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=abt78GHsdhE9jF2GphYVnSMXtR+sE9nlisRmpvpiUxs=; b=dZAzDy/yVkacUNoZUbtY+OyLMdHpn9+V4N4qAG3Q3yQp9GkBheIoTTq1q9n2GR6wto nZTz+7EfaGVQbDFGOsqGR4Va9ETpt8rj8tgDqrBHxtbOhvKzYcunyox/GyVPPw+VCMz3 3iutSBSIDGUQxgF4ew7LdWDw4T1EGRIIRHCoHYtq+gLcLM92STx3eOb8FScYTNMNyFhG +uUuGL2qc9/Rj2JXF+Ok77sUCoMtAoXWgEjmizFy8aW2xWSMwS9+nno8rG+cttvRiOKq 6RVH6wh6mkBiOvdjwYljEay7Co6t3DBTBZaZYvERMSo8H0Wi2WJi8cdAHjiaz5rxNM0w YPaQ== MIME-Version: 1.0 X-Received: by 10.42.207.68 with SMTP id fx4mr10061292icb.67.1409088873223; Tue, 26 Aug 2014 14:34:33 -0700 (PDT) Received: by 10.50.72.69 with HTTP; Tue, 26 Aug 2014 14:34:33 -0700 (PDT) In-Reply-To: <44sikjvw37.fsf@be-well.ilk.org> References: <53FCD7B8.5060300@wemm.org> <44sikjvw37.fsf@be-well.ilk.org> Date: Tue, 26 Aug 2014 14:34:33 -0700 Message-ID: Subject: Re: did tar(1) loose xz compression support in 11? From: Garrett Cooper To: Lowell Gilbert Content-Type: text/plain; charset=UTF-8 Cc: kientzle@freebsd.org, FreeBSD Current , Peter Wemm , Chris H X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 21:34:34 -0000 On Tue, Aug 26, 2014 at 1:23 PM, Lowell Gilbert wrote: > "Chris H" writes: > >>> On 8/26/14 11:05 AM, Chris H wrote: >>>> Greetings, >>>> I'm currently testing 11. My build / install is from about 2 days ago. >>>> I generally use xz compression, when creating archives. But when I >>>> attempt the following: >>>> >>>> tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file >>>> >>>> it returns the following: >>>> >>>> tar: Undefined option: `xz:9' >>>> >>>> This has always worked in previous versions. Has the syntax changed, >>>> and the man(1) pages just haven't caught up? >>> >>> I use: >>> tar -cJ --options xz:compression-level=1 >>> .. on head. Are you using the right syntax? >> Apparently not. Using your example works as expected. >> RELENG_8, and RELENG_9 use short-hand; >> tar -cvJ --options xz:9 >> >> Why/when the change to long-hand? Seems a shame. Now I >> get to modify all my scripts, and such. :P Altho I >> don't suppose it'd be a big deal to back out (revert) the >> changes made to tar(1). :) > > I can't find any changes that would make the syntax change. At least, > not in quite a long while. Therefore, this change may not be > intentional. However, I looked at the the manual page from 9.3, and its > description of the features looks the same as on the latest HEAD, and > *doesn't* look like leaving out a "key" (in this case, > "compression-level") is ever compliant. > > You might try the latest (or older) libarchive from the ports, and > compare its behaviour. Also, there are a number (amusingly many, in > fact) of other ways of specifying these parameters that may be more > convenient for you, so another look throught the tar(1) manual might > save you a few minutes. > > Good luck. I've CCed kientzle@ for input. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 21:43:22 2014 Return-Path: Delivered-To: freebsd-current@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 3371AC1B; Tue, 26 Aug 2014 21:43:22 +0000 (UTC) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 042163248; Tue, 26 Aug 2014 21:43:20 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id l18so14894332wgh.1 for ; Tue, 26 Aug 2014 14:43:19 -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=rpQwY8SC6sgiBDuUNk7iu8fscLdTepdERe0PKJ81kFY=; b=jVKOo2NvwOzdE8bG20pMOC5hy6+YqOWAPd9NVrDQvp7G0WpafjmTs2Glkxu7DsHMAG HubL50fqhOhJJGJ/IcgkuRj5mU63yNKAZ+PAQ2lk+lfb/IHP1XTuVzi2JfQbNk+jhi6W 9j6iTUZRmcQKBxFSpH3TRDsYrpCGw+1C3R5sNI9Q4RwycpJfBSj191VXUsUXL+rcBzua yYzM0afZlfBDCNSo3ZJufrmCzI/03u3J5m42uRPwotG5YJacaX7ZQUIzmTYGt2Q/B6DB VtG0lFOSJ6ECmrjqNiSoVxu0lG42sG7CRsPzxfDTepDANqZ56wG3NvyUHiZ8jjN4dNZI CuJA== MIME-Version: 1.0 X-Received: by 10.180.14.74 with SMTP id n10mr19793266wic.50.1409089399138; Tue, 26 Aug 2014 14:43:19 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.194.126.1 with HTTP; Tue, 26 Aug 2014 14:43:19 -0700 (PDT) In-Reply-To: References: <5256B761.4050301@gmail.com> <1381421583.19140.32451849.084D8E32@webmail.messagingengine.com> <5256E2D5.4060101@allanjude.com> <1387388390.28188.61199633.413D38F8@webmail.messagingengine.com> <53A7CE1B.7090400@gmail.com> <8e598a07cf5bc8690749120295936c40@mail.feld.me> <73E03261-8087-415A-BD04-EAADFF90C080@gmail.com> Date: Tue, 26 Aug 2014 15:43:19 -0600 X-Google-Sender-Auth: qepXNefodEErOgQeTrG4yx3KZ88 Message-ID: Subject: Re: FreeBSD 10 and zfsd From: Alan Somers To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Cc: Johan Hendriks , Julio Merino , FreeBSD CURRENT , Alan Somers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 21:43:22 -0000 On Tue, Aug 26, 2014 at 3:32 PM, Garrett Cooper wrote: > On Tue, Aug 26, 2014 at 1:51 PM, Alan Somers wrote: >> On Tue, Aug 26, 2014 at 1:48 PM, Garrett Cooper wrote: >>> >>>> On Aug 26, 2014, at 12:45, Alan Somers wrote: >>>> >>>>> On Tue, Aug 26, 2014 at 1:39 PM, Mark Felder wrote: >>>>> August 26 2014 10:21 AM, "Alan Somers" wrote: >>>>>> >>>>>> Merged into the projects/zfsd/head branch by change 270604. Merging >>>>>> to head is blocked by three issues: >>>>>> a) The atf-ksh93 hack. The correct solution is to modify all the test >>>>>> programs (not the test cases) so they can run under /bin/sh. That >>>>>> will take some effort. >>>>> >>>>> Can you provide a link to the atf-ksh93 code? >>>> >>>> There's not much to it. It simply sets an environment variable and >>>> calls atf-sh. What's more interesting is libtest.kshlib. In order to >>>> eliminate atf-ksh93, we would need to modify libtest.kshlib to run >>>> under /bin/sh. Alternatively, it may be easier to split >>>> libtest.kshlib into two files: a small /bin/sh-compatible that can be >>>> sourced by the ATF test programs, and a ksh93 script that only needs >>>> to be sourced by the ATF test cases. >>> >>> I'm working on integrating the dtrace testcases into kyua, then atf under Kyua as time permits, but I'm not rewriting the core test code (yet), because I want to reduce divergence with upstream. >>> >>> Why not just require ksh93 from ports? >> >> It's not that simple. It's certainly possible to put a "require.progs >> ksh93" in the test case header. But you also need to use ksh93 >> features before invoking the test case script. For example, see >> zpool_upgrade_004_pos_body in >> tests/sys/cddl/zfs/tests/cli_root/zpool_upgrade/zpool_upgrade_test.sh >> . Notice how it sources some .kshlib scripts, then checks the $KEEP >> variable. Other tests do similar things. Perhaps they could be fixed >> by wrapping those lines in a here document that gets fed to ksh93. >> But that's very ugly. I'd rather fix all the tests to not require >> ksh93 before invoking the separate test case script. >> >> If you change the interpreter script from atf-ksh93 to atf-sh, you'll >> see errors like this: >> >> # kyua debug zfsd_test:zfsd_import_001_pos >> set: Illegal option -A >> set: Illegal option -A >> zfsd_test:zfsd_import_001_pos -> broken: Premature exit; test case >> exited with code 2 > > This should be plugged into kyua-testers though instead of hacking > around ATF -- even if it's mostly a thin layer on top of the ATF > tester; we should work towards a common goal with the DTrace/ZFS > testing though because they sort of follow the same design patterns. > My mentor jmmv@ might have valuable input to provide here in what > should be done (I've CCed him). Adding a ksh93 tester to Kyua was previously discussed on kyua-discuss. But it was basically shot down. https://groups.google.com/forum/#!topic/kyua-discuss/w8oJHeZXuro Porting, in whole or in part, the tests to /bin/sh is time consuming, but it's the only option that satisfies everyone. -Alan From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 21:50:13 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03BF4F16; Tue, 26 Aug 2014 21:50:13 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id BD20232C2; Tue, 26 Aug 2014 21:50:12 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id 8A90F1598; Tue, 26 Aug 2014 21:50:10 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id s7QLo9G7077642; Tue, 26 Aug 2014 21:50:09 GMT (envelope-from phk@phk.freebsd.dk) To: John Baldwin Subject: Re: gbde destroy doesn't match man page? In-reply-to: <201408261723.53428.jhb@freebsd.org> From: "Poul-Henning Kamp" References: <20140820215522.GA92455@bewilderbeast.blackhelicopters.org> <2945485.ZemF81RAkB@ralph.baldwin.cx> <98222.1409034192@critter.freebsd.dk> <201408261723.53428.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <77640.1409089809.1@critter.freebsd.dk> Date: Tue, 26 Aug 2014 21:50:09 +0000 Message-ID: <77641.1409089809@critter.freebsd.dk> Cc: current@freebsd.org, "Michael W. Lucas" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 21:50:13 -0000 -------- In message <201408261723.53428.jhb@freebsd.org>, John Baldwin writes: >> Hmm, now that I think about it, -n doesn't make sense because any >> one of the four keys can open the volume as needed to blow away the >> masterkey. >> >> The manual page should just be fixed. > >Should the '-n -1' just be removed? I.e., is 'gbde destroy' sufficient to >destroy all copies of the key? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 21:51:31 2014 Return-Path: Delivered-To: current@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 089DDC4; Tue, 26 Aug 2014 21:51:31 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id C028232F3; Tue, 26 Aug 2014 21:51:30 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id DB5101598; Tue, 26 Aug 2014 21:51:29 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id s7QLpTW4078351; Tue, 26 Aug 2014 21:51:29 GMT (envelope-from phk@phk.freebsd.dk) To: John Baldwin Subject: Re: gbde destroy doesn't match man page? In-reply-to: <201408261723.53428.jhb@freebsd.org> From: "Poul-Henning Kamp" References: <20140820215522.GA92455@bewilderbeast.blackhelicopters.org> <2945485.ZemF81RAkB@ralph.baldwin.cx> <98222.1409034192@critter.freebsd.dk> <201408261723.53428.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <78348.1409089889.1@critter.freebsd.dk> Date: Tue, 26 Aug 2014 21:51:29 +0000 Message-ID: <78350.1409089889@critter.freebsd.dk> Cc: current@freebsd.org, "Michael W. Lucas" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 21:51:31 -0000 -------- In message <201408261723.53428.jhb@freebsd.org>, John Baldwin writes: >> Hmm, now that I think about it, -n doesn't make sense because any >> one of the four keys can open the volume as needed to blow away the >> masterkey. >> >> The manual page should just be fixed. > >Should the '-n -1' just be removed? I.e., is 'gbde destroy' sufficient to >destroy all copies of the key? (Sorry about previous empty reply) Yes, the -n isn't needed because it doesn't operate on any specific key but all of them. This differs from for instance "setkey" where you may use key number 1 to set a new key number 2. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 22:03:14 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9EAD24B5; Tue, 26 Aug 2014 22:03:14 +0000 (UTC) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::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 17C633482; Tue, 26 Aug 2014 22:03:14 +0000 (UTC) Received: by mail-qg0-f51.google.com with SMTP id a108so15220434qge.24 for ; Tue, 26 Aug 2014 15:03:13 -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:content-transfer-encoding; bh=r7GNVE8+CU3KtymSMVU1PdD982QLI1aKk4YLXMW0y2s=; b=iTx0P2DMFy0iYGbe9AEKCJqIGLWg6T3yxgbcZsDdA2nOnDTYcaomC4kCmHk9ynI7te 4zcCrS0Nj7EfTW/mVSrJVRcgQYeWz5ovyVazb9YnLKkWZXXzuwUnnr1GKsjFAJSuGs+R psVQgfurrXGUuX8QAAk22Kew70ZozTjEthoag8GUwENsHUiLCsJGyMmJf5GLHcg3iN/J pwU5H8J8wsKnO432eBro7h3DbIc/fz8qaE3PRVRdoDCSO8+7VijLoClgJBn7RnEdWJYw ErHw0rZMnCW08qYsFi/JuweZADTryzD1BF8lm/xzsT/yzkrHIQru8K98qImtiz8zXxDk Q9sA== MIME-Version: 1.0 X-Received: by 10.140.104.69 with SMTP id z63mr47369058qge.81.1409090593077; Tue, 26 Aug 2014 15:03:13 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.39.139 with HTTP; Tue, 26 Aug 2014 15:03:13 -0700 (PDT) In-Reply-To: References: <522300E3.6050303@rawbw.com> <2204059.7tqSNWvxzC@ralph.baldwin.cx> <201408261515.32146.jhb@freebsd.org> <20140826195140.GA10143@charmander.home> Date: Tue, 26 Aug 2014 15:03:13 -0700 X-Google-Sender-Auth: QYvLrrihXfauvkSGn4N4BOZ88Ho Message-ID: Subject: Re: [PATCH] Packet loss when 'control' messages are present with large data (sendmsg(2)) From: Adrian Chadd To: Alan Somers Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "current@freebsd.org" , FreeBSD CURRENT , Harald Schmalzbauer , Mark Johnston , "net@freebsd.org" , Yuri X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 22:03:14 -0000 On 26 August 2014 14:22, Alan Somers wrote: > On Tue, Aug 26, 2014 at 1:51 PM, Mark Johnston wrote: >> On Tue, Aug 26, 2014 at 03:15:31PM -0400, John Baldwin wrote: >>> On Tuesday, August 26, 2014 11:05:12 am Alan Somers wrote: >>> > On Mon, Aug 25, 2014 at 1:52 PM, John Baldwin wrote= : >>> > > On Friday, August 22, 2014 01:34:28 PM Harald Schmalzbauer wrote: >>> > >> Bez=C3=BCglich Yuri's Nachricht vom 02.09.2013 06:54 (localtime): >>> > >> > Please check in this patch: >>> > >> > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D181741 >>> > >> > Please MFC into 9.X >>> > >> > >>> > >> > Description of the problem is within PR. >>> > >> > >>> > >> > Thanks, >>> > >> > Yuri >>> > >> >>> > >> Hello, >>> > >> >>> > >> I guess this fix should make it into 10.1. >>> > >> Can someone check please? >>> > > >>> > > A fix has to make into HEAD first. I've cc'd Alan who responded to= the bug. >>> > > Alan, note that glebius@ already committed the test case to HEAD a = while ago. >>> > >>> > First, Gleb's testcase needs to be converted to ATF. This would be a >>> > good exercise for anybody who's new to ATF and wants some practice. >>> > Anybody interested? >>> >>> While that would be nice, I don't know that it's quite fair to require = the >>> test to be converted before working on a possible fix. The existing te= st >>> doesn't seem that hard to run by hand: >>> >>> % cd work/freebsd/head/tools/regression/sockets/unix_passfd/ >>> % make >>> ... >>> % > ./unix_passfd >>> beginning test1-simplesendfd >>> test1-simplesendfd passed >>> ... >>> beginning test8-rigths+creds+payload >>> unix_passfd: test8-rigths+creds+payload: recvmsg: 24 bytes received >>> >>> I only say this because in the bug followup you seemed to have describe= d a >>> possible solution so it seems that you would be able to develop a fix q= uicker >>> than other folks since you are already familiar with the issues involve= d. >>> (Also, you've fixed other related issues recently.) >> >> As it happens, I went ahead and did this anyway: >> https://reviews.freebsd.org/D689 > > BTW, is it just me, or is arcanist insanely slow? Usually "arc diff > --create" or "arc diff --update" take many minutes to complete. Like, > 30 minutes. I've been trying to do "arc patch" for nearly an hour > now, but it hasn't completed yet. It's you. it's very quick for me. -a From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 22:09:02 2014 Return-Path: Delivered-To: freebsd-current@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 22DEC7EF; Tue, 26 Aug 2014 22:09:02 +0000 (UTC) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::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 BAF9B34CE; Tue, 26 Aug 2014 22:09:01 +0000 (UTC) Received: by mail-ig0-f173.google.com with SMTP id h18so5286842igc.12 for ; Tue, 26 Aug 2014 15:09:01 -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=dpOVjSFQ5Fgm+Y2+vy1uwID0D/1IywyDnDFFCSV8eNY=; b=CkAB+9APkKAcka/RJHOBJ+OWlbFhkcPyfuCsfP/zJ8IzM2Y3bJigAY5JbBd8ak7kW9 Ih4COCngbv5FMt3TxgfLlsQxJGFSe4F6b4ZTUt/ndduJ8fjgKZPMHunTxVdbW8fD0NLj bm0anmOc1DP+2EpgiEvQ5LTSp9icG+aXEEbiIVu6hrScy1CDuIlRWpY63dqnoAWHDUWV KzjQbVQ73XfY8UqNBytamhIGAGuxjqS7d2QpRQbjp3lJkv6nWhv+kcXS5/AWGJ8dJt8Y ggz1BpYFy1h0E3pDPU+ZIn4f+952A+TH2kFTIIvgZHv2T+33Kx6g3jOy17jNi8bZrwy6 FHHA== MIME-Version: 1.0 X-Received: by 10.42.26.9 with SMTP id d9mr34285icc.93.1409090941176; Tue, 26 Aug 2014 15:09:01 -0700 (PDT) Received: by 10.50.72.69 with HTTP; Tue, 26 Aug 2014 15:09:01 -0700 (PDT) In-Reply-To: References: <5256B761.4050301@gmail.com> <1381421583.19140.32451849.084D8E32@webmail.messagingengine.com> <5256E2D5.4060101@allanjude.com> <1387388390.28188.61199633.413D38F8@webmail.messagingengine.com> <53A7CE1B.7090400@gmail.com> <8e598a07cf5bc8690749120295936c40@mail.feld.me> <73E03261-8087-415A-BD04-EAADFF90C080@gmail.com> Date: Tue, 26 Aug 2014 15:09:01 -0700 Message-ID: Subject: Re: FreeBSD 10 and zfsd From: Garrett Cooper To: Alan Somers Content-Type: text/plain; charset=UTF-8 Cc: Johan Hendriks , Julio Merino , FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 22:09:02 -0000 On Tue, Aug 26, 2014 at 2:43 PM, Alan Somers wrote: ... > Adding a ksh93 tester to Kyua was previously discussed on > kyua-discuss. But it was basically shot down. > https://groups.google.com/forum/#!topic/kyua-discuss/w8oJHeZXuro Maybe the idea just needs to be approached from a different angle like I did with /bin/sh/tests ( https://svnweb.freebsd.org/base/head/bin/sh/tests/functional_test.sh?revision=269902&view=markup )? I know that with DTrace at least, it uses dtest.pl, which implements its own test "discovery" mechanism, which should be easy to hook into atf and produce testcases for dynamically. Some additional logic might be required to work around testcases that fail today on FreeBSD or cause the system to livelock/panic (e.g. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192906 ), but writing in simple hooks for this shouldn't be hard. > Porting, in whole or in part, the tests to /bin/sh is time consuming, > but it's the only option that satisfies everyone. Perhaps. I'm lazier nowadays and prefer not chasing after the perfect solution if I can help it (especially because it tends to bite me in the rear later). Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 23:31:20 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E2EFD1A4 for ; Tue, 26 Aug 2014 23:31:19 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AAEDF3098 for ; Tue, 26 Aug 2014 23:31:19 +0000 (UTC) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.5/8.14.5) with ESMTP id s7QNWMnA056453; Tue, 26 Aug 2014 16:32:28 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimatedns.net (8.14.5/8.14.5/Submit) id s7QNWGAp056450; Tue, 26 Aug 2014 16:32:16 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Tue, 26 Aug 2014 16:32:16 -0700 (PDT) Message-ID: <6c36b18e9cf5d2dcd7b251bb385babbd.authenticated@ultimatedns.net> In-Reply-To: <44sikjvw37.fsf@be-well.ilk.org> References: <53FCD7B8.5060300@wemm.org> <44sikjvw37.fsf@be-well.ilk.org> Date: Tue, 26 Aug 2014 16:32:16 -0700 (PDT) Subject: Re: did tar(1) loose xz compression support in 11? From: "Chris H" To: "Lowell Gilbert" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-current@freebsd.org, Peter Wemm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 23:31:20 -0000 > "Chris H" writes: > >>> On 8/26/14 11:05 AM, Chris H wrote: >>>> Greetings, >>>> I'm currently testing 11. My build / install is from about 2 days ago. >>>> I generally use xz compression, when creating archives. But when I >>>> attempt the following: >>>> >>>> tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file >>>> >>>> it returns the following: >>>> >>>> tar: Undefined option: `xz:9' >>>> >>>> This has always worked in previous versions. Has the syntax changed, >>>> and the man(1) pages just haven't caught up? >>> >>> I use: >>> tar -cJ --options xz:compression-level=1 >>> .. on head. Are you using the right syntax? >> Apparently not. Using your example works as expected. >> RELENG_8, and RELENG_9 use short-hand; >> tar -cvJ --options xz:9 >> >> Why/when the change to long-hand? Seems a shame. Now I >> get to modify all my scripts, and such. :P Altho I >> don't suppose it'd be a big deal to back out (revert) the >> changes made to tar(1). :) > > I can't find any changes that would make the syntax change. At least, > not in quite a long while. Therefore, this change may not be > intentional. However, I looked at the the manual page from 9.3, and its > description of the features looks the same as on the latest HEAD, and > *doesn't* look like leaving out a "key" (in this case, > "compression-level") is ever compliant. > > You might try the latest (or older) libarchive from the ports, and > compare its behaviour. Also, there are a number (amusingly many, in > fact) of other ways of specifying these parameters that may be more > convenient for you, so another look throught the tar(1) manual might > save you a few minutes. Thank you, Lowell. For your extremely informative reply. Curious. The man page I read from my freshly built 11-CURRENT indicates the following: xz:compression-level A decimal integer from 0 to 9 specifying the xz compres- sion level. As I have always read that (interpreted it). It meant: xz: (0-9) Which is what I've always used. I haven't grepped ports||src yet. But if it makes any difference, it came from src -- build/install world. I'll do some poking around. But all my other boxes (RELENG_8 && RELENG_9) use xz:. Thanks again, Lowell. For taking the time to respond. Greatly appreciated. --Chris > > Good luck. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Wed Aug 27 00:35:31 2014 Return-Path: Delivered-To: freebsd-current@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 B949290 for ; Wed, 27 Aug 2014 00:35:31 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 93BA53702 for ; Wed, 27 Aug 2014 00:35:31 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s7R0ZF9W031244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Aug 2014 17:35:15 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s7R0ZEAh031243; Tue, 26 Aug 2014 17:35:14 -0700 (PDT) (envelope-from jmg) Date: Tue, 26 Aug 2014 17:35:14 -0700 From: John-Mark Gurney To: Chris H Subject: Re: did tar(1) loose xz compression support in 11? Message-ID: <20140827003514.GM71691@funkthat.com> Mail-Followup-To: Chris H , Lowell Gilbert , freebsd-current@freebsd.org, Peter Wemm References: <53FCD7B8.5060300@wemm.org> <44sikjvw37.fsf@be-well.ilk.org> <6c36b18e9cf5d2dcd7b251bb385babbd.authenticated@ultimatedns.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6c36b18e9cf5d2dcd7b251bb385babbd.authenticated@ultimatedns.net> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 26 Aug 2014 17:35:15 -0700 (PDT) Cc: freebsd-current@freebsd.org, Peter Wemm , Lowell Gilbert X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 00:35:31 -0000 Chris H wrote this message on Tue, Aug 26, 2014 at 16:32 -0700: > > "Chris H" writes: > > > >>> On 8/26/14 11:05 AM, Chris H wrote: > >>>> Greetings, > >>>> I'm currently testing 11. My build / install is from about 2 days ago. > >>>> I generally use xz compression, when creating archives. But when I > >>>> attempt the following: > >>>> > >>>> tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file > >>>> > >>>> it returns the following: > >>>> > >>>> tar: Undefined option: `xz:9' > >>>> > >>>> This has always worked in previous versions. Has the syntax changed, > >>>> and the man(1) pages just haven't caught up? > >>> > >>> I use: > >>> tar -cJ --options xz:compression-level=1 > >>> .. on head. Are you using the right syntax? > >> Apparently not. Using your example works as expected. > >> RELENG_8, and RELENG_9 use short-hand; > >> tar -cvJ --options xz:9 > >> > >> Why/when the change to long-hand? Seems a shame. Now I > >> get to modify all my scripts, and such. :P Altho I > >> don't suppose it'd be a big deal to back out (revert) the > >> changes made to tar(1). :) > > > > I can't find any changes that would make the syntax change. At least, > > not in quite a long while. Therefore, this change may not be > > intentional. However, I looked at the the manual page from 9.3, and its > > description of the features looks the same as on the latest HEAD, and > > *doesn't* look like leaving out a "key" (in this case, > > "compression-level") is ever compliant. > > > > You might try the latest (or older) libarchive from the ports, and > > compare its behaviour. Also, there are a number (amusingly many, in > > fact) of other ways of specifying these parameters that may be more > > convenient for you, so another look throught the tar(1) manual might > > save you a few minutes. > Thank you, Lowell. For your extremely informative reply. > Curious. The man page I read from my freshly built 11-CURRENT indicates > the following: > > xz:compression-level > A decimal integer from 0 to 9 specifying the xz compres- > sion level. > > As I have always read that (interpreted it). It meant: > xz: (0-9) > Which is what I've always used. I haven't grepped ports||src > yet. But if it makes any difference, it came from src -- build/install > world. > I'll do some poking around. But all my other boxes (RELENG_8 && RELENG_9) > use xz:. > > Thanks again, Lowell. For taking the time to respond. Greatly appreciated. Could it be that previous versions were ignoring the option and not giving you an error? It looks like that was the case on my 9.1-PR box: $tar -cJf test.txz *.patch *.c testcrypt *.h; ls -l test.txz -rw------- 1 jmg wheel 38956 Aug 26 17:33 test.txz $tar --options xz:9 -cJf test.txz *.patch *.c testcrypt *.h; ls -l test.txz -rw------- 1 jmg wheel 38956 Aug 26 17:33 test.txz $tar --options xz:1 -cJf test.txz *.patch *.c testcrypt *.h; ls -l test.txz -rw------- 1 jmg wheel 38956 Aug 26 17:33 test.txz $tar --options xz:compression-level=1 -cJf test.txz *.patch *.c testcrypt *.h; ls -l test.txz -rw------- 1 jmg wheel 41772 Aug 26 17:34 test.txz $tar --options xz:compression-level=9 -cJf test.txz *.patch *.c testcrypt *.h; ls -l test.txz -rw------- 1 jmg wheel 38956 Aug 26 17:34 test.txz -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Wed Aug 27 02:10:09 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C65599CA for ; Wed, 27 Aug 2014 02:10:09 +0000 (UTC) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) (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 9893A3EF4 for ; Wed, 27 Aug 2014 02:10:09 +0000 (UTC) Received: by mail-pd0-f173.google.com with SMTP id w10so23220318pde.18 for ; Tue, 26 Aug 2014 19:10:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Miekn/tUYH0H2poIjublzIQoSisZ6XlDR/Mp1T2D/yo=; b=QJFiBqZn6Ft0QOwjG/4aoTYlN8x+8PDUiNdCF/gXEcIlIAcGspRR3JjL3A9cNXlHNK VFkJYEBXa2DyeHKaeCrRjXDtaloh8f26E5FM1Bgb6Ko9jfDTI4G/JnVXH7Q9V3Uh+ujN 47fqq6aiQbn1eKaOUeI1pBxbkfb+Spbl0TvhgQ+zRAl5wpFAK4X5DxG20f845uWnuoF3 Ipo2LKNWwy4PDIDMPki2FW34nSKETHL+cPHtRe3I1lQLAe28HxGsJvcCYNln0rd3Wc4o xiiaA1hOi86jcYa2ttJIBWL8FvcaslaDsHhkhfpyzb/1BDpqn67lzhpKib9S8K6APpsj 0VBw== X-Gm-Message-State: ALoCoQnIGMUJai13g82DPDFCuRGMFJgPpC6UK6ly3ZGLNdXjEWQ/o17pH4AJkRUEci1elQo0av7q X-Received: by 10.70.103.42 with SMTP id ft10mr13305856pdb.2.1409105403746; Tue, 26 Aug 2014 19:10:03 -0700 (PDT) Received: from [192.168.1.100] (c-24-6-220-224.hsd1.ca.comcast.net. [24.6.220.224]) by mx.google.com with ESMTPSA id ow2sm7199738pdb.27.2014.08.26.19.10.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Aug 2014 19:10:02 -0700 (PDT) Subject: Re: did tar(1) loose xz compression support in 11? Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle X-Priority: 3 (Normal) In-Reply-To: Date: Tue, 26 Aug 2014 19:10:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <134A4303-3421-4A7B-9EB6-74D58B939217@kientzle.com> References: To: Chris H X-Mailer: Apple Mail (2.1878.6) Cc: freebsd hackers , freebsd current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 02:10:09 -0000 On Aug 26, 2014, at 11:05 AM, Chris H wrote: > Greetings, > I'm currently testing 11. My build / install is from about 2 days ago. > I generally use xz compression, when creating archives. But when I > attempt the following: >=20 > tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file >=20 > it returns the following: >=20 > tar: Undefined option: `xz:9' >=20 > This has always worked in previous versions. Has the syntax changed, > and the man(1) pages just haven't caught up? I can=92t see any evidence in libarchive=92s source that this ever = worked. However, there was some work done recently to improve error reporting = from the options processor. It=92s quite possible that =97options xz:9 = used to just be ignored and now it=92s reporting an error. Tim From owner-freebsd-current@FreeBSD.ORG Wed Aug 27 03:08:07 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D0C3E560 for ; Wed, 27 Aug 2014 03:08:07 +0000 (UTC) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7674034B5 for ; Wed, 27 Aug 2014 03:08:07 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.9/8.14.9/NETPLEX) with ESMTP id s7R2sunN034876; Tue, 26 Aug 2014 22:54:56 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Tue, 26 Aug 2014 22:54:56 -0400 (EDT) Date: Tue, 26 Aug 2014 22:54:56 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: Tim Kientzle Subject: Re: did tar(1) loose xz compression support in 11? In-Reply-To: <134A4303-3421-4A7B-9EB6-74D58B939217@kientzle.com> Message-ID: References: <134A4303-3421-4A7B-9EB6-74D58B939217@kientzle.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd current , Chris H X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 03:08:07 -0000 On Tue, 26 Aug 2014, Tim Kientzle wrote: > > On Aug 26, 2014, at 11:05 AM, Chris H wrote: > >> Greetings, >> I'm currently testing 11. My build / install is from about 2 days ago. >> I generally use xz compression, when creating archives. But when I >> attempt the following: >> >> tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file >> >> it returns the following: >> >> tar: Undefined option: `xz:9' >> >> This has always worked in previous versions. Has the syntax changed, >> and the man(1) pages just haven't caught up? > > I can=92t see any evidence in libarchive=92s source that this ever worked= =2E The man page is a little confusing. Here it says: --options options Select optional behaviors for particular modules. The argument is a text string containing comma-separated keywords and values. These are passed to the modules that handle particular formats to control how those formats will behave. Each option has one of the following forms: key=3Dvalue The key will be set to the specified value in every module that supports it. Modules that do not support this key will ignore it. Then below, after the last option, it says: ... zip:compression=3Dtype Use type as compression method. Supported values are store (uncompressed) and deflate (gzip algorithm). If a provided option is not supported by any module, that is a fatal error. The first states that it is ignored, the latter states that it is a fatal error. The meaning of "any module" is subtle, at least for my feeble brain ;-) Also, the syntax for "[lr]zip:compression=3Dtype" is very clear, whereas the syntax for compression-level keys omit the "=3Dvalue". --=20 DE From owner-freebsd-current@FreeBSD.ORG Wed Aug 27 13:59:38 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 571D2CFF; Wed, 27 Aug 2014 13:59:38 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 029DD352B; Wed, 27 Aug 2014 13:59:37 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id s7RDxKL6061645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 27 Aug 2014 07:59:20 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id s7RDxJcX061630; Wed, 27 Aug 2014 07:59:19 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Wed, 27 Aug 2014 07:59:19 -0600 (MDT) From: Warren Block To: Daniel Eischen Subject: Re: did tar(1) loose xz compression support in 11? In-Reply-To: Message-ID: References: <134A4303-3421-4A7B-9EB6-74D58B939217@kientzle.com> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Wed, 27 Aug 2014 07:59:20 -0600 (MDT) Cc: freebsd current , Chris H X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 13:59:38 -0000 On Tue, 26 Aug 2014, Daniel Eischen wrote: > On Tue, 26 Aug 2014, Tim Kientzle wrote: >> >> On Aug 26, 2014, at 11:05 AM, Chris H wrote: >> >>> Greetings, >>> I'm currently testing 11. My build / install is from about 2 days ago. >>> I generally use xz compression, when creating archives. But when I >>> attempt the following: >>> >>> tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file >>> >>> it returns the following: >>> >>> tar: Undefined option: `xz:9' >>> >>> This has always worked in previous versions. Has the syntax changed, >>> and the man(1) pages just haven't caught up? >> >> I can?t see any evidence in libarchive?s source that this ever worked. > > The man page is a little confusing. Here it says: > > --options options > Select optional behaviors for particular modules. The > argument is a text string containing comma-separated > keywords and values. These are passed to the modules that > handle particular formats to control how those formats will > behave. Each option has one of the following forms: > > key=value > The key will be set to the specified value in every > module that supports it. Modules that do not > support this key will ignore it. > > > Then below, after the last option, it says: > > ... > zip:compression=type > Use type as compression method. Supported values are > store (uncompressed) and deflate (gzip algorithm). > > If a provided option is not supported by any module, that is a > fatal error. > > The first states that it is ignored, the latter states that it > is a fatal error. The meaning of "any module" is subtle, at > least for my feeble brain ;-) It suggests that options are passed to all modules, and each module is free to ignore options it does not understand. But at least one module must understand the option, or a fatal error is reported. From owner-freebsd-current@FreeBSD.ORG Wed Aug 27 14:01:26 2014 Return-Path: Delivered-To: freebsd-current@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 EBC9DE80; Wed, 27 Aug 2014 14:01:25 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B54C83568; Wed, 27 Aug 2014 14:01:25 +0000 (UTC) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.5/8.14.5) with ESMTP id s7RE2WEm009331; Wed, 27 Aug 2014 07:02:39 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimatedns.net (8.14.5/8.14.5/Submit) id s7RE2Q1r009324; Wed, 27 Aug 2014 07:02:26 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Wed, 27 Aug 2014 07:02:27 -0700 (PDT) Message-ID: In-Reply-To: <134A4303-3421-4A7B-9EB6-74D58B939217@kientzle.com> References: <134A4303-3421-4A7B-9EB6-74D58B939217@kientzle.com> Date: Wed, 27 Aug 2014 07:02:27 -0700 (PDT) Subject: Re: did tar(1) loose xz compression support in 11? From: "Chris H" To: "Tim Kientzle" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd hackers , freebsd current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 14:01:26 -0000 > > On Aug 26, 2014, at 11:05 AM, Chris H wrote: > >> Greetings, >> I'm currently testing 11. My build / install is from about 2 days ago. >> I generally use xz compression, when creating archives. But when I >> attempt the following: >> >> tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file >> >> it returns the following: >> >> tar: Undefined option: `xz:9' >> >> This has always worked in previous versions. Has the syntax changed, >> and the man(1) pages just haven't caught up? > > I can’t see any evidence in libarchive’s source that this ever worked. > > However, there was some work done recently to improve error reporting from the options > processor. It’s quite possible that —options xz:9 used to just be ignored and now it’s > reporting an error. > > Tim On a hunch. I performed a similar test. I added STAGE to the following port. So I'll test here. # tar -cvJ --options xz:9 -f posadis-xz9.tar.xz ./posadis/ a ./posadis a ./posadis/files a ./posadis/pkg-plist a ./posadis/Makefile a ./posadis/distinfo a ./posadis/pkg-descr a ./posadis/files/patch-Makefile.in a ./posadis/files/patch-configure.in # tar -cvJ --options xz:1 -f posadis-xz1.tar.xz ./posadis/ a ./posadis a ./posadis/files a ./posadis/pkg-plist a ./posadis/Makefile a ./posadis/distinfo a ./posadis/pkg-descr a ./posadis/files/patch-Makefile.in a ./posadis/files/patch-configure.in unlike the previous examples, and arguments. I used the v switch. Presuming that would provide feedback on any anomalous usage. However. The following proves otherwise: # ls -la -rw-r--r-- 1 root wheel 2380 Aug 27 06:47 posadis-xz1.tar.xz -rw-r--r-- 1 root wheel 2380 Aug 27 06:47 posadis-xz9.tar.xz (performed on a RELENG_9 box) As one can see, nothing (compression level(s)) were UNchanged. So the verdict is in; the _recent_ changes provide the needed feedback where anomalous usage is concerned. Short version; tar now works correctly -- it's fixed. :) Humble opinion; the man(1) pages could be somewhat more concise. Humble request; would it be possible to make [bsd]tar(1) honor the short-hand version of options? Thank you, Tim, and everyone else, for all your thoughtful replies. --Chris > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Wed Aug 27 15:28:00 2014 Return-Path: Delivered-To: freebsd-current@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 9CE4BC1B for ; Wed, 27 Aug 2014 15:28:00 +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 6549830F5 for ; Wed, 27 Aug 2014 15:28:00 +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 s7RFS0sE086152 for ; Wed, 27 Aug 2014 15:28:00 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s7RFS0ew086151 for freebsd-current@freebsd.org; Wed, 27 Aug 2014 15:28:00 GMT (envelope-from bdrewery) Received: (qmail 62955 invoked from network); 27 Aug 2014 10:27:58 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 27 Aug 2014 10:27:58 -0500 Message-ID: <53FDF8F8.1070501@FreeBSD.org> Date: Wed, 27 Aug 2014 10:27:52 -0500 From: Bryan Drewery Reply-To: Ports FreeBSD Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: pkg@FreeBSD.org, ports@FreeBSD.org Subject: Pkg 1.3.7 out. Special handling recommended to avoid reinstalls. References: <53F4CC79.5000607@FreeBSD.org> <53F6188D.7090505@FreeBSD.org> In-Reply-To: <53F6188D.7090505@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KOqqM1JrRieVlRvFfl3xxSXLoSU38kOHB" X-Mailman-Approved-At: Wed, 27 Aug 2014 16:15:00 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 15:28:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KOqqM1JrRieVlRvFfl3xxSXLoSU38kOHB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Pkg 1.3.7 is now released. The port is updated. pkg.FreeBSD.org packages are now published with fixed shared libraries. It was found that 'pkg update -f' may be required as well. Here are the updated instructions: - Binary package users should run 'pkg update -f' and 'pkg check -Ba' after upgrading to pkg-1.3.7 and before updating any other packages. This avoids needing to reinstall anything not needed due to changed shared libraries. For binary package users: # pkg install ports-mgmt/pkg # pkg update -f # pkg check -Ba # pkg upgrade For port users: # portsnap fetch update # make -C /usr/ports/ports-mgmt/pkg build deinstall install clean # pkg check -Ba - People building packages for serving to other systems need to rebuild all packages with 1.3.7. The previous announcement explaining this in more detail is at http://lists.freebsd.org/pipermail/freebsd-ports-announce/2014-August/000= 086.html --=20 Regards, Bryan Drewery --KOqqM1JrRieVlRvFfl3xxSXLoSU38kOHB 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) iQEcBAEBAgAGBQJT/fj4AAoJEDXXcbtuRpfPFh8H/2LFypX/Q28Hsli0979ETTyL Rkq0qE8YCrqiL4hjB58oXARcJ8hTSFtSfa8anJwh1qnjYFLaR6Aoo8bqnxp/IQ4t rxAhtblFo9Z8FbY1axy152XIwV29NKokBl3uapQUXkfpxIKtxE5s7Qm2nsALJfFx s4TN7+6oZlPanbbkBJH5UCjDVpIbO7bGqjJ7P0pa0l6eiwvrji6g1Va65U2WBSHW CBsjVAoIms/BnBu2+ZgVqNZDL7ube58MwLE9wKiXM9A1cWxqpYAZ7KC/Xe/pnFRG wuD1VSXCExtYXQpnxt5E9eRdE3AHxviwmG8OorJbGX9oJdZQPwJQ3yix526x/OU= =W2U7 -----END PGP SIGNATURE----- --KOqqM1JrRieVlRvFfl3xxSXLoSU38kOHB-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 27 16:48:00 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC460DFD for ; Wed, 27 Aug 2014 16:48:00 +0000 (UTC) Received: from erelay4.ox.registrar-servers.com (erelay4.ox.registrar-servers.com [192.64.117.33]) by mx1.freebsd.org (Postfix) with ESMTP id 807E73CC9 for ; Wed, 27 Aug 2014 16:48:00 +0000 (UTC) Received: from localhost (unknown [127.0.0.1]) by erelay1.ox.registrar-servers.com (Postfix) with ESMTP id 262C02200A0F for ; Wed, 27 Aug 2014 16:48:00 +0000 (UTC) Received: from erelay1.ox.registrar-servers.com ([127.0.0.1]) by localhost (erelay.ox.registrar-servers.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xCt4m2mqTvw3 for ; Wed, 27 Aug 2014 12:47:59 -0400 (EDT) Received: from imap11.ox.privateemail.com (imap11.ox.privateemail.com [192.64.116.222]) by erelay1.ox.registrar-servers.com (Postfix) with ESMTP id 7872D2200753 for ; Wed, 27 Aug 2014 12:47:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.privateemail.com (Postfix) with ESMTP id 3CA4E8800CB for ; Wed, 27 Aug 2014 12:47:59 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at imap11.ox.privateemail.com Received: from mail.privateemail.com ([127.0.0.1]) by localhost (imap11.ox.privateemail.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id A2B2J6BjHH0W for ; Wed, 27 Aug 2014 12:47:59 -0400 (EDT) Received: from localhost (140.Red-83-57-187.dynamicIP.rima-tde.net [83.57.187.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.privateemail.com (Postfix) with ESMTPSA id 921798800E4 for ; Wed, 27 Aug 2014 12:47:58 -0400 (EDT) Date: Wed, 27 Aug 2014 18:46:36 +0200 From: Carlos Jacobo Puga Medina To: freebsd-current@freebsd.org Subject: Re: r269471 make unusable VT console Message-Id: <20140827184636.ab72ba17d68c88a7af596187@fbsd.es> In-Reply-To: <20140827184423.7c2903d288738766df38a53e@fbsd.es> References: <20140812232807.0f3aa02570becec15e056af2@fbsd.es> <20140816011444.301a98d6187aca27e3a2481b@ddteam.net> <1601387215.131322.1408191498255.JavaMail.open-xchange@app2.ox.registrar-servers.com> <1760448043.149874.1408203652364.JavaMail.open-xchange@app1.ox.registrar-servers.com> <20140827184423.7c2903d288738766df38a53e@fbsd.es> X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.22; i386-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 16:48:00 -0000 Hi, I just update my box. I confirm too that r270322 fixed the problem. Thanks for fix it, -- Carlos Jacobo Puga Medina From owner-freebsd-current@FreeBSD.ORG Wed Aug 27 17:28:52 2014 Return-Path: Delivered-To: freebsd-current@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 BC41CF42 for ; Wed, 27 Aug 2014 17:28:52 +0000 (UTC) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7BD0E3130 for ; Wed, 27 Aug 2014 17:28:52 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.9/8.14.9/NETPLEX) with ESMTP id s7RHSfYY016147; Wed, 27 Aug 2014 13:28:41 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Wed, 27 Aug 2014 13:28:41 -0400 (EDT) Date: Wed, 27 Aug 2014 13:28:41 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: Warren Block Subject: Re: did tar(1) loose xz compression support in 11? In-Reply-To: Message-ID: References: <134A4303-3421-4A7B-9EB6-74D58B939217@kientzle.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd current , Chris H X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 17:28:52 -0000 On Wed, 27 Aug 2014, Warren Block wrote: > On Tue, 26 Aug 2014, Daniel Eischen wrote: > >> The man page is a little confusing. Here it says: >> >> --options options >> Select optional behaviors for particular modules. The >> argument is a text string containing comma-separated >> keywords and values. These are passed to the modules that >> handle particular formats to control how those formats will >> behave. Each option has one of the following forms: >> >> key=value >> The key will be set to the specified value in every >> module that supports it. Modules that do not >> support this key will ignore it. >> >> >> Then below, after the last option, it says: >> >> ... >> zip:compression=type >> Use type as compression method. Supported values are >> store (uncompressed) and deflate (gzip algorithm). >> >> If a provided option is not supported by any module, that is a >> fatal error. >> >> The first states that it is ignored, the latter states that it >> is a fatal error. The meaning of "any module" is subtle, at >> least for my feeble brain ;-) > > It suggests that options are passed to all modules, and each module is free > to ignore options it does not understand. But at least one module must > understand the option, or a fatal error is reported. Yes, I got that, but it is confusing when you are intentionally passing to only one module, as in the original post, "xz:9", and considering that the "fatal error" and "ignore it" parts are listed in separate sections. Regardless, tar(1) has many options, so a little confusion is not unsurprising :-) -- DE From owner-freebsd-current@FreeBSD.ORG Wed Aug 27 22:37:57 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C61B904 for ; Wed, 27 Aug 2014 22:37:57 +0000 (UTC) Received: from mario.brtsvcs.net (mario.brtsvcs.net [IPv6:2607:fc50:0:a400::2]) (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 600F03685 for ; Wed, 27 Aug 2014 22:37:57 +0000 (UTC) Received: from chombo.houseloki.net (unknown [IPv6:2601:7:400:640:21c:c0ff:fe7f:96ee]) by mario.brtsvcs.net (Postfix) with ESMTPSA id DD6152C1630; Wed, 27 Aug 2014 15:37:54 -0700 (PDT) Received: from [IPv6:2601:7:2280:38b:baca:3aff:fe83:bd29] (unknown [IPv6:2601:7:2280:38b:baca:3aff:fe83:bd29]) by chombo.houseloki.net (Postfix) with ESMTPSA id F2DF9B6F; Wed, 27 Aug 2014 15:37:51 -0700 (PDT) Message-ID: <53FE5DBF.8070705@bluerosetech.com> Date: Wed, 27 Aug 2014 15:37:51 -0700 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Shane Ambler Subject: Re: android bsd connectivity tools etc ? References: <201408132347.s7DNlcHU013055@fire.js.berklix.net> <53EC3930.6060604@ShaneWare.Biz> In-Reply-To: <53EC3930.6060604@ShaneWare.Biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Julian H. Stacey" , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 22:37:57 -0000 On 8/13/2014 9:21 PM, Shane Ambler wrote: > It looks like mass storage was hidden in 4.0 and maybe removed after 4.2. > Try searching the android app store for usb mass storage. Android supports MTP over USB 2.0 and 3.0. It also has backward compatibility for PTP. Support for MTP is a bit rocky outside Windows and Mac OSX, but libmtp.sourceforge.net has a short list of clients. From owner-freebsd-current@FreeBSD.ORG Thu Aug 28 19:02:09 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2BA1EF38; Thu, 28 Aug 2014 19:02:09 +0000 (UTC) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7DB7111FB; Thu, 28 Aug 2014 19:02:08 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id p9so1427686lbv.19 for ; Thu, 28 Aug 2014 12:02:06 -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=P1vLKGIsFjVxUkrj7scRvVT2jKTz1XEHSgle4nDUo/M=; b=wkScx49o6+bhnU15Dm0pY4PA7YqC8G8Wz4M6aHH79M4mMokFAvDUB717dEfBl9IF+Q 7bx4apgYKtOP4kaYZi/pDwKtK38Tqjyos5emBVAAVAn80GCJJAU+ZJDDJCzIgIRc8PpG 4FSS1By5oBhCZQRfcvB6frRtFFAW4+Mu2FSypnPtA+ObHD7y5zo/7iM3A7Yoa2vgiV/k /1QTvGO0wbPCAtYFUbMSfiCw0X9CPtn3fit3MKEaHYdNFqdCIyaZP2Uv4cXI7eXz7xeo xPsotdV/CVSzsE2QkrSuVpld4ehA+rvBmZfy79vyJ6mTrUkB/3DxHAsComTTLnpThApH mrUQ== MIME-Version: 1.0 X-Received: by 10.152.20.41 with SMTP id k9mr6357485lae.57.1409252526363; Thu, 28 Aug 2014 12:02:06 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.197.107 with HTTP; Thu, 28 Aug 2014 12:02:06 -0700 (PDT) In-Reply-To: <20140825165522.GC91673@spindle.one-eyed-alien.net> References: <20140825165522.GC91673@spindle.one-eyed-alien.net> Date: Thu, 28 Aug 2014 12:02:06 -0700 X-Google-Sender-Auth: Bl-BFs3ZJIGt6r_cME0vB7mt8vQ Message-ID: Subject: Re: "make installworld" commands used to generate manifest for makefs? From: Craig Rodrigues To: Brooks Davis Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 19:02:09 -0000 On Mon, Aug 25, 2014 at 9:55 AM, Brooks Davis wrote: > On Sun, Aug 24, 2014 at 04:10:21PM -0700, Craig Rodrigues wrote: >> Hi, >> >> Is there an easy way to take most of the commands performed >> during "make installworld" and create a manifest file >> which is compatible with makefs? > > make -DNO_ROOT -DDB_FROM_SRC DESTDIR= installworld > > should result in a /METALOG file suitable for passing to makefs. > You may also want the distribution target if you want a populated /etc. > > -- Broks Thanks, that's useful info! I did this: make -DDB_FROM_SRC -DNO_ROOT installkernel DESTDIR=/tmp/test4 make -DDB_FROM_SRC -DNO_ROOT installworld DESTDIR=/tmp/test4 make -DDB_FROM_SRC -DNO_ROOT distribution DESTDIR=/tmp/test4 /tmp/test4/METALOG was created, but it did not seem to have /boot/kernel/kernel or any kernel modules. Is that expected? -- Craig From owner-freebsd-current@FreeBSD.ORG Thu Aug 28 19:53:21 2014 Return-Path: Delivered-To: freebsd-current@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 54878E6; Thu, 28 Aug 2014 19:53:21 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 423871918; Thu, 28 Aug 2014 19:53:21 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id DD921249; Thu, 28 Aug 2014 19:53:20 +0000 (UTC) Date: Thu, 28 Aug 2014 19:53:19 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, rodrigc@FreeBSD.org, jfv@FreeBSD.org Message-ID: <2143128560.13.1409255600495.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #1334 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 19:53:21 -0000 See Changes: [jfv] Add XL710 device entries to NOTES, and directories to the module Makefile so they will be built. MFC after: 1 day [rodrigc] Use "file -s", so that we can run vmrun.sh against special device= s such as /dev/md memory file systems Reviewed by: neel ------------------------------------------ [...truncated 254021 lines...] eventhandler_tag vlan_detach; ^ --- all_subdir_ixl --- :650:21: error: implicit declaration of function 'EVEN= THANDLER_REGISTER' is invalid in C99 [-Werror,-Wimplicit-function-declarati= on] vsi->vlan_attach =3D EVENTHANDLER_REGISTER(vlan_config, ^ --- all_subdir_ixlv --- :498:21: error: implicit declaration of function 'EV= ENTHANDLER_REGISTER' is invalid in C99 [-Werror,-Wimplicit-function-declara= tion] vsi->vlan_attach =3D EVENTHANDLER_REGISTER(vlan_config, ^ --- all_subdir_ixl --- :650:43: error: use of undeclared identifier 'vlan_con= fig' vsi->vlan_attach =3D EVENTHANDLER_REGISTER(vlan_config, ^ :652:43: error: use of undeclared identifier 'vlan_unc= onfig' vsi->vlan_detach =3D EVENTHANDLER_REGISTER(vlan_unconfig, ^ :670:3: error: implicit declaration of function 'if_fr= ee' is invalid in C99 [-Werror,-Wimplicit-function-declaration] if_free(vsi->ifp); ^ --- all_subdir_ixlv --- :498:43: error: use of undeclared identifier 'vlan_c= onfig' vsi->vlan_attach =3D EVENTHANDLER_REGISTER(vlan_config, ^ --- all_subdir_ixl --- :670:3: note: did you mean 'm_free'? --- all_subdir_ixlv --- :500:43: error: use of undeclared identifier 'vlan_u= nconfig' vsi->vlan_detach =3D EVENTHANDLER_REGISTER(vlan_unconfig, ^ --- all_subdir_ixl --- @/sys/mbuf.h:1138:1: note: 'm_free' declared here m_free(struct mbuf *m) ^ --- all_subdir_ixlv --- :550:14: error: incomplete definition of type 'struc= t ifnet' if (vsi->ifp->if_vlantrunk !=3D NULL) { ~~~~~~~~^ --- all_subdir_ixl --- :698:14: error: incomplete definition of type 'struct = ifnet' if (vsi->ifp->if_vlantrunk !=3D NULL) { ~~~~~~~~^ --- all_subdir_ixlv --- @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' struct ifnet *rcvif; /* rcv interface */ ^ :557:14: error: incomplete definition of type 'struc= t ifnet' if (vsi->ifp->if_drv_flags & IFF_DRV_RUNNING) { ~~~~~~~~^ --- all_subdir_ixl --- @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' struct ifnet *rcvif; /* rcv interface */ ^ --- all_subdir_ixlv --- @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' struct ifnet *rcvif; /* rcv interface */ ^ :566:18: error: incomplete definition of type 'struc= t ifnet' while (vsi->ifp->if_drv_flags & IFF_DRV_RUNNING ~~~~~~~~^ @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' struct ifnet *rcvif; /* rcv interface */ ^ :578:3: error: implicit declaration of function 'EVE= NTHANDLER_DEREGISTER' is invalid in C99 [-Werror,-Wimplicit-function-declar= ation] EVENTHANDLER_DEREGISTER(vlan_config, vsi->vlan_attach); ^ --- all_subdir_ixl --- :729:3: error: implicit declaration of function 'EVENT= HANDLER_DEREGISTER' is invalid in C99 [-Werror,-Wimplicit-function-declarat= ion] EVENTHANDLER_DEREGISTER(vlan_config, vsi->vlan_attach); ^ --- all_subdir_ixlv --- :578:3: note: did you mean 'EVENTHANDLER_REGISTER'? :498:21: note: 'EVENTHANDLER_REGISTER' declared here vsi->vlan_attach =3D EVENTHANDLER_REGISTER(vlan_config, ^ --- all_subdir_ixl --- :729:3: note: did you mean 'EVENTHANDLER_REGISTER'? :650:21: note: 'EVENTHANDLER_REGISTER' declared here vsi->vlan_attach =3D EVENTHANDLER_REGISTER(vlan_config, ^ --- all_subdir_ixgbe --- --- ixgbe.o --- ctfconvert -L VERSION -g ixgbe.o --- all_subdir_ixlv --- :578:27: error: use of undeclared identifier 'vlan_c= onfig' EVENTHANDLER_DEREGISTER(vlan_config, vsi->vlan_attach); ^ --- all_subdir_ixl --- :729:27: error: use of undeclared identifier 'vlan_con= fig' EVENTHANDLER_DEREGISTER(vlan_config, vsi->vlan_attach); ^ --- all_subdir_ixlv --- :580:27: error: use of undeclared identifier 'vlan_u= nconfig' EVENTHANDLER_DEREGISTER(vlan_unconfig, vsi->vlan_detach); ^ :604:10: error: incomplete definition of type 'struc= t ifnet' vsi->ifp->if_flags &=3D ~IFF_UP; ~~~~~~~~^ @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' struct ifnet *rcvif; /* rcv interface */ ^ :606:2: error: implicit declaration of function 'if_= free' is invalid in C99 [-Werror,-Wimplicit-function-declaration] if_free(vsi->ifp); ^ :606:2: note: did you mean 'm_free'? @/sys/mbuf.h:1138:1: note: 'm_free' declared here --- all_subdir_ixl --- :731:27: error: use of undeclared identifier 'vlan_unc= onfig' EVENTHANDLER_DEREGISTER(vlan_unconfig, vsi->vlan_detach); ^ --- all_subdir_ixlv --- m_free(struct mbuf *m) ^ :650:11: error: incomplete definition of type 'struc= t ifnet' if (!(ifp->if_capenable & IFCAP_TXCSUM) ~~~^ @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' struct ifnet *rcvif; /* rcv interface */ ^ :651:14: error: incomplete definition of type 'struc= t ifnet' && !(ifp->if_capenable & IFCAP_TSO4)) { ~~~^ @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' struct ifnet *rcvif; /* rcv interface */ ^ :653:7: error: incomplete definition of type 'struct= ifnet' ifp->if_capenable |=3D IFCAP_TXCSUM; ~~~^ @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' struct ifnet *rcvif; /* rcv interface */ ^ :657:8: error: incomplete definition of type 'struct= ifnet' ifp->if_capenable |=3D IFCAP_TSO4; ~~~^ @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' struct ifnet *rcvif; /* rcv interface */ ^ --- all_subdir_ixl --- :829:11: error: incomplete definition of type 'struct = ifnet' --- all_subdir_ixlv --- fatal error: too many errors emitted, stopping now [-ferror-limit=3D] --- all_subdir_ixl --- if (!(ifp->if_capenable & IFCAP_TXCSUM) ~~~^ @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' struct ifnet *rcvif; /* rcv interface */ ^ :830:14: error: incomplete definition of type 'struct = ifnet' && !(ifp->if_capenable & IFCAP_TSO4)) { ~~~^ @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' struct ifnet *rcvif; /* rcv interface */ ^ :832:7: error: incomplete definition of type 'struct i= fnet' ifp->if_capenable |=3D IFCAP_TXCSUM; ~~~^ @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' struct ifnet *rcvif; /* rcv interface */ ^ :836:8: error: incomplete definition of type 'struct i= fnet' ifp->if_capenable |=3D IFCAP_TSO4; ~~~^ @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' struct ifnet *rcvif; /* rcv interface */ ^ :840:7: error: incomplete definition of type 'struct i= fnet' ifp->if_capenable |=3D (IFCAP_TXCSUM | IFCAP_TSO4); ~~~^ @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' struct ifnet *rcvif; /* rcv interface */ ^ :845:16: error: incomplete definition of type 'struct = ifnet' } else if((ifp->if_capenable & IFCAP_TXCSUM) ~~~^ @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' struct ifnet *rcvif; /* rcv interface */ ^ :846:14: error: incomplete definition of type 'struct = ifnet' && !(ifp->if_capenable & IFCAP_TSO4)) { ~~~^ @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' struct ifnet *rcvif; /* rcv interface */ ^ fatal error: too many errors emitted, stopping now [-ferror-limit=3D] --- all_subdir_ixlv --- 20 errors generated. *** [if_ixlv.o] Error code 1 make[4]: stopped in 1 error make[4]: stopped in --- all_subdir_ixgbe --- --- ixgbe_common.o --- --- all_subdir_ixlv --- *** [all_subdir_ixlv] Error code 2 make[3]: stopped in --- all_subdir_ixgbe --- cc -O2 -pipe -DSMP -DIXGBE_FDIR -fno-strict-aliasing -Werror -D_KERNEL -D= KLD_MODULE -nostdinc -I -DHAVE_KERNEL_OPTION_HEADERS -incl= ude /usr/obj -I. -I@ -I@/contrib/altq -fno-common -g -fno-omit-frame= -pointer -mno-omit-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone= -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestan= ding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Qunused-arguments -std= =3Diso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs = -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-q= ual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs = -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty= -body -Wno-error-parentheses-equality -Wno-error-unused-function -mno-aes= -mno-avx -Qunused-arguments -c --- all_subdir_isci --- ctfconvert -L VERSION -g sati_start_stop_unit.o A failure has been detected in another branch of the parallel make make[4]: stopped in *** [all_subdir_isci] Error code 2 make[3]: stopped in --- all_subdir_ixl --- 20 errors generated. *** [if_ixl.o] Error code 1 make[4]: stopped in 1 error make[4]: stopped in *** [all_subdir_ixl] Error code 2 make[3]: stopped in --- all_subdir_ixgbe --- ctfconvert -L VERSION -g ixgbe_common.o A failure has been detected in another branch of the parallel make make[4]: stopped in *** [all_subdir_ixgbe] Error code 2 make[3]: stopped in 4 errors make[3]: stopped in *** [modules-all] 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-current@FreeBSD.ORG Thu Aug 28 19:57:45 2014 Return-Path: Delivered-To: freebsd-current@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 8821A297; Thu, 28 Aug 2014 19:57:45 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id E7838195B; Thu, 28 Aug 2014 19:57:44 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 79A9E20E7088A; Thu, 28 Aug 2014 19:57:43 +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 0250D20E70885; Thu, 28 Aug 2014 19:57:40 +0000 (UTC) Message-ID: <74F55F3D8645484E9583F3C5D77EAF95@multiplay.co.uk> From: "Steven Hartland" To: , , , References: <2143128560.13.1409255600495.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Re: Build failed in Jenkins: FreeBSD_HEAD #1334 Date: Thu, 28 Aug 2014 20:57:37 +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-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 19:57:45 -0000 This should already be fixed by r270758 ----- Original Message ----- From: To: ; ; ; Sent: Thursday, August 28, 2014 8:53 PM Subject: Build failed in Jenkins: FreeBSD_HEAD #1334 > See > > > Changes: > > [jfv] Add XL710 device entries to NOTES, and directories to the module > Makefile so they will be built. > > MFC after: 1 day > > [rodrigc] Use "file -s", so that we can run vmrun.sh against special > devices such > as /dev/md memory file systems > > Reviewed by: neel > > ------------------------------------------ > [...truncated 254021 lines...] > eventhandler_tag vlan_detach; > ^ > --- all_subdir_ixl --- > :650:21: > error: implicit declaration of function 'EVENTHANDLER_REGISTER' is > invalid in C99 [-Werror,-Wimplicit-function-declaration] > vsi->vlan_attach = EVENTHANDLER_REGISTER(vlan_config, > ^ > --- all_subdir_ixlv --- > :498:21: > error: implicit declaration of function 'EVENTHANDLER_REGISTER' is > invalid in C99 [-Werror,-Wimplicit-function-declaration] > vsi->vlan_attach = EVENTHANDLER_REGISTER(vlan_config, > ^ > --- all_subdir_ixl --- > :650:43: > error: use of undeclared identifier 'vlan_config' > vsi->vlan_attach = EVENTHANDLER_REGISTER(vlan_config, > ^ > :652:43: > error: use of undeclared identifier 'vlan_unconfig' > vsi->vlan_detach = EVENTHANDLER_REGISTER(vlan_unconfig, > ^ > :670:3: > error: implicit declaration of function 'if_free' is invalid in C99 > [-Werror,-Wimplicit-function-declaration] > if_free(vsi->ifp); > ^ > --- all_subdir_ixlv --- > :498:43: > error: use of undeclared identifier 'vlan_config' > vsi->vlan_attach = EVENTHANDLER_REGISTER(vlan_config, > ^ > --- all_subdir_ixl --- > :670:3: > note: did you mean 'm_free'? > --- all_subdir_ixlv --- > :500:43: > error: use of undeclared identifier 'vlan_unconfig' > vsi->vlan_detach = EVENTHANDLER_REGISTER(vlan_unconfig, > ^ > --- all_subdir_ixl --- > @/sys/mbuf.h:1138:1: note: 'm_free' declared here > m_free(struct mbuf *m) > ^ > --- all_subdir_ixlv --- > :550:14: > error: incomplete definition of type 'struct ifnet' > if (vsi->ifp->if_vlantrunk != NULL) { > ~~~~~~~~^ > --- all_subdir_ixl --- > :698:14: > error: incomplete definition of type 'struct ifnet' > if (vsi->ifp->if_vlantrunk != NULL) { > ~~~~~~~~^ > --- all_subdir_ixlv --- > @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' > struct ifnet *rcvif; /* rcv interface */ > ^ > :557:14: > error: incomplete definition of type 'struct ifnet' > if (vsi->ifp->if_drv_flags & IFF_DRV_RUNNING) { > ~~~~~~~~^ > --- all_subdir_ixl --- > @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' > struct ifnet *rcvif; /* rcv interface */ > ^ > --- all_subdir_ixlv --- > @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' > struct ifnet *rcvif; /* rcv interface */ > ^ > :566:18: > error: incomplete definition of type 'struct ifnet' > while (vsi->ifp->if_drv_flags & IFF_DRV_RUNNING > ~~~~~~~~^ > @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' > struct ifnet *rcvif; /* rcv interface */ > ^ > :578:3: > error: implicit declaration of function 'EVENTHANDLER_DEREGISTER' is > invalid in C99 [-Werror,-Wimplicit-function-declaration] > EVENTHANDLER_DEREGISTER(vlan_config, vsi->vlan_attach); > ^ > --- all_subdir_ixl --- > :729:3: > error: implicit declaration of function 'EVENTHANDLER_DEREGISTER' is > invalid in C99 [-Werror,-Wimplicit-function-declaration] > EVENTHANDLER_DEREGISTER(vlan_config, vsi->vlan_attach); > ^ > --- all_subdir_ixlv --- > :578:3: > note: did you mean 'EVENTHANDLER_REGISTER'? > :498:21: > note: 'EVENTHANDLER_REGISTER' declared here > vsi->vlan_attach = EVENTHANDLER_REGISTER(vlan_config, > ^ > --- all_subdir_ixl --- > :729:3: > note: did you mean 'EVENTHANDLER_REGISTER'? > :650:21: > note: 'EVENTHANDLER_REGISTER' declared here > vsi->vlan_attach = EVENTHANDLER_REGISTER(vlan_config, > ^ > --- all_subdir_ixgbe --- > --- ixgbe.o --- > ctfconvert -L VERSION -g ixgbe.o > --- all_subdir_ixlv --- > :578:27: > error: use of undeclared identifier 'vlan_config' > EVENTHANDLER_DEREGISTER(vlan_config, vsi->vlan_attach); > ^ > --- all_subdir_ixl --- > :729:27: > error: use of undeclared identifier 'vlan_config' > EVENTHANDLER_DEREGISTER(vlan_config, vsi->vlan_attach); > ^ > --- all_subdir_ixlv --- > :580:27: > error: use of undeclared identifier 'vlan_unconfig' > EVENTHANDLER_DEREGISTER(vlan_unconfig, > vsi->vlan_detach); > ^ > :604:10: > error: incomplete definition of type 'struct ifnet' > vsi->ifp->if_flags &= ~IFF_UP; > ~~~~~~~~^ > @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' > struct ifnet *rcvif; /* rcv interface */ > ^ > :606:2: > error: implicit declaration of function 'if_free' is invalid in C99 > [-Werror,-Wimplicit-function-declaration] > if_free(vsi->ifp); > ^ > :606:2: > note: did you mean 'm_free'? > @/sys/mbuf.h:1138:1: note: 'm_free' declared here > --- all_subdir_ixl --- > :731:27: > error: use of undeclared identifier 'vlan_unconfig' > EVENTHANDLER_DEREGISTER(vlan_unconfig, > vsi->vlan_detach); > ^ > --- all_subdir_ixlv --- > m_free(struct mbuf *m) > ^ > :650:11: > error: incomplete definition of type 'struct ifnet' > if (!(ifp->if_capenable & IFCAP_TXCSUM) > ~~~^ > @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' > struct ifnet *rcvif; /* rcv interface */ > ^ > :651:14: > error: incomplete definition of type 'struct ifnet' > && !(ifp->if_capenable & IFCAP_TSO4)) { > ~~~^ > @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' > struct ifnet *rcvif; /* rcv interface */ > ^ > :653:7: > error: incomplete definition of type 'struct ifnet' > ifp->if_capenable |= IFCAP_TXCSUM; > ~~~^ > @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' > struct ifnet *rcvif; /* rcv interface */ > ^ > :657:8: > error: incomplete definition of type 'struct ifnet' > ifp->if_capenable |= IFCAP_TSO4; > ~~~^ > @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' > struct ifnet *rcvif; /* rcv interface */ > ^ > --- all_subdir_ixl --- > :829:11: > error: incomplete definition of type 'struct ifnet' > --- all_subdir_ixlv --- > fatal error: too many errors emitted, stopping now [-ferror-limit=] > --- all_subdir_ixl --- > if (!(ifp->if_capenable & IFCAP_TXCSUM) > ~~~^ > @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' > struct ifnet *rcvif; /* rcv interface */ > ^ > :830:14: > error: incomplete definition of type 'struct ifnet' > && !(ifp->if_capenable & IFCAP_TSO4)) { > ~~~^ > @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' > struct ifnet *rcvif; /* rcv interface */ > ^ > :832:7: > error: incomplete definition of type 'struct ifnet' > ifp->if_capenable |= IFCAP_TXCSUM; > ~~~^ > @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' > struct ifnet *rcvif; /* rcv interface */ > ^ > :836:8: > error: incomplete definition of type 'struct ifnet' > ifp->if_capenable |= IFCAP_TSO4; > ~~~^ > @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' > struct ifnet *rcvif; /* rcv interface */ > ^ > :840:7: > error: incomplete definition of type 'struct ifnet' > ifp->if_capenable |= (IFCAP_TXCSUM | > IFCAP_TSO4); > ~~~^ > @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' > struct ifnet *rcvif; /* rcv interface */ > ^ > :845:16: > error: incomplete definition of type 'struct ifnet' > } else if((ifp->if_capenable & IFCAP_TXCSUM) > ~~~^ > @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' > struct ifnet *rcvif; /* rcv interface */ > ^ > :846:14: > error: incomplete definition of type 'struct ifnet' > && !(ifp->if_capenable & IFCAP_TSO4)) { > ~~~^ > @/sys/mbuf.h:123:9: note: forward declaration of 'struct ifnet' > struct ifnet *rcvif; /* rcv interface */ > ^ > fatal error: too many errors emitted, stopping now [-ferror-limit=] > --- all_subdir_ixlv --- > 20 errors generated. > *** [if_ixlv.o] Error code 1 > > make[4]: stopped in > > 1 error > > make[4]: stopped in > > --- all_subdir_ixgbe --- > --- ixgbe_common.o --- > --- all_subdir_ixlv --- > *** [all_subdir_ixlv] Error code 2 > > make[3]: stopped in > > --- all_subdir_ixgbe --- > cc -O2 -pipe -DSMP -DIXGBE_FDIR -fno-strict-aliasing -Werror -D_KERNEL > -DKLD_MODULE -nostdinc -I > -DHAVE_KERNEL_OPTION_HEADERS -include > /usr/obj > -I. -I@ -I@/contrib/altq -fno-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer > -I/usr/obj -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Qunused-arguments -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parenthese>s-equality -Wno-error-unused-function -mno-aes -mno-avx -Qunused-arguments -c> --- all_subdir_isci ---> ctfconvert -L VERSION -g sati_start_stop_unit.o> A failure has been detected in another branch of the parallel make>> make[4]: stopped in> *** [all_subdir_isci] Error code 2>> make[3]: stopped in> --- all_subdir_ixl ---> 20 errors generated.> *** [if_ixl.o] Error code 1>> make[4]: stopped in> 1 error>> make[4]: stopped in> *** [all_subdir_ixl] Error code 2>> make[3]: stopped in> --- all_subdir_ixgbe ---> ctfconvert -L VERSION -g ixgbe_common.o> A failure has been detected in another branch of the parallel make>> make[4]: stopped in> *** [all_subdir_ixgbe] Error code 2>> make[3]: stopped in> 4 errors>> make[3]: stopped in> *** [modules-all] 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> _______________________________________________> freebsd-current@freebsd.org mailing list> http://lists.freebsd.org/mailman/listinfo/freebsd-current> To unsubscribe, send any mail to"freebsd-current-unsubscribe@freebsd.org"> From owner-freebsd-current@FreeBSD.ORG Thu Aug 28 22:58:35 2014 Return-Path: Delivered-To: freebsd-current@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 9DBFE26B; Thu, 28 Aug 2014 22:58:35 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 8AFFB1D81; Thu, 28 Aug 2014 22:58:35 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 9826328E; Thu, 28 Aug 2014 22:58:35 +0000 (UTC) Date: Thu, 28 Aug 2014 22:58:34 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, tijl@FreeBSD.org, smh@FreeBSD.org, rodrigc@FreeBSD.org, jfv@FreeBSD.org Message-ID: <25364403.14.1409266715465.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <2143128560.13.1409255600495.JavaMail.jenkins@jenkins-9.freebsd.org> References: <2143128560.13.1409255600495.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD #1335 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 22:58:35 -0000 See From owner-freebsd-current@FreeBSD.ORG Fri Aug 29 05:38:06 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF8FCF84 for ; Fri, 29 Aug 2014 05:38:06 +0000 (UTC) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) (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 BDA34153C for ; Fri, 29 Aug 2014 05:38:06 +0000 (UTC) Received: by mail-oa0-f47.google.com with SMTP id i7so1432344oag.20 for ; Thu, 28 Aug 2014 22:38:06 -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=n66VX5fnAOS76zj73feza9V7KBg6x6q5DyDljBhK0xg=; b=ovQqaMWkaOv0TvKPTbL0qqDFf3wcnI3eQ/ygH4S2yBo2h++9hvULrO6yaQfXxYQoe7 QYRe1mXAcdXwYCWd57ZJMtIz+qyMYknUqD24+U89pIown7w7QAPC+d8oJ+GTMcXE7h5d EVBmXp/UHwkYZvSFvwsOEOLH506RMfjhhaohJ0YUyUsXD7jk+kdemcS0NO0eR03IPVcG sigoI6gkDWnlPZZBEps+9/fbg3w3zcCdLLHtOjKSvmNfICIdko2mtLP+kalm+tehs1Yg AMxJCoz7nQ5TlwkPR1BHVrMnq9ECuHokp1eqbfDXKDlXFTmrbe82XjqtQnii1gpl+Jtj 20Vw== MIME-Version: 1.0 X-Received: by 10.60.145.143 with SMTP id su15mr8369116oeb.58.1409290686074; Thu, 28 Aug 2014 22:38:06 -0700 (PDT) Received: by 10.202.105.4 with HTTP; Thu, 28 Aug 2014 22:38:06 -0700 (PDT) Date: Thu, 28 Aug 2014 22:38:06 -0700 Message-ID: Subject: i386 compilation errors in head/sys/dev/ixl/if_ixl.c From: David Shao To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Fri, 29 Aug 2014 11:33:49 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 05:38:07 -0000 Compilation errors occur in head/sys/dev/ixl/if_ixl.c on i386 for FreeBSD 11-current for the following: In function ixl_print_debug_info() printf("Queue irqs = %lx\n", que->irqs); printf("AdminQ irqs = %lx\n", pf->admin_irq); ... printf("RX not ready = %lx\n", rxr->not_done); printf("RX packets = %lx\n", rxr->rx_packets); all cause error: format specifies type 'unsigned long' but the argument has type 'u64' (aka 'unsigned long long') [-Werror,-Wformat] In function ixl_stat_update48(struct i40e_hw *hw, u32 hireg, u32 loreg, bool offset_loaded, u64 *offset, u64 *stat) #if __FreeBSD__ >= 10 && __amd64__ causes error: '__amd64__' is not defined, evaluates to 0 [-Werror,-Wundef] From owner-freebsd-current@FreeBSD.ORG Fri Aug 29 12:02:55 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5551F08 for ; Fri, 29 Aug 2014 12:02:55 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id A9AD51234 for ; Fri, 29 Aug 2014 12:02:55 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id E07F720E7088B; Fri, 29 Aug 2014 12:02:52 +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 12BBD20E70886; Fri, 29 Aug 2014 12:02:47 +0000 (UTC) Message-ID: From: "Steven Hartland" To: "David Shao" , References: Subject: Re: i386 compilation errors in head/sys/dev/ixl/if_ixl.c Date: Fri, 29 Aug 2014 13:02:44 +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-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 12:02:56 -0000 Looks like this was already fixed by: http://svnweb.freebsd.org/changeset/base/270799 Regards Steve ----- Original Message ----- From: "David Shao" To: Sent: Friday, August 29, 2014 6:38 AM Subject: i386 compilation errors in head/sys/dev/ixl/if_ixl.c > Compilation errors occur in head/sys/dev/ixl/if_ixl.c on i386 for > FreeBSD 11-current for the following: > > In function ixl_print_debug_info() > > printf("Queue irqs = %lx\n", que->irqs); > printf("AdminQ irqs = %lx\n", pf->admin_irq); > ... > printf("RX not ready = %lx\n", rxr->not_done); > printf("RX packets = %lx\n", rxr->rx_packets); > > all cause > error: format specifies type 'unsigned long' but the argument has type > 'u64' (aka 'unsigned long long') [-Werror,-Wformat] > > In function ixl_stat_update48(struct i40e_hw *hw, u32 hireg, u32 > loreg, > bool offset_loaded, u64 *offset, u64 *stat) > > > #if __FreeBSD__ >= 10 && __amd64__ > > causes > error: '__amd64__' is not defined, evaluates to 0 [-Werror,-Wundef] > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Fri Aug 29 12:55:50 2014 Return-Path: Delivered-To: freebsd-current@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 20FBA75C; Fri, 29 Aug 2014 12:55:50 +0000 (UTC) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C61F51965; Fri, 29 Aug 2014 12:55:49 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 5677C25D388C; Fri, 29 Aug 2014 12:55:46 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 583CCC77087; Fri, 29 Aug 2014 12:55:45 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id PdVK6H3S4Doj; Fri, 29 Aug 2014 12:55:44 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id C91B3C77086; Fri, 29 Aug 2014 12:55:42 +0000 (UTC) Subject: Re: i386 compilation errors in head/sys/dev/ixl/if_ixl.c Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: "Bjoern A. Zeeb" X-Priority: 3 In-Reply-To: Date: Fri, 29 Aug 2014 12:55:40 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Steven Hartland X-Mailer: Apple Mail (2.1878.6) Cc: Jack F Vogel , David Shao , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 12:55:50 -0000 On 29 Aug 2014, at 12:02 , Steven Hartland = wrote: > Looks like this was already fixed by: > http://svnweb.freebsd.org/changeset/base/270799 Yes, just before I closed the bugreport. There=92s a few more follow-up commits that (if I didn=92t screw up) = should make things at least compile now. To which extends some things = work I have no idea. /bz =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From owner-freebsd-current@FreeBSD.ORG Fri Aug 29 13:33:31 2014 Return-Path: Delivered-To: freebsd-current@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 7F0E6B36; Fri, 29 Aug 2014 13:33:31 +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 3DCA31DA2; Fri, 29 Aug 2014 13:33:30 +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 s7TDXT6n038920; Fri, 29 Aug 2014 06:33:29 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id s7TDXS18038919; Fri, 29 Aug 2014 06:33:28 -0700 (PDT) (envelope-from david) Date: Fri, 29 Aug 2014 06:33:28 -0700 From: David Wolfskill To: "Bjoern A. Zeeb" Subject: Re: i386 compilation errors in head/sys/dev/ixl/if_ixl.c Message-ID: <20140829133328.GB1408@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , "Bjoern A. Zeeb" , Steven Hartland , Jack F Vogel , David Shao , freebsd-current@freebsd.org References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="P6d3k5Edf9pZm0D3" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Jack F Vogel , David Shao , freebsd-current@freebsd.org, Steven Hartland X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 13:33:31 -0000 --P6d3k5Edf9pZm0D3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 29, 2014 at 12:55:40PM +0000, Bjoern A. Zeeb wrote: >=20 > On 29 Aug 2014, at 12:02 , Steven Hartland wrot= e: >=20 > > Looks like this was already fixed by: > > http://svnweb.freebsd.org/changeset/base/270799 >=20 > Yes, just before I closed the bugreport. >=20 > There?s a few more follow-up commits that (if I didn?t screw up) should m= ake things at least compile now. To which extends some things work I have = no idea. > .... Err.... I think I'm seeing this (or a related) problem @r270799: >>> Kernel build for CANARY started on Fri Aug 29 06:17:52 PDT 2014 =2E.ll_subdir_ixlv --- --- if_ixlv.o --- clang -O2 -pipe -DSMP -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE = -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /common/S4/obj/usr/src/sy= s/CANARY/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -g -I/common/S4/= obj/usr/src/sys/CANARY -mno-mmx -mno-sse -msoft-float -ffreestanding -fsta= ck-protector -gdwarf-2 -mno-aes -mno-avx -Qunused-arguments -std=3Diso9899:= 1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-pr= ototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wunde= f -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnosti= cs-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno= -error-parentheses-equality -Wno-error-unused-function -mno-aes -mno-avx -= Qunused-arguments -c /usr/src/sys/modules/ixlv/../../dev/ixl/if_ixlv.c --- all_subdir_ixl --- /usr/src/sys/modules/ixl/../../dev/ixl/i40e_osdep.c:66:1: error: conflictin= g types for 'i40e_allocate_dma' i40e_allocate_dma(struct i40e_hw *hw, struct i40e_dma_mem *dma, ^ /usr/src/sys/modules/ixl/../../dev/ixl/i40e_alloc.h:54:23: note: previous d= eclaration is here enum i40e_status_code i40e_allocate_dma_mem(struct i40e_hw *hw, ^ /usr/src/sys/modules/ixl/../../dev/ixl/i40e_osdep.h:169:51: note: expanded = =66rom macro 'i40e_allocate_dma_mem' #define i40e_allocate_dma_mem(h, m, unused, s, a) i40e_allocate_dma(h, m, s= , a) ^ 1 error generated. *** [i40e_osdep.o] Error code 1 make[4]: stopped in /usr/src/sys/modules/ixl --- all_subdir_ixgbe --- --- ixgbe_common.o --- ctfconvert -L VERSION -g ixgbe_common.o A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/sys/modules/ixgbe *** [all_subdir_ixgbe] Error code 2 make[3]: stopped in /usr/src/sys/modules --- all_subdir_ixlv --- ctfconvert -L VERSION -g if_ixlv.o A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/sys/modules/ixlv *** [all_subdir_ixlv] Error code 2 make[3]: stopped in /usr/src/sys/modules --- all_subdir_ixl --- --- if_ixl.o --- ctfconvert -L VERSION -g if_ixl.o 1 error make[4]: stopped in /usr/src/sys/modules/ixl *** [all_subdir_ixl] Error code 2 make[3]: stopped in /usr/src/sys/modules 3 errors make[3]: stopped in /usr/src/sys/modules *** [modules-all] Error code 2 make[2]: stopped in /common/S4/obj/usr/src/sys/CANARY 1 error make[2]: stopped in /common/S4/obj/usr/src/sys/CANARY *** [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 =2E >>> stage 3.2: building everything =2E.. Running: FreeBSD g1-235.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1354 r270= 745M/270748:1100029: Thu Aug 28 06:35:04 PDT 2014 root@g1-235.catwhiske= r.org:/common/S4/obj/usr/src/sys/CANARY i386 with sources: g1-235(11.0-C)[1] svn info /usr/src Path: /usr/src Working Copy Root Path: /usr/src URL: file:///svn/freebsd/src/base/head Relative URL: ^/head Repository Root: file:///svn/freebsd/src/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 270801 Node Kind: directory Schedule: normal Last Changed Author: bz Last Changed Rev: 270799 Last Changed Date: 2014-08-29 02:37:18 -0700 (Fri, 29 Aug 2014) g1-235(11.0-C)[2]=20 (First encountered during my usual "-DNOCLEAN" build, so I tried (just the kernnel) again without -DNOCLEAN; the latter is what I quoted above.) 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. --P6d3k5Edf9pZm0D3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUAIEmXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7m4IP/2J9/22dnNYrBy3AFn00iwN+ Lj6fuTkdnQtmrWs07/FmtrXREi3R63WNlShQuHuAs43XqAEc2gupGPscoWg7R1h1 h5b4I56jUJc9MdBhBgjc1+xnkQFqLSk/x9HqlxpzYyKeivT0oF43y5QVZGiD7uWy loz8pcDmCa/GrTCVGeoUjuVtp4kBsi2XW08NmooaV2lLPalOVK76JOV8uZ2Q1n6T a0xNxgzykTES5J2qiK/+tHIebAUSSopVjWZI6dlGymVXv4LPb95bFwcxgbv3bZLf AQdMEkM7Lir3XPkg7XHWgDlinkI3oRXOH6oDVzWOe4kBcW/XdF3x4QbA7VdZiao6 QUw2It3N/wLMv/UFGn3Psku3zZNNjnFzCH9NzpQne8X/qI3ArjW/MuxoIsjODHBF jwwzqW8j4XtOROUGg8Q9MgxtO94CO3jchodrs9sYko+IRsEzbgjKaweF04vSmP7J 4xX4VG+naD2+c2d821iZcCQR21mZv4S8KrXBo/TtgI5ng6cyQtnMcwCvEAHNATnp lqMjyGbZirJ3UHC7wEjpJ1W6cbpnGHWCNconEsFXRDDZbs9gkgDp/SXjxX3VDuma Fu7LrHgbf3jbE1hYe+ci3JinFXxncjDA0HgVDnQzowyMPWM1ePsLJE6axaO+2nVD rJGQ6qsm1joPb9/+tCb+ =Z3Xu -----END PGP SIGNATURE----- --P6d3k5Edf9pZm0D3-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 29 14:02:39 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D23B77ED for ; Fri, 29 Aug 2014 14:02:39 +0000 (UTC) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5A27E112F for ; Fri, 29 Aug 2014 14:02:39 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 912FF25D3871; Fri, 29 Aug 2014 14:02:36 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id A24F3C77087; Fri, 29 Aug 2014 14:02:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id W-TCyiPq5XbU; Fri, 29 Aug 2014 14:02:34 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 007F8C77086; Fri, 29 Aug 2014 14:02:32 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: i386 compilation errors in head/sys/dev/ixl/if_ixl.c From: "Bjoern A. Zeeb" In-Reply-To: <20140829133328.GB1408@albert.catwhisker.org> Date: Fri, 29 Aug 2014 14:02:30 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <3605C0F9-D1A0-42F4-BCCF-A6C74F45D547@FreeBSD.org> References: <20140829133328.GB1408@albert.catwhisker.org> To: David Wolfskill X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 14:02:40 -0000 On 29 Aug 2014, at 13:33 , David Wolfskill wrote: > On Fri, Aug 29, 2014 at 12:55:40PM +0000, Bjoern A. Zeeb wrote: >>=20 >> On 29 Aug 2014, at 12:02 , Steven Hartland = wrote: >>=20 >>> Looks like this was already fixed by: >>> http://svnweb.freebsd.org/changeset/base/270799 >>=20 >> Yes, just before I closed the bugreport. >>=20 >> There?s a few more follow-up commits that (if I didn?t screw up) = should make things at least compile now. To which extends some things = work I have no idea. >> .... >=20 > Err.... I think I'm seeing this (or a related) problem @r270799: >=20 >>>> Kernel build for CANARY started on Fri Aug 29 06:17:52 PDT 2014 > ..ll_subdir_ixlv --- > --- if_ixlv.o --- > clang -O2 -pipe -DSMP -fno-strict-aliasing -Werror -D_KERNEL = -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include = /common/S4/obj/usr/src/sys/CANARY/opt_global.h -I. -I@ -I@/contrib/altq = -fno-common -g -I/common/S4/obj/usr/src/sys/CANARY -mno-mmx -mno-sse = -msoft-float -ffreestanding -fstack-protector -gdwarf-2 -mno-aes = -mno-avx -Qunused-arguments -std=3Diso9899:1999 -fstack-protector -Wall = -Wredundant-decls -Wnested-externs -Wstrict-prototypes = -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef = -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs = -fdiagnostics-show-option -Wno-error-tautological-compare = -Wno-error-empty-body -Wno-error-parentheses-equality = -Wno-error-unused-function -mno-aes -mno-avx -Qunused-arguments -c = /usr/src/sys/modules/ixlv/../../dev/ixl/if_ixlv.c > --- all_subdir_ixl --- > /usr/src/sys/modules/ixl/../../dev/ixl/i40e_osdep.c:66:1: error: = conflicting types for 'i40e_allocate_dma' > i40e_allocate_dma(struct i40e_hw *hw, struct i40e_dma_mem *dma, > ^ > /usr/src/sys/modules/ixl/../../dev/ixl/i40e_alloc.h:54:23: note: = previous declaration is here > enum i40e_status_code i40e_allocate_dma_mem(struct i40e_hw *hw, > ^ > /usr/src/sys/modules/ixl/../../dev/ixl/i40e_osdep.h:169:51: note: = expanded from macro 'i40e_allocate_dma_mem' > #define i40e_allocate_dma_mem(h, m, unused, s, a) i40e_allocate_dma(h, = m, s, a) svn update; that was fixed There is one more on powerpc and then a couple of unrelated infiband = changes =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From owner-freebsd-current@FreeBSD.ORG Fri Aug 29 19:37:46 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5245854C; Fri, 29 Aug 2014 19:37:46 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 3E40A1C0C; Fri, 29 Aug 2014 19:37:46 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 8864E49E; Fri, 29 Aug 2014 19:37:46 +0000 (UTC) Date: Fri, 29 Aug 2014 19:37:45 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, jhb@FreeBSD.org, melifaro@FreeBSD.org Message-ID: <1967071676.17.1409341066253.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #1342 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 19:37:46 -0000 See Changes: [jhb] Use a unit number allocator to provide suitable st_dev and st_ino values for POSIX shared memory descriptors. The implementation is similar to that used for pipes. MFC after: 1 week [melifaro] * Add SIOCGI2C driver ioctl used to retrieve i2c info. * Convert ixgbe to use this ioctl * Convert ifconfig to use generic i2c handler for "ix" interfaces. Approved by: Eric Joyner (ixgbe part) MFC after: 2 weeks Sponsored by: Yandex LLC ------------------------------------------ [...truncated 270113 lines...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- nfs_clnfsiod.o --- ctfconvert -L VERSION -g nfs_clnfsiod.o --- nfs_fha_new.o --- ctfconvert -L VERSION -g nfs_fha_new.o --- nfs_nfsdstate.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- nfs_nfsdkrpc.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- nfs_nfsdsocket.o --- ctfconvert -L VERSION -g nfs_nfsdsocket.o --- nfs_nfsdserv.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- nfs_nfsdsubs.o --- ctfconvert -L VERSION -g nfs_nfsdsubs.o --- nfs_nfsdport.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- nfs_nfsdkrpc.o --- ctfconvert -L VERSION -g nfs_nfsdkrpc.o --- nfs_nfsdcache.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror ctfconvert -L VERSION -g nfs_nfsdcache.o --- procfs.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror ctfconvert -L VERSION -g procfs.o --- procfs_map.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- nfs_nfsdport.o --- ctfconvert -L VERSION -g nfs_nfsdport.o --- nfs_nfsdserv.o --- ctfconvert -L VERSION -g nfs_nfsdserv.o --- procfs_map.o --- ctfconvert -L VERSION -g procfs_map.o --- pseudofs.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- pseudofs_vncache.o --- --- nfs_nfsdstate.o --- ctfconvert -L VERSION -g nfs_nfsdstate.o --- pseudofs_vncache.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- pseudofs_vnops.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- geom_vfs.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- pseudofs_vncache.o --- ctfconvert -L VERSION -g pseudofs_vncache.o --- pseudofs.o --- ctfconvert -L VERSION -g pseudofs.o --- cd9660_bmap.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- cd9660_lookup.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- geom_vfs.o --- ctfconvert -L VERSION -g geom_vfs.o --- cd9660_node.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- cd9660_bmap.o --- ctfconvert -L VERSION -g cd9660_bmap.o --- cd9660_rrip.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- pseudofs_vnops.o --- ctfconvert -L VERSION -g pseudofs_vnops.o --- cd9660_util.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- cd9660_lookup.o --- ctfconvert -L VERSION -g cd9660_lookup.o --- cd9660_vfsops.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- cd9660_node.o --- ctfconvert -L VERSION -g cd9660_node.o --- cd9660_vnops.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- cd9660_util.o --- ctfconvert -L VERSION -g cd9660_util.o --- imgact_elf.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- cd9660_rrip.o --- ctfconvert -L VERSION -g cd9660_rrip.o --- imgact_elf32.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- cd9660_vfsops.o --- ctfconvert -L VERSION -g cd9660_vfsops.o --- cd9660_vnops.o --- ctfconvert -L VERSION -g cd9660_vnops.o --- imgact_shell.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- init_main.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- imgact_shell.o --- ctfconvert -L VERSION -g imgact_shell.o --- kern_acct.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- imgact_elf.o --- ctfconvert -L VERSION -g imgact_elf.o --- kern_conf.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- imgact_elf32.o --- ctfconvert -L VERSION -g imgact_elf32.o --- init_main.o --- ctfconvert -L VERSION -g init_main.o --- kern_cons.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_descrip.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_acct.o --- ctfconvert -L VERSION -g kern_acct.o --- kern_exec.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_cons.o --- ctfconvert -L VERSION -g kern_cons.o --- kern_exit.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_conf.o --- ctfconvert -L VERSION -g kern_conf.o --- kern_fork.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_exec.o --- ctfconvert -L VERSION -g kern_exec.o --- kern_jail.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_exit.o --- ctfconvert -L VERSION -g kern_exit.o --- kern_ktrace.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_fork.o --- ctfconvert -L VERSION -g kern_fork.o --- kern_lockf.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_descrip.o --- ctfconvert -L VERSION -g kern_descrip.o --- kern_mib.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror ctfconvert -L VERSION -g kern_mib.o --- kern_ktrace.o --- ctfconvert -L VERSION -g kern_ktrace.o --- kern_proc.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_shutdown.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_lockf.o --- ctfconvert -L VERSION -g kern_lockf.o --- kern_sig.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_shutdown.o --- ctfconvert -L VERSION -g kern_shutdown.o --- kern_time.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_jail.o --- ctfconvert -L VERSION -g kern_jail.o --- posix4_mib.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_proc.o --- ctfconvert -L VERSION -g kern_proc.o --- subr_acl_nfs4.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- posix4_mib.o --- ctfconvert -L VERSION -g posix4_mib.o --- subr_acl_posix1e.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_time.o --- ctfconvert -L VERSION -g kern_time.o --- subr_firmware.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_sig.o --- ctfconvert -L VERSION -g kern_sig.o --- subr_acl_posix1e.o --- ctfconvert -L VERSION -g subr_acl_posix1e.o --- subr_log.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- subr_uio.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- subr_acl_nfs4.o --- ctfconvert -L VERSION -g subr_acl_nfs4.o --- sys_generic.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- subr_firmware.o --- ctfconvert -L VERSION -g subr_firmware.o --- subr_log.o --- ctfconvert -L VERSION -g subr_log.o --- sys_pipe.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- sys_process.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- subr_uio.o --- ctfconvert -L VERSION -g subr_uio.o --- tty.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- sys_process.o --- ctfconvert -L VERSION -g sys_process.o --- tty_tty.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- sys_generic.o --- ctfconvert -L VERSION -g sys_generic.o --- tty_ttydisc.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- sys_pipe.o --- ctfconvert -L VERSION -g sys_pipe.o --- uipc_shm.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- tty_tty.o --- ctfconvert -L VERSION -g tty_tty.o --- uipc_syscalls.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- tty.o --- ctfconvert -L VERSION -g tty.o --- uipc_usrreq.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- uipc_shm.o --- :415:22: error: no member named 'shm_ino' in 'struct shmfd' sb->st_ino = shmfd->shm_ino; ~~~~~ ^ :566:10: error: no member named 'shm_ino' in 'struct shmfd' shmfd->shm_ino = 0; ~~~~~ ^ :568:10: error: no member named 'shm_ino' in 'struct shmfd' shmfd->shm_ino = ino; ~~~~~ ^ :599:14: error: no member named 'shm_ino' in 'struct shmfd' if (shmfd->shm_ino != 0) ~~~~~ ^ :600:33: error: no member named 'shm_ino' in 'struct shmfd' free_unr(shm_ino_unr, shmfd->shm_ino); ~~~~~ ^ 5 errors generated. *** [uipc_shm.o] Error code 1 make[2]: stopped in /usr/obj --- tty_ttydisc.o --- ctfconvert -L VERSION -g tty_ttydisc.o --- uipc_usrreq.o --- ctfconvert -L VERSION -g uipc_usrreq.o --- uipc_syscalls.o --- ctfconvert -L VERSION -g uipc_syscalls.o 1 error make[2]: stopped in /usr/obj *** [buildkernel] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildkernel] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Fri Aug 29 22:59:51 2014 Return-Path: Delivered-To: freebsd-current@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 760ED725; Fri, 29 Aug 2014 22:59:51 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 637F616A8; Fri, 29 Aug 2014 22:59:51 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id CF7744DE; Fri, 29 Aug 2014 22:59:51 +0000 (UTC) Date: Fri, 29 Aug 2014 22:59:51 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, jhb@FreeBSD.org, melifaro@FreeBSD.org Message-ID: <1421575126.18.1409353191810.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1967071676.17.1409341066253.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1967071676.17.1409341066253.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD #1343 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 22:59:51 -0000 See From owner-freebsd-current@FreeBSD.ORG Sat Aug 30 17:30:15 2014 Return-Path: Delivered-To: freebsd-current@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 0C78D19A; Sat, 30 Aug 2014 17:30:15 +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 D2B911235; Sat, 30 Aug 2014 17:30:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=fzwQKIgrH/eSRvCqRw2o75vdLLqIKQDDOaHNpKeX+x4=; b=uh2DmiAmC5ex91qnIkvm/kJYhW4eolicJxwm9bnjY19B8EoZVa/LsC497HlDPqhrk1LMtVgX5/PKb0NLQ18kzmQP7Hd9gTNiNmoOOdHrwVlVKnbxh45XruJZC4xeh/YP2kA2Rh7EzgZ1k5CC2G0x5vO5faFAtBpnYN3u1Vl5rMI=; Received: from 104-54-221-134.lightspeed.austtx.sbcglobal.net ([104.54.221.134]:39214 helo=borg.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XNmTZ-000MZz-RU; Sat, 30 Aug 2014 12:30:13 -0500 Date: Sat, 30 Aug 2014 12:29:58 -0500 From: Larry Rosenman To: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Solaris Assert: How to fix? Message-ID: <20140830172958.GA99694@borg.lerctr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, TVD_RCVD_IP=0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, TVD_RCVD_IP=0.001 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2014 17:30:15 -0000 I'm getting: borg.lerctr.org dumped core - see /var/crash/vmcore.0 Fri Aug 29 16:16:35 CDT 2014 FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r270811: Fri Aug 29 09:21:58 CDT 2014 root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 panic: solaris assert: l->l_phys->l_hdr.lh_block_type == ((1ULL << 63) + 0) (0x0 == 0x8000000000000000), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c, line: 534 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #0 r270811: Fri Aug 29 09:21:58 CDT 2014 root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 VT: running with driver "vga". info: [drm] Initialized drm 1.1.0 20060810 CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz (2327.55-MHz K8-class CPU) Origin="GenuineIntel" Id=0x10676 Family=0x6 Model=0x17 Stepping=6 Features=0xbfebfbff Features2=0xce3bd AMD Features=0x20100800 AMD Features2=0x1 VT-x: HLT,PAUSE TSC: P-state invariant, performance statistics real memory = 68719476736 (65536 MB) avail memory = 65627250688 (62587 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 random: initialized module_register_init: MOD_LOAD (vesa, 0xffffffff80e94c10, 0) error 19 cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) unknown: I/O range not supported cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 350 Event timer "HPET1" frequency 14318180 Hz quality 340 Event timer "HPET2" frequency 14318180 Hz quality 340 atrtc0: port 0x70-0x71 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 0.0 on pci1 pci2: on pcib2 pcib3: irq 16 at device 0.0 on pci2 pci3: on pcib3 pcib4: at device 0.0 on pci3 pci4: on pcib4 pcib5: at device 0.2 on pci3 pci5: on pcib5 pcib6: irq 18 at device 2.0 on pci2 pci6: on pcib6 em0: port 0x2000-0x201f mem 0xd9220000-0xd923ffff,0xd9200000-0xd921ffff irq 18 at device 0.0 on pci6 em0: Using an MSI interrupt em0: Ethernet address: 00:30:48:f2:29:9c em1: port 0x2020-0x203f mem 0xd9260000-0xd927ffff,0xd9240000-0xd925ffff irq 19 at device 0.1 on pci6 em1: Using an MSI interrupt em1: Ethernet address: 00:30:48:f2:29:9d pcib7: at device 0.3 on pci1 pci7: on pcib7 pcib8: at device 4.0 on pci0 pci8: on pcib8 vgapci0: port 0x3000-0x307f mem 0xd8000000-0xd8ffffff,0xc0000000-0xc7ffffff,0xc8000000-0xc9ffffff irq 16 at device 0.0 on pci8 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io hdac0: mem 0xd9000000-0xd9003fff irq 17 at device 0.1 on pci8 pcib9: at device 6.0 on pci0 pci9: on pcib9 pcib10: irq 17 at device 28.0 on pci0 pci10: on pcib10 pcib11: irq 16 at device 0.0 on pci10 pci11: on pcib11 pcm0: port 0x4080-0x409f,0x4000-0x407f irq 16 at device 0.0 on pci11 pcm0: system configuration SubVendorID: 0x1412, SubDeviceID: 0x2403 XIN2 Clock Source: 24.576MHz(96kHz*256) MPU-401 UART(s) #: not implemented ADC #: 1 and SPDIF receiver connected DAC #: 4 Multi-track converter type: AC'97(SDATA_OUT:packed) S/PDIF(IN/OUT): 1/1 ID# 0x00 GPIO(mask/dir/state): 0xff/0xff/0xff uhci0: port 0x1800-0x181f irq 17 at device 29.0 on pci0 usbus0 on uhci0 uhci1: port 0x1820-0x183f irq 19 at device 29.1 on pci0 usbus1 on uhci1 uhci2: port 0x1840-0x185f irq 18 at device 29.2 on pci0 usbus2 on uhci2 ehci0: mem 0xd9600400-0xd96007ff irq 17 at device 29.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 pcib12: at device 30.0 on pci0 pci12: on pcib12 vgapci1: port 0x5000-0x50ff mem 0xd0000000-0xd7ffffff,0xd9300000-0xd930ffff irq 18 at device 1.0 on pci12 drmn1: on vgapci1 info: [drm] RADEON_IS_PCI info: [drm] initializing kernel modesetting (RV100 0x1002:0x515E 0x15D9:0x8080). info: [drm] register mmio base: 0xD9300000 info: [drm] register mmio size: 65536 info: [drm] radeon_atrm_get_bios: ===> Try ATRM... info: [drm] radeon_atrm_get_bios: pci_find_class() found: 0:8:0:0, vendor=10de, device=104a info: [drm] radeon_atrm_get_bios: Get ACPI device handle info: [drm] radeon_acpi_vfct_bios: ===> Try VFCT... info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_FOUND info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM... info: [drm] igp_read_bios_from_vram: VRAM base address: 0xd0000000 info: [drm] igp_read_bios_from_vram: Map address: 0xfffff800d0000000 (262144 bytes) info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0x0000 info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... info: [drm] radeon_read_bios: Map address: 0xfffff800000c0000 (131072 bytes) drmn1: info: VRAM: 128M 0x00000000D0000000 - 0x00000000D7FFFFFF (16M used) drmn1: info: GTT: 512M 0x00000000B0000000 - 0x00000000CFFFFFFF info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. info: [drm] radeon: irq initialized. info: [drm] Detected VRAM RAM=128M, BAR=128M info: [drm] RAM width 64bits SDR [TTM] Zone kernel: Available graphics memory: 33001600 kiB [TTM] Zone dma32: Available graphics memory: 2097152 kiB [TTM] Initializing pool allocator info: [drm] radeon: 16M of VRAM memory ready info: [drm] radeon: 512M of GTT memory ready. info: [drm] GART: num cpu pages 131072, num gpu pages 131072 info: [drm] PCI GART of 512M enabled (table at 0x0000000010CF6000). drmn1: info: WB disabled drmn1: info: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0x0xfffff800118de000 info: [drm] Loading R100 Microcode info: [drm] radeon: ring at 0x00000000B0001000 info: [drm] ring test succeeded in 1 usecs info: [drm] ib test succeeded in 0 usecs info: [drm] radeon_device_init: Taking over the fictitious range 0xd0000000-0xd4000000 iicbus0: on iicbb0 addr 0xff iic0: on iicbus0 iicbus1: on iicbb1 addr 0x0 iic1: on iicbus1 iicbus2: on iicbb2 addr 0x0 iic2: on iicbus2 iicbus3: on iicbb3 addr 0x0 iic3: on iicbus3 info: [drm] Radeon Display Connectors info: [drm] Connector 0: info: [drm] VGA-1 info: [drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60 info: [drm] Encoders: info: [drm] CRT1: INTERNAL_DAC1 info: [drm] Connector 1: info: [drm] DVI-I-1 info: [drm] HPD2 info: [drm] DDC: 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c info: [drm] Encoders: info: [drm] CRT2: INTERNAL_DAC2 info: [drm] DFP2: INTERNAL_DVO1 composite sync not supported composite sync not supported info: [drm] fb mappable at 0xD0040000 info: [drm] vram apper at 0xD0000000 info: [drm] size 2076672 info: [drm] fb depth is 8 info: [drm] pitch is 1920 fbd1 on drmn1 VT: Replacing driver "vga" with new "fb". info: [drm] Initialized radeon 2.29.0 20080528 vgapci1: Boot video device isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: at channel 0 on atapci0 ahci0: port 0x18a0-0x18a7,0x1874-0x1877,0x1878-0x187f,0x1870-0x1873,0x1880-0x189f mem 0xd9600800-0xd9600bff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.10 with 6 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ichsmb0: port 0x1100-0x111f irq 19 at device 31.3 on pci0 smbus0: on ichsmb0 acpi_button0: on acpi0 ipmi0: port 0xca2-0xca3 on acpi0 ipmi0: KCS mode found at io 0xca2 on acpi atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ichwd0 on isa0 orm0: at iomem 0xc0000-0xcafff on isa0 coretemp0: on cpu0 est0: on cpu0 coretemp1: on cpu1 est1: on cpu1 coretemp2: on cpu2 est2: on cpu2 coretemp3: on cpu3 est3: on cpu3 coretemp4: on cpu4 est4: on cpu4 coretemp5: on cpu5 est5: on cpu5 coretemp6: on cpu6 est6: on cpu6 coretemp7: on cpu7 est7: on cpu7 random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec vboxdrv: fAsync=0 offMin=0x444 offMax=0x690 hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm1: at nid 4 on hdaa0 pcm2: at nid 5 on hdaa0 ugen0.1: at usbus0 uhub0: on usbus0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen3.1: at usbus3 uhub1: on usbus3 ugen2.1: at usbus2 uhub2: on usbus2 ugen1.1: at usbus1 uhub3: on usbus1 ipmi0: IPMI device rev. 1, firmware rev. 1.64, version 2.0 ata0: DMA limited to UDMA33, controller found non-ATA66 cable ipmi0: Number of channels 8 ipmi0: Attached watchdog uhub0: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: Serial Number 5YDA1ZL4 ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada0: quirks=0x1<4K> ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus2 target 0 lun 0 ada1: ATA-8 SATA 3.x device ada1: Serial Number 5YD6FPLG ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada1: quirks=0x1<4K> ada1: Previously was known as ad6 ada2 at ahcich2 bus 0 scbus3 target 0 lun 0 ada2: ATA-8 SATA 3.x device ada2: Serial Number 5YDA3PC5 ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada2: quirks=0x1<4K> ada2: Previously was known as ad8 ada3 at ahcich3 bus 0 scbus4 target 0 lun 0 ada3: ATA-8 SATA 3.x device ada3: Serial Number 5YD9Y0P4 ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada3: quirks=0x1<4K> ada3: Previously was known as ad10 ada4 at ahcich4 bus 0 scbus5 target 0 lun 0 ada4: ATA-8 SATA 3.x device ada4: Serial Number 5YDA1R5W ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada4: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada4: quirks=0x1<4K> ada4: Previously was known as ad12 ada5 at ahcich5 bus 0 scbus6 target 0 lun 0 ada5: ATA-8 SATA 3.x device ada5: Serial Number 5YD5RBS8 ada5: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada5: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada5: quirks=0x1<4K> ada5: Previously was known as ad14 cd0 at ata0 bus 0 scbus0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present SMP: AP CPU #4 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #7 Launched! Root mount waiting for: usbus3 uhub1: 6 ports with 6 removable, self powered Root mount waiting for: usbus3 Root mount waiting for: usbus3 ugen3.2: at usbus3 ukbd0: on usbus3 kbd2 at ukbd0 Trying to mount root from zfs:zroot/ROOT/default []... ugen0.2: at usbus0 <118>Setting hostuuid: 53d19f64-d663-a017-8922-0030488e9ff3. <118>Setting hostid: 0xf53a926e. <118>Entropy harvesting: interrupts ethernet point_to_point swi. <118>Starting file system checks: <118>Mounting local file systems:. panic: solaris assert: l->l_phys->l_hdr.lh_block_type == ((1ULL << 63) + 0) (0x0 == 0x8000000000000000), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c, line: 534 cpuid = 5 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe100be1d040 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe100be1d0f0 vpanic() at vpanic+0x189/frame 0xfffffe100be1d170 panic() at panic+0x43/frame 0xfffffe100be1d1d0 assfail3() at assfail3+0x2f/frame 0xfffffe100be1d1f0 zap_get_leaf_byblk() at zap_get_leaf_byblk+0x4e0/frame 0xfffffe100be1d240 zap_deref_leaf() at zap_deref_leaf+0xd3/frame 0xfffffe100be1d290 fzap_cursor_retrieve() at fzap_cursor_retrieve+0xf1/frame 0xfffffe100be1d300 zap_cursor_retrieve() at zap_cursor_retrieve+0x20d/frame 0xfffffe100be1d390 ddt_zap_walk() at ddt_zap_walk+0x53/frame 0xfffffe100be1d640 ddt_walk() at ddt_walk+0x79/frame 0xfffffe100be1d670 dsl_scan_sync() at dsl_scan_sync+0x8e7/frame 0xfffffe100be1d9d0 spa_sync() at spa_sync+0x5c1/frame 0xfffffe100be1dac0 txg_sync_thread() at txg_sync_thread+0x24d/frame 0xfffffe100be1dbb0 fork_exit() at fork_exit+0x84/frame 0xfffffe100be1dbf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe100be1dbf0 --- trap 0, rip = 0, rsp = 0xfffffe100be1dcb0, rbp = 0 --- Uptime: 14s Dumping 2340 out of 64456 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/linux.ko.symbols...done. Loaded symbols for /boot/kernel/linux.ko.symbols Reading symbols from /boot/kernel/if_lagg.ko.symbols...done. Loaded symbols for /boot/kernel/if_lagg.ko.symbols Reading symbols from /boot/kernel/snd_envy24ht.ko.symbols...done. Loaded symbols for /boot/kernel/snd_envy24ht.ko.symbols Reading symbols from /boot/kernel/snd_spicds.ko.symbols...done. Loaded symbols for /boot/kernel/snd_spicds.ko.symbols Reading symbols from /boot/kernel/coretemp.ko.symbols...done. Loaded symbols for /boot/kernel/coretemp.ko.symbols Reading symbols from /boot/kernel/ichsmb.ko.symbols...done. Loaded symbols for /boot/kernel/ichsmb.ko.symbols Reading symbols from /boot/kernel/smbus.ko.symbols...done. Loaded symbols for /boot/kernel/smbus.ko.symbols Reading symbols from /boot/kernel/ichwd.ko.symbols...done. Loaded symbols for /boot/kernel/ichwd.ko.symbols Reading symbols from /boot/kernel/cpuctl.ko.symbols...done. Loaded symbols for /boot/kernel/cpuctl.ko.symbols Reading symbols from /boot/kernel/crypto.ko.symbols...done. Loaded symbols for /boot/kernel/crypto.ko.symbols Reading symbols from /boot/kernel/cryptodev.ko.symbols...done. Loaded symbols for /boot/kernel/cryptodev.ko.symbols Reading symbols from /boot/kernel/dtraceall.ko.symbols...done. Loaded symbols for /boot/kernel/dtraceall.ko.symbols Reading symbols from /boot/kernel/profile.ko.symbols...done. Loaded symbols for /boot/kernel/profile.ko.symbols Reading symbols from /boot/kernel/cyclic.ko.symbols...done. Loaded symbols for /boot/kernel/cyclic.ko.symbols Reading symbols from /boot/kernel/dtrace.ko.symbols...done. Loaded symbols for /boot/kernel/dtrace.ko.symbols Reading symbols from /boot/kernel/systrace_freebsd32.ko.symbols...done. Loaded symbols for /boot/kernel/systrace_freebsd32.ko.symbols Reading symbols from /boot/kernel/systrace.ko.symbols...done. Loaded symbols for /boot/kernel/systrace.ko.symbols Reading symbols from /boot/kernel/sdt.ko.symbols...done. Loaded symbols for /boot/kernel/sdt.ko.symbols Reading symbols from /boot/kernel/lockstat.ko.symbols...done. Loaded symbols for /boot/kernel/lockstat.ko.symbols Reading symbols from /boot/kernel/fasttrap.ko.symbols...done. Loaded symbols for /boot/kernel/fasttrap.ko.symbols Reading symbols from /boot/kernel/fbt.ko.symbols...done. Loaded symbols for /boot/kernel/fbt.ko.symbols Reading symbols from /boot/kernel/dtnfscl.ko.symbols...done. Loaded symbols for /boot/kernel/dtnfscl.ko.symbols Reading symbols from /boot/kernel/dtmalloc.ko.symbols...done. Loaded symbols for /boot/kernel/dtmalloc.ko.symbols Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/ipmi.ko.symbols...done. Loaded symbols for /boot/kernel/ipmi.ko.symbols Reading symbols from /boot/kernel/ipmi_linux.ko.symbols...done. Loaded symbols for /boot/kernel/ipmi_linux.ko.symbols Reading symbols from /boot/kernel/radeonkms.ko.symbols...done. Loaded symbols for /boot/kernel/radeonkms.ko.symbols Reading symbols from /boot/kernel/iicbb.ko.symbols...done. Loaded symbols for /boot/kernel/iicbb.ko.symbols Reading symbols from /boot/kernel/iicbus.ko.symbols...done. Loaded symbols for /boot/kernel/iicbus.ko.symbols Reading symbols from /boot/kernel/iic.ko.symbols...done. Loaded symbols for /boot/kernel/iic.ko.symbols Reading symbols from /boot/kernel/drm2.ko.symbols...done. Loaded symbols for /boot/kernel/drm2.ko.symbols Reading symbols from /boot/kernel/radeonkmsfw_R100_cp.ko.symbols...done. Loaded symbols for /boot/kernel/radeonkmsfw_R100_cp.ko.symbols Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. Loaded symbols for /boot/kernel/fdescfs.ko.symbols #0 doadump (textdump=1) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:219 #1 0xffffffff80a15267 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0xffffffff80a15808 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:746 #3 0xffffffff80a15853 in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:675 #4 0xffffffff8032f0af in assfail3 (a=, lv=, op=, rv=, f=, l=) at /usr/src/sys/cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:91 #5 0xffffffff803c99a0 in zap_get_leaf_byblk (zap=, blkid=, tx=, lt=, lp=0xfffffe100be1d4d8) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c:534 #6 0xffffffff803c7053 in zap_deref_leaf (zap=0xfffff80024d3ff00, h=9377620324092215296, tx=0x0, lt=RW_READER, lp=0xfffffe100be1d4d8) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c:585 #7 0xffffffff803c8e11 in fzap_cursor_retrieve (zap=0xfffff80024d3ff00, zc=0xfffffe100be1d4c8, za=0xfffffe100be1d3b0) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c:1181 #8 0xffffffff803cf40d in zap_cursor_retrieve (zc=0xfffffe100be1d4c8, za=0xfffffe100be1d3b0) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:1290 #9 0xffffffff8035ca53 in ddt_zap_walk (os=0xfffff80024948000, object=156, dde=0xfffffe100be1d818, walk=0xfffff8001181fad8) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/ddt_zap.c:117 #10 0xffffffff8035c709 in ddt_walk (spa=0xfffffe00110cd000, ddb=0xfffff8001181fac0, dde=0xfffffe100be1d818) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/ddt.c:218 #11 0xffffffff8038c977 in dsl_scan_sync (dp=0xfffff80024095000, tx=0xfffff800276b7600) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_scan.c:1194 #12 0xffffffff803a7a91 in spa_sync (spa=0xfffffe00110cd000, txg=17880931) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:6610 #13 0xffffffff803b332d in txg_sync_thread (arg=0xfffff80024095000) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c:517 #14 0xffffffff809e3694 in fork_exit ( callout=0xffffffff803b30e0 , arg=0xfffff80024095000, frame=0xfffffe100be1dc00) at /usr/src/sys/kern/kern_fork.c:977 #15 0xffffffff80e07fce in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:605 #16 0x0000000000000000 in ?? () Current language: auto; currently minimal (kgdb) What can I do to fix the data on the disk? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Sat Aug 30 18:02:40 2014 Return-Path: Delivered-To: freebsd-current@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 386CF874; Sat, 30 Aug 2014 18:02:40 +0000 (UTC) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 07CE41738; Sat, 30 Aug 2014 18:02:40 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id ft15so2763910pdb.19 for ; Sat, 30 Aug 2014 11:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=2mPm4EHVMBdQE0JVMfbRIc57CyEHM1VwQL0eftI61t0=; b=nMUi0c0OmXSLXdPEBtEIUWmh2BUPTCOIyErKtGBo41qBjLYaz+UyylZYmf/YVYsQS/ a74YJNofEO8zlC4MMTbWdjngO9eWRJs9d6UamxoLbzPQCzUCqV4PQWeHNtqPNaYljktC t7Od5Ju9tjuC+Hh/i6eaSnw2a6n2E344bCuWzAeaYY9mVadAUqDQLGnTGWAIRu0txREz VBRi5cBPkezPEPCYLTd0Q5B7Dm4MXGvLHHYqLpWZDPA+CX5DuXHKu1Aqk7ke2UFwSv+n JSA+13vKF/j1H9KDc52v72TVAZfXdHG38UXZ/z/Vt8gII33/021zovMLNv+Li6MAcQ/F rqvA== X-Received: by 10.66.236.38 with SMTP id ur6mr26015489pac.49.1409421759552; Sat, 30 Aug 2014 11:02:39 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:d9df:e63e:f2c6:ea6d? ([2601:8:ab80:7d6:d9df:e63e:f2c6:ea6d]) by mx.google.com with ESMTPSA id cw5sm3425200pbc.9.2014.08.30.11.02.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 30 Aug 2014 11:02:38 -0700 (PDT) References: <20140830172958.GA99694@borg.lerctr.org> Mime-Version: 1.0 (1.0) In-Reply-To: <20140830172958.GA99694@borg.lerctr.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <2EBFA952-C7EE-49D5-B9D3-301FE690983B@gmail.com> X-Mailer: iPhone Mail (11D257) From: Garrett Cooper Subject: Re: Solaris Assert: How to fix? Date: Sat, 30 Aug 2014 11:02:37 -0700 To: Larry Rosenman Cc: "freebsd-fs@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2014 18:02:40 -0000 > On Aug 30, 2014, at 10:29, Larry Rosenman wrote: >=20 > I'm getting: Hi Larry, Please file a bug on bugs.freebsd.org so this can be tracked and resolve= d appropriately. Please be sure to include relevant details like the last ke= rnel that booted properly, the kernel that fails to boot, and your zpool sta= tus output. If you can provide the point in time where it worked and failed,= someone can potentially bisect the change to help resolve the issue. Thanks! -Garrett= From owner-freebsd-current@FreeBSD.ORG Sat Aug 30 21:06:01 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5CCB2819; Sat, 30 Aug 2014 21:06:01 +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 29CB919C5; Sat, 30 Aug 2014 21:06:01 +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=fRAkvgNTMkmRyFCAy/MjQwRYSPzWcmEf6Mg8NUM2Yq0=; b=hkl8o5QiUyy/4m0U7mULsfMfkD11IRaVkTcKq4VEjHfVoMV2ddfmeor8bduxMaiwGZ9CfP9ciFv0ylW7ukjG78/eiwI3NcogcS97n5f6hpcknHQj3j8KmUW9WicMEA0Prpksl3rjyIEWC4UAd8vrPccnN4d625CM/jZjI/LXM30=; Received: from localhost.lerctr.org ([127.0.0.1]:62372 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XNpqQ-000OVd-CO; Sat, 30 Aug 2014 16:05:59 -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); Sat, 30 Aug 2014 16:05:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 30 Aug 2014 16:05:58 -0500 From: Larry Rosenman To: Garrett Cooper Subject: Re: Solaris Assert: How to =?UTF-8?Q?fix=3F?= In-Reply-To: <2EBFA952-C7EE-49D5-B9D3-301FE690983B@gmail.com> References: <20140830172958.GA99694@borg.lerctr.org> <2EBFA952-C7EE-49D5-B9D3-301FE690983B@gmail.com> Message-ID: <3598806df85fd2c298724adcec8a2fb5@thebighonker.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.0.2 X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=0.001 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2014 21:06:01 -0000 On 2014-08-30 13:02, Garrett Cooper wrote: >> On Aug 30, 2014, at 10:29, Larry Rosenman wrote: >> >> I'm getting: > > Hi Larry, > Please file a bug on bugs.freebsd.org so this can be tracked and > resolved appropriately. Please be sure to include relevant details > like the last kernel that booted properly, the kernel that fails to > boot, and your zpool status output. If you can provide the point in > time where it worked and failed, someone can potentially bisect the > change to help resolve the issue. > Thanks! > -Garrett https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186112 Which I filed LONG ago, and has seen NO action on it WHATSOEVER. Can SOMEONE please look at it? I added the latest core.txt to it. -- 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