From owner-freebsd-current@freebsd.org Sun Jun 11 18:12:27 2017 Return-Path: Delivered-To: freebsd-current@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 55F7BD8BD79; Sun, 11 Jun 2017 18:12:27 +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 10269717C1; Sun, 11 Jun 2017 18:12:26 +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 v5BICPIo001685; Sun, 11 Jun 2017 18:12:25 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v5BICPG5001684; Sun, 11 Jun 2017 11:12:25 -0700 (PDT) (envelope-from david) Date: Sun, 11 Jun 2017 11:12:25 -0700 From: David Wolfskill To: stable@freebsd.org Subject: Re: post ino64: lockd no runs? Message-ID: <20170611172022.GA3184@albert.catwhisker.org> Reply-To: stable@freebsd.org Mail-Followup-To: stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0eh6TmSyL6TZE2Uz" Content-Disposition: inline In-Reply-To: <24b27f3e-f91b-553d-f2c1-e876608e0baf@protected-networks.net> User-Agent: Mutt/1.8.2 (2017-04-18) X-Mailman-Approved-At: Sun, 11 Jun 2017 18:23:26 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 18:12:27 -0000 --0eh6TmSyL6TZE2Uz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 04, 2017 at 08:57:44AM -0400, Michael Butler wrote: > It seems that {rpc.}lockd no longer runs after the ino64 changes on any > of my systems after a full rebuild of src and ports. No log entries > offer any insight as to why :-( >=20 > imb I don't tend to use NFS on my systems that are running head, so I haven't had occasion to test this as stated. However, I just completed my weekly update of the "prooduction" systems here at home, running stable/11. And I find that lockd seems to be ... claiming that all is well, but declining to run (for long). To the best of my knowledge, that was not the case until this last update, which was from: FreeBSD albert.catwhisker.org 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #316 = r319566M/319569:1100514: Sun Jun 4 03:54:41 PDT 2017 root@freebeast.c= atwhisker.org:/common/S1/obj/usr/src/sys/ALBERT amd64 to FreeBSD albert.catwhisker.org 11.1-BETA1 FreeBSD 11.1-BETA1 #322 r319823M/= 319823:1100514: Sun Jun 11 03:56:10 PDT 2017 root@freebeast.catwhisker.= org:/common/S1/obj/usr/src/sys/ALBERT amd64 The "glaringly obvious" symptom in my case is that I am now unable to (directly) save an email message from within mutt(1) by appending it to an NFS-resident file. (Saving it to a local file, then using cat(1) to append that to the NFS- resident file & removing the local copy works....) After a few variations on a theme of: albert(11.1)[5] sudo service lockd restart lockd not running? Starting lockd. albert(11.1)[6] echo $? 0 albert(11.1)[7] service lockd status lockd is not running. I finally(!) thought to ask ktrace what's going on (as tailing /var/log/messages was completely unproductive, even after enabling rc_debug). So I tried: "sudo ktrace -di service lockd restart"; upon exanimation of the output of kdump(1), I see that the trace ends with: ... 2811 rpc.lockd NAMI "/var/run/logpriv" 2786 sh CALL read(0xa,0x627fc0,0x400) 2786 sh GIO fd 10 read 0 bytes "" 2811 rpc.lockd RET connect 0 2786 sh RET read 0 2811 rpc.lockd CALL sendto(0x3,0x7fffffffe2c0,0x27,0,0,0) 2786 sh CALL exit(0) 2811 rpc.lockd GIO fd 3 wrote 39 bytes "<30>Jun 11 15:43:10 rpc.lockd: Starting" 2811 rpc.lockd RET sendto 39/0x27 2811 rpc.lockd CALL sigaction(SIGALRM,0x7fffffffec20,0) 2811 rpc.lockd RET sigaction 0 2811 rpc.lockd CALL nlm_syscall(0,0x1e,0x4,0x801015040) 2811 rpc.lockd RET nlm_syscall -1 errno 14 Bad address 2811 rpc.lockd CALL sigprocmask(SIG_BLOCK,0x800830c78,0x7fffffffea40) 2811 rpc.lockd RET sigprocmask 0 2811 rpc.lockd CALL sigprocmask(SIG_SETMASK,0x800830c8c,0) 2811 rpc.lockd RET sigprocmask 0 2811 rpc.lockd CALL sigprocmask(SIG_BLOCK,0x800830c78,0x7fffffffe5b0) 2811 rpc.lockd RET sigprocmask 0 2811 rpc.lockd CALL sigprocmask(SIG_SETMASK,0x800830c8c,0) 2811 rpc.lockd RET sigprocmask 0 2811 rpc.lockd CALL sigprocmask(SIG_BLOCK,0x800830c78,0x7fffffffe5b0) 2811 rpc.lockd RET sigprocmask 0 2811 rpc.lockd CALL sigprocmask(SIG_SETMASK,0x800830c8c,0) 2811 rpc.lockd RET sigprocmask 0 2811 rpc.lockd CALL sigprocmask(SIG_BLOCK,0x800830c78,0x7fffffffe5b0) 2811 rpc.lockd RET sigprocmask 0 2811 rpc.lockd CALL sigprocmask(SIG_SETMASK,0x800830c8c,0) 2811 rpc.lockd RET sigprocmask 0 2811 rpc.lockd CALL exit(0x1) Then, when I tried to send this message, I started getting more whines =66rom mutt(1). I finall gave up and rebooted from the previous environment: FreeBSD albert.catwhisker.org 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #316 = r319566M/319569:1100514: Sun Jun 4 03:54:41 PDT 2017 root@freebeast.c= atwhisker.org:/common/S1/obj/usr/src/sys/ALBERT amd64 and lockd is running: albert(11.1-P)[2] service lockd status lockd is running as pid 629. albert(11.1-P)[3]=20 so mutt(1) is not pitchng a hisssy-fit every time I try to save or send a message. In light of the above, I have Bcced: this message to current@ (where the thread originated) and sent it (and set replies) to stable@. I have a test system, last updated to stable/11 as of mid-October last year; lockd was running on it, as well (which is why I tried going back to last week's image). I'm happy to update it to points where lockd may be broken, if it might help figure out what's broken and how to fix it. Peace, david --=20 David H. Wolfskill david@catwhisker.org Looking forward to telling Mr. Trump: "You're fired!" See http://www.catwhisker.org/~david/publickey.gpg for my public key. --0eh6TmSyL6TZE2Uz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZPYgJXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XCHQIAKKEI5ugUyQLXysilReYaY2r 7iHfEmIPzuIvklDjgGgzhOSsz61vCvUa9NeRizlMexaan/9rBM41+9mIJqJ281nR kPdRL4ctCRz9wjSf0ASR2M5Y9bApzKCh19E23YSNEfejzBZBMyfQC9griCAi2fmL QmDkbevxTkdfAjsnS+HipeU306rdLX4b71q/4uL+y9tJyB9ZRbzEJ5MlXIahZd/g jO+pGAfX+jJK1nN3Hdkwac3feH4Gnr9TwAk5AwL3Ta8rSp47l+ESIaqcL8rdA1Rh fJMgXf6DwawCWJhlmBbeKk8bO1659Skxknc6UZhd/lUsptjkOyIj4pxRUpUbNkM= =RNn/ -----END PGP SIGNATURE----- --0eh6TmSyL6TZE2Uz-- From owner-freebsd-current@freebsd.org Mon Jun 12 18:48:17 2017 Return-Path: Delivered-To: freebsd-current@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 69D68C0A12A; Mon, 12 Jun 2017 18:48:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 202E5796A0; Mon, 12 Jun 2017 18:48:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 0EAAE10AF09; Mon, 12 Jun 2017 14:47:59 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org, stable@freebsd.org Subject: Re: post ino64: lockd no runs? Date: Mon, 12 Jun 2017 10:14:27 -0700 Message-ID: <2474735.4VjKMe5DLv@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: <20170611172022.GA3184@albert.catwhisker.org> References: <20170611172022.GA3184@albert.catwhisker.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Mon, 12 Jun 2017 14:47:59 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 18:48:17 -0000 On Sunday, June 11, 2017 11:12:25 AM David Wolfskill wrote: > On Sun, Jun 04, 2017 at 08:57:44AM -0400, Michael Butler wrote: > > It seems that {rpc.}lockd no longer runs after the ino64 changes on any > > of my systems after a full rebuild of src and ports. No log entries > > offer any insight as to why :-( > > > > imb > > I don't tend to use NFS on my systems that are running head, so I > haven't had occasion to test this as stated. > > However, I just completed my weekly update of the "prooduction" systems > here at home, running stable/11. And I find that lockd seems to be ... > claiming that all is well, but declining to run (for long). > > To the best of my knowledge, that was not the case until this last > update, which was from: > > FreeBSD albert.catwhisker.org 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #316 r319566M/319569:1100514: Sun Jun 4 03:54:41 PDT 2017 root@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/ALBERT amd64 > > to > > FreeBSD albert.catwhisker.org 11.1-BETA1 FreeBSD 11.1-BETA1 #322 r319823M/319823:1100514: Sun Jun 11 03:56:10 PDT 2017 root@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/ALBERT amd64 > > The "glaringly obvious" symptom in my case is that I am now unable > to (directly) save an email message from within mutt(1) by appending > it to an NFS-resident file. (Saving it to a local file, then using > cat(1) to append that to the NFS- resident file & removing the local > copy works....) > > After a few variations on a theme of: > > albert(11.1)[5] sudo service lockd restart > lockd not running? > Starting lockd. > albert(11.1)[6] echo $? > 0 > albert(11.1)[7] service lockd status > lockd is not running. > > I finally(!) thought to ask ktrace what's going on (as tailing > /var/log/messages was completely unproductive, even after enabling > rc_debug). > > So I tried: "sudo ktrace -di service lockd restart"; upon exanimation of > the output of kdump(1), I see that the trace ends with: > > ... > 2811 rpc.lockd NAMI "/var/run/logpriv" > 2786 sh CALL read(0xa,0x627fc0,0x400) > 2786 sh GIO fd 10 read 0 bytes > "" > 2811 rpc.lockd RET connect 0 > 2786 sh RET read 0 > 2811 rpc.lockd CALL sendto(0x3,0x7fffffffe2c0,0x27,0,0,0) > 2786 sh CALL exit(0) > 2811 rpc.lockd GIO fd 3 wrote 39 bytes > "<30>Jun 11 15:43:10 rpc.lockd: Starting" > 2811 rpc.lockd RET sendto 39/0x27 > 2811 rpc.lockd CALL sigaction(SIGALRM,0x7fffffffec20,0) > 2811 rpc.lockd RET sigaction 0 > 2811 rpc.lockd CALL nlm_syscall(0,0x1e,0x4,0x801015040) > 2811 rpc.lockd RET nlm_syscall -1 errno 14 Bad address This is a really good clue. nlm_syscall is dying with EFAULT. The last argument is a pointer to an array of char * pointers, and the only way I can see it dying is if it fails to copyin() one of the strings pointed to by those pointers. You could try running rpc.lockd under gdb from ports and setting a breakpoint on 'nlm_syscall' and then printing out 'addr_count' and 'p addrs@(addr_count * 2)'. Unfortunately I'm not able to reproduce the failure on a test machine I have running head post-ino64. -- John Baldwin From owner-freebsd-current@freebsd.org Mon Jun 12 19:28:57 2017 Return-Path: Delivered-To: freebsd-current@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 94CC4C0AD66; Mon, 12 Jun 2017 19:28:57 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 5E5C37ADF2; Mon, 12 Jun 2017 19:28:57 +0000 (UTC) (envelope-from delphij@gmail.com) Received: by mail-it0-x22d.google.com with SMTP id m47so28648448iti.1; Mon, 12 Jun 2017 12:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cmM24RUV1w6UMVKTm5mewV7c4IX4CYv9ueJxMFkD5Ig=; b=hr8H+E0WUcwMFgae7syB87jd0bYxnREnur7yPYphOGQjL03OLN+1/DQG8EQAaD7foH q8AZhmvVf12/Ak6yIjg1ii7Xr1+FYZ+8htXJwFDDPnQ5TpH5YJdKlQIrQjGlPIbaenK1 UgoQXdfil/dPQ7ixd++v+7LK7WLXLwJFM5X4uB42RqQlY+ifncMgWYc8E6+LJiq6EKIJ 93fAQoPr6/VRR9K8rt6XI4ZC9ChFGD49ACLz3PtKzWCOsMvqTTvTnkEx9NI9Wa424wtz nZN2/0uV9IsmOmCbVECbIaPEdgN/sMl6VTp8VszPdJEo2eFc5WaUoJJLsvRN4y004Fs5 FqAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cmM24RUV1w6UMVKTm5mewV7c4IX4CYv9ueJxMFkD5Ig=; b=sximuJ9+YDEa/D4tx5AAG6xG2hugZdso5ACiliq80qaB3P8MGCaGP2uzgHdA9CY+v0 TakIzSa9ZlGgpXrdKOSRHhLruQqHoNMnDwB2E+rxKDQrSXLvWU28dD3Mg6WV93lhslsw oWPI2r/nTTzVOcMTXWCLOPAUXinQYYDklbjD8VOKvxIPG/rBlb7TLRrB6COIGEetMYkI J6dDeMiR6BI2/DdyxjJBdJJhUX6RdSMtWNSEOQyY/1EFMOIKWJYSoEXL5vGYwJPcJb1o q1uKWJ8lJ/8zLgljb/Bt4aMsiq2d+oFLTa9XsTQftabdtYHaok0K/kjAqV3/bnEUPwJg OuIQ== X-Gm-Message-State: AODbwcCG5GjOyVewTZ4kGUpvhEsQt/8G5kmSFl7rGi0HHLUoM+5c5j2/ ehyc/vJofy6hJN4zRYGJ5AXvcRHGk1rbeU8= X-Received: by 10.36.29.150 with SMTP id 144mr13071745itj.71.1497295736455; Mon, 12 Jun 2017 12:28:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.33.199 with HTTP; Mon, 12 Jun 2017 12:28:55 -0700 (PDT) In-Reply-To: <2474735.4VjKMe5DLv@ralph.baldwin.cx> References: <20170611172022.GA3184@albert.catwhisker.org> <2474735.4VjKMe5DLv@ralph.baldwin.cx> From: Xin LI Date: Mon, 12 Jun 2017 12:28:55 -0700 Message-ID: Subject: Re: post ino64: lockd no runs? To: John Baldwin Cc: FreeBSD Current , stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 19:28:57 -0000 On Mon, Jun 12, 2017 at 10:14 AM, John Baldwin wrote: > On Sunday, June 11, 2017 11:12:25 AM David Wolfskill wrote: >> On Sun, Jun 04, 2017 at 08:57:44AM -0400, Michael Butler wrote: >> > It seems that {rpc.}lockd no longer runs after the ino64 changes on any >> > of my systems after a full rebuild of src and ports. No log entries >> > offer any insight as to why :-( >> > >> > imb >> >> I don't tend to use NFS on my systems that are running head, so I >> haven't had occasion to test this as stated. >> >> However, I just completed my weekly update of the "prooduction" systems >> here at home, running stable/11. And I find that lockd seems to be ... >> claiming that all is well, but declining to run (for long). >> >> To the best of my knowledge, that was not the case until this last >> update, which was from: >> >> FreeBSD albert.catwhisker.org 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #316 r319566M/319569:1100514: Sun Jun 4 03:54:41 PDT 2017 root@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/ALBERT amd64 >> >> to >> >> FreeBSD albert.catwhisker.org 11.1-BETA1 FreeBSD 11.1-BETA1 #322 r319823M/319823:1100514: Sun Jun 11 03:56:10 PDT 2017 root@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/ALBERT amd64 >> >> The "glaringly obvious" symptom in my case is that I am now unable >> to (directly) save an email message from within mutt(1) by appending >> it to an NFS-resident file. (Saving it to a local file, then using >> cat(1) to append that to the NFS- resident file & removing the local >> copy works....) >> >> After a few variations on a theme of: >> >> albert(11.1)[5] sudo service lockd restart >> lockd not running? >> Starting lockd. >> albert(11.1)[6] echo $? >> 0 >> albert(11.1)[7] service lockd status >> lockd is not running. >> >> I finally(!) thought to ask ktrace what's going on (as tailing >> /var/log/messages was completely unproductive, even after enabling >> rc_debug). >> >> So I tried: "sudo ktrace -di service lockd restart"; upon exanimation of >> the output of kdump(1), I see that the trace ends with: >> >> ... >> 2811 rpc.lockd NAMI "/var/run/logpriv" >> 2786 sh CALL read(0xa,0x627fc0,0x400) >> 2786 sh GIO fd 10 read 0 bytes >> "" >> 2811 rpc.lockd RET connect 0 >> 2786 sh RET read 0 >> 2811 rpc.lockd CALL sendto(0x3,0x7fffffffe2c0,0x27,0,0,0) >> 2786 sh CALL exit(0) >> 2811 rpc.lockd GIO fd 3 wrote 39 bytes >> "<30>Jun 11 15:43:10 rpc.lockd: Starting" >> 2811 rpc.lockd RET sendto 39/0x27 >> 2811 rpc.lockd CALL sigaction(SIGALRM,0x7fffffffec20,0) >> 2811 rpc.lockd RET sigaction 0 >> 2811 rpc.lockd CALL nlm_syscall(0,0x1e,0x4,0x801015040) >> 2811 rpc.lockd RET nlm_syscall -1 errno 14 Bad address > > This is a really good clue. nlm_syscall is dying with EFAULT. The last > argument is a pointer to an array of char * pointers, and the only way > I can see it dying is if it fails to copyin() one of the strings pointed > to by those pointers. You could try running rpc.lockd under gdb from > ports and setting a breakpoint on 'nlm_syscall' and then printing out > 'addr_count' and 'p addrs@(addr_count * 2)'. Yes, I found that the kernel was trying to copyin() from NULL, and then found that corresponds to 'uaddr'. After some tracing I found that the tightened condition for taddr2uaddr have enforced (correctly) buffer length passed from caller, which was not set correctly since ~9 years ago (r177633, which sets the size to sizeof(pointer)) but never gets noticed because there is no check on that, so the solution seems to be to correctly set the length values to (allocated size), and that have fixed the issue for me. The code could use some cleanups and I plan to do it at some later time. > Unfortunately I'm not able to reproduce the failure on a test machine > I have running head post-ino64. This should have been fixed by r319852 in -HEAD ( https://svnweb.freebsd.org/base?view=revision&revision=319852 ), and I'll MFC the change after 3 days' settle assuming there is no objections, as this is a regression. Cheers, From owner-freebsd-current@freebsd.org Tue Jun 13 00:45:14 2017 Return-Path: Delivered-To: freebsd-current@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 8BF76D87C3B; Tue, 13 Jun 2017 00:45:14 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 67A0E1C7E; Tue, 13 Jun 2017 00:45:13 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v5D0jCVH053880; Mon, 12 Jun 2017 17:45:12 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v5D0jC4a053879; Mon, 12 Jun 2017 17:45:12 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201706130045.v5D0jC4a053879@pdx.rh.CN85.dnsmgr.net> Subject: Re: post ino64: lockd no runs? In-Reply-To: To: Xin LI Date: Mon, 12 Jun 2017 17:45:12 -0700 (PDT) CC: John Baldwin , FreeBSD Current , stable@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Tue, 13 Jun 2017 05:39:09 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 00:45:14 -0000 > On Mon, Jun 12, 2017 at 10:14 AM, John Baldwin wrote: > > On Sunday, June 11, 2017 11:12:25 AM David Wolfskill wrote: > >> On Sun, Jun 04, 2017 at 08:57:44AM -0400, Michael Butler wrote: > >> > It seems that {rpc.}lockd no longer runs after the ino64 changes on any > >> > of my systems after a full rebuild of src and ports. No log entries > >> > offer any insight as to why :-( > >> > > >> > imb > >> > >> I don't tend to use NFS on my systems that are running head, so I > >> haven't had occasion to test this as stated. > >> > >> However, I just completed my weekly update of the "prooduction" systems > >> here at home, running stable/11. And I find that lockd seems to be ... > >> claiming that all is well, but declining to run (for long). > >> > >> To the best of my knowledge, that was not the case until this last > >> update, which was from: > >> > >> FreeBSD albert.catwhisker.org 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #316 r319566M/319569:1100514: Sun Jun 4 03:54:41 PDT 2017 root@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/ALBERT amd64 > >> > >> to > >> > >> FreeBSD albert.catwhisker.org 11.1-BETA1 FreeBSD 11.1-BETA1 #322 r319823M/319823:1100514: Sun Jun 11 03:56:10 PDT 2017 root@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/ALBERT amd64 > >> > >> The "glaringly obvious" symptom in my case is that I am now unable > >> to (directly) save an email message from within mutt(1) by appending > >> it to an NFS-resident file. (Saving it to a local file, then using > >> cat(1) to append that to the NFS- resident file & removing the local > >> copy works....) > >> > >> After a few variations on a theme of: > >> > >> albert(11.1)[5] sudo service lockd restart > >> lockd not running? > >> Starting lockd. > >> albert(11.1)[6] echo $? > >> 0 > >> albert(11.1)[7] service lockd status > >> lockd is not running. > >> > >> I finally(!) thought to ask ktrace what's going on (as tailing > >> /var/log/messages was completely unproductive, even after enabling > >> rc_debug). > >> > >> So I tried: "sudo ktrace -di service lockd restart"; upon exanimation of > >> the output of kdump(1), I see that the trace ends with: > >> > >> ... > >> 2811 rpc.lockd NAMI "/var/run/logpriv" > >> 2786 sh CALL read(0xa,0x627fc0,0x400) > >> 2786 sh GIO fd 10 read 0 bytes > >> "" > >> 2811 rpc.lockd RET connect 0 > >> 2786 sh RET read 0 > >> 2811 rpc.lockd CALL sendto(0x3,0x7fffffffe2c0,0x27,0,0,0) > >> 2786 sh CALL exit(0) > >> 2811 rpc.lockd GIO fd 3 wrote 39 bytes > >> "<30>Jun 11 15:43:10 rpc.lockd: Starting" > >> 2811 rpc.lockd RET sendto 39/0x27 > >> 2811 rpc.lockd CALL sigaction(SIGALRM,0x7fffffffec20,0) > >> 2811 rpc.lockd RET sigaction 0 > >> 2811 rpc.lockd CALL nlm_syscall(0,0x1e,0x4,0x801015040) > >> 2811 rpc.lockd RET nlm_syscall -1 errno 14 Bad address > > > > This is a really good clue. nlm_syscall is dying with EFAULT. The last > > argument is a pointer to an array of char * pointers, and the only way > > I can see it dying is if it fails to copyin() one of the strings pointed > > to by those pointers. You could try running rpc.lockd under gdb from > > ports and setting a breakpoint on 'nlm_syscall' and then printing out > > 'addr_count' and 'p addrs@(addr_count * 2)'. > > Yes, I found that the kernel was trying to copyin() from NULL, and > then found that corresponds to 'uaddr'. After some tracing I found > that the tightened condition for taddr2uaddr have enforced (correctly) > buffer length passed from caller, which was not set correctly since ~9 > years ago (r177633, which sets the size to sizeof(pointer)) but never > gets noticed because there is no check on that, so the solution seems > to be to correctly set the length values to (allocated size), and that > have fixed the issue for me. > > The code could use some cleanups and I plan to do it at some later time. > > > Unfortunately I'm not able to reproduce the failure on a test machine > > I have running head post-ino64. > > This should have been fixed by r319852 in -HEAD ( > https://svnweb.freebsd.org/base?view=revision&revision=319852 ), and > I'll MFC the change after 3 days' settle assuming there is no > objections, as this is a regression. (RE hat on) The next 11.1 release builds start on the 16th, please try to make your RFa to RE and complete the merge before that date, I would really hate to have 11.1 go out without this fixed. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Tue Jun 13 08:59:35 2017 Return-Path: Delivered-To: freebsd-current@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 64263BEE5E0 for ; Tue, 13 Jun 2017 08:59:35 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D6551738B0 for ; Tue, 13 Jun 2017 08:59:34 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MH4Os-1d6wHR3be6-00Dsrn for ; Tue, 13 Jun 2017 10:59:32 +0200 Date: Tue, 13 Jun 2017 10:59:25 +0200 From: "O. Hartmann" To: freebsd-current Subject: FreeBSD-base: build 11-STABLE on 12-CURRENT host system Message-ID: <20170613105925.6e95e67b@freyja.zeit4.iv.bundesimmobilien.de> Organization: Walstatt X-Mailer: Claws Mail 3.15.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:GghmNBftrVrC+H39El/+RYZuTi4D6EgSEDLDeO6q11UhoiKQfCn iSDfE0MRZCqUKbHb/27TN1SvtpNY6jtNLffiRu5Xxd3sWGUWTT+GFBN7VUG97BsizAf04mp IIx5uLecXB750QLTYk3pRJRBdegsNtOxZlJr8EZEZoUALykupW7vljl9qTD54bnBXDUbWFi tmKq/cTzuuQLrvkdUPLMw== X-UI-Out-Filterresults: notjunk:1;V01:K0:Lb0ZE+okLLU=:JTzHNaKJY1SGQMpCYiqi67 MGJktw7AdeDJiB1NyHK1IZ5bTo9LKScnK8XUBxZDIadLoS653khrPXumbeSItUQvubbtYyCNh 8DZ1nHt3iRgcVgkGW29Ui92yQtQdDfiK4psh6OkFd3APO4IeTlnd++XF5hTZQ6Cmw4c/ZPyep l2cbs0xUbpngNxAhTFWdrH+Fbz6w3hiyjPSfKwmggDUjTgC3T5ShjCVcQEqVpqtetN1JhqsMw LhPSP+Cz1Cbkal2BgNGUw0B0To3iKdlzgwfO0C5s2THIbYYw81gYuhGT0e28bYvkh0hgsLajh c1oSOLb0lO4GKas0g3cxOmXowK8e+x4A35/jiIN5YZZTpCp8XE067toJjB3cZLGwf8GhFXkVx FWjci1z2hHRDmlIeYCHJTJR4JdFUE59R1dJyi1PhsFO6mZFZ18uwzf3peGrpN+k11+7iKpd48 G+wFtwQHWKTO3ZkaDxyltj8Kw9fel1wb3CHLvfOPQ+fERercyezaGhchp4Pm5HF7nuBsuqo2k +x94xix/rQm6b5zgz+UkarG6wvJpzpYPbA5ICD2XurJg2PRt+YGWboESzSlcDwovzw40r8A4+ fmkAIjmrqGzV3A4/p2v+snZJ/7r3qAZvwpoIThTB37xbMf2GhnuugegVc4den9kX1aYYhmmbD +WJHPbcIGWyXTVMqwR2bG7Vt7gdupM2d2GLN5+T/jwLbRrSQyt7cPfm+Me33r6c74Dwr3R0pn 8CfDNKZKP+OJgLm0b6tldwre5ViPi5PB72vtgkF1biXvM4K69Ga7HLNF4GEuIXM0JNSp2v00i 2iEkiy/ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 08:59:35 -0000 I do not know whether this is the correct list, but since FreeBSD-base support (updating the OS via pkg as a feature) is considered BETA in FBSD 11, it is best to address the CURRENT list. Sorry if I'm mislead. The problem is, I try to build a "repo" on a 12-CURRENT host (r319846) with a dedicated 11-STABLE source tree (at the moment at r319892). It doesn't work, the creation of packages fail with the error shown below. It seems some targets are missing and I suspect the divergence between host OS and the supposed target OS (11-STABLE) as the warning "Major OS version upgrade detected" indicates. I provide you with these variables/environment setting I use: RELCONFBASE=/pool/relconfig/11/ #outside chroot()! __MAKE_CONF=${RELCONFBASE}/etc/make.conf SRCCONF=${RELCONFBASE}/etc/src.conf SRC_ENV_CONF=${RELCONFBASE}/etc/src-env.conf NO_INSTALLEXTRAKERNELS=NO KERNCONFDIR=${RELCONFBASE}/kernel_conf/amd64/ KERNCONF="MONITOR GENERIC2" and the build itself: cd ${SRCBASE}/src ; env MAKEOBJDIRPREFIX=${SRCBASE}/obj/ \ make \ __MAKE_CONF=${__MAKE_CONF} \ SRCCONF=${SRCCONF} \ SRC_ENV_CONF=${SRC_ENV_CONF} \ KERNCONFDIR=${KERNCONFDIR} \ KERNCONF="${KERNCONF}" \ NO_INSTALLEXTRAKERNELS=NO \ ${MKPARALLEL} \ buildworld buildkernel So far, this works with all desired aspects. But the make-target "packages" fails then as shown below. I use the very same schematics of a setup with TARGET=arm64 for crosscompiling 12-CURRENT for arm64.aarch64, which runs up to the end very smooth - so, again, the suspect is the diifference between the major OS versions. I's like to know how to build a 11-STABLE or, in the near future, the 11.1-RELENG FreeBSD-base repository on a 12-CURRENT platform. Is this possible in pricinciple (I think yes, but ...)? Or is there something I have missed? Thanks in advance, Oliver Hartmann [...] install -U -M /pool/sources/11-STABLE//obj//pool/sources/11-STABLE/src/amd64.amd64/kernelstage//kernel.GENERIC2.premeta -D /pool/sources/11-STABLE/obj/pool/sources/11-STABLE/src/amd64.amd64/kernelstage -T release -o root -g wheel -m 555 zlib.ko /pool/sources/11-STABLE/obj/pool/sources/11-STABLE/src/amd64.amd64/kernelstage/kernel.GENERIC2/boot/kernel.GENERIC2/ kldxref /pool/sources/11-STABLE/obj/pool/sources/11-STABLE/src/amd64.amd64/kernelstage/kernel.GENERIC2/boot/kernel.GENERIC2 --- create-packages --- --- create-world-packages --- --- create-world-packages --- ===> Creating FreeBSD-acct-11.1 pkg: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended pkg: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended pkg: Unable to access file /pool/sources/11-STABLE//obj//pool/sources/11-STABLE/src/amd64.amd64/worldstage/pool/sources/11-STABLE//obj//pool/sources/11-STABLE/src/amd64.amd64/worldstage/etc/periodic/daily/310.accounting:No such file or directory pkg: Unable to access file /pool/sources/11-STABLE//obj//pool/sources/11-STABLE/src/amd64.amd64/worldstage/pool/sources/11-STABLE//obj//pool/sources/11-STABLE/src/amd64.amd64/worldstage/etc/periodic/monthly/200.accounting:No such file or directory pkg: Unable to access file /pool/sources/11-STABLE//obj//pool/sources/11-STABLE/src/amd64.amd64/worldstage/pool/sources/11-STABLE//obj//pool/sources/11-STABLE/src/amd64.amd64/worldstage/etc/rc.d/accounting:No such file or directory pkg: Unable to access file /pool/sources/11-STABLE//obj//pool/sources/11-STABLE/src/amd64.amd64/worldstage/pool/sources/11-STABLE//obj//pool/sources/11-STABLE/src/amd64.amd64/worldstage/usr/bin/lastcomm:No such file or directory pkg: Unable to access file /pool/sources/11-STABLE//obj//pool/sources/11-STABLE/src/amd64.amd64/worldstage/pool/sources/11-STABLE//obj//pool/sources/11-STABLE/src/amd64.amd64/worldstage/usr/share/man/man1/lastcomm.1.gz:No such file or directory pkg: Unable to access file /pool/sources/11-STABLE//obj//pool/sources/11-STABLE/src/amd64.amd64/worldstage/pool/sources/11-STABLE//obj//pool/sources/11-STABLE/src/amd64.amd64/worldstage/usr/sbin/accton:No such file or directory pkg: Unable to access file /pool/sources/11-STABLE//obj//pool/sources/11-STABLE/src/amd64.amd64/worldstage/pool/sources/11-STABLE//obj//pool/sources/11-STABLE/src/amd64.amd64/worldstage/usr/share/man/man8/accton.8.gz:No such file or directory pkg: Unable to access file /pool/sources/11-STABLE//obj//pool/sources/11-STABLE/src/amd64.amd64/worldstage/pool/sources/11-STABLE//obj//pool/sources/11-STABLE/src/amd64.amd64/worldstage/usr/sbin/sa:No such file or directory pkg: Unable to access file /pool/sources/11-STABLE//obj//pool/sources/11-STABLE/src/amd64.amd64/worldstage/pool/sources/11-STABLE//obj//pool/sources/11-STABLE/src/amd64.amd64/worldstage/usr/share/man/man8/sa.8.gz:No such file or directory *** [create-world-packages] Error code 70 [...] From owner-freebsd-current@freebsd.org Wed Jun 14 11:21:20 2017 Return-Path: Delivered-To: freebsd-current@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 BAC6CD8B726 for ; Wed, 14 Jun 2017 11:21:20 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 752DA83D26 for ; Wed, 14 Jun 2017 11:21:20 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: by mail-qk0-x22d.google.com with SMTP id d14so33679494qkb.1 for ; Wed, 14 Jun 2017 04:21:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=4cVrW5sFn92p529mKvwbvWA4dg+YdlATs82W1gdVge8=; b=tZNJGByiYTN6PmOkXVxKa7gL8gMJN8BEnhSK56bOgn/nB3PZxPW3aEO0SQqNtYTujG sx0A5LtzVILqgjRZus3VSg5cENUF5X/2ziwyJMQ6Nl0QZOudrjZt4LEE0ls4zFKM9FG3 9N8xscB+5BbLqcGOxNh7RrgP7D4cZVmBv/BqtDMGik33P93NQOw29A/jNC2QaLTLk780 qapTLtVORWLV6BzqFF1k6ndgkGwoGLQ/XcGEGZrfLQu45ITDcUi/1yMKtvReBUN3FSrm ZVVPa7zXL3xJ6IGzNgnKcz2i8E+BJJIoyrVLKsHcSTyKrq/U63Mh0baSKax+DlV9EnN1 eqQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=4cVrW5sFn92p529mKvwbvWA4dg+YdlATs82W1gdVge8=; b=M8v/OgBV17e/+bYaTIpfB4okDDdSq0/w/c/llooPqC0FkLzsQR5pyaAcBCasZhhnK+ Vpu1cestgl1sCxcpMkpPPIUG14NpUX3x83B+g1N+dFqo0HS8wZqH2AWkexgek+INlvcL 2Ad1BeA5LS1ivyFmSt7kfEoZnPFDSZGBDpXzbku7gZAxnJy4sOVQpxOfYYvxPTB5Zqjq kcGH0udhlTylAnbcrnryYWnVGUXleKLEJBplRbd7yKI7Rh3U1603MbwrRw612V5yPz9r GlyB/kXWqHo6E4Sw91oHgkKcI4XFYo683HjEDt3rB4DniFpWNZhEmWa2DAJwQi2Y/mzX x7xw== X-Gm-Message-State: AKS2vOz4Rfq0xn3IcJo1z0VJLUIfK+XFLZ6U0zKV77iEPgtu162QF3RA ZrNVKnnTWoXkeK4b9B5VWo4VJAuVT9/F X-Received: by 10.55.131.132 with SMTP id f126mr131069qkd.212.1497439279289; Wed, 14 Jun 2017 04:21:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.93.114 with HTTP; Wed, 14 Jun 2017 04:20:48 -0700 (PDT) In-Reply-To: References: <0100015c6fc1167c-6e139920-60d9-4ce3-9f59-15520276aebb-000000@email.amazonses.com> From: Jia-Shiun Li Date: Wed, 14 Jun 2017 19:20:48 +0800 Message-ID: Subject: Re: Time to increase MAXPHYS? To: "freebsd-current@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 11:21:20 -0000 On Sun, Jun 4, 2017 at 1:33 PM, Warner Losh wrote: > On Sat, Jun 3, 2017 at 2:59 PM, Colin Percival > wrote: > > > On January 24, 1998, in what was later renumbered to SVN r32724, dyson@ > > wrote: > > > Add better support for larger I/O clusters, including larger physical > > > I/O. The support is not mature yet, and some of the underlying > > implementation > > > needs help. However, support does exist for IDE devices now. > > > > and increased MAXPHYS from 64 kB to 128 kB. Is it time to increase it > > again, > > or do we need to wait at least two decades between changes? > > > > This is hurting performance on some systems; in particular, EC2 "io1" > disks > > are optimized for 256 kB I/Os, EC2 "st1" (throughput optimized spinning > > rust) > > disks are optimized for 1 MB I/Os, and Amazon's NFS service (EFS) > > recommends > > using a maximum I/O size of 1 MB (and despite NFS not being *physical* > I/O > > it > > seems to still be limited by MAXPHYS). > > > > MAXPHYS is the largest I/O transaction you can push through the system. It > doesn't matter that the I/O is physical or not. The name is a relic from a > time that NFS didn't exist. > Sounds like MAXPHYS usage has grown too widespread than intended to be. Would it be better for specific components to depart from MAXPHYS if they care about performance, and use more specific limit from protocol or hardware spec etc. e.g. MAXDMASIZE, MAX_ATA_IO_SIZE, and maybe some query functions. Having a global max for everything to use just doesn't feel right. If this is the direction to go in the long run, then changing MAXPHYS references to own-defined limitations may be more meaningful than raising it universally. Then I'd propose not to raise it, or people would not be motivated to fix that. A quick grep shows that many references use it as a cap only 'for safety'. -Jia-Shiun From owner-freebsd-current@freebsd.org Wed Jun 14 12:21:41 2017 Return-Path: Delivered-To: freebsd-current@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 0D056D8CD3D for ; Wed, 14 Jun 2017 12:21:41 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E0B1EDAB for ; Wed, 14 Jun 2017 12:21:40 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: by mailman.ysv.freebsd.org (Postfix) id D78ADD8CD3A; Wed, 14 Jun 2017 12:21:40 +0000 (UTC) Delivered-To: current@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 D70DCD8CD39; Wed, 14 Jun 2017 12:21:40 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9CF2DDA7; Wed, 14 Jun 2017 12:21:40 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.127] (helo=rmmprod05.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1dL6q6-0003wE-4D; Wed, 14 Jun 2017 13:51:58 +0200 Received: from mail by rmmprod05.runbox with local (Exim 4.86_2) (envelope-from ) id 1dL6q6-0006j1-2h; Wed, 14 Jun 2017 13:51:58 +0200 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [Authenticated user (846156)] by runbox.com with http (RMM6); Wed, 14 Jun 2017 11:51:57 GMT From: "Jeffrey Bouquet" To: "current" , "ports" Subject: ERRATA: 12.0-CURRENT binaries 'stat' errors. Date: Wed, 14 Jun 2017 04:51:57 -0700 (PDT) X-Mailer: RMM6 Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 12:21:41 -0000 ne /usr/local/bin/ne: Undefined symbol "stat" ktrace -di ne /usr/local/bin/ne: Undefined symbol "stat" I may have posted in error an 'fstat' instead, unsure, to the ports list ju= st yesterday or so. A workaround is to use pkg.freebsd.org to attain compat11x binaries which r= un. This is a showstopper here otherwise as some large ports, do not build on t= he legacy desktop [ 2004 ] that has been updated numerous times, and for which I do not wish to reinstall. And, pkg gives conflicting messages, as pkg binaries are shown ABI v12 wher= eas if I do build from ports, the ports are shown as v11 ABI.=20 Also, ABI changed: 'freebsd:12:x86:32' > 'freebsd:12:*' upgrades are requ= ested making things so I have to lock many ports at v11 as the newer have the 'stat' o= r 'fstat' error. So more than one issue, I think maybe three in tandem making 'which to ta= ckle first' even problematic. Any advices? even a binary editor to examine the /ne for 'stat' code ?=20 Apologies for not being knowledgeable in many of the ways to code a solut= ion or even coding...=20= From owner-freebsd-current@freebsd.org Wed Jun 14 14:25:52 2017 Return-Path: Delivered-To: freebsd-current@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 C9010D8F113 for ; Wed, 14 Jun 2017 14:25:52 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B1B56657ED for ; Wed, 14 Jun 2017 14:25:52 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id AE044D8F111; Wed, 14 Jun 2017 14:25:52 +0000 (UTC) Delivered-To: current@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 AD79FD8F110; Wed, 14 Jun 2017 14:25:52 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (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 78572657EC; Wed, 14 Jun 2017 14:25:52 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [192.168.2.2] (unknown [77.95.97.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id CBA8A9730; Wed, 14 Jun 2017 16:25:50 +0200 (CEST) From: Dimitry Andric Message-Id: <1764FF36-A96E-4F85-A2D0-3B0C30E237AD@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_5971A61C-135C-4A28-968D-B15C4A34B0FC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: ERRATA: 12.0-CURRENT binaries 'stat' errors. Date: Wed, 14 Jun 2017 16:25:24 +0200 In-Reply-To: Cc: current , ports To: Jeffrey Bouquet References: X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 14:25:52 -0000 --Apple-Mail=_5971A61C-135C-4A28-968D-B15C4A34B0FC Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 14 Jun 2017, at 13:51, Jeffrey Bouquet wrote: > > ne > /usr/local/bin/ne: Undefined symbol "stat" > ktrace -di ne > /usr/local/bin/ne: Undefined symbol "stat" Be sure to exactly follow the procedure mentioned in /usr/src/UPDATING entry 20170523. My guess is that you do not have COMPAT_FREEBSD11 in your kernel configuration. If so, add that option, then rebuild and reinstall your kernel. -Dimitry --Apple-Mail=_5971A61C-135C-4A28-968D-B15C4A34B0FC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAllBR20ACgkQsF6jCi4glqMo9gCfZg5keG7XvsTn39kbr9OiWxT8 hvkAnjjJVpFgEYRzX0ZWF8tD2ZyX21uU =YWYh -----END PGP SIGNATURE----- --Apple-Mail=_5971A61C-135C-4A28-968D-B15C4A34B0FC-- From owner-freebsd-current@freebsd.org Wed Jun 14 16:19:45 2017 Return-Path: Delivered-To: freebsd-current@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 EE1F4BEE2EB for ; Wed, 14 Jun 2017 16:19:45 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 2C9016EFFB for ; Wed, 14 Jun 2017 16:19:45 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: by mail-lf0-x22a.google.com with SMTP id m77so5123596lfe.0 for ; Wed, 14 Jun 2017 09:19:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=lny7ch923Emb3tuqdlY8gigkZi/TG7e1kdpTRVZMvcY=; b=eSEaIHE1OvMnKFWdlNo9/61coljWiOHonuK6Yz4Jbw2AVkHMsZbJgugE5oH0jO3bAj /SFCBPiB6nGIMemmG3+djJdcyozT/axVaBJpFRUvDAI52PRuW7FjXzLybYm3Hp+HOKY/ LT6Eu1dNsrzReKCqqUUxyYYMd9o29addrM+fGTAtgWfa8F2aLiGr981OOF3i8E/Vv8+h NYUSRnmxP/hENwlbvtyYmqINcnLrw7RI+a3vwd1WCM9a8mLJrdZ3NBFCRRdIyoIr69Nd 9smCg00xWjGFlzBvdySraRv9xSh+kmdVNcCT4bLftTHPVitSWQ58pVQAW258zzYLrcFf vRyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=lny7ch923Emb3tuqdlY8gigkZi/TG7e1kdpTRVZMvcY=; b=Q9Ak9o/GNYEG5GZimSdhiu/vwqGHCN1WEtX8bza4+f9efo7nKiUpNuu22wccYG1ZPG yPcL7eDnLNyeRaewLmkqXZG4ZgpmtpKzQCt+48xc4Xd64ujucUciFx9MQkMS1rW3Nhf8 Kd1O+mtqx9P4BwHZEB1c3upw+0YO1rZwIWIB1Y82gzkl/c/PtAPmG/sT0G4JYzMtVqaG 0jKhY2qkuQ4y1Rd3HKgx7RUvrRdMFR0rW8xA3M9KFMvx1fFZymmfSddIZ0Mui3l8MzQB yJA6G3mnjIZbByB2LYBnPtW8+2CSZ20WaWWT7VeKorr7qYW11nzw7khPmxnkyRTCUVRS oSAQ== X-Gm-Message-State: AKS2vOyU4QlrM8UgdmtNYe5+x/cG4DtbYGq5U7aTluQ7dFIwa5sIid/u P7zTcqNA+rAf0XnoL+k= X-Received: by 10.46.82.79 with SMTP id g76mr272426ljb.32.1497457180799; Wed, 14 Jun 2017 09:19:40 -0700 (PDT) Received: from localhost ([81.19.73.157]) by smtp.gmail.com with ESMTPSA id r5sm108776lfe.41.2017.06.14.09.19.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Jun 2017 09:19:40 -0700 (PDT) Date: Wed, 14 Jun 2017 18:57:14 +0300 From: Vladimir Zakharov To: freebsd-current@freebsd.org Subject: ntpd dies soon after start Message-ID: <20170614155714.lvljvn4dsztinull@vzakharov> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Operating-System: FreeBSD 12.0-CURRENT amd64 X-PGP-Key: http://vzakharov.ru/pubkey.asc User-Agent: NeoMutt/20170609 (1.8.3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 16:19:46 -0000 Hello! I have ntpd enabled to start during boot. I see, that it starts. But querying it after booting fails: # ntpq -p ntpq: read: Connection refused After manual start, it works for several seconds and then dies. root@vzakharov:~ # service ntpd start Starting ntpd. root@vzakharov:~ # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 0.000 ftpshare1.corbi 89.109.251.21 2 u 1 64 1 1.489 1344688 0.000 root@vzakharov:~ # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 0.000 ftpshare1.corbi 89.109.251.21 2 u 1 64 1 1.495 1344688 0.018 time.ooonet.ru 89.109.251.24 2 u 1 64 1 25.201 1344687 0.000 nag.aleksdem.co 194.190.168.1 2 u 1 64 1 1.914 1344687 0.000 root@vzakharov:~ # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 0.000 ground.corbina. 193.11.166.20 2 u 2 64 1 1.673 1344687 0.000 ftpshare1.corbi 193.11.166.20 2 u 1 64 1 1.532 1344688 0.018 time.ooonet.ru 89.109.251.24 2 u 2 64 1 25.169 1344687 0.035 nag.aleksdem.co 194.190.168.1 2 u 1 64 1 2.740 1344686 0.311 root@vzakharov:~ # ntpq -p ntpq: read: Connection refused Cleaning, rebuilding and reinstalling world does not help. # uname -a FreeBSD vzakharov 12.0-CURRENT FreeBSD 12.0-CURRENT #87 r319940: Wed Jun 14 17:02:16 MSK 2017 root@vzakharov:/home/obj/usr/src/sys/GENERIC-NODEBUG amd64 # truss -f /usr/sbin/ntpd -c /etc/ntp.conf -p /var/run/ntpd.pid -f /var/db/ntpd.drift ... (closing descriptors is omitted) 14511: openat(AT_FDCWD,"/dev/null",O_RDONLY,00) = 0 (0x0) 14511: dup2(0,1) = 1 (0x1) 14511: dup2(0,2) = 2 (0x2) 14511: socket(PF_LOCAL,SOCK_DGRAM|SOCK_CLOEXEC,0) = 3 (0x3) 14511: connect(3,{ AF_UNIX "/var/run/logpriv" },106) = 0 (0x0) 14511: setsid() = 14511 (0x38af) 14511: getrlimit(RLIMIT_STACK,{ cur=536870912,max=536870912 }) = 0 (0x0) 14511: setrlimit(RLIMIT_STACK,{ cur=204800,max=536870912 }) = 0 (0x0) 14511: setrlimit(RLIMIT_MEMLOCK,{ cur=33554432,max=33554432 }) = 0 (0x0) 14511: sigprocmask(SIG_SETMASK,{ SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0) 14511: sigaction(SIGHUP,{ 0x80107afe0 SA_SIGINFO ss_t },{ SIG_DFL 0x0 ss_t }) = 0 (0x0) 14511: sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0) 14511: sigprocmask(SIG_SETMASK,{ SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0) 14511: sigaction(SIGINT,{ 0x80107afe0 SA_SIGINFO ss_t },{ SIG_DFL SA_RESTART ss_t }) = 0 (0x0) 14511: sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0) 14511: sigprocmask(SIG_SETMASK,{ SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0) 14511: sigaction(SIGQUIT,{ 0x80107afe0 SA_SIGINFO ss_t },{ SIG_DFL SA_RESTART ss_t }) = 0 (0x0) 14511: sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0) 14511: sigprocmask(SIG_SETMASK,{ SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0) 14511: sigaction(SIGTERM,{ 0x80107afe0 SA_SIGINFO ss_t },{ SIG_DFL SA_RESTART ss_t }) = 0 (0x0) 14511: sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0) 14511: sigprocmask(SIG_SETMASK,{ SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0) 14511: sigaction(SIGBUS,{ 0x80107afe0 SA_SIGINFO ss_t },{ SIG_DFL 0x0 ss_t }) = 0 (0x0) 14511: sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0) 14511: sigprocmask(SIG_SETMASK,{ SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0) 14511: sigaction(SIGUSR1,{ 0x80107afe0 SA_SIGINFO ss_t },{ SIG_DFL SA_RESTART ss_t }) = 0 (0x0) 14511: sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0) 14511: sigprocmask(SIG_SETMASK,{ SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0) 14511: sigaction(SIGUSR2,{ 0x80107afe0 SA_SIGINFO ss_t },{ SIG_DFL SA_RESTART ss_t }) = 0 (0x0) 14511: sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0) 14511: sigprocmask(SIG_SETMASK,{ SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0) 14511: sigaction(SIGPIPE,{ SIG_IGN 0x0 ss_t },{ SIG_DFL SA_RESTART ss_t }) = 0 (0x0) 14511: sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0) 14511: fstatat(AT_FDCWD,"/usr/share/nls/C/libc.cat",0x7fffffffe460,0x0) ERR#2 'No such file or directory' 14511: fstatat(AT_FDCWD,"/usr/share/nls/libc/C",0x7fffffffe460,0x0) ERR#2 'No such file or directory' 14511: fstatat(AT_FDCWD,"/usr/local/share/nls/C/libc.cat",0x7fffffffe460,0x0) ERR#2 'No such file or directory' 14511: fstatat(AT_FDCWD,"/usr/local/share/nls/libc/C",0x7fffffffe460,0x0) ERR#2 'No such file or directory' 14511: sigprocmask(SIG_SETMASK,{ SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0) 14511: sigaction(SIGALRM,{ 0x80107afe0 SA_SIGINFO ss_t },{ SIG_DFL 0x0 ss_t }) = 0 (0x0) 14511: sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0) 14511: setitimer(0,{ 1.000000, 1.000000 },0x0) = 0 (0x0) 14511: __sysctl(0x7fffffffe608,0x2,0x6c6f70,0x7fffffffe600,0x0,0x0) = 0 (0x0) 14511: __sysctl(0x7fffffffe608,0x2,0x6c7070,0x7fffffffe600,0x0,0x0) = 0 (0x0) 14511: __sysctl(0x7fffffffe608,0x2,0x6c7170,0x7fffffffe600,0x0,0x0) = 0 (0x0) 14511: __sysctl(0x7fffffffe608,0x2,0x6c7270,0x7fffffffe600,0x0,0x0) = 0 (0x0) 14511: __sysctl(0x7fffffffe608,0x2,0x6c7370,0x7fffffffe600,0x0,0x0) = 0 (0x0) 14511: fstatat(AT_FDCWD,"/etc/nsswitch.conf",{ mode=-rw-r--r-- ,inode=722492,size=331,blksize=32768 },0x0) = 0 (0x0) 14511: open("/etc/nsswitch.conf",O_RDONLY|O_CLOEXEC,0666) = 4 (0x4) 14511: ioctl(4,TIOCGETA,0x7fffffffdd60) ERR#25 'Inappropriate ioctl for device' 14511: fstat(4,{ mode=-rw-r--r-- ,inode=722492,size=331,blksize=32768 }) = 0 (0x0) 14511: read(4,"#\n# nsswitch.conf(5) - name ser"...,32768) = 331 (0x14b) 14511: read(4,0x801a89d00,32768) = 0 (0x0) 14511: access("/lib/nss_compat.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/lib/nss_compat.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/lib/compat/nss_compat.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/lib/nss_compat.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/lib/gcc5/nss_compat.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/lib/nss/nss_compat.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/lib/opencollada/nss_compat.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/lib/perl5/5.24/mach/CORE/nss_compat.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/lib/qt4/nss_compat.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/lib/samba4/nss_compat.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/llvm40/lib/nss_compat.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/lib/casper/nss_compat.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/lib/nss_compat.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/lib/nss_compat.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/lib/nss_nis.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/lib/nss_nis.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/lib/compat/nss_nis.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/lib/nss_nis.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/lib/gcc5/nss_nis.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/lib/nss/nss_nis.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/lib/opencollada/nss_nis.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/lib/perl5/5.24/mach/CORE/nss_nis.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/lib/qt4/nss_nis.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/lib/samba4/nss_nis.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/llvm40/lib/nss_nis.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/lib/casper/nss_nis.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/lib/nss_nis.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/lib/nss_nis.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/lib/nss_files.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/lib/nss_files.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/lib/compat/nss_files.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/lib/nss_files.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/lib/gcc5/nss_files.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/lib/nss/nss_files.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/lib/opencollada/nss_files.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/lib/perl5/5.24/mach/CORE/nss_files.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/lib/qt4/nss_files.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/lib/samba4/nss_files.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/llvm40/lib/nss_files.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/lib/casper/nss_files.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/lib/nss_files.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/lib/nss_files.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/lib/nss_dns.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/lib/nss_dns.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/lib/compat/nss_dns.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/lib/nss_dns.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/lib/gcc5/nss_dns.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/lib/nss/nss_dns.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/lib/opencollada/nss_dns.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/lib/perl5/5.24/mach/CORE/nss_dns.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/lib/qt4/nss_dns.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/lib/samba4/nss_dns.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/local/llvm40/lib/nss_dns.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/lib/casper/nss_dns.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/lib/nss_dns.so.1",F_OK) ERR#2 'No such file or directory' 14511: access("/usr/lib/nss_dns.so.1",F_OK) ERR#2 'No such file or directory' 14511: ioctl(4,TIOCGETA,0x7fffffffdd30) ERR#25 'Inappropriate ioctl for device' 14511: close(4) = 0 (0x0) 14511: open("/etc/services",O_RDONLY|O_CLOEXEC,0666) = 4 (0x4) 14511: fstat(4,{ mode=-rw-r--r-- ,inode=723103,size=86292,blksize=32768 }) = 0 (0x0) 14511: lseek(4,0x0,SEEK_CUR) = 0 (0x0) 14511: lseek(4,0x0,SEEK_SET) = 0 (0x0) 14511: read(4,"#\n# Network services, Internet "...,32768) = 32768 (0x8000) 14511: read(4,"all\t\t533/udp\t #for emergenc"...,32768) = 32768 (0x8000) 14511: read(4,"oracle\nmciautoreg\t1528/tcp\nmc"...,32768) = 20756 (0x5114) 14511: read(4,0x801a89d00,32768) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: fstatat(AT_FDCWD,"/etc/nsswitch.conf",{ mode=-rw-r--r-- ,inode=722492,size=331,blksize=32768 },0x0) = 0 (0x0) 14511: open("/etc/hosts",O_RDONLY|O_CLOEXEC,0666) = 4 (0x4) 14511: fstat(4,{ mode=-rw-r--r-- ,inode=722313,size=1454,blksize=32768 }) = 0 (0x0) 14511: read(4,"# $FreeBSD: head/etc/hosts 10999"...,32768) = 1454 (0x5ae) 14511: read(4,0x801a89d00,32768) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: getpid() = 14511 (0x38af) 14511: sendto(3,"<102>Jun 14 18:48:40 ntpd[14511]"...,69,0,NULL,0) = 69 (0x45) 14511: open("/var/db/ntpd.drift",O_RDONLY,0666) = 4 (0x4) 14511: fstat(4,{ mode=-rw-r--r-- ,inode=642111,size=7,blksize=32768 }) = 0 (0x0) 14511: read(4,"39.458\n",32768) = 7 (0x7) 14511: close(4) = 0 (0x0) 14511: open("/var/run/ntpd.pid",O_WRONLY|O_CREAT|O_TRUNC,0666) = 4 (0x4) 14511: getpid() = 14511 (0x38af) 14511: fstat(4,{ mode=-rw-r--r-- ,inode=240843,size=0,blksize=32768 }) = 0 (0x0) 14511: write(4,"14511",5) = 5 (0x5) 14511: close(4) = 0 (0x0) 14511: open("/etc/ntp.conf",O_RDONLY,0666) = 4 (0x4) 14511: fstat(4,{ mode=-rw-r--r-- ,inode=723602,size=4070,blksize=32768 }) = 0 (0x0) 14511: read(4,"#\n# $FreeBSD: head/etc/ntp.conf"...,32768) = 4070 (0xfe6) 14511: read(4,0x801a89d00,32768) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: fstatat(AT_FDCWD,"/var/db/ntpd.leap-seconds.list",{ mode=-rw-r--r-- ,inode=240777,size=10408,blksize=32768 },0x0) = 0 (0x0) 14511: open("/var/db/ntpd.leap-seconds.list",O_RDONLY,0666) = 4 (0x4) 14511: fstat(4,{ mode=-rw-r--r-- ,inode=240777,size=10408,blksize=32768 }) = 0 (0x0) 14511: read(4,"#\n#\tIn the following text, the"...,32768) = 10408 (0x28a8) 14511: read(4,0x801a89d00,32768) = 0 (0x0) 14511: getpid() = 14511 (0x38af) 14511: sendto(3,"<101>Jun 14 18:48:40 ntpd[14511]"...,105,0,NULL,0) = 105 (0x69) 14511: lseek(4,0x0,SEEK_CUR) = 10408 (0x28a8) 14511: lseek(4,0x0,SEEK_SET) = 0 (0x0) 14511: read(4,"#\n#\tIn the following text, the"...,32768) = 10408 (0x28a8) 14511: read(4,0x801a89d00,32768) = 0 (0x0) 14511: getpid() = 14511 (0x38af) 14511: sendto(3,"<101>Jun 14 18:48:40 ntpd[14511]"...,154,0,NULL,0) = 154 (0x9a) 14511: close(4) = 0 (0x0) 14511: socket(PF_INET6,SOCK_DGRAM,0) = 4 (0x4) 14511: getrlimit(RLIMIT_NOFILE,{ cur=217944,max=217944 }) = 0 (0x0) 14511: getrlimit(RLIMIT_NOFILE,{ cur=217944,max=217944 }) = 0 (0x0) 14511: fcntl(4,F_DUPFD,0x14) = 20 (0x14) 14511: close(4) = 0 (0x0) 14511: setsockopt(20,SOL_SOCKET,SO_REUSEADDR,0x7fffffffe354,4) = 0 (0x0) 14511: setsockopt(20,IPPROTO_IPV6,IPV6_TCLASS,0x6bfd64,4) = 0 (0x0) 14511: socket(PF_INET6,SOCK_STREAM,0) = 4 (0x4) 14511: setsockopt(4,IPPROTO_IPV6,IPV6_V6ONLY,0x7fffffffe22c,4) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: socket(PF_INET6,SOCK_DGRAM,0) = 4 (0x4) 14511: setsockopt(4,IPPROTO_IPV6,IPV6_V6ONLY,0x7fffffffe22c,4) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: setsockopt(20,IPPROTO_IPV6,IPV6_V6ONLY,0x7fffffffe358,4) = 0 (0x0) 14511: setsockopt(20,IPPROTO_IPV6,IPV6_V6ONLY,0x7fffffffe358,4) = 0 (0x0) 14511: bind(20,{ AF_INET6 [::]:123 },28) = 0 (0x0) 14511: setsockopt(20,SOL_SOCKET,SO_BINTIME,0x7fffffffe358,4) = 0 (0x0) 14511: fcntl(20,F_SETFL,O_RDONLY|O_NONBLOCK) = 0 (0x0) 14511: getpid() = 14511 (0x38af) 14511: sendto(3,"<102>Jun 14 18:48:40 ntpd[14511]"...,74,0,NULL,0) = 74 (0x4a) 14511: socket(PF_INET,SOCK_DGRAM,0) = 4 (0x4) 14511: fcntl(4,F_DUPFD,0x14) = 21 (0x15) 14511: close(4) = 0 (0x0) 14511: setsockopt(21,SOL_SOCKET,SO_REUSEADDR,0x7fffffffe354,4) = 0 (0x0) 14511: setsockopt(21,IPPROTO_IP,IP_TOS,0x6bfd64,4) = 0 (0x0) 14511: bind(21,{ AF_INET 0.0.0.0:123 },16) = 0 (0x0) 14511: setsockopt(21,SOL_SOCKET,SO_BINTIME,0x7fffffffe358,4) = 0 (0x0) 14511: fcntl(21,F_SETFL,O_RDONLY|O_NONBLOCK) = 0 (0x0) 14511: getpid() = 14511 (0x38af) 14511: sendto(3,"<102>Jun 14 18:48:40 ntpd[14511]"...,77,0,NULL,0) = 77 (0x4d) 14511: __sysctl(0x7fffffffdf50,0x6,0x0,0x7fffffffdf48,0x0,0x0) = 0 (0x0) 14511: __sysctl(0x7fffffffdf50,0x6,0x801a7d700,0x7fffffffdf48,0x0,0x0) = 0 (0x0) 14511: socket(PF_INET,SOCK_DGRAM|SOCK_CLOEXEC,0) = 4 (0x4) 14511: ioctl(4,SIOCGIFINDEX,0x7fffffffdf80) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: socket(PF_INET,SOCK_DGRAM,0) = 4 (0x4) 14511: fcntl(4,F_DUPFD,0x14) = 22 (0x16) 14511: close(4) = 0 (0x0) 14511: setsockopt(22,SOL_SOCKET,SO_REUSEADDR,0x7fffffffe018,4) = 0 (0x0) 14511: setsockopt(22,IPPROTO_IP,IP_TOS,0x6bfd64,4) = 0 (0x0) 14511: bind(22,{ AF_INET 10.60.0.245:123 },16) = 0 (0x0) 14511: setsockopt(22,SOL_SOCKET,SO_BINTIME,0x7fffffffe018,4) = 0 (0x0) 14511: fcntl(22,F_SETFL,O_RDONLY|O_NONBLOCK) = 0 (0x0) 14511: getpid() = 14511 (0x38af) 14511: sendto(3,"<102>Jun 14 18:48:40 ntpd[14511]"...,74,0,NULL,0) = 74 (0x4a) 14511: setsockopt(22,IPPROTO_IP,IP_MULTICAST_IF,0x801a32228,4) = 0 (0x0) 14511: socket(PF_INET,SOCK_DGRAM|SOCK_CLOEXEC,0) = 4 (0x4) 14511: ioctl(4,SIOCGIFINDEX,0x7fffffffdf80) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: socket(PF_INET6,SOCK_DGRAM,0) = 4 (0x4) 14511: ioctl(4,SIOCGIFAFLAG_IN6,0x7fffffffe220) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: socket(PF_INET6,SOCK_DGRAM,0) = 4 (0x4) 14511: ioctl(4,SIOCGIFAFLAG_IN6,0x7fffffffe220) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: socket(PF_INET6,SOCK_DGRAM,0) = 4 (0x4) 14511: fcntl(4,F_DUPFD,0x14) = 23 (0x17) 14511: close(4) = 0 (0x0) 14511: setsockopt(23,SOL_SOCKET,SO_REUSEADDR,0x7fffffffe018,4) = 0 (0x0) 14511: setsockopt(23,IPPROTO_IPV6,IPV6_TCLASS,0x6bfd64,4) = 0 (0x0) 14511: setsockopt(23,IPPROTO_IPV6,IPV6_V6ONLY,0x7fffffffe018,4) = 0 (0x0) 14511: setsockopt(23,IPPROTO_IPV6,IPV6_V6ONLY,0x7fffffffe018,4) = 0 (0x0) 14511: bind(23,{ AF_INET6 [::1]:123 },28) = 0 (0x0) 14511: setsockopt(23,SOL_SOCKET,SO_BINTIME,0x7fffffffe018,4) = 0 (0x0) 14511: fcntl(23,F_SETFL,O_RDONLY|O_NONBLOCK) = 0 (0x0) 14511: getpid() = 14511 (0x38af) 14511: sendto(3,"<102>Jun 14 18:48:40 ntpd[14511]"...,68,0,NULL,0) = 68 (0x44) 14511: socket(PF_INET,SOCK_DGRAM|SOCK_CLOEXEC,0) = 4 (0x4) 14511: ioctl(4,SIOCGIFINDEX,0x7fffffffdf80) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: socket(PF_INET6,SOCK_DGRAM,0) = 4 (0x4) 14511: ioctl(4,SIOCGIFAFLAG_IN6,0x7fffffffe220) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: socket(PF_INET6,SOCK_DGRAM,0) = 4 (0x4) 14511: ioctl(4,SIOCGIFAFLAG_IN6,0x7fffffffe220) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: socket(PF_INET6,SOCK_DGRAM,0) = 4 (0x4) 14511: fcntl(4,F_DUPFD,0x14) = 24 (0x18) 14511: close(4) = 0 (0x0) 14511: setsockopt(24,SOL_SOCKET,SO_REUSEADDR,0x7fffffffe018,4) = 0 (0x0) 14511: setsockopt(24,IPPROTO_IPV6,IPV6_TCLASS,0x6bfd64,4) = 0 (0x0) 14511: setsockopt(24,IPPROTO_IPV6,IPV6_V6ONLY,0x7fffffffe018,4) = 0 (0x0) 14511: setsockopt(24,IPPROTO_IPV6,IPV6_V6ONLY,0x7fffffffe018,4) = 0 (0x0) 14511: bind(24,{ AF_INET6 [fe80::1]:123 },28) = 0 (0x0) 14511: setsockopt(24,SOL_SOCKET,SO_BINTIME,0x7fffffffe018,4) = 0 (0x0) 14511: fcntl(24,F_SETFL,O_RDONLY|O_NONBLOCK) = 0 (0x0) 14511: getpid() = 14511 (0x38af) 14511: sendto(3,"<102>Jun 14 18:48:40 ntpd[14511]"...,74,0,NULL,0) = 74 (0x4a) 14511: setsockopt(24,IPPROTO_IPV6,IPV6_MULTICAST_IF,0x801a324d0,4) = 0 (0x0) 14511: socket(PF_INET,SOCK_DGRAM|SOCK_CLOEXEC,0) = 4 (0x4) 14511: ioctl(4,SIOCGIFINDEX,0x7fffffffdf80) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: socket(PF_INET,SOCK_DGRAM,0) = 4 (0x4) 14511: fcntl(4,F_DUPFD,0x14) = 25 (0x19) 14511: close(4) = 0 (0x0) 14511: setsockopt(25,SOL_SOCKET,SO_REUSEADDR,0x7fffffffe018,4) = 0 (0x0) 14511: setsockopt(25,IPPROTO_IP,IP_TOS,0x6bfd64,4) = 0 (0x0) 14511: bind(25,{ AF_INET 127.0.0.1:123 },16) = 0 (0x0) 14511: setsockopt(25,SOL_SOCKET,SO_BINTIME,0x7fffffffe018,4) = 0 (0x0) 14511: fcntl(25,F_SETFL,O_RDONLY|O_NONBLOCK) = 0 (0x0) 14511: getpid() = 14511 (0x38af) 14511: sendto(3,"<102>Jun 14 18:48:40 ntpd[14511]"...,72,0,NULL,0) = 72 (0x48) 14511: setsockopt(22,SOL_SOCKET,SO_REUSEADDR,0x7fffffffe3a0,4) = 0 (0x0) 14511: setsockopt(23,SOL_SOCKET,SO_REUSEADDR,0x7fffffffe3a0,4) = 0 (0x0) 14511: setsockopt(24,SOL_SOCKET,SO_REUSEADDR,0x7fffffffe3a0,4) = 0 (0x0) 14511: setsockopt(25,SOL_SOCKET,SO_REUSEADDR,0x7fffffffe3a0,4) = 0 (0x0) 14511: socket(PF_ROUTE,SOCK_RAW,0) = 4 (0x4) 14511: fcntl(4,F_DUPFD,0x14) = 26 (0x1a) 14511: close(4) = 0 (0x0) 14511: fcntl(26,F_SETFL,O_RDONLY|O_NONBLOCK) = 0 (0x0) 14511: getpid() = 14511 (0x38af) 14511: sendto(3,"<102>Jun 14 18:48:40 ntpd[14511]"...,93,0,NULL,0) = 93 (0x5d) 14511: socket(PF_UNSPEC,SOCK_DGRAM,0) ERR#47 'Address family not supported by protocol family' 14511: mlockall(MCL_CURRENT|MCL_FUTURE) = 0 (0x0) 14511: sigprocmask(SIG_SETMASK,{ SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0) 14511: sigaction(SIGSYS,{ 0x80107afe0 SA_SIGINFO ss_t },{ SIG_DFL 0x0 ss_t }) = 0 (0x0) 14511: sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0) 14511: sigprocmask(SIG_BLOCK,0x0,{ }) = 0 (0x0) 14511: ntp_adjtime(0x6c7c98) = 0 (0x0) 14511: sigprocmask(SIG_SETMASK,{ SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0) 14511: sigaction(SIGSYS,{ SIG_DFL 0x0 ss_t },{ 0x80107afe0 SA_SIGINFO ss_t }) = 0 (0x0) 14511: sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0) 14511: ntp_adjtime(0x6c7c98) = 0 (0x0) 14511: select(27,{ 20 21 22 23 24 25 26 },0x0,0x0,0x0) = 1 (0x1) 14511: read(26,"\^X\0\^E\^R\^C\0wlan0\0\0\0\0\0"...,5120) = 24 (0x18) 14511: select(27,{ 20 21 22 23 24 25 26 },0x0,0x0,0x0) ERR#4 'Interrupted system call' 14511: SIGNAL 14 (SIGALRM) 14511: sigprocmask(SIG_SETMASK,{ SIGALRM },0x0) = 0 (0x0) 14511: sigreturn(0x7fffffffd4c0) ERR#4 'Interrupted system call' 14511: socketpair(0x1,0x1,0x0,0x7fffffffdae8) = 0 (0x0) 14511: fcntl(4,F_DUPFD,0x14) = 27 (0x1b) 14511: close(4) = 0 (0x0) 14511: fcntl(5,F_DUPFD,0x14) = 28 (0x1c) 14511: close(5) = 0 (0x0) 14511: fcntl(27,F_GETFL,) = 2 (0x2) 14511: fcntl(27,F_SETFL,O_RDWR|O_NONBLOCK) = 0 (0x0) 14511: sigprocmask(SIG_BLOCK,{ SIGHUP|SIGINT|SIGQUIT|SIGBUS|SIGALRM|SIGTERM|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0) 14511: mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34367102976 (0x800706000) 14511: mmap(0x7fffdffbd000,266240,PROT_READ|PROT_WRITE,MAP_STACK,-1,0x0) = 140736951209984 (0x7fffdffbd000) 14511: mprotect(0x7fffdffbd000,4096,PROT_NONE) = 0 (0x0) 14511: thr_new(0x7fffffffda28,0x68) = 0 (0x0) 14511: 14511: sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0) 14511: _umtx_op(0x801aa909c,UMTX_OP_SEM2_WAIT,0x0,0x0,0x0) = 0 (0x0) 14511: __sysctl(0x7fffffffe150,0x6,0x0,0x7fffffffe148,0x0,0x0) = 0 (0x0) 14511: __sysctl(0x7fffffffe150,0x6,0x801a7d700,0x7fffffffe148,0x0,0x0) = 0 (0x0) 14511: socket(PF_INET,SOCK_DGRAM|SOCK_CLOEXEC,0) = 4 (0x4) 14511: mmap(0x0,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34389098496 (0x801c00000) 14511: ioctl(4,SIOCGIFINDEX,0x7fffffffe180) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: socket(PF_INET,SOCK_DGRAM|SOCK_CLOEXEC,0) = 4 (0x4) 14511: ioctl(4,SIOCGIFINDEX,0x7fffffffe180) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: socket(PF_INET6,SOCK_DGRAM,0) = 4 (0x4) 14511: ioctl(4,SIOCGIFAFLAG_IN6,0x7fffffffe420) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: socket(PF_INET6,SOCK_DGRAM,0) = 4 (0x4) 14511: ioctl(4,SIOCGIFAFLAG_IN6,0x7fffffffe420) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: socket(PF_INET,SOCK_DGRAM|SOCK_CLOEXEC,0) = 4 (0x4) 14511: mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34367107072 (0x800707000) 14511: ioctl(4,SIOCGIFINDEX,0x7fffffffe180) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: socket(PF_INET6,SOCK_DGRAM,0) = 4 (0x4) 14511: ioctl(4,SIOCGIFAFLAG_IN6,0x7fffffffe420) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: socket(PF_INET6,SOCK_DGRAM,0) = 4 (0x4) 14511: ioctl(4,SIOCGIFAFLAG_IN6,0x7fffffffe420) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: socket(PF_INET,SOCK_DGRAM|SOCK_CLOEXEC,0) = 4 (0x4) 14511: ioctl(4,SIOCGIFINDEX,0x7fffffffe180) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: fstatat(AT_FDCWD,"/etc/nsswitch.conf",{ mode=-rw-r--r-- ,inode=722492,size=331,blksize=32768 },0x0) = 0 (0x0) 14511: socket(PF_UNSPEC,SOCK_DGRAM,0) ERR#47 'Address family not supported by protocol family' 14511: open("/etc/services",O_RDONLY|O_CLOEXEC,0666) = 4 (0x4) 14511: fstat(4,{ mode=-rw-r--r-- ,inode=723103,size=86292,blksize=32768 }) = 0 (0x0) 14511: lseek(4,0x0,SEEK_CUR) = 0 (0x0) 14511: lseek(4,0x0,SEEK_SET) = 0 (0x0) 14511: read(4,"#\n# Network services, Internet "...,32768) = 32768 (0x8000) 14511: close(4) = 0 (0x0) 14511: fstatat(AT_FDCWD,"/etc/nsswitch.conf",{ mode=-rw-r--r-- ,inode=722492,size=331,blksize=32768 },0x0) = 0 (0x0) 14511: open("/etc/hosts",O_RDONLY|O_CLOEXEC,0666) = 4 (0x4) 14511: fstat(4,{ mode=-rw-r--r-- ,inode=722313,size=1454,blksize=32768 }) = 0 (0x0) 14511: read(4,"# $FreeBSD: head/etc/hosts 10999"...,32768) = 1454 (0x5ae) 14511: read(4,0x801c1fd40,32768) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: getpid() = 14511 (0x38af) 14511: issetugid() = 0 (0x0) 14511: open("/etc/resolv.conf",O_RDONLY|O_CLOEXEC,0666) = 4 (0x4) 14511: fstat(4,{ mode=-rw-r--r-- ,inode=722327,size=35,blksize=32768 }) = 0 (0x0) 14511: fstat(4,{ mode=-rw-r--r-- ,inode=722327,size=35,blksize=32768 }) = 0 (0x0) 14511: read(4,"nameserver 127.0.0.1\noptions ed"...,32768) = 35 (0x23) 14511: read(4,0x801c1fd40,32768) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: __sysctl(0x7fffdfffcbd0,0x2,0x7fffdfffcee0,0x7fffdfffcbc8,0x0,0x0) = 0 (0x0) 14511: issetugid() = 0 (0x0) 14511: socket(PF_INET,SOCK_DGRAM|SOCK_CLOEXEC,0) = 4 (0x4) 14511: connect(4,{ AF_INET 127.0.0.1:53 },16) = 0 (0x0) 14511: sendto(4,"\M-#\M-z\^A\0\0\^A\0\0\0\0\0\^A"...,51,0,NULL,0) = 51 (0x33) 14511: poll({ 4/POLLRDNORM },1,5000) = 1 (0x1) 14511: recvfrom(4,"\M-#\M-z\M^A\M^@\0\^A\0\^D\0\0\0"...,65536,0,{ AF_INET 127.0.0.1:53 },0x7fffdfffc808) = 115 (0x73) 14511: close(4) = 0 (0x0) 14511: socket(PF_INET,SOCK_DGRAM|SOCK_CLOEXEC,0) = 4 (0x4) 14511: connect(4,{ AF_INET 127.0.0.1:53 },16) = 0 (0x0) 14511: sendto(4,"\^Y|\^A\0\0\^A\0\0\0\0\0\^A\^A0"...,51,0,NULL,0) = 51 (0x33) 14511: poll({ 4/POLLRDNORM },1,5000) = 1 (0x1) 14511: recvfrom(4,"\^Y|\M^A\M^@\0\^A\0\0\0\^A\0\^A"...,65536,0,{ AF_INET 127.0.0.1:53 },0x7fffdfffc808) = 106 (0x6a) 14511: close(4) = 0 (0x0) 14511: fstatat(AT_FDCWD,"/etc/nsswitch.conf",{ mode=-rw-r--r-- ,inode=722492,size=331,blksize=32768 },0x0) = 0 (0x0) 14511: open("/etc/services",O_RDONLY|O_CLOEXEC,0666) = 4 (0x4) 14511: fstat(4,{ mode=-rw-r--r-- ,inode=723103,size=86292,blksize=32768 }) = 0 (0x0) 14511: lseek(4,0x0,SEEK_CUR) = 0 (0x0) 14511: lseek(4,0x0,SEEK_SET) = 0 (0x0) 14511: read(4,"#\n# Network services, Internet "...,32768) = 32768 (0x8000) 14511: close(4) = 0 (0x0) 14511: fstatat(AT_FDCWD,"/etc/nsswitch.conf",{ mode=-rw-r--r-- ,inode=722492,size=331,blksize=32768 },0x0) = 0 (0x0) 14511: open("/etc/services",O_RDONLY|O_CLOEXEC,0666) = 4 (0x4) 14511: fstat(4,{ mode=-rw-r--r-- ,inode=723103,size=86292,blksize=32768 }) = 0 (0x0) 14511: lseek(4,0x0,SEEK_CUR) = 0 (0x0) 14511: lseek(4,0x0,SEEK_SET) = 0 (0x0) 14511: read(4,"#\n# Network services, Internet "...,32768) = 32768 (0x8000) 14511: close(4) = 0 (0x0) 14511: fstatat(AT_FDCWD,"/etc/nsswitch.conf",{ mode=-rw-r--r-- ,inode=722492,size=331,blksize=32768 },0x0) = 0 (0x0) 14511: open("/etc/services",O_RDONLY|O_CLOEXEC,0666) = 4 (0x4) 14511: fstat(4,{ mode=-rw-r--r-- ,inode=723103,size=86292,blksize=32768 }) = 0 (0x0) 14511: lseek(4,0x0,SEEK_CUR) = 0 (0x0) 14511: lseek(4,0x0,SEEK_SET) = 0 (0x0) 14511: read(4,"#\n# Network services, Internet "...,32768) = 32768 (0x8000) 14511: close(4) = 0 (0x0) 14511: fstatat(AT_FDCWD,"/etc/nsswitch.conf",{ mode=-rw-r--r-- ,inode=722492,size=331,blksize=32768 },0x0) = 0 (0x0) 14511: open("/etc/services",O_RDONLY|O_CLOEXEC,0666) = 4 (0x4) 14511: fstat(4,{ mode=-rw-r--r-- ,inode=723103,size=86292,blksize=32768 }) = 0 (0x0) 14511: lseek(4,0x0,SEEK_CUR) = 0 (0x0) 14511: lseek(4,0x0,SEEK_SET) = 0 (0x0) 14511: read(4,"#\n# Network services, Internet "...,32768) = 32768 (0x8000) 14511: close(4) = 0 (0x0) 14511: fstatat(AT_FDCWD,"/etc/nsswitch.conf",{ mode=-rw-r--r-- ,inode=722492,size=331,blksize=32768 },0x0) = 0 (0x0) 14511: open("/etc/services",O_RDONLY|O_CLOEXEC,0666) = 4 (0x4) 14511: fstat(4,{ mode=-rw-r--r-- ,inode=723103,size=86292,blksize=32768 }) = 0 (0x0) 14511: lseek(4,0x0,SEEK_CUR) = 0 (0x0) 14511: lseek(4,0x0,SEEK_SET) = 0 (0x0) 14511: read(4,"#\n# Network services, Internet "...,32768) = 32768 (0x8000) 14511: close(4) = 0 (0x0) 14511: fstatat(AT_FDCWD,"/etc/nsswitch.conf",{ mode=-rw-r--r-- ,inode=722492,size=331,blksize=32768 },0x0) = 0 (0x0) 14511: open("/etc/services",O_RDONLY|O_CLOEXEC,0666) = 4 (0x4) 14511: fstat(4,{ mode=-rw-r--r-- ,inode=723103,size=86292,blksize=32768 }) = 0 (0x0) 14511: lseek(4,0x0,SEEK_CUR) = 0 (0x0) 14511: lseek(4,0x0,SEEK_SET) = 0 (0x0) 14511: read(4,"#\n# Network services, Internet "...,32768) = 32768 (0x8000) 14511: close(4) = 0 (0x0) 14511: __sysctl(0x7fffdfffdd20,0x4,0x0,0x7fffdfffde40,0x0,0x0) = 0 (0x0) 14511: __sysctl(0x7fffdfffdd20,0x4,0x801c50300,0x7fffdfffde40,0x0,0x0) = 0 (0x0) 14511: socket(PF_INET,SOCK_DGRAM|SOCK_CLOEXEC,IPPROTO_UDP) = 4 (0x4) 14511: connect(4,{ AF_INET 85.21.78.91:1 },16) = 0 (0x0) 14511: getsockname(4,{ AF_INET 10.60.0.245:50809 },0x7fffdfffdcbc) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: socket(PF_INET,SOCK_DGRAM|SOCK_CLOEXEC,IPPROTO_UDP) = 4 (0x4) 14511: connect(4,{ AF_INET 85.21.78.8:1 },16) = 0 (0x0) 14511: getsockname(4,{ AF_INET 10.60.0.245:56925 },0x7fffdfffdcbc) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: socket(PF_INET,SOCK_DGRAM|SOCK_CLOEXEC,IPPROTO_UDP) = 4 (0x4) 14511: connect(4,{ AF_INET 91.207.136.50:1 },16) = 0 (0x0) 14511: getsockname(4,{ AF_INET 10.60.0.245:38693 },0x7fffdfffdcbc) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: socket(PF_INET,SOCK_DGRAM|SOCK_CLOEXEC,IPPROTO_UDP) = 4 (0x4) 14511: connect(4,{ AF_INET 185.22.60.71:1 },16) = 0 (0x0) 14511: getsockname(4,{ AF_INET 10.60.0.245:44303 },0x7fffdfffdcbc) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: write(28,"\0",1) = 1 (0x1) 14511: select(28,{ 20 21 22 23 24 25 26 27 },0x0,0x0,0x0) = 1 (0x1) 14511: read(27,"\0",32) = 1 (0x1) 14511: socket(PF_INET,SOCK_DGRAM,0) = 4 (0x4) 14511: connect(4,{ AF_INET 85.21.78.91:123 },16) = 0 (0x0) 14511: getsockname(4,{ AF_INET 10.60.0.245:12832 },0x7fffffffdc1c) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: sendto(22,"\M-c\0\^F\M-h\0\0\0\0\0\0\0\0INI"...,48,0,{ AF_INET 85.21.78.91:123 },16) = 48 (0x30) 14511: getpid() = 14511 (0x38af) 14511: sendto(3,"<102>Jun 14 18:48:41 ntpd[14511]"...,68,0,NULL,0) = 68 (0x44) 14511: read(27,0x7fffffffe5d0,32) ERR#35 'Resource temporarily unavailable' 14511: select(28,{ 20 21 22 23 24 25 26 27 },0x0,0x0,0x0) = 1 (0x1) 14511: recvmsg(22,0x7fffffffe5f0,0) = 48 (0x30) 14511: recvmsg(22,0x7fffffffe5f0,0) ERR#35 'Resource temporarily unavailable' 14511: select(28,{ 20 21 22 23 24 25 26 27 },0x0,0x0,0x0) ERR#4 'Interrupted system call' 14511: SIGNAL 14 (SIGALRM) 14511: sigprocmask(SIG_SETMASK,{ SIGALRM },0x0) = 0 (0x0) 14511: sigreturn(0x7fffffffd4c0) ERR#4 'Interrupted system call' 14511: socket(PF_INET,SOCK_DGRAM,0) = 4 (0x4) 14511: connect(4,{ AF_INET 85.21.78.8:123 },16) = 0 (0x0) 14511: getsockname(4,{ AF_INET 10.60.0.245:33043 },0x7fffffffdbfc) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: sendto(22,"\M-c\0\^F\M-h\0\0\0\0\0\0\0\^AIN"...,48,0,{ AF_INET 85.21.78.8:123 },16) = 48 (0x30) 14511: getpid() = 14511 (0x38af) 14511: sendto(3,"<102>Jun 14 18:48:42 ntpd[14511]"...,67,0,NULL,0) = 67 (0x43) 14511: select(28,{ 20 21 22 23 24 25 26 27 },0x0,0x0,0x0) = 1 (0x1) 14511: recvmsg(22,0x7fffffffe5f0,0) = 48 (0x30) 14511: recvmsg(22,0x7fffffffe5f0,0) ERR#35 'Resource temporarily unavailable' 14511: select(28,{ 20 21 22 23 24 25 26 27 },0x0,0x0,0x0) ERR#4 'Interrupted system call' 14511: SIGNAL 14 (SIGALRM) 14511: sigprocmask(SIG_SETMASK,{ SIGALRM },0x0) = 0 (0x0) 14511: sigreturn(0x7fffffffd4c0) ERR#4 'Interrupted system call' 14511: socket(PF_INET,SOCK_DGRAM,0) = 4 (0x4) 14511: connect(4,{ AF_INET 91.207.136.50:123 },16) = 0 (0x0) 14511: getsockname(4,{ AF_INET 10.60.0.245:11423 },0x7fffffffdbfc) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: sendto(22,"\M-c\0\^F\M-h\0\0\0\0\0\0\0\^BIN"...,48,0,{ AF_INET 91.207.136.50:123 },16) = 48 (0x30) 14511: getpid() = 14511 (0x38af) 14511: sendto(3,"<102>Jun 14 18:48:43 ntpd[14511]"...,70,0,NULL,0) = 70 (0x46) 14511: select(28,{ 20 21 22 23 24 25 26 27 },0x0,0x0,0x0) = 1 (0x1) 14511: recvmsg(22,0x7fffffffe5f0,0) = 48 (0x30) 14511: recvmsg(22,0x7fffffffe5f0,0) ERR#35 'Resource temporarily unavailable' 14511: select(28,{ 20 21 22 23 24 25 26 27 },0x0,0x0,0x0) ERR#4 'Interrupted system call' 14511: SIGNAL 14 (SIGALRM) 14511: sigprocmask(SIG_SETMASK,{ SIGALRM },0x0) = 0 (0x0) 14511: sigreturn(0x7fffffffd4c0) ERR#4 'Interrupted system call' 14511: socket(PF_INET,SOCK_DGRAM,0) = 4 (0x4) 14511: connect(4,{ AF_INET 185.22.60.71:123 },16) = 0 (0x0) 14511: getsockname(4,{ AF_INET 10.60.0.245:56727 },0x7fffffffdbfc) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: sendto(22,"\M-c\0\^F\M-h\0\0\0\0\0\0\0\^CIN"...,48,0,{ AF_INET 185.22.60.71:123 },16) = 48 (0x30) 14511: getpid() = 14511 (0x38af) 14511: sendto(3,"<102>Jun 14 18:48:44 ntpd[14511]"...,69,0,NULL,0) = 69 (0x45) 14511: select(28,{ 20 21 22 23 24 25 26 27 },0x0,0x0,0x0) = 1 (0x1) 14511: recvmsg(22,0x7fffffffe5f0,0) = 48 (0x30) 14511: recvmsg(22,0x7fffffffe5f0,0) ERR#35 'Resource temporarily unavailable' 14511: select(28,{ 20 21 22 23 24 25 26 27 },0x0,0x0,0x0) ERR#4 'Interrupted system call' 14511: SIGNAL 14 (SIGALRM) 14511: sigprocmask(SIG_SETMASK,{ SIGALRM },0x0) = 0 (0x0) 14511: sigreturn(0x7fffffffd4c0) ERR#4 'Interrupted system call' 14511: socket(PF_UNSPEC,SOCK_DGRAM,0) ERR#47 'Address family not supported by protocol family' 14511: sendto(22,"\M-c\0\^F\M-h\0\0\0\0\0\0\0\^DIN"...,48,0,{ AF_INET 185.22.60.71:123 },16) = 48 (0x30) 14511: socket(PF_UNSPEC,SOCK_DGRAM,0) ERR#47 'Address family not supported by protocol family' 14511: sendto(22,"\M-c\0\^F\M-h\0\0\0\0\0\0\0\^DIN"...,48,0,{ AF_INET 85.21.78.8:123 },16) = 48 (0x30) 14511: _umtx_op(0x801aa909c,UMTX_OP_SEM2_WAKE,0x0,0x0,0x0) = 0 (0x0) 14511: _umtx_op(0x801aa909c,UMTX_OP_SEM2_WAIT,0x0,0x0,0x0) = 0 (0x0) 14511: fstatat(AT_FDCWD,"/etc/nsswitch.conf",{ mode=-rw-r--r-- ,inode=722492,size=331,blksize=32768 },0x0) = 0 (0x0) 14511: open("/etc/services",O_RDONLY|O_CLOEXEC,0666) = 4 (0x4) 14511: fstat(4,{ mode=-rw-r--r-- ,inode=723103,size=86292,blksize=32768 }) = 0 (0x0) 14511: lseek(4,0x0,SEEK_CUR) = 0 (0x0) 14511: lseek(4,0x0,SEEK_SET) = 0 (0x0) 14511: read(4,"#\n# Network services, Internet "...,32768) = 32768 (0x8000) 14511: close(4) = 0 (0x0) 14511: fstatat(AT_FDCWD,"/etc/nsswitch.conf",{ mode=-rw-r--r-- ,inode=722492,size=331,blksize=32768 },0x0) = 0 (0x0) 14511: open("/etc/hosts",O_RDONLY|O_CLOEXEC,0666) = 4 (0x4) 14511: fstat(4,{ mode=-rw-r--r-- ,inode=722313,size=1454,blksize=32768 }) = 0 (0x0) 14511: read(4,"# $FreeBSD: head/etc/hosts 10999"...,32768) = 1454 (0x5ae) 14511: read(4,0x801c1fd40,32768) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: fstatat(AT_FDCWD,"/etc/resolv.conf",{ mode=-rw-r--r-- ,inode=722327,size=35,blksize=32768 },0x0) = 0 (0x0) 14511: socket(PF_INET,SOCK_DGRAM|SOCK_CLOEXEC,0) = 4 (0x4) 14511: connect(4,{ AF_INET 127.0.0.1:53 },16) = 0 (0x0) 14511: sendto(4,"b:\^A\0\0\^A\0\0\0\0\0\^A\^A0\af"...,51,0,NULL,0) = 51 (0x33) 14511: poll({ 4/POLLRDNORM },1,5000) = 1 (0x1) 14511: recvfrom(4,"b:\M^A\M^@\0\^A\0\^D\0\0\0\^A\^A"...,65536,0,{ AF_INET 127.0.0.1:53 },0x7fffdfffc808) = 115 (0x73) 14511: close(4) = 0 (0x0) 14511: socket(PF_INET,SOCK_DGRAM|SOCK_CLOEXEC,0) = 4 (0x4) 14511: connect(4,{ AF_INET 127.0.0.1:53 },16) = 0 (0x0) 14511: sendto(4,"\M-I\r\^A\0\0\^A\0\0\0\0\0\^A\^A"...,51,0,NULL,0) = 51 (0x33) 14511: poll({ 4/POLLRDNORM },1,5000) = 1 (0x1) 14511: recvfrom(4,"\M-I\r\M^A\M^@\0\^A\0\0\0\^A\0"...,65536,0,{ AF_INET 127.0.0.1:53 },0x7fffdfffc808) = 106 (0x6a) 14511: close(4) = 0 (0x0) 14511: fstatat(AT_FDCWD,"/etc/nsswitch.conf",{ mode=-rw-r--r-- ,inode=722492,size=331,blksize=32768 },0x0) = 0 (0x0) 14511: open("/etc/services",O_RDONLY|O_CLOEXEC,0666) = 4 (0x4) 14511: fstat(4,{ mode=-rw-r--r-- ,inode=723103,size=86292,blksize=32768 }) = 0 (0x0) 14511: lseek(4,0x0,SEEK_CUR) = 0 (0x0) 14511: lseek(4,0x0,SEEK_SET) = 0 (0x0) 14511: read(4,"#\n# Network services, Internet "...,32768) = 32768 (0x8000) 14511: close(4) = 0 (0x0) 14511: fstatat(AT_FDCWD,"/etc/nsswitch.conf",{ mode=-rw-r--r-- ,inode=722492,size=331,blksize=32768 },0x0) = 0 (0x0) 14511: open("/etc/services",O_RDONLY|O_CLOEXEC,0666) = 4 (0x4) 14511: fstat(4,{ mode=-rw-r--r-- ,inode=723103,size=86292,blksize=32768 }) = 0 (0x0) 14511: lseek(4,0x0,SEEK_CUR) = 0 (0x0) 14511: lseek(4,0x0,SEEK_SET) = 0 (0x0) 14511: read(4,"#\n# Network services, Internet "...,32768) = 32768 (0x8000) 14511: select(28,{ 20 21 22 23 24 25 26 27 },0x0,0x0,0x0) = 1 (0x1) 14511: recvmsg(22,0x7fffffffe5f0,0) = 48 (0x30) 14511: recvmsg(22,0x7fffffffe5f0,0) ERR#35 'Resource temporarily unavailable' 14511: socket(PF_UNSPEC,SOCK_DGRAM,0) ERR#47 'Address family not supported by protocol family' 14511: close(4) = 0 (0x0) 14511: fstatat(AT_FDCWD,"/etc/nsswitch.conf",{ mode=-rw-r--r-- ,inode=722492,size=331,blksize=32768 },0x0) = 0 (0x0) 14511: select(28,{ 20 21 22 23 24 25 26 27 },0x0,0x0,0x0) = 1 (0x1) 14511: open("/etc/services",O_RDONLY|O_CLOEXEC,0666) = 4 (0x4) 14511: recvmsg(22,0x7fffffffe5f0,0) = 48 (0x30) 14511: fstat(4,{ mode=-rw-r--r-- ,inode=723103,size=86292,blksize=32768 }) = 0 (0x0) 14511: recvmsg(22,0x7fffffffe5f0,0) ERR#35 'Resource temporarily unavailable' 14511: lseek(4,0x0,SEEK_CUR) = 0 (0x0) 14511: lseek(4,0x0,SEEK_SET) = 0 (0x0) 14511: read(4,"#\n# Network services, Internet "...,32768) = 32768 (0x8000) 14511: socket(PF_UNSPEC,SOCK_DGRAM,0) ERR#47 'Address family not supported by protocol family' 14511: close(4) = 0 (0x0) 14511: fstatat(AT_FDCWD,"/etc/nsswitch.conf",{ mode=-rw-r--r-- ,inode=722492,size=331,blksize=32768 },0x0) = 0 (0x0) 14511: open("/etc/services",O_RDONLY|O_CLOEXEC,0666) = 4 (0x4) 14511: fstat(4,{ mode=-rw-r--r-- ,inode=723103,size=86292,blksize=32768 }) = 0 (0x0) 14511: lseek(4,0x0,SEEK_CUR) = 0 (0x0) 14511: lseek(4,0x0,SEEK_SET) = 0 (0x0) 14511: read(4,"#\n# Network services, Internet "...,32768) = 32768 (0x8000) 14511: close(4) = 0 (0x0) 14511: fstatat(AT_FDCWD,"/etc/nsswitch.conf",{ mode=-rw-r--r-- ,inode=722492,size=331,blksize=32768 },0x0) = 0 (0x0) 14511: open("/etc/services",O_RDONLY|O_CLOEXEC,0666) = 4 (0x4) 14511: fstat(4,{ mode=-rw-r--r-- ,inode=723103,size=86292,blksize=32768 }) = 0 (0x0) 14511: lseek(4,0x0,SEEK_CUR) = 0 (0x0) 14511: lseek(4,0x0,SEEK_SET) = 0 (0x0) 14511: read(4,"#\n# Network services, Internet "...,32768) = 32768 (0x8000) 14511: close(4) = 0 (0x0) 14511: fstatat(AT_FDCWD,"/etc/nsswitch.conf",{ mode=-rw-r--r-- ,inode=722492,size=331,blksize=32768 },0x0) = 0 (0x0) 14511: open("/etc/services",O_RDONLY|O_CLOEXEC,0666) = 4 (0x4) 14511: fstat(4,{ mode=-rw-r--r-- ,inode=723103,size=86292,blksize=32768 }) = 0 (0x0) 14511: lseek(4,0x0,SEEK_CUR) = 0 (0x0) 14511: lseek(4,0x0,SEEK_SET) = 0 (0x0) 14511: read(4,"#\n# Network services, Internet "...,32768) = 32768 (0x8000) 14511: close(4) = 0 (0x0) 14511: __sysctl(0x7fffdfffdd20,0x4,0x0,0x7fffdfffde40,0x0,0x0) = 0 (0x0) 14511: __sysctl(0x7fffdfffdd20,0x4,0x801c50300,0x7fffdfffde40,0x0,0x0) = 0 (0x0) 14511: socket(PF_INET,SOCK_DGRAM|SOCK_CLOEXEC,IPPROTO_UDP) = 4 (0x4) 14511: connect(4,{ AF_INET 85.21.78.91:1 },16) = 0 (0x0) 14511: getsockname(4,{ AF_INET 10.60.0.245:34985 },0x7fffdfffdcbc) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: socket(PF_INET,SOCK_DGRAM|SOCK_CLOEXEC,IPPROTO_UDP) = 4 (0x4) 14511: connect(4,{ AF_INET 85.21.78.8:1 },16) = 0 (0x0) 14511: getsockname(4,{ AF_INET 10.60.0.245:13180 },0x7fffdfffdcbc) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: socket(PF_INET,SOCK_DGRAM|SOCK_CLOEXEC,IPPROTO_UDP) = 4 (0x4) 14511: connect(4,{ AF_INET 91.207.136.50:1 },16) = 0 (0x0) 14511: getsockname(4,{ AF_INET 10.60.0.245:10681 },0x7fffdfffdcbc) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: socket(PF_INET,SOCK_DGRAM|SOCK_CLOEXEC,IPPROTO_UDP) = 4 (0x4) 14511: connect(4,{ AF_INET 185.22.60.71:1 },16) = 0 (0x0) 14511: getsockname(4,{ AF_INET 10.60.0.245:41761 },0x7fffdfffdcbc) = 0 (0x0) 14511: close(4) = 0 (0x0) 14511: write(28,"\0",1) = 1 (0x1) 14511: select(28,{ 20 21 22 23 24 25 26 27 },0x0,0x0,0x0) = 1 (0x1) 14511: read(27,"\0",32) = 1 (0x1) 14511: read(27,0x7fffffffe5d0,32) ERR#35 'Resource temporarily unavailable' 14511: select(28,{ 20 21 22 23 24 25 26 27 },0x0,0x0,0x0) ERR#4 'Interrupted system call' 14511: SIGNAL 14 (SIGALRM) 14511: sigprocmask(SIG_SETMASK,{ SIGALRM },0x0) = 0 (0x0) 14511: sigreturn(0x7fffffffd4c0) ERR#4 'Interrupted system call' 14511: socket(PF_UNSPEC,SOCK_DGRAM,0) ERR#47 'Address family not supported by protocol family' 14511: sendto(22,"\M-c\0\^F\M-h\0\0\0\0\0\0\0\^EIN"...,48,0,{ AF_INET 85.21.78.91:123 },16) = 48 (0x30) 14511: select(28,{ 20 21 22 23 24 25 26 27 },0x0,0x0,0x0) = 1 (0x1) 14511: recvmsg(22,0x7fffffffe5f0,0) = 48 (0x30) 14511: recvmsg(22,0x7fffffffe5f0,0) ERR#35 'Resource temporarily unavailable' 14511: socket(PF_UNSPEC,SOCK_DGRAM,0) ERR#47 'Address family not supported by protocol family' 14511: select(28,{ 20 21 22 23 24 25 26 27 },0x0,0x0,0x0) ERR#4 'Interrupted system call' 14511: SIGNAL 14 (SIGALRM) 14511: sigprocmask(SIG_SETMASK,{ SIGALRM },0x0) = 0 (0x0) 14511: sigreturn(0x7fffffffd4c0) ERR#4 'Interrupted system call' 14511: sendto(22,"\M-c\0\^F\M-h\0\0\0\0\0\0\0\^FIN"...,48,0,{ AF_INET 185.22.60.71:123 },16) = 48 (0x30) 14511: sendto(22,"\M-c\0\^F\M-h\0\0\0\0\0\0\0\^FIN"...,48,0,{ AF_INET 85.21.78.8:123 },16) = 48 (0x30) 14511: select(28,{ 20 21 22 23 24 25 26 27 },0x0,0x0,0x0) = 1 (0x1) 14511: recvmsg(22,0x7fffffffe5f0,0) = 48 (0x30) 14511: recvmsg(22,0x7fffffffe5f0,0) ERR#35 'Resource temporarily unavailable' 14511: socket(PF_UNSPEC,SOCK_DGRAM,0) ERR#47 'Address family not supported by protocol family' 14511: select(28,{ 20 21 22 23 24 25 26 27 },0x0,0x0,0x0) = 1 (0x1) 14511: recvmsg(22,0x7fffffffe5f0,0) = 48 (0x30) 14511: recvmsg(22,0x7fffffffe5f0,0) ERR#35 'Resource temporarily unavailable' 14511: socket(PF_UNSPEC,SOCK_DGRAM,0) ERR#47 'Address family not supported by protocol family' 14511: select(28,{ 20 21 22 23 24 25 26 27 },0x0,0x0,0x0) = 1 (0x1) 14511: read(26,"\^X\0\^E\^R\^C\0wlan0\0\0\0\0\0"...,5120) = 24 (0x18) 14511: select(28,{ 20 21 22 23 24 25 26 27 },0x0,0x0,0x0) ERR#4 'Interrupted system call' 14511: SIGNAL 14 (SIGALRM) 14511: sigprocmask(SIG_SETMASK,{ SIGALRM },0x0) = 0 (0x0) 14511: sigreturn(0x7fffffffd4c0) ERR#4 'Interrupted system call' 14511: socket(PF_UNSPEC,SOCK_DGRAM,0) ERR#47 'Address family not supported by protocol family' 14511: sendto(22,"\M-c\0\^F\M-h\0\0\0\0\0\0\0\aINI"...,48,0,{ AF_INET 91.207.136.50:123 },16) = 48 (0x30) 14511: sendto(22,"\M-c\0\^F\M-h\0\0\0\0\0\0\0\aINI"...,48,0,{ AF_INET 85.21.78.91:123 },16) = 48 (0x30) 14511: select(28,{ 20 21 22 23 24 25 26 27 },0x0,0x0,0x0) = 1 (0x1) 14511: recvmsg(22,0x7fffffffe5f0,0) = 48 (0x30) 14511: recvmsg(22,0x7fffffffe5f0,0) ERR#35 'Resource temporarily unavailable' 14511: socket(PF_UNSPEC,SOCK_DGRAM,0) ERR#47 'Address family not supported by protocol family' 14511: select(28,{ 20 21 22 23 24 25 26 27 },0x0,0x0,0x0) = 1 (0x1) 14511: recvmsg(22,0x7fffffffe5f0,0) = 48 (0x30) 14511: recvmsg(22,0x7fffffffe5f0,0) ERR#35 'Resource temporarily unavailable' 14511: socket(PF_UNSPEC,SOCK_DGRAM,0) ERR#47 'Address family not supported by protocol family' 14511: select(28,{ 20 21 22 23 24 25 26 27 },0x0,0x0,0x0) ERR#4 'Interrupted system call' 14511: SIGNAL 14 (SIGALRM) 14511: sigprocmask(SIG_SETMASK,{ SIGALRM },0x0) = 0 (0x0) 14511: sigreturn(0x7fffffffd4c0) ERR#4 'Interrupted system call' 14511: sendto(22,"\M-c\0\^F\M-h\0\0\0\0\0\0\0\bINI"...,48,0,{ AF_INET 185.22.60.71:123 },16) = 48 (0x30) 14511: sendto(22,"\M-c\0\^F\M-h\0\0\0\0\0\0\0\bINI"...,48,0,{ AF_INET 85.21.78.8:123 },16) = 48 (0x30) 14511: select(28,{ 20 21 22 23 24 25 26 27 },0x0,0x0,0x0) = 1 (0x1) 14511: recvmsg(22,0x7fffffffe5f0,0) = 48 (0x30) 14511: recvmsg(22,0x7fffffffe5f0,0) ERR#35 'Resource temporarily unavailable' 14511: socket(PF_UNSPEC,SOCK_DGRAM,0) ERR#47 'Address family not supported by protocol family' 14511: select(28,{ 20 21 22 23 24 25 26 27 },0x0,0x0,0x0) = 1 (0x1) 14511: recvmsg(22,0x7fffffffe5f0,0) = 48 (0x30) 14511: recvmsg(22,0x7fffffffe5f0,0) ERR#35 'Resource temporarily unavailable' 14511: socket(PF_UNSPEC,SOCK_DGRAM,0) ERR#47 'Address family not supported by protocol family' 14511: select(28,{ 20 21 22 23 24 25 26 27 },0x0,0x0,0x0) ERR#4 'Interrupted system call' 14511: SIGNAL 14 (SIGALRM) 14511: sigprocmask(SIG_SETMASK,{ SIGALRM },0x0) = 0 (0x0) 14511: sigreturn(0x7fffffffd4c0) ERR#4 'Interrupted system call' 14511: sendto(22,"\M-c\0\^F\M-h\0\0\0\0\0\0\0\tINI"...,48,0,{ AF_INET 91.207.136.50:123 },16) = 48 (0x30) 14511: sendto(22,"\M-c\0\^F\M-h\0\0\0\0\0\0\0\tINI"...,48,0,{ AF_INET 85.21.78.91:123 },16) = 48 (0x30) 14511: select(28,{ 20 21 22 23 24 25 26 27 },0x0,0x0,0x0) = 1 (0x1) 14511: recvmsg(22,0x7fffffffe5f0,0) = 48 (0x30) 14511: recvmsg(22,0x7fffffffe5f0,0) ERR#35 'Resource temporarily unavailable' 14511: socket(PF_UNSPEC,SOCK_DGRAM,0) ERR#47 'Address family not supported by protocol family' 14511: select(28,{ 20 21 22 23 24 25 26 27 },0x0,0x0,0x0) = 1 (0x1) 14511: recvmsg(22,0x7fffffffe5f0,0) = 48 (0x30) 14511: recvmsg(22,0x7fffffffe5f0,0) ERR#35 'Resource temporarily unavailable' 14511: socket(PF_UNSPEC,SOCK_DGRAM,0) ERR#47 'Address family not supported by protocol family' 14511: select(28,{ 20 21 22 23 24 25 26 27 },0x0,0x0,0x0) ERR#4 'Interrupted system call' 14511: SIGNAL 14 (SIGALRM) 14511: sigprocmask(SIG_SETMASK,{ SIGALRM },0x0) = 0 (0x0) 14511: sigreturn(0x7fffffffd4c0) ERR#4 'Interrupted system call' 14511: sendto(22,"\M-c\0\^F\M-h\0\0\0\0\0\0\0\nINI"...,48,0,{ AF_INET 185.22.60.71:123 },16) = 48 (0x30) 14511: sendto(22,"\M-c\0\^F\M-h\0\0\0\0\0\0\0\nINI"...,48,0,{ AF_INET 85.21.78.8:123 },16) = 48 (0x30) 14511: select(28,{ 20 21 22 23 24 25 26 27 },0x0,0x0,0x0) = 1 (0x1) 14511: recvmsg(22,0x7fffffffe5f0,0) = 48 (0x30) 14511: recvmsg(22,0x7fffffffe5f0,0) ERR#35 'Resource temporarily unavailable' 14511: socket(PF_UNSPEC,SOCK_DGRAM,0) ERR#47 'Address family not supported by protocol family' 14511: 14511: exit(0xffffffff) 14511: process exit, rval = 4294967295 -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra From owner-freebsd-current@freebsd.org Wed Jun 14 16:23:04 2017 Return-Path: Delivered-To: freebsd-current@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 DF38ABEE5DB for ; Wed, 14 Jun 2017 16:23:04 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (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 9DE7F6F575 for ; Wed, 14 Jun 2017 16:23:04 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-yb0-x233.google.com with SMTP id 84so1842736ybe.0 for ; Wed, 14 Jun 2017 09:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=r41sNvRW8oMmElWp+qInZbmG9h8j6+fVWxgh99Na8HU=; b=V0Oo6A0UeJVq7RtLxNqI66Uedxj9Yn3ylDHr3CJC2ySBHOgoRdBu4WV09oOiINNFiR RNMNY5y/0Qmc9EKljhUbtEw8xRLK2AVOfTVTJ5IldjRizRH/L14L1G9ZZ9mwoFe6Iecs f/TLXpHCoN0YcHJdFFuQsm3WmAmKO/qbHR3YLqpmPBIf8g8ha6TrN1dgKWjzQJGnzQMk +dv6kxxxxCREDKnAtS7lZPIDUIPzniaLgpBscQlkl4/GvKb3FMovjdhuKw8fmuf0pkDD hSLT1BQgzxI3LSvTlkvmCgpYtuAbgo4EJgoA6dQFu0V5l6i36aqLWItCFQFprJRHOcPH d2Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=r41sNvRW8oMmElWp+qInZbmG9h8j6+fVWxgh99Na8HU=; b=Jg66fM1aU/h2pMLX1mLjHJ/ZsYEERVyoeufIbh7/umv33Bvso70S4Mb0TU+WxuUbgO rW9JyowAwV2pwEbc2G7gg/PqbjRMRKZe1G+pWHWKeKf9wNZ3CkylCGvkr14ONwcGwcNA VAu7W/i3MWPXIg0TE+q9U3PhsIso4dZ/OGIOk/dJPQlCkAunt+jpcyRdN6L3CvD0b7Dl 2U53JADtZzufus0q8tX1v5/VsVNSrpgpdt/R0HtDF7IbTU65zYP9Ye3QVi6fqbyUZ2WX piduLQn5vW+D0F/7Qig0i2qyiFvVZzmtG/YTpIAJ/uhID0ngAozzzcxRGujKseSL9Yqg fwIg== X-Gm-Message-State: AKS2vOygwm2U13SlmgMC/lLYY3taEucL7+q8/HqOWAOQ7BjK8z+vm7Nw w914lROSadTUsEm+AFekmHMnhclTyw== X-Received: by 10.37.219.208 with SMTP id g199mr808981ybf.195.1497457383511; Wed, 14 Jun 2017 09:23:03 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.13.206.199 with HTTP; Wed, 14 Jun 2017 09:23:02 -0700 (PDT) In-Reply-To: <20170614155714.lvljvn4dsztinull@vzakharov> References: <20170614155714.lvljvn4dsztinull@vzakharov> From: Alan Somers Date: Wed, 14 Jun 2017 10:23:02 -0600 X-Google-Sender-Auth: 1j1KaQ-uT6tJOkmZ5qaJeJGVnHk Message-ID: Subject: Re: ntpd dies soon after start To: Vladimir Zakharov Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 16:23:05 -0000 On Wed, Jun 14, 2017 at 9:57 AM, Vladimir Zakharov wrote: > Hello! > > I have ntpd enabled to start during boot. I see, that it starts. But > querying it after booting fails: > # ntpq -p > ntpq: read: Connection refused > > After manual start, it works for several seconds and then dies. > root@vzakharov:~ # service ntpd start > Starting ntpd. > root@vzakharov:~ # ntpq -p > remote refid st t when poll reach delay offset jitter > ============================================================================== > 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 0.000 > ftpshare1.corbi 89.109.251.21 2 u 1 64 1 1.489 1344688 0.000 > root@vzakharov:~ # ntpq -p > remote refid st t when poll reach delay offset jitter > ============================================================================== > 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 0.000 > ftpshare1.corbi 89.109.251.21 2 u 1 64 1 1.495 1344688 0.018 > time.ooonet.ru 89.109.251.24 2 u 1 64 1 25.201 1344687 0.000 > nag.aleksdem.co 194.190.168.1 2 u 1 64 1 1.914 1344687 0.000 > root@vzakharov:~ # ntpq -p > remote refid st t when poll reach delay offset jitter > ============================================================================== > 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 0.000 > ground.corbina. 193.11.166.20 2 u 2 64 1 1.673 1344687 0.000 > ftpshare1.corbi 193.11.166.20 2 u 1 64 1 1.532 1344688 0.018 > time.ooonet.ru 89.109.251.24 2 u 2 64 1 25.169 1344687 0.035 > nag.aleksdem.co 194.190.168.1 2 u 1 64 1 2.740 1344686 0.311 > root@vzakharov:~ # ntpq -p > ntpq: read: Connection refused This is by design. Your offset is so large (more than a year), that ntpd fails its basic sanity test. You need to do one of the following: 1) Manually set the time before starting ntpd for the first time 2) Invoke ntpd with the "-g" flag 3) Run ntpdate before running ntpd. -Alan From owner-freebsd-current@freebsd.org Wed Jun 14 16:34:44 2017 Return-Path: Delivered-To: freebsd-current@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 83F2CBEEA9C for ; Wed, 14 Jun 2017 16:34:44 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (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 01A656FE73; Wed, 14 Jun 2017 16:34:44 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: by mail-lf0-x235.google.com with SMTP id p189so5335145lfe.2; Wed, 14 Jun 2017 09:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=fTJckHUePN0mFr24odTbXdvQmdTJbYabInQNdqTFneg=; b=UrzetXOm2CqxG/WL89KjwVBU/Y7asQ+mkR/M3WMKwdDYm7FaUL1jYyRhyJTu8FzI4x txyd/MB9n6fcBjgPRFo3frkR7vGN7aRzdJJJ7S9cchsEaNfna9PS0l2Wm96beLr8qP/6 NCHsB9Py/BdVectUPUglaOwgUV4HvcYXZ6F6GxF1etCpznB/WHGccWgDO5uZyA/VyaXS Lsrv1O2es4k5E1Q1gduw9PWhPpmE+LdVob8ESEIJCaTcXctzr0NRmtAqMwDgozaHo6i9 eRdU0DNYeIAmEwu/ui3uHJwvn48zNcer3RPepPhd++k9pT88GlJQL+amLQWWB53k6a5Q t8Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=fTJckHUePN0mFr24odTbXdvQmdTJbYabInQNdqTFneg=; b=EziBklhDTFmOI+YGT+XjFTzmBkCgDiu8eHpUQOaXDU5cVqIrP6xV61LXH0JcAyOrfP xfbStG/AMp7tR3f3fEbB83F18MooEFMAPhEIeNDtQ2IgyFkPD7XwZ7If3TQ/kDRSxmOH MeayHkaKkNX9tkWJoqeNrtu3LjSHdKTBAlR2WsgygRQT/XU1IXze3IVwvzbatAxCXlNz YLrE8K15mnkcg5EYdKAk82zzBPBvQJA0pVp502/z3ELTWD6JU18EME20PDxaQYtvcbrG qsrV0KjWDwdMST62FzK6f3P3cXYqYA8qTOgi9Cr/Ag+RuEhw/6yiXrsd2j4771eQViLt SDYg== X-Gm-Message-State: AKS2vOyFwGx8XpkHNESoBwRHfyYh5NtQZL3Wm7baR0nUi1X3dwvnHPnZ wPx04af9hvhHUFacUio= X-Received: by 10.46.33.164 with SMTP id h36mr301504lji.86.1497458081941; Wed, 14 Jun 2017 09:34:41 -0700 (PDT) Received: from localhost ([81.19.73.157]) by smtp.gmail.com with ESMTPSA id j63sm121084lfi.26.2017.06.14.09.34.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Jun 2017 09:34:41 -0700 (PDT) Date: Wed, 14 Jun 2017 19:34:40 +0300 From: Vladimir Zakharov To: Alan Somers Cc: FreeBSD CURRENT Subject: Re: ntpd dies soon after start Message-ID: <20170614163440.xgzqlph3nldki2vi@vzakharov> References: <20170614155714.lvljvn4dsztinull@vzakharov> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 12.0-CURRENT amd64 X-PGP-Key: http://vzakharov.ru/pubkey.asc User-Agent: NeoMutt/20170609 (1.8.3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 16:34:44 -0000 On Wed, Jun 14, 2017, Alan Somers wrote: > On Wed, Jun 14, 2017 at 9:57 AM, Vladimir Zakharov > > This is by design. Your offset is so large (more than a year), that > ntpd fails its basic sanity test. You need to do one of the > following: > 1) Manually set the time before starting ntpd for the first time > 2) Invoke ntpd with the "-g" flag > 3) Run ntpdate before running ntpd. My offset was about 22 minutes only. Your receipt solved the problem. Thanks root@vzakharov:~ # date Wed Jun 14 19:02:55 MSK 2017 root@vzakharov:~ # /usr/sbin/ntpd -q -c /etc/ntp.conf -p /var/run/ntpd.pid -f /var/db/ntpd.drift 14 Jun 19:05:01 ntpd[14722]: ntpd 4.2.8p10-a (1): Starting 14 Jun 19:05:01 ntpd[14722]: Command line: /usr/sbin/ntpd -q -c /etc/ntp.conf -p /var/run/ntpd.pid -f /var/db/ntpd.drift 14 Jun 19:05:01 ntpd[14722]: proto: precision = 0.065 usec (-24) 14 Jun 19:05:01 ntpd[14722]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): good hash signature 14 Jun 19:05:01 ntpd[14722]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): loaded, expire=2017-12-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37 14 Jun 19:05:01 ntpd[14722]: Listen and drop on 0 v6wildcard [::]:123 14 Jun 19:05:01 ntpd[14722]: Listen and drop on 1 v4wildcard 0.0.0.0:123 14 Jun 19:05:01 ntpd[14722]: Listen normally on 2 re0 10.60.0.245:123 14 Jun 19:05:01 ntpd[14722]: Listen normally on 3 lo0 [::1]:123 14 Jun 19:05:01 ntpd[14722]: Listen normally on 4 lo0 [fe80::1%2]:123 14 Jun 19:05:01 ntpd[14722]: Listen normally on 5 lo0 127.0.0.1:123 14 Jun 19:05:01 ntpd[14722]: Listening on routing socket on fd #26 for interface updates 14 Jun 19:05:02 ntpd[14722]: Soliciting pool server 192.36.143.130 14 Jun 19:05:03 ntpd[14722]: Soliciting pool server 195.122.241.236 14 Jun 19:05:04 ntpd[14722]: Soliciting pool server 91.207.136.55 14 Jun 19:05:05 ntpd[14722]: Soliciting pool server 194.190.168.1 root@vzakharov:~ # ntpdate 0.freebsd.pool.ntp.org 14 Jun 19:28:49 ntpdate[14740]: step time server 194.190.168.1 offset 1344.686561 sec root@vzakharov:~ # date Wed Jun 14 19:28:53 MSK 2017 -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra From owner-freebsd-current@freebsd.org Wed Jun 14 16:40:35 2017 Return-Path: Delivered-To: freebsd-current@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 5DA39BEEDFB for ; Wed, 14 Jun 2017 16:40:35 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 15D77702FF for ; Wed, 14 Jun 2017 16:40:35 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-yw0-x235.google.com with SMTP id e142so3602218ywa.1 for ; Wed, 14 Jun 2017 09:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=LYQRQu+Lpc7HoJH2TCr60NIqRtNPXYaRMioDnKQ6yO0=; b=Jbtibor5KmpmN1UDcvcSwYgGe4ubdZXxVarrbvPWsrsY9psQEeaiBkkE4ZP1aThfip sQlLsehTZUGPE7QMoreL0FdiVbsYcM7NBSQ/PULuyPiSgviPibymb4dpsO71Emdbn8hD nl1jHBpzq6/EaSFWv6l2XKXf2H1bG6mjBHPMP8QYWswbW5O5oaysGjLLn272SnGANPKz kXX2WV2lcFJbtKtuEBbu354Wj0uCm7cD9wcu2V4bEULq1PUnRfBAymW9adPCL6MN4R9s 7GYE6Wjcux0SgRZ0WieLUTpihpuuwhI+dxxSfhNEtRwYGqQ9xxw2mWpNoPRkvhdIhGZ8 eCcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=LYQRQu+Lpc7HoJH2TCr60NIqRtNPXYaRMioDnKQ6yO0=; b=AFv2T/X6d0VzfVv4LUx++QRF6ttcuoEtG2lSqwrt9hfc5SDlYZC7Kz3eiK5lR0qR7N PoJYW2Nt+z4/UlmKGGI7aB8Xg78jVSSGpe7w7PjVywTvoqRf3Y1UDEea7WqCXSHuHy0q q23bThOkOdnwy4/qMu1LcATGg+Kltjp15vL7omom7f3GI+9KH6Bol/agvXTLYD3Vakbh nP/UMlAfb00ES1n2/z5WIAr/GjCJrS8p1F4uNjmRl2cp3oik1Sgr8EwLPduXnpjt2Mbv /pMCCv73L+koBYiynHUGshX+2DWdZV948DWJE2wf/rJoBoj6kcdWGOUt4XVTN+bb7fla /BWg== X-Gm-Message-State: AKS2vOyBKi0Ov1Uku8BhYoAziyqxqRWgK3fclcrbyq06CGeGvxARtFUB sfamv/9m8ysdJsMzGbtcMvgN76w8Qg== X-Received: by 10.129.162.14 with SMTP id z14mr860461ywg.276.1497458433928; Wed, 14 Jun 2017 09:40:33 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.13.206.199 with HTTP; Wed, 14 Jun 2017 09:40:33 -0700 (PDT) In-Reply-To: <20170614163440.xgzqlph3nldki2vi@vzakharov> References: <20170614155714.lvljvn4dsztinull@vzakharov> <20170614163440.xgzqlph3nldki2vi@vzakharov> From: Alan Somers Date: Wed, 14 Jun 2017 10:40:33 -0600 X-Google-Sender-Auth: YN0L-9QrYK0MZlt4tU6U3RROqIU Message-ID: Subject: Re: ntpd dies soon after start To: Vladimir Zakharov Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 16:40:35 -0000 On Wed, Jun 14, 2017 at 10:34 AM, Vladimir Zakharov wrote: > On Wed, Jun 14, 2017, Alan Somers wrote: >> On Wed, Jun 14, 2017 at 9:57 AM, Vladimir Zakharov >> >> This is by design. Your offset is so large (more than a year), that >> ntpd fails its basic sanity test. You need to do one of the >> following: >> 1) Manually set the time before starting ntpd for the first time >> 2) Invoke ntpd with the "-g" flag >> 3) Run ntpdate before running ntpd. > > My offset was about 22 minutes only. Your receipt solved the problem. > Thanks My bad; I was thinking that the offset was in seconds but it's actually in milliseconds. Glad to hear your problem's fixed. > > root@vzakharov:~ # date > Wed Jun 14 19:02:55 MSK 2017 > root@vzakharov:~ # /usr/sbin/ntpd -q -c /etc/ntp.conf -p /var/run/ntpd.pid -f /var/db/ntpd.drift > 14 Jun 19:05:01 ntpd[14722]: ntpd 4.2.8p10-a (1): Starting > 14 Jun 19:05:01 ntpd[14722]: Command line: /usr/sbin/ntpd -q -c /etc/ntp.conf -p /var/run/ntpd.pid -f /var/db/ntpd.drift > 14 Jun 19:05:01 ntpd[14722]: proto: precision = 0.065 usec (-24) > 14 Jun 19:05:01 ntpd[14722]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): good hash signature > 14 Jun 19:05:01 ntpd[14722]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): loaded, expire=2017-12-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37 > 14 Jun 19:05:01 ntpd[14722]: Listen and drop on 0 v6wildcard [::]:123 > 14 Jun 19:05:01 ntpd[14722]: Listen and drop on 1 v4wildcard 0.0.0.0:123 > 14 Jun 19:05:01 ntpd[14722]: Listen normally on 2 re0 10.60.0.245:123 > 14 Jun 19:05:01 ntpd[14722]: Listen normally on 3 lo0 [::1]:123 > 14 Jun 19:05:01 ntpd[14722]: Listen normally on 4 lo0 [fe80::1%2]:123 > 14 Jun 19:05:01 ntpd[14722]: Listen normally on 5 lo0 127.0.0.1:123 > 14 Jun 19:05:01 ntpd[14722]: Listening on routing socket on fd #26 for interface updates > 14 Jun 19:05:02 ntpd[14722]: Soliciting pool server 192.36.143.130 > 14 Jun 19:05:03 ntpd[14722]: Soliciting pool server 195.122.241.236 > 14 Jun 19:05:04 ntpd[14722]: Soliciting pool server 91.207.136.55 > 14 Jun 19:05:05 ntpd[14722]: Soliciting pool server 194.190.168.1 > root@vzakharov:~ # ntpdate 0.freebsd.pool.ntp.org > 14 Jun 19:28:49 ntpdate[14740]: step time server 194.190.168.1 offset 1344.686561 sec > root@vzakharov:~ # date > Wed Jun 14 19:28:53 MSK 2017 > > -- > Regards, | "In theory there is no difference between theory > Vladimir Zakharov | and practice. In practice there is."- Yogi Berra From owner-freebsd-current@freebsd.org Wed Jun 14 19:14:47 2017 Return-Path: Delivered-To: freebsd-current@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 1C549BF20C4 for ; Wed, 14 Jun 2017 19:14:47 +0000 (UTC) (envelope-from bob@rancor.immure.com) Received: from rancor.immure.com (108-84-10-9.lightspeed.austtx.sbcglobal.net [108.84.10.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "darth.immure.com", Issuer "darth.immure.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DF5AD75BEF for ; Wed, 14 Jun 2017 19:14:46 +0000 (UTC) (envelope-from bob@rancor.immure.com) Received: from rancor.immure.com (localhost [127.0.0.1]) by rancor.immure.com (8.15.2/8.15.2) with ESMTPS id v5EJEjL8005813 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 14 Jun 2017 14:14:45 -0500 (CDT) (envelope-from bob@rancor.immure.com) Received: (from bob@localhost) by rancor.immure.com (8.15.2/8.15.2/Submit) id v5EJEjBa005812 for freebsd-current@freebsd.org; Wed, 14 Jun 2017 14:14:45 -0500 (CDT) (envelope-from bob) Date: Wed, 14 Jun 2017 14:14:45 -0500 From: Bob Willcox To: current list Subject: mount -t tmpfs tmpfs fails Message-ID: <20170614191445.GC5608@rancor.immure.com> Reply-To: Bob Willcox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.8.0 (2017-02-23) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 19:14:47 -0000 I was attempting to run 'synth status' on my 12-current (drm-next) system and I got this error: root@tavion:0 /> synth status Querying system about current package installations. Stand by, comparing installed packages against the ports tree. raised REPLICANT.SCENARIO_UNEXPECTED : /sbin/mount -t tmpfs tmpfs /usr/obj/synth-live/SL09 => failed with code 1 So then I attempted just to do a mount of tmpfs command and got this: root@tavion:0 /> mount -t tmpfs x /tmp/xxx mount: x: Operation not supported by device synth used to work on this system prior to my recent upgrade to the latest drm-next branch (cloned from github and build from source). root@tavion:1 /> uname -a FreeBSD tavion.austin.ibm.com 12.0-CURRENT FreeBSD 12.0-CURRENT #1 da5f90154f1(drm-next): Tue Jun 13 16:58:52 CDT 2017 bob@tavion.austin.ibm.com:/usr/obj/usr/freebsd-base-graphics/sys/TAVION amd64 Any suggestions on what I should be looking for (or fixing)? Thanks, Bob -- Bob Willcox | Lawsuit, n.: A machine which you go into as a pig and bob@immure.com | come out as a sausage. Austin, TX | -- Ambrose Bierce From owner-freebsd-current@freebsd.org Wed Jun 14 20:50:36 2017 Return-Path: Delivered-To: freebsd-current@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 89627BF39FE for ; Wed, 14 Jun 2017 20:50:36 +0000 (UTC) (envelope-from bob@rancor.immure.com) Received: from rancor.immure.com (108-84-10-9.lightspeed.austtx.sbcglobal.net [108.84.10.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "darth.immure.com", Issuer "darth.immure.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 50D03783AD for ; Wed, 14 Jun 2017 20:50:35 +0000 (UTC) (envelope-from bob@rancor.immure.com) Received: from rancor.immure.com (localhost [127.0.0.1]) by rancor.immure.com (8.15.2/8.15.2) with ESMTPS id v5EKoY8a006039 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 14 Jun 2017 15:50:34 -0500 (CDT) (envelope-from bob@rancor.immure.com) Received: (from bob@localhost) by rancor.immure.com (8.15.2/8.15.2/Submit) id v5EKoYH8006038 for freebsd-current@freebsd.org; Wed, 14 Jun 2017 15:50:34 -0500 (CDT) (envelope-from bob) Date: Wed, 14 Jun 2017 15:50:34 -0500 From: Bob Willcox To: current list Subject: Re: mount -t tmpfs tmpfs fails Message-ID: <20170614205034.GD5608@rancor.immure.com> Reply-To: Bob Willcox References: <20170614191445.GC5608@rancor.immure.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170614191445.GC5608@rancor.immure.com> User-Agent: Mutt/1.8.0 (2017-02-23) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 20:50:36 -0000 On Wed, Jun 14, 2017 at 02:14:45PM -0500, Bob Willcox wrote: > I was attempting to run 'synth status' on my 12-current (drm-next) system > and I got this error: > > root@tavion:0 /> synth status > Querying system about current package installations. > Stand by, comparing installed packages against the ports tree. > > raised REPLICANT.SCENARIO_UNEXPECTED : /sbin/mount -t tmpfs tmpfs /usr/obj/synth-live/SL09 => failed with code 1 > > So then I attempted just to do a mount of tmpfs command and got this: > > root@tavion:0 /> mount -t tmpfs x /tmp/xxx > mount: x: Operation not supported by device > > synth used to work on this system prior to my recent upgrade to the latest > drm-next branch (cloned from github and build from source). > > root@tavion:1 /> uname -a > FreeBSD tavion.austin.ibm.com 12.0-CURRENT FreeBSD 12.0-CURRENT #1 da5f90154f1(drm-next): Tue Jun 13 16:58:52 CDT 2017 bob@tavion.austin.ibm.com:/usr/obj/usr/freebsd-base-graphics/sys/TAVION amd64 > > Any suggestions on what I should be looking for (or fixing)? > > Thanks, > Bob Ok, I finally figured out that my previous kernel must have had the tmpfs (and nullfs, it was a problem also with synth) built into the kernel, probably by default. Further, the tmpfs.ko and nullfs.ko modules weren't built and installed. I wound up building and installing both tmpfs and nullfs manually (cding to their respective src direcdories and running make; make install) to get synth to run. My only question remaining now is was the removal of the building and installing of these modules a fairly recent change in 12.0, or is something in my system hosed up? Thanks, Bob -- Bob Willcox | Lawsuit, n.: A machine which you go into as a pig and bob@immure.com | come out as a sausage. Austin, TX | -- Ambrose Bierce From owner-freebsd-current@freebsd.org Thu Jun 15 07:45:35 2017 Return-Path: Delivered-To: freebsd-current@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 CC3BCC779B6 for ; Thu, 15 Jun 2017 07:45:35 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0F54668264 for ; Thu, 15 Jun 2017 07:45:34 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA04270 for ; Thu, 15 Jun 2017 10:45:27 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1dLPT4-000GrR-SA for freebsd-current@FreeBSD.org; Thu, 15 Jun 2017 10:45:26 +0300 To: FreeBSD Current From: Andriy Gapon Subject: hwpmc and Xeon E5 v4 Message-ID: Date: Thu, 15 Jun 2017 10:44:05 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 07:45:35 -0000 It seems that hwpmc does not support newer Xeon processors: pmc: Unknown Intel CPU. This is how FreeBSD reports a processor from Xeon E5 v4 line: CPU: Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz (2095.20-MHz K8-class CPU) Origin="GenuineIntel" Id=0x406f1 Family=0x6 Model=0x4f Stepping=1 Features=0xbfebfbff Features2=0x7ffefbff AMD Features=0x2c100800 AMD Features2=0x121 Structured Extended Features=0x21cbfbb XSAVE Features=0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr TSC: P-state invariant, performance statistics I think that this processor belongs to Broadwell-EP family: http://www.cpu-world.com/CPUs/Xeon/Intel-Xeon%20E5-2620%20v4.html >From my reading of the code it seems that 0xf1 case needs to be added to the big switch statement on the CPU model number. But I am not sure if / how the processor is compatible which the previous models. Would it suffice to treat that CPU as PMC_CPU_INTEL_BROADWELL_XEON? Or would something more elaborate be required? I would appreciate any help, patches, suggestions, documentation links, etc. Thank you. -- Andriy Gapon From owner-freebsd-current@freebsd.org Thu Jun 15 08:16:12 2017 Return-Path: Delivered-To: freebsd-current@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 15E97C78396 for ; Thu, 15 Jun 2017 08:16:12 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 C685968D24; Thu, 15 Jun 2017 08:16:11 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-qt0-x236.google.com with SMTP id w1so10280832qtg.2; Thu, 15 Jun 2017 01:16:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mdKmPtEABSFlZNUg9DHgtOveUp+fJCbKbjNO1Wi0a18=; b=Gwu6IIB1c2RIQD++ztd6nEUhNDOTeIMB7o+MqroAKTcn4JGOGen2Ml6Dz/0TZ4ZtDf y/34MZOsEe0a9TCK70laB8y4Qzv4R4QADssUqiJuyy2yRzcaTlKiOcZeUnfNgRKHCXKx lNsJkYe/MVUo6r8HuK7ntpgJCK0bnhvgNnmvAIkhHKwc+AB4IXohOPRXnk1wEnPFpE0r CAh4m1yvNhwKDCxqrOn6jXjHkplMAwDdag6R/iWzX1h07/XyRtnfWWDts/J46rJhc5C6 RNw/h3jhkRVCbii7fZrsguPV6SgXM/0vx/7fZ/ymzlkVh5OpA6Pr3Tom8tmQV/D2AHvq 9qng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mdKmPtEABSFlZNUg9DHgtOveUp+fJCbKbjNO1Wi0a18=; b=V0s0j3w8IxemOJNLIdhNCU5Lpz0BbLSJVUc6b7RNKyj8HWv9+7KWphHGJWFk1jcB5v zvEgNnacKoV4tVeDkWdFOCvhR4i18KRfTKTbg+54zAUpEmiKCtAq4OLS2+dinOZGUeyr xqD/EPrlgG3LameunehhMt3ckAGyd3ulIg1zqJQ7aAZIaHIKTtrybPXcYQ7fHQm7dqAJ QkSmO2lMBour1WBTspdLulRGzAZkrIoOl0GSrK3KjAc4mdbeCPQhK0mUaX2+oMrY9BrS Bk9Vj/2gtPTxfExOFOTkQSjZTjhk0gqki46Y0HO4LuUsAd4UFOX7Vpqip3/j2DVN8k7k v+Fw== X-Gm-Message-State: AKS2vOxK2vP28zLFNiaLfy+kGhkqKkRr7ZESlMls/6R+KRQYNZVHhes0 qFl34gulGrUKOoN2A36MLKjxjgMQEKxg X-Received: by 10.55.76.140 with SMTP id z134mr4879348qka.35.1497514570718; Thu, 15 Jun 2017 01:16:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.92.214 with HTTP; Thu, 15 Jun 2017 01:16:10 -0700 (PDT) In-Reply-To: References: From: Ngie Cooper Date: Thu, 15 Jun 2017 01:16:10 -0700 Message-ID: Subject: Re: hwpmc and Xeon E5 v4 To: Andriy Gapon Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 08:16:12 -0000 On Thu, Jun 15, 2017 at 12:44 AM, Andriy Gapon wrote: > > It seems that hwpmc does not support newer Xeon processors: > pmc: Unknown Intel CPU. What FreeBSD version is this? -Ngie From owner-freebsd-current@freebsd.org Thu Jun 15 09:51:38 2017 Return-Path: Delivered-To: freebsd-current@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 4FFA3C79FFB for ; Thu, 15 Jun 2017 09:51:38 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 836496F73F for ; Thu, 15 Jun 2017 09:51:37 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA04537; Thu, 15 Jun 2017 12:51:35 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1dLRR8-000Gwy-VC; Thu, 15 Jun 2017 12:51:34 +0300 Subject: Re: hwpmc and Xeon E5 v4 To: Ngie Cooper Cc: FreeBSD Current References: From: Andriy Gapon Message-ID: Date: Thu, 15 Jun 2017 12:50:38 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 09:51:38 -0000 On 15/06/2017 11:16, Ngie Cooper wrote: > On Thu, Jun 15, 2017 at 12:44 AM, Andriy Gapon wrote: >> >> It seems that hwpmc does not support newer Xeon processors: >> pmc: Unknown Intel CPU. > > What FreeBSD version is this? Head as of January. I do not see any changes to hwpmc_intel.c since then. -- Andriy Gapon From owner-freebsd-current@freebsd.org Thu Jun 15 18:49:15 2017 Return-Path: Delivered-To: freebsd-current@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 5356FB94016 for ; Thu, 15 Jun 2017 18:49:15 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 3ECC77FB7D for ; Thu, 15 Jun 2017 18:49:15 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 3E129B94014; Thu, 15 Jun 2017 18:49:15 +0000 (UTC) Delivered-To: current@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 3D9E0B94013 for ; Thu, 15 Jun 2017 18:49:15 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1D5557FB7C; Thu, 15 Jun 2017 18:49:15 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1235) id 6EC9437D0; Thu, 15 Jun 2017 18:49:14 +0000 (UTC) Date: Thu, 15 Jun 2017 20:49:14 +0200 From: Baptiste Daroussin To: Konstantin Belousov Cc: current@freebsd.org Subject: Re: kqueue(2) changes Message-ID: <20170615184914.axdulfdqzv6wpc4a@ivaldir.net> References: <20170602074516.GE82323@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bmz4wtxow7qoyh52" Content-Disposition: inline In-Reply-To: <20170602074516.GE82323@kib.kiev.ua> User-Agent: NeoMutt/20170428 (1.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 18:49:15 -0000 --bmz4wtxow7qoyh52 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 02, 2017 at 10:45:16AM +0300, Konstantin Belousov wrote: > I implemented an option to specify absolute time for kqueue(2) timers, > and did required type changes to support larger values in struct kevent. > Please see https://reviews.freebsd.org/D11025 for the patch, including > man page update, and for some more detailed explanation. >=20 > Please review. For me that looks good. As one of those requesting for that change (actually proxying the request from glib people for a appel's kqueue64 compatible interface). I find this approach more clever. As far as I remember it perfectly fits glib folks requirements (unfortunatl= y I could not reach out any of them to review yet) Here is a mail describing their requirement at the time: https://lists.freebsd.org/pipermail/freebsd-hackers/2014-March/044451.html In any case it opens the doors to be able to use kevent based timers with a nanonsecond precision useful, so looks good to me. Thank you, Best regards, Bapt --bmz4wtxow7qoyh52 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAllC1qcACgkQY4mL3PG3 PlpbLQ//Th1Gj8qnf4N+b1c7zWRnkP6u69EbkmGXBpMu3UiFJRLlow0DPG5ts+Ls lr01rGINHr1NRDfENu61M4KX9YG/80a7uTPr3gE2ozfNmnlG35PU3jl09FO4mUoG kCbPvXEvSJCxQJX/VDJ256VY7CpwmtGCZEo0EkFAbNzpjX2CxIP12UTvOAB0/Xsd ehZe/4+ppnE3jZA/btlckddWf2JdGJyS8enh96eH+GZlGEL1Lr7juDrANLlwOfyV jN4Vk+RXvj3KjAlHveB5eK327CRvNTUh1z4SPfvFJnbJshEPVlzqsVApDJUEEnNS sjQaloW8FlvVY4Xq7zbsZEux+a82+KEA0AI2ONurxxbSDZtU7xsV1WMvu8gMVhol wq/wT1gExyCH4/U04F92eoHZ/L9pF0tyZJId0WulZw6+CZIRaB/LgRzEpu4TYX4q t36wJ0e6mkeNccv5wOLsHs6c8nmgZv5nEwh/yK+Roc3NYXOwBno+r/xQohjCuk6T t9zTzy+UwbQ7bUISy+TxAguTQ5JS7WYSflOT3npK0X/N5qqihaACLjz+Mc/2XP+F v5tvPEyK8zydowPnFLVASKqUDDBIX3VBmZmq3ghz0pd5TRwWulHHphaGqaJfxgpi 9/nS/RCBjCBSo1mzc2jKc/y+PdC0ZFVnz+/xpM8sMWVZzxrrvYg= =gaaG -----END PGP SIGNATURE----- --bmz4wtxow7qoyh52-- From owner-freebsd-current@freebsd.org Fri Jun 16 10:03:32 2017 Return-Path: Delivered-To: freebsd-current@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 8FDCDBFC798 for ; Fri, 16 Jun 2017 10:03:32 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 39A0179130 for ; Fri, 16 Jun 2017 10:03:32 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: by mail-wm0-x236.google.com with SMTP id m125so21588440wmm.1 for ; Fri, 16 Jun 2017 03:03:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=ffkL588pCyYWJ+t3t/J8QJ+yJGXhn14vzBMlROrmN3U=; b=tF++AG/TTfDXvBZhAXmLf9W9EPZU06VpwBT9tuKL/XSLva0VJ1tdMRO2lhifEbNVc1 85lG3yy996e/7t9Pp3KVWtaiUgZy9hWXtHbeO4s511YPgAq6iIR2Qz/0hvLr9MVE34NR T5DqQzLQEwcRqqwcZYKGVu7qUHGEGb9TMi8UBUu1AqIvg5bst3P/FFkOjJXG0wQw9MC3 lrKCAi4RtlGgaeKECL7ukBV2QPa9ZdlZsCem1TwlCFjowdWIAQK/jTGbRvQ8FRvVvJEv fYt8zUlQTo4pdoZySpFEpzB3UZwVpk+O8buY7vraCR5mRmV9Lpi5vu/VFE4EWCibv3vy hfZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=ffkL588pCyYWJ+t3t/J8QJ+yJGXhn14vzBMlROrmN3U=; b=L2/Pu7Pw7YlFw64UHnjEMfz+mWDPjV4g55REBp9U4cLOiYB3gO+IAht1In5kR6eLsT F4wXGgudwkyPKeuOxVj5m7/nvbofZ1uytxxTLaAbguplqVNXKFXozGtGK+QRomVjulMk YB502Wxnhy1CN1v33YMAZIm5E3FRc6dnjylbY3oW4gGM2gxr5v3kK04iPs/sY+3KbXG2 g67pK3838zdthJ1Tlznse1NaDuCcB6mGJioflUYzmRORQXJXazcVgEPwS2ImM1ApVUBN XEftpBDkeZnvLA+0P4jE08aoryp6qVHozeGyf929vIf3PhosfoL3tngXFCHrgF6428MT Iqcw== X-Gm-Message-State: AKS2vOwmnMpz2rXnJTBUMKfzdmnktfkzGNo1bIsaFDELE9CI8W4DvkWX +P1UKWP8ff5YpwOcsFl6NSgbmx+QQIFA X-Received: by 10.28.198.3 with SMTP id w3mr6787515wmf.112.1497607410687; Fri, 16 Jun 2017 03:03:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.183.11 with HTTP; Fri, 16 Jun 2017 03:03:30 -0700 (PDT) From: Johannes Lundberg Date: Fri, 16 Jun 2017 12:03:30 +0200 Message-ID: Subject: libchromiumcontent (and electron+atom) To: freebsd-current Cc: pusateri@bangj.com Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 10:03:32 -0000 Hi Following this thread https://lists.freebsd.org/pipermail/freebsd-ports/2015-June/099398.html it seems someone (Tom?) was working on a port for libchromiumcontent. Whatever happened to this effort? libchromiumcontent is required for Electron which is required for Atom. I would love to use Atom editor on FreeBSD. Anyone with me to finally make this happen? (can't do it alone) From owner-freebsd-current@freebsd.org Fri Jun 16 19:14:38 2017 Return-Path: Delivered-To: freebsd-current@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 341B2D87469; Fri, 16 Jun 2017 19:14:38 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1C923682FA; Fri, 16 Jun 2017 19:14:38 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v5GJEa9Q001246 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Jun 2017 12:14:36 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v5GJEade001245; Fri, 16 Jun 2017 12:14:36 -0700 (PDT) (envelope-from sgk) Date: Fri, 16 Jun 2017 12:14:36 -0700 From: Steve Kargl To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: panic: handle_written_inodeblock: Invalid link count 57368 Message-ID: <20170616191436.GA1189@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 19:14:38 -0000 I grabbed a spare USB 2 TB hard drive yesterday. Put a GPT scheme on the drive and then used newfs to create 1 large UFS2 partition with softupdates and with journalling enabled. I then some 150 GB of data to drive. The drive in question is ugen0.3: at usbus0 umass0 on uhub8 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x4000 umass0:9:0: Attached to scbus9 da0 at umass-sim0 bus 0 scbus9 target 0 lun 0 da0: Fixed Direct Access SPC-4 SCSI device da0: Serial Number 575835314134334136333937 da0: 40.000MB/s transfers da0: 1907697MB (3906963456 512 byte sectors) da0: quirks=0x2 I just got the indicated panic while trying to do ls in a directory with 100+ files. From the panic, I have core.txt.7, info.7, and vmcore.7. info.7 contains Dump header from device: /dev/ada0p3 Architecture: amd64 Architecture Version: 2 Dump Length: 1150738432 Blocksize: 512 Dumptime: Fri Jun 16 11:47:07 2017 Hostname: troutmask.apl.washington.edu Magic: FreeBSD Kernel Dump Version String: FreeBSD 12.0-CURRENT #0 r318546: Fri May 19 12:51:04 PDT 2017 kargl@troutmask.apl.washington.edu:/data/obj/usr/src/sys/SPEW Panic String: handle_written_inodeblock: Invalid link count 57368 for inodedep 0xfffff800a56c4000 Dump Parity: 2911432532 Bounds: 7 Dump Status: good Leading portion of core.txt.7 is Unread portion of the kernel message buffer: panic: handle_written_inodeblock: Invalid link count 57368 for inodedep 0xfffff800a56c4000 cpuid = 3 time = 1497638827 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe022e2c40b0 vpanic() at vpanic+0x19c/frame 0xfffffe022e2c4130 panic() at panic+0x43/frame 0xfffffe022e2c4190 handle_written_inodeblock() at handle_written_inodeblock+0x7c9/frame 0xfffffe022e2c41e0 softdep_disk_write_complete() at softdep_disk_write_complete+0x1b4/frame 0xfffffe022e2c4240 bufdone_finish() at bufdone_finish+0x34/frame 0xfffffe022e2c42b0 bufdone() at bufdone+0x45/frame 0xfffffe022e2c42d0 g_io_deliver() at g_io_deliver+0x234/frame 0xfffffe022e2c4330 g_io_deliver() at g_io_deliver+0x234/frame 0xfffffe022e2c4390 g_disk_done() at g_disk_done+0x10d/frame 0xfffffe022e2c43e0 dadone() at dadone+0x1e21/frame 0xfffffe022e2c4960 xpt_done_process() at xpt_done_process+0x5d6/frame 0xfffffe022e2c49a0 xpt_done_td() at xpt_done_td+0x166/frame 0xfffffe022e2c49f0 fork_exit() at fork_exit+0x75/frame 0xfffffe022e2c4a30 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe022e2c4a30 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- Uptime: 27d22h21m17s (da0:umass-sim0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00 (da0:umass-sim0:0:0:0): CAM status: Resource Unavailable (da0:umass-sim0:0:0:0): Error 5, Retries exhausted (da0:umass-sim0:0:0:0): Synchronize cache failed Dumping 1097 out of 8142 MB:..2%..11%..21%..31%..41%..52%..62%..72%..81%..91% Reading symbols from /boot/kernel/radeonkms.ko...Reading symbols from /usr/lib/debug//boot/kernel/radeonkms.ko.debug...done. done. Reading symbols from /boot/kernel/drm2.ko...Reading symbols from /usr/lib/debug//boot/kernel/drm2.ko.debug...done. done. Reading symbols from /boot/kernel/agp.ko...Reading symbols from /usr/lib/debug//boot/kernel/agp.ko.debug...done. done. Reading symbols from /boot/kernel/radeonkmsfw_CAICOS_pfp.ko...Reading symbols from /usr/lib/debug//boot/kernel/radeonkmsfw_CAICOS_pfp.ko.debug...done. done. Reading symbols from /boot/kernel/radeonkmsfw_CAICOS_me.ko...Reading symbols from /usr/lib/debug//boot/kernel/radeonkmsfw_CAICOS_me.ko.debug...done. done. Reading symbols from /boot/kernel/radeonkmsfw_BTC_rlc.ko...Reading symbols from /usr/lib/debug//boot/kernel/radeonkmsfw_BTC_rlc.ko.debug...done. done. Reading symbols from /boot/kernel/radeonkmsfw_CAICOS_mc.ko...Reading symbols from /usr/lib/debug//boot/kernel/radeonkmsfw_CAICOS_mc.ko.debug...done. done. __curthread () at ./machine/pcpu.h:232 232 __asm("movq %%gs:%1,%0" : "=r" (td) (kgdb) #0 __curthread () at ./machine/pcpu.h:232 #1 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:318 #2 0xffffffff8058649b in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:386 #3 0xffffffff80586916 in vpanic (fmt=, ap=0xfffffe022e2c4170) at /usr/src/sys/kern/kern_shutdown.c:779 #4 0xffffffff80586733 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:710 #5 0xffffffff8079c1b9 in handle_written_inodeblock ( inodedep=0xfffff800a56c4000, bp=0xfffffe01f01b7a58, flags=) at /usr/src/sys/ufs/ffs/ffs_softdep.c:11535 #6 0xffffffff80782514 in softdep_disk_write_complete (bp=0xfffffe01f01b7a58) at /usr/src/sys/ufs/ffs/ffs_softdep.c:11043 #7 0xffffffff8061d2b4 in buf_complete (bp=0xfffffe01f01b7a58) at /usr/src/sys/sys/buf.h:422 #8 bufdone_finish (bp=0xfffffe01f01b7a58) at /usr/src/sys/kern/vfs_bio.c:4045 #9 0xffffffff8061d1b5 in bufdone (bp=0xfffffe01f01b7a58) at /usr/src/sys/kern/vfs_bio.c:4033 #10 0xffffffff8050df14 in g_io_deliver (bp=0xfffff80115d71bc0, error=) at /usr/src/sys/geom/geom_io.c:738 #11 0xffffffff8050df14 in g_io_deliver (bp=0xfffff801fd3b32f0, error=) at /usr/src/sys/geom/geom_io.c:738 #12 0xffffffff8050b77d in g_disk_done (bp=0xfffff8007613c2f0) at /usr/src/sys/geom/geom_disk.c:256 #13 0xffffffff802ef1b1 in dadone (periph=, done_ccb=0xfffff80068599800) at /usr/src/sys/cam/scsi/scsi_da.c:4216 #14 0xffffffff80292936 in xpt_done_process (ccb_h=0xfffff80068599800) at /usr/src/sys/cam/cam_xpt.c:5453 #15 0xffffffff80294ab6 in xpt_done_td ( arg=0xffffffff80bf9300 ) at /usr/src/sys/cam/cam_xpt.c:5480 #16 0xffffffff80553ff5 in fork_exit ( callout=0xffffffff80294950 , arg=0xffffffff80bf9300 , frame=0xfffffe022e2c4a40) at /usr/src/sys/kern/kern_fork.c:1038 #17 core.txt.7 and vmcore.7 can be made available for the asking. -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-current@freebsd.org Fri Jun 16 20:18:51 2017 Return-Path: Delivered-To: freebsd-current@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 17F91D88294 for ; Fri, 16 Jun 2017 20:18:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-16.reflexion.net [208.70.210.16]) (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 CE7286E00F for ; Fri, 16 Jun 2017 20:18:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9670 invoked from network); 16 Jun 2017 20:18:49 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 16 Jun 2017 20:18:49 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Fri, 16 Jun 2017 16:18:49 -0400 (EDT) Received: (qmail 18801 invoked from network); 16 Jun 2017 20:18:48 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 16 Jun 2017 20:18:48 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 0D83DEC9390; Fri, 16 Jun 2017 13:18:48 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: -r319936 and -r319991 TARGET_ARCH=powerpc via clang: boot1.chrp/boot1.c:(.text+0x14b8): undefined reference to `__udivdi3' (boot1.o: In function `fsread_size') [powerpc64 too] Date: Fri, 16 Jun 2017 13:18:47 -0700 References: <23CFE929-1A90-430E-A3E6-C9B56F642F8D@dsl-only.net> <732C2D2B-1533-469F-9683-A732BDE84490@dsl-only.net> To: FreeBSD Toolchain , FreeBSD PowerPC ML , FreeBSD Current In-Reply-To: <732C2D2B-1533-469F-9683-A732BDE84490@dsl-only.net> Message-Id: <87444191-89F0-4679-B412-1184E229FEB9@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 20:18:51 -0000 [Top posted note: I have submitted bugzilla 220024 for this powerpc64 and powerpc issue. It has also been reproduced when using /usr/local/powerpc64-freebsd/bin/ for binutils for a powerpc64 buildworld attempt.] On 2017-Jun-15, at 11:32 PM, Mark Millard = wrote: [powerpc64 has the same problem.] On 2017-Jun-15, at 9:34 PM, Mark Millard wrote: > [I should have listed more about my build context for clang.] >=20 > On 2017-Jun-15, at 9:20 PM, Mark Millard = wrote: >=20 >> [A gcc 4.2.1 based buildworld buildkernel did not have this problem.] >>=20 >> On 2017-Jun-15, at 5:34 PM, Mark Millard = wrote: >>=20 >>> Context: amd64 -> powerpc cross build of -r319936 >>> (one of my usual clang-based experiments): >>>=20 >>> --- all_subdir_sys --- >>> Building = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/boot/powerpc/boot1.= chrp/boot1.elf >>> --- boot1.elf --- >>> boot1.o: In function `fsread_size': >>> /usr/src/sys/boot/powerpc/boot1.chrp/boot1.c:(.text+0x14b8): = undefined reference to `__udivdi3' >>> /usr/src/sys/boot/powerpc/boot1.chrp/boot1.c:(.text+0x1508): = undefined reference to `__udivdi3' >>> cc: error: linker command failed with exit code 1 (use -v to see = invocation) >>> --- all_subdir_lib --- >>> Building = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/lib/msun/s_remquo.po >>> --- all_subdir_sys --- >>> *** [boot1.elf] Error code 1 >>>=20 >>> make[6]: stopped in /usr/src/sys/boot/powerpc/boot1.chrp >>> .ERROR_TARGET=3D'boot1.elf' >>> = .ERROR_META_FILE=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys= /boot/powerpc/boot1.chrp/boot1.elf.meta' >>>=20 >>>=20 >>> # Meta data file = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/boot/powerpc/boot1.= chrp/boot1.elf.meta >>> CMD cc -target powerpc-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp = -B/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/usr/bin = -ffreestanding -msoft-float = -I/usr/src/sys/boot/powerpc/boot1.chrp/../../common = -I/usr/src/sys/boot/powerpc/boot1.chrp/../../../ -D_STANDALONE = -std=3Dgnu99 -Qunused-arguments -nostdlib -static -Wl,-N -o boot1.elf = boot1.o ashldi3.o syncicache.o =20 >>> CWD = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/boot/powerpc/boot1.= chrp >>> TARGET boot1.elf >>> -- command output -- >>> boot1.o: In function `fsread_size': >>> /usr/src/sys/boot/powerpc/boot1.chrp/boot1.c:(.text+0x14b8): = undefined reference to `__udivdi3' >>> /usr/src/sys/boot/powerpc/boot1.chrp/boot1.c:(.text+0x1508): = undefined reference to `__udivdi3' >>> cc: error: linker command failed with exit code 1 (use -v to see = invocation) >>> *** Error code 1 >>>=20 >>> Note: This was -j16 for the build. >>>=20 >>> I updated /usr/src and amd64 to -r319991 and then >>> retried cross building for powerpc: same result. >>>=20 >>>=20 >>> Note: I'd frozen at -r317820 until this update. Back then >>> I could buildworld and buildkernel via clang (although >>> I could not boot the clang-based kernel and so had to >>> build a gcc 4.2.1 based one and use it). >>=20 >> I tried a gcc 4.2.1 buildworld buildkernel and it >> completed fine. >>=20 >> The __udivdi3 problem is clang toolchain specific. >=20 > Clang based build-context details: >=20 > # more = ~/sys_build_scripts.amd64-host/make_powerpcvtsc_nodebug_clang_bootstrap-am= d64-host.sh=20 > kldload -n filemon && \ > script = ~/sys_typescripts/typescript_make_powerpcvtsc_nodebug_clang_bootstrap-amd6= 4-host-$(date +%Y-%m-%d:%H:%M:%S) \ > env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.powerpc-clang-bootstrap.amd64-h= ost" \ > WITH_META_MODE=3Dyes \ > MAKEOBJDIRPREFIX=3D"/usr/obj/powerpcvtsc_clang" \ > make $* >=20 > # more /root/src.configs/src.conf.powerpc-clang-bootstrap.amd64-host > TO_TYPE=3Dpowerpc > # > KERNCONF=3DGENERICvtsc-NODBG > TARGET=3D${TO_TYPE} > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3D${TO_TYPE} > .export TARGET_ARCH > .endif > # > WITH_CROSS_COMPILER=3D > WITHOUT_SYSTEM_COMPILER=3D > # > WITH_LIBCPLUSPLUS=3D > WITH_BINUTILS_BOOTSTRAP=3D > WITH_ELFTOOLCHAIN_BOOTSTRAP=3D > WITH_CLANG_BOOTSTRAP=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_CLANG_EXTRAS=3D > WITH_LLD=3D > # lldb requires missing atomic 8-byte operations for powerpc (non-64) > WITHOUT_LLDB=3D > # > WITH_BOOT=3D > WITHOUT_LIB32=3D > # > WITHOUT_GCC_BOOTSTRAP=3D > WITHOUT_GCC=3D > WITHOUT_GCC_IS_CC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > # > # Use WERROR to avoid stopping at the likes of: > # error: implicit conversion from 'int' to 'int8_t' (aka 'signed = char') changes value from 128 to -128 [-Werror,-Wconstant-conversion] > WERROR=3D > MALLOC_PRODUCTION=3D > # > WITH_REPRODUCIBLE_BUILD=3D > WITH_DEBUG_FILES=3D >=20 > So the system binutils tools are in used. >=20 > Even though I build lld, last I tried lld could not > be used so it is not the linker used by the above. powerpc64 has the same buildworld problem for clang based builds: --- boot1.elf --- boot1.o: In function `fsread_size': /usr/src/sys/boot/powerpc/boot1.chrp/boot1.c:(.text+0x14b8): undefined = reference to `__udivdi3' /usr/src/sys/boot/powerpc/boot1.chrp/boot1.c:(.text+0x1508): undefined = reference to `__udivdi3' cc: error: linker command failed with exit code 1 (use -v to see = invocation) --- all_subdir_usr.sbin --- Building = /usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/usr.sbin/fstyp/ext2= fs.o --- all_subdir_sys --- *** [boot1.elf] Error code 1 make[6]: stopped in /usr/src/sys/boot/powerpc/boot1.chrp .ERROR_TARGET=3D'boot1.elf' = .ERROR_META_FILE=3D'/usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src= /sys/boot/powerpc/boot1.chrp/boot1.elf.meta' # more = /usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/sys/boot/powerpc/bo= ot1.chrp/boot1.elf.meta # Meta data file = /usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/sys/boot/powerpc/bo= ot1.chrp/boot1.elf.meta CMD cc -target powerpc64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/tmp = -B/usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/tmp/usr/bin = -ffreestanding -msoft-float = -I/usr/src/sys/boot/powerpc/boot1.chrp/../../common = -I/usr/src/sys/boot/powerpc/boot1.chrp/../../../ -D_STANDALONE -m32 = -mcpu=3Dpowerpc -m32 -mcpu=3Dpowerpc -std=3Dgnu99 -Qunused-arguments = -nostdlib -static -Wl,-N -Wl,-m -Wl,elf32ppc_fbsd -Wl,-m = -Wl,elf32ppc_fbsd -o boot1.elf boot1.o ashldi3.o syncicache.o =20 CWD = /usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/sys/boot/powerpc/bo= ot1.chrp TARGET boot1.elf -- command output -- boot1.o: In function `fsread_size': /usr/src/sys/boot/powerpc/boot1.chrp/boot1.c:(.text+0x14b8): undefined = reference to `__udivdi3' /usr/src/sys/boot/powerpc/boot1.chrp/boot1.c:(.text+0x1508): undefined = reference to `__udivdi3' cc: error: linker command failed with exit code 1 (use -v to see = invocation) *** Error code 1 # more = ~/sys_build_scripts.amd64-host/make_powerpc64vtsc_nodebug_clang-amd64-host= .sh kldload -n filemon && \ script = ~/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_clang-amd64-host-$= (date +%Y-%m-%d:%H:%M:%S) \ env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.powerpc64-clang-bootstrap.amd64= -host" \ WITH_META_MODE=3Dyes \ MAKEOBJDIRPREFIX=3D"/usr/obj/powerpc64vtsc_clang" \ make $* # more /root/src.configs/src.conf.powerpc64-clang-bootstrap.amd64-host TO_TYPE=3Dpowerpc64 # KERNCONF=3DGENERIC64vtsc-NODBG TARGET=3Dpowerpc .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD=3D WITH_LLDB=3D # WITH_BOOT=3D WITH_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D # buildkernel fails for sign mismatch on pointed-to types. WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sat Jun 17 00:01:47 2017 Return-Path: Delivered-To: freebsd-current@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 34E3DD8BE41 for ; Sat, 17 Jun 2017 00:01:47 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-16.reflexion.net [208.70.210.16]) (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 D80D774D8D for ; Sat, 17 Jun 2017 00:01:46 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31729 invoked from network); 17 Jun 2017 00:01:45 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 17 Jun 2017 00:01:45 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Fri, 16 Jun 2017 20:01:45 -0400 (EDT) Received: (qmail 28514 invoked from network); 17 Jun 2017 00:01:44 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 17 Jun 2017 00:01:44 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 258A2EC938A; Fri, 16 Jun 2017 17:01:44 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: INO64 in head: Does sys/boot/common/ufsread.c need its "typedef uint32_t ufs_ino_t;" replaced? Message-Id: <3AF2C2DB-1A61-4EC3-BCB7-B05D99273561@dsl-only.net> Date: Fri, 16 Jun 2017 17:01:43 -0700 To: kib@FreeBSD.org, FreeBSD Current , freebsd-hackers@freebsd.org, FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 00:01:47 -0000 buildworld via clang for powerpc64 and powerpc fails for lack of `__udivdi3' referenced in sys/boot/common/ufsread.c fsread_size code. But this lead to me looking around and I found a conceptually separate possible issue. . . sys/sys/_types.h : typedef __uint64_t __ino_t; /* inode number */ # find /usr/src/sys/ -exec grep __ino_t {} \; -print | more typedef __ino_t ino_t; /usr/src/sys/sys/stat.h typedef __ino_t ino_t; /* inode number */ /usr/src/sys/sys/types.h typedef __uint64_t __ino_t; /* inode number */ /usr/src/sys/sys/_types.h typedef __ino_t ino_t; /usr/src/sys/sys/dirent.h sys/boot/common/ufsread.c : . . . #include #include #include . . . typedef uint32_t ufs_ino_t; . . . Note the 32-bit type above. The headers included have use of the 64-bit ino_t type as well, for example: sys/ufs/ufs/diniode.h : . . . #define UFS_ROOTINO ((ino_t)2) . . . #define UFS_WINO ((ino_t)1) . . . sys/ufs/ffs/fs.h : . . . #define ino_to_cg(fs, x) (((ino_t)(x)) / (fs)->fs_ipg) #define ino_to_fsba(fs, x) = \ ((ufs2_daddr_t)(cgimin(fs, ino_to_cg(fs, (ino_t)(x))) + = \ (blkstofrags((fs), ((((ino_t)(x)) % (fs)->fs_ipg) / = INOPB(fs)))))) #define ino_to_fsbo(fs, x) (((ino_t)(x)) % INOPB(fs)) . . . I believe the powerpc64/powerpc issue gives evidence of ino_t being used in addition ot ufs_ino_t in sys/boot/common/ufsread.c 's fsread_size . Other things that look 32-bit inode-ish: (I do not claim to know that any of this matters.) sys/ufs/ufs/dir.h has: struct direct { u_int32_t d_ino; /* inode number of entry */ . . . struct dirtemplate { u_int32_t dot_ino; . . . u_int32_t dotdot_ino; . . . struct odirtemplate { u_int32_t dot_ino; . . . u_int32_t dotdot_ino; . . . sys/ufs/ffs/fs.h has: struct jrefrec { . . . uint32_t jr_ino; struct jmvrec { . . . uint32_t jm_ino; struct jblkrec { . . . uint32_t jb_ino; struct jtrncrec { . . . uint32_t jt_ino; =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sat Jun 17 01:59:14 2017 Return-Path: Delivered-To: freebsd-current@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 F012BD8F0AA for ; Sat, 17 Jun 2017 01:59:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-16.reflexion.net [208.70.210.16]) (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 A28BB78B7A for ; Sat, 17 Jun 2017 01:59:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1261 invoked from network); 17 Jun 2017 01:59:06 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 17 Jun 2017 01:59:06 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Fri, 16 Jun 2017 21:59:06 -0400 (EDT) Received: (qmail 30288 invoked from network); 17 Jun 2017 01:59:06 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 17 Jun 2017 01:59:06 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 180B7EC8714; Fri, 16 Jun 2017 18:59:06 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: INO64 in head: Does sys/boot/common/ufsread.c need its "typedef uint32_t ufs_ino_t;" replaced? Date: Fri, 16 Jun 2017 18:59:05 -0700 References: <3AF2C2DB-1A61-4EC3-BCB7-B05D99273561@dsl-only.net> To: kib@FreeBSD.org, FreeBSD Current , freebsd-hackers@freebsd.org, FreeBSD PowerPC ML In-Reply-To: <3AF2C2DB-1A61-4EC3-BCB7-B05D99273561@dsl-only.net> Message-Id: <700CC284-8750-448D-83DB-19C6F5CB6AE8@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 01:59:15 -0000 Top post of context note: I should have noted up front that: /usr/src/sys/boot/powerpc/boot1.chrp/boot1.c does: #include "ufsread.c" and that is the context of the __udivdi3 use that is rejected at link time when clang is used to buildworld for powerpc or pwoerpc64. My original note might really trace back to boot1.c needing to be different even if ufsread.c stays the same. === Mark Millard markmi at dsl-only.net On 2017-Jun-16, at 5:01 PM, Mark Millard wrote: buildworld via clang for powerpc64 and powerpc fails for lack of `__udivdi3' referenced in sys/boot/common/ufsread.c fsread_size code. But this lead to me looking around and I found a conceptually separate possible issue. . . sys/sys/_types.h : typedef __uint64_t __ino_t; /* inode number */ # find /usr/src/sys/ -exec grep __ino_t {} \; -print | more typedef __ino_t ino_t; /usr/src/sys/sys/stat.h typedef __ino_t ino_t; /* inode number */ /usr/src/sys/sys/types.h typedef __uint64_t __ino_t; /* inode number */ /usr/src/sys/sys/_types.h typedef __ino_t ino_t; /usr/src/sys/sys/dirent.h sys/boot/common/ufsread.c : . . . #include #include #include . . . typedef uint32_t ufs_ino_t; . . . Note the 32-bit type above. The headers included have use of the 64-bit ino_t type as well, for example: sys/ufs/ufs/diniode.h : . . . #define UFS_ROOTINO ((ino_t)2) . . . #define UFS_WINO ((ino_t)1) . . . sys/ufs/ffs/fs.h : . . . #define ino_to_cg(fs, x) (((ino_t)(x)) / (fs)->fs_ipg) #define ino_to_fsba(fs, x) \ ((ufs2_daddr_t)(cgimin(fs, ino_to_cg(fs, (ino_t)(x))) + \ (blkstofrags((fs), ((((ino_t)(x)) % (fs)->fs_ipg) / INOPB(fs)))))) #define ino_to_fsbo(fs, x) (((ino_t)(x)) % INOPB(fs)) . . . I believe the powerpc64/powerpc issue gives evidence of ino_t being used in addition ot ufs_ino_t in sys/boot/common/ufsread.c 's fsread_size . Other things that look 32-bit inode-ish: (I do not claim to know that any of this matters.) sys/ufs/ufs/dir.h has: struct direct { u_int32_t d_ino; /* inode number of entry */ . . . struct dirtemplate { u_int32_t dot_ino; . . . u_int32_t dotdot_ino; . . . struct odirtemplate { u_int32_t dot_ino; . . . u_int32_t dotdot_ino; . . . sys/ufs/ffs/fs.h has: struct jrefrec { . . . uint32_t jr_ino; struct jmvrec { . . . uint32_t jm_ino; struct jblkrec { . . . uint32_t jb_ino; struct jtrncrec { . . . uint32_t jt_ino; === Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sat Jun 17 02:48:59 2017 Return-Path: Delivered-To: freebsd-current@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 0D2AAD90B00; Sat, 17 Jun 2017 02:48:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A87AC7A6D8; Sat, 17 Jun 2017 02:48:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v5H2mptV094830 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 17 Jun 2017 05:48:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v5H2mptV094830 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v5H2moBR094829; Sat, 17 Jun 2017 05:48:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 17 Jun 2017 05:48:50 +0300 From: Konstantin Belousov To: Mark Millard Cc: FreeBSD Current , freebsd-hackers@freebsd.org, FreeBSD PowerPC ML Subject: Re: INO64 in head: Does sys/boot/common/ufsread.c need its "typedef uint32_t ufs_ino_t;" replaced? Message-ID: <20170617024850.GB2088@kib.kiev.ua> References: <3AF2C2DB-1A61-4EC3-BCB7-B05D99273561@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3AF2C2DB-1A61-4EC3-BCB7-B05D99273561@dsl-only.net> User-Agent: Mutt/1.8.2 (2017-04-18) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 02:48:59 -0000 On Fri, Jun 16, 2017 at 05:01:43PM -0700, Mark Millard wrote: > buildworld via clang for powerpc64 and powerpc fails for lack of > `__udivdi3' referenced in sys/boot/common/ufsread.c fsread_size > code. But this lead to me looking around and I found a conceptually > separate possible issue. . . > > sys/sys/_types.h : > > typedef __uint64_t __ino_t; /* inode number */ > > # find /usr/src/sys/ -exec grep __ino_t {} \; -print | more > typedef __ino_t ino_t; > /usr/src/sys/sys/stat.h > typedef __ino_t ino_t; /* inode number */ > /usr/src/sys/sys/types.h > typedef __uint64_t __ino_t; /* inode number */ > /usr/src/sys/sys/_types.h > typedef __ino_t ino_t; > /usr/src/sys/sys/dirent.h > > > sys/boot/common/ufsread.c : > > . . . > #include > #include > #include > . . . > typedef uint32_t ufs_ino_t; > . . . > > Note the 32-bit type above. The headers included > have use of the 64-bit ino_t type as well, for > example: > > sys/ufs/ufs/diniode.h : > > . . . > #define UFS_ROOTINO ((ino_t)2) > . . . > #define UFS_WINO ((ino_t)1) > . . . > > sys/ufs/ffs/fs.h : > > . . . > #define ino_to_cg(fs, x) (((ino_t)(x)) / (fs)->fs_ipg) > #define ino_to_fsba(fs, x) \ > ((ufs2_daddr_t)(cgimin(fs, ino_to_cg(fs, (ino_t)(x))) + \ > (blkstofrags((fs), ((((ino_t)(x)) % (fs)->fs_ipg) / INOPB(fs)))))) > #define ino_to_fsbo(fs, x) (((ino_t)(x)) % INOPB(fs)) > . . . > > > I believe the powerpc64/powerpc issue > gives evidence of ino_t being used in > addition ot ufs_ino_t in > sys/boot/common/ufsread.c 's fsread_size . > > > Other things that look 32-bit inode-ish: > (I do not claim to know that any of this > matters.) > > sys/ufs/ufs/dir.h has: > > struct direct { > u_int32_t d_ino; /* inode number of entry */ > . . . > struct dirtemplate { > u_int32_t dot_ino; > . . . > u_int32_t dotdot_ino; > . . . > > struct odirtemplate { > u_int32_t dot_ino; > . . . > u_int32_t dotdot_ino; > . . . > > > sys/ufs/ffs/fs.h has: > > struct jrefrec { > . . . > uint32_t jr_ino; > > struct jmvrec { > . . . > uint32_t jm_ino; > > struct jblkrec { > . . . > uint32_t jb_ino; > > struct jtrncrec { > . . . > uint32_t jt_ino; UFS uses 32bit inodes, changing to 64bit is both pointless currently, and causes on-disk layout incompatibilities. As a consequence, use of ino_t (64bit) or uint32_t for inode numbers are almost always interchangeable, unless used for specifying on-disk layout. UFS correctly uses (and was changed to use) uint32_t for inode numbers in the disk-layout definitions. Other places, which calculate inode numbers from inode block numbers, or do some other calculations with inodes, are fine with either width. That is, I believe that all instances which I looked at during the ino64 preparation are fine. From owner-freebsd-current@freebsd.org Sat Jun 17 03:54:13 2017 Return-Path: Delivered-To: freebsd-current@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 DEE49BEE23F for ; Sat, 17 Jun 2017 03:54:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-16.reflexion.net [208.70.210.16]) (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 777AA7D4C3 for ; Sat, 17 Jun 2017 03:54:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18573 invoked from network); 17 Jun 2017 03:54:11 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 17 Jun 2017 03:54:11 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Fri, 16 Jun 2017 23:54:11 -0400 (EDT) Received: (qmail 16225 invoked from network); 17 Jun 2017 03:54:11 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 17 Jun 2017 03:54:11 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id CF334EC8A8B; Fri, 16 Jun 2017 20:54:10 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: INO64 in head: Does sys/boot/common/ufsread.c need its "typedef uint32_t ufs_ino_t;" replaced? From: Mark Millard In-Reply-To: <20170617024850.GB2088@kib.kiev.ua> Date: Fri, 16 Jun 2017 20:54:10 -0700 Cc: FreeBSD Current , freebsd-hackers@freebsd.org, FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <73F88E18-37A1-47C6-8783-F51F131A9671@dsl-only.net> References: <3AF2C2DB-1A61-4EC3-BCB7-B05D99273561@dsl-only.net> <20170617024850.GB2088@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 03:54:14 -0000 On 2017-Jun-16, at 7:48 PM, Konstantin Belousov = wrote: > On Fri, Jun 16, 2017 at 05:01:43PM -0700, Mark Millard wrote: >> . . . >=20 > UFS uses 32bit inodes, changing to 64bit is both pointless currently, = and > causes on-disk layout incompatibilities. >=20 > As a consequence, use of ino_t (64bit) or uint32_t for inode numbers = are > almost always interchangeable, unless used for specifying on-disk = layout. > UFS correctly uses (and was changed to use) uint32_t for inode numbers > in the disk-layout definitions. Other places, which calculate inode > numbers from inode block numbers, or do some other calculations with > inodes, are fine with either width. >=20 > That is, I believe that all instances which I looked at during the > ino64 preparation are fine. Thanks for letting me know --and good to know. I've added a note to the bugzilla report of the failed linking of boot1.elf for powerpc and powerpc64 that you have indicated that if the __udivdi3 is supplied to allow the linking to complete for builds based on clang then the result should operate okay for the mix of types. (The report is bugzilla 220024 .) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sat Jun 17 08:06:43 2017 Return-Path: Delivered-To: freebsd-current@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 7E01EBF454E for ; Sat, 17 Jun 2017 08:06:43 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (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 50A2E83C88 for ; Sat, 17 Jun 2017 08:06:43 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-pg0-x230.google.com with SMTP id f185so29351918pgc.0 for ; Sat, 17 Jun 2017 01:06:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ZsrDxo628krm6+whF0AgLIKJ5lUwy/IE9RHn6DszEXY=; b=fzabkwM0dJ0GNJtd/nZ4gimx6ViqG9hRZmPffymUSIvRM32tgM28uknbA198tqWR0f iHS7qCIGuTSH1JgKS70/jTG/tPsrWy/CvF0T+SpdzbamZk3+1RSdg9G/drh6/D1dKE31 T+58V9zudvi6zRtnCScZ+oVnJLDE43yTiBEvboNSgoOqsY7DXM7joz3BHguALYovmMqD aLwQeCIsPzPM3aZRNajQv2aJIM9T+Xf3O8EHr8ibatYkfVbFh9Yk6ZaWjE7zc9tsJgyM CszXB6LZQUgrxzu5wtAxEcvAFeri6owOq3wRRIQNrvLI1ogF55up3jCWValJqX5aD+mf BT4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ZsrDxo628krm6+whF0AgLIKJ5lUwy/IE9RHn6DszEXY=; b=hAKdh5ItReB/Fz78y2R3ayM5UEAo9iOQcssaiqccRj7X3h8BO8CawZauVPF81ZQuSv Jgrz9TMJvqPG59uJ+0ed1Eq9R0xxedKbw7Dz/m2bA5xW5OV+6h0xOG1CU1qUL+VaDxPS ax21bHIiGrRCgAPy23R4XlbL4ecuhWTj06v6V3xJCtqHCGI27M2L0hJUaE2jpJTwaKO2 jIrVxNm7KYqrDzykoiI7Ivufz3RuzEB0MasVi4b6AqK7zbGtqrnw0qBbJWAqSsjyWCxc 9P+Fl2jbdJVXzgs+WAvpO58GPmgI/TbR+U26guQ2MNmWO5FvYyF66KapTh06n+bWQoH8 vIiQ== X-Gm-Message-State: AKS2vOx2Wi/6MW04ds9+FZVpNh/q9Va6BUsf4rCzk9AwrhTbr8/P3Sc/ TM1yWEF591L8gyFw0IMiIMSNN9rpLpK7 X-Received: by 10.99.165.78 with SMTP id r14mr15868167pgu.74.1497686802214; Sat, 17 Jun 2017 01:06:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.162.5 with HTTP; Sat, 17 Jun 2017 01:06:41 -0700 (PDT) From: blubee blubeeme Date: Sat, 17 Jun 2017 16:06:41 +0800 Message-ID: Subject: autotools failing To: FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 08:06:43 -0000 Hi I just started to run into this problem with autotools. I am getting this error running autoreconf -fi here's the end of the output before unsuccessful exit: --------------------------------------------------------------------------------------- configure.ac:54: error: possibly undefined macro: AS_IF If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:56: error: possibly undefined macro: AC_MSG_NOTICE configure.ac:221: error: possibly undefined macro: AC_MSG_ERROR autoreconf-2.69: /usr/local/bin/autoconf-2.69 failed with exit status: 1 --------------------------------------------------------------------------------------- ===== installed packages ========= Coin-3.1.3_11 = FreeCAD-0.17.g20170310_4 = ORBit2-2.14.19_2 = SoQt-1.5.0_6 = adwaita-icon-theme-3.22.0 = alsa-lib-1.1.2 = alsa-plugins-1.1.1_1 = apiextractor-0.10.10_3 = appres-1.0.4 = apr-1.5.2.1.5.4_2 = arandr-0.1.9 = argyllcms-1.9.2_1 = at-spi2-atk-2.24.0 = at-spi2-core-2.24.0 = atk-2.24.0 = autoconf-2.69_1 = autoconf-wrapper-20131203 = autoconf213-2.13.000227_6 = automake-1.15_1 = automake-wrapper-20131203 = autotools-20130627 = avahi-app-0.6.31_5 = bash-4.4.12_2 = binutils-2.28,1 = bison-3.0.4,1 = bitmap-1.0.8 = blas-3.5.0_3 = boost-all-1.64.0 = boost-docs-1.64.0 = boost-jam-1.64.0 = boost-libs-1.64.0 = boost-python-libs-1.64.0 = ca_root_nss-3.31 = cairo-1.14.8_1,2 = cargo-0.17.0 = cblas-1.0_6 = chromium-58.0.3029.110_2 = cmake-3.8.2 = cmake-modules-3.8.2 = colord-1.2.12 = compositeproto-0.4.2 = compton-20160907_2 = cups-2.2.3 = curl-7.54.0 < cvsps-2.1_2 = damageproto-1.2.1 = db5-5.3.28_6 = dbus-1.10.16_1 = dbus-glib-0.108 = dconf-0.24.0_1 = dejavu-2.37 = desktop-file-utils-0.23 = dialog4ports-0.1.6 = dmenu-4.7 = dmxproto-2.3.1 = dotconf-1.3_1 = dri2proto-2.8 = dri3proto-1.0 = droid-fonts-ttf-20131024_3 = dunst-1.1.0 = encodings-1.0.4_3,1 = espeak-1.48.04_2 = expat-2.2.0_1 = feh-2.18 = ffmpeg-3.3.2,1 = firefox-54.0,1 = firefox-i18n-54.0 = fixesproto-5.0 = flac-1.3.2 = font-adobe-100dpi-1.0.3_3 = font-adobe-75dpi-1.0.3_3 = font-adobe-utopia-100dpi-1.0.4_3 = font-adobe-utopia-75dpi-1.0.4_3 = font-adobe-utopia-type1-1.0.4_3 = font-alias-1.0.3_3 = font-arabic-misc-1.0.3_3 = font-bh-100dpi-1.0.3_3 = font-bh-75dpi-1.0.3_3 = font-bh-lucidatypewriter-100dpi-1.0.3_3 = font-bh-lucidatypewriter-75dpi-1.0.3_3 = font-bh-ttf-1.0.3_3 = font-bh-type1-1.0.3_3 = font-bitstream-100dpi-1.0.3_3 = font-bitstream-75dpi-1.0.3_3 = font-bitstream-type1-1.0.3_3 = font-cronyx-cyrillic-1.0.3_3 = font-cursor-misc-1.0.3_3 = font-daewoo-misc-1.0.3_3 = font-dec-misc-1.0.3_3 = font-ibm-type1-1.0.3_3 = font-isas-misc-1.0.3_3 = font-jis-misc-1.0.3_3 = font-micro-misc-1.0.3_3 = font-misc-cyrillic-1.0.3_3 = font-misc-ethiopic-1.0.3_3 = font-misc-meltho-1.0.3_3 = font-misc-misc-1.1.2_3 = font-mutt-misc-1.0.3_3 = font-schumacher-misc-1.1.2_3 = font-screen-cyrillic-1.0.4_3 = font-sony-misc-1.0.3_3 = font-sun-misc-1.0.3_3 = font-util-1.3.1 = font-winitzki-cyrillic-1.0.3_3 = font-xfree86-type1-1.0.4_3 = fontcacheproto-0.1.3 = fontconfig-2.12.1,1 = fontsproto-2.1.3,1 = fr-med-3.2.0_2 = freeimage-3.16.0_2 = freetype2-2.8 = ftgl-2.1.3.r5_6,1 = gcc-ecj-4.5 = gcc5-5.4.0_2 = gconf2-3.2.6_5 = gdbm-1.13 = gdk-pixbuf2-2.36.6 = generatorrunner-0.6.16_1 = gettext-runtime-0.19.8.1_1 = gettext-tools-0.19.8.1 = giflib-5.1.4 = git-2.13.1_1 = gl2ps-1.3.9_1 = glib-2.50.2_2,1 = glproto-1.4.17 = gmake-4.2.1_1 = gmp-6.1.2 = gnome_subr-1.0 = gnutls-3.5.13 = gobject-introspection-1.50.0,1 = graphite2-1.3.10 = gstreamer-0.10.36_6 = gstreamer-plugins-0.10.36_8,3 = gtk-update-icon-cache-2.24.29 = gtk2-2.24.31 = gtk3-3.22.15 = harfbuzz-1.4.6_1 = harfbuzz-icu-1.4.6_1 = hdf-szip-2.1_2 = hdf5-1.10.1 = hdf5-18-1.8.18_2 = help2man-1.47.4 = hicolor-icon-theme-0.15 = hunspell-1.6.1 = i3-4.13 = i3status-2.11_1 = ibus-1.5.14_2 = iceauth-1.0.7 = icu-58.2_2,1 = imlib2-1.4.9,2 = indexinfo-0.2.6 = inputproto-2.3.2 = intltool-0.51.0_1 = irssi-1.0.3,1 = iso-codes-3.75 = jasper-1.900.1_17 = jbigkit-2.1_1 = jpeg-turbo-1.5.1 = jsoncpp-1.8.0_2 = kbproto-1.0.7 = lapack-3.5.0_2 = lcms2-2.8 = libFS-1.0.7 = libGLU-9.0.0_3 = libICE-1.0.9_1,1 = libIDL-0.8.14_3 = libSM-1.2.2_3,1 = libX11-1.6.5,1 = libXScrnSaver-1.2.2_3 = libXTrap-1.0.1_3 = libXau-1.0.8_3 = libXaw-1.0.13,2 = libXcomposite-0.4.4_3,1 = libXcursor-1.1.14_3 = libXdamage-1.1.4_3 = libXdmcp-1.1.2 = libXevie-1.0.3_3 = libXext-1.3.3_1,1 = libXfixes-5.0.3 = libXfont-1.5.2,2 = libXfontcache-1.0.5_3 = libXft-2.3.2_1 = libXi-1.7.9,1 = libXinerama-1.1.3_3,1 = libXmu-1.1.2_3,1 = libXp-1.0.3,1 = libXpm-3.5.12 = libXrandr-1.5.1 = libXrender-0.9.10 = libXres-1.0.7_3 = libXt-1.1.5,1 = libXtst-1.2.3 = libXv-1.0.11,1 = libXvMC-1.0.10 = libXxf86dga-1.1.4_3 = libXxf86misc-1.0.3_3 = libXxf86vm-1.1.4_1 = libarchive-3.3.1,1 = libarea-20160313_3 = libconfig-1.4.9_1 = libconfuse-2.7_2 = libcroco-0.6.11 = libdaemon-0.14_1 = libdmx-1.1.3_3 = libdrm-2.4.81,1 = libedit-3.1.20170329_2,1 = libepoxy-1.4.3 = libev-4.22,1 = libevent-2.1.8 = libexif-0.6.21_4 = libffi-3.2.1 = libfontenc-1.1.3_1 = libgcrypt-1.7.7 = libglade2-2.6.4_8 = libgnome-keyring-3.12.0_2 = libgpg-error-1.27 = libgsf-1.14.41 = libiconv-1.14_10 = libid3tag-0.15.1b_1 = libidn2-2.0.2 = libltdl-2.4.6 = liblz4-1.7.5,1 = libnghttp2-1.23.1 = libnotify-0.7.7 = libogg-1.3.2_2,4 = liboldX-1.0.1_3 = libpaper-1.1.24.4 = libpci-3.5.4 = libpciaccess-0.13.5 = libpthread-stubs-0.4 = librsvg2-2.40.17 = libsndfile-1.0.28 = libssh2-1.8.0,3 = libtasn1-4.12 = libtermkey-0.20 = libtheora-1.1.1_7 = libtool-2.4.6 = libunistring-0.9.7 = libunwind-20170113_1 = libuv-1.12.0 = libv4l-1.6.3_2 = libva-1.8.2 = libvdpau-1.1.1 = libvorbis-1.3.5_1,3 = libvpx-1.6.1_1 = libvterm-git20161218 = libx264-0.148.2728_1 = libxcb-1.12_2 = libxdg-basedir-1.2.0_1 = libxkbcommon-0.7.1 = libxkbfile-1.0.9 = libxkbui-1.0.2_4 = libxml2-2.9.4 = libxshmfence-1.2_1 = libxslt-1.1.29_1 = linux-c6-expat-2.0.1_5 = linux-c6-fontconfig-2.8.0_3 = linux-c6-xorg-libs-7.4_9 = linux_base-c6-6.9 = llvm40-4.0.1.r1_5 = luajit-2.0.5 = luit-1.1.1_1 = lzo2-2.10_1 = m4-1.4.18,1 = mesa-dri-17.1.1 = mesa-libs-17.1.1 = mkfontdir-1.0.7 = mkfontscale-1.1.2 = mpc-1.0.3 = mpfr-3.1.5_1 = msgpack-1.4.2_2 = neovim-0.2.0 = nettle-3.3 = nspr-4.15 = nss-3.31 = nvidia-driver-375.66 = nvidia-xconfig-378.13 = openal-soft-1.17.2_2 = openblas-0.2.19_1,1 = opencascade-6.9.1_9 = opencv-core-2.4.13.1_1 = orc-0.4.25 = p11-kit-0.23.7 = p5-AnyEvent-7.13,1 = p5-AnyEvent-I3-0.17 = p5-Authen-SASL-2.16_1 = p5-Digest-HMAC-1.03_1 = p5-Error-0.17024 = p5-GSSAPI-0.28_1 = p5-IO-Tty-1.12_2 = p5-IPC-Run-0.96 = p5-JSON-XS-3.03 = p5-Locale-gettext-1.07 = p5-Try-Tiny-0.24 = p5-Types-Serialiser-1.0_1 = p5-XML-Parser-2.44 = p5-common-sense-3.74 = pango-1.40.6 = pastebinit-1.5_1 = pciids-20170525 = pcre-8.40 = perl5-5.24.1_1 = phonon-4.9.1_1 = pivy-0.5.0 = pixman-0.34.0 = pkg-1.10.1 = pkgconf-1.3.7,1 = png-1.6.29 = polkit-0.113_5 = portaudio-19.20140130_6 = printproto-1.0.5 = py27-backports_abc-0.5 = py27-cairo-1.10.0_2 = py27-certifi-2017.4.17 = py27-configobj-5.0.6_1 = py27-cycler-0.10.0 = py27-dateutil-2.6.0_1 = py27-dbus-1.2.0_1 = py27-gobject-2.28.6_7 = py27-gobject3-3.18.2 = py27-gtk2-2.24.0_4 = py27-matplotlib-1.5.3_2 = py27-notify-0.1.1_11 = py27-numpy-1.11.2_3,1 = py27-pyparsing-2.2.0 = py27-pytz-2016.10,1 = py27-setuptools-36.0.1 = py27-singledispatch-3.4.0.3_1 = py27-six-1.10.0 = py27-sqlite3-2.7.13_7 = py27-tkinter-2.7.13_6 = py27-tornado-4.5.1 = py27-xdg-0.25_1 = pydbus-common-1.2.0_1 = pygobject3-common-3.18.2 = pyside-py27-1.2.2_1 = python-2.7_3,2 = python2-2_3 = python27-2.7.13_4 = python3-3_3 = python36-3.6.1_2 = qt4-assistant-4.8.7_1 = qt4-clucene-4.8.7_1 = qt4-corelib-4.8.7_8 = qt4-dbus-4.8.7_1 = qt4-declarative-4.8.7_1 = qt4-designer-4.8.7_1 = qt4-doc-4.8.7_1 = qt4-gui-4.8.7_3 = qt4-help-4.8.7_2 = qt4-multimedia-4.8.7_2 = qt4-network-4.8.7_3 = qt4-opengl-4.8.7_3 = qt4-qt3support-4.8.7_2 = qt4-script-4.8.7_2 = qt4-scripttools-4.8.7_1 = qt4-sql-4.8.7_2 = qt4-sqlite-plugin-4.8.7_4 = qt4-svg-4.8.7_2 = qt4-testlib-4.8.7_2 = qt4-webkit-4.8.7_2 = qt4-xml-4.8.7_2 = qt4-xmlpatterns-4.8.7_2 = qtchooser-39 = qzeitgeist-0.8.0_2 = randrproto-1.5.0 = re2-20170301 = readline-6.3.8_1 = recordproto-1.14.2 = renderproto-0.11.1 = rhash-1.3.4 = rust-1.18.0 = rxvt-unicode-9.22 = s2tc-1.0+20151228 = schroedinger-1.0.11_4 = scrnsaverproto-1.2.2 = serf-1.3.9_1 = sessreg-1.1.1 = setxkbmap-1.3.1 = shared-mime-info-1.8 = shiboken-1.2.2_2 = simage-1.7.0_6 = smproxy-1.0.6 = snappy-1.1.4 = speech-dispatcher-0.8.6 = speex-1.2.0,1 = speexdsp-1.2.r3_1 = spidermonkey170-17.0.0_6 = sqlite3-3.19.3 = startup-notification-0.12_4 = subversion-1.9.5 = sudo-1.8.20p2 < suitesparse-4.0.2_6 = tbb-2017.5 = tcl86-8.6.6_2 = texinfo-6.3_2,1 = tiff-4.0.8 = tk86-8.6.6 = tpm-emulator-0.7.4_2 = trapproto-3.4.3 = trousers-0.3.14_1 = twm-1.0.9 = unibilium-1.2.0 = unzip-6.0_7 = v4l_compat-1.6.3 = videoproto-2.3.3 = vtk6-6.2.0_5 = webp-0.6.0_3 = x11perf-1.6.0 = x265-2.3 = xauth-1.0.10 = xbacklight-1.2.1_1 = xbitmaps-1.1.1 = xcalc-1.0.6_2 = xcb-util-0.4.0_2,1 = xcb-util-cursor-0.1.3 = xcb-util-image-0.4.0_1 = xcb-util-keysyms-0.4.0_1 = xcb-util-renderutil-0.3.9_1 = xcb-util-wm-0.4.1_3 = xcb-util-xrm-1.0 = xclock-1.0.7_2 = xcmsdb-1.0.5 = xconsole-1.0.7_1 = xcursor-themes-1.0.4_1 = xcursorgen-1.0.6_1 = xdg-utils-1.1.1 = xdpyinfo-1.3.2 = xdriinfo-1.0.5_1 = xerces-c3-3.1.4 = xev-1.2.2 = xextproto-7.3.0 = xf86-input-keyboard-1.9.0_1 = xf86-input-mouse-1.9.2_1 = xf86-video-scfb-0.0.4_5 = xf86-video-vesa-2.3.4_1 = xf86dga-1.0.3_1 = xf86dgaproto-2.1 = xf86miscproto-0.9.3 = xf86vidmodeproto-2.3.1 = xgamma-1.0.6 = xgc-1.0.5 = xhost-1.0.7 = xineramaproto-1.2.1 = xinit-1.3.4,1 = xinput-1.6.2 = xkbcomp-1.4.0 = xkbevd-1.1.4 = xkbutils-1.0.4 = xkeyboard-config-2.21 = xkill-1.0.4 = xlsatoms-1.1.2 = xlsclients-1.1.3 = xmessage-1.0.4 = xmlcatmgr-2.2_2 = xmodmap-1.0.9 = xorg-7.7_3 = xorg-apps-7.7_2 = xorg-docs-1.7.1,1 = xorg-drivers-7.7_5 = xorg-fonts-7.7_1 = xorg-fonts-100dpi-7.7 = xorg-fonts-75dpi-7.7 = xorg-fonts-cyrillic-7.7 = xorg-fonts-miscbitmaps-7.7 = xorg-fonts-truetype-7.7_1 = xorg-fonts-type1-7.7 = xorg-libraries-7.7_2 = xorg-macros-1.19.1 = xorg-server-1.18.4_1,1 = xpi-quick-locale-switcher-1.7.8.5 = xpr-1.0.4 = xprop-1.2.2 = xproto-7.0.31 = xrandr-1.5.0 = xrdb-1.1.0 = xrefresh-1.0.5 = xset-1.2.3_1 = xsetmode-1.0.0 = xsetroot-1.1.1 = xterm-329 = xtrans-1.3.5 = xvid-1.3.4,1 = xvinfo-1.1.3 = xwd-1.0.6 = xwininfo-1.1.3_2 = xwud-1.0.4 = yajl-2.1.0 = yasm-1.3.0 = zh-ibus-chewing-1.5.1 = zh-ibus-pinyin-1.5.0_4 = zh-libchewing-0.5.1 = zh-pyzy-0.1.0_4 = zip-3.0_1 = From owner-freebsd-current@freebsd.org Sat Jun 17 10:24:15 2017 Return-Path: Delivered-To: freebsd-current@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 50DC8BF776F; Sat, 17 Jun 2017 10:24:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CDCC764346; Sat, 17 Jun 2017 10:24:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v5HAO7ZE096948 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 17 Jun 2017 13:24:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v5HAO7ZE096948 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v5HAO79w096947; Sat, 17 Jun 2017 13:24:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 17 Jun 2017 13:24:07 +0300 From: Konstantin Belousov To: Mark Millard Cc: FreeBSD Current , freebsd-hackers@freebsd.org, FreeBSD PowerPC ML Subject: Re: INO64 in head: Does sys/boot/common/ufsread.c need its "typedef uint32_t ufs_ino_t;" replaced? Message-ID: <20170617102407.GD2088@kib.kiev.ua> References: <3AF2C2DB-1A61-4EC3-BCB7-B05D99273561@dsl-only.net> <20170617024850.GB2088@kib.kiev.ua> <73F88E18-37A1-47C6-8783-F51F131A9671@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <73F88E18-37A1-47C6-8783-F51F131A9671@dsl-only.net> User-Agent: Mutt/1.8.2 (2017-04-18) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 10:24:15 -0000 On Fri, Jun 16, 2017 at 08:54:10PM -0700, Mark Millard wrote: > On 2017-Jun-16, at 7:48 PM, Konstantin Belousov wrote: > > > On Fri, Jun 16, 2017 at 05:01:43PM -0700, Mark Millard wrote: > >> . . . > > > > UFS uses 32bit inodes, changing to 64bit is both pointless currently, and > > causes on-disk layout incompatibilities. > > > > As a consequence, use of ino_t (64bit) or uint32_t for inode numbers are > > almost always interchangeable, unless used for specifying on-disk layout. > > UFS correctly uses (and was changed to use) uint32_t for inode numbers > > in the disk-layout definitions. Other places, which calculate inode > > numbers from inode block numbers, or do some other calculations with > > inodes, are fine with either width. > > > > That is, I believe that all instances which I looked at during the > > ino64 preparation are fine. > > Thanks for letting me know --and good to know. > > I've added a note to the bugzilla report of the failed > linking of boot1.elf for powerpc and powerpc64 that > you have indicated that if the __udivdi3 is supplied to > allow the linking to complete for builds based on clang > then the result should operate okay for the mix of types. > (The report is bugzilla 220024 .) I never said that. From owner-freebsd-current@freebsd.org Sat Jun 17 10:53:01 2017 Return-Path: Delivered-To: freebsd-current@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 EFE44BF7F16 for ; Sat, 17 Jun 2017 10:53:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-16.reflexion.net [208.70.210.16]) (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 967E7651CE for ; Sat, 17 Jun 2017 10:53:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25388 invoked from network); 17 Jun 2017 10:53:00 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 17 Jun 2017 10:53:00 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Sat, 17 Jun 2017 06:53:00 -0400 (EDT) Received: (qmail 30304 invoked from network); 17 Jun 2017 10:52:59 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 17 Jun 2017 10:52:59 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 247CAEC8714; Sat, 17 Jun 2017 03:52:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: INO64 in head: Does sys/boot/common/ufsread.c need its "typedef uint32_t ufs_ino_t;" replaced? From: Mark Millard In-Reply-To: <20170617102407.GD2088@kib.kiev.ua> Date: Sat, 17 Jun 2017 03:52:58 -0700 Cc: FreeBSD Current , freebsd-hackers@freebsd.org, FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <063A0C56-E9D5-4C84-AD15-B36F267F00BA@dsl-only.net> References: <3AF2C2DB-1A61-4EC3-BCB7-B05D99273561@dsl-only.net> <20170617024850.GB2088@kib.kiev.ua> <73F88E18-37A1-47C6-8783-F51F131A9671@dsl-only.net> <20170617102407.GD2088@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 10:53:02 -0000 On 2017-Jun-17, at 3:24 AM, Konstantin Belousov = wrote: > On Fri, Jun 16, 2017 at 08:54:10PM -0700, Mark Millard wrote: >> On 2017-Jun-16, at 7:48 PM, Konstantin Belousov wrote: >>=20 >>> On Fri, Jun 16, 2017 at 05:01:43PM -0700, Mark Millard wrote: >>>> . . . >>>=20 >>> UFS uses 32bit inodes, changing to 64bit is both pointless = currently, and >>> causes on-disk layout incompatibilities. >>>=20 >>> As a consequence, use of ino_t (64bit) or uint32_t for inode numbers = are >>> almost always interchangeable, unless used for specifying on-disk = layout. >>> UFS correctly uses (and was changed to use) uint32_t for inode = numbers >>> in the disk-layout definitions. Other places, which calculate inode >>> numbers from inode block numbers, or do some other calculations with >>> inodes, are fine with either width. >>>=20 >>> That is, I believe that all instances which I looked at during the >>> ino64 preparation are fine. >>=20 >> Thanks for letting me know --and good to know. >>=20 >> I've added a note to the bugzilla report of the failed >> linking of boot1.elf for powerpc and powerpc64 that >> you have indicated that if the __udivdi3 is supplied to >> allow the linking to complete for builds based on clang >> then the result should operate okay for the mix of types. >> (The report is bugzilla 220024 .) > I never said that. Sorry. I apparently read too much of my=20 overall purpose into your reply to what I asked about for if the types needed to be changed in fsread.c . I've reported the "I never said that" in 220024. I've also copied and pasted your original reply for reference. Again: Sorry to have misrepresented you. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sat Jun 17 20:20:59 2017 Return-Path: Delivered-To: freebsd-current@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 272BFC089FE for ; Sat, 17 Jun 2017 20:20:59 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9992376D3E for ; Sat, 17 Jun 2017 20:20:57 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([85.179.173.20]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MHH6Z-1dZqbK2A0R-00E5uX for ; Sat, 17 Jun 2017 22:20:49 +0200 Date: Sat, 17 Jun 2017 22:20:42 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: igb0: core crash (if_io_tqg_0) VLAN Message-ID: <20170617222042.6a9d8cb5@thor.intern.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/EEdIE7L7dVHGiys0.9_Vpo="; protocol="application/pgp-signature" X-Provags-ID: V03:K0:EuPusk0MryW55pjPEGNSf/QP5sgvCpFzTslDkH3Q+Fs8kARNGg9 AcGujHc3TF7wgqIeR9ZeF5kJ4hdGs7LDN6b8s7Nw7Yu+Dg0+ltSDc2/CNwGwY4aedthcXw1 +DBXEjfV8qS/2mVqxG1WJcbICoUIUw9NgFf1YaqlyhHeFbbpBsIS8L4Y9Int8f69MpnGlwr WZmTR073lpNzftm8p8pdw== X-UI-Out-Filterresults: notjunk:1;V01:K0:9ApzNwCy2gY=:mW3HX40tHUFSoUoF4fVk+A bPagkzVpbupUDqW3j3pPfWO0Wl+mHmtWJP44oQgEjLuXqUChQu1YgScKfVbQ2gpiekwHPxOHf PBpkgcYPXaLmKvir2IlK91wogYtwBO6APLq74jdEZEHMvz/cIWiNEbCysWpuph+8E44ri5Vh0 9sVlastOBSWmNxFlJKZSZPbSXEPrC1+wMs7YSOPsUANuBHguMms8jJdR+gGFpyP9QAVokQWUI Ow/CMJGFx69mMKk3FxEywlzGc9zmu7yK2cV15n4AANL++OUuFy/2s4T1IeOaIMH+hm3RdfyY+ aPUDoRrEJdMzVSWjrBTRMdnwSQGWYdeDpkQOratZrZN77BbXxdBHdYc+1YjiqXtG/obocvSA+ OvzfqYpWeiv603a9NG8P4JRRLQFsghwAivsAFLY0HsIsfAQILJUfoyHr6PbafSrcHEmDkcfkD m3Kux1RBYJ4UZDwHR/bUZ9D8XRGZCmHcWbuSrFWpmpVgdt8SBBSjMcM86S7LkPy0dSNI+0TlO 0EYqFgaCv1hQcnnIJXnM1SDPsfvqF94k2lsgZR50P6YGDMYGa5Xkia+LsjHAQonEePLMLNumY br5R2Un7y71lYXRJfe8l0xNZE7DB7PSE6gGdPHBnMLRfxJiOSBsvfCOOqkGeAYMdczdCAT2Gq V1cCTQdu3ocRrDINENUXuJNy8A3l9Weake4a5NXuLxtsKfA2zQ5J61TQVpPKmxicgqgtlzjn+ 2OvOTKXkJR0ky0DDX0bUvar6Ujh486byYSn9rj9EoEUMONPDfFPvzPGrHC4= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 20:20:59 -0000 --Sig_/EEdIE7L7dVHGiys0.9_Vpo= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Running CURRENT (FreeBSD 12.0-CURRENT #0 r320050: Sat Jun 17 11:03:50 CEST = 2017 amd64) on PCengines APU 2C4: CPU: AMD GX-412TC SOC with recent Sea BIOS. The APU is configured as a small router. The tun0 device is spawned from ig= b0 and bound to ppp (providing the conenction to my ISP). igb1 is the internal NIC and it is a Intel i210, identified as igb1. The NI= C is configured to bear a also a VLAN called igb1.2 providing a dedicated VoIP n= etwork framework on which I'm working for some tests. So far, that setup worked wi= t a 12-CURRENT roughly two weeks old - I don't have the revison at hand. Firewall is IPFW. The very moment I plug in the uplink to the switch, the APU goes down with = an coredump: Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x0 fault code =3D supervisor write data, page not present instruction pointer =3D 0x20:0xffffffff8068b5c0 stack pointer =3D 0x28:0xfffffe0126762920 frame pointer =3D 0x28:0xfffffe01267629f0 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D= interrupt enabled, resume, IOPL =3D 0 current process =3D 0 (if_io_tqg_0) trap number =3D= 12 panic: page fault cpuid =3D 0 time =3D 1497723644 Uptime: 21s Dumping 253 out of 4063 MB:..7%..13%..26%..32%..45%..51%..64%..76%..82%..95% Dump complete PCEngines apu2 coreboot build 20170228 4080 MB ECC DRAM SeaBIOS (version rel-1.10.0= .1) Press F10 key now for boot = menu --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/EEdIE7L7dVHGiys0.9_Vpo= Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWUWPGgAKCRDS528fyFhY lKXQAf95nprky6FbAMHcM4HYXb7MpIGtvf1bptJOmfPoIfHSK8YyZ+BZg72Rx3R8 npHoG0DfoKgAudRqOYaBF8880L/7Af4tjGBLzNjER/DT69ThnUhlzht8rJXBgBOP Rp23KAsNP+MAtQKLE3Y6SpdvTPDn37o/UTvrVv1Ut9Vh4fGhLYw8 =QrnV -----END PGP SIGNATURE----- --Sig_/EEdIE7L7dVHGiys0.9_Vpo=-- From owner-freebsd-current@freebsd.org Sat Jun 17 21:15:30 2017 Return-Path: Delivered-To: freebsd-current@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 C8C21C0988D for ; Sat, 17 Jun 2017 21:15:30 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4862678195 for ; Sat, 17 Jun 2017 21:15:29 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.52.149.214]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MPYqL-1dQRfU1QuX-004hLj; Sat, 17 Jun 2017 23:15:21 +0200 Date: Sat, 17 Jun 2017 23:15:14 +0200 From: "O. Hartmann" To: "O. Hartmann" Cc: FreeBSD CURRENT Subject: Re: igb0: core crash (if_io_tqg_0) VLAN Message-ID: <20170617231514.1e5cd56b@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20170617222042.6a9d8cb5@thor.intern.walstatt.dynvpn.de> References: <20170617222042.6a9d8cb5@thor.intern.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/xulrb.C5dEDUVGvD/2L6wha"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:+50zdPai+Z+QfY8EnVcevVl6PumdfXK1ZKXXIe5zTcJcg3eJPxx oB+XIOPFnwOXLlaW7Aq4C7HuQn5AADExGRfLUQpiqPz3vMbawbVjK/oYuCYqBZNSqEHDU5Y 51kfxpw05SVvMkH/0Z5y326h89vgMBBbtqP6lcymTN8Jtu252fk1KB54RN95ZOPIVQoAXTl /ErLBk+jCaDL7c4ck8gxA== X-UI-Out-Filterresults: notjunk:1;V01:K0:qzJUnV7kHz4=:mk2XhIMecE4ixrX6FwsFvO hbOS4anVbC4Xn4/bssdA+xZX8otkq5zE6Xqjx7Um9BEqb7LUU5x5dxmtnP2uRyry0bqwk0mBt iUCgsOikzlg+fgh3wxSnyMvzW9J2GIM/c4rf1/TZ1u8edyzdBMfOril9W9e74UsQuVkVQyNEY PsXevejZxpXGPdVfiGAI2v40NCcX0aBUtkJrr+FA+O1gbS8uY6pvrNVr0uSaGJd8txRZkBNen 3YD/1fMxVhL0kQQtVa2tIhAtORJgHfwm3+rTrJ9Pq8ZT6Kkux+7vvYZV22hnKqzPpEANMcFp7 gMv5GLTYNA8MqR579QYZRyNbT4RC5vLxH/2AfE283Lj1TGkCVbSGtMWBW87YEtF1aL60aM8Pv hRcGyzhGVnjVT1myDbNS+hfYSIp3cHPrFp+jiXgbG6RgPLEttu4cUuPCoKj58CSMo5GhUtVVf ftJcORJXQNAjvfpPHm5jk+n7yUv0f/v+YEBIRcwGNbt5fxQF+yYSNYYcgPiZU5id3OPlnzww1 12dPKan21833HKwTr1lUjLLEPXXdl67dFXRfowTaRDaYpPqcPjgK60tOEWA4S2toihCGemcyq v0/YOCqbIBK8c+cFZCgrljdWaI2wGUyfylCW3QsmiTa6VKfVBzOTTA/Fa4NS/ntd9lIlNhHZX WHDZEio6HxwCkwrJ85iie4H5qjXc/ZcYEY7udwFS2VIR2BjmaEq/Q0XDsG35uRztgaHM+/Mi1 NGRlGcLEQUjKUHtWWRy5RKmhzf527vD41vPSekmvDdRQqlAlQZvdUN12mX0= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 21:15:30 -0000 --Sig_/xulrb.C5dEDUVGvD/2L6wha Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Sat, 17 Jun 2017 22:20:42 +0200 "O. Hartmann" schrieb: > Running CURRENT (FreeBSD 12.0-CURRENT #0 r320050: Sat Jun 17 11:03:50 CES= T 2017 amd64) > on PCengines APU 2C4: CPU: AMD GX-412TC SOC with recent Sea BIOS. > The APU is configured as a small router. The tun0 device is spawned from = igb0 and bound > to ppp (providing the conenction to my ISP). >=20 > igb1 is the internal NIC and it is a Intel i210, identified as igb1. The = NIC is > configured to bear a also a VLAN called igb1.2 providing a dedicated VoIP= network > framework on which I'm working for some tests. So far, that setup worked = wit a > 12-CURRENT roughly two weeks old - I don't have the revison at hand. >=20 > Firewall is IPFW. >=20 > The very moment I plug in the uplink to the switch, the APU goes down wit= h an coredump: >=20 > Fatal trap 12: page fault while in kernel mode > cpuid =3D 0; apic id =3D 00 > fault virtual address =3D 0x0 > fault code =3D supervisor write data, page not present > instruction pointer =3D 0x20:0xffffffff8068b5c0 > stack pointer =3D 0x28:0xfffffe0126762920 > frame pointer =3D 0x28:0xfffffe01267629f0 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = =3D interrupt > enabled, resume, IOPL =3D 0 current process =3D 0 (if_io_tqg_0) > trap number = =3D 12 > panic: page fault > cpuid =3D 0 > time =3D 1497723644 > Uptime: 21s > Dumping 253 out of 4063 > MB:..7%..13%..26%..32%..45%..51%..64%..76%..82%..95% Dump complete > PCEngines apu2 > coreboot build 20170228 > 4080 MB ECC DRAM >=20 > SeaBIOS (version rel-1.10= .0.1) >=20 > Press F10 key now for boo= t menu >=20 >=20 The problem seems to be solved with r320060/r320061. --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/xulrb.C5dEDUVGvD/2L6wha Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWUWb4gAKCRDS528fyFhY lDOUAgCYGq5WyJBVDV8ezelnIj+OtQzLTBZHgSxxzwSn8XdxJf9l0R0b1W/fB3+F 80fhRd8tJNivLIomCclPohPajKo0AgCHsL1rzzQRMvTWrQdJlCJjBATaSkf6BH9o TJrMffKt/QrIxQ3DMfg2/DTotOczKYkV9OJPPY0oKU5/pqCDrzfy =sIfn -----END PGP SIGNATURE----- --Sig_/xulrb.C5dEDUVGvD/2L6wha-- From owner-freebsd-current@freebsd.org Sat Jun 17 23:11:02 2017 Return-Path: Delivered-To: freebsd-current@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 72AABC31674 for ; Sat, 17 Jun 2017 23:11:02 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 24DDF7B0D0; Sat, 17 Jun 2017 23:11:02 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 4DD2E8793; Sat, 17 Jun 2017 23:11:01 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 775AB2729; Sat, 17 Jun 2017 23:11:00 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id glBvACoVUx37; Sat, 17 Jun 2017 23:10:52 +0000 (UTC) Subject: Re: mount -t tmpfs tmpfs fails DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 88D682724 To: Bob Willcox , current list References: <20170614191445.GC5608@rancor.immure.com> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: Date: Sat, 17 Jun 2017 16:10:53 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170614191445.GC5608@rancor.immure.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wlS3XT9MAXGN9eeNrJ3b1q2OewO1l7kiN" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 23:11:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wlS3XT9MAXGN9eeNrJ3b1q2OewO1l7kiN Content-Type: multipart/mixed; boundary="OvqxcdArhluAov93gjMXI6nSmSPFADGEk"; protected-headers="v1" From: Bryan Drewery To: Bob Willcox , current list Message-ID: Subject: Re: mount -t tmpfs tmpfs fails References: <20170614191445.GC5608@rancor.immure.com> In-Reply-To: <20170614191445.GC5608@rancor.immure.com> --OvqxcdArhluAov93gjMXI6nSmSPFADGEk Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/14/2017 12:14 PM, Bob Willcox wrote: > I was attempting to run 'synth status' on my 12-current (drm-next) syst= em > and I got this error: >=20 > root@tavion:0 /> synth status > Querying system about current package installations. > Stand by, comparing installed packages against the ports tree. >=20 > raised REPLICANT.SCENARIO_UNEXPECTED : /sbin/mount -t tmpfs tmpfs /usr/= obj/synth-live/SL09 =3D> failed with code 1 >=20 > So then I attempted just to do a mount of tmpfs command and got this: >=20 > root@tavion:0 /> mount -t tmpfs x /tmp/xxx =20 > mount: x: Operation not supported by device I'm betting 'kldload tmpfs' fixes it. >=20 > synth used to work on this system prior to my recent upgrade to the lat= est > drm-next branch (cloned from github and build from source). >=20 > root@tavion:1 /> uname -a > FreeBSD tavion.austin.ibm.com 12.0-CURRENT FreeBSD 12.0-CURRENT #1 da5f= 90154f1(drm-next): Tue Jun 13 16:58:52 CDT 2017 bob@tavion.austin.ibm= =2Ecom:/usr/obj/usr/freebsd-base-graphics/sys/TAVION amd64 >=20 > Any suggestions on what I should be looking for (or fixing)? >=20 > Thanks, > Bob >=20 --=20 Regards, Bryan Drewery --OvqxcdArhluAov93gjMXI6nSmSPFADGEk-- --wlS3XT9MAXGN9eeNrJ3b1q2OewO1l7kiN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJZRbb9AAoJEDXXcbtuRpfPUGUIALvKQ8pyzbmseQNzTApnLtMf WCSMv+MMrYrL22Nv304h0M7NlRoR5gjpufR2kNcEJCu9taH++u9bAg7PiU70jyZa EaDmwQVz4dv1wEfkCHlnxUNH44KI+c/CqwVh5F28VyONTovdqQVRaHBv0HIK5vyi EGooNTvcODLHoTpllaRNiCv4yywFMQ4aV7y9MaqQwISd00/BhJfmqPDkgR84DYF7 O5XMz5pWTCFoJKzSaGR8Wi9KzPWVhqG2i/cmi58KLNSMKvKJ1J+8a4a1ge+V/YbC U41LqjaiJi6M6bSl0B2RSUoxsB3q2DDItzVeSe6qB5JTGoKRo0NXfmijLo7M+vg= =IswQ -----END PGP SIGNATURE----- --wlS3XT9MAXGN9eeNrJ3b1q2OewO1l7kiN-- From owner-freebsd-current@freebsd.org Sat Jun 17 23:14:46 2017 Return-Path: Delivered-To: freebsd-current@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 A8739C3188D for ; Sat, 17 Jun 2017 23:14:46 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7B2187B355; Sat, 17 Jun 2017 23:14:46 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id A4894887A; Sat, 17 Jun 2017 23:14:45 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id C6EAB273D; Sat, 17 Jun 2017 23:14:44 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id VyqAFm8rW9ub; Sat, 17 Jun 2017 23:14:39 +0000 (UTC) Subject: Re: mount -t tmpfs tmpfs fails DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com A58EC2737 To: Bob Willcox , current list References: <20170614191445.GC5608@rancor.immure.com> <20170614205034.GD5608@rancor.immure.com> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <260d04dd-64a4-0bb3-f1a1-3cdc38f8c9c2@FreeBSD.org> Date: Sat, 17 Jun 2017 16:14:39 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170614205034.GD5608@rancor.immure.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IlT4bkpWeOqFXeGFdhxJX6EjJASTrCpfL" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 23:14:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IlT4bkpWeOqFXeGFdhxJX6EjJASTrCpfL Content-Type: multipart/mixed; boundary="sH9ugnTK8E2p9laqLXiUTm000BKCE8OVN"; protected-headers="v1" From: Bryan Drewery To: Bob Willcox , current list Message-ID: <260d04dd-64a4-0bb3-f1a1-3cdc38f8c9c2@FreeBSD.org> Subject: Re: mount -t tmpfs tmpfs fails References: <20170614191445.GC5608@rancor.immure.com> <20170614205034.GD5608@rancor.immure.com> In-Reply-To: <20170614205034.GD5608@rancor.immure.com> --sH9ugnTK8E2p9laqLXiUTm000BKCE8OVN Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/14/2017 1:50 PM, Bob Willcox wrote: > On Wed, Jun 14, 2017 at 02:14:45PM -0500, Bob Willcox wrote: >> I was attempting to run 'synth status' on my 12-current (drm-next) sys= tem >> and I got this error: >> >> root@tavion:0 /> synth status >> Querying system about current package installations. >> Stand by, comparing installed packages against the ports tree. >> >> raised REPLICANT.SCENARIO_UNEXPECTED : /sbin/mount -t tmpfs tmpfs /usr= /obj/synth-live/SL09 =3D> failed with code 1 >> >> So then I attempted just to do a mount of tmpfs command and got this: >> >> root@tavion:0 /> mount -t tmpfs x /tmp/xxx =20 >> mount: x: Operation not supported by device >> >> synth used to work on this system prior to my recent upgrade to the la= test >> drm-next branch (cloned from github and build from source). >> >> root@tavion:1 /> uname -a >> FreeBSD tavion.austin.ibm.com 12.0-CURRENT FreeBSD 12.0-CURRENT #1 da5= f90154f1(drm-next): Tue Jun 13 16:58:52 CDT 2017 bob@tavion.austin.ib= m.com:/usr/obj/usr/freebsd-base-graphics/sys/TAVION amd64 >> >> Any suggestions on what I should be looking for (or fixing)? >> >> Thanks, >> Bob >=20 > Ok, I finally figured out that my previous kernel must have had the tmp= fs (and > nullfs, it was a problem also with synth) built into the kernel, probab= ly by > default. Further, the tmpfs.ko and nullfs.ko modules weren't built and > installed. >=20 > I wound up building and installing both tmpfs and nullfs manually (cdin= g to > their respective src direcdories and running make; make install) to get= synth > to run. >=20 > My only question remaining now is was the removal of the building and > installing of these modules a fairly recent change in 12.0, or is somet= hing in > my system hosed up? Oddly I don't see TMPFS ever being in the x86 GENERIC kernel files. Only in some arm and mips kernel configurations. Even if not built into the kernel there should be a loadable module built unless you are using MODULES_OVERRIDE. --=20 Regards, Bryan Drewery --sH9ugnTK8E2p9laqLXiUTm000BKCE8OVN-- --IlT4bkpWeOqFXeGFdhxJX6EjJASTrCpfL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJZRbffAAoJEDXXcbtuRpfPbNEIALEvYPspt0l3NR4urXB65Osq p3P+2eAsG/IVDBhiKpbRugk3d899P/4hE1jfXBTHiGjRUm0oBcMfw8eVAJFEoJWY Qnp3fHYIpQRIYjEAldlRtQlrqsYMSfPyyePTPxAv9WThhKmUvLm0T9uaaE11raYq ZIlXdKU/46AAwAaIgnFYFvBMjCyZfG3rCXHzlWfqfmbwVMzziBZQjCqiFii6O/Xy /bNXARjGED6VTWrEc3Rjhlqgb9KycMR9+z8DLW42BDVSjvSj51BEUC/8VHyrJyIO GKfjFbm1F7fIT5WPJvrDAv+A2icciSXQ0iBsbKQSXiqQjIEA1aIep1tHWr9KAks= =h12n -----END PGP SIGNATURE----- --IlT4bkpWeOqFXeGFdhxJX6EjJASTrCpfL--