From owner-freebsd-stable@freebsd.org Sun Dec 25 13:33:59 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8749C8DC13 for ; Sun, 25 Dec 2016 13:33:59 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id C3C7B17D3 for ; Sun, 25 Dec 2016 13:33:59 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id C0249C8DC11; Sun, 25 Dec 2016 13:33:59 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFC17C8DC0E for ; Sun, 25 Dec 2016 13:33:59 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 827E517D2 for ; Sun, 25 Dec 2016 13:33:58 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id uBPDXpup003907 for ; Sun, 25 Dec 2016 13:33:51 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id uBPDXp2U003906 for stable@freebsd.org; Sun, 25 Dec 2016 05:33:51 -0800 (PST) (envelope-from david) Date: Sun, 25 Dec 2016 05:33:51 -0800 From: David Wolfskill To: stable@freebsd.org Subject: Possible issue building kernel modules: dialog4ports invocation Message-ID: <20161225133351.GK1154@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="x6U/3PXg5ULAGGbX" Content-Disposition: inline User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2016 13:33:59 -0000 --x6U/3PXg5ULAGGbX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This morning, my laptop & build machine (daily) source-based updates for stable/11 were uneventful, but the (weekly) update to my desktop at work died (temporarily) during an attempt to build a kernel module (because I have PORTS_MODULES=3Dx11/nvidia-driver in etcsrc.conf): =2E.. --- kernel.full --- linking kernel.full ctfmerge -L VERSION -g -o kernel.full ... text data bss dec hex filename 22011101 1257388 4963232 28231721 0x1aec829 kernel.full --- kernel.debug --- objcopy --only-keep-debug kernel.full kernel.debug --- kernel --- objcopy --strip-debug --add-gnu-debuglink=3Dkernel.debug kernel.full kernel --- all --- =3D=3D=3D> Ports module x11/nvidia-driver (all) cd ${PORTSDIR:-/usr/ports}/x11/nvidia-driver; env -u CC -u CXX -u CPP P= ATH=3D/ usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/us= r/obj /usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/= usr/b in:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin SRC_BASE= =3D/usr/s rc OSVERSION=3D1100507 WRKDIRPREFIX=3D/usr/obj/usr/src/sys/ /usr/obj/usr/= src/make. amd64/bmake -B clean all =3D=3D=3D> Cleaning for nvidia-driver-367.44_3 *** [all] Stopped -- signal 22 =2E... Running "ps" showed that a few processes (including dialog4ports) had received SIGSTOP; sending them a SIGCONT wasn't helpful (as in "didn't seem to cause the processes to resume execution"). I finally did circumvent the issue by (separately) running "portmaster x11/nvidia-driver", which brought up the dialog4ports menu Just Fine, then built & installed the port. After having done that, build kernel (including updating the x11/nvidia-driver module again), install kernel, install world (as well as mergemaster &c.) all worked. In case it's relevant, I ran the build within script(1), running in a tmux(1) session. Peace, david --=20 David H. Wolfskill david@catwhisker.org Epistemology for post-truthers: How do we select parts of reality to ignore? See http://www.catwhisker.org/~david/publickey.gpg for my public key. --x6U/3PXg5ULAGGbX Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJYX8q/XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4X0q8IAIvNpFBmR/JKua3BElmhg/8l b7IqG/t06NETyVALx8a5ckwNNaShaSWb1ZdsjGRq97xp6jkfLshr4pPO6EnHg9Nb WJc/x9Vs1BXL82rJ5OvUdiOdXuRAYFLEIXeNyRQb2OryUZ3dmBSLF1OxL/4q//Rh ZK92YGssxdZJPZRZCRQnOf1YltpWKxNqKOHHytpVjES+LMmHQLCEVNDel3hW3W0k 4tmIgTAPGQ3EkaPRjkm82nmbjPNrzVnytn7YJcnvHhxKIWnMPpZBe4a9fVMo3OPx GVpnuCFd1UQuJsnO0p5oCdVjZyjVyjIgr6Cf25ZqH3fFV8vt0r3oz4QY0VVDLog= =p3wi -----END PGP SIGNATURE----- --x6U/3PXg5ULAGGbX-- From owner-freebsd-stable@freebsd.org Sun Dec 25 14:48:54 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4950C90C76 for ; Sun, 25 Dec 2016 14:48:54 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norma.perm.ru [IPv6:2a00:7540:1::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.norma.perm.ru", Issuer "Vivat-Trade UNIX Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E98ADA5 for ; Sun, 25 Dec 2016 14:48:53 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from [IPv6:2a02:2698:25:3ab8:9978:232e:2a2:2c20] ([IPv6:2a02:2698:25:3ab8:9978:232e:2a2:2c20]) (authenticated bits=0) by elf.hq.norma.perm.ru (8.15.2/8.15.2) with ESMTPSA id uBPEmmBh010634 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sun, 25 Dec 2016 19:48:48 +0500 (YEKT) (envelope-from emz@norma.perm.ru) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=norma.perm.ru; s=key; t=1482677329; bh=BaSSrmsDz4Qie6X4hKX/TFiK6eaGFKjhPqDS1CTyI1E=; h=From:Subject:To:References:Date:In-Reply-To; b=OC+Hls7XenQBxooqNFk9ySEbBbnTJPcR0Nbk07qmnXN3QxmIbOBPSGBT3rPgHOGcJ Dsskup/3rmZxJvtgm2yV7Am8xRs+QcvCa6ie/EyW7k+z3xZjn76rqHeMPP+WjYEGqM s8eDgRnEitg6Qa/Ca+cDfwf+0paRlXEX616eQzCs= From: "Eugene M. Zheganin" Subject: Re: camcontrol rescan seems to be broken To: freebsd-stable References: <585B77EF.2000805@norma.perm.ru> <34645c95-2b83-c92b-0195-c1fae9b28df4@norma.perm.ru> Message-ID: <4e663af4-2358-12a8-52ea-36f1b3c925a0@norma.perm.ru> Date: Sun, 25 Dec 2016 19:48:58 +0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2016 14:48:54 -0000 Hi. On 22.12.2016 23:46, Warner Losh wrote: > Sure sounds like your binaries are cross-threaded with the kernel. > what was "file `which camcontrol`" tell you? > I just got this on the FreeBSD 11.0-RELEASE Live CD, whan trying to rescan a scsci bus on an LSI3008 adapter. Looks more like a bug in 11.0-RELEASE, since I downloaded the image from the official ftp. Does it work for you ? On the original machine I was talking about in this thread: # file `which camcontrol` /sbin/camcontrol: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 11.0 (1100122), FreeBSD-style, stripped # uname -U 1100122 # uname -K 1100122 P.S. Does the `camcontrol rescan all` work for anyone reading this ? Eugene. From owner-freebsd-stable@freebsd.org Mon Dec 26 01:11:01 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2967AC905C6 for ; Mon, 26 Dec 2016 01:11:01 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) (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 148ED13C3 for ; Mon, 26 Dec 2016 01:11:01 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id uBQ1AvXo055407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 25 Dec 2016 17:10:59 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.14.2/Submit) with UUCP id uBQ1AuQD055398 for freebsd-stable@freebsd.org; Sun, 25 Dec 2016 17:10:56 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: from fbsd81 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA24464; Sun, 25 Dec 16 17:03:54 PST Date: Sun, 25 Dec 2016 17:03:46 -0800 From: perryh@pluto.rain.com (Perry Hutchison) To: freebsd-stable@freebsd.org Subject: bugs in memstick GPT table, and in gpart(8) Message-Id: <58606c72.4VCGEwexwvhtqyXW%perryh@pluto.rain.com> References: <57e87099.y0HRwon108cNG6uj%perryh@pluto.rain.com> <57ddefcf.jk4kZ2Kp+EcHfcFr%perryh@pluto.rain.com> <57d4c674.bo2VPtTSitHw8Suf%perryh@pluto.rain.com> In-Reply-To: <57e87099.y0HRwon108cNG6uj%perryh@pluto.rain.com> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2016 01:11:01 -0000 Some months ago: > I dd'd FreeBSD-10.3-RELEASE-i386-memstick.img to a 4GB flash drive, > and booted it into single-user mode where it appeared as da0. Then, > to resize the GPT to the media (to make space for another partition): > > # gpart show da0 > # gpart recover da0 > # gpart show da0 > > which appeared to work ... [but] when I tried to create a 4th > partition in that free space: > > # gpart show da0 # showed 3 partitions and about 3GB of free space > # gpart add -t freebsd-ufs da0 # reported "da0p4 added" > # gpart show da0 # showed 4 partitions including the new one, and > # no free space -- as expected > # shutdown -r now > > a "gpart show da0" after the reboot showed 3 partitions and about > 3GB of free space, the same as before the "gpart add" operation. > In other words, the new partition did not survive the reboot. I finally had time to track down what was going on, and it turns out that both the 10.3 GPT support, and the construction of the 10.3-RELEASE-i386-memstick, are buggy. Details: The 10.3-RELEASE-i386-memstick has the smallest possible GPT table (one sector), three GPT table entries (boot, rootfs, & swap), and hdr_entries == 3 in the GPT header. Despite that setting, the "gpart add" operation did create a fourth table entry -- and the new entry was (temporarily) available for the system to use (e.g. I was able to run an apparently-successful newfs on it). A subsequent hexdump(1) of the GPT table sector showed that the new entry had even been written to the device. However, after a reboot (or, likely, any event causing the device to be tasted again), the hdr_entries setting causes the new, fourth entry to be ignored: only the three original entries are recognized. Bugs: Since the GPT table is always a whole number of sectors, and each sector has room for four GPT table entries, there's no reason for hdr_entries not to be a multiple of 4. Whatever constructed the 10.3-RELEASE-i386-memstick image should have rounded it up. The GPT support in the kernel and in gpart(8) should handle hdr_entries consistently: either always round it up to a multiple of four, or always take it at face value. It should not be possible for gpart(8) to create a partition which will effectively disappear the next time the provider is tasted. The willingness of gpart(8) to add a partition exceeding the defined size of the GPT table is a recent regression (as well as, arguably, a buffer overrun): Under the same conditions the FreeBSD 8 version of gpart(8) complained "gpart: index '4': No space left on device". (The message is wrong -- it should be something like "Partition table full" -- but apart from the misleading message the situation seems to have been handled correctly.) Meanwhile even FreeBSD 8's gpart(8) is less helpful than its predecessor, gpt(8). Trying to perform this same operation on FreeBSD 6 produces: # gpt -r show da0 start size index contents 0 1 PMBR 1 1 Pri GPT header 2 1 Pri GPT table 3 32 1 GPT part - 83bd6b9d-7f41-11dc-be0b-001560b84f0f 35 1348832 2 GPT part - FreeBSD UFS/UFS2 1348867 2048 3 GPT part - FreeBSD swap 1350915 6460155 7811070 1 Sec GPT table 7811071 1 Sec GPT header # gpt add da0 gpt add: da0: error: no available table entries # gpt add -i 4 da0 gpt add: da0: error: index 4 out of range (3 max) From owner-freebsd-stable@freebsd.org Mon Dec 26 16:20:05 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D97DC9142A for ; Mon, 26 Dec 2016 16:20:05 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (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 BAC5F1DA0; Mon, 26 Dec 2016 16:20:03 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id uBQGJpwj019521; Tue, 27 Dec 2016 03:19:52 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 27 Dec 2016 03:19:51 +1100 (EST) From: Ian Smith To: Perry Hutchison cc: freebsd-stable@freebsd.org, marcel@freebsd.org Subject: Re: bugs in memstick GPT table, and in gpart(8) In-Reply-To: <58606c72.4VCGEwexwvhtqyXW%perryh@pluto.rain.com> Message-ID: <20161227012948.K26979@sola.nimnet.asn.au> References: <57e87099.y0HRwon108cNG6uj%perryh@pluto.rain.com> <57ddefcf.jk4kZ2Kp+EcHfcFr%perryh@pluto.rain.com> <57d4c674.bo2VPtTSitHw8Suf%perryh@pluto.rain.com> <58606c72.4VCGEwexwvhtqyXW%perryh@pluto.rain.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2016 16:20:05 -0000 On Sun, 25 Dec 2016 17:03:46 -0800, Perry Hutchison wrote: > Some months ago: > > > I dd'd FreeBSD-10.3-RELEASE-i386-memstick.img to a 4GB flash drive, > > and booted it into single-user mode where it appeared as da0. Then, > > to resize the GPT to the media (to make space for another partition): > > > > # gpart show da0 > > # gpart recover da0 > > # gpart show da0 > > > > which appeared to work ... [but] when I tried to create a 4th > > partition in that free space: > > > > # gpart show da0 # showed 3 partitions and about 3GB of free space > > # gpart add -t freebsd-ufs da0 # reported "da0p4 added" > > # gpart show da0 # showed 4 partitions including the new one, and > > # no free space -- as expected > > # shutdown -r now > > > > a "gpart show da0" after the reboot showed 3 partitions and about > > 3GB of free space, the same as before the "gpart add" operation. > > In other words, the new partition did not survive the reboot. > > I finally had time to track down what was going on, and it turns > out that both the 10.3 GPT support, and the construction of the > 10.3-RELEASE-i386-memstick, are buggy. > > Details: > > The 10.3-RELEASE-i386-memstick has the smallest possible GPT table > (one sector), three GPT table entries (boot, rootfs, & swap), and > hdr_entries == 3 in the GPT header. Despite that setting, the > "gpart add" operation did create a fourth table entry -- and the > new entry was (temporarily) available for the system to use (e.g. > I was able to run an apparently-successful newfs on it). > > A subsequent hexdump(1) of the GPT table sector showed that the new > entry had even been written to the device. However, after a reboot > (or, likely, any event causing the device to be tasted again), the > hdr_entries setting causes the new, fourth entry to be ignored: > only the three original entries are recognized. > > Bugs: > > Since the GPT table is always a whole number of sectors, and each > sector has room for four GPT table entries, there's no reason for > hdr_entries not to be a multiple of 4. Whatever constructed the > 10.3-RELEASE-i386-memstick image should have rounded it up. That would be mkimg(1). Recall that the 10.3-R amd64 memstick.img still (or rather, again?) used the BSD scheme (daXa) rather than GPT, due to a some-BIOSes issue. In 11+ both use mkimg, both adding a 1MB 'vestigial' swap partition to keep some BIOSes happy (thanks to Glen who pointed me to the relevant r265017) However in both cases, this is affected by a quite early commit to mkimg.c: https://svnweb.freebsd.org/base?view=revision&revision=263382 "Also (...), remove the enforcement of creating a GPT table with at least 128 entries. While this is generally advised as the default or minimum, it's not actually a hard requirement. We now recreate a table that's precisely enough (rounded of course)." So '3' definitely seems an unrounded result, long after this commit. Have you checked this against an 11.0-RELEASE-i386-memstick.img ? > The GPT support in the kernel and in gpart(8) should handle > hdr_entries consistently: either always round it up to a multiple > of four, or always take it at face value. It should not be possible > for gpart(8) to create a partition which will effectively disappear > the next time the provider is tasted. Agreed. I'm not sure, even after checking the _possibly somewhat_ authoritative https://en.wikipedia.org/wiki/GUID_Partition_Table whether this refers to the maximum (as I suspect) or the current number of partitions, as listed in 'GPT header format': 72 (0x48) 8 bytes Starting LBA of array of partition entries (always 2 in primary copy) 80 (0x50) 4 bytes Number of partition entries in array 84 (0x54) 4 bytes Size of a single partition entry (usually 80h or 128) Also from that, we're apparently disregarding: "The UEFI specification stipulates that a minimum of 16,384 bytes, regardless of sector size, be allocated for the Partition Entry Array." Ie, 128 entries. Which is probably just as well, though losing 16KB at the start and end of a physical disk seems fairly minute these days, even on 1GB sticks, Still, there are various references, as in mkimg(1) above, stating this is not required. Similarly in gpart(8), optional for 'create' we have: -n entries The number of entries in the partition table. Every partitioning scheme has a minimum and maximum number of entries. This option allows tables to be created with a number of entries that is within the limits. Some schemes have a maximum equal to the minimum and some schemes have a maximum large enough to be considered unlimited. By default, partition tables are created with the minimum number of entries. In none of the instances of use of gpart(8) I've seen in any /release is that -n flag used. mkimg(1) doesn't take anything like the -n switch, though perhaps it could / should? > The willingness of gpart(8) to add a partition exceeding the defined > size of the GPT table is a recent regression (as well as, arguably, > a buffer overrun): I'm surprised it didn't extend that '3' count (clearly bogus, not at all rounded) to 4 when it added another partition. It didn't even need to allocate another table sector, as going from 4 to 5 or more would. I totally agree that memsticks ought to be extendable; the root fs is RO anyway, but there's no reason not to allow other RW partition/s that one could mount from 'live CD' or a single user boot, as you wanted. > Under the same conditions the FreeBSD 8 version > of gpart(8) complained "gpart: index '4': No space left on device". > (The message is wrong -- it should be something like "Partition > table full" -- but apart from the misleading message the situation > seems to have been handled correctly.) Meanwhile even FreeBSD 8's > gpart(8) is less helpful than its predecessor, gpt(8). Trying to > perform this same operation on FreeBSD 6 produces: > > # gpt -r show da0 > start size index contents > 0 1 PMBR > 1 1 Pri GPT header > 2 1 Pri GPT table > 3 32 1 GPT part - 83bd6b9d-7f41-11dc-be0b-001560b84f0f > 35 1348832 2 GPT part - FreeBSD UFS/UFS2 > 1348867 2048 3 GPT part - FreeBSD swap > 1350915 6460155 > 7811070 1 Sec GPT table > 7811071 1 Sec GPT header > # gpt add da0 > gpt add: da0: error: no available table entries > # gpt add -i 4 da0 > gpt add: da0: error: index 4 out of range (3 max) I missed gpt(8) altogether through 6.x and 7.x. I wish gpart could at least optionally report the Pri / Sec header / table LBAs that clearly. I guess gpart(8) and mking(1) should have complementary behaviour in this regard. Perhaps they now do, though I can't spot commits since 10.3 through current head to either gpart nor mkimg that mention this, but I'm just looking through about a dozen tabs on svnweb here .. While one may agree that we'll never need 128 table entries, surely 4 is too few? On and64, we already assign 4 partitions including the extra 1MB swap partition, so there's now no scope to add a partition anyway, unless gpart can learn to grow the number of partitions in the table. I wonder if, as a workaround, we could use mkimg's -p- empty or skipped partition option _after_ defining the 3 | 4 partitions initially wanted, in order to have mkimg allocate another LBA to the pri and sec GPTs? The example in mkimg(1) only indicates intermediate entries. Perhaps a few "-p-" followed by another e.g 1MB swap partition would do the job? Ot even a small bunch of say 64KB swap partitions .. is that too ugly? cheers, Ian From owner-freebsd-stable@freebsd.org Tue Dec 27 04:10:54 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 08544C87416 for ; Tue, 27 Dec 2016 04:10:54 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) (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 D97CF1FC5; Tue, 27 Dec 2016 04:10:53 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id uBR4AkOp094331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Dec 2016 20:10:48 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.14.2/Submit) with UUCP id uBR4AkVx094330; Mon, 26 Dec 2016 20:10:46 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: from fbsd81 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA02401; Mon, 26 Dec 16 19:39:32 PST Date: Mon, 26 Dec 2016 19:39:23 -0800 From: perryh@pluto.rain.com (Perry Hutchison) To: smithi@nimnet.asn.au Cc: marcel@freebsd.org, freebsd-stable@freebsd.org Subject: Re: bugs in memstick GPT table, and in gpart(8) Message-Id: <5861e26b.HX9c2TvEoZnz0K2K%perryh@pluto.rain.com> References: <57e87099.y0HRwon108cNG6uj%perryh@pluto.rain.com> <57ddefcf.jk4kZ2Kp+EcHfcFr%perryh@pluto.rain.com> <57d4c674.bo2VPtTSitHw8Suf%perryh@pluto.rain.com> <58606c72.4VCGEwexwvhtqyXW%perryh@pluto.rain.com> <20161227012948.K26979@sola.nimnet.asn.au> In-Reply-To: <20161227012948.K26979@sola.nimnet.asn.au> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2016 04:10:54 -0000 Ian Smith wrote: > On Sun, 25 Dec 2016 17:03:46 -0800, Perry Hutchison wrote: > > ... > > The 10.3-RELEASE-i386-memstick has the smallest possible GPT table > > (one sector), three GPT table entries (boot, rootfs, & swap), and > > hdr_entries == 3 in the GPT header ... > > > > Since the GPT table is always a whole number of sectors, and each > > sector has room for four GPT table entries, there's no reason for > > hdr_entries not to be a multiple of 4. Whatever constructed the > > 10.3-RELEASE-i386-memstick image should have rounded it up. > > That would be mkimg(1). Recall that the 10.3-R amd64 memstick.img still > (or rather, again?) used the BSD scheme (daXa) rather than GPT, due to a > some-BIOSes issue. In 11+ both use mkimg, both adding a 1MB 'vestigial' > swap partition to keep some BIOSes happy (thanks to Glen who pointed me > to the relevant r265017) There is something truly horrifying about a report that "some BIOSes" require a FreeBSD-swap partition in order to boot. (I could understand FreeBSD _itself_ insisting on having a swap partition, but the BIOS?) > However in both cases, this is affected by a quite early commit to > mkimg.c: https://svnweb.freebsd.org/base?view=revision&revision=263382 > > "Also (...), remove the enforcement of creating a GPT table with at > least 128 entries. While this is generally advised as the default or > minimum, it's not actually a hard requirement. We now recreate a table > that's precisely enough (rounded of course)." > > So '3' definitely seems an unrounded result, long after this commit. > > Have you checked this against an 11.0-RELEASE-i386-memstick.img ? I hadn't, because I don't generally deal with .0 releases :) but I just checked and it still has gpt_hdr.hdr_entries == 3. > > The GPT support in the kernel and in gpart(8) should handle > > hdr_entries consistently: either always round it up to a multiple > > of four, or always take it at face value. It should not be possible > > for gpart(8) to create a partition which will effectively disappear > > the next time the provider is tasted. > > Agreed. I'm not sure, even after checking the _possibly somewhat_ > authoritative https://en.wikipedia.org/wiki/GUID_Partition_Table > whether this refers to the maximum (as I suspect) or the current > number of partitions, as listed in 'GPT header format': > > 72 (0x48) 8 bytes Starting LBA of array of partition entries ... > 80 (0x50) 4 bytes Number of partition entries in array > 84 (0x54) 4 bytes Size of a single partition entry (usually 80h or 128) > > Also from that, we're apparently disregarding: "The UEFI specification > stipulates that a minimum of 16,384 bytes, regardless of sector size, > be allocated for the Partition Entry Array." Ie, 128 entries. > > Which is probably just as well, though losing 16KB at the start and end > of a physical disk seems fairly minute these days, even on 1GB sticks, It won't matter, until someday when it makes the difference between an image fitting onto a stick of a given size or not :) I have no complaint with minimizing wasted space, but limiting the size to 3 when it necessarily occupies a multiple of 4 goes too far IMO. > Still, there are various references, as in mkimg(1) above, stating this > is not required. Similarly in gpart(8), optional for 'create' we have: > > -n entries The number of entries in the partition table ... > By default, partition tables are created with the > minimum number of entries. > > In none of the instances of use of gpart(8) I've seen in any /release is > that -n flag used. mkimg(1) doesn't take anything like the -n switch, > though perhaps it could / should? mkimg(1) seems to set the number of partitions created according to the number of -p switches provided on the command line -- but I'd think it ought to round up rather than leave part of a sector unused. > > The willingness of gpart(8) to add a partition exceeding the defined > > size of the GPT table is a recent regression (as well as, arguably, > > a buffer overrun): > > I'm surprised it didn't extend that '3' count (clearly bogus, not > at all rounded) to 4 when it added another partition. IMO it should either have enforced the limit of 3 -- with an accurate message (not FreeBSD 8's misleading "No space left on device") -- or incremented it (that being possible in this case since there was room to enlarge the table). However ... > It didn't even need to allocate another table sector, as going from > 4 to 5 or more would. Allocating another sector would be a _very_ large and risky operation if, as would usually be the case, the sector needed for expansion of the primary table is part of an already-created (and, in this case, not-empty) partition. Every partition up to the first unallocated sector on the stick would need to be moved, and interrupting that lengthy process would corrupt the partition being moved at the time. It gets even worse if one of the partitions to be moved contained any absolute LBAs (not relative to the base of the partition). > I totally agree that memsticks ought to be extendable; the root fs is RO > anyway, but there's no reason not to allow other RW partition/s that one > could mount from 'live CD' or a single user boot, as you wanted. In this case the plan was to use the added partition for packages, so that an entire system (not just base) could be installed without needing network connectivity. The only reason I was using the memstick to resize itself was that the earlier FreeBSD system I'm starting from does not implement "gpart recover" to resize the GPT to the media. Speaking of "gpart recover", it might make sense for that operation to round up the table size to whole sectors if it is not already a multiple. The recovery process has to rewrite the primary header anyway, so that it will point to the new location of the secondary. > > Trying to perform this same operation on FreeBSD 6 produces: > > > > # gpt -r show da0 > > start size index contents > > 0 1 PMBR > > 1 1 Pri GPT header > > 2 1 Pri GPT table > > 3 32 1 GPT part - 83bd6b9d-7f41-11dc-be0b-001560b84f0f > > 35 1348832 2 GPT part - FreeBSD UFS/UFS2 > > 1348867 2048 3 GPT part - FreeBSD swap > > 1350915 6460155 > > 7811070 1 Sec GPT table > > 7811071 1 Sec GPT header > > # gpt add da0 > > gpt add: da0: error: no available table entries > > # gpt add -i 4 da0 > > gpt add: da0: error: index 4 out of range (3 max) > > I missed gpt(8) altogether through 6.x and 7.x. I wish gpart could at > least optionally report the Pri / Sec header / table LBAs that clearly. Time for a -v (verbose) switch to "gpart show" -- or a separate "gpart dump" operation -- perhaps? My next move is to hack together a program -- incorporating parts of the existing FreeBSD GPT code -- to round up that table size, recompute the checksums, and rewrite the GPT headers. It "should not" be all that difficult. From owner-freebsd-stable@freebsd.org Tue Dec 27 07:48:31 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA348C93E5F for ; Tue, 27 Dec 2016 07:48:31 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (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 F2C641881; Tue, 27 Dec 2016 07:48:30 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id uBR7mNR6052379; Tue, 27 Dec 2016 18:48:24 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 27 Dec 2016 18:48:23 +1100 (EST) From: Ian Smith To: Perry Hutchison cc: marcel@freebsd.org, freebsd-stable@freebsd.org Subject: Re: bugs in memstick GPT table, and in gpart(8) In-Reply-To: <5861e26b.HX9c2TvEoZnz0K2K%perryh@pluto.rain.com> Message-ID: <20161227180352.I26979@sola.nimnet.asn.au> References: <57e87099.y0HRwon108cNG6uj%perryh@pluto.rain.com> <57ddefcf.jk4kZ2Kp+EcHfcFr%perryh@pluto.rain.com> <57d4c674.bo2VPtTSitHw8Suf%perryh@pluto.rain.com> <58606c72.4VCGEwexwvhtqyXW%perryh@pluto.rain.com> <20161227012948.K26979@sola.nimnet.asn.au> <5861e26b.HX9c2TvEoZnz0K2K%perryh@pluto.rain.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2016 07:48:31 -0000 On Mon, 26 Dec 2016 19:39:23 -0800, Perry Hutchison wrote: > Ian Smith wrote: > > On Sun, 25 Dec 2016 17:03:46 -0800, Perry Hutchison wrote: > > > ... > > > The 10.3-RELEASE-i386-memstick has the smallest possible GPT table > > > (one sector), three GPT table entries (boot, rootfs, & swap), and > > > hdr_entries == 3 in the GPT header ... > > > > > > Since the GPT table is always a whole number of sectors, and each > > > sector has room for four GPT table entries, there's no reason for > > > hdr_entries not to be a multiple of 4. Whatever constructed the > > > 10.3-RELEASE-i386-memstick image should have rounded it up. > > > > That would be mkimg(1). Recall that the 10.3-R amd64 memstick.img still > > (or rather, again?) used the BSD scheme (daXa) rather than GPT, due to a > > some-BIOSes issue. In 11+ both use mkimg, both adding a 1MB 'vestigial' > > swap partition to keep some BIOSes happy (thanks to Glen who pointed me > > to the relevant r265017) > > There is something truly horrifying about a report that "some BIOSes" > require a FreeBSD-swap partition in order to boot. (I could understand > FreeBSD _itself_ insisting on having a swap partition, but the BIOS?) Sorry, my bad paraphrasing; I should have quoted Revision 265017: "loader's GPT support on BIOS does not seem to like the root filesystem being the last filesystem on the disk for some reason when made by this script. Add a vestigial swap partition to allow this to boot with QEMU BIOS." So being a swap partition, rather than any other type, is irrelevant and likely just the easiest to specify empty, as '-p freebsd-swap::1M' While visiting the littlest room, before breakfast and after reading and while pondering yours, it occurred to me that for your stated purpose of adding another partition for packages, you might get away - after using 'gpart recover' to make the rest of your memstick available - with just deleting that 1M swap partition, then adding your new partition? You'd still only have 3 partitions, so gpart should(?) be happy. Worth a try? If that works, it should also work on the amd64 stick with 4 partitions. [..] > > Have you checked this against an 11.0-RELEASE-i386-memstick.img ? > > I hadn't, because I don't generally deal with .0 releases :) > but I just checked and it still has gpt_hdr.hdr_entries == 3. That still seems odd (in both senses of the word :) [.. I may follow up on other stuff later, if sensible .. except: ] > IMO it should either have enforced the limit of 3 -- with an accurate > message (not FreeBSD 8's misleading "No space left on device") -- or > incremented it (that being possible in this case since there was room > to enlarge the table). However ... > > > It didn't even need to allocate another table sector, as going from > > 4 to 5 or more would. > > Allocating another sector would be a _very_ large and risky > operation if, as would usually be the case, the sector needed for > expansion of the primary table is part of an already-created (and, > in this case, not-empty) partition. Yes, that was a totally dumb idea, too late at night. I already knew the first (freebsd-boot) partition started at (the next) LBA 3 .. cheers, Ian From owner-freebsd-stable@freebsd.org Wed Dec 28 08:16:48 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 786B5C9317C; Wed, 28 Dec 2016 08:16:48 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from frv73.fwdcdn.com (frv73.fwdcdn.com [212.42.77.73]) by mx1.freebsd.org (Postfix) with ESMTP id 216B91F50; Wed, 28 Dec 2016 08:16:47 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from [10.10.14.72] (helo=frv157.fwdcdn.com) by frv73.fwdcdn.com QID:1cM97o-000Fff-Nv/RC:2; Wed, 28 Dec 2016 09:58:16 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References: In-Reply-To:Message-ID:Subject:To:From:Date:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=iz7bM/0eTtZSbRQGEyqbXpCDhgm6Y+Cfyo1RtZYwTSc=; b=ooNcg5HRWAb0120GrYE/JFgktz pA1UzFVeM9NMe8BgrauqX/sOU66eWV5CUar8/Lg3e/NGcjvrUx/wq4eliuNEawwVe1kHxm/J+L1Gc aAbm1JhjXqt90xsxv1x8uizYvtaoaxK3+97pxI8VOaHqAfRq2d40BsdDt3pryceO5uUk=; Received: from [46.185.1.216] (helo=nonamehost) by frv157.fwdcdn.com with esmtpsa ID 1cM97g-000FXM-My ; Wed, 28 Dec 2016 09:58:08 +0200 Date: Wed, 28 Dec 2016 09:58:08 +0200 From: Ivan Klymenko To: freebsd-bugs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: panics collections on FreeBSD 11.0-RC1 RC2 PRERELEASE RELEASE STABLE Message-ID: <20161228095808.64d617de@nonamehost> In-Reply-To: <20161021220413.1d130f5c@nonamehost> References: <20161021220413.1d130f5c@nonamehost> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEWpqak/Pz/i4uIfHx8GBwZwcHAQEBA6o92AAAACHElEQVQ4jWWUTY7bMAyF6QzUPSEoa8PFHEBgqwuM4bVVg7MvZOj+R+ijpMTpjIwgkT7z75EKrdfattpXERG6zqvUOtAr2LCRYfEKcB4l/Q+2cc6XjQH7hv+2YZYreIk5nevZEPvuzUzptizHLzgDMnC5Wpbl7ewJlOEqlQF+DlCjgVLki0WV6FMDMsBxjlJiQulIznwZ+DxHiQyDyIg0wN3Oo6o6ZQ5s5AIfar+W2Wlmz+kCcb8tg6j3voMEwNrBQk69dDBDqw/urpqJH+m+Q6u/4QnoAeYpnUXC/s1iup9rhCd6xMgAqdDyAyFegbKkVAHeLCcOulPLawaoUIDos4M88iLNrVkU7uu5ccTDO6naJzWLum51C6Yb7y4HKKbdArLWir0PBiS8glJRBZHeyHl7J9lENpAC6qT9NlNG4u5hsVYDyJP6mlJJtY3oVju4WSUzHal1sDU17NASoBWSk40J2eBLBJhYrVmzC5gVALGpNIAiQgN6eGstOp9Oa6zFbbLTISYi28BGZDRUJKWeroECkCEkzXjUtbmmaKMfAx2RfbT69/cO+tgHcmx6AfyZOmj3NDIah0F0GB66d4CrdIoplNFFGHSpSheRxbo0W4S8azNItEoMWbw3uXAeJgCrmX5joz7CGXqSg6PcryEhnFr/C1C2ntPxBOYbdwY+8dO3+wZJyFlbMX9s8zNnvp/tLwAv03NB4j3HVpn8Awwm+GrlP6MVAAAAAElFTkSuQmCC MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Authentication-Result: IP=46.185.1.216; mail.from=fidaj@ukr.net; dkim=pass; header.d=ukr.net X-Ukrnet-Yellow: 0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2016 08:16:48 -0000 Next panic uname -a FreeBSD ns 11.0-STABLE FreeBSD 11.0-STABLE #1 r310470: Fri Dec 23 12:00:49 EET 2016 root@ns:/usr/obj/usr/src/sys/bzk11 amd64 Dec 28 09:43:21 ns kernel: Fatal trap 12: page fault while in kernel mode Dec 28 09:43:21 ns kernel: cpuid = 3; apic id = 03 Dec 28 09:43:21 ns kernel: fault virtual address = 0x8 Dec 28 09:43:21 ns kernel: fault code = supervisor read data, page not present Dec 28 09:43:21 ns kernel: instruction pointer = 0x20:0xffffffff80bb0090 Dec 28 09:43:21 ns kernel: stack pointer = 0x28:0xfffffe083b7fc560 Dec 28 09:43:21 ns kernel: frame pointer = 0x28:0xfffffe083b7fc590 Dec 28 09:43:21 ns kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Dec 28 09:43:21 ns kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Dec 28 09:43:21 ns kernel: processor eflags = interrupt enabled, resume, IOPL = 0 Dec 28 09:43:21 ns kernel: current process = 12 (swi5: fast taskq) Dec 28 09:43:21 ns kernel: trap number = 12 Dec 28 09:43:21 ns kernel: panic: page fault Dec 28 09:43:21 ns kernel: cpuid = 3 Dec 28 09:43:21 ns kernel: KDB: stack backtrace: Dec 28 09:43:21 ns kernel: #0 0xffffffff80b5f7e7 at kdb_backtrace+0x67 Dec 28 09:43:21 ns kernel: #1 0xffffffff80b131e2 at vpanic+0x182 Dec 28 09:43:21 ns kernel: #2 0xffffffff80b13053 at panic+0x43 Dec 28 09:43:21 ns kernel: #3 0xffffffff8105c230 at trap_fatal+0x330 Dec 28 09:43:21 ns kernel: #4 0xffffffff8105c423 at trap_pfault+0x1e3 Dec 28 09:43:21 ns kernel: #5 0xffffffff8105ba24 at trap+0x274 Dec 28 09:43:21 ns kernel: #6 0xffffffff8103dbb1 at calltrap+0x8 Dec 28 09:43:21 ns kernel: #7 0xffffffff80d5492a at tcp_do_segment+0x1a1a Dec 28 09:43:21 ns kernel: #8 0xffffffff80d52669 at tcp_input+0x1559 Dec 28 09:43:21 ns kernel: #9 0xffffffff80cb6dee at ip_input+0x18e Dec 28 09:43:21 ns kernel: #10 0xffffffff80c4aead at netisr_dispatch_src+0xad Dec 28 09:43:21 ns kernel: #11 0xffffffff80c325ba at ether_demux+0x13a Dec 28 09:43:21 ns kernel: #12 0xffffffff82b6871c at vboxNetFltFreeBSDinput+0x27c Dec 28 09:43:21 ns kernel: #13 0xffffffff80b7308a at taskqueue_run_locked+0x14a Dec 28 09:43:21 ns kernel: #14 0xffffffff80b72e7f at taskqueue_run+0xbf Dec 28 09:43:21 ns kernel: #15 0xffffffff80acbcff at intr_event_execute_handlers+0x20f Dec 28 09:43:21 ns kernel: #16 0xffffffff80acbf66 at ithread_loop+0xc6 Dec 28 09:43:21 ns kernel: #17 0xffffffff80ac8745 at fork_exit+0x85 Dec 28 09:43:21 ns kernel: Uptime: 4d14h37m22s Dec 28 09:43:21 ns kernel: Dumping 8226 out of 32688 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%Copyright (c) 1992-2016 The FreeBSD Project. From owner-freebsd-stable@freebsd.org Wed Dec 28 15:22:18 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6056C94556 for ; Wed, 28 Dec 2016 15:22:18 +0000 (UTC) (envelope-from David.Boyd49@twc.com) Received: from dnvrco-oedge-vip.email.rr.com (dnvrco-outbound-snat.email.rr.com [107.14.73.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "dnvrco-oedge-vip.email.rr.com", Issuer "dnvrco-oedge-vip.email.rr.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 84485110C for ; Wed, 28 Dec 2016 15:22:18 +0000 (UTC) (envelope-from David.Boyd49@twc.com) Received: from [96.28.207.162] ([96.28.207.162:60468] helo=bashful.bsd1.net) by dnvrco-omsmta02 (envelope-from ) (ecelerity 3.6.9.48312 r(Core:3.6.9.0)) with ESMTP id DC/CA-16304-2F6D3685; Wed, 28 Dec 2016 15:14:58 +0000 Message-ID: <1482938097.5904.5.camel@twc.com> Subject: Regression in pciconf utility in releng/11.0 From: David Boyd To: freebsd-stable@freebsd.org Date: Wed, 28 Dec 2016 10:14:57 -0500 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 (3.12.11-22.el7) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.64.7:25 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2016 15:22:18 -0000 pciconf -lv em0@pci0:6:0:0: returns the following error: pciconf: cannont parse selector em0:pci0:6:0:0: This is contrary to the man page documentation which specifies that the trailing colon is optional and ignored. I have verified that this worked properly (as documented) in releng/10.3. A diff of pciconf.c between releng/11.0 and releng/10.3 show that the "parsesel" function received a major rewrite. Thanks. If I should submit a PR, just let me know. From owner-freebsd-stable@freebsd.org Wed Dec 28 22:50:08 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 355A0C95A83 for ; Wed, 28 Dec 2016 22:50:08 +0000 (UTC) (envelope-from jack@jarasoft.net) Received: from nl.nb24.nl (nl.nb24.nl [37.97.225.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nb24.nl", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B7E6E1B04 for ; Wed, 28 Dec 2016 22:50:07 +0000 (UTC) (envelope-from jack@jarasoft.net) Received: from nl.nb24.nl (nl.nb24.nl [37.97.225.103]) by nl.nb24.nl (Postfix) with ESMTP id 4C7801210409 for ; Wed, 28 Dec 2016 23:47:30 +0100 (CET) Received: from [10.10.10.20] (raats.xs4all.nl [82.95.230.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by nl.nb24.nl (Postfix) with ESMTPSA id EA95A12103FA for ; Wed, 28 Dec 2016 23:47:29 +0100 (CET) User-Agent: Microsoft-MacOutlook/f.1c.1.161117 Date: Wed, 28 Dec 2016 23:47:28 +0100 Subject: Compile error while building world From: Jack Raats To: Message-ID: <96268895-B686-4796-8118-83C3410BF03B@jarasoft.net> Thread-Topic: Compile error while building world Mime-version: 1.0 X-Virus-Scanned: ClamAV using ClamSMTP on nl.nb24.nl Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2016 22:50:08 -0000 Hi =20 At this moment I=E2=80=99ll get the following error while compiling buildworld =20 --- clang-tblgen.full --- c++ -O2 -pipe -I/usr/obj/usr/src/tmp/usr/src/lib/clang/libllvm -I/usr/src/l= ib/clang/include -I/usr/src/contrib/llvm/include -DLLVM_ON_UNIX -DLLVM_ON_FR= EEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -DLLVM_DEFAULT= _TARGET_TRIPLE=3D\"x86_64-unknown-freebsd11.0\" -DLLVM_HOST_TRIPLE=3D\"x86_64-un= known-freebsd11.0\" -DDEFAULT_SYSROOT=3D\"/usr/obj/usr/src/tmp\" -g -Qunused-a= rguments -I/usr/obj/usr/src/tmp/legacy/usr/include -std=3Dc++11 -fno-exception= s -fno-rtti -stdlib=3Dlibc++ -Wno-c++11-extensions -static -L/usr/obj/usr/src= /tmp/legacy/usr/lib -o clang-tblgen.full ClangASTNodesEmitter.o ClangAttrEm= itter.o ClangCommentCommandInfoEmitter.o ClangCommentHTMLNamedCharacterRefer= enceEmitter.o ClangCommentHTMLTagsEmitter.o ClangDiagnosticsEmitter.o ClangS= ACheckersEmitter.o NeonEmitter.o TableGen.o /usr/obj/usr/src/tmp/usr/src/lib= /clang/libllvmminimal/libllvmminimal.a -lncursesw -lpthread -legacy /usr/lib/libpthread.a(thr_syscalls.o): In function `__thr_fdatasync': /usr/src/lib/libthr/thread/thr_syscalls.c:(.text+0xe51): undefined referenc= e to `__sys_fdatasync' c++: error: linker command failed with exit code 1 (use -v to see invocatio= n) *** [clang-tblgen.full] Error code 1 =20 Systeem: FreeBSD 11.0-STABLE=C2=A0 At revision 310725. =20 Can anyone give me a clue? =20 Thanks =20 Jack =20 =20 =20 =20 =20 =20 From owner-freebsd-stable@freebsd.org Thu Dec 29 08:35:46 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1727C96110 for ; Thu, 29 Dec 2016 08:35:46 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0D5EB15F4; Thu, 29 Dec 2016 08:35:45 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id uBT8Zg48081223; Thu, 29 Dec 2016 09:35:42 +0100 (CET) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 6040D351; Thu, 29 Dec 2016 09:35:42 +0100 (CET) Message-ID: <5864CADD.6020805@omnilan.de> Date: Thu, 29 Dec 2016 09:35:41 +0100 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Alexander Motin CC: FreeBSD Stable Subject: ASM1062 AHCI timeouts, ppt(4) BAR aligning [Was: Re: svn commit: r309251 - head/sys/dev/ahci] References: <201611281623.uASGNWoA056995@repo.freebsd.org> In-Reply-To: <201611281623.uASGNWoA056995@repo.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Thu, 29 Dec 2016 09:35:42 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 08:35:46 -0000 Bezüglich Alexander Motin's Nachricht vom 28.11.2016 17:23 (localtime): > Author: mav > Date: Mon Nov 28 16:23:32 2016 > New Revision: 309251 > URL: https://svnweb.freebsd.org/changeset/base/309251 > > Log: > Process port interrupt even is PxIS register is zero. > > ASMedia ASM1062 AHCI chips with some fancy firmware handling PMP inside > seems sometimes forgeting to set bits in PxIS, causing command timeouts. > Removal of this check fixes the issue by the theoretical cost of slightly > higher CPU usage in some odd cases, but this is what Linux does too. > > MFC after: 1 month > > Modified: > head/sys/dev/ahci/ahci.c > > Modified: head/sys/dev/ahci/ahci.c > ============================================================================== > --- head/sys/dev/ahci/ahci.c Mon Nov 28 15:14:31 2016 (r309250) > +++ head/sys/dev/ahci/ahci.c Mon Nov 28 16:23:32 2016 (r309251) > @@ -1169,8 +1169,6 @@ ahci_ch_intr(void *arg) > > /* Read interrupt statuses. */ > istatus = ATA_INL(ch->r_mem, AHCI_P_IS); > - if (istatus == 0) > - return; > > mtx_lock(&ch->mtx); > ahci_ch_intr_main(ch, istatus); > @@ -1187,8 +1185,6 @@ ahci_ch_intr_direct(void *arg) > > /* Read interrupt statuses. */ > istatus = ATA_INL(ch->r_mem, AHCI_P_IS); > - if (istatus == 0) > - return; > > mtx_lock(&ch->mtx); > ch->batch = 1; Hello, I'd like to report that this doesn't fix timeouts for me (applied to 11-stable). For example my REV120 works without problems on Intel-AHCI but not on ASM1062-AHCI. Even attaching gives different output. Both look fine at first: # cd0 at ahcich0 bus 0 scbus5 target 0 lun 0 # cd0: Removable CD-ROM SCSI device # cd0: Serial Number 0C1E4D046E5DFF18 # cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) When attached to the Intel-AHCI, it's followed by + cd0: Attempt to query device size failed: NOT READY, Medium not present while attaching to ASM1062 it reads (!?) - cd0: 0MB (1 0 byte sectors) Then these timeouts occur: ahcich7: Timeout on slot 11 port 0 ahcich7: is 00000000 cs 00000c00 ss 00000000 rs 00000c00 tfd 6051 serr 00000000 cmd 0004cb17 ahcich7: Timeout on slot 24 port 0 ahcich7: is 00000000 cs 01800000 ss 00000000 rs 01800000 tfd 2051 serr 00000000 cmd 0004d817 ahcich7: Timeout on slot 6 port 0 ahcich7: is 00000000 cs 00000060 ss 00000000 rs 00000060 tfd 2051 serr 00000000 cmd 0004c617 ahcich7: Timeout on slot 20 port 0 ahcich7: is 00000000 cs 00180000 ss 00000000 rs 00180000 tfd 2051 serr 00000000 cmd 0004d417 Also IDENT (via camcontrol) "hangs" for 20 seconds, but finally succeeds. Btw: I already found out that extending ppt(4) to support unaligned base address register wouldn't be too easy. Initially I added that ASM1062 card to use it for byhve(8) passthrough. Unfortunately that doesn't work: bhyve: passthru device 6/0/0 BAR 5: base 0xc3e10000 or size 0x200 not page aligned That's the ASM1062: ppt0@pci0:6:0:0: class=0x010601 card=0x10601b21 chip=0x06121b21 rev=0x01 hdr=0x00 bar [10] = type I/O Port, range 32, base 0x5050, size 8, enabled bar [14] = type I/O Port, range 32, base 0x5040, size 4, enabled bar [18] = type I/O Port, range 32, base 0x5030, size 8, enabled bar [1c] = type I/O Port, range 32, base 0x5020, size 4, enabled bar [20] = type I/O Port, range 32, base 0x5000, size 32, enabled bar [24] = type Memory, range 32, base 0xc3e10000, size 512, enabled Are there any recommendations for AHCI (SATA-PCIe) controller cards/chips that do work (both, for byhve passthrough and also as plain AHCI provider)? Thanks, -harry From owner-freebsd-stable@freebsd.org Thu Dec 29 10:33:00 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6368BC95C85 for ; Thu, 29 Dec 2016 10:33:00 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E78D710BE for ; Thu, 29 Dec 2016 10:32:59 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: by mail-wm0-x242.google.com with SMTP id c85so27646911wmi.1 for ; Thu, 29 Dec 2016 02:32:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=X61WHjV7A4Gr+0BkOhNljfTkx+ZpE6r8TEEWzwBhqgQ=; b=TojAY//EJElO9d1ZTcIqa59/M5JpokUi3Z0kcpK0kLLw3Zmlp/xNZUjRHEig2he5rY TSUEP8yPSjc9c1SBqXmyT4S0H4h0EU2TUf7z2pGTgD1NnOUf1yJRrgJbyrhbssvAbEwh RqOyTbLJ51NmWixvhJ7rPA900lzKK4s/8ZyYxZG+f1wnBEUWumR2mT/01HQdA8vmaRc0 gT3pKmnaiICbWYIoBo8s5L2/7rSIg/099bIoO06p72J9Z1jTrmfJlwhj8WfPkdfITlvU u7AC3O9ai29Oqz/chcXuuZaWI3OEY3uAXcW/hQCS8pafOg9gVtgaZWiSBGyXwv0DfD2X rtHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=X61WHjV7A4Gr+0BkOhNljfTkx+ZpE6r8TEEWzwBhqgQ=; b=mC5bffIOkpN14EW0xRjKpvPBsFCa32teL+BkCUp5Ny0XKqYCnH+KS0q+yoGAdVvpGX Jpr71GeYnBRSY6+u2gawy5g2qWTkLzBaASB24fWZUDaBYPVTMPP117aSx+JeSVRwOd+x 5Y7AihqNXFFxAXUXM3GkTPxLCzhv8oCBrrlRu1ZggP/mMXI9Eld07Dvn5lq+HG6/Wg79 0aghk+SzQCvAEyagBe9EHWH69HQ45MXFpy0ccs8ADDgsZXUugG4iWiVQNFraGaWsSiUQ KNhFYX/VifipXRkyt5wWd3m/B3Mcr1cqvAcZlmjf3bxMJEYwG2YiltwQErBLUckOA6F3 mUmw== X-Gm-Message-State: AIkVDXJjyl+l0sa975WQT1Y36cxZ7aOV4e/MYhoyZDo8h+neLeQTUAjXq8yucTIcBrz/wQ== X-Received: by 10.28.22.193 with SMTP id 184mr36936504wmw.100.1483007578259; Thu, 29 Dec 2016 02:32:58 -0800 (PST) Received: from spectre.mavhome.dp.ua ([92.38.100.11]) by smtp.gmail.com with ESMTPSA id ua15sm68240243wjb.1.2016.12.29.02.32.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Dec 2016 02:32:57 -0800 (PST) Sender: Alexander Motin Subject: Re: ASM1062 AHCI timeouts, ppt(4) BAR aligning [Was: Re: svn commit: r309251 - head/sys/dev/ahci] To: Harry Schmalzbauer References: <201611281623.uASGNWoA056995@repo.freebsd.org> <5864CADD.6020805@omnilan.de> Cc: FreeBSD Stable From: Alexander Motin Message-ID: <8c37d73e-59dc-3ca2-cab0-941a525f4d44@FreeBSD.org> Date: Thu, 29 Dec 2016 12:32:56 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <5864CADD.6020805@omnilan.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 10:33:00 -0000 On 29.12.2016 10:35, Harry Schmalzbauer wrote: > I'd like to report that this doesn't fix timeouts for me (applied to > 11-stable). > > For example my REV120 works without problems on Intel-AHCI but not on > ASM1062-AHCI. > Even attaching gives different output. Both look fine at first: > # cd0 at ahcich0 bus 0 scbus5 target 0 lun 0 > # cd0: Removable CD-ROM SCSI device > # cd0: Serial Number 0C1E4D046E5DFF18 > # cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO > 8192bytes) > > When attached to the Intel-AHCI, it's followed by > + cd0: Attempt to query device size failed: NOT READY, Medium not present > while attaching to ASM1062 it reads (!?) > - cd0: 0MB (1 0 byte sectors) > > Then these timeouts occur: > ahcich7: Timeout on slot 11 port 0 > ahcich7: is 00000000 cs 00000c00 ss 00000000 rs 00000c00 tfd 6051 serr > 00000000 cmd 0004cb17 > ahcich7: Timeout on slot 24 port 0 > ahcich7: is 00000000 cs 01800000 ss 00000000 rs 01800000 tfd 2051 serr > 00000000 cmd 0004d817 > ahcich7: Timeout on slot 6 port 0 > ahcich7: is 00000000 cs 00000060 ss 00000000 rs 00000060 tfd 2051 serr > 00000000 cmd 0004c617 > ahcich7: Timeout on slot 20 port 0 > ahcich7: is 00000000 cs 00180000 ss 00000000 rs 00180000 tfd 2051 serr > 00000000 cmd 0004d417 > > Also IDENT (via camcontrol) "hangs" for 20 seconds, but finally succeeds. I think problem may be different in your case. The HBA still reports that command is not completed by the device. Unfortunately I don't have those fancy drives to try, but I'll try to reproduce it with regular CD drive when I get back home after short New Year holidays. > Btw: I already found out that extending ppt(4) to support unaligned base > address register wouldn't be too easy. > Initially I added that ASM1062 card to use it for byhve(8) passthrough. > Unfortunately that doesn't work: > bhyve: passthru device 6/0/0 BAR 5: base 0xc3e10000 or size 0x200 not > page aligned > That's the ASM1062: > ppt0@pci0:6:0:0: class=0x010601 card=0x10601b21 chip=0x06121b21 > rev=0x01 hdr=0x00 > bar [10] = type I/O Port, range 32, base 0x5050, size 8, enabled > bar [14] = type I/O Port, range 32, base 0x5040, size 4, enabled > bar [18] = type I/O Port, range 32, base 0x5030, size 8, enabled > bar [1c] = type I/O Port, range 32, base 0x5020, size 4, enabled > bar [20] = type I/O Port, range 32, base 0x5000, size 32, enabled > bar [24] = type Memory, range 32, base 0xc3e10000, size 512, enabled I believe it is bhyve bug, since these values are just what hardware reports. BAR size of 512 bytes indeed does not align to 4K, but that is not our problem. :) > Are there any recommendations for AHCI (SATA-PCIe) controller > cards/chips that do work (both, for byhve passthrough and also as plain > AHCI provider)? Please don't mix multiple unrelated questions in one email. There is very little reasonable external AHCI controllers on the market now. I am not sure anything other then Marvell and ASmedia were released at all in last years since 6Gbps SATA came out. Marvell and ASmedia probably worth each other, while later Marvell may be slightly better on functionality (number of ports and FBS PMP support), but they are both desktop products. If you need this in server environment -- think about about SAS adapter like LSI. Or just use on-board Intel AHCI, since they are probably the best om reliability you may get out of SATA. -- Alexander Motin From owner-freebsd-stable@freebsd.org Thu Dec 29 11:05:08 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3240AC9668D for ; Thu, 29 Dec 2016 11:05:08 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 952BC101A for ; Thu, 29 Dec 2016 11:05:07 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id uBTB4vQm036888 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 29 Dec 2016 12:04:57 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id uBTB4vCf036885 for ; Thu, 29 Dec 2016 12:04:57 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Thu, 29 Dec 2016 12:04:56 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD stable Subject: Strange dtrace warning on running svn, perl and other programs on stable/10 r310494 Message-ID: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 11:05:08 -0000 I keep getting these warnings whenever I run svn, perl, and other programs. WARNING: number of probes fixed does not match the number of defined probes (16 != 18, respectively) WARNING: some probes might not fire or your program might crash They also clobber the building of security/vpnc. Some "clever" Perl script is being used to produce a .c file on stdout and a .h file on stderr while building vpnc. Any chance of getting rid of the messages, or at least disabling them? This is on stable/10, r310494. /etc/make.conf contains: STRIP= CFLAGS+=-fno-omit-frame-pointer WITH_CTF=1 WITH_SSP_PORTS=yes This particular system will soon be upgraded to stable/11, r310770. Maybe my troubles will disappear once the transition is complete. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-stable@freebsd.org Thu Dec 29 11:14:59 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ED9CDC968A4; Thu, 29 Dec 2016 11:14:59 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8CB72145B; Thu, 29 Dec 2016 11:14:59 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id uBTBEvG2083238; Thu, 29 Dec 2016 12:14:57 +0100 (CET) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 7806F3AD; Thu, 29 Dec 2016 12:14:57 +0100 (CET) Message-ID: <5864F030.4050204@omnilan.de> Date: Thu, 29 Dec 2016 12:14:56 +0100 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Alexander Motin CC: FreeBSD Stable , freebsd-virtualization@freebsd.org Subject: Re: ASM1062 AHCI timeouts, ppt(4) BAR aligning [Was: Re: svn commit: r309251 - head/sys/dev/ahci] References: <201611281623.uASGNWoA056995@repo.freebsd.org> <5864CADD.6020805@omnilan.de> <8c37d73e-59dc-3ca2-cab0-941a525f4d44@FreeBSD.org> In-Reply-To: <8c37d73e-59dc-3ca2-cab0-941a525f4d44@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Thu, 29 Dec 2016 12:14:57 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 11:15:00 -0000 Bezüglich Alexander Motin's Nachricht vom 29.12.2016 11:32 (localtime): > On 29.12.2016 10:35, Harry Schmalzbauer wrote: >> I'd like to report that this doesn't fix timeouts for me (applied to >> 11-stable). >> >> For example my REV120 works without problems on Intel-AHCI but not on >> ASM1062-AHCI. >> Even attaching gives different output. Both look fine at first: >> # cd0 at ahcich0 bus 0 scbus5 target 0 lun 0 >> # cd0: Removable CD-ROM SCSI device >> # cd0: Serial Number 0C1E4D046E5DFF18 >> # cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO >> 8192bytes) >> >> When attached to the Intel-AHCI, it's followed by >> + cd0: Attempt to query device size failed: NOT READY, Medium not present >> while attaching to ASM1062 it reads (!?) >> - cd0: 0MB (1 0 byte sectors) >> >> Then these timeouts occur: >> ahcich7: Timeout on slot 11 port 0 >> ahcich7: is 00000000 cs 00000c00 ss 00000000 rs 00000c00 tfd 6051 serr >> 00000000 cmd 0004cb17 >> ahcich7: Timeout on slot 24 port 0 >> ahcich7: is 00000000 cs 01800000 ss 00000000 rs 01800000 tfd 2051 serr >> 00000000 cmd 0004d817 >> ahcich7: Timeout on slot 6 port 0 >> ahcich7: is 00000000 cs 00000060 ss 00000000 rs 00000060 tfd 2051 serr >> 00000000 cmd 0004c617 >> ahcich7: Timeout on slot 20 port 0 >> ahcich7: is 00000000 cs 00180000 ss 00000000 rs 00180000 tfd 2051 serr >> 00000000 cmd 0004d417 >> >> Also IDENT (via camcontrol) "hangs" for 20 seconds, but finally succeeds. > > I think problem may be different in your case. The HBA still reports > that command is not completed by the device. Unfortunately I don't have > those fancy drives to try, but I'll try to reproduce it with regular CD > drive when I get back home after short New Year holidays. Oic, then I need to test the patch with regular SSD usage! I have had problems with the asm1062 when I used it for a "roaming" SSD, backing virtio-blk/ahci,hd:/dev/ada4. After some mentionable I/O there were _always_ outages which I don't remember exactly, but moving the SSD from asm-ahci to intel-ahci made them vanish. I'll see if these are now solved for the ASM1062. Otherwise I'll report. >> Btw: I already found out that extending ppt(4) to support unaligned base >> address register wouldn't be too easy. >> Initially I added that ASM1062 card to use it for byhve(8) passthrough. >> Unfortunately that doesn't work: >> bhyve: passthru device 6/0/0 BAR 5: base 0xc3e10000 or size 0x200 not … > > I believe it is bhyve bug, since these values are just what hardware > reports. BAR size of 512 bytes indeed does not align to 4K, but that is > not our problem. :) > >> Are there any recommendations for AHCI (SATA-PCIe) controller >> cards/chips that do work (both, for byhve passthrough and also as plain >> AHCI provider)? > > Please don't mix multiple unrelated questions in one email. Yes, sorry, I should have sent that in two different mails. Took the wrong route because I thought others who are possibly searching/trying low-power SATA passthrough controllers could find this (useful)... > There is very little reasonable external AHCI controllers on the market > now. I am not sure anything other then Marvell and ASmedia were > released at all in last years since 6Gbps SATA came out. Marvell and > ASmedia probably worth each other, while later Marvell may be slightly > better on functionality (number of ports and FBS PMP support), but they > are both desktop products. If you need this in server environment -- > think about about SAS adapter like LSI. Or just use on-board Intel > AHCI, since they are probably the best om reliability you may get out of > SATA. Thanks for your hints! Usually I go with LSI2008 for such cases, but this time the additional 7W power consumption for only _one_ roaming SATA-SSD seemd inappropriate. Furthermore, I only have one spare slot, so I got a card with the ASM1062 and an Etron EJ168 USB 3.0 combined. That was exactly what I'd want to have as passthrough for my guest :-) Hopefully bhyve(8)/ppt will make that possible in the future. Thanks, -harry From owner-freebsd-stable@freebsd.org Thu Dec 29 12:42:41 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D4450C945E3 for ; Thu, 29 Dec 2016 12:42:41 +0000 (UTC) (envelope-from riley_ward-freebsd+2Dstable=freebsd.org@ccreceipt.com) Received: from mail.ccreceipt.com (ccreceipt.com [185.169.229.104]) by mx1.freebsd.org (Postfix) with ESMTP id 7AE95105E for ; Thu, 29 Dec 2016 12:42:41 +0000 (UTC) (envelope-from riley_ward-freebsd+2Dstable=freebsd.org@ccreceipt.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=dkim; d=ccreceipt.com; h=Date:From:To:Subject:MIME-Version:Content-Type:List-Unsubscribe:Message-ID; i=riley_ward@ccreceipt.com; bh=eC4R3m+UeAVS6gWjCnQ2C/MmCKg=; b=oAV4rreZWYRc0bIuEx13CikGSgAudAT3PcpvV6Y/Ey3o6Xe7MwKmpArHAYrHR8sZeTrDoe9s4WQm 9W/twYwNcNVgSrEMiG/t7KlAqrrfQBBrE7nF2QyjvTUosJ5HQHuwEga/8OnkDCkw9FrLklDkjiF6 /sBAnk2B0PIuHoHyDRw= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=dkim; d=ccreceipt.com; b=GctwMik4abvQvKhtcFtx+vE/bLhuQ96vyh5DlaCVfOCVY1OWfd/GBU0Xb6Fr3UDY4Kb0xvLrKvrC /AB2As0+/Z4SkincY+Gb9wBwA3DMGvAVXJDh/BO5ypHeeX6KZMV7A+N1lbYR8qAgD0Gj8h3XSIAj 1+P9qtjRApIVshrk6Ig=; Received: by mail.ccreceipt.com id hck1ri0001gg for ; Thu, 29 Dec 2016 07:31:46 -0500 (envelope-from ) Date: Thu, 29 Dec 2016 07:31:46 -0500 From: "Riley Ward" To: Subject: Alert - Your Credit Card has been charged X-SMTPAPI: {"category": "20161229-072109-858-96"} Feedback-ID: 2016122907210985896 Message-ID: <0.0.0.254.1D261CF85210CA2.242BBA@mail.ccreceipt.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 12:42:41 -0000 From owner-freebsd-stable@freebsd.org Thu Dec 29 13:56:23 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1A73BC89E26 for ; Thu, 29 Dec 2016 13:56:23 +0000 (UTC) (envelope-from marko.cupac@mimar.rs) Received: from mail.mimar.rs (mail1.mimar.rs [193.53.106.128]) (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 775E71972 for ; Thu, 29 Dec 2016 13:56:21 +0000 (UTC) (envelope-from marko.cupac@mimar.rs) Received: from mail1.mimar.rs (localhost [127.0.1.128]) by mail.mimar.rs (Postfix) with ESMTP id 329289FA8B6A for ; Thu, 29 Dec 2016 14:50:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mimar.rs; h= content-transfer-encoding:content-type:content-type:mime-version :x-mailer:organization:message-id:subject:subject:from:from:date :date:received:received; s=mimar-0901; t=1483019395; x= 1484833796; bh=TQg+aCNiZ0jWv6Dc7mYvjqjiA6700I8GMOiEyZyTZYM=; b=M wmDV+QJ0BudY66W/bt9KwUMp3Te03b2DoARPqOF+GuChNusIqOoKOKgkeXs2dKRQ 0P1Y880WV87IS5wj0gP6H4ityUbTwO8JlJmAWqbz5tUapATD3qDo8mWeiX0+5HnP vQn0sEIsumrx7cORyMPINGrX5Zr9xHjxq58ypWlcIU= X-Virus-Scanned: amavisd-new at mimar.rs Received: from mail.mimar.rs ([127.0.1.128]) by mail1.mimar.rs (amavis.mimar.rs [127.0.1.128]) (amavisd-new, port 10026) with LMTP id 7Sy0jCTgtg2g for ; Thu, 29 Dec 2016 14:49:55 +0100 (CET) Received: from mephala.kappastar.com (nat-nat.kappastar.com [193.53.106.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: marko.cupac@mimar.rs) by mail.mimar.rs (Postfix) with ESMTPSA id 0ED7A9FA8B69 for ; Thu, 29 Dec 2016 14:49:54 +0100 (CET) Date: Thu, 29 Dec 2016 14:48:49 +0100 From: Marko =?UTF-8?B?Q3VwYcSH?= To: Subject: current state of nfs between FreeBSD and ESXi Message-ID: <20161229144849.35dac6f6@mephala.kappastar.com> Organization: Mimar X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 13:56:23 -0000 Hi, a few years ago I opted to replace our NFS server from FreeBSD to CentOS, because I was getting sub-optimal speeds between ESXi client and FreeBSD server. I never tried the workaround described here: [http://christopher-technicalmusings.blogspot.rs/2011/06/speeding-up-freebs= ds-nfs-on-zfs-for-esx.html] Years have passed, and both FreeBSD and ESXi are now at a few major versions higher than at the time I last tried to make them talk NFS. Has anything changed in the meantime? Would I have the same problem now with FreeBSD 11.0 and ESXi 6.5? Thank you in advance, --=20 Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupa=C4=87 https://www.mimar.rs/ From owner-freebsd-stable@freebsd.org Thu Dec 29 15:06:30 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8B29C96804 for ; Thu, 29 Dec 2016 15:06:30 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5F5B614DD for ; Thu, 29 Dec 2016 15:06:30 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::b1d9:a86:d7c3:cef7] (unknown [IPv6:2001:7b8:3a7:0:b1d9:a86:d7c3:cef7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id B639718DDF; Thu, 29 Dec 2016 16:06:20 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_A4D23648-627E-45FE-B578-19858EE788E8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Compile error while building world From: Dimitry Andric In-Reply-To: <96268895-B686-4796-8118-83C3410BF03B@jarasoft.net> Date: Thu, 29 Dec 2016 16:06:11 +0100 Cc: freebsd-stable@freebsd.org Message-Id: References: <96268895-B686-4796-8118-83C3410BF03B@jarasoft.net> To: Jack Raats X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 15:06:30 -0000 --Apple-Mail=_A4D23648-627E-45FE-B578-19858EE788E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 28 Dec 2016, at 23:47, Jack Raats wrote: >=20 > At this moment I=E2=80=99ll get the following error while compiling = buildworld >=20 >=20 >=20 > --- clang-tblgen.full --- >=20 > c++ -O2 -pipe -I/usr/obj/usr/src/tmp/usr/src/lib/clang/libllvm = -I/usr/src/lib/clang/include -I/usr/src/contrib/llvm/include = -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS = -D__STDC_CONSTANT_MACROS -DNDEBUG = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"x86_64-unknown-freebsd11.0\" = -DLLVM_HOST_TRIPLE=3D\"x86_64-unknown-freebsd11.0\" = -DDEFAULT_SYSROOT=3D\"/usr/obj/usr/src/tmp\" -g -Qunused-arguments = -I/usr/obj/usr/src/tmp/legacy/usr/include -std=3Dc++11 -fno-exceptions = -fno-rtti -stdlib=3Dlibc++ -Wno-c++11-extensions -static = -L/usr/obj/usr/src/tmp/legacy/usr/lib -o clang-tblgen.full = ClangASTNodesEmitter.o ClangAttrEmitter.o = ClangCommentCommandInfoEmitter.o = ClangCommentHTMLNamedCharacterReferenceEmitter.o = ClangCommentHTMLTagsEmitter.o ClangDiagnosticsEmitter.o = ClangSACheckersEmitter.o NeonEmitter.o TableGen.o = /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmminimal/libllvmminimal.a = -lncursesw -lpthread -legacy >=20 > /usr/lib/libpthread.a(thr_syscalls.o): In function `__thr_fdatasync': >=20 > /usr/src/lib/libthr/thread/thr_syscalls.c:(.text+0xe51): undefined = reference to `__sys_fdatasync' >=20 > c++: error: linker command failed with exit code 1 (use -v to see = invocation) >=20 > *** [clang-tblgen.full] Error code 1 >=20 >=20 >=20 > Systeem: FreeBSD 11.0-STABLE At revision 310725. The fdatasync symbol was added to head in r304209, and that was MFC'd to stable/11 in r304980, almost 4 months ago. For some reason, you don't seem to have it in libc.a. Can you link any application statically? And if you use -lpthread? -Dimitry --Apple-Mail=_A4D23648-627E-45FE-B578-19858EE788E8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAlhlJmwACgkQsF6jCi4glqM/9ACgxgfPbSTBT3qViDGRo4u9Q7Nl Uc8AnjOO4yz+Rttt0L1IXnFupq0g6GKP =5gzo -----END PGP SIGNATURE----- --Apple-Mail=_A4D23648-627E-45FE-B578-19858EE788E8-- From owner-freebsd-stable@freebsd.org Thu Dec 29 18:55:46 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9891BC967DB for ; Thu, 29 Dec 2016 18:55:46 +0000 (UTC) (envelope-from jack@nb24.nl) Received: from nl.nb24.nl (nl.nb24.nl [37.97.225.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nb24.nl", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C7F814AD; Thu, 29 Dec 2016 18:55:45 +0000 (UTC) (envelope-from jack@nb24.nl) Received: from nl.nb24.nl (nl.nb24.nl [37.97.225.103]) by nl.nb24.nl (Postfix) with ESMTP id 442A21210406; Thu, 29 Dec 2016 19:55:43 +0100 (CET) Received: from www.nb24.nl (nl.nb24.nl [37.97.225.103]) by nl.nb24.nl (Postfix) with ESMTP id E4E3D12103FA; Thu, 29 Dec 2016 19:55:42 +0100 (CET) Received: from 82.95.230.43 (SquirrelMail authenticated user jack) by www.nb24.nl with HTTP; Thu, 29 Dec 2016 19:55:43 +0100 Message-ID: <1b78fff280a3b37fb6b6693cd521a765.squirrel@www.nb24.nl> In-Reply-To: References: <96268895-B686-4796-8118-83C3410BF03B@jarasoft.net> Date: Thu, 29 Dec 2016 19:55:43 +0100 Subject: Re: Compile error while building world From: jack@nb24.nl To: "Dimitry Andric" Cc: "Jack Raats" , freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: ClamAV using ClamSMTP on nl.nb24.nl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 18:55:46 -0000 > On 28 Dec 2016, at 23:47, Jack Raats wrote: >> >> At this moment I’ll get the following error while compiling buildworld >> >> >> >> --- clang-tblgen.full --- >> >> c++ -O2 -pipe -I/usr/obj/usr/src/tmp/usr/src/lib/clang/libllvm >> -I/usr/src/lib/clang/include -I/usr/src/contrib/llvm/include >> -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS >> -D__STDC_CONSTANT_MACROS -DNDEBUG >> -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\" >> -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" >> -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/tmp\" -g -Qunused-arguments >> -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11 -fno-exceptions >> -fno-rtti -stdlib=libc++ -Wno-c++11-extensions -static >> -L/usr/obj/usr/src/tmp/legacy/usr/lib -o clang-tblgen.full >> ClangASTNodesEmitter.o ClangAttrEmitter.o >> ClangCommentCommandInfoEmitter.o >> ClangCommentHTMLNamedCharacterReferenceEmitter.o >> ClangCommentHTMLTagsEmitter.o ClangDiagnosticsEmitter.o >> ClangSACheckersEmitter.o NeonEmitter.o TableGen.o >> /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmminimal/libllvmminimal.a >> -lncursesw -lpthread -legacy >> >> /usr/lib/libpthread.a(thr_syscalls.o): In function `__thr_fdatasync': >> >> /usr/src/lib/libthr/thread/thr_syscalls.c:(.text+0xe51): undefined >> reference to `__sys_fdatasync' >> >> c++: error: linker command failed with exit code 1 (use -v to see >> invocation) >> >> *** [clang-tblgen.full] Error code 1 >> >> >> >> Systeem: FreeBSD 11.0-STABLE At revision 310725. > > The fdatasync symbol was added to head in r304209, and that was MFC'd to > stable/11 in r304980, almost 4 months ago. For some reason, you don't > seem to have it in libc.a. > > Can you link any application statically? And if you use -lpthread? > > -Dimitry Dimitry, Thanks for your reaction. After this error I empty's /usr/src and /usr/ports I can compile the kernel and install the kernel. But a "make buildworld" gives the above error. Copying libc.a and libc32.a from another machine didn't solve the problem. Can you give me another clue? Is it possible to reinstall world from a nightly snapshot without destroying the running system (I'm using the ZFS file system with a pool of 4 HDD) Thanks Jack From owner-freebsd-stable@freebsd.org Thu Dec 29 18:57:42 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 12BF1C9697D for ; Thu, 29 Dec 2016 18:57:42 +0000 (UTC) (envelope-from jack@jarasoft.net) Received: from nl.nb24.nl (nl.nb24.nl [37.97.225.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nb24.nl", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CA7251820; Thu, 29 Dec 2016 18:57:41 +0000 (UTC) (envelope-from jack@jarasoft.net) Received: from nl.nb24.nl (nl.nb24.nl [37.97.225.103]) by nl.nb24.nl (Postfix) with ESMTP id 97E4D1210400; Thu, 29 Dec 2016 19:57:39 +0100 (CET) Received: from www.nb24.nl (nl.nb24.nl [37.97.225.103]) by nl.nb24.nl (Postfix) with ESMTP id 4573B12103FA; Thu, 29 Dec 2016 19:57:39 +0100 (CET) Received: from 82.95.230.43 (SquirrelMail authenticated user jack) by www.nb24.nl with HTTP; Thu, 29 Dec 2016 19:57:39 +0100 Message-ID: In-Reply-To: References: <96268895-B686-4796-8118-83C3410BF03B@jarasoft.net> Date: Thu, 29 Dec 2016 19:57:39 +0100 Subject: Re: Compile error while building world From: "Jack Raats" To: "Dimitry Andric" Cc: freebsd-stable@freebsd.org Reply-To: jack@jarasoft.net User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: ClamAV using ClamSMTP on nl.nb24.nl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 18:57:42 -0000 > On 28 Dec 2016, at 23:47, Jack Raats wrote: >> >> At this moment I’ll get the following error while compiling buildworld >> >> >> >> --- clang-tblgen.full --- >> >> c++ -O2 -pipe -I/usr/obj/usr/src/tmp/usr/src/lib/clang/libllvm >> -I/usr/src/lib/clang/include -I/usr/src/contrib/llvm/include >> -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS >> -D__STDC_CONSTANT_MACROS -DNDEBUG >> -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\" >> -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" >> -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/tmp\" -g -Qunused-arguments >> -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11 -fno-exceptions >> -fno-rtti -stdlib=libc++ -Wno-c++11-extensions -static >> -L/usr/obj/usr/src/tmp/legacy/usr/lib -o clang-tblgen.full >> ClangASTNodesEmitter.o ClangAttrEmitter.o >> ClangCommentCommandInfoEmitter.o >> ClangCommentHTMLNamedCharacterReferenceEmitter.o >> ClangCommentHTMLTagsEmitter.o ClangDiagnosticsEmitter.o >> ClangSACheckersEmitter.o NeonEmitter.o TableGen.o >> /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmminimal/libllvmminimal.a >> -lncursesw -lpthread -legacy >> >> /usr/lib/libpthread.a(thr_syscalls.o): In function `__thr_fdatasync': >> >> /usr/src/lib/libthr/thread/thr_syscalls.c:(.text+0xe51): undefined >> reference to `__sys_fdatasync' >> >> c++: error: linker command failed with exit code 1 (use -v to see >> invocation) >> >> *** [clang-tblgen.full] Error code 1 >> >> >> >> Systeem: FreeBSD 11.0-STABLE At revision 310725. > > The fdatasync symbol was added to head in r304209, and that was MFC'd to > stable/11 in r304980, almost 4 months ago. For some reason, you don't > seem to have it in libc.a. > > Can you link any application statically? And if you use -lpthread? > > -Dimitry > > Dimitry, Thanks for your reaction. After this error I empty's /usr/src and /usr/ports I can compile the kernel and install the kernel. But a "make buildworld" gives the above error. Copying libc.a and libc32.a from another machine didn't solve the problem. Can you give me another clue? Is it possible to reinstall world from a nightly snapshot without destroying the running system (I'm using the ZFS file system with a pool of 4 HDD) Thanks Jack From owner-freebsd-stable@freebsd.org Thu Dec 29 19:06:33 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 67CA9C96C9D for ; Thu, 29 Dec 2016 19:06:33 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from mbob.nabble.com (mbob.nabble.com [162.253.133.15]) by mx1.freebsd.org (Postfix) with ESMTP id 591C011CC for ; Thu, 29 Dec 2016 19:06:32 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from static.162.255.23.37.macminivault.com (unknown [162.255.23.37]) by mbob.nabble.com (Postfix) with ESMTP id 2B67F392D378 for ; Thu, 29 Dec 2016 10:51:25 -0800 (PST) Date: Thu, 29 Dec 2016 12:06:31 -0700 (MST) From: Jakub Lach To: freebsd-stable@freebsd.org Message-ID: <1483038391207-6154963.post@n6.nabble.com> Subject: FreeBSD 11.0-STABLE #0 r310265 amd64 seems to be cpi-ing garbage to mounted FAT32 fs after 10-20 GB. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 19:06:33 -0000 Hello, I've recently tried to make a switch to a bigger memory card in some device; what I've discovered, is that FreeBSD is cp-ing garbage to a mounted FAT32 fs after first 10-20 GB (depending on luck). What I mean by garbage are non removable 'files' with random names which cannot be escaped. The fastest way to get rid of them is newfs. I've initially thought the problem were faulty memory card(s) but I was able to test them (mounted as FAT32 still) with sysutils/f3. They are fine, the utility writes(!) and reads them correctly. However, as soon as cp (-a) gets involved, the garbage appears, sometimes with CAM errors and reboots. Additionally, I saw exactly the same errors with FAT32 on HDD mounted via USB, so the cards are not a problem. What I can do? 1. Reading is not at all affected, I can backup (cp -a) mounted FAT32 cards to UFS2 (local disk) without problems. 2. I can mount FAT32 and test the cards with sysutils/f3. The medium (card) is tested via the same USB dual card reader as below. What I can't do reliably, as garbage appears after first 10-20 GB? 1. I can't cp (-a) from UFS2 to mounted FAT32 partition. Smaller writes are a matter of luck. 2. I can't cp (-a) from FAT32 (mounted fs on memory card A in dual card reader) to another FAT32 (mounted fs on memory card B in a dual card reader). Same problem as above. Any ideas? -- View this message in context: http://freebsd.1045724.x6.nabble.com/FreeBSD-11-0-STABLE-0-r310265-amd64-seems-to-be-cpi-ing-garbage-to-mounted-FAT32-fs-after-10-20-GB-tp6154963.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@freebsd.org Thu Dec 29 19:41:40 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F1277C9681F for ; Thu, 29 Dec 2016 19:41:40 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B42D11D78 for ; Thu, 29 Dec 2016 19:41:40 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt0-x22e.google.com with SMTP id p16so377287856qta.0 for ; Thu, 29 Dec 2016 11:41:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=YH7J7MZjb5LYzIuCZLYnWhIzosNkfRijQFmH0ISgW8A=; b=CWOmBQuywjGgTfVhawyTEAoSn0K/DFcS06mZH/BK5R3EAJlQ+6APjVNhTGVbXr2UJd 7VWXq5xJ1zrHd8dECa7wfdMygnDw+li++kpyTGdP7GnAeR5W6zQDZwFcO8KcdJMmLtTF p9odfmy4YALkHhPTd4M/37s15IEkggC4VtbDV2L8zhviyowyO/rH+jmcuGZhkW2ZyBlE 9akYRyP8dqylzT1p8HCQUWmdAC6gGCewCQIUYXRR5c/1tk1IXzbOteMukeI11NqvpGYl 8pzPKSRcvddWaB2pNIKe9Za1FOV1N/o9mVB9Vw1nSz1HLA1A4zuKvPM8n3zxwKg7VJW6 Rq6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=YH7J7MZjb5LYzIuCZLYnWhIzosNkfRijQFmH0ISgW8A=; b=D17QyQZ51B1ojLS6Yzhe4JzLJt00U6cryW/ILkkXz4me1nEQG86npQUbSEmGjAA81L eXfmojQBmxuZbujv0D0dwwjmwq/eKrDmYcQ89nnIZCAJ4WgVpSIdDtgwRoG3otH61B1w Bn++DnWAeh3PbqPi0J2xeJf66R7MxinwOriLfhlhfzZHUhIeW9Yym2VCesX32BCyX678 NdOyPCWnjuUDIT1eTT6nL1Zf0fDdRjQS5IOYmKHT71/1IqmejspZWzw4kICjcdPsmjYP sqe2b7Qmrf1MsDSmJpwTch2f6mZtHQ1mRS4PSFjAavUtT60WgtsZY7DJCjmIgeNLPmbt C4Sg== X-Gm-Message-State: AIkVDXIdFaZjF9mLV5TQKwDxyIRyOhoPDisIZX785VIuEwkcGbfKEiQACnulb2Q43J0Ssw== X-Received: by 10.200.0.145 with SMTP id c17mr38009999qtg.275.1483040499920; Thu, 29 Dec 2016 11:41:39 -0800 (PST) Received: from wkstn-mjohnston.west.isilon.com (c-76-104-201-218.hsd1.wa.comcast.net. [76.104.201.218]) by smtp.gmail.com with ESMTPSA id p47sm19345169qtc.25.2016.12.29.11.41.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Dec 2016 11:41:39 -0800 (PST) Sender: Mark Johnston Date: Thu, 29 Dec 2016 11:47:50 -0800 From: Mark Johnston To: Trond =?iso-8859-1?Q?Endrest=F8l?= Cc: FreeBSD stable Subject: Re: Strange dtrace warning on running svn, perl and other programs on stable/10 r310494 Message-ID: <20161229194750.GB29960@wkstn-mjohnston.west.isilon.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 19:41:41 -0000 On Thu, Dec 29, 2016 at 12:04:56PM +0100, Trond Endrestøl wrote: > I keep getting these warnings whenever I run svn, perl, and other > programs. > > WARNING: number of probes fixed does not match the number of defined probes (16 != 18, respectively) > WARNING: some probes might not fire or your program might crash > > They also clobber the building of security/vpnc. Some "clever" Perl > script is being used to produce a .c file on stdout and a .h file on > stderr while building vpnc. This is emitted by some code that registers userland DTrace probes during process init. The mechanism used in stable/10 doesn't work in some cases. This has been fixed in 11, but the change cannot easily be merged back. > > Any chance of getting rid of the messages, or at least disabling them? If you're not planning on using the DTrace probes, the message can be suppressed by setting DTRACE_DOF_INIT_DISABLE in the environment. > > This is on stable/10, r310494. > > /etc/make.conf contains: > > STRIP= > CFLAGS+=-fno-omit-frame-pointer > WITH_CTF=1 > WITH_SSP_PORTS=yes > > This particular system will soon be upgraded to stable/11, r310770. > Maybe my troubles will disappear once the transition is complete. Indeed, this message is gone on stable/11. From owner-freebsd-stable@freebsd.org Thu Dec 29 22:51:47 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14409C9717C for ; Thu, 29 Dec 2016 22:51:47 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from mbob.nabble.com (mbob.nabble.com [162.253.133.15]) by mx1.freebsd.org (Postfix) with ESMTP id EEEB2173B for ; Thu, 29 Dec 2016 22:51:46 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from static.162.255.23.37.macminivault.com (unknown [162.255.23.37]) by mbob.nabble.com (Postfix) with ESMTP id D424F393013A for ; Thu, 29 Dec 2016 14:36:38 -0800 (PST) Date: Thu, 29 Dec 2016 15:51:46 -0700 (MST) From: Jakub Lach To: freebsd-stable@freebsd.org Message-ID: <1483051906021-6155011.post@n6.nabble.com> Subject: Cannot buildworld r310779 on FreeBSD 11.0-STABLE #0 r310265 amd64 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 22:51:47 -0000 Hello, I'm quite puzzled. Emptied /usr/obj, make cleandir and # make buildworld && make buildkernel... svn st is clear. <...> ===> usr.bin/dtc (all) echo dtc: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend echo dtc: /usr/obj/usr/src/tmp/usr/lib/libc++.a >> .depend c++ -O2 -pipe -march=native -DNDEBUG -MD -MF.depend.dtc.o -MTdtc.o -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith -Wno-uninitialized -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -std=c++11 -fno-rtti -fno-exceptions -Wno-c++11-extensions -c /usr/src/usr.bin/dtc/dtc.cc -o dtc.o c++ -O2 -pipe -march=native -DNDEBUG -MD -MF.depend.input_buffer.o -MTinput_buffer.o -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith -Wno-uninitialized -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -std=c++11 -fno-rtti -fno-exceptions -Wno-c++11-extensions -c /usr/src/usr.bin/dtc/input_buffer.cc -o input_buffer.o c++ -O2 -pipe -march=native -DNDEBUG -MD -MF.depend.string.o -MTstring.o -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith -Wno-uninitialized -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -std=c++11 -fno-rtti -fno-exceptions -Wno-c++11-extensions -c /usr/src/usr.bin/dtc/string.cc -o string.o c++ -O2 -pipe -march=native -DNDEBUG -MD -MF.depend.dtb.o -MTdtb.o -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith -Wno-uninitialized -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -std=c++11 -fno-rtti -fno-exceptions -Wno-c++11-extensions -c /usr/src/usr.bin/dtc/dtb.cc -o dtb.o c++ -O2 -pipe -march=native -DNDEBUG -MD -MF.depend.fdt.o -MTfdt.o -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith -Wno-uninitialized -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -std=c++11 -fno-rtti -fno-exceptions -Wno-c++11-extensions -c /usr/src/usr.bin/dtc/fdt.cc -o fdt.o /usr/src/usr.bin/dtc/fdt.cc:1593:8: error: cannot initialize a variable of type 'char *' with an rvalue of type 'const char *' char *val = strchr(def, '='); ^ ~~~~~~~~~~~~~~~~ 1 error generated. *** Error code 1 Stop. make[4]: stopped in /usr/src/usr.bin/dtc *** Error code 1 -- View this message in context: http://freebsd.1045724.x6.nabble.com/Cannot-buildworld-r310779-on-FreeBSD-11-0-STABLE-0-r310265-amd64-tp6155011.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@freebsd.org Fri Dec 30 09:34:33 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4020DC91896 for ; Fri, 30 Dec 2016 09:34:33 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-wj0-x22d.google.com (mail-wj0-x22d.google.com [IPv6:2a00:1450:400c:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BFAB51A8D for ; Fri, 30 Dec 2016 09:34:32 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: by mail-wj0-x22d.google.com with SMTP id sd9so189731576wjb.1 for ; Fri, 30 Dec 2016 01:34:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:cc:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=1BxTRRXhtgQDNGvDi8qIKFyq4sGPffhRhTl8NTAbm/Q=; b=CLA1uQA+RBg/+yvmPBRhVSdx7NaPK9KOLF6VfwQJQ861sizTNrxR0NLaIiqC6BHIIz cW9cpXpKwuGCDib4gL8MgJWs5e7WKzF4iSdw4wMZxUMKeSh0KHz/AD8l8VHYt+iw67hk e5VsDm0v+nYvT8DMZ3ODMAWQ55kYyIZx2fzFTXXsOg84OR/YmDkxajznwiPh9uZOPzqI w5G6RmIHeVeYuEHarriNnHcqGhY/Lb2Lo6jqtnpPVbyb50oRHb4EHcTpFRE8KxsCeAia imk0IUVeCHUk0mxjOIqBSAajGoGPLap6fOX5Btr9izgLon2cmt1M2tfMpV9vRRI+RNLz XJ6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=1BxTRRXhtgQDNGvDi8qIKFyq4sGPffhRhTl8NTAbm/Q=; b=YAP6YIhqabaOXD/c3VQKu/1MSUgLQm0JsJRDKqFg3QFtDxNevcncmVozwmobwgNiRl XhJ9d+tx05gYzsJL2Sd+D0qmrOvp1/aPPuWnlYPE3ePebXt14FL41zuz9GRuRlr2TZGE 9KpT/8s9gv0Hf/iDXd60dZKKECI26etD6vAY8vr9GwZbznz4OhF3odtsTFZStk2Y3IUC n3ZNhbgvR9vtdNNarbI5a/AoM8tS8QU4+AeeXDsFQnQjW6pkeEZZLulL9R+8JLN88+XT v1QKMQDeQtB/Mc12yVNBv9QWJCdksEkPjpb8tN6Tb0gxcOX/5HmRdlx2fh1TAZYBBItf oCeg== X-Gm-Message-State: AIkVDXLF470w74Tmj/mYkV2361IBGxKdD8XaV5bIPJHB2Ub/A+hHv5+VV1koPPLckc1uqw== X-Received: by 10.194.203.135 with SMTP id kq7mr47564538wjc.26.1483090470745; Fri, 30 Dec 2016 01:34:30 -0800 (PST) Received: from Johans-MacBook-Air-2.local (92-111-79-242.static.chello.nl. [92.111.79.242]) by smtp.googlemail.com with ESMTPSA id e5sm69187089wma.12.2016.12.30.01.34.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Dec 2016 01:34:29 -0800 (PST) Subject: Re: current state of nfs between FreeBSD and ESXi To: =?UTF-8?Q?Marko_Cupa=c4=87?= References: <20161229144849.35dac6f6@mephala.kappastar.com> From: Johan Hendriks Cc: freebsd-stable@freebsd.org Message-ID: <41f15f28-91c2-705c-0beb-2b1b76bdbfc3@gmail.com> Date: Fri, 30 Dec 2016 10:34:28 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20161229144849.35dac6f6@mephala.kappastar.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2016 09:34:33 -0000 Op 29/12/2016 om 14:48 schreef Marko Cupać: > Hi, > > a few years ago I opted to replace our NFS server from FreeBSD to > CentOS, because I was getting sub-optimal speeds between ESXi client > and FreeBSD server. > > I never tried the workaround described here: > [http://christopher-technicalmusings.blogspot.rs/2011/06/speeding-up-freebsds-nfs-on-zfs-for-esx.html] > > Years have passed, and both FreeBSD and ESXi are now at a few major > versions higher than at the time I last tried to make them talk NFS. Has > anything changed in the meantime? Would I have the same problem now > with FreeBSD 11.0 and ESXi 6.5? > > Thank you in advance, The only way to find out is to test your setup. We use FreeBSD 9.0 as a NFS server for our ESXi 5 servers. We added a ZIL/SLOG device to our setup and speeds are back to normal. The slowdown is because the async and sync behaviour of ZFS and ESXi. One other option is to disable sync on the ZFS dataset. That will also speedup NFS transfer speeds for the ESXi hosts, but then there is a slight window for data corruption in case of a sudden crash of the server. regards Johan From owner-freebsd-stable@freebsd.org Fri Dec 30 09:39:47 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 774B2C91C84 for ; Fri, 30 Dec 2016 09:39:47 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 40CBA1F7C for ; Fri, 30 Dec 2016 09:39:47 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::7d0d:fedb:8b40:bd7f] (unknown [IPv6:2001:7b8:3a7:0:7d0d:fedb:8b40:bd7f]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 45EC419A41; Fri, 30 Dec 2016 10:39:44 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_F354BEC3-FAEF-4A80-BD03-8A9F287AD106"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Cannot buildworld r310779 on FreeBSD 11.0-STABLE #0 r310265 amd64 From: Dimitry Andric In-Reply-To: <1483051906021-6155011.post@n6.nabble.com> Date: Fri, 30 Dec 2016 10:39:39 +0100 Cc: freebsd-stable@freebsd.org Message-Id: <6F910BF3-BEB4-4268-80E3-5CB2E7695797@FreeBSD.org> References: <1483051906021-6155011.post@n6.nabble.com> To: Jakub Lach X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2016 09:39:47 -0000 --Apple-Mail=_F354BEC3-FAEF-4A80-BD03-8A9F287AD106 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 29 Dec 2016, at 23:51, Jakub Lach wrote: > > I'm quite puzzled. Emptied /usr/obj, make cleandir and > # make buildworld && make buildkernel... svn st is clear. ... > /usr/src/usr.bin/dtc/fdt.cc -o fdt.o > /usr/src/usr.bin/dtc/fdt.cc:1593:8: error: cannot initialize a variable of > type 'char *' with an > rvalue of type 'const char *' > char *val = strchr(def, '='); > ^ ~~~~~~~~~~~~~~~~ This was fixed in head with r309191, but it was not MFC'd yet. I have done so in r310808. -Dimitry --Apple-Mail=_F354BEC3-FAEF-4A80-BD03-8A9F287AD106 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAlhmK18ACgkQsF6jCi4glqNGSACgxmyaSt8nAereZaD9AVMm862P +IIAni/s7ujpng8lpIwdNu3BXBsNoE5T =pJVW -----END PGP SIGNATURE----- --Apple-Mail=_F354BEC3-FAEF-4A80-BD03-8A9F287AD106-- From owner-freebsd-stable@freebsd.org Fri Dec 30 09:59:40 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 16776C953C8 for ; Fri, 30 Dec 2016 09:59:40 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from mbob.nabble.com (mbob.nabble.com [162.253.133.15]) by mx1.freebsd.org (Postfix) with ESMTP id 067C21915 for ; Fri, 30 Dec 2016 09:59:39 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from static.162.255.23.37.macminivault.com (unknown [162.255.23.37]) by mbob.nabble.com (Postfix) with ESMTP id 4B6AF393664F for ; Fri, 30 Dec 2016 01:44:28 -0800 (PST) Date: Fri, 30 Dec 2016 02:59:38 -0700 (MST) From: Jakub Lach To: freebsd-stable@freebsd.org Message-ID: <1483091978719-6155058.post@n6.nabble.com> In-Reply-To: <6F910BF3-BEB4-4268-80E3-5CB2E7695797@FreeBSD.org> References: <1483051906021-6155011.post@n6.nabble.com> <6F910BF3-BEB4-4268-80E3-5CB2E7695797@FreeBSD.org> Subject: Re: Cannot buildworld r310779 on FreeBSD 11.0-STABLE #0 r310265 amd64 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2016 09:59:40 -0000 Great! Thanks for the MFC, should have checked HEAD too though, sorry about that. -- View this message in context: http://freebsd.1045724.x6.nabble.com/Cannot-buildworld-r310779-on-FreeBSD-11-0-STABLE-0-r310265-amd64-tp6155011p6155058.html Sent from the freebsd-stable mailing list archive at Nabble.com.