From owner-freebsd-current@freebsd.org Sun Mar 26 04:13:05 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 6E62BD12AF6; Sun, 26 Mar 2017 04:13:05 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 D48AE1011; Sun, 26 Mar 2017 04:13:04 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074423-1a7ff70000005559-2f-58d73e99e698 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 81.20.21849.99E37D85; Sun, 26 Mar 2017 00:07:53 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v2Q47qTp019273; Sun, 26 Mar 2017 00:07:52 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v2Q47miA002608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 26 Mar 2017 00:07:51 -0400 Date: Sat, 25 Mar 2017 23:07:47 -0500 From: Benjamin Kaduk To: freebsd-hackers@FreeBSD.org Cc: freebsd-current@FreeBSD.org Subject: Second call for 2017Q1 quarterly status reports Message-ID: <20170326040747.GV30306@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrEIsWRmVeSWpSXmKPExsUixCmqrTvT7nqEwblDuha7rp1mt5jz5gOT xfbN/xgdmD1mfJrPEsAYxWWTkpqTWZZapG+XwJXRtPIFW8Fs7opDjyczNzAu5+xi5OSQEDCR WDCpgbWLkYtDSKCNSeLEkWMsEM5GRok/a84wQThXmST2/trIDNLCIqAqcfDlPSYQm01ATWL9 imtgcREBeYl9Te/ZQWxmIPvX1iYgm4NDWMBC4v6XBJAwL9C2bUc+M0PYghInZz5hgSjXkrjx 7yUTSDmzgLTE8n8cIGFRAWWJhhkPmCcw8s1C0jELSccshI4FjMyrGGVTcqt0cxMzc4pTk3WL kxPz8lKLdM30cjNL9FJTSjcxgoKO3UV5B+PLPu9DjAIcjEo8vA07r0UIsSaWFVfmHmKU5GBS EuWNOAsU4kvKT6nMSCzOiC8qzUktPsQowcGsJML7y+B6hBBvSmJlVWpRPkxKmoNFSZxXXKMx QkggPbEkNTs1tSC1CCYrw8GhJMHrbwvUKFiUmp5akZaZU4KQZuLgBBnOAzQ8BqSGt7ggMbc4 Mx0if4pRUUqc19kGKCEAksgozYPrBSUFiez9Na8YxYFeEeaNAGnnASYUuO5XQIOZgAbP3nAF ZHBJIkJKqoHRcU3cx77Gq7qx1xZ0Tk+en+/0oPu98eMlSpzR5s+fnAtYk2Q/c0enx/WzQdHX Ra58jXzI4BUpY7D2bPUB/8ajBo8mWV55IJ7Ldi6y9ZzGt/mH6yrP16udZG70Tds7Xf937n1N QYe5oRt2HTSsmOHxNPpsE3ueRtns6iyTg4Vz7RLMbqQ8vnFLiaU4I9FQi7moOBEATnAzR+UC AAA= 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, 26 Mar 2017 04:13:05 -0000 Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is April 7, 2017, for work done in January through March. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and provide a great way to inform FreeBSD users and developers about work that is underway and completed. Submission of reports is not restricted to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The preferred and easiest submission method is to use the XML generator [1] with the results emailed to the status report team at monthly@FreeBSD.org . (Do be sure, though, to save the form output and not the form itself!) There is also an XML template [2] that can be filled out manually and attached if preferred. For the expected content and style, please study our guidelines on how to write a good status report [3]. You can also review previous issues [4][5] for ideas on the style and format. We look forward to seeing your 2016Q4 reports! Thanks, Ben (on behalf of monthly@) [1] https://www.FreeBSD.org/cgi/monthly.cgi [2] https://www.FreeBSD.org/news/status/report-sample.xml [3] https://www.FreeBSD.org/news/status/howto.html [4] https://www.FreeBSD.org/news/status/report-2016-07-2016-09.html [5] https://www.FreeBSD.org/news/status/report-2016-10-2016-12.html From owner-freebsd-current@freebsd.org Sun Mar 26 06:18: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 61957D1DBAC for ; Sun, 26 Mar 2017 06:18:20 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (glebi.us [96.95.210.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 335CD173E for ; Sun, 26 Mar 2017 06:18:19 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.15.2/8.15.2) with ESMTPS id v2Q6IDZH003640 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 25 Mar 2017 23:18:13 -0700 (PDT) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebi.us (8.15.2/8.15.2/Submit) id v2Q6IDJ3003639; Sat, 25 Mar 2017 23:18:13 -0700 (PDT) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@FreeBSD.org using -f Date: Sat, 25 Mar 2017 23:18:13 -0700 From: Gleb Smirnoff To: Konstantin Belousov Cc: Darren , "freebsd-current@freebsd.org" Subject: Re: r315684 panic: sleepq_add: td 0xfffff80003c01a40 to sleep on wchan 0xfffff80006f0873c with sleeping prohibited Message-ID: <20170326061813.GB23308@FreeBSD.org> References: <1824572972.3096988.1490377215756.ref@mail.yahoo.com> <1824572972.3096988.1490377215756@mail.yahoo.com> <20170325010314.GG43712@kib.kiev.ua> <20170325033142.GA23308@FreeBSD.org> <20170325094529.GH43712@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="x1F0m3RQhDZyj8sd" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170325094529.GH43712@kib.kiev.ua> 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: Sun, 26 Mar 2017 06:18:20 -0000 --x1F0m3RQhDZyj8sd Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Sat, Mar 25, 2017 at 11:45:29AM +0200, Konstantin Belousov wrote: K> On Fri, Mar 24, 2017 at 08:31:42PM -0700, Gleb Smirnoff wrote: K> > Darren, K> > K> > On Sat, Mar 25, 2017 at 03:03:14AM +0200, Konstantin Belousov wrote: K> > K> On Fri, Mar 24, 2017 at 05:40:15PM +0000, Darren wrote: K> > K> > I am getting this panic every hour to every couple of hours. K> > K> > K> > K> > FreeBSD asrock 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r315684: Thu Mar 23 14:56:45 EDT 2017     darren@asrock:/usr/obj/usr/src/sys/GENERIC  amd64 K> > K> > I manually typed out the following, apologize for any typos. K> > K> > K> > K> > K> > K> > panic: sleepq_add: td 0xfffff80003c01a40 to sleep on wchan 0xfffff80006f0873c with sleeping prohibited K> > K> > cpuid = 0 K> > K> > time = 1490372797 K> > K> > KDB: stack backtrace: K> > K> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0072e33690 K> > K> > vpanic() at vpanic+0x19c/frame 0xfffffe0072e33710 K> > K> > kassert_panic() at kassert_panic+0x126/frame 0xfffffe0072e33780 K> > K> > sleepq_add() at sleepq_add+0x34f/frame 0xfffffe0072337d0 K> > K> > _sleep() at _sleep+0x28d/frame 0xfffffe0072e33870 K> > K> > soclose() at soclose+0xda/frame 0xfffffe0072e338b0 K> > K> > _fdrop() at _fdrop+0x1a/frame 0xfffffe0072e338d0 K> > K> > sendfile_iodone() at sendfile_iodone+0x19d/frame 0xfffffe0072e33910 K> > K> > vnode_pager_generic_getpages_done_async() at vnode_pager_generic_getpages_done_async+037/frame 0xfffffe0072e33930 K> > K> > bufdone() at bufdone+0x64/frame 0xfffffe0072e33960 K> > K> > g_io_deliver() at g_io_deliver+0x276/frame 0xfffffe0072e339b0 K> > K> > g_io_deliver() at g_io_deliver+0x276/frame 0xfffffe0072e33a00 K> > K> > g_disk_done() at g_disk_done+0x104/frame 0xfffffe0072e33a40 K> > K> > xpt_done_process() at xpt_done_process+0x35f/frame 0xfffffe0072e33a80 K> > K> > xpt_done_direct() at ahci_ch_intr_direct+0xd5/frame 0xfffffe0072e33af0 K> > K> > ahci_itr() at ahci_intr+0x102/frame 0xfffffe0072e33b20 K> > K> > intr_event_execute_handlers() at intr_event_execute_handlers+0x99/frame 0xfffffe0072e33b60 K> > K> > ithread_loop() at ithread_loop+0xb6/frame 0xfffffe0072e33bb0 K> > K> > fork_exit() at fork_exit+0x84/frame 0xfffffe0072e33bf0 K> > K> > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0072e33bf0 K> > K> > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- K> > K> > KDB: enter: panic K> > K> > [ thread pid 12 tid 100038 ] K> > K> > Stopped at      kdb_enter+0x3b: movq    $0,kdb_why K> > K> > db> K> > K> K> > K> Indeed, the context where sendfile_iodone() is executed, cannot call fdrop(). K> > K> > Can you please test the attached patch? K> > K> > -- K> > Totus tuus, Glebius. K> K> > Index: sys/kern/kern_sendfile.c K> > =================================================================== K> > --- sys/kern/kern_sendfile.c (revision 315926) K> > +++ sys/kern/kern_sendfile.c (working copy) K> > @@ -296,8 +296,9 @@ sendfile_iodone(void *arg, vm_page_t *pg, int coun K> > CURVNET_RESTORE(); K> > } K> > K> > - /* XXXGL: curthread */ K> > - fdrop(sfio->sock_fp, curthread); K> > + ACCEPT_LOCK(); K> > + SOCK_LOCK(so); K> > + sorele(so); K> > free(sfio, M_TEMP); K> > } K> > K> > @@ -860,7 +861,9 @@ prepend_header: K> > } else { K> > sfio->sock_fp = sock_fp; K> > sfio->npages = npages; K> > - fhold(sock_fp); K> > + SOCK_LOCK(so); K> > + soref(so); K> > + SOCK_UNLOCK(so); K> > error = (*so->so_proto->pr_usrreqs->pru_send) K> > (so, PRUS_NOTREADY, m, NULL, NULL, td); K> > sendfile_iodone(sfio, NULL, 0, 0); K> K> With this patch, what prevents a close of the sfio->sock_fp file, which is K> needed to get the pointer to socket ? You are right, patch is unfinished. Here is better one. -- Totus tuus, Glebius. --x1F0m3RQhDZyj8sd Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="sendfile_sleep.diff" Index: sys/kern/kern_sendfile.c =================================================================== --- sys/kern/kern_sendfile.c (revision 315926) +++ sys/kern/kern_sendfile.c (working copy) @@ -80,7 +80,7 @@ struct sf_io { volatile u_int nios; u_int error; int npages; - struct file *sock_fp; + struct socket *so; struct mbuf *m; vm_page_t pa[]; }; @@ -255,7 +255,7 @@ static void sendfile_iodone(void *arg, vm_page_t *pg, int count, int error) { struct sf_io *sfio = arg; - struct socket *so; + struct socket *so = sfio->so; for (int i = 0; i < count; i++) if (pg[i] != bogus_page) @@ -267,8 +267,6 @@ sendfile_iodone(void *arg, vm_page_t *pg, int coun if (!refcount_release(&sfio->nios)) return; - so = sfio->sock_fp->f_data; - if (sfio->error) { struct mbuf *m; @@ -296,8 +294,9 @@ sendfile_iodone(void *arg, vm_page_t *pg, int coun CURVNET_RESTORE(); } - /* XXXGL: curthread */ - fdrop(sfio->sock_fp, curthread); + ACCEPT_LOCK(); + SOCK_LOCK(so); + sorele(so); free(sfio, M_TEMP); } @@ -858,9 +857,11 @@ prepend_header: error = (*so->so_proto->pr_usrreqs->pru_send) (so, 0, m, NULL, NULL, td); } else { - sfio->sock_fp = sock_fp; + sfio->so = so; sfio->npages = npages; - fhold(sock_fp); + SOCK_LOCK(so); + soref(so); + SOCK_UNLOCK(so); error = (*so->so_proto->pr_usrreqs->pru_send) (so, PRUS_NOTREADY, m, NULL, NULL, td); sendfile_iodone(sfio, NULL, 0, 0); --x1F0m3RQhDZyj8sd-- From owner-freebsd-current@freebsd.org Sun Mar 26 20:00:11 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 98ACCD1E67D for ; Sun, 26 Mar 2017 20:00:11 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660040.outbound.protection.outlook.com [40.107.66.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 87E8F15D7; Sun, 26 Mar 2017 20:00:10 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Sun, 26 Mar 2017 20:00:08 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0991.020; Sun, 26 Mar 2017 20:00:08 +0000 From: Rick Macklem To: Toomas Soome , Daniel Braniss CC: Baptiste Daroussin , FreeBSD Current Subject: Re: NFSv2 boot & OLD_NFSV2 Thread-Topic: NFSv2 boot & OLD_NFSV2 Thread-Index: AQHSoabzN3fGlEoBW0OV/vmFdatswaGeGqEAgAAonNqAAALjgIAAqGOAgAAERoCAAApggIAAA/eAgAiSfbo= Date: Sun, 26 Mar 2017 20:00:07 +0000 Message-ID: References: <38DD1950-AD12-4A27-8335-54F997E408DF@me.com> <20170320192000.6hal22ibnr3ajog3@ivaldir.net> <1B7471CD-2F2D-4F22-9D25-E46580CF9E96@me.com> <84D239AB-AB57-4A50-9700-E42BBF9CBE5A@cs.huji.ac.il> <20170321081339.2wbx3rb32qdavvn3@ivaldir.net> <80C5425F-9A71-45D9-BA41-229E4E72EC36@cs.huji.ac.il>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: me.com; dkim=none (message not signed) header.d=none;me.com; dmarc=none action=none header.from=uoguelph.ca; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0189; 7:xhOirgO+4/FsXrVxThjHPJMev2MO5ZXLAEsuOVqIR8b8AlxzKTexZ/UHDm/T3MO1+qP862w/Xse3BZfJ1x/Hk6oLvjGWYpVkL2OG54zggK7mXo24vJjjiDRtSz3MfR1jYFVXkqOvDmNbw0QGvCNaP3QEgTBWFRIaEN30JW0QAFpyVWJjr2bmBdjwL+1fgroBt7X/PW70OU5b5AEMX3QK0fDsiKCHm5qRM+lN0puHPZokAmopXMsNy3X6if7zsHEqMl0297TL0PcoZKyEDOPjmqpyNc2x+ZL7cAdLxPLbX8hoKQkznM4zu/YvvTEGAVAJVZyITprPvfk8ebxWWMSOmQ== x-ms-office365-filtering-correlation-id: ffb40c79-dac6-4575-b4f3-08d47482b401 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:YTXPR01MB0189; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(188474585043545); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(20161123558025)(6072148); SRVR:YTXPR01MB0189; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0189; x-forefront-prvs: 0258E7CCD4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39830400002)(39410400002)(24454002)(377454003)(2906002)(55016002)(54906002)(9686003)(3660700001)(3280700002)(6436002)(8656002)(33656002)(53936002)(25786009)(38730400002)(229853002)(39060400002)(6246003)(2900100001)(189998001)(74482002)(102836003)(54356999)(5660300001)(81166006)(50986999)(86362001)(76176999)(7696004)(8676002)(93886004)(2950100002)(305945005)(74316002)(6506006)(77096006)(53546009)(4326008)(122556002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0189; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2017 20:00:07.9101 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0189 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, 26 Mar 2017 20:00:11 -0000 Just in case it wasn't clear, I think this is a good idea and I think you have a handle on any potential problems. Good luck with it, rick ________________________________________ From: Toomas Soome Sent: Tuesday, March 21, 2017 5:04:59 AM To: Daniel Braniss Cc: Baptiste Daroussin; Rick Macklem; FreeBSD Current Subject: Re: NFSv2 boot & OLD_NFSV2 On 21. m=E4rts 2017, at 10:50, Daniel Braniss > wrote: On 21 Mar 2017, at 10:13, Baptiste Daroussin > wrote: On Tue, Mar 21, 2017 at 09:58:21AM +0200, Daniel Braniss wrote: On 20 Mar 2017, at 23:55, Toomas Soome = > wrote: On 20. m=E4rts 2017, at 23:53, Rick Macklem > wrote: Baptiste Daroussin wrote: On Mon, Mar 20, 2017 at 08:22:12PM +0200, Toomas Soome wrote: Hi! The current boot code is building NFSv3, with preprocessor conditional OLD_= NFSV2. Should NFSv2 code still be kept around or can we burn it? rgds, toomas I vote burn Bapt I would be happy to see NFSv2 go away. However, depending on how people con= figure their diskless root fs, they do end up using NFSv2 for their root fs. Does booting over NFSv3 affect this? I think the answer is no for a FreeBSD server (since the NFSv2 File Handle = is the same as the NFSv3 one, except padded with 0 bytes to 32bytes long). However, there might be non-FreeBSD NFS servers where the NFSv2 file handle= is different than the NFSv3 one and for that case, the user would need NFSv2 boot code (= or reconfigure their root fs to use NFSv3). To be honest, I suspect few realize that they are using NFSv2 for their roo= t fs. (They'd see it in a packet trace or via "nfsstat -m", but otherwise they pr= obably think they are using NFSv3 for their root fs.) rick if they do not suspect, they most likely use v3 - due to simple fact that y= ou have to rebuild loader to use NFSv2 - it is compile time option. old systems, 8.x, still use/boot v2, and so do old linux. NetApp has discontinued support for v2, so we had to move this machines to = use FreeBSD server and the day was saved. So, till these machines get upgraded/discontinued we have a problem.= There are several solutions to this issue, but as long as it's a matter of getting rid for the sake of = it, I would vote to keep it a while longer. danny Given you are speaking of 8.x I suppose you are using the loader that comes= with it, meaning you are safe if we remove it from the loader in 12.0 (note as s= aid by Toomas that is it is already off by default in the 12.0 loader) am I mis= sing something? as usual, did not read the whole thread, I assumed - wrongly - that support= for v2 would be discontinued. removing v2 support from the boot process is fine! great, go for it. It wil= l only involve newer hosts, and simplifying the boot process is always a good idea. sorry for the noise. danny yes, just to clarify, the current loader code (in current), is having NFS = code implemented as: #ifdef OLD_NFSV2 v2 implementation is here #else v3 implementation is here #endif Which does mean that pxeboot/loader.efi is built by default to use v3 only,= but we do have 2 parallel implementations of the NFS readers. And yes, the= question is just about boot loader reader code (we do not implement NFS wr= ites) - and we are *not* talking about server side there. Indeed it also is possible to merge those 2 version implementations, but to= be honest, I see very little point of doing that either, even if there is = some setup still with v2 only server, there is still an option just to use = TFTP based boot - especially given that current boot loader does provide pa= rallel option to use either NFS or TFTP (via dhcp option 150), with existin= g binaries - that is, without having to re-compile. rgds, toomas From owner-freebsd-current@freebsd.org Sun Mar 26 20:09:11 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 1CCC8D1EB7B for ; Sun, 26 Mar 2017 20:09:11 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp001.me.com (st13p35im-asmtp001.me.com [17.164.199.64]) (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 C48951C7F; Sun, 26 Mar 2017 20:09:10 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp001.me.com by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0ONF00J00UC8RQ00@st13p35im-asmtp001.me.com>; Sun, 26 Mar 2017 20:09:03 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1490558943; bh=KKlS8zBLrw78ZKNjfOIF7hp8m0ZpLYUcZeHzx0SsEvI=; h=From:Message-id:Content-type:MIME-version:Subject:Date:To; b=nsBxgTeS8tgVfUir1l1W/Hrh+MrneXVbMtHmK6P4p4DflFhAFNJLKTsqKiUOo8Imv 6uzjGoRjDeA+77TuojKWv8HoFhgzEp5DXZpREPr5wp5D1fnYjIPTZk/F6QHZtNkNfY phee/voWkVv2EDg6hf1ETGnKMkjCEDmHmDvs3mE+7AsBlbPSwJku9/92TVMxPQ5hk1 6MxqdAM3sG2fSzjQmEpEmS7W2pJJT27b0QG5CzTY3tSeVUitWA9LqPi1m5343bCtqM pTAgVmonZQvdAJQ24rxjt9zN9wQzHtwzOakNqL8BZRSmK7POr9fsMW51zA0Xnq4LKs hKAoOS378YV0w== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0ONF00O0HUMZYT00@st13p35im-asmtp001.me.com>; Sun, 26 Mar 2017 20:09:02 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-26_17:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=8 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1703260186 From: Toomas Soome Message-id: MIME-version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: NFSv2 boot & OLD_NFSV2 Date: Sun, 26 Mar 2017 23:08:58 +0300 In-reply-to: Cc: Daniel Braniss , Baptiste Daroussin , FreeBSD Current To: Rick Macklem References: <38DD1950-AD12-4A27-8335-54F997E408DF@me.com> <20170320192000.6hal22ibnr3ajog3@ivaldir.net> <1B7471CD-2F2D-4F22-9D25-E46580CF9E96@me.com> <84D239AB-AB57-4A50-9700-E42BBF9CBE5A@cs.huji.ac.il> <20170321081339.2wbx3rb32qdavvn3@ivaldir.net> <80C5425F-9A71-45D9-BA41-229E4E72EC36@cs.huji.ac.il> X-Mailer: Apple Mail (2.3259) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Sun, 26 Mar 2017 20:09:11 -0000 > On 26. m=C3=A4rts 2017, at 23:00, Rick Macklem = wrote: >=20 > Just in case it wasn't clear, I think this is a good idea and I think > you have a handle on any potential problems. >=20 > Good luck with it, rick aye, thanks, just wanted to give people some time to react. And got some = stupid cold meanwhile:D rgds, toomas > ________________________________________ > From: Toomas Soome > > Sent: Tuesday, March 21, 2017 5:04:59 AM > To: Daniel Braniss > Cc: Baptiste Daroussin; Rick Macklem; FreeBSD Current > Subject: Re: NFSv2 boot & OLD_NFSV2 >=20 > On 21. m=C3=A4rts 2017, at 10:50, Daniel Braniss >> wrote: >=20 >=20 > On 21 Mar 2017, at 10:13, Baptiste Daroussin >> wrote: >=20 > On Tue, Mar 21, 2017 at 09:58:21AM +0200, Daniel Braniss wrote: >=20 > On 20 Mar 2017, at 23:55, Toomas Soome >> = wrote: >=20 >=20 > On 20. m=C3=A4rts 2017, at 23:53, Rick Macklem >> wrote: >=20 > Baptiste Daroussin wrote: > On Mon, Mar 20, 2017 at 08:22:12PM +0200, Toomas Soome wrote: > Hi! >=20 > The current boot code is building NFSv3, with preprocessor conditional = OLD_NFSV2. Should NFSv2 code still be kept around or can we burn it? >=20 > rgds, > toomas >=20 > I vote burn >=20 > Bapt > I would be happy to see NFSv2 go away. However, depending on how = people configure > their diskless root fs, they do end up using NFSv2 for their root fs. >=20 > Does booting over NFSv3 affect this? >=20 > I think the answer is no for a FreeBSD server (since the NFSv2 File = Handle is the same as > the NFSv3 one, except padded with 0 bytes to 32bytes long). > However, there might be non-FreeBSD NFS servers where the NFSv2 file = handle is different > than the NFSv3 one and for that case, the user would need NFSv2 boot = code (or > reconfigure their root fs to use NFSv3). >=20 > To be honest, I suspect few realize that they are using NFSv2 for = their root fs. > (They'd see it in a packet trace or via "nfsstat -m", but otherwise = they probably > think they are using NFSv3 for their root fs.) >=20 > rick >=20 > if they do not suspect, they most likely use v3 - due to simple fact = that you have to rebuild loader to use NFSv2 - it is compile time = option. >=20 >=20 > old systems, 8.x, still use/boot v2, and so do old linux. > NetApp has discontinued support for v2, so we had to move this = machines to use FreeBSD server and the day was > saved. So, till these machines get upgraded/discontinued we have a = problem. There are several solutions > to this issue, but as long as it's a matter of getting rid for the = sake of it, I would vote to keep it a while longer. >=20 > danny >=20 >=20 > Given you are speaking of 8.x I suppose you are using the loader that = comes with > it, meaning you are safe if we remove it from the loader in 12.0 (note = as said > by Toomas that is it is already off by default in the 12.0 loader) am = I missing > something? >=20 >=20 > as usual, did not read the whole thread, I assumed - wrongly - that = support for v2 would be discontinued. > removing v2 support from the boot process is fine! great, go for it. = It will only involve newer > hosts, and simplifying the boot process is always a good idea. >=20 > sorry for the noise. > danny >=20 >=20 >=20 > yes, just to clarify, the current loader code (in current), is having = NFS code implemented as: >=20 > #ifdef OLD_NFSV2 >=20 > v2 implementation is here >=20 > #else >=20 > v3 implementation is here >=20 > #endif >=20 > Which does mean that pxeboot/loader.efi is built by default to use v3 = only, but we do have 2 parallel implementations of the NFS readers. And = yes, the question is just about boot loader reader code (we do not = implement NFS writes) - and we are *not* talking about server side = there. >=20 > Indeed it also is possible to merge those 2 version implementations, = but to be honest, I see very little point of doing that either, even if = there is some setup still with v2 only server, there is still an option = just to use TFTP based boot - especially given that current boot loader = does provide parallel option to use either NFS or TFTP (via dhcp option = 150), with existing binaries - that is, without having to re-compile. >=20 > rgds, > toomas >=20 > _______________________________________________ > freebsd-current@freebsd.org = mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current = > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org = " From owner-freebsd-current@freebsd.org Sun Mar 26 21:36:40 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 F038CD1FDD8 for ; Sun, 26 Mar 2017 21:36:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-181.reflexion.net [208.70.211.181]) (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 B55F71708 for ; Sun, 26 Mar 2017 21:36:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25830 invoked from network); 26 Mar 2017 21:36:33 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 26 Mar 2017 21:36:33 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Sun, 26 Mar 2017 17:36:33 -0400 (EDT) Received: (qmail 6701 invoked from network); 26 Mar 2017 21:36:33 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 26 Mar 2017 21:36:33 -0000 Received: from [192.168.1.119] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 44100EC770C; Sun, 26 Mar 2017 14:36:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) From: Mark Millard In-Reply-To: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> Date: Sun, 26 Mar 2017 14:36:31 -0700 Cc: FreeBSD Toolchain , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> To: FreeBSD Ports , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3259) 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, 26 Mar 2017 21:36:41 -0000 [I add some what-it-take-for-an-upgrade information.] On 2017-Mar-12, at 6:53 PM, Mark Millard wrote: > Summary: RAM+(peak swap) was about 26 GiBytes. > Also: about 118 GiByte /usr/obj/. . ./llvm40/ area. > (2 processors, 2 cores each, all in use; > WITH_DEBUG=3D used) >=20 > The peak usage times were when the 4 cores were > each busy running ld at the same time. >=20 > [So far as I know FreeBSD does not report peak swap usage > "since boot". So I do not have a cross check on if I missed > seeing a higher peak then I report in the details below.] >=20 > What all this note spans as part of the build: >=20 > # more /var/db/ports/devel_llvm40/options > # This file is auto-generated by 'make config'. > # Options for llvm40-4.0.0.r4 > _OPTIONS_READ=3Dllvm40-4.0.0.r4 > _FILE_COMPLETE_OPTIONS_LIST=3DCLANG DOCS EXTRAS LIT LLD LLDB > OPTIONS_FILE_SET+=3DCLANG > OPTIONS_FILE_SET+=3DDOCS > OPTIONS_FILE_SET+=3DEXTRAS > OPTIONS_FILE_SET+=3DLIT > OPTIONS_FILE_SET+=3DLLD > OPTIONS_FILE_SET+=3DLLDB >=20 > The system clang 4.0 was used to do the build. A port > binutils was used (-B${LOCALBASE}/bin/ in CFLAGS, > CXXFLAGS, an CPPFLAGS). The kernel was non-debug generally > but buildworld buildkernel did not have MALLOC_PRODUCTION=3D . > The llvm40 build did have MALLOC_PRODUCTION=3D . >=20 > # uname -paKU > FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT r314687M powerpc = powerpc64 1200023 1200023 >=20 > Most of what I have access to for FreeBSD does not have a > big enough configuration to do a WITH_DEBUG=3D build of llvm40 > on a machine with 4 cores, all in use. >=20 > One type of environment that does is an old PowerMac G5 > so-called "Quad Core" that has 16 GiBytes of RAM, 17 GiBytes > of swap, and a 480 GiByte SSD (but extra over provisioned so > it appears even smaller for the file system+swap). >=20 > Watching with top the peak swap usage that I saw was > 56% of the 17 GiByte --so call it 10 GiBytes or so. >=20 > So something like 16 GiBytes RAM + 10 GiBytes swap > and so something like 26 GiByte total. >=20 > I used portmaster with -DK. Afterwards the /usr/obj/ > sub-area for llvm40 used totaled to a size of: >=20 > # du -sg /usr/obj/portswork/usr/ports/devel/llvm40 > 118 /usr/obj/portswork/usr/ports/devel/llvm40 >=20 > So around 118 GiBytes of disk space. >=20 > Showing the major space usage contributions: >=20 > # du -sg /usr/obj/portswork/usr/ports/devel/llvm40/work/.build/* = /usr/obj/portswork/usr/ports/devel/llvm40/work/stage/usr/local/llvm40/* > . . . > 29 /usr/obj/portswork/usr/ports/devel/llvm40/work/.build/bin > . . . > 29 /usr/obj/portswork/usr/ports/devel/llvm40/work/.build/lib > . . . > 12 /usr/obj/portswork/usr/ports/devel/llvm40/work/.build/tools > . . . > 26 = /usr/obj/portswork/usr/ports/devel/llvm40/work/stage/usr/local/llvm40/bin > . . . > 24 = /usr/obj/portswork/usr/ports/devel/llvm40/work/stage/usr/local/llvm40/lib > . . . >=20 >=20 >=20 > Side notes that are more system specific: >=20 > The timestamps on the script output file indicate that > the build took about 8 hours 24 minutes. >=20 > The powerpc64 system used was built with the system clang > 4.0 compiler and a port-based binutils. This is despite that > clang 4.0 produces code that has any thrown C++ exceptions > completely non-functional for powerpc64 (program crashes > via signals reporting problems). I upgraded from llvm40 r4 to final. An interesting result was its creation of a backup package for llvm40-4.0.0.r4: about 13 cpu-core-hours running pkg create (Remember: I've been building with WITH_DEBUG=3D ) Its single-threaded status stands out via elapsed time approximately matching. I'll note that it was somewhat under 6 elapsed hours for staging to have been populated (-j4 with 4 cores present helps for this part). (Of course these elapsed-time figures are rather system dependent, although the ratio might be more stable.) Also interesting was: Installed packages to be REMOVED: llvm40-4.0.0.r4 Number of packages to be removed: 1 The operation will free 49 GiB. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Mon Mar 27 06:43:18 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 7E316D1FBE1 for ; Mon, 27 Mar 2017 06:43:18 +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 DBB03121C for ; Mon, 27 Mar 2017 06:43:17 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MQ7sF-1cons81HSF-005DzP for ; Mon, 27 Mar 2017 08:43:15 +0200 Date: Mon, 27 Mar 2017 08:43:14 +0200 From: "O. Hartmann" To: freebsd-current Subject: "service netif restart" doesn't restart ppp() Message-ID: <20170327084314.7fec3f70@freyja.zeit4.iv.bundesimmobilien.de> Organization: Walstatt X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:e6R2uywZP/Bc/FDVziT9KYmSRSXSJ/WU6p6ho1sYbB3Ho0aM3nV 1RH6HKpVsdv8O6loDHGsj6R5VQWdPuohcz3nXyDWQkLNbuPgnSkRxrsYByo01bupHCnbkAA pmkARNDQHbzQ3ThH05+zVLnWefgC6j/2tooa6F6Drkrnq1Da1T/rNHdphOZQJkDNL36qesW BJv9363W0bChgwnv1E8dw== X-UI-Out-Filterresults: notjunk:1;V01:K0:1eMhLXOr0Jg=:oNPnBxUXOWhJjyQ4xCxG3V JFAMBGQuuq2qMC4YbNich0glQ/DcHgj5zAmaA0A114mQuAvAK7jjWP57Z89Ua+LIAqLjuU6FN OyykAMsDQERVl4EiUm3U2dnjr0sRqv5owSq3v9SAQKqIE4xKQwdUHtfKPEjZKsAjT1nHllTsB JjxtZmO3Yh0paxyc6QWiVvmH0mnU2Qq4Tf1xlWcYjzqfdlb1lyOUCWOTNedATNt4Ouy7ISpC+ sqkySjJL/K8VN+I07Dj2G2O3QGwNkC3MRR5OoE+YTUxPovi6s4I+g8L5oIz0xPDbl0DLZoa9M BL6/zHtvasMwuDJX88+cmgplk1x74sh11dvCzZM35a7qDKGEffwPxFjXHzUqICNgXOy/8odBg ApZc8xRoBi1+uAL5sd7Ct7SD8yV8IBDa3DJC+6pezH49NKirpetc27TnJMVeuXn6pfXk8E7un s9HPaZl+sB+cBTwzmw6gKPrAgUghjKtu1gAgiTjlbuBhuCi3cyfCAvSB3V05rVVLQt/WZCsHv x9ncwwMqA77sxrFXrcL0e+fB8yQ9LDelPdk7/Me+FWX7HGou4MMxqhWHKhYx9wWSsChy9dQSs JB82Uwe81KMRYOmTjncnb79qxZ+KfSnB2XryfJSgS8D+p0HGLAb2LEvyYwkpijGBVZOJY11a8 5HgjbedNFAPw9g5LxOecZ/kvBbxH3Dbu0+R0MlAT22ms5c5he3mPdHnKKvp2nebDq+Yd0Qzko vW/Ajtc58k28FBtOrYmgglYHmy9X43BPu6fw7IBe4a3W4RYALqcp/JUzZdLkFfx2N3mEZM4kl mfrJBgm 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, 27 Mar 2017 06:43:18 -0000 I have palyed with a FreeBSD 12-CURRENT based router/firewall system and realized, that the trias service netif restart service routing restart service ipfw restart (in any order) doesn't start/restart the ppp session properly, it doesn't even restart ppp. tun0 is gone. I had to manually restart ppp via service ppp stop && sleep 2 && service ppp start A simple service ppp restart fails, the rc script complains about a still running ppp/PID. Stopping ppp, waiting a short time and restarting ppp works fine. Oliver From owner-freebsd-current@freebsd.org Mon Mar 27 08:10:39 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 D7AD8D1F598 for ; Mon, 27 Mar 2017 08:10:39 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 4111E119A for ; Mon, 27 Mar 2017 08:10:38 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MJBRC-1cql2U063u-002oZz for ; Mon, 27 Mar 2017 10:10:36 +0200 Date: Mon, 27 Mar 2017 10:10:29 +0200 From: "O. Hartmann" To: freebsd-current Subject: Howto complete(!) install a world? Message-ID: <20170327101029.1a372c9d@freyja.zeit4.iv.bundesimmobilien.de> Organization: Walstatt X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:pnX6RZvuY9LL1RCYJgDIJF1VdlDdjy+1uyp30IGiTcNX+cjg0NN ntPdbTyc1pQHWNQFLytG4wE+uMfsoYPHwzXeDvD93tiqvuYz8cQiAxiVJJFLWdfdGhNb7a6 jORo95bSbTymWtWhj3FzFo9QE07vST58EVny1R1p9Y93P90RXKAaeZ0NJ04EoQfkD0jPyhl avHlAcoEQ4PlRAPw8+/Ew== X-UI-Out-Filterresults: notjunk:1;V01:K0:LtWoaIb0v2g=:qPd58U3pl4DWLXTii7SsCl nZdn/WqiNJMWPEw/lLS4sUtT+p7esW4MAOLaZ57GByi+Syjt1c3LecgGXQ5NSdxFMlZ7vinKY EsYvYkd6ZEOQqRuwx1gBhxg1kFb6ynO1fNNU08QV1mSD9kWxCb8f+tZdtpkBkQvIlh4Jie/Rk 1fDX1BKf7BWcjBgAFgf893fX6frBFPWNLq7TlCdyxu5L5U3NgIW36GbCaJSRq7j2jWpP8Edgq +uZzdWSgAVg1nxs/J5/AYyw74SP7gPVT/80wfH0w8XxmvciKhfr1LJ0674n707VAMvMgyWy0I e130hjSSHVNSL8ubRsRn+GYHxAaicQqUPQCoCxW4JND9lPptZpe+YuP7t08546MQisf+vH3G1 1QBOmN8Io+WIclV/OcPBZMRDYNfVSXv4P8SQHkNFKknuT2eutzqIfDzliBWM7zhjkA4cQofLH 3P3rCt2Kj+DJWySzYKr0zOOP3VW9d4pK61p8KVhNYKmb0Sy9HbttDsgGT25XdbDJpN65V4DTe q7C74pNcvDUeBdJxk8zum2KPpFTBQzojl/F4xlRZF4U6504kHLNytpp6bMIS3jAAwBoQhe2TI HjReY2jS4edViajvYHrEAczTCnZImtfcLvb9Urv6n5kr14Vi3FvDVsJbV7BIvkLtJKn+TzXmJ o+wvleYKIb4Y9B3bUVG8rCeQzHDnaiPDULgkZc/sjf1fllziWiJz3ahBd7dhe+LmJYNcIhRvZ 1D1jPs9coGKZoFJK3z4+Wd/snEvJRGI0gpJLNex3B1+7ylrPyGq8uqRU6bEBuWZ/Cv4TdPsid gt0/5+nJqGJBMufKZQDRqXcIT+RFJiPAqNiIRi1biA0Ez9mHyaSlscRcK5NEqtGu2D1cqGNHE c2U98LN3LtcF6QBhkufw== 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, 27 Mar 2017 08:10:39 -0000 After a crash in which repeatedly portions of the base tree of FreeBSD has nullified on a SSD system "disk" (UFS), I had to save and repair on Friday, 24th March anno 2017 the broken infrastructure by copying (via pax -rw -p e) the binaries from the recent USB (memstick) image of 23rd provided by freebsd.org download site. After rebuilding and installing a complete "world" (make buildworld on a delete /usr/obj, so to ensure it is empty), I still face a nasty ssh problem (/usr/bin/ssh: Undefined symbol "msetlocale"). I checked the age of the libraries, especially the libraries, which has supposedly been installed and although I did in the past update/buildworld on a daily base, /lib is populated with libraries dated on February, 3rd, and /libexec still has the ld-elf.so libs from 23rd/24th. Using "kldload filemon" in conjuction with /etc/src-env.conf containing WITH_META_MODE= YES I'd expect such a thing, but I got confused with "/lib". Since Feb 3rd, LLVM 4.0 has been introduced and all libs should definitely have been recompiled, haven't they? After rebuilding a "clean" world, I'd like to know how I can force a complete and radical installation of ALL what's in /usr/src and /usr/obj - meaning: how to force the installation process to install even those libs/files/bins which the installer suppose to be not necessary to be installed? After two times rebuilding now world and installing it I can not get rid of this nasty ssh problem which prevents me from login onto remote systems and I suspect a faulty library to be the culprit. libprivatessh.so is installed on every rund of installworld accordingly to its date/ctime, I also delete the *.a and *_p.a archives and had them reinstalled, but without success. Help! Kind regards and thanks in advance, Oliver From owner-freebsd-current@freebsd.org Mon Mar 27 08:31:58 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 40CCFD1E3D6 for ; Mon, 27 Mar 2017 08:31:58 +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 6FDDE1475 for ; Mon, 27 Mar 2017 08:31:56 +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 LAA13167; Mon, 27 Mar 2017 11:31:55 +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 1csQ4A-000GR5-Qm; Mon, 27 Mar 2017 11:31:54 +0300 Subject: Re: New /head/sys/amd64/amd64/genassym.c breaks buildkernel amd64 current To: Manfred Antar , FreeBSD Current References: From: Andriy Gapon Message-ID: <74862f9a-ac5b-e39b-5178-f3db5623c172@FreeBSD.org> Date: Mon, 27 Mar 2017 11:31:18 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: base64 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, 27 Mar 2017 08:31:58 -0000 T24gMDMvMjYvMjAxNyAwMDoyMSwgTWFuZnJlZCBBbnRhciB3cm90ZToNCj4gUmVjZW50IGNo YW5nZSB0byBnZW5hc3N5bS5jIGJyZWFrcyBidWlsZGluZyBhIGN1cnJlbnQga2VybmVsOg0K PiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4+Pj4gc3RhZ2UgMy4xOiBidWlsZGluZyBldmVyeXRoaW5nDQo+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+IGNkIC91c3Ivb2JqL3Vzci9zcmMvc3lzL3Bvem87IENPTVBJTEVSX1ZF UlNJT049NDAwMDAgIENPTVBJTEVSX1RZUEU9Y2xhbmcgIENPTVBJTEVSX0ZSRUVCU0RfVkVS U0lPTj0xMjAwMDA2IE1BS0VPQkpESVJQUkVGSVg9L3Vzci9vYmogIE1BQ0hJTkVfQVJDSD1h bWQ2NCAgTUFDSElORT1hbWQ2NCAgQ1BVVFlQRT0gR1JPRkZfQklOX1BBVEg9L3Vzci9vYmov dXNyL3NyYy90bXAvbGVnYWN5L3Vzci9iaW4gIEdST0ZGX0ZPTlRfUEFUSD0vdXNyL29iai91 c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL3NoYXJlL2dyb2ZmX2ZvbnQgIEdST0ZGX1RNQUNfUEFU SD0vdXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL3NoYXJlL3RtYWMgQ0M9Ii91c3Iv bG9jYWwvYmluL2NjYWNoZSBjYyAtdGFyZ2V0IHg4Nl82NC11bmtub3duLWZyZWVic2QxMi4w IC0tc3lzcm9vdD0vdXNyL29iai91c3Ivc3JjL3RtcCAtQi91c3Ivb2JqL3Vzci9zcmMvdG1w L3Vzci9iaW4iIENYWD0iL3Vzci9sb2NhbC9iaW4vY2NhY2hlIGMrKyAgLXRhcmdldCB4ODZf NjQtdW5rbm93bi1mcmVlYnNkMTIuMCAtLXN5c3Jvb3Q9L3Vzci9vYmovdXNyL3NyYy90bXAg LUIvdXNyL29iai91c3Ivc3JjL3RtcC91c3IvYmluIiAgQ1BQPSJjcHAgLXRhcmdldCB4ODZf NjQtdW5rbm93bi1mcmVlYnNkMTIuMCAtLXN5c3Jvb3Q9L3Vzci9vYmovdXNyL3NyYy90bXAg LUIvdXNyL29iai91c3Ivc3JjL3RtcC91c3IvYmluIiAgQVM9ImFzIiBBUj0iYXIiIExEPSJs ZCIgTExWTV9MSU5LPSIiICBOTT1ubSBPQkpDT1BZPSJvYmpjb3B5IiAgUkFOTElCPXJhbmxp YiBTVFJJTkdTPSAgU0laRT0ic2l6ZSIgIElOU1RBTEw9InNoIC91c3Ivc3JjL3Rvb2xzL2lu c3RhbGwuc2giICBQQVRIPS91c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3Ivc2Jpbjov dXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL2JpbjovdXNyL29iai91c3Ivc3JjL3Rt cC9sZWdhY3kvYmluOi91c3Ivb2JqL3Vzci9zcmMvdG1wL3Vzci9zYmluOi91c3Ivb2JqL3Vz ci9zcmMvdG1wL3Vzci9iaW46L3NiaW46L2JpbjovdXNyL3NiaW46L3Vzci9iaW4gbWFrZSAg LW0gL3Vzci9zcmMvc2hhcmUvbWsgIEtFUk5FTD1rZXJuZWwgYWxsIC1ETk9fTU9EVUxFU19P QkoNCj4gbWFjaGluZSAtPiAvdXNyL3NyYy9zeXMvYW1kNjQvaW5jbHVkZQ0KPiB4ODYgLT4g L3Vzci9zcmMvc3lzL3g4Ni9pbmNsdWRlDQo+IC91c3IvbG9jYWwvYmluL2NjYWNoZSBjYyAt dGFyZ2V0IHg4Nl82NC11bmtub3duLWZyZWVic2QxMi4wIC0tc3lzcm9vdD0vdXNyL29iai91 c3Ivc3JjL3RtcCAtQi91c3Ivb2JqL3Vzci9zcmMvdG1wL3Vzci9iaW4gLWMgLU8yIC1waXBl IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1nIC1ub3N0ZGluYyAtSS4gLUkvdXNyL3NyYy9zeXMg LUkvdXNyL3NyYy9zeXMvY29udHJpYi9saWJmZHQgLURfS0VSTkVMIC1ESEFWRV9LRVJORUxf T1BUSU9OX0hFQURFUlMgLWluY2x1ZGUgb3B0X2dsb2JhbC5oIC1mbm8tb21pdC1mcmFtZS1w b2ludGVyIC1tbm8tb21pdC1sZWFmLWZyYW1lLXBvaW50ZXIgLU1EIC1NRi5kZXBlbmQuZ2Vu YXNzeW0ubyAtTVRnZW5hc3N5bS5vIC1tY21vZGVsPWtlcm5lbCAtbW5vLXJlZC16b25lIC1t bm8tbW14IC1tbm8tc3NlIC1tc29mdC1mbG9hdCAtZm5vLWFzeW5jaHJvbm91cy11bndpbmQt dGFibGVzIC1mZnJlZXN0YW5kaW5nIC1md3JhcHYgLWZzdGFjay1wcm90ZWN0b3IgLWdkd2Fy Zi0yIC1XYWxsIC1XcmVkdW5kYW50LWRlY2xzIC1XbmVzdGVkLWV4dGVybnMgLVdzdHJpY3Qt cHJvdG90eXBlcyAtV21pc3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVdpbmxp bmUgLVdjYXN0LXF1YWwgLVd1bmRlZiAtV25vLXBvaW50ZXItc2lnbiAtRF9fcHJpbnRmX189 X19mcmVlYnNkX2twcmludGZfXyAtV21pc3NpbmctaW5jbHVkZS1kaXJzIC1mZGlhZ25vc3Rp Y3Mtc2hvdy1vcHRpb24gLVduby11bmtub3duLXByYWdtYXMgLVduby1lcnJvci10YXV0b2xv Z2ljYWwtY29tcGFyZSAtV25vLWVycm9yLWVtcHR5LWJvZHkgLVduby1lcnJvci1wYXJlbnRo ZXNlcy1lcXVhbGl0eSAtV25vLWVycm9yLXVudXNlZC1mdW5jdGlvbiAtV25vLWVycm9yLXBv aW50ZXItc2lnbiAtV25vLWVycm9yLXNoaWZ0LW5lZ2F0aXZlLXZhbHVlIC1Xbm8tZXJyb3It YWRkcmVzcy1vZi1wYWNrZWQtbWVtYmVyIC1tbm8tYWVzIC1tbm8tYXZ4IC1zdGQ9aXNvOTg5 OToxOTk5IC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC9nZW5hc3N5bS5jDQo+IEluIGZpbGUg aW5jbHVkZWQgZnJvbSAvdXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQvZ2VuYXNzeW0uYzo0NzoN Cj4gL3Vzci9zcmMvc3lzL3N5cy9idXMuaDo3MzA6MTA6IGZhdGFsIGVycm9yOiAnZGV2aWNl X2lmLmgnIGZpbGUgbm90IGZvdW5kDQo+ICNpbmNsdWRlICJkZXZpY2VfaWYuaCINCj4gICAg ICAgICAgXn5+fn5+fn5+fn5+fg0KPiAxIGVycm9yIGdlbmVyYXRlZC4NCj4gKioqIEVycm9y IGNvZGUgMQ0KPiANCj4gU3RvcC4NCj4gbWFrZVsyXTogc3RvcHBlZCBpbiAvdXNyL29iai91 c3Ivc3JjL3N5cy9wb3pvDQo+ICoqKiBFcnJvciBjb2RlIDENCj4gDQo+IFN0b3AuDQo+IG1h a2VbMV06IHN0b3BwZWQgaW4gL3Vzci9zcmMNCj4gKioqIEVycm9yIGNvZGUgMQ0KPiANCj4g U3RvcC4NCj4gbWFrZTogc3RvcHBlZCBpbiAvdXNyL3NyYw0KPiANCj4gDQo+IGNkIC91c3Iv b2JqL3Vzci9zcmMvc3lzL3Bvem8gOyBtYWtlIGRldmljZV9pZi5oDQo+IGF3ayAtZiAvdXNy L3NyYy9zeXMvdG9vbHMvbWFrZW9iam9wcy5hd2sgL3Vzci9zcmMvc3lzL2tlcm4vZGV2aWNl X2lmLm0gLWgNCj4gDQo+IGFsc28gYnVzX2lmLmggaXMgbWlzc2luZzoNCj4gKHBvem8pNTAy M31tYWtlDQo+IC91c3IvbG9jYWwvYmluL2NjYWNoZSBjYyAtYyAtTzIgLXBpcGUgLWZuby1z dHJpY3QtYWxpYXNpbmcgLWcgLW5vc3RkaW5jIC1JLiAtSS91c3Ivc3JjL3N5cyAtSS91c3Iv c3JjL3N5cy9jb250cmliL2xpYmZkdCAtRF9LRVJORUwgLURIQVZFX0tFUk5FTF9PUFRJT05f SEVBREVSUyAtaW5jbHVkZSBvcHRfZ2xvYmFsLmggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg LW1uby1vbWl0LWxlYWYtZnJhbWUtcG9pbnRlciAtTUQgLU1GLmRlcGVuZC5nZW5hc3N5bS5v IC1NVGdlbmFzc3ltLm8gLW1jbW9kZWw9a2VybmVsIC1tbm8tcmVkLXpvbmUgLW1uby1tbXgg LW1uby1zc2UgLW1zb2Z0LWZsb2F0IC1mbm8tYXN5bmNocm9ub3VzLXVud2luZC10YWJsZXMg LWZmcmVlc3RhbmRpbmcgLWZ3cmFwdiAtZnN0YWNrLXByb3RlY3RvciAtZ2R3YXJmLTIgLVdh bGwgLVdyZWR1bmRhbnQtZGVjbHMgLVduZXN0ZWQtZXh0ZXJucyAtV3N0cmljdC1wcm90b3R5 cGVzIC1XbWlzc2luZy1wcm90b3R5cGVzIC1XcG9pbnRlci1hcml0aCAtV2lubGluZSAtV2Nh c3QtcXVhbCAtV3VuZGVmIC1Xbm8tcG9pbnRlci1zaWduIC1EX19wcmludGZfXz1fX2ZyZWVi c2Rfa3ByaW50Zl9fIC1XbWlzc2luZy1pbmNsdWRlLWRpcnMgLWZkaWFnbm9zdGljcy1zaG93 LW9wdGlvbiAtV25vLXVua25vd24tcHJhZ21hcyAtV25vLWVycm9yLXRhdXRvbG9naWNhbC1j b21wYXJlIC1Xbm8tZXJyb3ItZW1wdHktYm9keSAtV25vLWVycm9yLXBhcmVudGhlc2VzLWVx dWFsaXR5IC1Xbm8tZXJyb3ItdW51c2VkLWZ1bmN0aW9uIC1Xbm8tZXJyb3ItcG9pbnRlci1z aWduIC1Xbm8tZXJyb3Itc2hpZnQtbmVnYXRpdmUtdmFsdWUgLVduby1lcnJvci1hZGRyZXNz LW9mLXBhY2tlZC1tZW1iZXIgLW1uby1hZXMgLW1uby1hdnggLXN0ZD1pc285ODk5OjE5OTkg L3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L2dlbmFzc3ltLmMNCj4gSW4gZmlsZSBpbmNsdWRl ZCBmcm9tIC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC9nZW5hc3N5bS5jOjQ3Og0KPiAvdXNy L3NyYy9zeXMvc3lzL2J1cy5oOjczMToxMDogZmF0YWwgZXJyb3I6ICdidXNfaWYuaCcgZmls ZSBub3QgZm91bmQNCj4gDQo+IHNvOg0KPiBtYWtlIGJ1c19pZi5oDQo+IGF3ayAtZiAvdXNy L3NyYy9zeXMvdG9vbHMvbWFrZW9iam9wcy5hd2sgL3Vzci9zcmMvc3lzL2tlcm4vYnVzX2lm Lm0gLWgNCj4gdGhlbiB0aGUgYnVpbGQgd29ya3M6DQo+IA0KPiBNQUtFPW1ha2Ugc2ggL3Vz ci9zcmMvc3lzL2NvbmYvbmV3dmVycy5zaCAgcG96bw0KPiAtLS0gdmVycy5vIC0tLQ0KPiAv dXNyL2xvY2FsL2Jpbi9jY2FjaGUgY2MgLWMgLU8yIC1waXBlIC1mbm8tc3RyaWN0LWFsaWFz aW5nICAtZyAtbm9zdGRpbmMgIC1JLiAtSS91c3Ivc3JjL3N5cyAtSS91c3Ivc3JjL3N5cy9j b250cmliL2xpYmZkdCAtRF9LRVJORUwgLURIQVZFX0tFUk5FTF9PUFRJT05fSEVBREVSUyAt aW5jbHVkZSBvcHRfZ2xvYmFsLmggIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tbm8tb21p dC1sZWFmLWZyYW1lLXBvaW50ZXIgIC1tY21vZGVsPWtlcm5lbCAtbW5vLXJlZC16b25lIC1t bm8tbW14IC1tbm8tc3NlIC1tc29mdC1mbG9hdCAgLWZuby1hc3luY2hyb25vdXMtdW53aW5k LXRhYmxlcyAtZmZyZWVzdGFuZGluZyAtZndyYXB2IC1mc3RhY2stcHJvdGVjdG9yIC1nZHdh cmYtMiAtV2FsbCAtV3JlZHVuZGFudC1kZWNscyAtV25lc3RlZC1leHRlcm5zIC1Xc3RyaWN0 LXByb3RvdHlwZXMgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdwb2ludGVyLWFyaXRoIC1XaW5s aW5lIC1XY2FzdC1xdWFsIC1XdW5kZWYgLVduby1wb2ludGVyLXNpZ24gLURfX3ByaW50Zl9f PV9fZnJlZWJzZF9rcHJpbnRmX18gLVdtaXNzaW5nLWluY2x1ZGUtZGlycyAtZmRpYWdub3N0 aWNzLXNob3ctb3B0aW9uIC1Xbm8tdW5rbm93bi1wcmFnbWFzIC1Xbm8tZXJyb3ItdGF1dG9s b2dpY2FsLWNvbXBhcmUgLVduby1lcnJvci1lbXB0eS1ib2R5IC1Xbm8tZXJyb3ItcGFyZW50 aGVzZXMtZXF1YWxpdHkgLVduby1lcnJvci11bnVzZWQtZnVuY3Rpb24gLVduby1lcnJvci1w b2ludGVyLXNpZ24gLVduby1lcnJvci1zaGlmdC1uZWdhdGl2ZS12YWx1ZSAtV25vLWVycm9y LWFkZHJlc3Mtb2YtcGFja2VkLW1lbWJlciAgLW1uby1hZXMgLW1uby1hdnggIC1zdGQ9aXNv OTg5OToxOTk5ICAgdmVycy5jDQo+IGN0ZmNvbnZlcnQgLUwgVkVSU0lPTiAtZyB2ZXJzLm8N Cj4gLS0tIGtlcm5lbC5mdWxsIC0tLQ0KPiBsaW5raW5nIGtlcm5lbC5mdWxsDQo+IGN0Zm1l cmdlIC1MIFZFUlNJT04gLWcgLW8ga2VybmVsLmZ1bGwgLi4uDQo+ICAgICAgdGV4dCAgICAg ZGF0YSAgICAgICBic3MgICAgICAgIGRlYyAgICAgICAgaGV4ICAgZmlsZW5hbWUNCj4gICA4 NjU3MDgzICAgODA1NTcwICAgMzM1MDY2NCAgIDEyODEzMzE3ICAgMHhjMzg0MDUgICBrZXJu ZWwuZnVsbA0KPiAtLS0ga2VybmVsLmRlYnVnIC0tLQ0KPiBvYmpjb3B5IC0tb25seS1rZWVw LWRlYnVnIGtlcm5lbC5mdWxsIGtlcm5lbC5kZWJ1Zw0KPiAtLS0ga2VybmVsIC0tLQ0KPiBv Ympjb3B5IC0tc3RyaXAtZGVidWcgLS1hZGQtZ251LWRlYnVnbGluaz1rZXJuZWwuZGVidWcg IGtlcm5lbC5mdWxsIGtlcm5lbA0KPiANCj4gc29tZWhvdyB0aGlzIG5lZWRzIHRvIGhhcHBl biBiZWZvcmUgZ2VuYXNzeW0uYyBpcyBjb21waWxlZA0KPiB0aGlzIGlzIGEga2VybmVsIHdp dGhvdXQgYW55IG1vZHVsZXMNCg0KSSd2ZSBnb3QgYW5vdGhlciByZXBvcnQgYWJvdXQgdGhp cyBwcm9ibGVtLCBidXQgSSBjYW4gbm90IHJlcHJvZHVjZSBpdCBoZXJlIHdpdGgNCmEgY2xl YW4ga2VybmVsIGJ1aWxkIG9mIEdFTkVSSUMuDQpJIGFtIG5vdCBzdXJlIHdoYXQgdGhlIHBy b2JsZW0gaXMuDQpEbyB5b3UgaGF2ZSBhbnl0aGluZyB1bnVzdWFsIGluIG1ha2UuY29uZiwg c3JjLmNvbmYgb3IgeW91ciBrZXJuZWwgY29uZmlndXJhdGlvbj8NCg0KLS0gDQpBbmRyaXkg R2Fwb24NCg== From owner-freebsd-current@freebsd.org Mon Mar 27 08:54: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 2AAD5D1EC68 for ; Mon, 27 Mar 2017 08:54:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-179.reflexion.net [208.70.211.179]) (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 CC2A210B7 for ; Mon, 27 Mar 2017 08:54:26 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31450 invoked from network); 27 Mar 2017 08:57:00 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 27 Mar 2017 08:57:00 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Mon, 27 Mar 2017 04:54:19 -0400 (EDT) Received: (qmail 5865 invoked from network); 27 Mar 2017 08:54:19 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 Mar 2017 08:54:19 -0000 Received: from [192.168.1.119] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id A8E85EC770C for ; Mon, 27 Mar 2017 01:54:18 -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.2 \(3259\)) Subject: Re: Howto complete(!) install a world? Message-Id: Date: Mon, 27 Mar 2017 01:54:18 -0700 To: FreeBSD Current X-Mailer: Apple Mail (2.3259) 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, 27 Mar 2017 08:54:27 -0000 O. Hartmann ohartmann at walstatt.org wrote on Mon Mar 27 08:10:39 UTC = 2017 of: > /usr/bin/ssh: Undefined symbol "msetlocale" I do not know if this will help or not. . . (Notes based on head -r315914 for amd64.) Looking around: # grep -R msetlocale /usr/src/*/ | more /usr/src/crypto/openssh/ssh.c: msetlocale(); /usr/src/crypto/openssh/utf8.h:void msetlocale(void); /usr/src/crypto/openssh/sftp.c: msetlocale(); /usr/src/crypto/openssh/scp.c: msetlocale(); /usr/src/crypto/openssh/utf8.c:msetlocale(void) It looks like msetlocale is local to openssh itself and is tied to utf8 support. # ldd `which ssh` /usr/bin/ssh: libprivatessh.so.5 =3D> /usr/lib/libprivatessh.so.5 = (0x800851000) libgssapi.so.10 =3D> /usr/lib/libgssapi.so.10 (0x800af2000) libcrypto.so.8 =3D> /lib/libcrypto.so.8 (0x800e00000) libc.so.7 =3D> /lib/libc.so.7 (0x801269000) libprivateldns.so.5 =3D> /usr/lib/libprivateldns.so.5 = (0x801624000) libcrypt.so.5 =3D> /lib/libcrypt.so.5 (0x801882000) # objdump -d --prefix-addresses /usr/lib/libprivatessh.so.5 | more /usr/lib/libprivatessh.so.5: file format elf64-x86-64-freebsd . . . 0000000000020e40 push %rbp 0000000000020e41 mov %rsp,%rbp 0000000000020e44 push %rbx 0000000000020e45 push %rax 0000000000020e46 lea 0x4c4e2(%rip),%rdi # = 000000000006d32f <_fini+0x1c67> . . . So it is /usr/lib/libprivateshh.so.5 that should have msetlocale in it. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Mon Mar 27 09:41:54 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 44FD5D1FC9A; Mon, 27 Mar 2017 09:41:54 +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 0F5521791; Mon, 27 Mar 2017 09:41:54 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::5868:2545:a766:52d] (unknown [IPv6:2001:470:7a58:0:5868:2545:a766:52d]) (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 C84B51F951; Mon, 27 Mar 2017 11:41:50 +0200 (CEST) From: Dimitry Andric Message-Id: <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_42849A06-C7A8-45F6-85FA-EA3552BA4953"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) Date: Mon, 27 Mar 2017 11:41:40 +0200 In-Reply-To: <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> Cc: FreeBSD Ports , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current To: Mark Millard References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> X-Mailer: Apple Mail (2.3259) 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, 27 Mar 2017 09:41:54 -0000 --Apple-Mail=_42849A06-C7A8-45F6-85FA-EA3552BA4953 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 26 Mar 2017, at 23:36, Mark Millard wrote: > > I upgraded from llvm40 r4 to final. An interesting result was > its creation of a backup package for llvm40-4.0.0.r4: > > about 13 cpu-core-hours running pkg create > > (Remember: I've been building with WITH_DEBUG= ) Its > single-threaded status stands out via elapsed time > approximately matching. > > I'll note that it was somewhat under 6 elapsed hours for > staging to have been populated (-j4 with 4 cores present > helps for this part). > > (Of course these elapsed-time figures are rather system > dependent, although the ratio might be more stable.) > > > > Also interesting was: > > Installed packages to be REMOVED: > llvm40-4.0.0.r4 > > Number of packages to be removed: 1 > > The operation will free 49 GiB. Yes, this is big. But there is no real need to build the llvm ports with debug information, unless you want to hack on llvm itself. And in that case, you are better served by a Subversion checkout or Git clone from upstream instead. -Dimitry --Apple-Mail=_42849A06-C7A8-45F6-85FA-EA3552BA4953 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 iEYEARECAAYFAljY3l4ACgkQsF6jCi4glqNxXQCeMmQxz2blw4Ebe9kfnfD2Lgst zswAn1d2KmHqe49pG50RRjWtVnrquJMM =phiU -----END PGP SIGNATURE----- --Apple-Mail=_42849A06-C7A8-45F6-85FA-EA3552BA4953-- From owner-freebsd-current@freebsd.org Mon Mar 27 09:49: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 01945D1FF82; Mon, 27 Mar 2017 09:49: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 26AF11CB7; Mon, 27 Mar 2017 09:49:33 +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 MAA13325; Mon, 27 Mar 2017 12:49:32 +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 1csRHI-000GUk-5d; Mon, 27 Mar 2017 12:49:32 +0300 Subject: Re: Opteron 6100-series "Magny-Cours" To: "Jack L." References: <6C0CE842-C900-4914-B362-8DD88C1BDB2E@gmail.com> Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org From: Andriy Gapon Message-ID: <0ff0e9ab-524f-cb0d-87c9-bfec9aa44a4e@FreeBSD.org> Date: Mon, 27 Mar 2017 12:48:10 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <6C0CE842-C900-4914-B362-8DD88C1BDB2E@gmail.com> Content-Type: text/plain; charset=windows-1252 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: Mon, 27 Mar 2017 09:49:35 -0000 On 03/25/2017 23:26, Jack L. wrote: > I have a few still sitting in a corner with FreeBSD 7 or 8 on them. Someday i might put them back on with FreeBSD but not anytime soon Apologies for not qualifying my question. I would like to obtain some information from such a system and possibly to ask to test a patch. Looks like you won't be able to help with that. At least, until that some day :-). >> On Mar 25, 2017, at 11:02 AM, Andriy Gapon wrote: >> >> >> Does anyone [still] use Opteron 6100-series / "Magny-Cours" processors with FreeBSD? -- Andriy Gapon From owner-freebsd-current@freebsd.org Mon Mar 27 10:12: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 28A7FD1FA20 for ; Mon, 27 Mar 2017 10:12:46 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-177.reflexion.net [208.70.211.177]) (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 D0D9E1E9F for ; Mon, 27 Mar 2017 10:12:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 11306 invoked from network); 27 Mar 2017 10:13:38 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 27 Mar 2017 10:13:38 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Mon, 27 Mar 2017 06:12:43 -0400 (EDT) Received: (qmail 20833 invoked from network); 27 Mar 2017 10:12:43 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 Mar 2017 10:12:43 -0000 Received: from [192.168.1.119] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id BD3B2EC7822; Mon, 27 Mar 2017 03:12:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Howto complete(!) install a world? From: Mark Millard In-Reply-To: <20170327115309.0271cd7f@freyja.zeit4.iv.bundesimmobilien.de> Date: Mon, 27 Mar 2017 03:12:42 -0700 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170327115309.0271cd7f@freyja.zeit4.iv.bundesimmobilien.de> To: "O. Hartmann" X-Mailer: Apple Mail (2.3259) 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, 27 Mar 2017 10:12:46 -0000 On 2017-Mar-27, at 2:53 AM, O. Hartmann = wrote: > On Mon, 27 Mar 2017 01:54:18 -0700 > Mark Millard wrote: >=20 >> O. Hartmann ohartmann at walstatt.org wrote on Mon Mar 27 08:10:39 = UTC 2017 >> of: >>=20 >>> /usr/bin/ssh: Undefined symbol "msetlocale" =20 >>=20 >>=20 >> I do not know if this will help or not. . . >> (Notes based on head -r315914 for amd64.) >>=20 >> Looking around: >>=20 >> # grep -R msetlocale /usr/src/*/ | more >> /usr/src/crypto/openssh/ssh.c: msetlocale(); >> /usr/src/crypto/openssh/utf8.h:void msetlocale(void); >> /usr/src/crypto/openssh/sftp.c: msetlocale(); >> /usr/src/crypto/openssh/scp.c: msetlocale(); >> /usr/src/crypto/openssh/utf8.c:msetlocale(void) >>=20 >> It looks like msetlocale is local to openssh itself and is >> tied to utf8 support. >>=20 >> # ldd `which ssh` >> /usr/bin/ssh: >> libprivatessh.so.5 =3D> /usr/lib/libprivatessh.so.5 = (0x800851000) >> libgssapi.so.10 =3D> /usr/lib/libgssapi.so.10 (0x800af2000) >> libcrypto.so.8 =3D> /lib/libcrypto.so.8 (0x800e00000) >> libc.so.7 =3D> /lib/libc.so.7 (0x801269000) >> libprivateldns.so.5 =3D> /usr/lib/libprivateldns.so.5 = (0x801624000) >> libcrypt.so.5 =3D> /lib/libcrypt.so.5 (0x801882000) >>=20 >> # objdump -d --prefix-addresses /usr/lib/libprivatessh.so.5 | more >>=20 >> /usr/lib/libprivatessh.so.5: file format elf64-x86-64-freebsd >> . . . >> 0000000000020e40 push %rbp >> 0000000000020e41 mov %rsp,%rbp >> 0000000000020e44 push %rbx >> 0000000000020e45 push %rax >> 0000000000020e46 lea 0x4c4e2(%rip),%rdi # >> 000000000006d32f <_fini+0x1c67> . . . >>=20 >> So it is /usr/lib/libprivateshh.so.5 that should have >> msetlocale in it. >=20 > I've already deleted that lib manually and "make installworld" did = reinstall > the lib again.=20 >=20 > No effect. >=20 > The problem occurs only on that crashed box :-( Do commands similar to what I showed agree with what I shown? # grep -R msetlocale /usr/src/*/ | more # ldd `which ssh` # objdump -d --prefix-addresses /usr/lib/libprivatessh.so.5 | grep = msetlocale | more (That last presumes that ldd's output points to that file instead of = some alternative.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Mon Mar 27 10:25:08 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 94712D1FDD1 for ; Mon, 27 Mar 2017 10:25:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-173.reflexion.net [208.70.211.173]) (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 45FAC9AD for ; Mon, 27 Mar 2017 10:25:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17928 invoked from network); 27 Mar 2017 10:27:47 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 27 Mar 2017 10:27:47 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Mon, 27 Mar 2017 06:25:06 -0400 (EDT) Received: (qmail 7097 invoked from network); 27 Mar 2017 10:25:06 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 Mar 2017 10:25:06 -0000 Received: from [192.168.1.119] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 9D6F3EC85DE; Mon, 27 Mar 2017 03:25:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) From: Mark Millard In-Reply-To: <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> Date: Mon, 27 Mar 2017 03:25:04 -0700 Cc: FreeBSD Ports , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current Content-Transfer-Encoding: 7bit Message-Id: <45E32F4F-A238-47AA-8E1E-7AD4D9E857D9@dsl-only.net> References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.3259) 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, 27 Mar 2017 10:25:08 -0000 On 2017-Mar-27, at 2:41 AM, Dimitry Andric wrote: > On 26 Mar 2017, at 23:36, Mark Millard wrote: >> >> I upgraded from llvm40 r4 to final. An interesting result was >> its creation of a backup package for llvm40-4.0.0.r4: >> >> about 13 cpu-core-hours running pkg create >> >> (Remember: I've been building with WITH_DEBUG= ) Its >> single-threaded status stands out via elapsed time >> approximately matching. >> >> I'll note that it was somewhat under 6 elapsed hours for >> staging to have been populated (-j4 with 4 cores present >> helps for this part). >> >> (Of course these elapsed-time figures are rather system >> dependent, although the ratio might be more stable.) >> >> >> >> Also interesting was: >> >> Installed packages to be REMOVED: >> llvm40-4.0.0.r4 >> >> Number of packages to be removed: 1 >> >> The operation will free 49 GiB. > > Yes, this is big. But there is no real need to build the llvm ports > with debug information, unless you want to hack on llvm itself. And > in that case, you are better served by a Subversion checkout or Git > clone from upstream instead. > > -Dimitry FYI: Historically unless something extreme like this ends up involved I build everything using WITH_DEBUG= or explicit -g's in order to have better information on any failure. This is extreme enough that next time I synchronize /usr/ports and it has a devel/llvm40 update I'll likely rebuild devel/llvm40 without using WITH_DEBUG= . I'm more concerned with the time it takes than with the file system space involved. === Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Mon Mar 27 10:43:05 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 4F7D5CA139E for ; Mon, 27 Mar 2017 10:43:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-176.reflexion.net [208.70.211.176]) (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 0098A640 for ; Mon, 27 Mar 2017 10:43:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2250 invoked from network); 27 Mar 2017 10:42:58 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 27 Mar 2017 10:42:58 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Mon, 27 Mar 2017 06:42:58 -0400 (EDT) Received: (qmail 26722 invoked from network); 27 Mar 2017 10:42:57 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 Mar 2017 10:42:57 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 34503EC7822; Mon, 27 Mar 2017 03:42:57 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) From: Mark Millard In-Reply-To: <45E32F4F-A238-47AA-8E1E-7AD4D9E857D9@dsl-only.net> Date: Mon, 27 Mar 2017 03:42:56 -0700 Cc: FreeBSD Current , FreeBSD Toolchain , FreeBSD Ports , FreeBSD PowerPC ML Content-Transfer-Encoding: 7bit Message-Id: <849A6761-FF8C-4D28-82C5-4324DED00402@dsl-only.net> References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <45E32F4F-A238-47AA-8E1E-7AD4D9E857D9@dsl-only.net> To: Dimitry Andric X-Mailer: Apple Mail (2.3259) 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, 27 Mar 2017 10:43:05 -0000 On 2017-Mar-27, at 3:25 AM, Mark Millard wrote: > On 2017-Mar-27, at 2:41 AM, Dimitry Andric wrote: > >> On 26 Mar 2017, at 23:36, Mark Millard wrote: >>> >>> I upgraded from llvm40 r4 to final. An interesting result was >>> its creation of a backup package for llvm40-4.0.0.r4: >>> >>> about 13 cpu-core-hours running pkg create >>> >>> (Remember: I've been building with WITH_DEBUG= ) Its >>> single-threaded status stands out via elapsed time >>> approximately matching. >>> >>> I'll note that it was somewhat under 6 elapsed hours for >>> staging to have been populated (-j4 with 4 cores present >>> helps for this part). >>> >>> (Of course these elapsed-time figures are rather system >>> dependent, although the ratio might be more stable.) >>> >>> >>> >>> Also interesting was: >>> >>> Installed packages to be REMOVED: >>> llvm40-4.0.0.r4 >>> >>> Number of packages to be removed: 1 >>> >>> The operation will free 49 GiB. >> >> Yes, this is big. But there is no real need to build the llvm ports >> with debug information, unless you want to hack on llvm itself. And >> in that case, you are better served by a Subversion checkout or Git >> clone from upstream instead. >> >> -Dimitry > > FYI: > > Historically unless something extreme like this ends up > involved I build everything using WITH_DEBUG= or explicit > -g's in order to have better information on any failure. > > This is extreme enough that next time I synchronize > /usr/ports and it has a devel/llvm40 update I'll > likely rebuild devel/llvm40 without using WITH_DEBUG= . > I'm more concerned with the time it takes than with > the file system space involved. [Bad example of a incomplete thought. . .] That last presumes a hardware environment with lots of RAM (such as 16 GiBytes) --which I usually do not have access to. Having such is why the report was from a powerpc64 context: that is where I've access to that much RAM for FreeBSD. === Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Mon Mar 27 10:50:09 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 C1BEACA181B for ; Mon, 27 Mar 2017 10:50:09 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from fmailer.gwdg.de (fmailer.gwdg.de [134.76.11.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 89084C01; Mon, 27 Mar 2017 10:50:08 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from um-excht-a02.um.gwdg.de ([134.76.11.222] helo=email.gwdg.de) by mailer.gwdg.de with esmtp (Exim 4.80) (envelope-from ) id 1csS0H-00073N-4E; Mon, 27 Mar 2017 12:36:01 +0200 Received: from [172.20.200.47] (134.76.242.1) by email.gwdg.de (134.76.9.211) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 27 Mar 2017 12:36:00 +0200 Subject: Re: New /head/sys/amd64/amd64/genassym.c breaks buildkernel amd64 current To: Andriy Gapon References: <74862f9a-ac5b-e39b-5178-f3db5623c172@FreeBSD.org> CC: Manfred Antar , FreeBSD Current From: Rainer Hurling Message-ID: <9b493788-0a91-aa6b-2673-318320d8ca99@gwdg.de> Date: Mon, 27 Mar 2017 13:35:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <74862f9a-ac5b-e39b-5178-f3db5623c172@FreeBSD.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: quoted-printable X-Antivirus: Avast (VPS 170326-0, 26.03.2017), Outbound message X-Antivirus-Status: Clean X-Spam-Level: - X-Virus-Scanned: (clean) by clamav 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, 27 Mar 2017 10:50:09 -0000 Am 27.03.2017 um 10:31 schrieb Andriy Gapon: > On 03/26/2017 00:21, Manfred Antar wrote: >> Recent change to genassym.c breaks building a current kernel: >> >> -------------------------------------------------------------- >>>>> stage 3.1: building everything >> -------------------------------------------------------------- >> cd /usr/obj/usr/src/sys/pozo; COMPILER_VERSION=3D40000 COMPILER_TYPE=3D= clang COMPILER_FREEBSD_VERSION=3D1200006 MAKEOBJDIRPREFIX=3D/usr/obj MA= CHINE_ARCH=3Damd64 MACHINE=3Damd64 CPUTYPE=3D GROFF_BIN_PATH=3D/usr/obj= /usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=3D/usr/obj/usr/src/tmp/legac= y/usr/share/groff_font GROFF_TMAC_PATH=3D/usr/obj/usr/src/tmp/legacy/usr= /share/tmac CC=3D"/usr/local/bin/ccache cc -target x86_64-unknown-freebsd= 12.0 --sysroot=3D/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" CXX= =3D"/usr/local/bin/ccache c++ -target x86_64-unknown-freebsd12.0 --sysro= ot=3D/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" CPP=3D"cpp -ta= rget x86_64-unknown-freebsd12.0 --sysroot=3D/usr/obj/usr/src/tmp -B/usr/o= bj/usr/src/tmp/usr/bin" AS=3D"as" AR=3D"ar" LD=3D"ld" LLVM_LINK=3D"" NM= =3Dnm OBJCOPY=3D"objcopy" RANLIB=3Dranlib STRINGS=3D SIZE=3D"size" INS= TALL=3D"sh /usr/src/tools/install.sh" PATH=3D/usr/obj/usr/src/tmp/legacy= /usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy= /bin:/usr/obj/usr/src/tmp/usr > /sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin make= -m /usr/src/share/mk KERNEL=3Dkernel all -DNO_MODULES_OBJ >> machine -> /usr/src/sys/amd64/include >> x86 -> /usr/src/sys/x86/include >> /usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0 --sysroot=3D= /usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin -c -O2 -pipe -fno-str= ict-aliasing -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfd= t -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-= frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.genassym.o -MTg= enassym.o -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float = -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector = -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -W= missing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-poin= ter-sign -D__printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs -fdiag= nostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare = -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-f= unction -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-erro= r-address-of-packed-member -mno-aes -mno-avx -std=3Diso9 > 899:1999 /usr/src/sys/amd64/amd64/genassym.c >> In file included from /usr/src/sys/amd64/amd64/genassym.c:47: >> /usr/src/sys/sys/bus.h:730:10: fatal error: 'device_if.h' file not fou= nd >> #include "device_if.h" >> ^~~~~~~~~~~~~ >> 1 error generated. >> *** Error code 1 >> >> Stop. >> make[2]: stopped in /usr/obj/usr/src/sys/pozo >> *** Error code 1 >> >> Stop. >> make[1]: stopped in /usr/src >> *** Error code 1 >> >> Stop. >> make: stopped in /usr/src >> >> >> cd /usr/obj/usr/src/sys/pozo ; make device_if.h >> awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m= -h >> >> also bus_if.h is missing: >> (pozo)5023}make >> /usr/local/bin/ccache cc -c -O2 -pipe -fno-strict-aliasing -g -nostdin= c -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNE= L_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-= leaf-frame-pointer -MD -MF.depend.genassym.o -MTgenassym.o -mcmodel=3Dker= nel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind= -tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredund= ant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpoi= nter-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D= __freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno= -unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -W= no-error-parentheses-equality -Wno-error-unused-function -Wno-error-point= er-sign -Wno-error-shift-negative-value -Wno-error-address-of-packed-memb= er -mno-aes -mno-avx -std=3Diso9899:1999 /usr/src/sys/amd64/amd64/genassy= m.c >> In file included from /usr/src/sys/amd64/amd64/genassym.c:47: >> /usr/src/sys/sys/bus.h:731:10: fatal error: 'bus_if.h' file not found >> >> so: >> make bus_if.h >> awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h= >> then the build works: >> >> MAKE=3Dmake sh /usr/src/sys/conf/newvers.sh pozo >> --- vers.o --- >> /usr/local/bin/ccache cc -c -O2 -pipe -fno-strict-aliasing -g -nostdi= nc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KER= NEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse = -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fst= ack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict= -prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wu= ndef -Wno-pointer-sign -D__printf__=3D__freebsd_kprintf__ -Wmissing-inclu= de-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautolo= gical-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-= error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-v= alue -Wno-error-address-of-packed-member -mno-aes -mno-avx -std=3Diso98= 99:1999 vers.c >> ctfconvert -L VERSION -g vers.o >> --- kernel.full --- >> linking kernel.full >> ctfmerge -L VERSION -g -o kernel.full ... >> text data bss dec hex filename >> 8657083 805570 3350664 12813317 0xc38405 kernel.full >> --- kernel.debug --- >> objcopy --only-keep-debug kernel.full kernel.debug >> --- kernel --- >> objcopy --strip-debug --add-gnu-debuglink=3Dkernel.debug kernel.full = kernel >> >> somehow this needs to happen before genassym.c is compiled >> this is a kernel without any modules > I've got another report about this problem, but I can not reproduce it = here with > a clean kernel build of GENERIC. > I am not sure what the problem is. > Do you have anything unusual in make.conf, src.conf or your kernel conf= iguration? > I get the same failures on 12.0-CURRENT amd64 r315794, even if build=20 with generic kernel and without make.conf and src.conf. From owner-freebsd-current@freebsd.org Mon Mar 27 11:08: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 6613ACA1F54 for ; Mon, 27 Mar 2017 11:08:52 +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 734D6C01 for ; Mon, 27 Mar 2017 11:08:50 +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 OAA13581; Mon, 27 Mar 2017 14:08:49 +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 1csSW1-000GZj-6N; Mon, 27 Mar 2017 14:08:49 +0300 Subject: Re: New /head/sys/amd64/amd64/genassym.c breaks buildkernel amd64 current To: Rainer Hurling References: <74862f9a-ac5b-e39b-5178-f3db5623c172@FreeBSD.org> <9b493788-0a91-aa6b-2673-318320d8ca99@gwdg.de> Cc: Manfred Antar , FreeBSD Current From: Andriy Gapon Message-ID: <41a7d9b5-f803-7297-190c-799fa59a9f51@FreeBSD.org> Date: Mon, 27 Mar 2017 14:07:52 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <9b493788-0a91-aa6b-2673-318320d8ca99@gwdg.de> Content-Type: text/plain; charset=windows-1252 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: Mon, 27 Mar 2017 11:08:52 -0000 On 03/27/2017 14:35, Rainer Hurling wrote: > Am 27.03.2017 um 10:31 schrieb Andriy Gapon: >> On 03/26/2017 00:21, Manfred Antar wrote: >>> Recent change to genassym.c breaks building a current kernel: >>> >>> -------------------------------------------------------------- >>>>>> stage 3.1: building everything >>> -------------------------------------------------------------- >>> cd /usr/obj/usr/src/sys/pozo; COMPILER_VERSION=40000 COMPILER_TYPE=clang >>> COMPILER_FREEBSD_VERSION=1200006 MAKEOBJDIRPREFIX=/usr/obj >>> MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= >>> GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin >>> GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font >>> GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac >>> CC="/usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0 >>> --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" >>> CXX="/usr/local/bin/ccache c++ -target x86_64-unknown-freebsd12.0 >>> --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" CPP="cpp >>> -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp >>> -B/usr/obj/usr/src/tmp/usr/bin" AS="as" AR="ar" LD="ld" LLVM_LINK="" NM=nm >>> OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size" INSTALL="sh >>> /usr/src/tools/install.sh" >>> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr >>> >> /sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin make -m >> /usr/src/share/mk KERNEL=kernel all -DNO_MODULES_OBJ >>> machine -> /usr/src/sys/amd64/include >>> x86 -> /usr/src/sys/x86/include >>> /usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0 >>> --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin -c -O2 -pipe >>> -fno-strict-aliasing -g -nostdinc -I. -I/usr/src/sys >>> -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include >>> opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD >>> -MF.depend.genassym.o -MTgenassym.o -mcmodel=kernel -mno-red-zone -mno-mmx >>> -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv >>> -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs >>> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual >>> -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ >>> -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas >>> -Wno-error-tautological-compare -Wno-error-empty-body >>> -Wno-error-parentheses-equality -Wno-error-unused-function >>> -Wno-error-pointer-sign -Wno-error-shift-negative-value >>> -Wno-error-address-of-packed-member -mno-aes -mno-avx -std=iso9 >> 899:1999 /usr/src/sys/amd64/amd64/genassym.c >>> In file included from /usr/src/sys/amd64/amd64/genassym.c:47: >>> /usr/src/sys/sys/bus.h:730:10: fatal error: 'device_if.h' file not found >>> #include "device_if.h" >>> ^~~~~~~~~~~~~ >>> 1 error generated. >>> *** Error code 1 >>> >>> Stop. >>> make[2]: stopped in /usr/obj/usr/src/sys/pozo >>> *** Error code 1 >>> >>> Stop. >>> make[1]: stopped in /usr/src >>> *** Error code 1 >>> >>> Stop. >>> make: stopped in /usr/src >>> >>> >>> cd /usr/obj/usr/src/sys/pozo ; make device_if.h >>> awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h >>> >>> also bus_if.h is missing: >>> (pozo)5023}make >>> /usr/local/bin/ccache cc -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. >>> -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL >>> -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer >>> -mno-omit-leaf-frame-pointer -MD -MF.depend.genassym.o -MTgenassym.o >>> -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float >>> -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector >>> -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes >>> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef >>> -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs >>> -fdiagnostics-show-option -Wno-unknown-pragmas >>> -Wno-error-tautological-compare -Wno-error-empty-body >>> -Wno-error-parentheses-equality -Wno-error-unused-function >>> -Wno-error-pointer-sign -Wno-error-shift-negative-value >>> -Wno-error-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999 >>> /usr/src/sys/amd64/amd64/genassym.c >>> In file included from /usr/src/sys/amd64/amd64/genassym.c:47: >>> /usr/src/sys/sys/bus.h:731:10: fatal error: 'bus_if.h' file not found >>> >>> so: >>> make bus_if.h >>> awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h >>> then the build works: >>> >>> MAKE=make sh /usr/src/sys/conf/newvers.sh pozo >>> --- vers.o --- >>> /usr/local/bin/ccache cc -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. >>> -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL >>> -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer >>> -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse >>> -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv >>> -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs >>> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual >>> -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ >>> -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas >>> -Wno-error-tautological-compare -Wno-error-empty-body >>> -Wno-error-parentheses-equality -Wno-error-unused-function >>> -Wno-error-pointer-sign -Wno-error-shift-negative-value >>> -Wno-error-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999 >>> vers.c >>> ctfconvert -L VERSION -g vers.o >>> --- kernel.full --- >>> linking kernel.full >>> ctfmerge -L VERSION -g -o kernel.full ... >>> text data bss dec hex filename >>> 8657083 805570 3350664 12813317 0xc38405 kernel.full >>> --- kernel.debug --- >>> objcopy --only-keep-debug kernel.full kernel.debug >>> --- kernel --- >>> objcopy --strip-debug --add-gnu-debuglink=kernel.debug kernel.full kernel >>> >>> somehow this needs to happen before genassym.c is compiled >>> this is a kernel without any modules >> I've got another report about this problem, but I can not reproduce it here with >> a clean kernel build of GENERIC. >> I am not sure what the problem is. >> Do you have anything unusual in make.conf, src.conf or your kernel configuration? >> > I get the same failures on 12.0-CURRENT amd64 r315794, even if build with > generic kernel and without make.conf and src.conf. Looks like it could be a timing issue because of a new dependency that is not declared in the make files. I am going to revert the commit while I am figuring out the details. -- Andriy Gapon From owner-freebsd-current@freebsd.org Mon Mar 27 11:13:26 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 9B6B8CA262F for ; Mon, 27 Mar 2017 11:13:26 +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 60AF1BBA for ; Mon, 27 Mar 2017 11:13:25 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.127] (helo=rmmprod05.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1csSaL-0005Ml-56; Mon, 27 Mar 2017 13:13:17 +0200 Received: from mail by rmmprod05.runbox with local (Exim 4.86_2) (envelope-from ) id 1csSaL-0007HS-15; Mon, 27 Mar 2017 13:13:17 +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); Mon, 27 Mar 2017 11:13:16 GMT From: "Jeffrey Bouquet" Reply-To: jbtakk@iherebuywisely.com To: "O. Hartmann" CC: "freebsd-current" Subject: Re: Howto complete(!) install a world? Date: Mon, 27 Mar 2017 04:13:16 -0700 (PDT) X-Mailer: RMM6 In-Reply-To: <20170327101029.1a372c9d@freyja.zeit4.iv.bundesimmobilien.de> 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: Mon, 27 Mar 2017 11:13:26 -0000 On Mon, 27 Mar 2017 10:10:29 +0200, "O. Hartmann" = wrote: > After a crash in which repeatedly portions of the base tree of FreeBSD has > nullified on a SSD system "disk" (UFS), I had to save and repair on Frida= y, > 24th March anno 2017 the broken infrastructure by copying (via pax -rw -p= e) > the binaries from the recent USB (memstick) image of 23rd provided by > freebsd.org download site. >=20 > After rebuilding and installing a complete "world" (make buildworld on a > delete /usr/obj, so to ensure it is empty), I still face a nasty ssh prob= lem > (/usr/bin/ssh: Undefined symbol "msetlocale"). >=20 > I checked the age of the libraries, especially the libraries, which has > supposedly been installed and although I did in the past update/buildworl= d on a > daily base, /lib is populated with libraries dated on February, 3rd, > and /libexec still has the ld-elf.so libs from 23rd/24th.=20 >=20 > Using "kldload filemon" in conjuction with /etc/src-env.conf containing > WITH_META_MODE=3D YES I'd expect such a thing, but I got confused= with > "/lib". Since Feb 3rd, LLVM 4.0 has been introduced and all libs should > definitely have been recompiled, haven't they? >=20 > After rebuilding a "clean" world, I'd like to know how I can force a comp= lete > and radical installation of ALL what's in /usr/src and /usr/obj - meaning= : how > to force the installation process to install even those libs/files/bins w= hich > the installer suppose to be not necessary to be installed? >=20 > After two times rebuilding now world and installing it I can not get rid = of > this nasty ssh problem which prevents me from login onto remote systems a= nd I > suspect a faulty library to be the culprit. libprivatessh.so is installed= on > every rund of installworld accordingly to its date/ctime, I also delete t= he *.a > and *_p.a archives and had them reinstalled, but without success. >=20 > Help! >=20 > Kind regards and thanks in advance, >=20 > Oliver > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" This highlights what I think is one of my foremost concerns as to 'why not = is part of FreeBSD yet' .... namely the proof that an installworld can complete [think 'foolproof staging' ] before the installworld is actually 'ENTER' ke= yed... ................ b... fallback /var/db/pkg flat file pkg equivalent re-done and CARP-like = failover c... 2005 era install bsd ncurses menus allowing setting partitions and t= ype d... pkg updates to allow 'beastie boot menu 'choose options' style fixin= g of each line in each FreeBSD.conf and pkg.conf so that they are what pkg expects to be there, vs what are there... if you grasp that. e... lint >> GENERIC heavily commented to allow... f... e1... an ncurses-build-line-by-line-completion of a kernel file so= that each line omit/include is understood as to consequence AKA bios me= nus. g... flow chart [ 8 sided raw disk >> 8 side which raid do you want huge= 2 meter by two meter ZFS decision tree aka shareware 1998 style inclusion= s, some of them so one does not depend upon guides from, say, Solaris h.... more, but that should do. Just tacking on gossip, sorry... please = read the three lines above this list so I do not de-emphasize the point= of this reply, and thank you so very kindly for reading. =20 Sort of like a 'me too...'=20=20=20= From owner-freebsd-current@freebsd.org Mon Mar 27 06:23:16 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 E1EC4D1F495 for ; Mon, 27 Mar 2017 06:23:16 +0000 (UTC) (envelope-from o.hartmann@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 4A2791829 for ; Mon, 27 Mar 2017 06:23:15 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MIuft-1cqS712hh3-002bM3; Mon, 27 Mar 2017 08:23:06 +0200 Date: Mon, 27 Mar 2017 08:23:05 +0200 From: "O. Hartmann" To: Andreas Nilsson Cc: "O. Hartmann" , freebsd-current Subject: Re: r315900: /usr/bin/ssh: Undefined symbol "msetlocale" Message-ID: <20170327082305.4b48021f@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: References: <20170324143738.0d676402@freyja.zeit4.iv.bundesimmobilien.de> Organization: Walstatt X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:DuT1wdOkPHl3rFdW1weZIqkTrIXTVG7idTGo+9AveBp7lawjrIh vX3Xp3lVn4pOVV0UAHOImOwrHNv6oha2pg9Alafc8L7/gvnVl3Dy6IfyjroZ9WrF4Qdsrui h5//gSS+iuphzfFYv9uA6mceCA/6qJnx3C3tVE/rOglv8/hCUClX6GSESoDh2zZMGAD1UTx 31MgLRNaS84Giph0TsHsQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:obFqjTqb/Oc=:ZP2lAcPm4SI96Zo9UDGjGo aVbFREnhFd8f2MVt73/BjTAyCUtQ8LJd3rHoDIUYatlWSGkT55xdeahoTQtbALZeVS5MyM5IS B7wMfQHHMvWH33P2tCb5M8+kKXA9Cx8p7bWWgLWI72STKDHlGZx7hvypM5Ok8zYdiGfAmwLMJ wvJZywZ7uAO70rLTl6wfirPThhPBgoHhGvj6G3qoKe6ZHN/QV0p0nqsq1WsamoUuc7/FhenlG F0BN1lzXt6tvKxFTZfcWULPdfepvW5EUqE+Ipu7+Dn0Gzq2EFz5Ama6/K08vKaasZWLgW6oBO rHqSRzaP8RRZHBe2lX2gBN1LDwSM0g3bbILzAVOXxe8NsYW4jtUtpusK1OoslOm6wOzu2tHqB NVNp8knXvEXxLDm9oJqbrwL/1fs53JXMhNyFNfnbkKib7wLnhHCYgkmR9n4ix1VYwETjgzNxC jO5d2j2j+lssN3jeXdYjUO6GgEsXBbiBMm6Kxh45IzidQZLH1WadIozkJdGbBNyqX5LXRH+Wf DD+6n8ZTsHBrCxhZOo/sK0VvE9oxBZX9JLoQYT225GZYDahY+3wjw19mnTMx3cQ9CbFpHLKOr a6Y+tcB+YBUKf+ggpPscUs9KsNh/RmFN9ikG49dDA0agWs9fUNeQ7Z+mE/NzSVm/7Mpm0Fflv ghHwjcyXwvIzjJLaY3VoLeh/QfPGq4NWD8rg1N62S94tiLWOepi6VdjD8T8epvVy62+gYTjS1 JHUjid+vz3bdVKTYKy68LZ9YrPeF0yLcRb2UusTXkmdYUQX03j7rXQuQ+6HysxbY1nxf0uAgV oRkHfOM X-Mailman-Approved-At: Mon, 27 Mar 2017 11:34:57 +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: Mon, 27 Mar 2017 06:23:17 -0000 On Fri, 24 Mar 2017 15:28:31 +0100 Andreas Nilsson wrote: > On Fri, Mar 24, 2017 at 2:37 PM, O. Hartmann wrote: > > > Having just updated CURRENT to CURRENT 12.0-CURRENT FreeBSD 12.0-CURRENT #1 > > r315900: Fri Mar 24 14:17:22 CET 2017 amd64, I can not connect to remote > > systems via ssh anymore: > > > > /usr/bin/ssh: Undefined symbol "msetlocale" > > > > Google suggests for this kind of error a miscompilation of the binary. > > > > I had a crash, again (SSDs and CURRENT have a serious problem!), had to > > improvise with the USB flash ISO image of CURRENT found on FreeBSD.org from > > 23.03.2017, ~ 18 o'clock, but have rebuilt and installed world and kernel > > from a > > clean /usr/obj two times. Still being bugged by this mysterious error. > > > > Can somebody help, please? > > > > Thanks in advance, > > Oliver > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > > I haven't upgraded myself yet, but I fetched the sources. > > Could you check ldd /usr/bin/ssh ? > If you have libprivatessh in there, could you do nm -D > /usr/lib/libprivatessh.so | grep msetlocale and see if you get any output ( > I think you should get one line ) > > Otherwise it would seem that either libprivatessh is not built correctly or > that it is not installed correctly. But these are just my guesses. > > Best regards > Andreas > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" The answer to nm -D is: 0000000000021690 T msetlocale I have finished a buildworld from a fresh (clean/empty /usr/obj/ ) start and give that a try as soon I can installworkd/installkernel and reboot. Thank you very much, Oliver From owner-freebsd-current@freebsd.org Mon Mar 27 09:53:16 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 66D9DD1F3BA for ; Mon, 27 Mar 2017 09:53:16 +0000 (UTC) (envelope-from o.hartmann@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 BB9901394 for ; Mon, 27 Mar 2017 09:53:15 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MPlY2-1cobqv1htS-00501I; Mon, 27 Mar 2017 11:53:11 +0200 Date: Mon, 27 Mar 2017 11:53:09 +0200 From: "O. Hartmann" To: Mark Millard Cc: FreeBSD Current Subject: Re: Howto complete(!) install a world? Message-ID: <20170327115309.0271cd7f@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: References: Organization: Walstatt X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:HDVz+NbYZawpnSKaSUxOYFDcwIZtXO1nG7+k6IlJ91jkjlFLKu5 KGy6P3EpqemTn8usXGAHCyAN5vvsSenDFENsFSl/19vQg3rct1T/o67nxYUtFrKCZN6XpU1 /x3DZ00cksIg1TwMtvY9M785IooSuO9Of6hsnrd5POeKidkN+sWbODES9UqGfEv4CAvsdFN f73zKTgOWbW3zs2SX+6sw== X-UI-Out-Filterresults: notjunk:1;V01:K0:mn+ekiOz0XA=:rzlZbViu9krZSxKkt2vj3T bXagqZt8bup0Ri7I6iQ6C+ffewFq82LIPqr90GOUG4YR0FCOxQ0/XAdseW7lsPa/0tjaOj8zp G949RTdTSVvdCHQ7quxt3CyosgPwxX6aehTcpoA6zRTrEsJiAeYng++a7ABED5qGVIgpg+Xnc 3zWDZv9vT5bTigs7i2qd4x6JxnegHmb3EMD6sfXACmN3y2J55L+qgtYLxzVIVVDgVfoYPUZD5 /TnlimbqCPjrocvRIeYsdI4b05SMU60cdNb/jc0NknlGkCEdUINWcUj4iCQYCUFqMHi8LujiH oHFsA+bUJr9FH1t/f8UmqY+lkBoNR6x2Ys8c60wGerJTY0ynivxN+q1RFnRjjpwRlt9F1yqDT u1D4wOwJBV5XdCD9yb7T418RGxOPbR6piqhbZFr/KBksMo7Truh4xl87c89y0meE/fphWCFgS 5SHLMV+DbiHybI0Z4HkrnbjHRixRuslHmgxUvykoNRNJ8aFGeb92ijperN3bnv5QKkZhwZhgd y/ti+q5jDIW9LrtlNFFAjn4FodhF0+a6eFcp3nyJM4ticUugUWchmLmphdPEpykVmn6nve/2q P/Uql6ha1WnSN9LUGBDo6u89Pdm21jbHPqMvnb98eMFS6FILmUKgLGDRFJzyn0q6Y/ZPXU0Cm /CSBNP3XsT4JOI5TlMlLP3Jr7OynyrtA/+Vi9x46EgYSnqbHPb8wmkCZjZ+ZpCiEYBL2cSmwd f5/2R9oMu5MrnMQqrJKYeqjJnx+EpMxgGjdywjs4qjp937rsDlTc0vcXuUUBRUS0aRWc65dck wFj34Gg X-Mailman-Approved-At: Mon, 27 Mar 2017 11:36:04 +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: Mon, 27 Mar 2017 09:53:16 -0000 On Mon, 27 Mar 2017 01:54:18 -0700 Mark Millard wrote: > O. Hartmann ohartmann at walstatt.org wrote on Mon Mar 27 08:10:39 UTC 2017 > of: > > > /usr/bin/ssh: Undefined symbol "msetlocale" > > > I do not know if this will help or not. . . > (Notes based on head -r315914 for amd64.) > > Looking around: > > # grep -R msetlocale /usr/src/*/ | more > /usr/src/crypto/openssh/ssh.c: msetlocale(); > /usr/src/crypto/openssh/utf8.h:void msetlocale(void); > /usr/src/crypto/openssh/sftp.c: msetlocale(); > /usr/src/crypto/openssh/scp.c: msetlocale(); > /usr/src/crypto/openssh/utf8.c:msetlocale(void) > > It looks like msetlocale is local to openssh itself and is > tied to utf8 support. > > # ldd `which ssh` > /usr/bin/ssh: > libprivatessh.so.5 => /usr/lib/libprivatessh.so.5 (0x800851000) > libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x800af2000) > libcrypto.so.8 => /lib/libcrypto.so.8 (0x800e00000) > libc.so.7 => /lib/libc.so.7 (0x801269000) > libprivateldns.so.5 => /usr/lib/libprivateldns.so.5 (0x801624000) > libcrypt.so.5 => /lib/libcrypt.so.5 (0x801882000) > > # objdump -d --prefix-addresses /usr/lib/libprivatessh.so.5 | more > > /usr/lib/libprivatessh.so.5: file format elf64-x86-64-freebsd > . . . > 0000000000020e40 push %rbp > 0000000000020e41 mov %rsp,%rbp > 0000000000020e44 push %rbx > 0000000000020e45 push %rax > 0000000000020e46 lea 0x4c4e2(%rip),%rdi # > 000000000006d32f <_fini+0x1c67> . . . > > So it is /usr/lib/libprivateshh.so.5 that should have > msetlocale in it. I've already deleted that lib manually and "make installworld" did reinstall the lib again. No effect. The problem occurs only on that crashed box :-( > > > === > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Mon Mar 27 10:09: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 3CCB4D1F6FD; Mon, 27 Mar 2017 10:09:45 +0000 (UTC) (envelope-from ml@netfence.it) Received: from smtp208.alice.it (smtp208.alice.it [82.57.200.104]) by mx1.freebsd.org (Postfix) with ESMTP id E8E461A20; Mon, 27 Mar 2017 10:09:44 +0000 (UTC) (envelope-from ml@netfence.it) Received: from soth.ventu (82.52.25.226) by smtp208.alice.it (8.6.060.28) (authenticated as acanedi@alice.it) id 588F42930A8B18FF; Mon, 27 Mar 2017 12:09:33 +0200 Received: from alamar.ventu (alamar.local.netfence.it [10.1.2.18]) by soth.ventu (8.15.2/8.15.2) with ESMTP id v2RA9X3T063176; Mon, 27 Mar 2017 12:09:36 +0200 (CEST) (envelope-from ml@netfence.it) X-Authentication-Warning: soth.ventu: Host alamar.local.netfence.it [10.1.2.18] claimed to be alamar.ventu Subject: Re: Opteron 6100-series "Magny-Cours" To: Andriy Gapon , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org References: From: Andrea Venturoli Message-ID: Date: Mon, 27 Mar 2017 12:09:30 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 27 Mar 2017 11:36:16 +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: Mon, 27 Mar 2017 10:09:45 -0000 On 03/25/17 19:02, Andriy Gapon wrote: > > Does anyone [still] use Opteron 6100-series / "Magny-Cours" processors with FreeBSD? Will an equivalent Athlon do or is this Opteron specific? What would that Athlon be? bye av. From owner-freebsd-current@freebsd.org Mon Mar 27 12:06:40 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 B7018D20544 for ; Mon, 27 Mar 2017 12:06:40 +0000 (UTC) (envelope-from pkubaj@anongoth.pl) Received: from mail.anongoth.pl (anongoth.pl [88.156.79.165]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anongoth.pl", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 760D0A6D for ; Mon, 27 Mar 2017 12:06:39 +0000 (UTC) (envelope-from pkubaj@anongoth.pl) Received: from anongoth.pl (unknown [46.248.161.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: pkubaj@anongoth.pl) by mail.anongoth.pl (Postfix) with ESMTPSA id 5E6522EBA2 for ; Mon, 27 Mar 2017 14:06:32 +0200 (CEST) Authentication-Results: mail.anongoth.pl; dmarc=none header.from=anongoth.pl DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=anongoth.pl; s=ANONGOTH; t=1490616392; bh=+Ge3H65xoNVF1yts1KhaAIeq2yzLGS1Y5zVzFcGAiIE=; h=Date:From:To:Subject:References:In-Reply-To; b=dSaeDiZp1lhtSqxFzoprv/gGDrBKoYCPhs3HhE6p/a10WyZJ0a7eRsHRYO/l5SD15 Ub6Od0Y/Ju2EmNyIn0IvOFavpXf/xTbsgLkNJKv2OEp7JZAkm701KHrf3PEttqujFq l3y5cit2gEy6UOTx4njrWQPBNR9p49636+7wM2ePeZUmLQp3hetNgmmtOfLCuBpyzR qqJuRwXCFZXR165Fac4wimUpdBkgtIvSshDMmorj/yEQOv95B01eGGQR8FSXbO0qCC RkJs7fi0UG558S4ZK0jh6sFAjo/xOSmetp7rH2ve/79LsJdgzHlElHVWc0s0yUXLbb imPdFPF4ITnWA== Date: Mon, 27 Mar 2017 14:06:31 +0200 From: Piotr Kubaj To: freebsd-current@freebsd.org Subject: Re: Opteron 6100-series "Magny-Cours" Message-ID: <20170327120631.GB36590@chujemuje> Mail-Followup-To: freebsd-current@freebsd.org References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-Mailman-Approved-At: Mon, 27 Mar 2017 12:25:48 +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: Mon, 27 Mar 2017 12:06:40 -0000 --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Does it have to be specifically 61xx series? I have a server running 2 6262HE's. --IS0zKkzwUGydFO0o Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEycyIeNkkgohzsoorelmbhSCDnJ0FAljZAEcACgkQelmbhSCD nJ2vxw/+Ps8snULU9RyDKXicvFO4tcfJJG4meKIRxP4cLJuihA/QzPgvrLlZNo5I VO+rnu5iRyZOLzh4Uj4b31wKfD/P7HXAplXFnIKcJqSmk3PQPY9M7zcM7B8hs/W9 kfFWXkQMtxxBaapRLLnPb0CrySGkuUNLqhrjY+WUQx6QbyX1x2mfMS2XWF/bTz9H D8IUs+0QvWwYKIpBijsWkVwO5LMGIn/1NPd/f0KNOLoo8JClhy9HBxE8LaHWa6jx gvNwJod7lHilsvfF0YnSs4R3JCg4uOn0oiy479kU0i/dEqZnIhg8pm2WUQSNeqS5 hPjsaZKCVtKJR1NubOfu66G+CeVJBRxJzj34tGZ0uSdgplfa4yYfkTyjOC79JqDI VVz1lSdvP1uJC8XLVspi4wHvJ9NP5mRz7BxBxgPGnKjfPWtJ8WQhfaytEKuMP3P0 P2D3r1m8x8HUjIg/SMF/wUbWMY1QPmQwFFrwHYEAfD7roZtqPTVl1aZcZK0jiVqh uasEj/KudS+qIdjiFbviJWc2hWB0VcNgpkdTwjBXpfpVZQxgdk01zzXFT6UFrYis dO72/umjT86t2YkGgmVsfJkP4zjkCJV5EUw1DRkeiDTdQqZktSJHYDNtDNbqjHhi BK0vcSapVvE6/+50Krw1emLBzDwk/EW4uYG9eWsxOpFVX9MxPTA= =FyND -----END PGP SIGNATURE----- --IS0zKkzwUGydFO0o-- From owner-freebsd-current@freebsd.org Mon Mar 27 12:34:56 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 29BA7D20E8D for ; Mon, 27 Mar 2017 12:34:56 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from fmailer.gwdg.de (fmailer.gwdg.de [134.76.11.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 E3EFFDAD; Mon, 27 Mar 2017 12:34:55 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from um-excht-a01.um.gwdg.de ([134.76.11.221] helo=email.gwdg.de) by mailer.gwdg.de with esmtp (Exim 4.80) (envelope-from ) id 1csTrH-00008n-7b; Mon, 27 Mar 2017 14:34:51 +0200 Received: from [172.20.200.47] (134.76.242.1) by email.gwdg.de (134.76.9.210) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 27 Mar 2017 14:34:50 +0200 Subject: Re: New /head/sys/amd64/amd64/genassym.c breaks buildkernel amd64 current To: Andriy Gapon References: <74862f9a-ac5b-e39b-5178-f3db5623c172@FreeBSD.org> <9b493788-0a91-aa6b-2673-318320d8ca99@gwdg.de> <41a7d9b5-f803-7297-190c-799fa59a9f51@FreeBSD.org> CC: Manfred Antar , FreeBSD Current From: Rainer Hurling Message-ID: <25df8c27-f223-91d6-eab4-60d175164f9f@gwdg.de> Date: Mon, 27 Mar 2017 15:34:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <41a7d9b5-f803-7297-190c-799fa59a9f51@FreeBSD.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: Avast (VPS 170326-0, 26.03.2017), Outbound message X-Antivirus-Status: Clean X-Spam-Level: - X-Virus-Scanned: (clean) by clamav 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, 27 Mar 2017 12:34:56 -0000 Am 27.03.2017 um 13:07 schrieb Andriy Gapon: > On 03/27/2017 14:35, Rainer Hurling wrote: >> Am 27.03.2017 um 10:31 schrieb Andriy Gapon: >>> On 03/26/2017 00:21, Manfred Antar wrote: >>>> Recent change to genassym.c breaks building a current kernel: >>>> >>>> -------------------------------------------------------------- >>>>>>> stage 3.1: building everything >>>> -------------------------------------------------------------- >>>> cd /usr/obj/usr/src/sys/pozo; COMPILER_VERSION=40000 COMPILER_TYPE=clang >>>> COMPILER_FREEBSD_VERSION=1200006 MAKEOBJDIRPREFIX=/usr/obj >>>> MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= >>>> GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin >>>> GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font >>>> GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac >>>> CC="/usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0 >>>> --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" >>>> CXX="/usr/local/bin/ccache c++ -target x86_64-unknown-freebsd12.0 >>>> --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" CPP="cpp >>>> -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp >>>> -B/usr/obj/usr/src/tmp/usr/bin" AS="as" AR="ar" LD="ld" LLVM_LINK="" NM=nm >>>> OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size" INSTALL="sh >>>> /usr/src/tools/install.sh" >>>> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr >>>> >>> /sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin make -m >>> /usr/src/share/mk KERNEL=kernel all -DNO_MODULES_OBJ >>>> machine -> /usr/src/sys/amd64/include >>>> x86 -> /usr/src/sys/x86/include >>>> /usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0 >>>> --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin -c -O2 -pipe >>>> -fno-strict-aliasing -g -nostdinc -I. -I/usr/src/sys >>>> -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include >>>> opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD >>>> -MF.depend.genassym.o -MTgenassym.o -mcmodel=kernel -mno-red-zone -mno-mmx >>>> -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv >>>> -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs >>>> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual >>>> -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ >>>> -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas >>>> -Wno-error-tautological-compare -Wno-error-empty-body >>>> -Wno-error-parentheses-equality -Wno-error-unused-function >>>> -Wno-error-pointer-sign -Wno-error-shift-negative-value >>>> -Wno-error-address-of-packed-member -mno-aes -mno-avx -std=iso9 >>> 899:1999 /usr/src/sys/amd64/amd64/genassym.c >>>> In file included from /usr/src/sys/amd64/amd64/genassym.c:47: >>>> /usr/src/sys/sys/bus.h:730:10: fatal error: 'device_if.h' file not found >>>> #include "device_if.h" >>>> ^~~~~~~~~~~~~ >>>> 1 error generated. >>>> *** Error code 1 >>>> >>>> Stop. >>>> make[2]: stopped in /usr/obj/usr/src/sys/pozo >>>> *** Error code 1 >>>> >>>> Stop. >>>> make[1]: stopped in /usr/src >>>> *** Error code 1 >>>> >>>> Stop. >>>> make: stopped in /usr/src >>>> >>>> >>>> cd /usr/obj/usr/src/sys/pozo ; make device_if.h >>>> awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h >>>> >>>> also bus_if.h is missing: >>>> (pozo)5023}make >>>> /usr/local/bin/ccache cc -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. >>>> -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL >>>> -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer >>>> -mno-omit-leaf-frame-pointer -MD -MF.depend.genassym.o -MTgenassym.o >>>> -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float >>>> -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector >>>> -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes >>>> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef >>>> -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs >>>> -fdiagnostics-show-option -Wno-unknown-pragmas >>>> -Wno-error-tautological-compare -Wno-error-empty-body >>>> -Wno-error-parentheses-equality -Wno-error-unused-function >>>> -Wno-error-pointer-sign -Wno-error-shift-negative-value >>>> -Wno-error-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999 >>>> /usr/src/sys/amd64/amd64/genassym.c >>>> In file included from /usr/src/sys/amd64/amd64/genassym.c:47: >>>> /usr/src/sys/sys/bus.h:731:10: fatal error: 'bus_if.h' file not found >>>> >>>> so: >>>> make bus_if.h >>>> awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h >>>> then the build works: >>>> >>>> MAKE=make sh /usr/src/sys/conf/newvers.sh pozo >>>> --- vers.o --- >>>> /usr/local/bin/ccache cc -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. >>>> -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL >>>> -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer >>>> -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse >>>> -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv >>>> -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs >>>> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual >>>> -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ >>>> -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas >>>> -Wno-error-tautological-compare -Wno-error-empty-body >>>> -Wno-error-parentheses-equality -Wno-error-unused-function >>>> -Wno-error-pointer-sign -Wno-error-shift-negative-value >>>> -Wno-error-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999 >>>> vers.c >>>> ctfconvert -L VERSION -g vers.o >>>> --- kernel.full --- >>>> linking kernel.full >>>> ctfmerge -L VERSION -g -o kernel.full ... >>>> text data bss dec hex filename >>>> 8657083 805570 3350664 12813317 0xc38405 kernel.full >>>> --- kernel.debug --- >>>> objcopy --only-keep-debug kernel.full kernel.debug >>>> --- kernel --- >>>> objcopy --strip-debug --add-gnu-debuglink=kernel.debug kernel.full kernel >>>> >>>> somehow this needs to happen before genassym.c is compiled >>>> this is a kernel without any modules >>> I've got another report about this problem, but I can not reproduce it here with >>> a clean kernel build of GENERIC. >>> I am not sure what the problem is. >>> Do you have anything unusual in make.conf, src.conf or your kernel configuration? >>> >> I get the same failures on 12.0-CURRENT amd64 r315794, even if build with >> generic kernel and without make.conf and src.conf. > Looks like it could be a timing issue because of a new dependency that is not > declared in the make files. > I am going to revert the commit while I am figuring out the details. > Seems, like r315959 is the culprit. At least, until r315958, the kernel sources build for me. From owner-freebsd-current@freebsd.org Mon Mar 27 12:53:48 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 7A131D2043C; Mon, 27 Mar 2017 12:53:48 +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 42BC6A09; Mon, 27 Mar 2017 12:53:48 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::5868:2545:a766:52d] (unknown [IPv6:2001:470:7a58:0:5868:2545:a766:52d]) (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 C37DA1F968; Mon, 27 Mar 2017 14:53:45 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_54747A7A-60FC-41AE-A610-0C40033DAA05"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) Date: Mon, 27 Mar 2017 14:53:39 +0200 In-Reply-To: <45E32F4F-A238-47AA-8E1E-7AD4D9E857D9@dsl-only.net> Cc: FreeBSD Ports , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current To: Mark Millard References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <45E32F4F-A238-47AA-8E1E-7AD4D9E857D9@dsl-only.net> X-Mailer: Apple Mail (2.3259) 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, 27 Mar 2017 12:53:48 -0000 --Apple-Mail=_54747A7A-60FC-41AE-A610-0C40033DAA05 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 27 Mar 2017, at 12:25, Mark Millard wrote: > > On 2017-Mar-27, at 2:41 AM, Dimitry Andric wrote: >> On 26 Mar 2017, at 23:36, Mark Millard wrote: ... >>> Installed packages to be REMOVED: >>> llvm40-4.0.0.r4 >>> >>> Number of packages to be removed: 1 >>> >>> The operation will free 49 GiB. >> >> Yes, this is big. But there is no real need to build the llvm ports >> with debug information, unless you want to hack on llvm itself. And >> in that case, you are better served by a Subversion checkout or Git >> clone from upstream instead. ... > Historically unless something extreme like this ends up > involved I build everything using WITH_DEBUG= or explicit > -g's in order to have better information on any failure. The problem with the ports implementation of WITH_DEBUG is that it always disables all optimizations, without a possibility to override. Which bloats the resulting object files, libraries and executables, and especially so for large C++ projects such as LLVM. I can recommend the following workaround. If you want to build a port with optimizations disabled, you can always pass -O0 in CFLAGS. -Dimitry Index: Mk/bsd.port.mk =================================================================== --- Mk/bsd.port.mk (revision 436685) +++ Mk/bsd.port.mk (working copy) @@ -1646,7 +1646,7 @@ MAKE_ENV+= DONTSTRIP=yes STRIP_CMD= ${TRUE} .endif DEBUG_FLAGS?= -g -CFLAGS:= ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS} +CFLAGS:= ${CFLAGS} ${DEBUG_FLAGS} .if defined(INSTALL_TARGET) INSTALL_TARGET:= ${INSTALL_TARGET:S/^install-strip$/install/g} .endif --Apple-Mail=_54747A7A-60FC-41AE-A610-0C40033DAA05 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 iEYEARECAAYFAljZC1kACgkQsF6jCi4glqNJ9ACaA7mkaSbBsbXWA54kbVSMwc/k vn8AoIAUO0WmGfOZ1OWXdQfDsgreAgpo =6gZ8 -----END PGP SIGNATURE----- --Apple-Mail=_54747A7A-60FC-41AE-A610-0C40033DAA05-- From owner-freebsd-current@freebsd.org Mon Mar 27 13:10: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 D3CD8D20A3C for ; Mon, 27 Mar 2017 13:10:45 +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 4AECD19A for ; Mon, 27 Mar 2017 13:10:44 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M7Yhz-1bystD0StL-00xO0U; Mon, 27 Mar 2017 15:10:40 +0200 Date: Mon, 27 Mar 2017 15:10:32 +0200 From: "O. Hartmann" To: Mark Millard Cc: FreeBSD Current Subject: Re: Howto complete(!) install a world? Message-ID: <20170327151014.558b3059@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: References: <20170327115309.0271cd7f@freyja.zeit4.iv.bundesimmobilien.de> Organization: Walstatt X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:wGTceRWltDUzd+7BfCXJkyBcD27BtwuNaC+LLiAJuPmrDHXqmSX OApD32C2qkGddDSTAad9Jmcdm23aB2BOkpMujNqW2liH0EEFrP3pCgR2x8ACvnixGxUxNoq Guj5ol92ik4uRtFiQ+3xXG5fOkL3kofjUngHuoGbuPHvqRjtCsIrJaq0eTimtR+wKvlxchq alo4Dgtlo08Cf30rxAELw== X-UI-Out-Filterresults: notjunk:1;V01:K0:ySs/p1Hwn/I=:I/ujtgM8XjU60Nf4h78fHO 38nZLqxHKM5Kf9jsm+qPCQsH7YzwPQi3VFmVtb/N6Z0ltgjIECHEv2kPxZBzjjuvhUSmsFGPB 52h8EA1cupHfeJawlBDFbqoOaRYokXadr7QMYt2T0H/+qVaJCeCdgd5F/Dr7kX25wi2F3iLB7 hosYisMs5g1MHFpXGh44jTVSAlDvnBM6CTt47X7WRLqUSRXSqr3hYIEXsFniejmjfB7rEC9rP DMHRuF+3zV5QJDFM7HOTHEoM+Niiv91u248TalUGNwndgwr6FJFUDledPsakluBXHBqulyqQ9 tIOoB9I6DJlmfP0wwKnx06q5rUEwca5SlVZTMMDjX3YYrxsaUK4LfdvmuEPKN9peSSCio7v5L EyzLxLa2b8GdI4zqUEGGr2/h94J4+VvS7j/0nBjHrRzUnOLy8OzoBuCypNVFoswj/z3TU37DP E2RyzoR+A3oIc/KYXpjmH4gSeuFoMuZLN+E0YNd7vpjzUdepknUl4czX2jRQoDZKKMO75I8tx deuzhbQtWMyFwbYxSp2zAFYbd+ahdHRqc8n8fJcR3TYaf90doxEbtCv/y2He04+94D6TGc85R Ha1XYP4w+zRPiNHChbPE6JdwOfXUxBdiM5biNNKXd8KwoOEsk3+xKZG00+znQvKhHI2OVtCpn NArNVMe7m3MrsnrBWhePkzPdu0U78pxXqsDNdOB1aVR+OQfTQU3in9p4n5OSLXl04oDDmmFyZ DIC4SuYJwavugb+0+vgkrWzqthHvo7d3wOjTgGqYFOlYkEspbm0wmhJBF+6S9i2TTNJx5S34d ZcpoIOD 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, 27 Mar 2017 13:10:45 -0000 On Mon, 27 Mar 2017 03:12:42 -0700 Mark Millard wrote: > On 2017-Mar-27, at 2:53 AM, O. Hartmann wrote: > > > On Mon, 27 Mar 2017 01:54:18 -0700 > > Mark Millard wrote: > > > >> O. Hartmann ohartmann at walstatt.org wrote on Mon Mar 27 08:10:39 UTC 2017 > >> of: > >> > >>> /usr/bin/ssh: Undefined symbol "msetlocale" > >> > >> > >> I do not know if this will help or not. . . > >> (Notes based on head -r315914 for amd64.) > >> > >> Looking around: > >> > >> # grep -R msetlocale /usr/src/*/ | more > >> /usr/src/crypto/openssh/ssh.c: msetlocale(); > >> /usr/src/crypto/openssh/utf8.h:void msetlocale(void); > >> /usr/src/crypto/openssh/sftp.c: msetlocale(); > >> /usr/src/crypto/openssh/scp.c: msetlocale(); > >> /usr/src/crypto/openssh/utf8.c:msetlocale(void) > >> > >> It looks like msetlocale is local to openssh itself and is > >> tied to utf8 support. > >> > >> # ldd `which ssh` > >> /usr/bin/ssh: > >> libprivatessh.so.5 => /usr/lib/libprivatessh.so.5 (0x800851000) > >> libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x800af2000) > >> libcrypto.so.8 => /lib/libcrypto.so.8 (0x800e00000) > >> libc.so.7 => /lib/libc.so.7 (0x801269000) > >> libprivateldns.so.5 => /usr/lib/libprivateldns.so.5 (0x801624000) > >> libcrypt.so.5 => /lib/libcrypt.so.5 (0x801882000) > >> > >> # objdump -d --prefix-addresses /usr/lib/libprivatessh.so.5 | more > >> > >> /usr/lib/libprivatessh.so.5: file format elf64-x86-64-freebsd > >> . . . > >> 0000000000020e40 push %rbp > >> 0000000000020e41 mov %rsp,%rbp > >> 0000000000020e44 push %rbx > >> 0000000000020e45 push %rax > >> 0000000000020e46 lea 0x4c4e2(%rip),%rdi # > >> 000000000006d32f <_fini+0x1c67> . . . > >> > >> So it is /usr/lib/libprivateshh.so.5 that should have > >> msetlocale in it. > > > > I've already deleted that lib manually and "make installworld" did reinstall > > the lib again. > > > > No effect. > > > > The problem occurs only on that crashed box :-( > > > > Do commands similar to what I showed agree with what I shown? I think, yes, see belwo: > > # grep -R msetlocale /usr/src/*/ | more grep -R msetlocale /usr/src/*/ | more /usr/src/crypto/openssh/scp.c: msetlocale(); /usr/src/crypto/openssh/sftp.c: msetlocale(); /usr/src/crypto/openssh/ssh.c: msetlocale(); /usr/src/crypto/openssh/utf8.h:void msetlocale(void); /usr/src/crypto/openssh/utf8.c:msetlocale(void) > > # ldd `which ssh` ldd `which ssh` /usr/bin/ssh: libprivatessh.so.5 => /lib/libprivatessh.so.5 (0x800853000) libgssapi.so.10 => /lib/libgssapi.so.10 (0x800af2000) libcrypto.so.8 => /lib/libcrypto.so.8 (0x800e00000) libc.so.7 => /lib/libc.so.7 (0x801272000) libprivateldns.so.5 => /lib/libprivateldns.so.5 (0x80163a000) libcrypt.so.5 => /lib/libcrypt.so.5 (0x801897000) libz.so.6 => /lib/libz.so.6 (0x801ab5000) > > # objdump -d --prefix-addresses /usr/lib/libprivatessh.so.5 | grep msetlocale > | more objdump -d --prefix-addresses /usr/lib/libprivatessh.so.5 | grep msetlocale | more 0000000000021690 push %rbp 0000000000021691 mov %rsp,%rbp 0000000000021694 push %rbx 0000000000021695 push %rax 0000000000021696 lea 0x59dd2(%rip),%rdi # 000000000007b46f <_fini@@Base+0x1c77> 000000000002169d callq 0000000000019f9c 00000000000216a2 mov %rax,%rbx 00000000000216a5 test %rbx,%rbx 00000000000216a8 jne 00000000000216d2 00000000000216aa lea 0x59dc5(%rip),%rdi # 000000000007b476 <_fini@@Base+0x1c7e> 00000000000216b1 callq 0000000000019f9c 00000000000216b6 mov %rax,%rbx 00000000000216b9 test %rbx,%rbx 00000000000216bc jne 00000000000216d2 00000000000216be lea 0x59dba(%rip),%rdi # 000000000007b47f <_fini@@Base+0x1c87> 00000000000216c5 callq 0000000000019f9c 00000000000216ca mov %rax,%rbx 00000000000216cd test %rbx,%rbx 00000000000216d0 je 00000000000216ea 00000000000216d2 lea 0x59dab(%rip),%rsi # 000000000007b484 <_fini@@Base+0x1c8c> 00000000000216d9 mov $0x2,%edx 00000000000216de mov %rbx,%rdi 00000000000216e1 callq 0000000000019c3c 00000000000216e6 test %eax,%eax 00000000000216e8 je 0000000000021701 00000000000216ea lea 0x5af18(%rip),%rsi # 000000000007c609 <_fini@@Base+0x2e11> 00000000000216f1 mov $0x2,%edi 00000000000216f6 add $0x8,%rsp 00000000000216fa pop %rbx 00000000000216fb pop %rbp 00000000000216fc jmpq 00000000000198ac 0000000000021701 lea 0x59d86(%rip),%rsi # 000000000007b48e <_fini@@Base+0x1c96> 0000000000021708 mov %rbx,%rdi 000000000002170b callq 000000000001a69c 0000000000021710 test %rax,%rax 0000000000021713 jne 0000000000021729 0000000000021715 lea 0x59d6b(%rip),%rsi # 000000000007b487 <_fini@@Base+0x1c8f> 000000000002171c mov %rbx,%rdi 000000000002171f callq 000000000001a69c 0000000000021724 test %rax,%rax 0000000000021727 je 000000000002175c 0000000000021729 lea 0x59d5c(%rip),%rsi # 000000000007b48c <_fini@@Base+0x1c94> 0000000000021730 mov $0x2,%edi 0000000000021735 callq 00000000000198ac 000000000002173a test %rax,%rax 000000000002173d jne 0000000000021755 000000000002173f lea 0x59d4e(%rip),%rsi # 000000000007b494 <_fini@@Base+0x1c9c> 0000000000021746 mov $0x2,%edi 000000000002174b callq 00000000000198ac 0000000000021750 test %rax,%rax 0000000000021753 je 000000000002175c 0000000000021755 add $0x8,%rsp 0000000000021759 pop %rbx 000000000002175a pop %rbp 000000000002175b retq 000000000002175c lea 0x59d3d(%rip),%rsi # 000000000007b4a0 <_fini@@Base+0x1ca8> 0000000000021763 jmp 00000000000216f1 0000000000021765 int3 0000000000021766 int3 0000000000021767 int3 0000000000021768 int3 0000000000021769 int3 000000000002176a int3 000000000002176b int3 000000000002176c int3 000000000002176d int3 000000000002176e int3 000000000002176f int3 > > (That last presumes that ldd's output points to that file instead of some > alternative.) > > === > Mark Millard > markmi at dsl-only.net > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Mon Mar 27 13:12: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 458CCD20C13 for ; Mon, 27 Mar 2017 13:12:43 +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 7D5567EA for ; Mon, 27 Mar 2017 13:12:41 +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 QAA13876 for ; Mon, 27 Mar 2017 16:12:40 +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 1csURs-000GgH-GP for freebsd-current@freebsd.org; Mon, 27 Mar 2017 16:12:40 +0300 Subject: Re: Opteron 6100-series "Magny-Cours" To: freebsd-current@FreeBSD.org References: <20170327120631.GB36590@chujemuje> From: Andriy Gapon Message-ID: Date: Mon, 27 Mar 2017 16:11:44 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170327120631.GB36590@chujemuje> Content-Type: text/plain; charset=utf-8 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: Mon, 27 Mar 2017 13:12:43 -0000 On 27/03/2017 15:06, Piotr Kubaj wrote: > Does it have to be specifically 61xx series? I have a server running 2 6262HE's. > Yes. I have the info that I need for 62xx Opterons. Thanks. -- Andriy Gapon From owner-freebsd-current@freebsd.org Mon Mar 27 13:21: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 DC58FD20DE2 for ; Mon, 27 Mar 2017 13:21:13 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9FA4FC5D for ; Mon, 27 Mar 2017 13:21:13 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::5868:2545:a766:52d] (unknown [IPv6:2001:470:7a58:0:5868:2545:a766:52d]) (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 D93DA1F96C; Mon, 27 Mar 2017 15:21:04 +0200 (CEST) From: Dimitry Andric Message-Id: <85EA9616-F813-4A17-9E45-7235CC86588D@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_261FDF15-DC17-4C96-A042-A60429FEE7A2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Howto complete(!) install a world? Date: Mon, 27 Mar 2017 15:20:57 +0200 In-Reply-To: <20170327151014.558b3059@freyja.zeit4.iv.bundesimmobilien.de> Cc: Mark Millard , FreeBSD Current To: "O. Hartmann" References: <20170327115309.0271cd7f@freyja.zeit4.iv.bundesimmobilien.de> <20170327151014.558b3059@freyja.zeit4.iv.bundesimmobilien.de> X-Mailer: Apple Mail (2.3259) 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, 27 Mar 2017 13:21:14 -0000 --Apple-Mail=_261FDF15-DC17-4C96-A042-A60429FEE7A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 27 Mar 2017, at 15:10, O. Hartmann wrote: >=20 > On Mon, 27 Mar 2017 03:12:42 -0700 > Mark Millard wrote: >> On 2017-Mar-27, at 2:53 AM, O. Hartmann = wrote: >>> On Mon, 27 Mar 2017 01:54:18 -0700 >>> Mark Millard wrote: >>>> O. Hartmann ohartmann at walstatt.org wrote on Mon Mar 27 08:10:39 = UTC 2017 >>>> of: >>>>> /usr/bin/ssh: Undefined symbol "msetlocale" ... > ldd `which ssh` > /usr/bin/ssh: > libprivatessh.so.5 =3D> /lib/libprivatessh.so.5 (0x800853000) > libgssapi.so.10 =3D> /lib/libgssapi.so.10 (0x800af2000) > libcrypto.so.8 =3D> /lib/libcrypto.so.8 (0x800e00000) > libc.so.7 =3D> /lib/libc.so.7 (0x801272000) > libprivateldns.so.5 =3D> /lib/libprivateldns.so.5 (0x80163a000) > libcrypt.so.5 =3D> /lib/libcrypt.so.5 (0x801897000) > libz.so.6 =3D> /lib/libz.so.6 (0x801ab5000) That is very weird. Private libs such as libprivatessh.so.5 should be in /usr/lib, never in /lib. Likely, this is what is tripping you up. > objdump -d --prefix-addresses /usr/lib/libprivatessh.so.5 | grep = msetlocale | > more 0000000000021690 push %rbp Now you are dumping a different libprivatessh.so.5 than /usr/bin/ssh is actually using. Try checking the copy in /lib: nm -D /lib/libprivatessh.so.5 | grep msetlocale That said, I would carefully check your make.conf settings related to installworld. If you override LIBDIR, for instance, I think libraries might be put in the wrong location. -Dimitry --Apple-Mail=_261FDF15-DC17-4C96-A042-A60429FEE7A2 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 iEYEARECAAYFAljZEcAACgkQsF6jCi4glqNrbgCg4BdbeGv0yJI7+frrNgiT9MbO GqEAoJgNuvZtik2UWphVrhPDYsf4YCs0 =AKUJ -----END PGP SIGNATURE----- --Apple-Mail=_261FDF15-DC17-4C96-A042-A60429FEE7A2-- From owner-freebsd-current@freebsd.org Mon Mar 27 14:24:06 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 1196CD20601 for ; Mon, 27 Mar 2017 14:24:06 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [50.197.129.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "pozo.com", Issuer "pozo.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EF32881B; Mon, 27 Mar 2017 14:24:05 +0000 (UTC) (envelope-from null@pozo.com) Received: from octo.pozo.com (octo.pozo.com [192.168.0.2]) (authenticated bits=128) by pozo.com (8.15.2/8.15.2) with ESMTPA id v2REIocT033605; Mon, 27 Mar 2017 07:18:50 -0700 (PDT) (envelope-from null@pozo.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: New /head/sys/amd64/amd64/genassym.c breaks buildkernel amd64 current From: Manfred Antar In-Reply-To: <74862f9a-ac5b-e39b-5178-f3db5623c172@FreeBSD.org> Date: Mon, 27 Mar 2017 07:18:49 -0700 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <74862f9a-ac5b-e39b-5178-f3db5623c172@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.3259) X-Spam-Status: No, score=-96.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, RP_MATCHES_RCVD,USER_IN_WHITELIST autolearn=ham autolearn_force=no version=3.4.1, No X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: v2REIocT033605 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com 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, 27 Mar 2017 14:24:06 -0000 >=20 > I've got another report about this problem, but I can not reproduce it he= re with > a clean kernel build of GENERIC. > I am not sure what the problem is. > Do you have anything unusual in make.conf, src.conf or your kernel config= uration? >=20 > --=20 > Andriy Gapon >=20 Here is my src.conf: WITHOUT_DYNAMICROOT=3Dyes=20 WITHOUT_UNBOUND=3Dyes WITHOUT_CASPER=3Dyes WITHOUT_CAPSICUM=3Dyes WITHOUT_DMAGENT=3Dyes WITHOUT_PROFILE=3Dyes WITHOUT_TESTS=3Dyes WITHOUT_KERNEL_SYMBOLS=3Dyes WITHOUT_DEBUG_FILES=3D1 WITHOUT_LIB32=3Dyes INSTALL_NODEBUG=3Dyes NO_WERROR=3D WERROR=3D KERNCONF=3Dpozo WITH_CCACHE_BUILD=3Dyes Here is make.conf: MODULES_OVERRIDE=3D BOOT_COMCONSOLE_PORT=3D0x3F8 BOOT_COMCONSOLE_SPEED=3D57600 DOC_LANG=3Den_US.ISO8859-1 SENDMAIL_MC=3D/root/config-files/pozo-hp-8000-sff/sendmail/pozo.mc SENDMAIL_SUBMIT_MC=3D/root/config-files/pozo-hp-8000-sff/sendmail/pozo-subm= it.mc SENDMAIL_CFLAGS=3D-I/usr/local/include -DSASL=3D2 SENDMAIL_LDFLAGS=3D-L/usr/local/lib SENDMAIL_LDADD=3D-lsasl2 DEFAULT_VERSIONS=3D mysql=3D5.7 apache=3D2.4 python2=3D2.7 python3=3D3.4 ru= by=3D2.3 perl5=3D5.24 php=3D5.6 tcltk=3D8.6 samba=3D4.4 ssl=3Dbase ncurses= =3Dbase MALLOC_PRODUCTION=3Dyes WITH_BDB_VERSION=3D5 I have the same thing happen on another machine wth custom kernel and modul= es. Could it be ccache ? for now i do: cd /sys/amd64/conf config pozo cd /sys/amd64/compile/pozo make device_if.h make bus_if.h make depend make -j8 make install and it builds fine --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-current@freebsd.org Mon Mar 27 16:20: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 8802BD20DB9 for ; Mon, 27 Mar 2017 16:20:52 +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 074C86C6; Mon, 27 Mar 2017 16:20:51 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([92.225.14.162]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MVsUW-1cd9A92Pk0-00X6PY; Mon, 27 Mar 2017 18:20:41 +0200 Date: Mon, 27 Mar 2017 18:20:30 +0200 From: "O. Hartmann" To: Dimitry Andric Cc: "O. Hartmann" , Mark Millard , FreeBSD Current Subject: Re: Howto complete(!) install a world? Message-ID: <20170327182030.4bb4d227@thor.intern.walstatt.dynvpn.de> In-Reply-To: <85EA9616-F813-4A17-9E45-7235CC86588D@FreeBSD.org> References: <20170327115309.0271cd7f@freyja.zeit4.iv.bundesimmobilien.de> <20170327151014.558b3059@freyja.zeit4.iv.bundesimmobilien.de> <85EA9616-F813-4A17-9E45-7235CC86588D@FreeBSD.org> 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_/+waoUG9cV8lqRy7MBLYQt4b"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:N/4LA5MSqwCsw4okrnRwyDgaPCNPUkcPPdfhcgxsvpCMPD3+9GI ObzUN10ZfIFWM2lzIMj8FYiHwqcb3dr/bLxsD/r8wYHRQz2nHuHK2Efa0PVlYAy/AOdXGWK sgC8KBhqK4YWzLHH38xTzK9IgpSRHPiCQ9dPuPPVde+u56qxIvWFXcleDMYrhHPgGSn2AgS X5JPk/4mruRqjJ71ekogA== X-UI-Out-Filterresults: notjunk:1;V01:K0:zrpq+Qy1EzA=:phyGblnZX8mLGEkboB8SyH j9iEFWl9AMGQtoLqkNaKOrUl3pYR7apRHKif5iE1jjh2aNxUalUop2hunziadVr+kQX2mlNr5 NwmhlalcZ9YzdEfDxawwW57kDcXM6ybpSi4ujoLHLpZwaf00hMnIyoobdzIqRq1f9p2tCB9GY kKi1vXfpnuddmWHBJJj5HeUSCLIicNXkQPwU/U8NtLCUZs1muCaEIxBVLKaYQyz7V8xmsrHTT XMUZVpqb2OMW/ZxmSLG56ywxNThmITS7VMgD4OAWvB5ceENgmlvtJ7NHbbrNqSQcLL5jHTyBa YitdwGjiXh0OrEEGziJTY5bHvKpB1vEYZrNPl8trN09n7277SoaY8JmnrFDshV/u/UqkmW/Gz 4tjqdSN41vIPoiqkd+339m7XuJ8nuc11kAUvOeBaFM0UxdF+8HcVo9M+U18nZOpjt3i8aJwuy cmMEg9JqfJdRNFkO80IamcOKpGeRSeecCDlRslxIcki6AhsjUkr9NR0+O+nUnUkaqbfFBvzU1 MGnx0CAvNrJ8wvQfGhpuKc80mIDPzprMsG4p8pMMNaLaX3pBrKfKpt3gu6LcEU2liAuOwbIFB Hf5dfRPtaiSjAptOB8WwFsKy+4fbumh4VCWPJx0TRWeSFWcJtxhqoxNHWCLBfz1bVFpwe7XQj fUgYiUvMsktxzQop/TJDuY7rutMIISuUu3a68KxiLpVolL/SxEpxNpFTNiRPzaGeMCDgwjtzP yoa1q37S3PTPK3clYeVZ0G1EH45z6WkZuuJCAn1ynw6ZHxKJjwBXU7NCwrg= 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, 27 Mar 2017 16:20:52 -0000 --Sig_/+waoUG9cV8lqRy7MBLYQt4b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Mon, 27 Mar 2017 15:20:57 +0200 Dimitry Andric schrieb: > On 27 Mar 2017, at 15:10, O. Hartmann wrote: > >=20 > > On Mon, 27 Mar 2017 03:12:42 -0700 > > Mark Millard wrote: =20 > >> On 2017-Mar-27, at 2:53 AM, O. Hartmann w= rote: =20 > >>> On Mon, 27 Mar 2017 01:54:18 -0700 > >>> Mark Millard wrote: =20 > >>>> O. Hartmann ohartmann at walstatt.org wrote on Mon Mar 27 08:10:39 U= TC 2017 > >>>> of: =20 > >>>>> /usr/bin/ssh: Undefined symbol "msetlocale" =20 > ... > > ldd `which ssh` > > /usr/bin/ssh: > > libprivatessh.so.5 =3D> /lib/libprivatessh.so.5 (0x800853000) > > libgssapi.so.10 =3D> /lib/libgssapi.so.10 (0x800af2000) > > libcrypto.so.8 =3D> /lib/libcrypto.so.8 (0x800e00000) > > libc.so.7 =3D> /lib/libc.so.7 (0x801272000) > > libprivateldns.so.5 =3D> /lib/libprivateldns.so.5 (0x80163a000) > > libcrypt.so.5 =3D> /lib/libcrypt.so.5 (0x801897000) > > libz.so.6 =3D> /lib/libz.so.6 (0x801ab5000) =20 >=20 > That is very weird. Private libs such as libprivatessh.so.5 should be > in /usr/lib, never in /lib. Likely, this is what is tripping you up. After you stated this fact, I also see that I have some weird symbolic link= s in /lib - and I recall some strange thing I did: I used prior to the flash mem drive = as stated above one that has been released on Feb, 3rd! Therefore, I think, the weird= date. All my boxes I have investigated after your comment here do have /lib updated acco= rdingly to the last "make installworld". Except the box that is suffering the problems! I think my little stupid "pax" manouvre in the first place corrupted someth= ing and after I failed, I swapped to a more recent FreeBSD image (23rd March) and fullfil= led - with hidden consequences :-( The question of how to install a FreeBSD completely (means: force a complet= e install of a world except configuration files, I was having the libs in mind) arose from= this problem. Once in my office again, I'll check that and somehow I need a plan how to update/exchange /lib without corrupting the system. Now /rescue with static= ally linked binaries come into play. Maybe a "DESTDIR=3D" driven shadow installation sh= ould suffice. The /lib folder on healthy systems do not show symbolic links ... =20 >=20 >=20 > > objdump -d --prefix-addresses /usr/lib/libprivatessh.so.5 | grep msetlo= cale | > > more 0000000000021690 push %rbp =20 >=20 > Now you are dumping a different libprivatessh.so.5 than /usr/bin/ssh is > actually using. Try checking the copy in /lib: >=20 > nm -D /lib/libprivatessh.so.5 | grep msetlocale >=20 > That said, I would carefully check your make.conf settings related to > installworld. If you override LIBDIR, for instance, I think libraries > might be put in the wrong location. >=20 > -Dimitry >=20 --=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_/+waoUG9cV8lqRy7MBLYQt4b Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWNk7zgAKCRDS528fyFhY lIUEAgCnB+dV/3cNT5CaVVKv+RXr0qczKO5gU3b7xZ21Dkq1bMcHoQ5nM5TT8txP 7nopgMyljTIx/Dsz9eKH3eNwngxAAf9c0SYJx22w2hx79/hLDdi2DqGuVL6E/m1r Tdo6xGtxF8N/s/ZfhsWujSWrTm+zbSVxpXuM7tMn+9V3i6ZnlMGZ =ZM+k -----END PGP SIGNATURE----- --Sig_/+waoUG9cV8lqRy7MBLYQt4b-- From owner-freebsd-current@freebsd.org Mon Mar 27 21:11: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 8BBC3D2093F for ; Mon, 27 Mar 2017 21:11:52 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-180.reflexion.net [208.70.211.180]) (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 46FABE49 for ; Mon, 27 Mar 2017 21:11:52 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 16407 invoked from network); 27 Mar 2017 21:11:51 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 27 Mar 2017 21:11:51 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Mon, 27 Mar 2017 17:11:51 -0400 (EDT) Received: (qmail 15521 invoked from network); 27 Mar 2017 21:11:50 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 Mar 2017 21:11:50 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 00D36EC81C9; Mon, 27 Mar 2017 14:11:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) From: Mark Millard In-Reply-To: Date: Mon, 27 Mar 2017 14:11:49 -0700 Cc: FreeBSD Ports , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <45E32F4F-A238-47AA-8E1E-7AD4D9E857D9@dsl-only.net> To: Dimitry Andric X-Mailer: Apple Mail (2.3259) 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, 27 Mar 2017 21:11:52 -0000 On 2017-Mar-27, at 5:53 AM, Dimitry Andric wrote: > On 27 Mar 2017, at 12:25, Mark Millard wrote: >>=20 >> On 2017-Mar-27, at 2:41 AM, Dimitry Andric wrote: >>> On 26 Mar 2017, at 23:36, Mark Millard wrote: > ... >>>> Installed packages to be REMOVED: >>>> llvm40-4.0.0.r4 >>>>=20 >>>> Number of packages to be removed: 1 >>>>=20 >>>> The operation will free 49 GiB. >>>=20 >>> Yes, this is big. But there is no real need to build the llvm ports >>> with debug information, unless you want to hack on llvm itself. And >>> in that case, you are better served by a Subversion checkout or Git >>> clone from upstream instead. > ... >> Historically unless something extreme like this ends up >> involved I build everything using WITH_DEBUG=3D or explicit >> -g's in order to have better information on any failure. >=20 > The problem with the ports implementation of WITH_DEBUG is that it > always disables all optimizations, without a possibility to override. > Which bloats the resulting object files, libraries and executables, = and > especially so for large C++ projects such as LLVM. >=20 > I can recommend the following workaround. If you want to build a port > with optimizations disabled, you can always pass -O0 in CFLAGS. >=20 > -Dimitry >=20 > Index: Mk/bsd.port.mk > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- Mk/bsd.port.mk (revision 436685) > +++ Mk/bsd.port.mk (working copy) > @@ -1646,7 +1646,7 @@ MAKE_ENV+=3D DONTSTRIP=3Dyes > STRIP_CMD=3D ${TRUE} > .endif > DEBUG_FLAGS?=3D -g > -CFLAGS:=3D ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS} > +CFLAGS:=3D ${CFLAGS} ${DEBUG_FLAGS} > .if defined(INSTALL_TARGET) > INSTALL_TARGET:=3D ${INSTALL_TARGET:S/^install-strip$/install/g} > .endif Interesting. WITH_DEBUG's description in the file does not mention that stripping of optimization flags: # WITH_DEBUG - If set, debugging flags are added to CFLAGS = and the # binaries don't get stripped by INSTALL_PROGRAM = or # INSTALL_LIB. Besides, individual ports might # add their specific to produce binaries for = debugging # purposes. You can override the debug flags = that are # passed to the compiler by setting DEBUG_FLAGS. = It is # set to "-g" at default. I'll probably give myself an override that I can specify in /etc/make.conf , such as: # svnlite diff /usr/ports/Mk/bsd.port.mk Index: /usr/ports/Mk/bsd.port.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/ports/Mk/bsd.port.mk (revision 436747) +++ /usr/ports/Mk/bsd.port.mk (working copy) @@ -1646,7 +1646,11 @@ STRIP_CMD=3D ${TRUE} .endif DEBUG_FLAGS?=3D -g +.if defined(ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG) +CFLAGS:=3D ${CFLAGS} ${DEBUG_FLAGS} +.else CFLAGS:=3D ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS} +.endif .if defined(INSTALL_TARGET) INSTALL_TARGET:=3D ${INSTALL_TARGET:S/^install-strip$/install/g} .endif =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Mon Mar 27 21:40: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 1D2BDD20348; Mon, 27 Mar 2017 21:40:57 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D469A6A; Mon, 27 Mar 2017 21:40:56 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::5868:2545:a766:52d] (unknown [IPv6:2001:470:7a58:0:5868:2545:a766:52d]) (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 9C5801F9A6; Mon, 27 Mar 2017 23:40:52 +0200 (CEST) From: Dimitry Andric Message-Id: <7FFF80B9-CE74-49C8-B295-DCB630368152@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_514FBD21-D9EF-4E52-B92E-56F9D9059F6B"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) Date: Mon, 27 Mar 2017 23:40:45 +0200 In-Reply-To: Cc: FreeBSD Ports , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current To: Mark Millard References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <45E32F4F-A238-47AA-8E1E-7AD4D9E857D9@dsl-only.net> X-Mailer: Apple Mail (2.3259) 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, 27 Mar 2017 21:40:57 -0000 --Apple-Mail=_514FBD21-D9EF-4E52-B92E-56F9D9059F6B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 27 Mar 2017, at 23:11, Mark Millard wrote: >=20 > On 2017-Mar-27, at 5:53 AM, Dimitry Andric wrote: >> On 27 Mar 2017, at 12:25, Mark Millard = wrote: >>>=20 >>> On 2017-Mar-27, at 2:41 AM, Dimitry Andric wrote: >>>> On 26 Mar 2017, at 23:36, Mark Millard wrote: >> ... >>>>> Installed packages to be REMOVED: >>>>> llvm40-4.0.0.r4 >>>>>=20 >>>>> Number of packages to be removed: 1 >>>>>=20 >>>>> The operation will free 49 GiB. >>>>=20 >>>> Yes, this is big. But there is no real need to build the llvm = ports >>>> with debug information, unless you want to hack on llvm itself. = And >>>> in that case, you are better served by a Subversion checkout or Git >>>> clone from upstream instead. >> ... >>> Historically unless something extreme like this ends up >>> involved I build everything using WITH_DEBUG=3D or explicit >>> -g's in order to have better information on any failure. >>=20 >> The problem with the ports implementation of WITH_DEBUG is that it >> always disables all optimizations, without a possibility to override. >> Which bloats the resulting object files, libraries and executables, = and >> especially so for large C++ projects such as LLVM. >>=20 >> I can recommend the following workaround. If you want to build a = port >> with optimizations disabled, you can always pass -O0 in CFLAGS. >>=20 >> -Dimitry >>=20 >> Index: Mk/bsd.port.mk >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- Mk/bsd.port.mk (revision 436685) >> +++ Mk/bsd.port.mk (working copy) >> @@ -1646,7 +1646,7 @@ MAKE_ENV+=3D DONTSTRIP=3Dyes >> STRIP_CMD=3D ${TRUE} >> .endif >> DEBUG_FLAGS?=3D -g >> -CFLAGS:=3D ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS} >> +CFLAGS:=3D ${CFLAGS} ${DEBUG_FLAGS} >> .if defined(INSTALL_TARGET) >> INSTALL_TARGET:=3D ${INSTALL_TARGET:S/^install-strip$/install/g} >> .endif >=20 > Interesting. WITH_DEBUG's description in the file does not > mention that stripping of optimization flags: >=20 > # WITH_DEBUG - If set, debugging flags are added to CFLAGS = and the > # binaries don't get stripped by = INSTALL_PROGRAM or > # INSTALL_LIB. Besides, individual ports might > # add their specific to produce binaries for = debugging > # purposes. You can override the debug flags = that are > # passed to the compiler by setting = DEBUG_FLAGS. It is > # set to "-g" at default. >=20 > I'll probably give myself an override that I can specify in > /etc/make.conf , such as: >=20 > # svnlite diff /usr/ports/Mk/bsd.port.mk > Index: /usr/ports/Mk/bsd.port.mk > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/ports/Mk/bsd.port.mk (revision 436747) > +++ /usr/ports/Mk/bsd.port.mk (working copy) > @@ -1646,7 +1646,11 @@ > STRIP_CMD=3D ${TRUE} > .endif > DEBUG_FLAGS?=3D -g > +.if defined(ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG) > +CFLAGS:=3D ${CFLAGS} ${DEBUG_FLAGS} > +.else > CFLAGS:=3D ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS} > +.endif > .if defined(INSTALL_TARGET) > INSTALL_TARGET:=3D ${INSTALL_TARGET:S/^install-strip$/install/g} > .endif Effectively, this gives some sort of support for three of CMake's build types, e.g: * Debug, which disables optimization, and obviously adds debuginfo * Release, which optimizes for speed, and does not add debuginfo * RelWithDebInfo, similar to Release but does add debuginfo It would be nice if there was some way of directly utilizing these. The RelWithDebInfo target is very useful with the LLVM projects. -Dimitry --Apple-Mail=_514FBD21-D9EF-4E52-B92E-56F9D9059F6B 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 iEYEARECAAYFAljZhuQACgkQsF6jCi4glqMorQCgv/7IBqz9jGgFaN9QHYfyAdbR KxEAn0lOODsBULR/lK+hU1IIgZzVItti =v4EU -----END PGP SIGNATURE----- --Apple-Mail=_514FBD21-D9EF-4E52-B92E-56F9D9059F6B-- From owner-freebsd-current@freebsd.org Tue Mar 28 03:59:10 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 4AC28D2155D for ; Tue, 28 Mar 2017 03:59:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-178.reflexion.net [208.70.211.178]) (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 0A37D7BE for ; Tue, 28 Mar 2017 03:59:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21249 invoked from network); 28 Mar 2017 04:01:44 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 28 Mar 2017 04:01:44 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Mon, 27 Mar 2017 23:59:03 -0400 (EDT) Received: (qmail 27894 invoked from network); 28 Mar 2017 03:59:02 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 28 Mar 2017 03:59:02 -0000 Received: from [192.168.1.119] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 27966EC8257; Mon, 27 Mar 2017 20:59:02 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!] From: Mark Millard In-Reply-To: <1C595969-C6E0-44A2-9086-E48C237263BC@dsl-only.net> Date: Mon, 27 Mar 2017 20:59:01 -0700 Cc: FreeBSD Current , FreeBSD-STABLE Mailing List Content-Transfer-Encoding: 7bit Message-Id: References: <01735A68-FED6-4E63-964F-0820FE5C446C@dsl-only.net> <16B3D614-62E1-4E58-B409-8DB9DBB35BCB@dsl-only.net> <5BEAFC6C-DA80-4D7B-AB55-977E585D1ACC@dsl-only.net> <10F50F1C-FD26-4142-9350-966312822438@dsl-only.net> <76DD9882-B4BD-4A16-A8E1-5A5FBB5A21F5@dsl-only.net> <1C595969-C6E0-44A2-9086-E48C237263BC@dsl-only.net> To: Andrew Turner , freebsd-arm X-Mailer: Apple Mail (2.3259) 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, 28 Mar 2017 03:59:10 -0000 On 2017-Mar-21, at 7:21 PM, Mark Millard wrote: > On 2017-Mar-18, at 9:10 PM, Mark Millard wrote: > >> >> On 2017-Mar-18, at 5:53 PM, Mark Millard wrote: >> >>> A new, significant discovery follows. . . >>> >>> While checking out use of procstat -v I ran >>> into the following common property for the 3 >>> programs that I looked at: >>> >>> A) My small test program that fails for >>> a dynamically allocated space. >>> >>> B) sh reporting Failed assertion: "tsd_booted". >>> >>> C) su reporting Failed assertion: "tsd_booted". >>> >>> Here are example addresses from the area of >>> incorrectly zeroed memory (A then B then C): >>> >>> (lldb) print dyn_region >>> (region *volatile) $0 = 0x0000000040616000 >>> >>> (lldb) print &__je_tsd_booted >>> (bool *) $0 = 0x0000000040618520 >>> >>> (lldb) print &__je_tsd_booted >>> (bool *) $0 = 0x0000000040618520 >> >> That last above was a copy/paste error. Correction: >> >> (lldb) print &__je_tsd_booted >> (bool *) $0 = 0x000000004061d520 >> >>> The first is from dynamic allocation ending up >>> in the area. The other two are from libc.so.7 >>> globals/statics ending up in the general area. >>> >>> It looks like something is trashing a specific >>> memory area for some reason, rather independently >>> of what the program specifics are. > > I probably should have noted that the processes > involved were: child/parent then grandparent > and then great grandparent. The grandparent > was sh and the great grandparent was su. > > The ancestors in the process tree are being > damaged, not just the instances of the > program that demonstrates the problem. > >>> Other notes: >>> >>> At least for my small program showing failure: >>> >>> Being explicit about the combined conditions for failure >>> for my test program. . . >>> >>> Both tcache enabled and allocations fitting in SMALL_MAXCLASS >>> are required in order to make the program fail. >>> >>> Note: >>> >>> lldb) print __je_tcache_maxclass >>> (size_t) $0 = 32768 >>> >>> which is larger than SMALL_MAXCLASS. I've not observed >>> failures for sizes above SMALL_MAXCLASS but not exceeding >>> __je_tcache_maxclass. >>> >>> Thus tcache use by itself does not seen sufficient for >>> my program to get corruption of its dynamically allocated >>> memory: the small allocation size also matters. >>> >>> >>> Be warned that I can not eliminate the possibility that >>> the trashing changed what region of memory it trashed >>> for larger allocations or when tcache is disabled. >> >> The pine64+ 2GB eventually got into a state where: >> >> /etc/malloc.conf -> tcache:false >> >> made no difference and the failure kept occurring >> with that symbolic link in place. >> >> But after a reboot of the pin46+ 2GB >> /etc/malloc.conf -> tcache:false was again effective >> for my test program. (It was still present from >> before the reboot.) >> >> I checked the .core files and the allocated address >> assigned to dyn_region was the same in the tries >> before and after the reboot. (I had put in an >> additional raise(SIGABRT) so I'd always have >> a core file to look at.) >> >> Apparently /etc/malloc.conf -> tcache:false was >> being ignored before the reboot for some reason? > > I have also discovered that if the child process > in an example like my program does a: > > (void) posix_madvise(dyn_region, region_size, POSIX_MADV_WILLNEED); > > after the fork but before the sleep/swap-out/wait > then the problem does not happen. This is without > any read or write access to the memory between the > fork and sleep/swap-out/wait. > > By contrast such POSIX_MADV_WILLNEED use in the parent > process does not change the failure behavior. I've added another test program to bugzilla 217239 and 217138, one with thousands of 14 KiByte allocations. The test program usually ends up with them all being zeroed in the parent and child of the fork. But I've had a couple of runs where a much smaller prefix was messed up and then there were normal, expected values. #define region_size (14u*1024u) . . . #define num_regions (256u*1024u*1024u/region_size) So num_regions==18724, using up most of 256 MiBytes. Note: each region has its own 14 KiByte allocation. But dyn_regions[1296].array[0] in one example was the first normal value. In another example dyn_regions[2180].array[4096] was the first normal value. The last is interesting for being part way through an allocation's space. That but aligning with a 4 KiByte page size would seem odd for a pure-jemalloc issue. === Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Tue Mar 28 05:30:24 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 BDC7CD2175A for ; Tue, 28 Mar 2017 05:30:24 +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 302D5979; Tue, 28 Mar 2017 05:30:23 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MNZgw-1cmgEm0Xpy-007FJ1; Tue, 28 Mar 2017 07:30:14 +0200 Date: Tue, 28 Mar 2017 07:30:07 +0200 From: "O. Hartmann" To: Dimitry Andric Cc: "O. Hartmann" , Mark Millard , FreeBSD Current Subject: Re: Howto complete(!) install a world? Message-ID: <20170328073000.7ed4e1f3@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <85EA9616-F813-4A17-9E45-7235CC86588D@FreeBSD.org> References: <20170327115309.0271cd7f@freyja.zeit4.iv.bundesimmobilien.de> <20170327151014.558b3059@freyja.zeit4.iv.bundesimmobilien.de> <85EA9616-F813-4A17-9E45-7235CC86588D@FreeBSD.org> Organization: Walstatt X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:aSDW+RoQ9b1zZCNFoqhMH3sgkIJo3KuFSJCx1XmZlhL5h/n5flg HYM1tFvP27rEjzkeIp3/36IsyB+cNblUtWYqojW46QBY40zSCwt7Brw+B0kANPe74UTW/5E jwIHQG3qjc0LOIMTO+2CR9+z2AJ9umzge6uSaWu7o+qknE1zL4OpyatgBfX5kKa7iESEpuw HobR38BsgSSViquye2fMA== X-UI-Out-Filterresults: notjunk:1;V01:K0:Xcdk8ZCAtAg=:9TYaPtIUrN2Lt9a9sY+PwP fE8XS8ySkElksGjli11n29h4wdM1teNxEDjrrHULjfDZJ8o2Tzy6q7SuXr4hItNyYPtetSYPF HNp+HbS8gbt9oVnEyk+APw8TRxCzQdIv3Xv62iwYwxnuIk6+Gkf7N9RenPBxs2JIz1jMJ265U EOEIu0XYJHxj+OhR8N+C648ouCqJIjKxrAnOBXXm/nHU07easlciug/xvIbGSs3DUwqpw5R2U KDNHxRNIgbwTK7yZc/CICZbPTozCLFUQiUQoESjv2Tm5hS1Vig8rIaKiYTzcDb67xfVI7fejp 40cR5IDb6iRTaz/rUX10FEpaS99zPYW9h1uHa246fIGA6FqC/6LEHqJf7j+jOjwFgK8JV7Y6U Bb0U5988pJiDrHIfbsZcq6u+7PQLJhsI5S8WZ3KIOTd+BqWILIP5EkwAxG63F9l1gA+uxcVR+ jwqc/Buyowzgo+UTCFgkT8EAvVgL3fLs6EY5ZvKcclxtUUYOjlkA8jat5LrYh2MZ/URLyHCKc WbtRKbq3aJlO0XMmOAVP25G4pShnEMIQ+4wDtOeEOrXEAQ0DYAb7uroncmYFq/8p20FPXgbLf tXeI1t6kDYMcK8GDqSuEX3Q3a4rANNTNIFpbWJdzDLAVh0fxzK0y+OHeFrlD1zMzID8xNBlOm CSOvI5YDwNAiJ92P66DcZDa7+d3ueZuDGZLO9WzfpvdTdgmOllv1EUcOnN41BAwERl6VcOVtD gfyLbraH3YEBBOvO03thvK2RloRPYKHQ6TVJU9g0GXzFyCiI9XAQtg3+69ZSzzYu14nWHOcGL u+YUAfC 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, 28 Mar 2017 05:30:24 -0000 On Mon, 27 Mar 2017 15:20:57 +0200 Dimitry Andric wrote: > On 27 Mar 2017, at 15:10, O. Hartmann wrote: > > > > On Mon, 27 Mar 2017 03:12:42 -0700 > > Mark Millard wrote: > >> On 2017-Mar-27, at 2:53 AM, O. Hartmann > >> wrote: > >>> On Mon, 27 Mar 2017 01:54:18 -0700 > >>> Mark Millard wrote: > >>>> O. Hartmann ohartmann at walstatt.org wrote on Mon Mar 27 08:10:39 UTC > >>>> 2017 of: > >>>>> /usr/bin/ssh: Undefined symbol "msetlocale" > ... > > ldd `which ssh` > > /usr/bin/ssh: > > libprivatessh.so.5 => /lib/libprivatessh.so.5 (0x800853000) > > libgssapi.so.10 => /lib/libgssapi.so.10 (0x800af2000) > > libcrypto.so.8 => /lib/libcrypto.so.8 (0x800e00000) > > libc.so.7 => /lib/libc.so.7 (0x801272000) > > libprivateldns.so.5 => /lib/libprivateldns.so.5 (0x80163a000) > > libcrypt.so.5 => /lib/libcrypt.so.5 (0x801897000) > > libz.so.6 => /lib/libz.so.6 (0x801ab5000) > > That is very weird. Private libs such as libprivatessh.so.5 should be > in /usr/lib, never in /lib. Likely, this is what is tripping you up. > > > > objdump -d --prefix-addresses /usr/lib/libprivatessh.so.5 | grep msetlocale > > | more 0000000000021690 push %rbp > > Now you are dumping a different libprivatessh.so.5 than /usr/bin/ssh is > actually using. Try checking the copy in /lib: > > nm -D /lib/libprivatessh.so.5 | grep msetlocale > > That said, I would carefully check your make.conf settings related to > installworld. If you override LIBDIR, for instance, I think libraries > might be put in the wrong location. > > -Dimitry > Repairing /lib did it! All libs in /lib were from Feb 3rd and had symbolic links. Thanks for the help! Kind regards, Oliver From owner-freebsd-current@freebsd.org Tue Mar 28 08:10: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 82A40D1B89D for ; Tue, 28 Mar 2017 08:10:44 +0000 (UTC) (envelope-from mueller6722@twc.com) Received: from dnvrco-oedge-vip.email.rr.com (dnvrco-outbound-snat.email.rr.com [107.14.73.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "dnvrco-oedge-vip.email.rr.com", Issuer "dnvrco-oedge-vip.email.rr.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 602C9C88 for ; Tue, 28 Mar 2017 08:10:43 +0000 (UTC) (envelope-from mueller6722@twc.com) Received: from [74.134.208.22] ([74.134.208.22:13736] helo=localhost) by dnvrco-omsmta01 (envelope-from ) (ecelerity 3.6.9.48312 r(Core:3.6.9.0)) with ESMTP id B2/60-09002-D7A1AD85; Tue, 28 Mar 2017 08:10:37 +0000 Date: Tue, 28 Mar 2017 08:10:36 +0000 Message-ID: From: "Thomas Mueller" To: freebsd-current@freebsd.org Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <45E32F4F-A238-47AA-8E1E-7AD4D9E857D9@dsl-only.net> <7FFF80B9-CE74-49C8-B295-DCB630368152@FreeBSD.org> X-RR-Connecting-IP: 107.14.64.6:25 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, 28 Mar 2017 08:10:44 -0000 This raises the question, how much diskspace is required or advised for a full FreeBSD installation if both the base system and ports are built from source? Some messages in this thread have raised the possibility of needing 49 to over 100 GB, which is much more than I have allotted. Also, what about space for a local repository when using synth for ports? I could run out of space on some of my partitions but could make a much bigger separate partition if necessary, 500 GB or more. If this question diverges from the proper thread topic, feel free to change the subject line and respond to freebsd-ports if that is more appropriate, so I won't be accused of hijacking this thread. Tom From owner-freebsd-current@freebsd.org Tue Mar 28 16:31:16 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 2760AD22D79 for ; Tue, 28 Mar 2017 16:31:16 +0000 (UTC) (envelope-from rwestlun@gmail.com) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 E846119C for ; Tue, 28 Mar 2017 16:31:15 +0000 (UTC) (envelope-from rwestlun@gmail.com) Received: by mail-qt0-x231.google.com with SMTP id r45so68732871qte.3 for ; Tue, 28 Mar 2017 09:31:15 -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=8nW1T5TyRkk9XHQIwASn+d0yoZu94dU6FmQl/CFhfFc=; b=qDSf8yY4wgqEPX1Oj6ICXYq7vYDgjPp3ycEmZhB5EMDbPMxJYGsDozqs8KRhQen1NA +SdCMrtfGeL2kamsdpwxsNBGzv99MdIgYJ+Bi9NMTmhihi9af3gMGmR527Pw8mjoBa0g N3ATcyt90cUXag6wc+gWkUfPvR1Sp7EW/NC8ZLim5YGFwlm5K7581MIp5xQ9/tTgknNx KtJ3HNuCjZHsl7mj4d+DLQwZ31MsorEpmHhG1IbUwZ5bqy7jXC36HSrCbGVKB1Nmnv2P ChKTlgyVd4QpRqvwv6B8VeaHvaZ3d0hLExJDwZJ12lhp12O2I7MAlCzQOLeTgvzOBoys ih5Q== 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=8nW1T5TyRkk9XHQIwASn+d0yoZu94dU6FmQl/CFhfFc=; b=cQSQ6rY9vaWh/Qk8tphSc+KY/aOpZmp+rcZjT5BRK6sxdqUPnOuNyA7wL9NwfY/bFE qzWsohX540dEJsCpL6JiNh1Z/4JmILCTTDqkUIJqUFICKDypWEMAKFvuOTWDIo4lNUsv x9N5GoIc4NbGtaBtZFw6DrXd7zHAjzD+18mb2IaDz9TBmlFt+KNk47bIvkjsnwlW8UBu s5H/jUoJokC+8jvrQzyZrPP15XHuG1O08xNlhXJ1Ak0sX8s7IDaqioAeYtsRmRkzVLOA lSmU5fJHafveqZaj688Hnr3S/yGCOnxCZz/xgg2C8oQh5Y36O5VuWJE2IAbEur3j3nVY 4S1g== X-Gm-Message-State: AFeK/H3K/BnSlREOC7o4RYkHsGd4TrU68nhdnmDCzeRF2vmi5+EmZPFtcUtKcXAfSrFimA== X-Received: by 10.200.50.112 with SMTP id y45mr26171906qta.75.1490718674766; Tue, 28 Mar 2017 09:31:14 -0700 (PDT) Received: from gmail.com (c-24-2-162-133.hsd1.ma.comcast.net. [24.2.162.133]) by smtp.gmail.com with ESMTPSA id v63sm2978996qkc.5.2017.03.28.09.31.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 09:31:14 -0700 (PDT) Date: Tue, 28 Mar 2017 12:31:10 -0400 From: Randy Westlund To: freebsd-current@freebsd.org Subject: Build fails in libpcap with WITHOUT_INET6 Message-ID: <20170328163110.GD78849@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7DO5AaGCk89r4vaK" 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: Tue, 28 Mar 2017 16:31:16 -0000 --7DO5AaGCk89r4vaK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Building r315872 for the Tegra (arm/armv6) board with WITHOUT_INET6 set fai= ls in libpcap: > --- klm_prot_xdr.pico --- > cc -target armv6-gnueabihf-freebsd12.0 --sysroot=3D/usr/home/randy/tegra/= freebs > d-obj/arm.armv6/usr/home/randy/tegra/freebsd/tmp -B/usr/home/randy/tegra/= free > bsd-obj/arm.armv6/usr/home/randy/tegra/freebsd/tmp/usr/bin -fpic -DPIC -g= -O > -pipe -DYP -I/usr/home/randy/tegra/freebsd-obj/arm.armv6/usr/home/randy= /teg > ra/freebsd/tmp/usr/include/rpcsvc -MD -MF.depend.klm_prot_xdr.pico -MTkl= m_pr > ot_xdr.pico -std=3Dgnu99 -Wsystem-headers -Werror -Wno-pointer-sign -Wno-= empty- > body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-co= mpar > e -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-e= num- > conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-s= witc > h -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused= -arg > uments -c klm_prot_xdr.c -o klm_prot_xdr.pico > --- all_subdir_lib/libpcap --- > /usr/home/randy/tegra/freebsd/contrib/libpcap/gencode.c:695:9: error: no = memb > er named 'ai' in 'struct _compiler_state' > cstate.ai =3D NULL; > ~~~~~~ ^ > --- all_subdir_lib/librpcsvc --- > --- mount_xdr.pico --- > cc -target armv6-gnueabihf-freebsd12.0 --sysroot=3D/usr/home/randy/tegra/= freebs > d-obj/arm.armv6/usr/home/randy/tegra/freebsd/tmp -B/usr/home/randy/tegra/= free > bsd-obj/arm.armv6/usr/home/randy/tegra/freebsd/tmp/usr/bin -fpic -DPIC -g= -O > -pipe -DYP -I/usr/home/randy/tegra/freebsd-obj/arm.armv6/usr/home/randy= /teg > ra/freebsd/tmp/usr/include/rpcsvc -MD -MF.depend.mount_xdr.pico -MTmount= _xdr > .pico -std=3Dgnu99 -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-= body - > Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare = -Wno > -unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-co= nver > sion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch = -Wno > -switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-argum= ents > -c mount_xdr.c -o mount_xdr.pico > --- all_subdir_lib/libpcap --- > /usr/home/randy/tegra/freebsd/contrib/libpcap/gencode.c:4916:13: error: u= se o > f undeclared identifier 'cstate' > bpf_error(cstate, "direction applied to 'gateway'"); > ^ > /usr/home/randy/tegra/freebsd/contrib/libpcap/gencode.c:4923:11: error: u= se o > f undeclared identifier 'cstate' > switch (cstate->linktype) { > ^ > /usr/home/randy/tegra/freebsd/contrib/libpcap/gencode.c:4961:17: error: u= se o > f undeclared identifier 'cstate' > b1 =3D gen_host(cstate, **alist++, 0xffffffff, proto, Q_O= R, Q_H > OST); > ^ > /usr/home/randy/tegra/freebsd/contrib/libpcap/gencode.c:4963:19: error: u= se o > f undeclared identifier 'cstate' > tmp =3D gen_host(cstate, **alist++, 0xffffffff, p= roto, > Q_OR, > ^ > /usr/home/randy/tegra/freebsd/contrib/libpcap/gencode.c:4972:12: error: u= se o > f undeclared identifier 'cstate' > bpf_error(cstate, "illegal modifier of 'gateway'"); > ^ > 6 errors generated. > *** [gencode.o] Error code 1 >=20 > make[5]: stopped in /usr/home/randy/tegra/freebsd/lib/libpcap > 1 error >=20 > make[5]: stopped in /usr/home/randy/tegra/freebsd/lib/libpcap > *** [all_subdir_lib/libpcap] Error code 2 --7DO5AaGCk89r4vaK Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEAjssMridOhQY6jcWZrB5ePM2yakFAljaj84ACgkQZrB5ePM2 yalK4wf+P1utcqWi+OCaxcBbc380tF4rf0yUZedG/nWHb1HF50R8zIDHJbHFzbDf wLhELWhorDbSkqmR/fkQ4RvpwbgLDPKDbbJCZjjy+R1v6QsmiDQKuYnMtmvrSo1F kJ578B7BaIVPtU/1v9TTdrLWYj9t36aIW35tKSTPnDCez2OU8eIdte9s2oxWX8Yp uOe1Cj2uUF2rbvLnUbqDYOGKTnBX84AWXRLLB6k3QZRYL5ZJddsMwyTL/uWDxoWy 7G9flTTIgFiu3GiSTQ4U+WcGcDakmyAIAA2/QXZQ9zMYOHRZlIyFJqfJzU33U9VL gBE4QYXPMTxwZsKu4l5xZKnkgb8jMg== =C/Pd -----END PGP SIGNATURE----- --7DO5AaGCk89r4vaK-- From owner-freebsd-current@freebsd.org Tue Mar 28 16:45:00 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 0BFF2D2238A for ; Tue, 28 Mar 2017 16:45:00 +0000 (UTC) (envelope-from alex.deiter@gmail.com) Received: from mail-lf0-x242.google.com (mail-lf0-x242.google.com [IPv6:2a00:1450:4010:c07::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 85580ED4 for ; Tue, 28 Mar 2017 16:44:59 +0000 (UTC) (envelope-from alex.deiter@gmail.com) Received: by mail-lf0-x242.google.com with SMTP id v2so11040659lfi.2 for ; Tue, 28 Mar 2017 09:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+pwfZACkFctp1YoWYMAdYLZ18bSuE4u+cWjFgtZWp2c=; b=L6BvNGcIXoGrRjdN8cgcbvnWoyP8Jg5qz7889Gr5Z7CklrEhAtX5hFlEJaD8Keab3H yDPhaOCbBXPQDOE86VtrZNHQQQK+lWuBFYvar9tL+Y9VoEjjNTD7wWfWlnAIy2XFLnru 7EVi7SqB/Kc7ZzZcMAw58cyXN9QksVzn4oQ4o5MMmPaSmm2gqvCN6LolMSlbnNZ3k75X 8My8ndlC30EC1BrZBlfiNTeeisI/zMw3WfkD1N1sfDVqTLczF4Y6ih3KJlBTkNrtewJf 7EPPMOVhF7o0gJCHJD3FR6MYp0mLPNDqBqQZ669E/qq7wfiwvImNgj8PP+QE4eMmTIfE HyPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+pwfZACkFctp1YoWYMAdYLZ18bSuE4u+cWjFgtZWp2c=; b=AGhE2ZzUkRsJEgHMtTJ+XUAXd7nogZ6j9t/TOkCDOXnMWG+uP7kjXcYJmoEUZovz5j odXFYAQ4UCifDiIsWeRRuZaTAdWg+t2YGxO88IFaDuFX9CEE2HfHnO17s7mg3RTffLr9 izFhfo6bSS7mdg5NFP/fXPz1X+IXqsCuCOjtao5OOcd+Y7DGshDykSM/bVL+Y41he7gF 6o2ga4R3iCjqWsWISX7zUPp3xlgjteO8vcKRpxFtlZ5l9APHKBlmyJAqmxRf6WBXqYJo UsRYje0F4XiJl/M5NebOZDfU5ZgFgEBnZAxo75VeUq4E3UiebW/9CKrxkdOdNeV18X8/ JA8Q== X-Gm-Message-State: AFeK/H33Z5h+fs2rcJCwx56XokEhjtRtvIzJaeikTjx+wpSSjLRY4WnJyme6XX+MvE7x4w== X-Received: by 10.46.80.89 with SMTP id v25mr2051309ljd.33.1490719497833; Tue, 28 Mar 2017 09:44:57 -0700 (PDT) Received: from tiamat.deiter.ru ([109.167.157.231]) by smtp.gmail.com with ESMTPSA id r204sm771009lff.57.2017.03.28.09.44.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 09:44:57 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Build fails in libpcap with WITHOUT_INET6 From: Alex Deiter In-Reply-To: <20170328163110.GD78849@gmail.com> Date: Tue, 28 Mar 2017 19:44:55 +0300 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <673B538A-D071-46D0-8586-67CD01CE957B@gmail.com> References: <20170328163110.GD78849@gmail.com> To: Randy Westlund X-Mailer: Apple Mail (2.3259) 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, 28 Mar 2017 16:45:00 -0000 Hello, Please apply patch from upstream: https://github.com/the-tcpdump-group/libpcap/pull/541 Fix compilation if INET6 isn't defined. Addresses GitHub issue #541, but differently from the pull request (it defines gen_gateway() with a function prototype rather than using a pre-prototype-style definition). = https://github.com/the-tcpdump-group/libpcap/commit/470df104c6f55f6d6f390d= f7448d8eb65c7642b9#diff-021c0dd9e9ed7100b9e31d8d95c930f2 Thank you! Alex Deiter alex.deiter@gmail.com > On 28 Mar 2017, at 19:31, Randy Westlund wrote: >=20 > Building r315872 for the Tegra (arm/armv6) board with WITHOUT_INET6 = set fails > in libpcap: >=20 >> --- klm_prot_xdr.pico --- >> cc -target armv6-gnueabihf-freebsd12.0 = --sysroot=3D/usr/home/randy/tegra/freebs >> d-obj/arm.armv6/usr/home/randy/tegra/freebsd/tmp = -B/usr/home/randy/tegra/free >> bsd-obj/arm.armv6/usr/home/randy/tegra/freebsd/tmp/usr/bin -fpic = -DPIC -g -O >> -pipe -DYP = -I/usr/home/randy/tegra/freebsd-obj/arm.armv6/usr/home/randy/teg >> ra/freebsd/tmp/usr/include/rpcsvc -MD -MF.depend.klm_prot_xdr.pico = -MTklm_pr >> ot_xdr.pico -std=3Dgnu99 -Wsystem-headers -Werror -Wno-pointer-sign = -Wno-empty- >> body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compar >> e -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function = -Wno-enum- >> conversion -Wno-unused-local-typedef -Wno-address-of-packed-member = -Wno-switc >> h -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses = -Qunused-arg >> uments -c klm_prot_xdr.c -o klm_prot_xdr.pico >> --- all_subdir_lib/libpcap --- >> /usr/home/randy/tegra/freebsd/contrib/libpcap/gencode.c:695:9: error: = no memb >> er named 'ai' in 'struct _compiler_state' >> cstate.ai =3D NULL; >> ~~~~~~ ^ >> --- all_subdir_lib/librpcsvc --- >> --- mount_xdr.pico --- >> cc -target armv6-gnueabihf-freebsd12.0 = --sysroot=3D/usr/home/randy/tegra/freebs >> d-obj/arm.armv6/usr/home/randy/tegra/freebsd/tmp = -B/usr/home/randy/tegra/free >> bsd-obj/arm.armv6/usr/home/randy/tegra/freebsd/tmp/usr/bin -fpic = -DPIC -g -O >> -pipe -DYP = -I/usr/home/randy/tegra/freebsd-obj/arm.armv6/usr/home/randy/teg >> ra/freebsd/tmp/usr/include/rpcsvc -MD -MF.depend.mount_xdr.pico = -MTmount_xdr >> .pico -std=3Dgnu99 -Wsystem-headers -Werror -Wno-pointer-sign = -Wno-empty-body - >> Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno >> -unused-value -Wno-parentheses-equality -Wno-unused-function = -Wno-enum-conver >> sion -Wno-unused-local-typedef -Wno-address-of-packed-member = -Wno-switch -Wno >> -switch-enum -Wno-knr-promoted-parameter -Wno-parentheses = -Qunused-arguments >> -c mount_xdr.c -o mount_xdr.pico >> --- all_subdir_lib/libpcap --- >> /usr/home/randy/tegra/freebsd/contrib/libpcap/gencode.c:4916:13: = error: use o >> f undeclared identifier 'cstate' >> bpf_error(cstate, "direction applied to 'gateway'"); >> ^ >> /usr/home/randy/tegra/freebsd/contrib/libpcap/gencode.c:4923:11: = error: use o >> f undeclared identifier 'cstate' >> switch (cstate->linktype) { >> ^ >> /usr/home/randy/tegra/freebsd/contrib/libpcap/gencode.c:4961:17: = error: use o >> f undeclared identifier 'cstate' >> b1 =3D gen_host(cstate, **alist++, 0xffffffff, proto, = Q_OR, Q_H >> OST); >> ^ >> /usr/home/randy/tegra/freebsd/contrib/libpcap/gencode.c:4963:19: = error: use o >> f undeclared identifier 'cstate' >> tmp =3D gen_host(cstate, **alist++, = 0xffffffff, proto, >> Q_OR, >> ^ >> /usr/home/randy/tegra/freebsd/contrib/libpcap/gencode.c:4972:12: = error: use o >> f undeclared identifier 'cstate' >> bpf_error(cstate, "illegal modifier of 'gateway'"); >> ^ >> 6 errors generated. >> *** [gencode.o] Error code 1 >>=20 >> make[5]: stopped in /usr/home/randy/tegra/freebsd/lib/libpcap >> 1 error >>=20 >> make[5]: stopped in /usr/home/randy/tegra/freebsd/lib/libpcap >> *** [all_subdir_lib/libpcap] Error code 2 >=20 >=20 From owner-freebsd-current@freebsd.org Tue Mar 28 18:58:23 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 287EED2363F for ; Tue, 28 Mar 2017 18:58:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::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 B61F538E for ; Tue, 28 Mar 2017 18:58:22 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wr0-x236.google.com with SMTP id w11so94375883wrc.3 for ; Tue, 28 Mar 2017 11:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=T18DxqJEfP0kUtOD7ODgaXFh2oRf/XyJtqiXgvgk/u4=; b=MhQk55jnPS7/ry7WM09+UYDs7jUSud5LPXs/Pkkvqnt1QrvMS+hvkZHcky1h3TAO6O NVZDuyVWKPhRpcK3yEBIM9h4x15Ai0pIVg5EhB9DvkqHbpJzSNN/d5iFZPk9otjYz8sK MIOfM7yCRm7IcMiM9OcaK5Wf/YVl5lMQ+fS+6cYi6QhiN34lQ6IVaD4CtYZA4/VnCpeZ JYTdmKWP+PA4Qtt+pZDZOh9B876Nkrdy+NbQTOErJOFIxdgqkIzZUDdLB2EXSlzYyB5d q2o6AHhU0VieS5lQnzdgy72WvcYVGLcS0/TP7+AcWFpws2RanxcxVZaJn6scvRx21LZ1 FAQQ== 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:from:date:message-id:subject :to; bh=T18DxqJEfP0kUtOD7ODgaXFh2oRf/XyJtqiXgvgk/u4=; b=dawSMVXKtG5+aTgPhcMb5ffPveLaPT1/y5ipZMAB2VK+wg5+Dc1LfrrKIFlBlKOosN ii5tgc90VNsMYegqksLGUljMox0U1XFVgnYNqE8zcjMHRy1IJ3MMWyET8vdWz+8dSmxA 8Zc3Dm2v8ptHymZ3UWa1gLc1bK+bqIFg72kmjNwC9Ek9mLjxPFxAEkVWwWxM5j9KW6rF dwARwPKHOe2sRPea6GJ+EOyafcGfWIp+aVromAZ/V2J5KHWGRZ+G6nFMklfIMnfvjdxV Cnjp4i2sOEhDWXzDe8Zc3YHEgO0sZBWgo0bi75zrExgw1sbidhc91bzYHEjAF63Inbyn +CHQ== X-Gm-Message-State: AFeK/H0SVAXnqI/oIciIqKkGkIvCgE7+swmdRkbKqQRK9UXgmI9Ml4tKAvmKS2HCKFJGwBVnm8+6YvCeofllOA== X-Received: by 10.223.152.43 with SMTP id v40mr24719051wrb.60.1490727500860; Tue, 28 Mar 2017 11:58:20 -0700 (PDT) MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.28.128.133 with HTTP; Tue, 28 Mar 2017 11:58:20 -0700 (PDT) From: Adrian Chadd Date: Tue, 28 Mar 2017 11:58:20 -0700 X-Google-Sender-Auth: xvR9Sr_mkoXRRL7QInZZTtHpgBc Message-ID: Subject: increased power consumption lately? To: 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: Tue, 28 Mar 2017 18:58:23 -0000 hiya, I've noticed that my battery life on my haswell laptop (T540p) seems to have taken a nosedive lately. I could've /sworn/ it was getting better than 15-16W at idle. Has anyone noticed any massive decrease in battery life lately? -adrian From owner-freebsd-current@freebsd.org Tue Mar 28 19:22: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 67B22D22192; Tue, 28 Mar 2017 19:22:46 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 32E31BE8; Tue, 28 Mar 2017 19:22:45 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id v2SJ24bB036623; Tue, 28 Mar 2017 12:02:10 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: "FreeBSD Hackers" Cc: "FreeBSD CURRENT" From: "Chris H" Subject: is an r316100 world/kernel possible from a r314700 jail? Date: Tue, 28 Mar 2017 12:02:10 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 28 Mar 2017 19:22:46 -0000 While I *know* this at *least* risky business; I was wondering what the chances are that I can create a new world/kernel from my current custom world/kernel? I've built/installed world/kernel (12-CURRENT) tracking HEAD. Which is now at r314700. But was hoping I could test a copy of r316100 by building everything in an r314700 jail. Thanks for any thoughts you'd care to share on this! --Chris From owner-freebsd-current@freebsd.org Tue Mar 28 19:30: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 A163DD2276F for ; Tue, 28 Mar 2017 19:30:46 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 86BB33DD for ; Tue, 28 Mar 2017 19:30:46 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mailman.ysv.freebsd.org (Postfix) id 831C5D2276E; Tue, 28 Mar 2017 19:30:46 +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 82BF9D2276B for ; Tue, 28 Mar 2017 19:30:46 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f68.google.com (mail-lf0-f68.google.com [209.85.215.68]) (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 18CF03DB for ; Tue, 28 Mar 2017 19:30:45 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f68.google.com with SMTP id r36so11457099lfi.0 for ; Tue, 28 Mar 2017 12:30:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=7B24Cdpvd4PvhSno36UvOP/ybv7TfgGvyo5hTyQ4a88=; b=jzCDrjxXFU7EPWIPpU6P2N3R0lfuGtFphDXAzHWhbz+4LyE+WlIFglXxYORg1PdDii rdcnJV+2QqDRFF7WRVkpb21o24QF03WQGKcrBvtTllEkBsLcmbEZEFUOVTWn3DP7VOrV NEevNlbZMfUaEv6l8WCiP/YNRYIZwz+T8uyKy9bqmo2m2wtQt+3iFFU96pGsf1S9fkwJ x8cRYB5V5CBU3+FSlMvV6tRqSfN5IJj9NIwaU+zyLZr420ITlhM0U5ViUAOcSVc9Hrk7 XUlVXk/yQLTDP2sQqlE08mYImVTwJCTfM06bTm1ZuJxRrhBuDGAL3cYor9TnjPWmmkg7 DYEA== X-Gm-Message-State: AFeK/H1jPxDrI3cZzVlln+U0BOxhicZ3Q2dI/SVdEa1MeYNRbY5IbrQIt1HqYa0lAaL/ZA== X-Received: by 10.25.201.74 with SMTP id z71mr12973471lff.108.1490729443979; Tue, 28 Mar 2017 12:30:43 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id 30sm833966lju.53.2017.03.28.12.30.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 12:30:43 -0700 (PDT) To: current@freebsd.org From: Andrey Chernov Subject: shutdown -r doesn't execute rc.d sequence Message-ID: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> Date: Tue, 28 Mar 2017 22:30:42 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 28 Mar 2017 19:30:46 -0000 With latest -current amd64, reboot happens almost immediately, leaving FS dirty. No proper backward rc.d or /usr/local/etc/rc.d sequence execution is shown. No deactivating GELI swap too. From owner-freebsd-current@freebsd.org Tue Mar 28 19:33: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 915F6D22A09 for ; Tue, 28 Mar 2017 19:33:44 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 6CB359E4 for ; Tue, 28 Mar 2017 19:33:44 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 6C135D22A08; Tue, 28 Mar 2017 19:33:44 +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 6BB78D22A07 for ; Tue, 28 Mar 2017 19:33:44 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 399C29E3; Tue, 28 Mar 2017 19:33:44 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pg0-x22e.google.com with SMTP id g2so81108576pge.3; Tue, 28 Mar 2017 12:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=VyO8DfsxcgLIWOv/yNLi7/kMbVVlYdT2toBIn7EhyDg=; b=PSTjIXpbLaUUoZRTArGgTiH8xSYRNxApV5IYrOUth20Ls1tNJ+jag/pAQb5l+d43iE G8X9yOVIx+LeLCDcsifCBr6Yw0NelNUCzmZRFuREHb40G00U5P9GLU6xHrdVoRUOwbAE G2sR9aOI6vIsN9mWLkc9bg9mCZ/1dnX4q64ciWTtemXpbkYUq2elXN9U4SZiWAdj20yJ O7XqaCNh/1KeXB2B+cY5Ca6qY3dBcr8hZfGj1/JuAL5SI2zWAuqXIz0bxxjb3lXDQrWh 2qS53WGli4Wk3HyyXnzVN+L3YeuZpyPVIO7ALF8BQ54HA3qhvTHpNz/b+QQz+Wh6KGKb GxnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=VyO8DfsxcgLIWOv/yNLi7/kMbVVlYdT2toBIn7EhyDg=; b=D8mnvuvzIoEwtAmK99GEoP2OaCPFPxKgFJ84U4ALL9CjBRvmbni+Jt7XF4VkfRH07u eGAl8GMj22NRS2LFlaYDRHuGFdOcVYzqUdB4oL6bdG/w38HpMAX2LHrLRCrrrQFjltPc Z8wpG0NvN0K42kFp2TKa4wy764FOGuXASf2MhKCovNoy7sD8mjhjkUdJizStnvqdRPBG QT2bGx0uMkww/lbZupcInxu57QMtaJKYo+aXvWNVnkNu/5dStKfsidIi1zfqddMaBCGb sVk+TPGeLjAtXQ8tXcqLTGraMtyg+Yg1hPK77MCIn2TA/bOUkjqopUupKW0wlnKQv+YH qR/Q== X-Gm-Message-State: AFeK/H3Lfou06JKuoH7m7oTGt1yc+VwcsWFxUOhaQbkPvZS4SL6W9CS8AtPM6jVNNC5R/Q== X-Received: by 10.98.160.194 with SMTP id p63mr4109001pfl.72.1490729623599; Tue, 28 Mar 2017 12:33:43 -0700 (PDT) Received: from pinklady.local (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id l9sm8943208pfi.97.2017.03.28.12.33.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 28 Mar 2017 12:33:42 -0700 (PDT) Subject: Re: shutdown -r doesn't execute rc.d sequence Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D3077A37-EFAB-44D3-9E9F-D0BE39E71DB8"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Ngie Cooper (yaneurabeya)" In-Reply-To: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> Date: Tue, 28 Mar 2017 12:33:41 -0700 Cc: current@freebsd.org Message-Id: References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> To: Andrey Chernov X-Mailer: Apple Mail (2.3124) 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, 28 Mar 2017 19:33:44 -0000 --Apple-Mail=_D3077A37-EFAB-44D3-9E9F-D0BE39E71DB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 28, 2017, at 12:30, Andrey Chernov wrote: >=20 > With latest -current amd64, reboot happens almost immediately, leaving > FS dirty. No proper backward rc.d or /usr/local/etc/rc.d sequence > execution is shown. No deactivating GELI swap too. Hi Andrey, Do you have a typescript demonstrating this? Adding rc_debug=3Dyes= to /etc/rc.conf would be super helpful, along with `boot -v`, to see = whether the issue is in userspace or rc(5). I=E2=80=99ll double check my amd64/i386 VMs too (if possible, = redirect the output over serial to a typescript for analysis). Are you using vanilla FreeBSD, a fork, or a packaged variant = (mfsbsd, nanobsd, etc)? Thanks! -Ngie --Apple-Mail=_D3077A37-EFAB-44D3-9E9F-D0BE39E71DB8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY2rqWAAoJEPWDqSZpMIYVhwAP/jvSZ3Czu76qXbwY7zzI/PkO jmJe7ar7gfz/AJMdJ4VWOIwS5gVqJMm/YRdaynvkZH56aThKoY5YwJx5+HdwanfT Q+jkonynRxT8BmBMecFMPSaeldYxYcXunmJ6SpbdU5recxP+UF7dBulAW+uRkGQm MtV/sbE1BF6Y9c0qMD4rRJ31PDBFgzXM9kMVZE+vTzlFsnzFCUioJ2u/mllZKS5P /VktnYLAAmvSOMG3fXwu/lwuZgukoNOS9pPTSst+WHpERJ7UNjmOf6o629SGWqZU 7h+wD3MYhJEgYtxbb9kkGCDpva0U/fWU3s8duujIE6yOPLS2nIg0lRuTfF315k/a PJAwpCoQhTrdBn/Sb+GFpinDMyNe0CNsb5jQyublejke8/x3SPq4NXtYXbf0VZkB fqZ7dve3h3pz2EzrRLBnGAmiPnkFsnn98BCeFP6mMTRwDOgfdpcUnOglp2gZxPak tCwk1aZ8wztAVCzRxHbDPOgxbf+CprU5XxGUEZ9cS2uAtFWnrVAdN+Z9zEyj6a6M lO7DG1Y49nJtRMPjPBGdGShl3BQcZmDKkkINZPenN4Q30E0EMUeWA0ppJ2d9MDtz MFUXJ0JVFM9JwtARNzicYGeSo9XM4Y6jKQqoogLZiAS34MVMqV/zL962KPLDbJPZ 553bmUysDUt2DC8nqAsr =45EU -----END PGP SIGNATURE----- --Apple-Mail=_D3077A37-EFAB-44D3-9E9F-D0BE39E71DB8-- From owner-freebsd-current@freebsd.org Tue Mar 28 19:38: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 5DCC5D22BA9 for ; Tue, 28 Mar 2017 19:38:57 +0000 (UTC) (envelope-from mailing-machine@vniz.net) 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 396A1BFE for ; Tue, 28 Mar 2017 19:38:57 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mailman.ysv.freebsd.org (Postfix) id 35E6FD22BA8; Tue, 28 Mar 2017 19:38:57 +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 358BED22BA7 for ; Tue, 28 Mar 2017 19:38:57 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f65.google.com (mail-lf0-f65.google.com [209.85.215.65]) (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 D6DAABFD for ; Tue, 28 Mar 2017 19:38:56 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f65.google.com with SMTP id v2so11450515lfi.2 for ; Tue, 28 Mar 2017 12:38:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=NlbXc06d0wzahjFtgPTH1zpzTcIBi6WEzY1TBha3lo8=; b=eiQTC5WQa/+4hsgu4XKLok6M5yDc8I37KD6lgpu4gJRHxDw6nsCuP2e64JszdQIotS whXWSbnOgJM+9UHgVvjV7euleoipEEESxok7WdrBenbF9WPDdrrcTSW7p4xUgfGJBNR1 dBFJEEhlrCqC/IhqcZxqgqmUuV1isrHNeqO+WR7nTNXEOpuowQqQKtMSE6TqttzCS0eT 8g++iGF1n2dxw0VvB42MTCSmj/Iww2Ug3R0fRxyIgBD4tgBAM/F5jNH1IeTMNWMh7i60 YlmzP5CYC5x30aYb30te6+trGaZfMjIQyzM0zLHPGDVbedPn5Qbfh/Ix1T7yAMI5EHUR UI9w== X-Gm-Message-State: AFeK/H03GeL3pN6fjIorffR0AJEgqguE1RwBJ9koCHWTWyadjM3jk/nHVMdt7TIUHZq2GQ== X-Received: by 10.46.83.85 with SMTP id t21mr2276943ljd.82.1490729934727; Tue, 28 Mar 2017 12:38:54 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id f19sm848953lji.69.2017.03.28.12.38.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 12:38:54 -0700 (PDT) Subject: Re: shutdown -r doesn't execute rc.d sequence To: "Ngie Cooper (yaneurabeya)" References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> Cc: current@freebsd.org From: Andrey Chernov Message-ID: <39da5181-98f4-8d6b-15bb-dd2552cce055@freebsd.org> Date: Tue, 28 Mar 2017 22:38:53 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sITnRn3vKMvEJua8p65lrm66huBlVpegr" 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, 28 Mar 2017 19:38:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sITnRn3vKMvEJua8p65lrm66huBlVpegr Content-Type: multipart/mixed; boundary="fGDMFLLN6E4qUaEuMfjS9xmbqnumMLmWo"; protected-headers="v1" From: Andrey Chernov To: "Ngie Cooper (yaneurabeya)" Cc: current@freebsd.org Message-ID: <39da5181-98f4-8d6b-15bb-dd2552cce055@freebsd.org> Subject: Re: shutdown -r doesn't execute rc.d sequence References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> In-Reply-To: --fGDMFLLN6E4qUaEuMfjS9xmbqnumMLmWo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 28.03.2017 22:33, Ngie Cooper (yaneurabeya) wrote: >=20 >> On Mar 28, 2017, at 12:30, Andrey Chernov wrote: >> >> With latest -current amd64, reboot happens almost immediately, leaving= >> FS dirty. No proper backward rc.d or /usr/local/etc/rc.d sequence >> execution is shown. No deactivating GELI swap too. >=20 > Hi Andrey, > Do you have a typescript demonstrating this? Adding rc_debug=3Dyes to = /etc/rc.conf would be super helpful, along with `boot -v`, to see whether= the issue is in userspace or rc(5). > I=E2=80=99ll double check my amd64/i386 VMs too (if possible, redirect= the output over serial to a typescript for analysis). > Are you using vanilla FreeBSD, a fork, or a packaged variant (mfsbsd, = nanobsd, etc)? > Thanks! > -Ngie I don't have serial, so typescript may not work treating as dirty, but I'll try. As I say, it is today's -current, vanilla. It looks like regression because few weeks ago all things works. --fGDMFLLN6E4qUaEuMfjS9xmbqnumMLmWo-- --sITnRn3vKMvEJua8p65lrm66huBlVpegr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJY2rvNAAoJEKUckv0MjfbKV7QH+weP7pm5yqZBjWeDnsHcT09U 3CxVR6GcJRmv1OwwG4i+pQzEobzW25M9KRttwMCkZLbbw3JO9LbFm6kZ1e0OPAND I3W9w1VYaUpJMluHoFdvJfe68l9JtVCfRlogfW980qDg0N7t9U+LwS2OBzgICNJf Zuv6jc41TPypRwWpft5lxhAoMcg6ZDuZMHZ7niUkLMJtBi5n1oGHe/NWTUsN0vca YLknZiMdE0X+/LYpJf1US18f50bUeeuSBwACFW0T7lwZAKZJRfztVgMlxgewLIMY P1P6cKuOthcVOLJ3XdrtdEivBGS+jg+A6sajd3xE6xHmFJ5H7PckpgGdBcOkJy0= =CO9b -----END PGP SIGNATURE----- --sITnRn3vKMvEJua8p65lrm66huBlVpegr-- From owner-freebsd-current@freebsd.org Tue Mar 28 19:47: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 60BDFD22F05 for ; Tue, 28 Mar 2017 19:47:35 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 48E3214B for ; Tue, 28 Mar 2017 19:47:35 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 48467D22F04; Tue, 28 Mar 2017 19:47:35 +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 47F6DD22F03 for ; Tue, 28 Mar 2017 19:47:35 +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 E9FC614A; Tue, 28 Mar 2017 19:47:34 +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 v2SJlRJE028888; Tue, 28 Mar 2017 19:47:27 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v2SJlQxu028887; Tue, 28 Mar 2017 12:47:26 -0700 (PDT) (envelope-from david) Date: Tue, 28 Mar 2017 12:47:26 -0700 From: David Wolfskill To: Andrey Chernov Cc: "Ngie Cooper (yaneurabeya)" , current@freebsd.org Subject: Re: shutdown -r doesn't execute rc.d sequence Message-ID: <20170328194726.GG1415@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Andrey Chernov , "Ngie Cooper (yaneurabeya)" , current@freebsd.org References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <39da5181-98f4-8d6b-15bb-dd2552cce055@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="G4GkWxNJALccptvH" Content-Disposition: inline In-Reply-To: <39da5181-98f4-8d6b-15bb-dd2552cce055@freebsd.org> 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: Tue, 28 Mar 2017 19:47:35 -0000 --G4GkWxNJALccptvH Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 28, 2017 at 10:38:53PM +0300, Andrey Chernov wrote: > ... > >> With latest -current amd64, reboot happens almost immediately, leaving > >> FS dirty. No proper backward rc.d or /usr/local/etc/rc.d sequence > >> execution is shown. No deactivating GELI swap too. > >=20 > > Hi Andrey, > > Do you have a typescript demonstrating this? Adding rc_debug=3Dyes to = /etc/rc.conf would be super helpful, along with `boot -v`, to see whether t= he issue is in userspace or rc(5). > > I=E2=80=99ll double check my amd64/i386 VMs too (if possible, redirect= the output over serial to a typescript for analysis). > > Are you using vanilla FreeBSD, a fork, or a packaged variant (mfsbsd, = nanobsd, etc)? > > Thanks! > > -Ngie >=20 > I don't have serial, so typescript may not work treating as dirty, but > I'll try. As I say, it is today's -current, vanilla. It looks like > regression because few weeks ago all things works. > .... FWIW, I did not see an issue either for my build machine of my laptop at r316082: FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #298 r3160= 82M/316093:1200027: Tue Mar 28 06:37:15 PDT 2017 root@g1-252.catwhisker= =2Eorg:/common/S4/obj/usr/src/sys/CANARY amd64 Peace, david --=20 David H. Wolfskill david@catwhisker.org Who would have thought that a "hotelier" would be so ... unwelcoming? Sad. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --G4GkWxNJALccptvH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJY2r3OXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4X94YIALDs85mdH6SDaZHVBKHU6OOE jlTpJa5IBq4bwGCpqCj037AhdSQ8B7wg/M/Q1PLucC+k4ZrA8o9Hx8vCPBCGZMnS jkYqVfy5DWkX/ZZw4kVxIOQejazs/H2Z5/OwJnTgf7e50SjrOLws1v53lgD9+9ZS iEdj7BA8TWTxpfiGTmRlHOClErI5CXOff3jZ25LO5gr6nikGYuYBYmmGmxy5I8IY 8VsPM6Qm9c3Dh/xyxvRZsVcy2amn4fRn3IZhkgL8fd+QEg01phbMZTBlJfTNUHPZ iH5xh0Tsos8kwJ1fwv9nCBIJ6XpNl2yP0b+hYU2MXSAv8DEL0qPr2SRpm63qeq4= =W+q7 -----END PGP SIGNATURE----- --G4GkWxNJALccptvH-- From owner-freebsd-current@freebsd.org Tue Mar 28 19:50:58 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 26844D21153; Tue, 28 Mar 2017 19:50:58 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 E34337E4; Tue, 28 Mar 2017 19:50:56 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id v2SJpX88063952; Tue, 28 Mar 2017 12:51:39 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: "FreeBSD Hackers" Cc: "FreeBSD CURRENT" In-Reply-To: References: From: "Chris H" Subject: Re: is an r316100 world/kernel possible from a r314700 jail? Date: Tue, 28 Mar 2017 12:51:39 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 28 Mar 2017 19:50:58 -0000 On Tue, 28 Mar 2017 12:02:10 -0700 "Chris H" wrote > While I *know* this at *least* risky business; > I was wondering what the chances are that I can create > a new world/kernel from my current custom world/kernel? > I've built/installed world/kernel (12-CURRENT) tracking > HEAD. Which is now at r314700. But was hoping I could > test a copy of r316100 by building everything in an > r314700 jail. Sorry. That was a *real* stupid question. Sorry for the noise! I've got *way* too many irons in the fire today. Gonna need to slow down. Again, sorry. :-( --Chris From owner-freebsd-current@freebsd.org Tue Mar 28 20:23:10 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 84B60D21EDA for ; Tue, 28 Mar 2017 20:23:10 +0000 (UTC) (envelope-from rwestlun@gmail.com) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 3D0D7E73 for ; Tue, 28 Mar 2017 20:23:10 +0000 (UTC) (envelope-from rwestlun@gmail.com) Received: by mail-qt0-x22d.google.com with SMTP id x35so74461257qtc.2 for ; Tue, 28 Mar 2017 13:23:10 -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=JlZbHmQT6vugN+TygQZRAUF/Lll9YXp43uovXKR70ZQ=; b=F45n8UyPwJUQ7GoWdQJm0WvQbaMWeI5sT8+IsBCMeM/KGOECw/BP2okOne+s8tMxmx XTWJOIoRG38RoCuus39bSu2zRfUNdTabfEeK2LqVeb6kKbC5fkTAZ0/5gdS4d4T6r9xt R1tMQAbCs4kHm3ioamAix2+1kI8ZgghJCoKH0wZorVcRw6ECMO3Pc+f8kW/xW90TaMSP lQIiCf2MBZwYXa718kOkNvIscFOk59ebW041DRkJ6uceRzhmRYEZxtaUv0oYpdj8j07h U/lKlNOFVV0adCkX/5DcuXuUFDiYXG53mH8lXsroqkT8URMDKkcBmJo9geFF04tc/xpw Wo9Q== 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=JlZbHmQT6vugN+TygQZRAUF/Lll9YXp43uovXKR70ZQ=; b=AFMnVttHb2qZAqWXs54yCWkKR6Cp9ysly53PqSE6xU1FndioOI84Ochygw2CAxQWF6 S4+DHZ4GBs2gWp5MDYNcYMmxjZZus7X0T2r9xFjIZmqEMkF6TLjv4kVMBLZVVvDY8gbT FavdzFc0jhN07hoSKz0oK9Y14zdKG5A3TZHDgsmtQxL/kutk5Euw6XLO0VwsyFcx2DMO HFLz1uHDVmG8bybAJdzxfwWq8QrAHSxvy9DqQ3Bnm+34Y3MHjrgANFUQmmW5pbviYY2w HwxqRS8K+WNzllP/NzSFYw9/NSDmXDZoP4PgcW79xqIUmZU/IWnSSSMG+wrYUKHCmKWd QH5g== X-Gm-Message-State: AFeK/H2bV6LqjvWDJj7RGhGFSl5LDpk5+EnAi3dDrabJJl5cHWrjbYQWbhY1YZO3WqwHtA== X-Received: by 10.237.37.229 with SMTP id y34mr28776952qtc.30.1490732589247; Tue, 28 Mar 2017 13:23:09 -0700 (PDT) Received: from gmail.com (c-24-2-162-133.hsd1.ma.comcast.net. [24.2.162.133]) by smtp.gmail.com with ESMTPSA id u43sm3399076qtc.11.2017.03.28.13.23.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 13:23:08 -0700 (PDT) Date: Tue, 28 Mar 2017 16:23:06 -0400 From: Randy Westlund To: Alex Deiter Cc: freebsd-current@freebsd.org Subject: Re: Build fails in libpcap with WITHOUT_INET6 Message-ID: <20170328202306.GF78849@gmail.com> References: <20170328163110.GD78849@gmail.com> <673B538A-D071-46D0-8586-67CD01CE957B@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tmoQ0UElFV5VgXgH" Content-Disposition: inline In-Reply-To: <673B538A-D071-46D0-8586-67CD01CE957B@gmail.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: Tue, 28 Mar 2017 20:23:10 -0000 --tmoQ0UElFV5VgXgH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 28, 2017 at 07:44:55PM +0300, Alex Deiter wrote: > Hello, >=20 > Please apply patch from upstream: >=20 > https://github.com/the-tcpdump-group/libpcap/pull/541 >=20 > Fix compilation if INET6 isn't defined. > Addresses GitHub issue #541, but differently from the pull request (it > defines gen_gateway() with a function prototype rather than using a > pre-prototype-style definition). >=20 > https://github.com/the-tcpdump-group/libpcap/commit/470df104c6f55f6d6f390= df7448d8eb65c7642b9#diff-021c0dd9e9ed7100b9e31d8d95c930f2 >=20 > Thank you! >=20 > Alex Deiter > alex.deiter@gmail.com That works, thanks. --tmoQ0UElFV5VgXgH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEAjssMridOhQY6jcWZrB5ePM2yakFAljaxioACgkQZrB5ePM2 yal+wQgAvKoE1VKU0C7mXt701crNriToq6qr3CfzcIXd9FPZe88GqCyzhFvjRsY7 hDK1L0WM1KDj9H/cwsYwFWfiKE6PRIYgrUmX/T5ayGG5P9u4JR7+b2ksDU31ntj3 3HlsneGDF63Rg9MQ/NZOyGYgY0KNJPtoEbvs/ePknmQav7xoR1mEwu8wXh9LEmv1 XF8kmN4KTL4ICw2JhtgrtSvD+IrMxyQ2nRJwnXlwZBARWlYeHFmASvxttUql3bpJ D63+yctCUyikj/wIDcAXnEtn1DscM0ublp7uJQap+hsmKkv16wirdQLmgle5gyMc 2jvZQgI01k5jL0gG/S3emAR18Sgxuw== =vibh -----END PGP SIGNATURE----- --tmoQ0UElFV5VgXgH-- From owner-freebsd-current@freebsd.org Tue Mar 28 20:37: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 D41BBD2266F for ; Tue, 28 Mar 2017 20:37:02 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6BE1ED02; Tue, 28 Mar 2017 20:37:02 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: by mail-wr0-x22e.google.com with SMTP id w11so95992895wrc.3; Tue, 28 Mar 2017 13:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=2+wYZ77+VVk69COmmd6fzxtb6cObl3zCyTk9J37WA24=; b=qHxAZRUClMWUPQwOJfInMYRqZCmZSFeD/eqf/kNtKVnIHy1eRKFp3yLWN1cS4A4byo Xv/IAq63U2ofxrIxF1z48HG0TcnQ8O6tNOV28jOV+BpnmBID5PQIMr9JD1iqBuvYYtKI KGDKkXoh26+p6axs5MORus6w4UPdxmo29+YmEsCvultVNlU0aNYVjpqsGHm0V1CNA8iY Y4wCd5n8JfgkeCoOPHW3jKB2I7ytDQ0eWG+3QCW0krU/PyXbS581GNXZTaw8sK32kNro Wk2MJIPXfRD6PbQobHaBO4waCyIn8TtIf8ZGS4KjmDZul+qhxuhaF7cVjdZo0PsZFaWr q70Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=2+wYZ77+VVk69COmmd6fzxtb6cObl3zCyTk9J37WA24=; b=VakwYVxs3OpyXFwCV0cUtOJ2umYIm95zZ+XwGQ86pOOc+3rmWZptk8IRG4QSkZoaI0 pdRD/As0cQzeNgCJm2jcPbJ5BXMgAT7m1woX1AHxEWesYotW3kngqQVgbYY7VmSmxDbZ ORUj/Yzxy9O+eyiSt5wtGGPGhIVxsO6jpHnED1mdb1QKhe4msQh6qd926S7tQY0KqesM jdGwmveB7eIOZVKMyxlwm75mjYNjhHBwX5x3sRh1/BVrTylS3ZEgEeD2kIxX1DkZLb/b hooytPH+EBmIBD32wEJgYUH6vq0xFDghnVBuFkpNRUYjNaNyiq6cY/zmF884VvqCnyl0 hYAw== X-Gm-Message-State: AFeK/H0HcLONjkP+i8mlD/9jt8/sBvj026bhs69NomsPcyPWHtwBu2A9LLcLkWcRLQKe8qeq9/RzyDrufCfCcQ== X-Received: by 10.223.170.142 with SMTP id h14mr17816575wrc.146.1490733420415; Tue, 28 Mar 2017 13:37:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Johannes Lundberg Date: Tue, 28 Mar 2017 20:36:49 +0000 Message-ID: Subject: Re: increased power consumption lately? To: Adrian Chadd , 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: Tue, 28 Mar 2017 20:37:02 -0000 Hi Personally I got some acpi-something kernel thread at 100% CPU constant usage. Need to lock CPU freq at lower value otherwise it runs with turboboost all the time. Could it be the same for you? On Tue, 28 Mar 2017 at 20:58, Adrian Chadd wrote: > hiya, > > I've noticed that my battery life on my haswell laptop (T540p) seems > to have taken a nosedive lately. I could've /sworn/ it was getting > better than 15-16W at idle. > > Has anyone noticed any massive decrease in battery life lately? > > > > -adrian > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Tue Mar 28 21:15:49 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 AFBEDD233C4 for ; Tue, 28 Mar 2017 21:15:49 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 8B9F2FA0 for ; Tue, 28 Mar 2017 21:15:49 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mailman.ysv.freebsd.org (Postfix) id 8AFA9D233C3; Tue, 28 Mar 2017 21:15:49 +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 8A9C0D233C2 for ; Tue, 28 Mar 2017 21:15:49 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f67.google.com (mail-lf0-f67.google.com [209.85.215.67]) (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 241F8F9F for ; Tue, 28 Mar 2017 21:15:49 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f67.google.com with SMTP id x137so11681680lff.1 for ; Tue, 28 Mar 2017 14:15:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=TkDikrL2+uNavosi4i7aWfVYLqcgsECs+EXN7W9H4z0=; b=Sgraq7TAbplhJvE7bMr8q2jD82rGU7hjEJQnyZ4NmQNMN5RmNnKXUQ2GUZ87G2y6TS PaHEvlti3Lv/t/KjItOlGZCVLBu9Fgi2eIPPWWyT0aNiLGB+CM0g3PYkrMSt5UpAu6Zw 4PKN/6WahBcqvNryVxofmARn614n8QSIr8u9MOyQvEmUkD1k74QfOM5SI2fev7qHLnwz QcpMRU7vCdR5jXg1f/Tbc0TBDUtG7udI5HCAYrobk1Dxmz+Dn9pusdaeHyD9L/+MJLxh YQ1M0YTf7l8Fu93R7N+b7xUa1HfZF3PbmL+BQ9cjsu0QdQySIO2/5DRLG1VDbUr+jFjB M1iQ== X-Gm-Message-State: AFeK/H3/Tn/nZLmv1xCbmxS3VeW4orATwfB0yEBIcl7rQPAZdxr4qHOzrhX+faj6IF0/og== X-Received: by 10.46.33.209 with SMTP id h78mr2479481lji.53.1490735746908; Tue, 28 Mar 2017 14:15:46 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id w78sm902713lfi.23.2017.03.28.14.15.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 14:15:46 -0700 (PDT) Subject: Re: shutdown -r doesn't execute rc.d sequence To: "Ngie Cooper (yaneurabeya)" References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> Cc: current@freebsd.org From: Andrey Chernov Message-ID: <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> Date: Wed, 29 Mar 2017 00:15:44 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="G0adDj5hAqRloaD3cHOBCakL6tBkAbxCI" 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, 28 Mar 2017 21:15:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --G0adDj5hAqRloaD3cHOBCakL6tBkAbxCI Content-Type: multipart/mixed; boundary="CK2fkpXM9bT4TmFnq0JCrtDEAKU1HNwNq"; protected-headers="v1" From: Andrey Chernov To: "Ngie Cooper (yaneurabeya)" Cc: current@freebsd.org Message-ID: <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> Subject: Re: shutdown -r doesn't execute rc.d sequence References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> In-Reply-To: --CK2fkpXM9bT4TmFnq0JCrtDEAKU1HNwNq Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 28.03.2017 22:33, Ngie Cooper (yaneurabeya) wrote: >=20 >> On Mar 28, 2017, at 12:30, Andrey Chernov wrote: >> >> With latest -current amd64, reboot happens almost immediately, leaving= >> FS dirty. No proper backward rc.d or /usr/local/etc/rc.d sequence >> execution is shown. No deactivating GELI swap too. >=20 > Hi Andrey, > Do you have a typescript demonstrating this? Adding rc_debug=3Dyes to = /etc/rc.conf would be super helpful, along with `boot -v`, to see whether= the issue is in userspace or rc(5). > I=E2=80=99ll double check my amd64/i386 VMs too (if possible, redirect= the output over serial to a typescript for analysis). > Are you using vanilla FreeBSD, a fork, or a packaged variant (mfsbsd, = nanobsd, etc)? > Thanks! > -Ngie >=20 Using rc_debug=3Dyes I see that it is the kernel problem, not rc problem.= Sometimes rc backward sequence executed even fully, sometimes only partly, but in unpredictable moment inside rc sequence the kernel decide to reboot quickly (or even deadly hang in rare cases). Always without any "Syncing buffers..." leaving FS dirty. No zfs etc. just normal UFS, no EFI, no GPT. I change GELI swap to normal one, but it does not help. The same untouched config works for years, I see this bug for the first time in FreeBSD. --CK2fkpXM9bT4TmFnq0JCrtDEAKU1HNwNq-- --G0adDj5hAqRloaD3cHOBCakL6tBkAbxCI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJY2tKBAAoJEKUckv0MjfbKCB8IAI8A8AATbhyAr34Bk0SWl1UZ qGjXKgyBR0FuySkwxqDpZhR5f/UlrWZcw17nrxF13EC1tNW1LI/elYnxuUTBhxe9 VkpOrk/UvqniKoP8VbAU8+K7ssQbRaxJCC7Oczewj+JsaP0rk4fsymA4w4M0LQ/t k3k5m1lLWoRJUjdprmLDSxeqpZeT4Ns0aBhWeYTVoRTq6BsxUgKsTWFCuM1l9Zdn MNq6vEPbjMGKBqmkkrUMBUAocr0s1C8Hkp7WhHMkMtyMFmvlzesR8N300Pn9B06f NrQhI9SSIWwOGvsE9jKRbLl1c2cKvyzESFGIb+f8+dkABFXYMLsfJOm/z7lkEbE= =zJ5L -----END PGP SIGNATURE----- --G0adDj5hAqRloaD3cHOBCakL6tBkAbxCI-- From owner-freebsd-current@freebsd.org Tue Mar 28 21:27:28 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 F27B6D236FC for ; Tue, 28 Mar 2017 21:27:28 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id CD704A91 for ; Tue, 28 Mar 2017 21:27:28 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mailman.ysv.freebsd.org (Postfix) id CA048D236FB; Tue, 28 Mar 2017 21:27:28 +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 C7FADD236FA for ; Tue, 28 Mar 2017 21:27:28 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f68.google.com (mail-lf0-f68.google.com [209.85.215.68]) (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 44D13A8C for ; Tue, 28 Mar 2017 21:27:28 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f68.google.com with SMTP id n78so11676867lfi.3 for ; Tue, 28 Mar 2017 14:27:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=X81kd+l7Fdk5U1WsNj15pzH83se+F5dUlOIBqpA+mcE=; b=YssQ6hhTKH/PT/ZGLI9cX0QtT9ZsFWEhjkJC+OLetmcn5051ufTv9LNE89iQgc5Aq7 48+hiKr9VtNxhnbi5mE+qAgtsM8BKrArDeAA/sJLBHlQ75Y9Yei9kC0pjdj7QTwBLNld FfmqrKF42DXRDh+N5qQhpEDcWZeFKMUMcSRNE2tT/I8V5j5gvHriEYKT45v42vWn6c+x 5SdPi5dKGzOdKN0j9QVhms8hQctDEZCKKvD3PfJ6mteU0dnzjffTtysS4SC2mCASvH3O 9qkpneMtTCfllUT3NV2WNMd1349tPUOtRPB7ypPLgcD7M9t0uIfhbnK7O1EOdKYtaI5P upfQ== X-Gm-Message-State: AFeK/H0yFf63Fa95rMl2/sGJJafxkee1B8UTMVpy4bZpB4RdbjoT38TLtlkzxeD3OMcARw== X-Received: by 10.25.19.194 with SMTP id 63mr13962017lft.144.1490736446242; Tue, 28 Mar 2017 14:27:26 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id 34sm895367lfv.48.2017.03.28.14.27.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 14:27:25 -0700 (PDT) Subject: Re: shutdown -r doesn't execute rc.d sequence To: "Ngie Cooper (yaneurabeya)" References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> Cc: current@freebsd.org From: Andrey Chernov Message-ID: <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> Date: Wed, 29 Mar 2017 00:27:24 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NR6HbT8a8dF4wQaL5s2GnklSPaADeSVAE" 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, 28 Mar 2017 21:27:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NR6HbT8a8dF4wQaL5s2GnklSPaADeSVAE Content-Type: multipart/mixed; boundary="mMRgSVl1IJxkBxBQES7cVIqaTrCGMX6i3"; protected-headers="v1" From: Andrey Chernov To: "Ngie Cooper (yaneurabeya)" Cc: current@freebsd.org Message-ID: <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> Subject: Re: shutdown -r doesn't execute rc.d sequence References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> In-Reply-To: <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> --mMRgSVl1IJxkBxBQES7cVIqaTrCGMX6i3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 29.03.2017 0:15, Andrey Chernov wrote: > On 28.03.2017 22:33, Ngie Cooper (yaneurabeya) wrote: >> >>> On Mar 28, 2017, at 12:30, Andrey Chernov wrote: >>> >>> With latest -current amd64, reboot happens almost immediately, leavin= g >>> FS dirty. No proper backward rc.d or /usr/local/etc/rc.d sequence >>> execution is shown. No deactivating GELI swap too. >> >> Hi Andrey, >> Do you have a typescript demonstrating this? Adding rc_debug=3Dyes to= /etc/rc.conf would be super helpful, along with `boot -v`, to see whethe= r the issue is in userspace or rc(5). >> I=E2=80=99ll double check my amd64/i386 VMs too (if possible, redirec= t the output over serial to a typescript for analysis). >> Are you using vanilla FreeBSD, a fork, or a packaged variant (mfsbsd,= nanobsd, etc)? >> Thanks! >> -Ngie >> >=20 > Using rc_debug=3Dyes I see that it is the kernel problem, not rc proble= m. > Sometimes rc backward sequence executed even fully, sometimes only > partly, but in unpredictable moment inside rc sequence the kernel decid= e > to reboot quickly (or even deadly hang in rare cases). Always without > any "Syncing buffers..." leaving FS dirty. No zfs etc. just normal UFS,= > no EFI, no GPT. > I change GELI swap to normal one, but it does not help. The same > untouched config works for years, I see this bug for the first time in > FreeBSD. >=20 I forget to mention that typescript and dmesg does not survive after this reboot (or rare hang). --mMRgSVl1IJxkBxBQES7cVIqaTrCGMX6i3-- --NR6HbT8a8dF4wQaL5s2GnklSPaADeSVAE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJY2tU8AAoJEKUckv0MjfbK4jwIALm3DjpeU0wi31sY0rAj/kbv LfFrI/1QbBbXU16dzLth9NQqm1vygROL/VF9C6JbR+BpiFSRfD+C7PcCQJ1mONNN dzDyEGLsmwcSb0lNulBYwgBwP4rNmU5+JVhAINS1rPLPXypor3Xk2/VoG3dWB0SD rI6GSIvDFckqeMdLIGQSS2RIGTHMe4Bx7ltoKC4OWd6S8428x+VVbOA5/ULkilby C27xryMizKkHGwbdM4FUOPmACEkqMtejietCD4OPvpLJMKwVIxLCd+Ow135RxUft RSThmaY5pFJ+UruTnucBFqqP0HvU4Sudvp4E1spnipR/WSwP4vZKwmWKeGBoU8Y= =MDVS -----END PGP SIGNATURE----- --NR6HbT8a8dF4wQaL5s2GnklSPaADeSVAE-- From owner-freebsd-current@freebsd.org Tue Mar 28 21:46: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 3D5BCD23D93 for ; Tue, 28 Mar 2017 21:46:52 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 175F2B29 for ; Tue, 28 Mar 2017 21:46:52 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 168F2D23D92; Tue, 28 Mar 2017 21:46: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 162DDD23D91 for ; Tue, 28 Mar 2017 21:46:52 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 CDFC9B28; Tue, 28 Mar 2017 21:46:51 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-it0-x230.google.com with SMTP id y18so130911300itc.0; Tue, 28 Mar 2017 14:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=GNgWuSjNPyuiQ/h/0xI72rCffao/iwuSHXQK0xYj2ik=; b=aREVqzN0cTRALXd9RnuEfVrBxoOjrFU3mec1BoeSwmXxtwgwXWr0zsQYZqxiazEwTP yLsIzN81kciazOU2BIcNA0M/nSgfE8isuurNt9DXQmDMoRNrRuCrkgDTQh2ZgQ2k8uek xLkBlzNUl6Cu/iUljzVezFU/9MSKbIVTbyUnrDNHhxzqHk36ShrfCSJyVus0YvuR4asH uH5VmEbWXw8Ztwjud7sbXxZRtVxsM5g8t9PMwG7C6d+URXyyq7X+ynpWhundS5C4QHhU ccxrE2aSgpASge6t5sqcecLWohbDdV/rviEzyCHm4kU6ir7B5ervhtKGqtWaagN6fivF GSzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=GNgWuSjNPyuiQ/h/0xI72rCffao/iwuSHXQK0xYj2ik=; b=OjcIT6c3QhZF+Xa/mRKOrVySMNNbbpT8UuhXA3fjENdTAHIRsVomaT0e05bpiI/PIT HJZbKUeteL7Ek/B97HXzEJ6m2D3e+JNcLlld+0qQW81ADporWv0fzmd3rrckLrOlC6Tm RMgYJCMrrqfoOjo45H2KRhDhLVWvfiXOm5QXCXrzGYv9ES73cyci74A/yxkRF2aMFGAc PSwI4mIGzibD+GLZfmSovNIJTe/qyEs4ZIB+wAYyzjNs6SblqV6jcVkKw90WalayWPlT sqT0R3bEnTSGMgu77K3uTvN723lj3zSQ4X2ZTPo+8f41s73/UulPzt73uArj5sYVg5zg rcEw== X-Gm-Message-State: AFeK/H1b4CbpSSLxPovP+Xu9JtoJ7t15h2nADUS5BqLIFcWV/+riK0nmPuUny4J7JBaCrg== X-Received: by 10.36.175.28 with SMTP id t28mr9502431ite.56.1490737611023; Tue, 28 Mar 2017 14:46:51 -0700 (PDT) Received: from pinklady.local (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id l198sm2173615ita.10.2017.03.28.14.46.49 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 28 Mar 2017 14:46:50 -0700 (PDT) Subject: Re: shutdown -r doesn't execute rc.d sequence Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_12FA81ED-5F6B-45F9-BBF8-ABEEBA556CFE"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Ngie Cooper (yaneurabeya)" In-Reply-To: <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> Date: Tue, 28 Mar 2017 14:46:48 -0700 Cc: current@freebsd.org Message-Id: <8C24D1BA-1607-4C19-BA38-39256E82C7AF@gmail.com> References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> To: Andrey Chernov X-Mailer: Apple Mail (2.3124) 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, 28 Mar 2017 21:46:52 -0000 --Apple-Mail=_12FA81ED-5F6B-45F9-BBF8-ABEEBA556CFE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 28, 2017, at 14:27, Andrey Chernov wrote: =E2=80=A6 >> Using rc_debug=3Dyes I see that it is the kernel problem, not rc = problem. >> Sometimes rc backward sequence executed even fully, sometimes only >> partly, but in unpredictable moment inside rc sequence the kernel = decide >> to reboot quickly (or even deadly hang in rare cases). Always without >> any "Syncing buffers..." leaving FS dirty. No zfs etc. just normal = UFS, >> no EFI, no GPT. >> I change GELI swap to normal one, but it does not help. The same >> untouched config works for years, I see this bug for the first time = in >> FreeBSD. >>=20 >=20 > I forget to mention that typescript and dmesg does not survive after > this reboot (or rare hang). Good to note. The simple explanation to the problem might be r307755, depending on = when you last synced/built ^/head. I have a few more questions (if reverting that doesn't pan out): - What make/model of x86_64 are you running AMD (Bulldozer, etc) or = Intel (Conroe/Nehalem/Westmere/Sandybridge/Haswell)? - Is this a custom built machine? If so, what is your motherboard? If = not, who=E2=80=99s the vendor? - Is your system firmware up to date? - What does your make.conf/src.conf look like? - Are you running GENERIC or a custom kernel? If custom, could you = please include the config somewhere? - Are you loading any drivers in loader.conf? - Are you using Linux emulation? - Are you running any blob drivers, like nvidia? Thanks! -Ngie --Apple-Mail=_12FA81ED-5F6B-45F9-BBF8-ABEEBA556CFE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY2tnJAAoJEPWDqSZpMIYV4qUP/0DXqukrgyr0Kyt8jypwTVpK oGo1oEhYbeMe8P/ONOyRYjwhJHm+S365FiFrOioKt7ut8vbAGM0MJ6ePF5EvQW2J DBZC/qGlZNseQV5fzG5l/U430lPQayMhcfubbMyO3Ts98osYQzubd8nWHQd53A7D YpybAswKtdAJTZimSDBbIx2dvgjZc8iSbQcFarL9zZzXNgb5RWJZ84ExLHroerI1 ayAuhx4S3nTvPwybukqJ1IlTTn0Dn4iF6ZD94ackXNSHAOZS+PIJPO+qRBRGs5jp W2hv2elHCX3S/YDqn5oaq4QbhnKhWOhs7ig1F5DemwSY5jTKcKBxYLyvjUpmt37D Rjnb4aF+Gktl//Rpvj2/463k2CYqshzFOhUOmcMGGCcbasWE3+QJexibkkMcUkuh JzGfcCDGBIgu4UmJzl7gjEXbr6pxzh7RBhwR+PeURjhoANwBo98hh+yDFTI0xex9 NmyGAEh2NXOprRkwjEpefBZ9BfwUJQ+YlsUhR16eeal190eS97m62U5Zx7O1MGPn /l8g4cc3VvprIKZUl1Rwr6vwzzgZNquN6HWf4juyZs8qf3hqA/n40qvl9fmadnvw DKrtmpejqmjNqq9O3lUuAggku+PnybGwV9p8USrgj1aNfH2zd/LpTvq33Umv+OTv bbqKai6UfSh4RfpDc0To =qF1b -----END PGP SIGNATURE----- --Apple-Mail=_12FA81ED-5F6B-45F9-BBF8-ABEEBA556CFE-- From owner-freebsd-current@freebsd.org Wed Mar 29 00:29:08 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 38EBBD23CDC for ; Wed, 29 Mar 2017 00:29:08 +0000 (UTC) (envelope-from mailing-machine@vniz.net) 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 10D613054 for ; Wed, 29 Mar 2017 00:29:08 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mailman.ysv.freebsd.org (Postfix) id 1027BD23CDB; Wed, 29 Mar 2017 00:29:08 +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 0FC75D23CDA for ; Wed, 29 Mar 2017 00:29:08 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f67.google.com (mail-lf0-f67.google.com [209.85.215.67]) (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 8C9873053 for ; Wed, 29 Mar 2017 00:29:07 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f67.google.com with SMTP id r36so72813lfi.0 for ; Tue, 28 Mar 2017 17:29:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=zafLMMPb96CATvEKBF7/fi5dItzO8PXHTqIsIg2UvC4=; b=MHzUtGfsn2ihPlCz6W5JpM80RS2Jr1rEDm3LNOGr6jR8ljhoN1yy2bcLtMX+Imhgmr K6cKutGbTrCaHPaG9pjdffmk5p8azvpTwuiwYxtfD4SX2tEMkGpcBV6Dv/y2Ffgs/FIf DV1ar8EH/g4P/0QcmL/8d7uxpWZaVQeGyW70SI+BUKLsYuXr6Cy2bvMWzl6wl/DVvyFC YdyogjEFX52De+fVpp17VL5U9INfl4rQ4rd+8kD8/L4iu2tmJAK52EcmDg1ChlYLPwnz Qc0Sj1sT7uZfZKRuMLk3X2I2RC8DZOsnh2N1tPFm17eHUV3h7p6iTNABIs0MKMQ4kmB4 NrOQ== X-Gm-Message-State: AFeK/H0JIwjYNiMiH/+1xLQtYH2Qmxx7C/s4iOuxxSBmdwaQvbB9q2qbuTo+WKaI89tHGA== X-Received: by 10.46.32.152 with SMTP id g24mr2277915lji.78.1490747344959; Tue, 28 Mar 2017 17:29:04 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id o100sm961170lfi.18.2017.03.28.17.29.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 17:29:04 -0700 (PDT) Subject: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others To: "Ngie Cooper (yaneurabeya)" , bde@freebsd.org References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> <8C24D1BA-1607-4C19-BA38-39256E82C7AF@gmail.com> Cc: current@freebsd.org From: Andrey Chernov Message-ID: <51045bee-a626-efb3-4b1e-0c3d36abb1ab@freebsd.org> Date: Wed, 29 Mar 2017 03:29:03 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8C24D1BA-1607-4C19-BA38-39256E82C7AF@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wOuThEcT9VaRi1T6Ppl8TVX1ftGQrVqFD" 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, 29 Mar 2017 00:29:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wOuThEcT9VaRi1T6Ppl8TVX1ftGQrVqFD Content-Type: multipart/mixed; boundary="jElXp8Sq08LWbqELVGi9d1jikOXEU7LQf"; protected-headers="v1" From: Andrey Chernov To: "Ngie Cooper (yaneurabeya)" , bde@freebsd.org Cc: current@freebsd.org Message-ID: <51045bee-a626-efb3-4b1e-0c3d36abb1ab@freebsd.org> Subject: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> <8C24D1BA-1607-4C19-BA38-39256E82C7AF@gmail.com> In-Reply-To: <8C24D1BA-1607-4C19-BA38-39256E82C7AF@gmail.com> --jElXp8Sq08LWbqELVGi9d1jikOXEU7LQf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 29.03.2017 0:46, Ngie Cooper (yaneurabeya) wrote: >=20 >> On Mar 28, 2017, at 14:27, Andrey Chernov wrote: >=20 > =E2=80=A6 >=20 >>> Using rc_debug=3Dyes I see that it is the kernel problem, not rc prob= lem. >>> Sometimes rc backward sequence executed even fully, sometimes only >>> partly, but in unpredictable moment inside rc sequence the kernel dec= ide >>> to reboot quickly (or even deadly hang in rare cases). Always without= >>> any "Syncing buffers..." leaving FS dirty. No zfs etc. just normal UF= S, >>> no EFI, no GPT. >>> I change GELI swap to normal one, but it does not help. The same >>> untouched config works for years, I see this bug for the first time i= n >>> FreeBSD. >>> >> >> I forget to mention that typescript and dmesg does not survive after >> this reboot (or rare hang). >=20 > Good to note. > The simple explanation to the problem might be r307755, depending on wh= en you last synced/built ^/head. >=20 > I have a few more questions (if reverting that doesn't pan out): I just found the cause, it is new syscons bug (bde@ cc'ed). I never compile vt driver into kernel, i.e. I don't have this lines in the kernel config: device vt device vt_vga device vt_efifb When I add them, the bug described is gone. It seems syscons goes off to early, provoking reboot. I also find some lines of the kernel messages strange colored instead of white in the syscons only mode. Even in vt mode vidcontrol errors have invisible escapes prepended (although visible through /var/log/messages).= Moreover, I can't enter KDB via Ctrl-Alt-ESC in the syscons only mode anymore - nothing happens. In the vt mode I can, but can't exit via "c" properly, all chars typed after "c" produce beep unless I switch to another screen and back. All it means that syscons becomes very broken now by itself and even damages the kernel operations. --jElXp8Sq08LWbqELVGi9d1jikOXEU7LQf-- --wOuThEcT9VaRi1T6Ppl8TVX1ftGQrVqFD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJY2v/PAAoJEKUckv0MjfbKLwwIANT1C3D9OhNicbgStnQk7/bS ipIJu6il3o/qJRr6vuBbCtafZajgn9hUpVGHbxS83l/JdH8lK0FRtDNq7s50Dl8s y9XOsg7TUjBV3qFwqFK56BLWlghaLeu4jBh3t8pKhXug0o5TYzLhjpGlfgnvgSPR lLj5MI1M5lkfiOQMpdos9yQbMqGBJ/DWpLEi5Hw7o6WhTDfEh/EeXOPNaMcQFYIZ 1DYKZF2DH2vshYcksqKJlHN4cNAXqiYrk+a7I0c7uoTy2haTnASQ3+G5CSCim7Qx JM1k6MSWQEIe5BjUxsfQtib3wK8WaxPxLol0uypljHvhG89JeZYWYXUNZmeMEyw= =2v0O -----END PGP SIGNATURE----- --wOuThEcT9VaRi1T6Ppl8TVX1ftGQrVqFD-- From owner-freebsd-current@freebsd.org Wed Mar 29 03:37:28 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 60010D2328E for ; Wed, 29 Mar 2017 03:37:28 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::231]) (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 274A03D45 for ; Wed, 29 Mar 2017 03:37:28 +0000 (UTC) (envelope-from delphij@gmail.com) Received: by mail-ot0-x231.google.com with SMTP id t8so2395257otf.3 for ; Tue, 28 Mar 2017 20:37:28 -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=1EgnTLePRNAcYfrAIV46dPYq1M1mJkFfy090XUn4X+I=; b=gNgNw4aix7z6ElRaboFD7JTU8jgo28f8QYcA3SluH4xW5BaIKlKxtvcXFmZCKsTrC0 0TqyneBBT07QxPE7cxCkQxESMztV5bt6mPmS3WOP93dFlY65UEHjfzf2tnkHge7bg4vp djOnJDG7cjSyExiUxKQ6l5JlsoF2FtiVzP7R39llf3B6G0XvISZdz2q9nBZ4ywf11aTp XzLUyTcBuQe++DcErwC3xMDTnSIqdqZ1UHDK9OZBr3VfR/db7cL68+2xOZVguz60EZ7H 4amhaBE2ktKkK7//dVO2TuJhRIijVJ8YODIKBaVybpnapczURJGl1U6oowrMG6Lxk/5O 8yXA== 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=1EgnTLePRNAcYfrAIV46dPYq1M1mJkFfy090XUn4X+I=; b=HjzqDSyxIjvUyNIfVsPDWiv4W4gVhe0ugo7qeETJqDVnDZE2K1QWl5IQfuawIkTyIG LTS0PaL/Xh5FoovJ++CzEf8CBLg3ZB1uhD03x6qVGx921kLFdZMv3jAwLwOMHgfqDpIe icTiK7c4jN7HwoT8aw6yKahx28Uv/q9Ge1QrVJVh4Ydg+lIiWFM1Zz02XrnRPXuqN1gL HlA5bzLoGdqy+THa/jTTqsCI2KRcH7Gu5KckCu4of86NvESx6TGCkbnPmkmCY+0Cbi2X Op32eKb03p/f+I+r1LT5W/53jf4dNG93dNWBE0NdBXL+967wu2u78QOxub8mf0bKrXQL ITcA== X-Gm-Message-State: AFeK/H23NRisr5vqNNNFv4bMiFx/e2E4fAFSjrKVMj6uDObi6dB8irYkmCBS2nZGR++Fierd7lWQAu/ZEEGrdQ== X-Received: by 10.157.17.40 with SMTP id g37mr2640772ote.259.1490758647314; Tue, 28 Mar 2017 20:37:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.48.102 with HTTP; Tue, 28 Mar 2017 20:37:26 -0700 (PDT) In-Reply-To: <20170328163110.GD78849@gmail.com> References: <20170328163110.GD78849@gmail.com> From: Xin LI Date: Tue, 28 Mar 2017 20:37:26 -0700 Message-ID: Subject: Re: Build fails in libpcap with WITHOUT_INET6 To: Randy Westlund 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, 29 Mar 2017 03:37:28 -0000 Thanks for reporting. I have applied a fix as r316125. On Tue, Mar 28, 2017 at 9:31 AM, Randy Westlund wrote: > Building r315872 for the Tegra (arm/armv6) board with WITHOUT_INET6 set fails > in libpcap: > >> --- klm_prot_xdr.pico --- >> cc -target armv6-gnueabihf-freebsd12.0 --sysroot=/usr/home/randy/tegra/freebs >> d-obj/arm.armv6/usr/home/randy/tegra/freebsd/tmp -B/usr/home/randy/tegra/free >> bsd-obj/arm.armv6/usr/home/randy/tegra/freebsd/tmp/usr/bin -fpic -DPIC -g -O >> -pipe -DYP -I/usr/home/randy/tegra/freebsd-obj/arm.armv6/usr/home/randy/teg >> ra/freebsd/tmp/usr/include/rpcsvc -MD -MF.depend.klm_prot_xdr.pico -MTklm_pr >> ot_xdr.pico -std=gnu99 -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty- >> body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compar >> e -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum- >> conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switc >> h -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arg >> uments -c klm_prot_xdr.c -o klm_prot_xdr.pico >> --- all_subdir_lib/libpcap --- >> /usr/home/randy/tegra/freebsd/contrib/libpcap/gencode.c:695:9: error: no memb >> er named 'ai' in 'struct _compiler_state' >> cstate.ai = NULL; >> ~~~~~~ ^ >> --- all_subdir_lib/librpcsvc --- >> --- mount_xdr.pico --- >> cc -target armv6-gnueabihf-freebsd12.0 --sysroot=/usr/home/randy/tegra/freebs >> d-obj/arm.armv6/usr/home/randy/tegra/freebsd/tmp -B/usr/home/randy/tegra/free >> bsd-obj/arm.armv6/usr/home/randy/tegra/freebsd/tmp/usr/bin -fpic -DPIC -g -O >> -pipe -DYP -I/usr/home/randy/tegra/freebsd-obj/arm.armv6/usr/home/randy/teg >> ra/freebsd/tmp/usr/include/rpcsvc -MD -MF.depend.mount_xdr.pico -MTmount_xdr >> .pico -std=gnu99 -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body - >> Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno >> -unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conver >> sion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno >> -switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments >> -c mount_xdr.c -o mount_xdr.pico >> --- all_subdir_lib/libpcap --- >> /usr/home/randy/tegra/freebsd/contrib/libpcap/gencode.c:4916:13: error: use o >> f undeclared identifier 'cstate' >> bpf_error(cstate, "direction applied to 'gateway'"); >> ^ >> /usr/home/randy/tegra/freebsd/contrib/libpcap/gencode.c:4923:11: error: use o >> f undeclared identifier 'cstate' >> switch (cstate->linktype) { >> ^ >> /usr/home/randy/tegra/freebsd/contrib/libpcap/gencode.c:4961:17: error: use o >> f undeclared identifier 'cstate' >> b1 = gen_host(cstate, **alist++, 0xffffffff, proto, Q_OR, Q_H >> OST); >> ^ >> /usr/home/randy/tegra/freebsd/contrib/libpcap/gencode.c:4963:19: error: use o >> f undeclared identifier 'cstate' >> tmp = gen_host(cstate, **alist++, 0xffffffff, proto, >> Q_OR, >> ^ >> /usr/home/randy/tegra/freebsd/contrib/libpcap/gencode.c:4972:12: error: use o >> f undeclared identifier 'cstate' >> bpf_error(cstate, "illegal modifier of 'gateway'"); >> ^ >> 6 errors generated. >> *** [gencode.o] Error code 1 >> >> make[5]: stopped in /usr/home/randy/tegra/freebsd/lib/libpcap >> 1 error >> >> make[5]: stopped in /usr/home/randy/tegra/freebsd/lib/libpcap >> *** [all_subdir_lib/libpcap] Error code 2 > > From owner-freebsd-current@freebsd.org Wed Mar 29 06:24:08 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 9158BD237AD for ; Wed, 29 Mar 2017 06:24:08 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 6C23B67D2B for ; Wed, 29 Mar 2017 06:24:08 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 68AE8D237AC; Wed, 29 Mar 2017 06:24:08 +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 66A00D237AB for ; Wed, 29 Mar 2017 06:24:08 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 2967967D29; Wed, 29 Mar 2017 06:24:08 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pf0-x244.google.com with SMTP id r137so703674pfr.3; Tue, 28 Mar 2017 23:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jab9tnx4c7vtbnip6gmI5xFQVCrLx40wMJPwYkYkkgc=; b=LncnAiIMwj5Ml63ShNmk9L1nZbb8lbPOKf5+lvFNU9E641qs9jK+KakxfJiPG9s2yB bJcsRICZ1rwhrgGRpAnG9zNn5jbyhvrJyufum+T91t3cJOWBUvj/XNk18KfVAlF8xV90 OuAsLuQL5HkbOLuBk1hR+ut++wD1Zd8zEb2kT0CasotpG6N0Ke9Cjk4mYkX5diU4hxO4 GViaGemsrJXfmROZ6Ea3lXl9mgHjy7shcdCI/ro3Ub9fmcIjie2AOq8bjJkMZhRxz3F+ 5DA1xcPIaIBOWiscR8fypgYJNz3qO2upsW6u/9YoV6oJUG8FWDy49she87fQBgKBJ1Nw HDQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jab9tnx4c7vtbnip6gmI5xFQVCrLx40wMJPwYkYkkgc=; b=ggXWUu3wZU4o2Gtlc0pGXXgg/yG8WXo1lQPWkzSSdDoQNxIkLBnvrnmaly+8nund7c 45VWfY2rkBd7s+tRyzWa5JP9qQLrQdWyw/3Bb5bULhUr2u99BB0gWd9ko8El2IyLsNlU TxdH78xffSqbhLY89J3YOAc0eWZaQnJkQY+I0EG1ncsropcVpVKTSYEJ9z9B09sB5y6A dPk4ue6K/NrNonpJY3EZrhflZNjyDLGW0pdF2GmW7BcROOgxdrUpZQUag1yQFrNY1DqO FptX0McvpkWag9iUciwInY6cGRPkdwIC5trOKkl71a7aPOAukMJ62puJxvuHFhZaBFi5 eBJw== X-Gm-Message-State: AFeK/H0S741DE+Xvgtjqso5WwFbM8zcKec8bdenaBaxKDcoAPK3iqYxyPVcC2yvcNCsW2A== X-Received: by 10.98.139.78 with SMTP id j75mr34668593pfe.122.1490768647544; Tue, 28 Mar 2017 23:24:07 -0700 (PDT) Received: from ?IPv6:2607:fb90:8350:9a20:47c:5ab4:774e:ed5c? ([2607:fb90:8350:9a20:47c:5ab4:774e:ed5c]) by smtp.gmail.com with ESMTPSA id x15sm10935187pgc.16.2017.03.28.23.24.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 23:24:06 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others From: Ngie Cooper X-Mailer: iPhone Mail (14D27) In-Reply-To: <20170329150903.T1156@besplex.bde.org> Date: Tue, 28 Mar 2017 23:24:05 -0700 Cc: Andrey Chernov , bde@freebsd.org, current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <8078CD32-2DFB-4296-BD92-29627A1B4559@gmail.com> References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> <8C24D1BA-1607-4C19-BA38-39256E82C7AF@gmail.com> <51045bee-a626-efb3-4b1e-0c3d36abb1ab@freebsd.org> <20170329132927.U882@besplex.bde.org> <20170329150903.T1156@besplex.bde.org> To: Bruce Evans 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, 29 Mar 2017 06:24:08 -0000 > On Mar 28, 2017, at 21:40, Bruce Evans wrote: >=20 >> On Wed, 29 Mar 2017, Bruce Evans wrote: >>=20 >>> On Wed, 29 Mar 2017, Andrey Chernov wrote: >>> ... >>> Moreover, I can't enter KDB via Ctrl-Alt-ESC in the syscons only mode >>> anymore - nothing happens. In the vt mode I can, but can't exit via "c" >>> properly, all chars typed after "c" produce beep unless I switch to >>> another screen and back. >>> All it means that syscons becomes very broken now by itself and even >>> damages the kernel operations. >>=20 >> ... >> But I suspect it is a usb keyboard problem. Syscons now does almost >> correct locking for the screen, but not for the keyboard, and the usb >> keyboard is especially fragile, especially in ddb mode. Console input >> is not used in normal operation except for checking for characters on >> reboot. >>=20 >> Try using vt with syscons unconfigured. Syscons shouldn't be used when >> vt is selected, but unconfigure it to be sure. vt has different bugs >> using the usb keyboard. I haven't tested usb keyboards recently. >=20 > I tested usb keyboards again. They sometimes work, much the same as > a few months ago after some fixes: > - after booting with -d, they never work (give no input) at the ddb > prompt with either sc or vt. usb is not initialized then, and no usb > keyboard is attached to sc or vt > - after booting without loader with -a, sc rarely or never works (gives > no input) at the mountroot prompt > - after booting with loader with -a, vt works at the mountroot prompt. > I don't normally use loader but need to use it to change the configuratio= n. > This might be better than before. There used to be a screen refresh bug.= > - after booting with loader with -a, sc works at the mountroot prompt too.= > I previously debugged that vt worked better because it attaches the keybo= ard > before this point, while sc attaches it after. Booting with loader > apparently fixes the order. > - after any booting, sc works for user input (except sometimes after a > too-soft hard reset, the keyboard doesn't even work in the BIOS, and it > takes unplugging the keyboard to fix this) > - after almost any booting, vt doesn't work for user input (gives no input= ). > However, if ddb is entered using a serial console, vt does work! A few > months ago, normal input was fixed by configuring kbdmux (the default in > GENERIC). It is not fixed by unplugging the keyboard. kbdmux has a know= n > bug of not doing nested switching for the keyboard state. Perhaps this > "fixes" ddb mode. But I would have expected it to break ddb mode. > - I didn't test sc after entering ddb, except early when it doesn't work. >=20 > The above testing is with a usb keyboard, no ps/2 keyboard, and no kbdmux.= > Other combinations and dynamic switching move the bugs around, and a > serial console is needed to recover in cases where the bugs prevent any > keyboard input. I filed a bug a few years ago about USB keyboards and usability in ddb. If y= ou increase the timeout so the USB hubs have enough time to probe/attach, th= ey will work. I haven't taken the time to follow up on that and fix the issue, or at least= propose a bit more functional workaround. HTH, -Ngie= From owner-freebsd-current@freebsd.org Wed Mar 29 08:41: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 AB09CD228E2 for ; Wed, 29 Mar 2017 08:41:01 +0000 (UTC) (envelope-from yaneurabeya@gmail.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 8152F6552E for ; Wed, 29 Mar 2017 08:41:01 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 809EDD228E0; Wed, 29 Mar 2017 08:41:01 +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 80328D228DD for ; Wed, 29 Mar 2017 08:41:01 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (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 430346552B; Wed, 29 Mar 2017 08:41:01 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pg0-x243.google.com with SMTP id o123so1825157pga.1; Wed, 29 Mar 2017 01:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=2RaFU5SU8fH6ZWTUTUVkPFiWgf8msa8EJik8klwTdQA=; b=MtA4/Q+Fgv9Z6peO/a+PiGXgnxfOYsbYeW9xKlvJZHAL4h9NZ4nlzBRPHp5V77lHI7 fBxqdKYAB3CIaXhv4qnR26t+DxtRxK5D2Vi8Cuj5pRcs6A+8i7vLNeQ+UVvHaxzJZiKJ FMDJxVa5lM1P5xOkebMDVd8SbynWDyV9Slj9kbc73hZHHCnbsOYWmexEdHL5nCp8YdTK bDGMrEGJ/fhIdv0DZVWaQrDjwHpG8sSAaqdtNoI/NUuKrMSNA7eFR4BcahBNsyVcuE8B HSwq2LC51uE/5xzlvrjZ1qaDnvI+NJRy3Xx4xIcRUveLI4MBkDFINjnitjySW1C0LI8U WTyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=2RaFU5SU8fH6ZWTUTUVkPFiWgf8msa8EJik8klwTdQA=; b=jKI/GFlGGX1XUpLhEgTZG5ljuyj4ngMkCS+J8aBNCQzP8gxMRoIHP247Mx6qQFSIq1 cFWu7aSuXyjvFjLTO21Pb6FscpuJBh2mB1/HHOhRz2kdj9UImlIx5p9ACVRnycOtLFNN FMOQN8sukk1EyNV1bHXi6Zr/ExO6lTs01qX1B9zNOBY+NW1tDZd3mH5kGuDEJwQ5+llx qHeknV/tGJlcWuH4S5P2MrU/nhx4XhdPlaR38W7FoPvK9d0PdR9PpT1GL1ThMaIRK68/ D+XVOz3QY/iU50YfoSOXVAuzrvpKkUKPnVwrY6Un2StJVx+Qu6uTKn1gyGGhcDP3fHrN 4SFw== X-Gm-Message-State: AFeK/H1hz0O/3oqQhoe3Y/4aGAFxYAvwCOv7kGVhrnWD/1Jouivwf8Tr10s+huD2Vlp2vQ== X-Received: by 10.84.216.17 with SMTP id m17mr41067538pli.158.1490776860870; Wed, 29 Mar 2017 01:41:00 -0700 (PDT) Received: from pinklady.local (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id 73sm12042627pfj.31.2017.03.29.01.40.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 29 Mar 2017 01:41:00 -0700 (PDT) Subject: Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_22CFF767-91DA-471A-9F92-DC70CBD6B99B"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Ngie Cooper (yaneurabeya)" In-Reply-To: <20170329190919.C26218@besplex.bde.org> Date: Wed, 29 Mar 2017 01:40:58 -0700 Cc: Andrey Chernov , bde@freebsd.org, current@freebsd.org Message-Id: <6E572F7D-8DA3-4801-B370-B7B63C664760@gmail.com> References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> <8C24D1BA-1607-4C19-BA38-39256E82C7AF@gmail.com> <51045bee-a626-efb3-4b1e-0c3d36abb1ab@freebsd.org> <20170329132927.U882@besplex.bde.org> <20170329150903.T1156@besplex.bde.org> <8078CD32-2DFB-4296-BD92-29627A1B4559@gmail.com> <20170329190919.C26218@besplex.bde.org> To: Bruce Evans X-Mailer: Apple Mail (2.3124) 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, 29 Mar 2017 08:41:01 -0000 --Apple-Mail=_22CFF767-91DA-471A-9F92-DC70CBD6B99B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 29, 2017, at 01:26, Bruce Evans wrote: >=20 > On Tue, 28 Mar 2017, Ngie Cooper wrote: >=20 >>> On Mar 28, 2017, at 21:40, Bruce Evans wrote: >>>=20 >>>> On Wed, 29 Mar 2017, Bruce Evans wrote: >>>>=20 >>>>> On Wed, 29 Mar 2017, Andrey Chernov wrote: >>>>> ... >>>>> Moreover, I can't enter KDB via Ctrl-Alt-ESC in the syscons only = mode >>>>> anymore - nothing happens. In the vt mode I can, but can't exit = via "c" >>>>> properly, all chars typed after "c" produce beep unless I switch = to >>>>> another screen and back. >>>>> All it means that syscons becomes very broken now by itself and = even >>>>> damages the kernel operations. >=20 > I found a bug in screen resizing (the console context doesn't get = resized). > This doesn't cause any keyboard problems. >=20 >>>> ... >>>> But I suspect it is a usb keyboard problem. Syscons now does = almost >>>> correct locking for the screen, but not for the keyboard, and the = usb >>>> keyboard is especially fragile, especially in ddb mode. Console = input >>>> is not used in normal operation except for checking for characters = on >>>> reboot. >>>>=20 >>>> Try using vt with syscons unconfigured. Syscons shouldn't be used = when >>>> vt is selected, but unconfigure it to be sure. vt has different = bugs >>>> using the usb keyboard. I haven't tested usb keyboards recently. >>>=20 >>> ... >>> I tested usb keyboards again. They sometimes work, much the same as >>> a few months ago after some fixes: >>> ... >>>=20 >>> The above testing is with a usb keyboard, no ps/2 keyboard, and no = kbdmux. >>> Other combinations and dynamic switching move the bugs around, and a >>> serial console is needed to recover in cases where the bugs prevent = any >>> keyboard input. >>=20 >> I filed a bug a few years ago about USB keyboards and usability in = ddb. If you increase the timeout so the USB hubs have enough time to = probe/attach, they will work. >=20 > Is that for user mode or earlier? ukb has some other fixes for ddb = now, but > of course it can't work before it finds the device. >=20 > I recently found that usb boot drives sometimes don't have enough time = to > probe/attach before they are used in mountroot, and the mount -a = prompt > does locking that doesn't allow them enough time if they are not ready > before it. The usb maintainers already know about this. Ah, I misremembered my filing the bug =E2=80=94 someone else did it: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D133989 (it happens = at mountroot, for example, because of probing order being what it is). -Ngie --Apple-Mail=_22CFF767-91DA-471A-9F92-DC70CBD6B99B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY23MbAAoJEPWDqSZpMIYVH5sP/0RfNzM6K+QYb60C94VOT9YF Yeo9hi5K5+G4gY2F2/CMhXQSgUby7xKYW+qXtmsJ9iJ+2mCQjQ5f5lMJwSuVqhXm EH2KZ25B6dd1z2QyB2DClDqkMOS4M0daWjEyxjfSy4K43Y75M6ODw3JhlGKH5kUF vo+iEQpOQXwFfYRU8SZJ7zvETPVf64618Ik/eI+7Hz2cIIzh6/y6sYFtxpvjJfvQ I7gzdxaxFHNsa48rEzjznQnC+EYYuSSwwmUVlbJ+NMrMJZ8f0TX29mUKmH90iQDl InNrCE4RGgUCdJANTzpIAeh+zqDpRkI57SdjHLD/JtQHo06KCAYpWXjxYOyp6A29 xM8i56mx1N9sYzQHviCcizwQB/nSJlXWlFZaKQJmKAnZAKPQhiyXeE6ylTg94qjH kC2MwIMb6x+gJfMIte73iHf+Gl8jyOqE/TOsat5yyhe2DkvHxaZ489vFtvXwLmCu S6NjsuqAIqKJXHzJI4wbXXX/TsMt7S2wLf664uzJuWXisWwgii1KGs6D3U2c68pO OBv8p2cmI2vpVnZYb2TTuZ6/PkSiIDNuzDkZKyRd04FTUX6pzhKqtTBLQYHYLpwx 1l3rpgSXjZ+kEqrQNx3L2toel7n7zaadzhuCCimdmmRpIcJb2CoY70Gu0zoT000p BklvdizL1V/w79XvArkr =9CoP -----END PGP SIGNATURE----- --Apple-Mail=_22CFF767-91DA-471A-9F92-DC70CBD6B99B-- From owner-freebsd-current@freebsd.org Wed Mar 29 03:52: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 9B11FD237D1 for ; Wed, 29 Mar 2017 03:52:38 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 845102ABF for ; Wed, 29 Mar 2017 03:52:38 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: by mailman.ysv.freebsd.org (Postfix) id 83AEAD237D0; Wed, 29 Mar 2017 03:52:38 +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 835BED237CF for ; Wed, 29 Mar 2017 03:52:38 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id 14CBD2ABD; Wed, 29 Mar 2017 03:52:37 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id 9D4383C504C; Wed, 29 Mar 2017 14:29:55 +1100 (AEDT) Date: Wed, 29 Mar 2017 14:29:55 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Andrey Chernov cc: "Ngie Cooper (yaneurabeya)" , bde@freebsd.org, current@freebsd.org Subject: Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others In-Reply-To: <51045bee-a626-efb3-4b1e-0c3d36abb1ab@freebsd.org> Message-ID: <20170329132927.U882@besplex.bde.org> References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> <8C24D1BA-1607-4C19-BA38-39256E82C7AF@gmail.com> <51045bee-a626-efb3-4b1e-0c3d36abb1ab@freebsd.org> MIME-Version: 1.0 X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=VbSHBBh9 c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=nlC_4_pT8q9DhB4Ho9EA:9 a=6I5d2MoRAAAA:8 a=afwJpxqgKJD2fXreN-sA:9 a=45ClL6m2LaAA:10 a=IjZwj45LgO3ly-622nXo:22 X-Mailman-Approved-At: Wed, 29 Mar 2017 11:00:08 +0000 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE 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, 29 Mar 2017 03:52:38 -0000 On Wed, 29 Mar 2017, Andrey Chernov wrote: > On 29.03.2017 0:46, Ngie Cooper (yaneurabeya) wrote: >> >>> On Mar 28, 2017, at 14:27, Andrey Chernov wrote: >> >> =E2=80=A6 >> >>>> Using rc_debug=3Dyes I see that it is the kernel problem, not rc probl= em. >>>> Sometimes rc backward sequence executed even fully, sometimes only >>>> partly, but in unpredictable moment inside rc sequence the kernel deci= de >>>> to reboot quickly (or even deadly hang in rare cases). Always without >>>> any "Syncing buffers..." leaving FS dirty. No zfs etc. just normal UFS= , >>>> no EFI, no GPT. >>>> I change GELI swap to normal one, but it does not help. The same >>>> untouched config works for years, I see this bug for the first time in >>>> FreeBSD. >>> >>> I forget to mention that typescript and dmesg does not survive after >>> this reboot (or rare hang). >> >> Good to note. >> The simple explanation to the problem might be r307755, depending on whe= n you last synced/built ^/head. >> >> I have a few more questions (if reverting that doesn't pan out): > > I just found the cause, it is new syscons bug (bde@ cc'ed). I never > compile vt driver into kernel, i.e. I don't have this lines in the > kernel config: > > device=09vt > device=09vt_vga > device=09vt_efifb > > When I add them, the bug described is gone. It seems syscons goes off to > early, provoking reboot. Bah, I only have vt and vt_vga to check that I didn't break them. Unfortunately, syscons still works right when I remove these lines. > I also find some lines of the kernel messages strange colored instead of > white in the syscons only mode. Even in vt mode vidcontrol errors have > invisible escapes prepended (although visible through /var/log/messages). Kernel messages in syscons are now supposed to be colorized by CPU. The boot messages should show all the colors. Shutdown and ddb are normally done by a single random CPU, so are shown in a single random color. The colors are bright (light) 8-15 foreground, except bright black (8) is not so bright. Configure with a non-default KERNEL_SC_CONS_ATTR (maybe yellow on black instead of lightwhite on black) to turn of the colorization= =2E I haven't tested this recently. There is also a sysctl for setting all the colors. > Moreover, I can't enter KDB via Ctrl-Alt-ESC in the syscons only mode > anymore - nothing happens. In the vt mode I can, but can't exit via "c" > properly, all chars typed after "c" produce beep unless I switch to > another screen and back. > > All it means that syscons becomes very broken now by itself and even > damages the kernel operations. Try backing out r315984 only. This is supposed to fix parsing of output. It switches to a state indexed by the CPU for every character, and switches back. Screen switching does a different switch and would fix any bug in switching back. But I suspect it is a usb keyboard problem. Syscons now does almost correct locking for the screen, but not for the keyboard, and the usb keyboard is especially fragile, especially in ddb mode. Console input is not used in normal operation except for checking for characters on reboot. Try using vt with syscons unconfigured. Syscons shouldn't be used when vt is selected, but unconfigure it to be sure. vt has different bugs using the usb keyboard. I haven't tested usb keyboards recently. Bruce From owner-freebsd-current@freebsd.org Wed Mar 29 04:40:18 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 EAC59D23204 for ; Wed, 29 Mar 2017 04:40:18 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id D4DDB67AC0 for ; Wed, 29 Mar 2017 04:40:18 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: by mailman.ysv.freebsd.org (Postfix) id D0907D23203; Wed, 29 Mar 2017 04:40:18 +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 D01ACD23202 for ; Wed, 29 Mar 2017 04:40:18 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id 64D7D67ABE; Wed, 29 Mar 2017 04:40:18 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id 6F9BC3C5758; Wed, 29 Mar 2017 15:40:15 +1100 (AEDT) Date: Wed, 29 Mar 2017 15:40:14 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bruce Evans cc: Andrey Chernov , "Ngie Cooper (yaneurabeya)" , bde@freebsd.org, current@freebsd.org Subject: Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others In-Reply-To: <20170329132927.U882@besplex.bde.org> Message-ID: <20170329150903.T1156@besplex.bde.org> References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> <8C24D1BA-1607-4C19-BA38-39256E82C7AF@gmail.com> <51045bee-a626-efb3-4b1e-0c3d36abb1ab@freebsd.org> <20170329132927.U882@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=VbSHBBh9 c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=ffRTqb9OHUFA3UoZTXcA:9 a=CjuIK1q_8ugA:10 X-Mailman-Approved-At: Wed, 29 Mar 2017 11:39:38 +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: Wed, 29 Mar 2017 04:40:19 -0000 On Wed, 29 Mar 2017, Bruce Evans wrote: > On Wed, 29 Mar 2017, Andrey Chernov wrote: > ... >> Moreover, I can't enter KDB via Ctrl-Alt-ESC in the syscons only mode >> anymore - nothing happens. In the vt mode I can, but can't exit via "c" >> properly, all chars typed after "c" produce beep unless I switch to >> another screen and back. >> >> All it means that syscons becomes very broken now by itself and even >> damages the kernel operations. > > ... > But I suspect it is a usb keyboard problem. Syscons now does almost > correct locking for the screen, but not for the keyboard, and the usb > keyboard is especially fragile, especially in ddb mode. Console input > is not used in normal operation except for checking for characters on > reboot. > > Try using vt with syscons unconfigured. Syscons shouldn't be used when > vt is selected, but unconfigure it to be sure. vt has different bugs > using the usb keyboard. I haven't tested usb keyboards recently. I tested usb keyboards again. They sometimes work, much the same as a few months ago after some fixes: - after booting with -d, they never work (give no input) at the ddb prompt with either sc or vt. usb is not initialized then, and no usb keyboard is attached to sc or vt - after booting without loader with -a, sc rarely or never works (gives no input) at the mountroot prompt - after booting with loader with -a, vt works at the mountroot prompt. I don't normally use loader but need to use it to change the configuration. This might be better than before. There used to be a screen refresh bug. - after booting with loader with -a, sc works at the mountroot prompt too. I previously debugged that vt worked better because it attaches the keyboard before this point, while sc attaches it after. Booting with loader apparently fixes the order. - after any booting, sc works for user input (except sometimes after a too-soft hard reset, the keyboard doesn't even work in the BIOS, and it takes unplugging the keyboard to fix this) - after almost any booting, vt doesn't work for user input (gives no input). However, if ddb is entered using a serial console, vt does work! A few months ago, normal input was fixed by configuring kbdmux (the default in GENERIC). It is not fixed by unplugging the keyboard. kbdmux has a known bug of not doing nested switching for the keyboard state. Perhaps this "fixes" ddb mode. But I would have expected it to break ddb mode. - I didn't test sc after entering ddb, except early when it doesn't work. The above testing is with a usb keyboard, no ps/2 keyboard, and no kbdmux. Other combinations and dynamic switching move the bugs around, and a serial console is needed to recover in cases where the bugs prevent any keyboard input. Bruce From owner-freebsd-current@freebsd.org Wed Mar 29 08:26: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 A0579D2251D for ; Wed, 29 Mar 2017 08:26:27 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 893E76BBB6 for ; Wed, 29 Mar 2017 08:26:27 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: by mailman.ysv.freebsd.org (Postfix) id 85A77D2251C; Wed, 29 Mar 2017 08:26:27 +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 8542FD2251B for ; Wed, 29 Mar 2017 08:26:27 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail108.syd.optusnet.com.au (mail108.syd.optusnet.com.au [211.29.132.59]) by mx1.freebsd.org (Postfix) with ESMTP id 43C176BBB5; Wed, 29 Mar 2017 08:26:26 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail108.syd.optusnet.com.au (Postfix) with ESMTPS id 6D0191A4244; Wed, 29 Mar 2017 19:26:24 +1100 (AEDT) Date: Wed, 29 Mar 2017 19:26:23 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Ngie Cooper cc: Bruce Evans , Andrey Chernov , bde@freebsd.org, current@freebsd.org Subject: Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others In-Reply-To: <8078CD32-2DFB-4296-BD92-29627A1B4559@gmail.com> Message-ID: <20170329190919.C26218@besplex.bde.org> References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> <8C24D1BA-1607-4C19-BA38-39256E82C7AF@gmail.com> <51045bee-a626-efb3-4b1e-0c3d36abb1ab@freebsd.org> <20170329132927.U882@besplex.bde.org> <20170329150903.T1156@besplex.bde.org> <8078CD32-2DFB-4296-BD92-29627A1B4559@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=VbSHBBh9 c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=djocrBDfS-jKbYuDqNYA:9 a=CjuIK1q_8ugA:10 a=Oa0T6EYmKFNB-xRHvYM1:22 X-Mailman-Approved-At: Wed, 29 Mar 2017 11:40:04 +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: Wed, 29 Mar 2017 08:26:27 -0000 On Tue, 28 Mar 2017, Ngie Cooper wrote: >> On Mar 28, 2017, at 21:40, Bruce Evans wrote: >> >>> On Wed, 29 Mar 2017, Bruce Evans wrote: >>> >>>> On Wed, 29 Mar 2017, Andrey Chernov wrote: >>>> ... >>>> Moreover, I can't enter KDB via Ctrl-Alt-ESC in the syscons only mode >>>> anymore - nothing happens. In the vt mode I can, but can't exit via "c" >>>> properly, all chars typed after "c" produce beep unless I switch to >>>> another screen and back. >>>> All it means that syscons becomes very broken now by itself and even >>>> damages the kernel operations. I found a bug in screen resizing (the console context doesn't get resized). This doesn't cause any keyboard problems. >>> ... >>> But I suspect it is a usb keyboard problem. Syscons now does almost >>> correct locking for the screen, but not for the keyboard, and the usb >>> keyboard is especially fragile, especially in ddb mode. Console input >>> is not used in normal operation except for checking for characters on >>> reboot. >>> >>> Try using vt with syscons unconfigured. Syscons shouldn't be used when >>> vt is selected, but unconfigure it to be sure. vt has different bugs >>> using the usb keyboard. I haven't tested usb keyboards recently. >> >> ... >> I tested usb keyboards again. They sometimes work, much the same as >> a few months ago after some fixes: >> ... >> >> The above testing is with a usb keyboard, no ps/2 keyboard, and no kbdmux. >> Other combinations and dynamic switching move the bugs around, and a >> serial console is needed to recover in cases where the bugs prevent any >> keyboard input. > > I filed a bug a few years ago about USB keyboards and usability in ddb. If you increase the timeout so the USB hubs have enough time to probe/attach, they will work. Is that for user mode or earlier? ukb has some other fixes for ddb now, but of course it can't work before it finds the device. I recently found that usb boot drives sometimes don't have enough time to probe/attach before they are used in mountroot, and the mount -a prompt does locking that doesn't allow them enough time if they are not ready before it. The usb maintainers already know about this. > I haven't taken the time to follow up on that and fix the issue, or at least propose a bit more functional workaround. Bruce From owner-freebsd-current@freebsd.org Wed Mar 29 15:53:24 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 0C532D20E16; Wed, 29 Mar 2017 15:53:24 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 C16A567685; Wed, 29 Mar 2017 15:53:23 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 649735A9F15; Wed, 29 Mar 2017 15:53:16 +0000 (UTC) Date: Wed, 29 Mar 2017 15:53:16 +0000 From: Brooks Davis To: Mark Millard Cc: Dimitry Andric , FreeBSD Ports , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) Message-ID: <20170329155316.GK59667@spindle.one-eyed-alien.net> References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <45E32F4F-A238-47AA-8E1E-7AD4D9E857D9@dsl-only.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="m1UC1K4AOz1Ywdkx" Content-Disposition: inline In-Reply-To: <45E32F4F-A238-47AA-8E1E-7AD4D9E857D9@dsl-only.net> 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: Wed, 29 Mar 2017 15:53:24 -0000 --m1UC1K4AOz1Ywdkx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 27, 2017 at 03:25:04AM -0700, Mark Millard wrote: > On 2017-Mar-27, at 2:41 AM, Dimitry Andric wrote: >=20 > > On 26 Mar 2017, at 23:36, Mark Millard wrote: > >>=20 > >> I upgraded from llvm40 r4 to final. An interesting result was > >> its creation of a backup package for llvm40-4.0.0.r4: > >>=20 > >> about 13 cpu-core-hours running pkg create > >>=20 > >> (Remember: I've been building with WITH_DEBUG=3D ) Its > >> single-threaded status stands out via elapsed time > >> approximately matching. > >>=20 > >> I'll note that it was somewhat under 6 elapsed hours for > >> staging to have been populated (-j4 with 4 cores present > >> helps for this part). > >>=20 > >> (Of course these elapsed-time figures are rather system > >> dependent, although the ratio might be more stable.) > >>=20 > >>=20 > >>=20 > >> Also interesting was: > >>=20 > >> Installed packages to be REMOVED: > >> llvm40-4.0.0.r4 > >>=20 > >> Number of packages to be removed: 1 > >>=20 > >> The operation will free 49 GiB. > >=20 > > Yes, this is big. But there is no real need to build the llvm ports > > with debug information, unless you want to hack on llvm itself. And > > in that case, you are better served by a Subversion checkout or Git > > clone from upstream instead. > >=20 > > -Dimitry >=20 > FYI: >=20 > Historically unless something extreme like this ends up > involved I build everything using WITH_DEBUG=3D or explicit > -g's in order to have better information on any failure. >=20 > This is extreme enough that next time I synchronize > /usr/ports and it has a devel/llvm40 update I'll > likely rebuild devel/llvm40 without using WITH_DEBUG=3D . > I'm more concerned with the time it takes than with > the file system space involved. In the case of LLVM, enabling debug builds does a LOT more than adding symbols. It's much more like enabling WITNESS and INVARIANTS in your kernel, except that the performance of the resulting binary is much worse than a WITNESS kernel (more like 10x slowdown). As Dimitry points out, these builds are of questionable value in ports so garbage collecting the knob might be the sensable thing to do. -- Brooks --m1UC1K4AOz1Ywdkx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJY29hrAAoJEKzQXbSebgfA6cgH/1FWA1dO2yctl/WJzfe4cF2E 1QRc3LUXX/DR9NktYS1GyLUJvgSncqNBMTBIwgeto5JxESn5A9fwry9L3koVCNFC GyjK+y1mNakVnZsFpe42QxKg53xv2Mi2ummNuatebC23a6ari++l/ioPIpR0tI+h nXRlH+PQYmXRnZvFoB2knVOXp5U++UkeoqJ0RnT17hHnwvLVwMlRdFyC+IoAuVZb xHb7bwm7yk0zo66onLfMcuj7MlIOgncg5l6KB42MTh6uIKY23LNl3qYernRbodnj 9t6eKI1mnD3nA10G8b0MBoUoDPb9/MkubIm4jRC1ag0k7Dj7YdHE8Wh/pLOyfxY= =MI2X -----END PGP SIGNATURE----- --m1UC1K4AOz1Ywdkx-- From owner-freebsd-current@freebsd.org Wed Mar 29 17:25: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 6F359D231E0; Wed, 29 Mar 2017 17:25:59 +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 375C267E56; Wed, 29 Mar 2017 17:25:59 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::416b:f3a0:99b:694b] (unknown [IPv6:2001:470:7a58:0:416b:f3a0:99b:694b]) (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 D12B315014; Wed, 29 Mar 2017 19:25:47 +0200 (CEST) From: Dimitry Andric Message-Id: <779FB7DC-C041-43CD-ADF2-1F5D791832A6@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_EE11392F-FEC5-4555-BA6C-B9AB94FCAF35"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) Date: Wed, 29 Mar 2017 19:25:43 +0200 In-Reply-To: <20170329155316.GK59667@spindle.one-eyed-alien.net> Cc: Mark Millard , FreeBSD Ports , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current To: Brooks Davis References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <45E32F4F-A238-47AA-8E1E-7AD4D9E857D9@dsl-only.net> <20170329155316.GK59667@spindle.one-eyed-alien.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: Wed, 29 Mar 2017 17:25:59 -0000 --Apple-Mail=_EE11392F-FEC5-4555-BA6C-B9AB94FCAF35 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 29 Mar 2017, at 17:53, Brooks Davis wrote: > > On Mon, Mar 27, 2017 at 03:25:04AM -0700, Mark Millard wrote: ... >> This is extreme enough that next time I synchronize >> /usr/ports and it has a devel/llvm40 update I'll >> likely rebuild devel/llvm40 without using WITH_DEBUG= . >> I'm more concerned with the time it takes than with >> the file system space involved. > > In the case of LLVM, enabling debug builds does a LOT more than adding > symbols. It's much more like enabling WITNESS and INVARIANTS in your > kernel, except that the performance of the resulting binary is much > worse than a WITNESS kernel (more like 10x slowdown). > > As Dimitry points out, these builds are of questionable value in ports > so garbage collecting the knob might be the sensable thing to do. I suggest that for the LLVM ports, the DEBUG option should set the RelWithDebInfo build type for CMake. That will give you binaries which can produce good backtraces, and a fair chance at debugging, in a pinch. -Dimitry --Apple-Mail=_EE11392F-FEC5-4555-BA6C-B9AB94FCAF35 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 iEYEARECAAYFAljb7hsACgkQsF6jCi4glqNTCACghnz91bTIcsVeRILZ8G99/Qr1 QIEAn3G5vr5EwRwJ5DqfnQmJC130xw+Y =Nno0 -----END PGP SIGNATURE----- --Apple-Mail=_EE11392F-FEC5-4555-BA6C-B9AB94FCAF35-- From owner-freebsd-current@freebsd.org Wed Mar 29 22:33: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 7FA12D2344A for ; Wed, 29 Mar 2017 22:33:51 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 57B87193F for ; Wed, 29 Mar 2017 22:33:51 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mailman.ysv.freebsd.org (Postfix) id 5714AD23448; Wed, 29 Mar 2017 22:33:51 +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 56BD0D23447 for ; Wed, 29 Mar 2017 22:33:51 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f67.google.com (mail-lf0-f67.google.com [209.85.215.67]) (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 0D8481938 for ; Wed, 29 Mar 2017 22:33:50 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f67.google.com with SMTP id v2so2982427lfi.2 for ; Wed, 29 Mar 2017 15:33:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=vJPdcVYRNBBPT16yAdwI/7kxhg7i4b8rgM/QYnVkan4=; b=Z0EssKm5PkA0eA+yMM6d9ssMA9Ie2tQ3zrvRMbdmQU6bcZGpepdA0e/7bZwbxhQVIu snhAHcC4nOhqZtUiCH16aasmXxjUbydVsXgDKeC3YC11kI7E8bTwkvNzALdp6Avvhq+N LW6Hnf9SaXUP0B/QP5vUDEAYl6k3qLKNpWFy54BznUnkYRpl2znOJE+Q5eAVrtEfJu/W ekMQ6r5DkqWGXDCK9Fa0C4CC/oZw6xKNXxDQuUprZHXtGdmmZlHAX+ejiyeSHr7lUBiL sApe7tJWkyVwOk9xub2ZY3459SN0N8KIotr+BcT+9I00XDE5YnrTD9Jl7vgmhf/sFDvD 3OQw== X-Gm-Message-State: AFeK/H1tc4e0ksqun0snLI5EIWGmWb7w49c8R4oN7sjNGOxGNpvG0weU3Toq4OKq9s+5/A== X-Received: by 10.46.22.92 with SMTP id 28mr974373ljw.55.1490826822550; Wed, 29 Mar 2017 15:33:42 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id v26sm41387lja.31.2017.03.29.15.33.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Mar 2017 15:33:42 -0700 (PDT) Subject: Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others To: Bruce Evans References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> <8C24D1BA-1607-4C19-BA38-39256E82C7AF@gmail.com> <51045bee-a626-efb3-4b1e-0c3d36abb1ab@freebsd.org> <20170329132927.U882@besplex.bde.org> Cc: "Ngie Cooper (yaneurabeya)" , bde@freebsd.org, current@freebsd.org From: Andrey Chernov Message-ID: Date: Thu, 30 Mar 2017 01:33:38 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170329132927.U882@besplex.bde.org> Content-Type: text/plain; charset=us-ascii 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: Wed, 29 Mar 2017 22:33:51 -0000 On 29.03.2017 6:29, Bruce Evans wrote: >>>>> Using rc_debug=yes I see that it is the kernel problem, not rc >>>>> problem. >>>>> Sometimes rc backward sequence executed even fully, sometimes only >>>>> partly, but in unpredictable moment inside rc sequence the kernel >>>>> decide >>>>> to reboot quickly (or even deadly hang in rare cases). Always without >>>>> any "Syncing buffers..." leaving FS dirty. No zfs etc. just normal >>>>> UFS, >>>>> no EFI, no GPT. >>>>> I change GELI swap to normal one, but it does not help. The same >>>>> untouched config works for years, I see this bug for the first time in >>>>> FreeBSD. >>>> >>>> I forget to mention that typescript and dmesg does not survive after >>>> this reboot (or rare hang). >>> >>> Good to note. >>> The simple explanation to the problem might be r307755, depending on >>> when you last synced/built ^/head. >>> >>> I have a few more questions (if reverting that doesn't pan out): >> >> I just found the cause, it is new syscons bug (bde@ cc'ed). I never >> compile vt driver into kernel, i.e. I don't have this lines in the >> kernel config: >> >> device vt >> device vt_vga >> device vt_efifb >> >> When I add them, the bug described is gone. It seems syscons goes off to >> early, provoking reboot. > > Bah, I only have vt and vt_vga to check that I didn't break them. > > Unfortunately, syscons still works right when I remove these lines. Maybe two will be enough too, I don't check. I just don't need _any_ of vt lines. What is matter it is that syscons only mode (without any vt) was recently broken, causing shutdown problems and file system damage each time. Syscons only mode works for years until you break it recently. > Kernel messages in syscons are now supposed to be colorized by CPU. The It looks really crazy on 8-core CPU and should not be default. And I don't see colors in vt mode (which should be parallel at that point, at least), but what about invisible escapes on vidcontrol errors (f.e. invalid argument) in vt mode? >> Moreover, I can't enter KDB via Ctrl-Alt-ESC in the syscons only mode >> anymore - nothing happens. In the vt mode I can, but can't exit via "c" >> properly, all chars typed after "c" produce beep unless I switch to >> another screen and back. > > Try backing out r315984 only. This is supposed to fix parsing of output. I'll try. thanx. But most dangerous new syscons bug is the first one, damaging file system on each reboot. I try to go to KDB to debug it, but seeing that I can't even enter KDB I understand that all that bugs, including nasty one, are introduced by your syscons changes, it was a hint to add completely unneeded and unused vt to my kernel config file. vt is real downgrade. Its default console font is plain ugly, it is impossible to work with it. I can't find proper TERM for it to make function keys and pseudographics works in ncurses apps (not with xterm, a little better with xterm-sco), lynx can't display all things properly, etc. All we need is KMS integration alone and not vt. > But I suspect it is a usb keyboard problem. No, I have PS/2 keyboard. From owner-freebsd-current@freebsd.org Wed Mar 29 22:39: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 8CE0CD236C1 for ; Wed, 29 Mar 2017 22:39:20 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 56E761D77 for ; Wed, 29 Mar 2017 22:39:19 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id v2TMe0Co087776 for ; Wed, 29 Mar 2017 15:40:06 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: "FreeBSD CURRENT" From: "Chris H" Subject: Was pf(4) removed from periodic daily? Date: Wed, 29 Mar 2017 15:40:06 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <3248c64096dae788afc7fde72082b1d1@ultimatedns.net> Content-Transfer-Encoding: 8bit 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, 29 Mar 2017 22:39:20 -0000 I've depended upon pf for many years, but somewhere between updating my servers from 9 to 11, and 12. I seem to have lost getting the daily statistics from pf. Does anyone know what changed, and what I need to do to get those reports back? Thanks! --Chris From owner-freebsd-current@freebsd.org Wed Mar 29 22:50: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 132E3D2396A for ; Wed, 29 Mar 2017 22:50:43 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 BC9E17B8 for ; Wed, 29 Mar 2017 22:50:42 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-yw0-x234.google.com with SMTP id v76so21086984ywg.0 for ; Wed, 29 Mar 2017 15:50:42 -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=Lvu6zgKn1zghVbzHF/y8tN1fUOXul4HPvb+blPMXQjs=; b=Pssa4cfzekREKGQbfJ0sV20rXSPgtKgW8GgukqYMhw/seCf0OTWzISPjwg5bC7SXGI odbzzucAmwqCt3uJA1XOhI1afq9yTY+Z+iPUiqR8UdYION5q/iproj2tHZSxLHp4iQCj jdfsWH7NJLelEhA19deVZYqUTn8d7v5eyFrdUX36n6DPZZzbdpJisfIpp50PmDLU93q1 DPsSzWGyd86Pd0l+P1sgZdJ9HLMCDJq90XtUqTkxOYY8q6Cy11O0EYxSLCJqT8WRxJix snvYvmFeXrP+2OhNS6kWnGifMgrPC7Os8w/P8uONYPm/O60S0AvFZGxIu4tKwt2CO76E eAeA== 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=Lvu6zgKn1zghVbzHF/y8tN1fUOXul4HPvb+blPMXQjs=; b=geEwmXVNx+HinEM9WHTHZ3R7dz+vj9Kk1zL1xQFI5T3eFO3R4ttoAx6RrfcvSLOC51 cL56sXLszugX+vqx8Ey/5ZVbKiQRqmgWMJvDjsSPQRt0AW/J0oDwGRXGxkmSxLu2CtIM 9OOtGWsLYdggOs7pksAbUJRqO/rY347v/Tj6W7oJQ+1OcoxH8Ae5YG/EXztVRwd/e0Db YeTNVZ1iM1cpNIU/TDooXJxgKzNcSzqg+jYg5qdzfzYHx09f9ylaT31LyLHd6P80O8FK z2Nq2NojpdP2FEMNNqpVxyREU0++hYhmwrjbMEA6zXfSl4/4YbN93ksPIGdUDafs2wcs 8j4A== X-Gm-Message-State: AFeK/H0EvivKJ2Jr7uFZKEdIUaeEAOG2pWA9EUTZSpKbrawDjwblbhxy0HKYXDvXKIo7LP6Fs5/tK0U0T99seg== X-Received: by 10.37.6.87 with SMTP id 84mr3457537ybg.92.1490827841882; Wed, 29 Mar 2017 15:50:41 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.129.20.214 with HTTP; Wed, 29 Mar 2017 15:50:41 -0700 (PDT) In-Reply-To: <3248c64096dae788afc7fde72082b1d1@ultimatedns.net> References: <3248c64096dae788afc7fde72082b1d1@ultimatedns.net> From: Alan Somers Date: Wed, 29 Mar 2017 16:50:41 -0600 X-Google-Sender-Auth: CsmlffRKobjyXohxEJerSisjEkc Message-ID: Subject: Re: Was pf(4) removed from periodic daily? To: Chris H 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, 29 Mar 2017 22:50:43 -0000 On Wed, Mar 29, 2017 at 4:40 PM, Chris H wrote: > I've depended upon pf for many years, but somewhere between > updating my servers from 9 to 11, and 12. I seem to have > lost getting the daily statistics from pf. > > Does anyone know what changed, and what I need to do to > get those reports back? > > Thanks! > > --Chris This change made the report less verbose. That's the only relevant change I can see. https://svnweb.freebsd.org/base?view=revision&revision=290405 As always, the way to enable the reports is to set security_status_pfdenied_enable=YES in periodic.conf (YES is the default) and set the daily_output variable to an email address you check. -Alan From owner-freebsd-current@freebsd.org Wed Mar 29 23:08: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 EE1CCD23EEB for ; Wed, 29 Mar 2017 23:08:02 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 CE686336; Wed, 29 Mar 2017 23:08:02 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id v2TN8h96092653; Wed, 29 Mar 2017 16:08:49 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: Alan Somers Cc: FreeBSD CURRENT In-Reply-To: References: <3248c64096dae788afc7fde72082b1d1@ultimatedns.net>, From: "Chris H" Subject: Re: Was pf(4) removed from periodic daily? Date: Wed, 29 Mar 2017 16:08:49 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <71a58561e31713c4d849fc5c65b5f31d@ultimatedns.net> Content-Transfer-Encoding: 8bit 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, 29 Mar 2017 23:08:03 -0000 On Wed, 29 Mar 2017 16:50:41 -0600 Alan Somers wrote > On Wed, Mar 29, 2017 at 4:40 PM, Chris H wrote: > > I've depended upon pf for many years, but somewhere between > > updating my servers from 9 to 11, and 12. I seem to have > > lost getting the daily statistics from pf. > > > > Does anyone know what changed, and what I need to do to > > get those reports back? > > > > Thanks! > > > > --Chris > > This change made the report less verbose. That's the only relevant > change I can see. > https://svnweb.freebsd.org/base?view=revision&revision=290405 > > As always, the way to enable the reports is to set > security_status_pfdenied_enable=YES in periodic.conf (YES is the > default) and set the daily_output variable to an email address you > check. Thanks, Alan! I'll set it, and anxiously await my pf(4) report! :-) --Chris > > -Alan From owner-freebsd-current@freebsd.org Thu Mar 30 06:51:11 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 7CEE3D251C9 for ; Thu, 30 Mar 2017 06:51:11 +0000 (UTC) (envelope-from mailing-machine@vniz.net) 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 5BD623CD for ; Thu, 30 Mar 2017 06:51:11 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mailman.ysv.freebsd.org (Postfix) id 5B3A2D251C8; Thu, 30 Mar 2017 06:51:11 +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 5AE53D251C7 for ; Thu, 30 Mar 2017 06:51:11 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f65.google.com (mail-lf0-f65.google.com [209.85.215.65]) (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 DF0FA3CA for ; Thu, 30 Mar 2017 06:51:10 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f65.google.com with SMTP id n78so3679394lfi.3 for ; Wed, 29 Mar 2017 23:51:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Bq1KioXHltjRd6W6hlIRRDBRy9PjIKsfwkeSBTKVDBQ=; b=rNTxoj+LFeR4QNluzzR7GpCxZehw3OCTtLV/mAkv0TmbNx6xt5eLSkUEHFzBkl+jZg eSX9zGDWVWQw3d5fuHCVniJ9AxoeRrgw0lpcMvcM9fmFN6KaNS7J7yVCK7jR8uXEr58V bG12303V6MCkQzq0VcLOO3vO/lR75LC9FxmECsB8GI7gNmF5/E1KEmQd7jThoZDvT+AY 4YLMUh78cOzadjSIV8kchVJ3imJ8DWMQAFx+R7MmmLjqGN+hxdstbw8EICt6UrPvedwY FXOhQKV+oHnWhDyXmAjNCJDyELUacUeP3JyB6fxZA11SG/2K7Ejs9TleD7BXMuATUTCt A2eA== X-Gm-Message-State: AFeK/H2eagXsu99+6SC6HOVl5tptjTPudKXcqNLAfHVVIysewzXtUMBirEYyjEZFbhfcSw== X-Received: by 10.46.84.75 with SMTP id y11mr1581533ljd.6.1490856663142; Wed, 29 Mar 2017 23:51:03 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id t125sm205204lff.31.2017.03.29.23.51.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Mar 2017 23:51:02 -0700 (PDT) Subject: Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others To: Bruce Evans References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> <8C24D1BA-1607-4C19-BA38-39256E82C7AF@gmail.com> <51045bee-a626-efb3-4b1e-0c3d36abb1ab@freebsd.org> <20170329132927.U882@besplex.bde.org> <20170330150449.R1061@besplex.bde.org> Cc: "Ngie Cooper (yaneurabeya)" , bde@freebsd.org, current@freebsd.org From: Andrey Chernov Message-ID: <3534bbeb-9f73-4e37-8f89-c05dd9f89f8c@freebsd.org> Date: Thu, 30 Mar 2017 09:51:01 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170330150449.R1061@besplex.bde.org> Content-Type: text/plain; charset=us-ascii 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, 30 Mar 2017 06:51:11 -0000 On 30.03.2017 8:53, Bruce Evans wrote: >> Maybe two will be enough too, I don't check. I just don't need _any_ of >> vt lines. What is matter it is that syscons only mode (without any vt) >> was recently broken, causing shutdown problems and file system damage >> each time. Syscons only mode works for years until you break it recently. > > Actually, I fixed it not so recently (over the last few months), partly > with much older local fixes. Please commit your fix as soon as possible. vt is broken as designed in many aspects (I even mention not all of them), but from other hand I can't allow dirty filesystem (or hang) on each reboot using sc only mode as always. It is dangerous, and fsck takes big time. Moreover, using sc while keeping vt bloat compiled in the kernel just as the bug workaround is the best demotivator for perfectionist. > The escape sequences in dmesg are very interesting. You should debug > those. I'll send you them a bit later. Since I don't want vt at all, I don't want to debug or fix it, let it die. >> I'll try. thanx. But most dangerous new syscons bug is the first one, >> damaging file system on each reboot. I try to go to KDB to debug it, but >> seeing that I can't even enter KDB I understand that all that bugs, >> including nasty one, are introduced by your syscons changes, it was a >> hint to add completely unneeded and unused vt to my kernel config file. > > It's normal to have a slightly damaged file system after a panic. In sc only mode I have no kernel panic, i.e panic with trace on console or entering KDB. I have silent reboot in the middle or end of shutdown sequence or rare dead hang on reboot (which absolutely not acceptable for remote machine). > You might have entered ddb in a context which used to race or deadlock. No. I try about 20 times on machine which does nothing and can't enter KDB in sc only mode, but got one dead hang instead, when start to repeat it too fast. In vt mode I can enter each time, but there are exit problems I already mention. I use text mode in sc. > Strings for function keys: > - these are just broken in both sc and vt I have all function keys working in sc only mode with TERM=cons25 and similar ones. > Pseudographics: > - I don't use it enough to see problems in it. Even finding the unicode > glyph for the block character took me some time. Even cp437 have it and dialog library use it for all windows frames, f.e. all ports config windows use pseudographics if it is available and working (replaced by +-| etc poor looking ASCII otherwise). From owner-freebsd-current@freebsd.org Thu Mar 30 07:40: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 C78DFD2506F for ; Thu, 30 Mar 2017 07:40:36 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id A61348F1 for ; Thu, 30 Mar 2017 07:40:36 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mailman.ysv.freebsd.org (Postfix) id A297BD2506E; Thu, 30 Mar 2017 07:40:36 +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 A234CD2506D for ; Thu, 30 Mar 2017 07:40:36 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f67.google.com (mail-lf0-f67.google.com [209.85.215.67]) (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 316368EE for ; Thu, 30 Mar 2017 07:40:35 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f67.google.com with SMTP id n78so3777465lfi.3 for ; Thu, 30 Mar 2017 00:40:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=DDuMHch/QfkzblMB2YR6U8jlq1L/esjHbPclZQhlBYQ=; b=Z+fJL1m4prSQ3lFXqeO/QW0RGmOVPviaMXfF7/WGhlcjf1TrswIOurMOMWHVZT8gCy 649EgnNRnKxfXuemjuEX0Y5T27B2PFT0O+Ht0e+tEiLW5Mb1Apa4XJ3RRS00bWvKL8b/ rcT2DRyFEXoISCzILfvEXzW2NHqzT86FDXKmt92Yqwka1/XHwcXqFVPqrf6m9+JRmG8i hlbHpqYphV4neT8thXhRxnL3VgSwdVjnOwz83qOplCz7XLWgw4377Zy5BOiN6ZmEj1ec wuaki/pSvi5+STp9dt78aSgLhGStzqLHRwl0oS1xKPlHyFYaobAzTwmGnoLbllOSHmNE WW/w== X-Gm-Message-State: AFeK/H08UnUXoZrO2LmCHFAuVe00y+wC7iivXsGxpZ5JBmpUjUBMaNwblcRq+3ZP/wCDnQ== X-Received: by 10.46.32.152 with SMTP id g24mr1449805lji.78.1490859633412; Thu, 30 Mar 2017 00:40:33 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id e2sm219437ljb.9.2017.03.30.00.40.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 00:40:32 -0700 (PDT) Subject: Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others To: Bruce Evans References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> <8C24D1BA-1607-4C19-BA38-39256E82C7AF@gmail.com> <51045bee-a626-efb3-4b1e-0c3d36abb1ab@freebsd.org> <20170329132927.U882@besplex.bde.org> <20170330150449.R1061@besplex.bde.org> <3534bbeb-9f73-4e37-8f89-c05dd9f89f8c@freebsd.org> Cc: "Ngie Cooper (yaneurabeya)" , bde@freebsd.org, current@freebsd.org From: Andrey Chernov Message-ID: <74ff3f3b-3001-4bdd-1c4b-251a2c4a6f90@freebsd.org> Date: Thu, 30 Mar 2017 10:40:31 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <3534bbeb-9f73-4e37-8f89-c05dd9f89f8c@freebsd.org> Content-Type: text/plain; charset=us-ascii 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, 30 Mar 2017 07:40:36 -0000 On 30.03.2017 9:51, Andrey Chernov wrote: > On 30.03.2017 8:53, Bruce Evans wrote: >>> Maybe two will be enough too, I don't check. I just don't need _any_ of >>> vt lines. What is matter it is that syscons only mode (without any vt) >>> was recently broken, causing shutdown problems and file system damage >>> each time. Syscons only mode works for years until you break it recently. >> >> Actually, I fixed it not so recently (over the last few months), partly >> with much older local fixes. > > Please commit your fix as soon as possible. vt is broken as designed in > many aspects (I even mention not all of them), but from other hand I > can't allow dirty filesystem (or hang) on each reboot using sc only mode > as always. It is dangerous, and fsck takes big time. Moreover, using sc > while keeping vt bloat compiled in the kernel just as the bug workaround > is the best demotivator for perfectionist. > >> The escape sequences in dmesg are very interesting. You should debug >> those. > > I'll send you them a bit later. Since I don't want vt at all, I don't > want to debug or fix it, let it die. Here it is: kernel: allscreens_kbd cursor^[[=0A^[[=7F^[[=0G^[[=0H^[[=7Ividcontrol: setting cursor type: Inappropriate ioctl for device It is caused by vidcontrol call which left from previous sc setup. >>> I'll try. thanx. But most dangerous new syscons bug is the first one, >>> damaging file system on each reboot. I try to go to KDB to debug it, but >>> seeing that I can't even enter KDB I understand that all that bugs, >>> including nasty one, are introduced by your syscons changes, it was a >>> hint to add completely unneeded and unused vt to my kernel config file. >> >> It's normal to have a slightly damaged file system after a panic. > > In sc only mode I have no kernel panic, i.e panic with trace on console > or entering KDB. I have silent reboot in the middle or end of shutdown > sequence or rare dead hang on reboot (which absolutely not acceptable > for remote machine). > >> You might have entered ddb in a context which used to race or deadlock. > > No. I try about 20 times on machine which does nothing and can't enter > KDB in sc only mode, but got one dead hang instead, when start to repeat > it too fast. In vt mode I can enter each time, but there are exit > problems I already mention. > I use text mode in sc. > >> Strings for function keys: >> - these are just broken in both sc and vt > > I have all function keys working in sc only mode with TERM=cons25 and > similar ones. > >> Pseudographics: >> - I don't use it enough to see problems in it. Even finding the unicode >> glyph for the block character took me some time. > > Even cp437 have it and dialog library use it for all windows frames, > f.e. all ports config windows use pseudographics if it is available and > working (replaced by +-| etc poor looking ASCII otherwise). From owner-freebsd-current@freebsd.org Thu Mar 30 09:23:53 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 A663CD2278D for ; Thu, 30 Mar 2017 09:23:53 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 84C49AAB for ; Thu, 30 Mar 2017 09:23:53 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mailman.ysv.freebsd.org (Postfix) id 8068CD2278B; Thu, 30 Mar 2017 09:23:53 +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 800C7D22789 for ; Thu, 30 Mar 2017 09:23:53 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f66.google.com (mail-lf0-f66.google.com [209.85.215.66]) (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 0E251AA5 for ; Thu, 30 Mar 2017 09:23:52 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f66.google.com with SMTP id v2so4002061lfi.2 for ; Thu, 30 Mar 2017 02:23:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=sSkBCcfxTVd8vBo0jsiOEVv8iC90Z4UCFlrVVjv8Jjo=; b=dRpe5cb7g9PooCpl/wICLeAMbtbxOlisAlOYNglfEBZOjDcLge9LxgA7nSoA8+pmYM lHNntyCkennqKjqiJ5h4uwoii61WSNhSgjjKK0pQ+QlPb/izNVc5wsgGn9ycKpc8UtIW F3UU5JbNwaLsJ1q2dArSMPygzAjhDkLKnz5Bc1fCuJdGmGXRK/ibNK8I8oj09FnmJAVu nZxnJxaMz4rEsimSBHNcPcR4EJcsBmDOQDfDzvM6G5+l3bglBP0BE+WKe33HFS72wFwa ZFzCsxJO4PkShRuHgHDdb3WuEnxIpWVi+jjlEEQ/Ov2cYVug2HMxKYpBv0jr2Isfkyix adVQ== X-Gm-Message-State: AFeK/H2DYci20PQjEmEH23Jr7Q7GcT2nDNMtJcyD/0M4cbSBdv5ksOalVR/vlA+u2A+y5w== X-Received: by 10.25.18.95 with SMTP id h92mr1281906lfi.63.1490865830930; Thu, 30 Mar 2017 02:23:50 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id o100sm276183lfi.18.2017.03.30.02.23.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 02:23:50 -0700 (PDT) Subject: Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others To: Bruce Evans References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> <8C24D1BA-1607-4C19-BA38-39256E82C7AF@gmail.com> <51045bee-a626-efb3-4b1e-0c3d36abb1ab@freebsd.org> <20170329132927.U882@besplex.bde.org> <20170330150449.R1061@besplex.bde.org> <3534bbeb-9f73-4e37-8f89-c05dd9f89f8c@freebsd.org> <20170330183716.W1655@besplex.bde.org> Cc: "Ngie Cooper (yaneurabeya)" , bde@freebsd.org, current@freebsd.org From: Andrey Chernov Message-ID: <4085b441-74ee-796f-adc0-713dfc198b03@freebsd.org> Date: Thu, 30 Mar 2017 12:23:49 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170330183716.W1655@besplex.bde.org> Content-Type: text/plain; charset=us-ascii 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, 30 Mar 2017 09:23:53 -0000 > We don't understand the bug yet. It might not even be in sc. Do you only > see problems for shutdown? The shutdown environment is special for > locking. Yes, only for reboot/shutdown. The system does not do anythings wrong even under high load. On reboot or hang those lines are never printed: kernel: Waiting (max 60 seconds) for system process `vnlru' to stop...done kernel: Waiting (max 60 seconds) for system process `bufdaemon' to stop...done kernel: Waiting (max 60 seconds) for system process `syncer' to stop... kernel: Syncing disks, vnodes remaining...5 3 0 1 0 0 done kernel: All buffers synced. (it is from 10-stable sample, old -current samples are lost) Moreover, GELI swap deactivation lines are never printed too (I already mention that I change swap to normal, but nothing is changed). > A hang in sc means that deadlock occurred and sc's new deadlock detection > didn't work. Hangs are rare. Most common are premature reboots. > Check that ddb works before shutdown, or just put a lot of printfs in I can't check it ddb because I can't enter ddb in sc mode, as I already write, nothing happens. Only vt mode allows Ctrl-Alt-ESC, but the bug does not exist in vt mode, so it is pointless. >>> You might have entered ddb in a context which used to race or deadlock. >> >> No. I try about 20 times on machine which does nothing and can't enter >> KDB in sc only mode, but got one dead hang instead, when start to repeat >> it too fast. > > Even earlier than shutdown, and when booting? I mean in normal operation mode after booting, earlier than shutdown. Shutdown with premature reboot is too fast to press anything at the right time. I don't try to enter ddb when booting yet, but tell you results later. > I call this line-drawing characters for cp437, and use them occasionally, > but I don't know the termcap method for using them very well. See ac, as, ae. From owner-freebsd-current@freebsd.org Thu Mar 30 09:34: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 872E3D22C44 for ; Thu, 30 Mar 2017 09:34:47 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 653BA206 for ; Thu, 30 Mar 2017 09:34:47 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mailman.ysv.freebsd.org (Postfix) id 64911D22C43; Thu, 30 Mar 2017 09:34:47 +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 64366D22C42 for ; Thu, 30 Mar 2017 09:34:47 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f68.google.com (mail-lf0-f68.google.com [209.85.215.68]) (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 E6D7D204 for ; Thu, 30 Mar 2017 09:34:46 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f68.google.com with SMTP id v2so4026711lfi.2 for ; Thu, 30 Mar 2017 02:34:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=5mksr8U/LREJOaW4PCiEi3UmHWYp0OH8a6DcugVYK+Y=; b=muNzNc2E2qmCWuqaxULOE/0+wdeG87WMKLpzicfX2BrgwbzLFa576Y9GBX7oNgUO9Y VxJqAgcea6UFYGyjUkmqgC0EHlS+HGe2BjtJMUZcvksvx2xamhfzvsxyYxMykvSBITA2 1Vx1XIHuVSrzr9AzCMYTQPGQgph6/Rtm7CuEXvhkuu3fYp8BjMF5CV5fhnvDOICl8tWG 4Y9J0KZ/t0RtmPW6G5VfycFFvJFgiP0NJrTbp9CsZNULUPhFAoALqJUxWKhKBscF9d6g RgMT4jWa3F+IAPgbGicse/d1IM7D0JfJukaSCFsPuCuGhcrK9dLZnpUfpQiOAxZj2iyT F+iw== X-Gm-Message-State: AFeK/H1UzMSWwZuFSAZXPY1KN1DPhRE//GBKXWDoxqhTZNEScKsEunDuywsCAt1umjd0Jw== X-Received: by 10.25.221.195 with SMTP id w64mr1290632lfi.31.1490866484589; Thu, 30 Mar 2017 02:34:44 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id f187sm272167lfg.37.2017.03.30.02.34.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 02:34:44 -0700 (PDT) Subject: Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others To: Bruce Evans References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> <8C24D1BA-1607-4C19-BA38-39256E82C7AF@gmail.com> <51045bee-a626-efb3-4b1e-0c3d36abb1ab@freebsd.org> <20170329132927.U882@besplex.bde.org> <20170330150449.R1061@besplex.bde.org> <3534bbeb-9f73-4e37-8f89-c05dd9f89f8c@freebsd.org> <20170330183716.W1655@besplex.bde.org> <4085b441-74ee-796f-adc0-713dfc198b03@freebsd.org> Cc: "Ngie Cooper (yaneurabeya)" , bde@freebsd.org, current@freebsd.org From: Andrey Chernov Message-ID: <1772f54a-4268-577a-8e7f-abce929d39c8@freebsd.org> Date: Thu, 30 Mar 2017 12:34:42 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <4085b441-74ee-796f-adc0-713dfc198b03@freebsd.org> Content-Type: text/plain; charset=us-ascii 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, 30 Mar 2017 09:34:47 -0000 On 30.03.2017 12:23, Andrey Chernov wrote: > Yes, only for reboot/shutdown. The system does not do anythings wrong > even under high load. On reboot or hang those lines are never printed: > > kernel: Waiting (max 60 seconds) for system process `vnlru' to stop...done > kernel: Waiting (max 60 seconds) for system process `bufdaemon' to > stop...done > kernel: Waiting (max 60 seconds) for system process `syncer' to stop... > kernel: Syncing disks, vnodes remaining...5 3 0 1 0 0 done > kernel: All buffers synced. > (it is from 10-stable sample, old -current samples are lost) > > Moreover, GELI swap deactivation lines are never printed too (I already > mention that I change swap to normal, but nothing is changed). I start to have raw guess that _any_ kernel printf in shutdown mode cause not printf but premature reboot. From owner-freebsd-current@freebsd.org Thu Mar 30 05:53:21 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 9D23BD257CD for ; Thu, 30 Mar 2017 05:53:21 +0000 (UTC) (envelope-from brde@optusnet.com.au) 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 85BF665E for ; Thu, 30 Mar 2017 05:53:21 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: by mailman.ysv.freebsd.org (Postfix) id 850B8D257CC; Thu, 30 Mar 2017 05:53:21 +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 84AAAD257CB for ; Thu, 30 Mar 2017 05:53:21 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 30D0265C; Thu, 30 Mar 2017 05:53:20 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id AE2104204CA; Thu, 30 Mar 2017 16:53:12 +1100 (AEDT) Date: Thu, 30 Mar 2017 16:53:11 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Andrey Chernov cc: Bruce Evans , "Ngie Cooper (yaneurabeya)" , bde@freebsd.org, current@freebsd.org Subject: Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others In-Reply-To: Message-ID: <20170330150449.R1061@besplex.bde.org> References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> <8C24D1BA-1607-4C19-BA38-39256E82C7AF@gmail.com> <51045bee-a626-efb3-4b1e-0c3d36abb1ab@freebsd.org> <20170329132927.U882@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=AYLBJzfG c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=rBur9i-uB1bm9AmBHvcA:9 a=CjuIK1q_8ugA:10 X-Mailman-Approved-At: Thu, 30 Mar 2017 10:54:55 +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: Thu, 30 Mar 2017 05:53:21 -0000 On Thu, 30 Mar 2017, Andrey Chernov wrote: > On 29.03.2017 6:29, Bruce Evans wrote: >>> ... >>> I just found the cause, it is new syscons bug (bde@ cc'ed). I never >>> compile vt driver into kernel, i.e. I don't have this lines in the >>> kernel config: >>> >>> device vt >>> device vt_vga >>> device vt_efifb >>> >>> When I add them, the bug described is gone. It seems syscons goes off to >>> early, provoking reboot. >> >> Bah, I only have vt and vt_vga to check that I didn't break them. >> >> Unfortunately, syscons still works right when I remove these lines. > > Maybe two will be enough too, I don't check. I just don't need _any_ of > vt lines. What is matter it is that syscons only mode (without any vt) > was recently broken, causing shutdown problems and file system damage > each time. Syscons only mode works for years until you break it recently. Actually, I fixed it not so recently (over the last few months), partly with much older local fixes. >> Kernel messages in syscons are now supposed to be colorized by CPU. The > > It looks really crazy on 8-core CPU and should not be default. And I > don't see colors in vt mode (which should be parallel at that point, at > least), but what about invisible escapes on vidcontrol errors (f.e. > invalid argument) in vt mode? It is tuned for an 8-core CPU :-). 16 CPUs don't get unique colors by default, but could get 16 unique foreground ones and 1 reverse video (reverse video indeed looks crazier for short messages). 2 CPUs don't get the best choice of colors by default. More than 16 CPUs woold need to use lots of reverse video, except in graphics mode I'm considering expanding to 256 or 64K colors. vt doesn't support colorized kernel messages since I don't want to touch it more than necessary. See subr_terminal.c:termcn_putc(). This is almost exactly the same as scteken_puts() where the color change and some bugs were. It has to switch to the kernel color, and does this by abusing the user state. User escape sequences get corrupted by kernel output, and kernel escape sequence to change the color change the user's color but not the kernel's if they are atomic and not part of a user escape sequence. The escape sequences in dmesg are very interesting. You should debug those. They might be caused by misparsing of kernel escape sequences, or more likely by corruption of user escape sequences. This might happen when: - user prints foo" and ther terminal parses - kernel interrupts this and prints "bar"; "foo" is a supported sequence but "bar" isn't - the error handling is to print the entire escape sequence (that would be the interleaved message "bar" up to the point where the error is detected. Kernel console drivers seem to discard the entire mess. Userland xterm seems to print the entire message. Usually there aren't enough kernel messages interleaved with user ones to make the problem obvious. My changes should fix the problem for syscons, not cause it. But if they are slightly wrong, then they might cause it. >>> Moreover, I can't enter KDB via Ctrl-Alt-ESC in the syscons only mode >>> anymore - nothing happens. In the vt mode I can, but can't exit via "c" >>> properly, all chars typed after "c" produce beep unless I switch to >>> another screen and back. >> >> Try backing out r315984 only. This is supposed to fix parsing of output. > > I'll try. thanx. But most dangerous new syscons bug is the first one, > damaging file system on each reboot. I try to go to KDB to debug it, but > seeing that I can't even enter KDB I understand that all that bugs, > including nasty one, are introduced by your syscons changes, it was a > hint to add completely unneeded and unused vt to my kernel config file. It's normal to have a slightly damaged file system after a panic. You might have entered ddb in a context which used to race or deadlock. It might have seemed to work if it only raced. After the fix, when in this mode the following happens: - in graphics mode, no output is done. The races and deadlocks are not all fixed in the keyboard driver, and it might work in this mode. - in text mode, output is done specially, direct to the frame buffer, in a horizontal window 2/3 of the screen size. This doesn't use a full terminal driver so is hard to use at first. Even the reduced window causes problems. The colorization was originally to make this mode more usable. This mode is rarely active, except for debugging the console driver itself, or for low-level trap handlers. Put a breakpoint almost anywhere in the console driver to see it. sc_puts() is a good choice. > vt is real downgrade. Its default console font is plain ugly, it is > impossible to work with it. I can't find proper TERM for it to make > function keys and pseudographics works in ncurses apps (not with xterm, > a little better with xterm-sco), lynx can't display all things properly, > etc. I agree, but started testing vt a few years ago, and have workarounds for some of its deficiencies. After committing only half of my fixes for low-level console drivers, I got sidetracked into fixing higher level syscons bugs (mainly for for attributes) that are caused by it using the same methods as vt. To work around the above: Default console font: - in text mode, it looks the same as sc, but doesn't have as many non- default fonts in already /usr/share to choose from - in graphics mode, the bold font used for bright characters looks OK, but the font for normal characters is too thin as well as ugly. Graphics mode also defaults to 8-bit wide fonts. Text mode uses 9-bit wide fonts with a hidden bit and the hidden bit extended for characters in the graphics range. The 9th bit allows nicer fonts. vt also breaks use of the 9th bit for graphics characters in text mode. It benefits from the hidden bit, but always zero-extends it. I don't understand the details. From an application: %%% # XXX user must load font with block char where we expect it. case $VTY in vt) # XXX broken in text mode (no extension from 8th bit to 9th). BL="\342\226\210";; # Block char 0x2588 in UTF8 for unicode font. *) BL="\333";; # Block char 0xDB in ASCII for cp437 font. esac %%% I didn't load cp437 for vt, but found the unicode character for the block glyph. This still doesn't work right. The hidden bit is not extended. I guess the details are: - vt looks up the unicode character and finds a glyph for it - this glyph is not at its usual index '\333' in the font, but is outside of the graphics range, so its 8th bit is zero-extended. - unicode doesn't have normal characters in the range 0x80-0xff, but the hardware font should. I think VGA also supports extended fonts. I don't know if vt uses extended fonts or misplaces the block glyph in the 0x80-0xff. It could also do fancy stuff like creating glyphs on the fly. Then it would be difficult to find a place to map it if the map is nearly full with in-use glyphs. - graphics modes gives a much larger choice of fonts than sc or vt-text. You can have much larger ones, as needed for 1920x1080. Since I don't use vt, I never got around to setting this up. It seems to be far from automatic, but I'm not sure of the details since I use a FreeBSD-~5.2 userland with current kernels. Strings for function keys: - these are just broken in both sc and vt TERM and simple use of function keys: - using vt in syscons mode mostly works, almost automatically. I just use TEKEN_CONS25 and a hard-coded TERM=cons25 and TERMCAP="cons25:md=\E[1;37m:so=\E[37;44m:se=\E[39;49m:us=\E[1;33;44m:ue=\E[22;39;49m:tc=cons25:". This termcap entry is needed for syscons too. It works around the broken ESC...x sequences by changing attributes to use colors (the ESC...x sequences should give sticky default colors and I program them in .profile but that no longer works. xterm the program uses resources and command-line options to allow the user to change the bad defaults for ANSI attributes and user colors instead, much like the ESC...x sequences used to. xterm escape sequences don't seem to support this, so xterm TERMCAP entries should set colors like the above or better, but I couldn't find any that do. The above actually gives better colors than my ESC...x sequences. ESC...x only supports adjusting normal and reverse video. xterm resources support adjusting everything. Pseudographics: - I don't use it enough to see problems in it. Even finding the unicode glyph for the block character took me some time. Lynx: - the above termcap hack works well for old lynx and man. > All we need is KMS integration alone and not vt. KMS is unusable for me since it is only in a module. Syscons has a remarkably large amount of support for VGA. The only problems are that features that VGAs had in 1990 are still not used in upper layers), and SVGA is not quite enough now. Syscons on Intel graphics (SVGA compatible) is still much better than vt without KMS. It supports switching from text mode to 1920x1080 graphics mode at runtime. I don't actually use graphics mode except for X and other OSes. It is too hard to make graphics mode work correctly for ddb and low-level console messages. KMS would make it harder, since it is too hard to even read large code to see where it has races and deadlocks when it is reentered. I also don't need teken features. syscons features that I need like ESC...x support are easy to restore by restoring scterm-sc.c (takes 10-20 lines of updates). This loses mainly UTF8 support. UTF8 can't really work for syscons either, since it has only 8-bit characters in history, so all that can be done is map UTF8 encodings for 256 preferred or active characters into 8-bit encodings. Bruce From owner-freebsd-current@freebsd.org Thu Mar 30 08:31: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 BBC40D235A2 for ; Thu, 30 Mar 2017 08:31:51 +0000 (UTC) (envelope-from brde@optusnet.com.au) 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 A3E1C847 for ; Thu, 30 Mar 2017 08:31:51 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: by mailman.ysv.freebsd.org (Postfix) id A31F7D2359E; Thu, 30 Mar 2017 08:31:51 +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 A2B2ED2359D for ; Thu, 30 Mar 2017 08:31:51 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id 5155F845; Thu, 30 Mar 2017 08:31:51 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id B0DEAD61D56; Thu, 30 Mar 2017 19:11:04 +1100 (AEDT) Date: Thu, 30 Mar 2017 19:11:04 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Andrey Chernov cc: Bruce Evans , "Ngie Cooper (yaneurabeya)" , bde@freebsd.org, current@freebsd.org Subject: Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others In-Reply-To: <3534bbeb-9f73-4e37-8f89-c05dd9f89f8c@freebsd.org> Message-ID: <20170330183716.W1655@besplex.bde.org> References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> <8C24D1BA-1607-4C19-BA38-39256E82C7AF@gmail.com> <51045bee-a626-efb3-4b1e-0c3d36abb1ab@freebsd.org> <20170329132927.U882@besplex.bde.org> <20170330150449.R1061@besplex.bde.org> <3534bbeb-9f73-4e37-8f89-c05dd9f89f8c@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=AYLBJzfG c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=KmuJ64jpmaimA1LAmLMA:9 a=CjuIK1q_8ugA:10 X-Mailman-Approved-At: Thu, 30 Mar 2017 10:55:22 +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: Thu, 30 Mar 2017 08:31:51 -0000 On Thu, 30 Mar 2017, Andrey Chernov wrote: > On 30.03.2017 8:53, Bruce Evans wrote: >>> Maybe two will be enough too, I don't check. I just don't need _any_ of >>> vt lines. What is matter it is that syscons only mode (without any vt) >>> was recently broken, causing shutdown problems and file system damage >>> each time. Syscons only mode works for years until you break it recently. >> >> Actually, I fixed it not so recently (over the last few months), partly >> with much older local fixes. > > Please commit your fix as soon as possible. Committing it is what broke things for you. > vt is broken as designed in > many aspects (I even mention not all of them), It is not that bad. It is much cleaner, but 10-20 times slower and too simple to have as many features or preserve old features, and I don't like rewrites than remove or move features. vt does well to be as compatible as it is, so only annoys people who use the more arcane syscons features (I don't use most of them, but find them in regression tests). Syscons looks ugly, but much better when you look at the details. > but from other hand I > can't allow dirty filesystem (or hang) on each reboot using sc only mode > as always. It is dangerous, and fsck takes big time. Moreover, using sc > while keeping vt bloat compiled in the kernel just as the bug workaround > is the best demotivator for perfectionist. We don't understand the bug yet. It might not even be in sc. Do you only see problems for shutdown? The shutdown environment is special for locking. A hang in sc means that deadlock occurred and sc's new deadlock detection didn't work. sc is supposed to either drop the output or do it specially when it detects deadlock. Deadlocks can also occur in upper layers of the console driver, but even more rarely. I haven't committed fixes for this yet. cnputs() detects some deadlocks and handles them by dropping the output. This loses WITNESS output when you need it for debugging the deadlock. >> The escape sequences in dmesg are very interesting. You should debug >> those. > > I'll send you them a bit later. Since I don't want vt at all, I don't > want to debug or fix it, let it die. :-) >>> I'll try. thanx. But most dangerous new syscons bug is the first one, >>> damaging file system on each reboot. I try to go to KDB to debug it, but >>> seeing that I can't even enter KDB I understand that all that bugs, >>> including nasty one, are introduced by your syscons changes, it was a >>> hint to add completely unneeded and unused vt to my kernel config file. >> >> It's normal to have a slightly damaged file system after a panic. > > In sc only mode I have no kernel panic, i.e panic with trace on console > or entering KDB. I have silent reboot in the middle or end of shutdown > sequence or rare dead hang on reboot (which absolutely not acceptable > for remote machine). There's not much that sc does which can cause that. Maybe a wrong pointer for the frame buffer access in emergency ouput. I saw reboots when I broke this during booting. Check that ddb works before shutdown, or just put a lot of printfs in the shutdown sequence to see where it stops working. I usually sprinkle ddb breakpoints instead of printf()s. This requires more console code to work. Both should work until the final shutdown message from a working version. ddb breakpoints don't work properly under SMP. If all CPUs hit the same one, then the first one corrupts the state for the others. Shutdown should be mostly on a single CPU or with not all CPUs running the shutdown code, so most won't hit breakpoints in shutdown code, so it is fairly safe to put them there. >> You might have entered ddb in a context which used to race or deadlock. > > No. I try about 20 times on machine which does nothing and can't enter > KDB in sc only mode, but got one dead hang instead, when start to repeat > it too fast. Even earlier than shutdown, and when booting? booting with -d gives a simpler environment until sc is completely attached. Try testing that first. Also, do tests before mounting file systems so that nothing needs fsck'ing. > In vt mode I can enter each time, but there are exit > problems I already mention. > I use text mode in sc. > >> Strings for function keys: >> - these are just broken in both sc and vt > > I have all function keys working in sc only mode with TERM=cons25 and > similar ones. > >> Pseudographics: >> - I don't use it enough to see problems in it. Even finding the unicode >> glyph for the block character took me some time. > > Even cp437 have it and dialog library use it for all windows frames, > f.e. all ports config windows use pseudographics if it is available and > working (replaced by +-| etc poor looking ASCII otherwise). I call this line-drawing characters for cp437, and use them occasionally, but I don't know the termcap method for using them very well. Bruce From owner-freebsd-current@freebsd.org Thu Mar 30 11:24:54 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 DF127D25D76 for ; Thu, 30 Mar 2017 11:24:54 +0000 (UTC) (envelope-from avg@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 C5F5BA27 for ; Thu, 30 Mar 2017 11:24:54 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id C54EBD25D75; Thu, 30 Mar 2017 11:24:54 +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 C4F18D25D74 for ; Thu, 30 Mar 2017 11:24:54 +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 B4947A24; Thu, 30 Mar 2017 11:24:53 +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 OAA23286; Thu, 30 Mar 2017 14:24:50 +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 1ctYCA-000Kjg-AG; Thu, 30 Mar 2017 14:24:50 +0300 Subject: Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others To: Andrey Chernov , Bruce Evans Cc: "Ngie Cooper (yaneurabeya)" , bde@FreeBSD.org, current@FreeBSD.org References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> <8C24D1BA-1607-4C19-BA38-39256E82C7AF@gmail.com> <51045bee-a626-efb3-4b1e-0c3d36abb1ab@freebsd.org> <20170329132927.U882@besplex.bde.org> <20170330150449.R1061@besplex.bde.org> <3534bbeb-9f73-4e37-8f89-c05dd9f89f8c@freebsd.org> <20170330183716.W1655@besplex.bde.org> <4085b441-74ee-796f-adc0-713dfc198b03@freebsd.org> <1772f54a-4268-577a-8e7f-abce929d39c8@freebsd.org> From: Andriy Gapon Message-ID: Date: Thu, 30 Mar 2017 14:23:53 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <1772f54a-4268-577a-8e7f-abce929d39c8@freebsd.org> 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, 30 Mar 2017 11:24:55 -0000 On 30/03/2017 12:34, Andrey Chernov wrote: > On 30.03.2017 12:23, Andrey Chernov wrote: >> Yes, only for reboot/shutdown. The system does not do anythings wrong >> even under high load. On reboot or hang those lines are never printed: >> >> kernel: Waiting (max 60 seconds) for system process `vnlru' to stop...done >> kernel: Waiting (max 60 seconds) for system process `bufdaemon' to >> stop...done >> kernel: Waiting (max 60 seconds) for system process `syncer' to stop... >> kernel: Syncing disks, vnodes remaining...5 3 0 1 0 0 done >> kernel: All buffers synced. >> (it is from 10-stable sample, old -current samples are lost) >> >> Moreover, GELI swap deactivation lines are never printed too (I already >> mention that I change swap to normal, but nothing is changed). > > I start to have raw guess that _any_ kernel printf in shutdown mode > cause not printf but premature reboot. This sounds somewhat familiar... I vaguely recall an opposite issue that happened in the past. After one of my changes the reboot started hanging for one user. Turned out that the actual bug was always there, but previously the system rebooted because of a printf that caused a LOR (between spinlocks, AFAIR), witness tried to report it... using printf, and that recursed and there was a triple fault in the end. Let me try to dig some details, maybe the current issue is related in some ways. By chance, do you have WITNESS but not WITNESS_SKIPSPIN in your kernel config? -- Andriy Gapon From owner-freebsd-current@freebsd.org Thu Mar 30 11:33: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 E5158D22277 for ; Thu, 30 Mar 2017 11:33:51 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id CBC7614D for ; Thu, 30 Mar 2017 11:33:51 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id C83A9D22276; Thu, 30 Mar 2017 11:33:51 +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 C7DB3D22274 for ; Thu, 30 Mar 2017 11:33:51 +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 9C09214C; Thu, 30 Mar 2017 11:33:50 +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 OAA23320; Thu, 30 Mar 2017 14:33:49 +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 1ctYKq-000KkB-R4; Thu, 30 Mar 2017 14:33:48 +0300 Subject: Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others From: Andriy Gapon To: Andrey Chernov , Bruce Evans Cc: "Ngie Cooper (yaneurabeya)" , bde@FreeBSD.org, current@FreeBSD.org References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> <8C24D1BA-1607-4C19-BA38-39256E82C7AF@gmail.com> <51045bee-a626-efb3-4b1e-0c3d36abb1ab@freebsd.org> <20170329132927.U882@besplex.bde.org> <20170330150449.R1061@besplex.bde.org> <3534bbeb-9f73-4e37-8f89-c05dd9f89f8c@freebsd.org> <20170330183716.W1655@besplex.bde.org> <4085b441-74ee-796f-adc0-713dfc198b03@freebsd.org> <1772f54a-4268-577a-8e7f-abce929d39c8@freebsd.org> Message-ID: Date: Thu, 30 Mar 2017 14:33:12 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0 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, 30 Mar 2017 11:33:52 -0000 On 30/03/2017 14:23, Andriy Gapon wrote: > On 30/03/2017 12:34, Andrey Chernov wrote: >> On 30.03.2017 12:23, Andrey Chernov wrote: >>> Yes, only for reboot/shutdown. The system does not do anythings wrong >>> even under high load. On reboot or hang those lines are never printed: >>> >>> kernel: Waiting (max 60 seconds) for system process `vnlru' to stop...done >>> kernel: Waiting (max 60 seconds) for system process `bufdaemon' to >>> stop...done >>> kernel: Waiting (max 60 seconds) for system process `syncer' to stop... >>> kernel: Syncing disks, vnodes remaining...5 3 0 1 0 0 done >>> kernel: All buffers synced. >>> (it is from 10-stable sample, old -current samples are lost) >>> >>> Moreover, GELI swap deactivation lines are never printed too (I already >>> mention that I change swap to normal, but nothing is changed). >> >> I start to have raw guess that _any_ kernel printf in shutdown mode >> cause not printf but premature reboot. > > This sounds somewhat familiar... > I vaguely recall an opposite issue that happened in the past. After one of my > changes the reboot started hanging for one user. Turned out that the actual bug > was always there, but previously the system rebooted because of a printf that > caused a LOR (between spinlocks, AFAIR), witness tried to report it... using > printf, and that recursed and there was a triple fault in the end. > > Let me try to dig some details, maybe the current issue is related in some ways. Here they are: https://lists.freebsd.org/pipermail/freebsd-hackers/2012-May/038812.html Turns out I remembered them quite wrong. > By chance, do you have WITNESS but not WITNESS_SKIPSPIN in your kernel config? -- Andriy Gapon From owner-freebsd-current@freebsd.org Thu Mar 30 13:06:40 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 AE8E9D244FB for ; Thu, 30 Mar 2017 13:06:40 +0000 (UTC) (envelope-from brde@optusnet.com.au) 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 96AD0916 for ; Thu, 30 Mar 2017 13:06:40 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: by mailman.ysv.freebsd.org (Postfix) id 932A6D244FA; Thu, 30 Mar 2017 13:06: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 92D4ED244F9 for ; Thu, 30 Mar 2017 13:06:40 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id 58C88915; Thu, 30 Mar 2017 13:06:40 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id 0E88C3C49AA; Fri, 31 Mar 2017 00:06:32 +1100 (AEDT) Date: Fri, 31 Mar 2017 00:06:30 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Andrey Chernov cc: Bruce Evans , "Ngie Cooper (yaneurabeya)" , bde@freebsd.org, current@freebsd.org Subject: Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others In-Reply-To: <74ff3f3b-3001-4bdd-1c4b-251a2c4a6f90@freebsd.org> Message-ID: <20170330233711.O2881@besplex.bde.org> References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> <8C24D1BA-1607-4C19-BA38-39256E82C7AF@gmail.com> <51045bee-a626-efb3-4b1e-0c3d36abb1ab@freebsd.org> <20170329132927.U882@besplex.bde.org> <20170330150449.R1061@besplex.bde.org> <3534bbeb-9f73-4e37-8f89-c05dd9f89f8c@freebsd.org> <74ff3f3b-3001-4bdd-1c4b-251a2c4a6f90@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=KeqiiUQD c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=TBuOmgnnCN7PEgwTOrMA:9 a=CjuIK1q_8ugA:10 X-Mailman-Approved-At: Thu, 30 Mar 2017 13:18:32 +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: Thu, 30 Mar 2017 13:06:40 -0000 On Thu, 30 Mar 2017, Andrey Chernov wrote: > On 30.03.2017 9:51, Andrey Chernov wrote: >> On 30.03.2017 8:53, Bruce Evans wrote: >> >>> The escape sequences in dmesg are very interesting. You should debug >>> those. >> >> I'll send you them a bit later. Since I don't want vt at all, I don't >> want to debug or fix it, let it die. > > Here it is: > kernel: allscreens_kbd cursor^[[=0A^[[=7F^[[=0G^[[=0H^[[=7Ividcontrol: > setting cursor type: Inappropriate ioctl for device > > It is caused by vidcontrol call which left from previous sc setup. This turns out to be uninteresting then. I think you have to configure something specially to get console messages in dmesg, but I get then in console.log, which also requires special configuration (turn this on in syslog.conf). In my configuration, vidcontrol only does ioctls in rc.d, so there are no escape sequences for vidcontrol in console.log, and only 1 error message (for changing the font to a syscons font). There should be more failures, but some ioctls are null instead of working. "vidcontrol show >/dev/console" works to show the colors and also to show that escape sequences end up in console.log. Bruce From owner-freebsd-current@freebsd.org Thu Mar 30 13:26: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 5C561D24B4A for ; Thu, 30 Mar 2017 13:26:13 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 390AC79D for ; Thu, 30 Mar 2017 13:26:13 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mailman.ysv.freebsd.org (Postfix) id 385E8D24B49; Thu, 30 Mar 2017 13:26:13 +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 3805BD24B48 for ; Thu, 30 Mar 2017 13:26:13 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f68.google.com (mail-lf0-f68.google.com [209.85.215.68]) (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 B9B8479C for ; Thu, 30 Mar 2017 13:26:12 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f68.google.com with SMTP id v2so4600580lfi.2 for ; Thu, 30 Mar 2017 06:26:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=BeIHLSdhIj8/8mjTatQzrXOEmKNyqMpTuD1IoHBXiIk=; b=kxs3Dqd85pCxR4RQR9D0MVb3Fy52Jfj7p4NQ7TpEtPTrS9aR9Tx6tUwBoHXTiP27wm qkvI+BXEuzV091G/+N64RC6oMC3oAGFEf1dS+gDpMu0L1GwmXs2ves2mtCUPZ6giRlK8 T5wMVsaa4WRnFdRbYfCG6+JOTZYj0ufFu9bSVio3BpbCk6IeOwb+2RVNaeUV9G4nC8e5 o5DNXsfnVmE7wl3i4H8d8RdnXXKeHigwyhXGnEVyuAIVAHYJyttQi0KxKMa/u8lTqhe2 N0gdv8r2O13mRYDmLpKkz1Q8LsPppA4VJ6ItcDbH4s4HJD1RQy2dYGobPGQuEkInMWwh cd+A== X-Gm-Message-State: AFeK/H1IKObjbgQib20VmbOL+jjd1NlCINLecm6CWZHvpMNhkoPtbJhmu/9lcfgwCszibg== X-Received: by 10.25.202.29 with SMTP id a29mr1829162lfg.23.1490880370295; Thu, 30 Mar 2017 06:26:10 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id f28sm375312lfi.52.2017.03.30.06.26.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 06:26:09 -0700 (PDT) Subject: Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others To: Andriy Gapon , Bruce Evans References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> <8C24D1BA-1607-4C19-BA38-39256E82C7AF@gmail.com> <51045bee-a626-efb3-4b1e-0c3d36abb1ab@freebsd.org> <20170329132927.U882@besplex.bde.org> <20170330150449.R1061@besplex.bde.org> <3534bbeb-9f73-4e37-8f89-c05dd9f89f8c@freebsd.org> <20170330183716.W1655@besplex.bde.org> <4085b441-74ee-796f-adc0-713dfc198b03@freebsd.org> <1772f54a-4268-577a-8e7f-abce929d39c8@freebsd.org> Cc: "Ngie Cooper (yaneurabeya)" , bde@FreeBSD.org, current@FreeBSD.org From: Andrey Chernov Message-ID: <365b1846-ee24-00f5-9498-63b3a290483a@freebsd.org> Date: Thu, 30 Mar 2017 16:26:08 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii 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, 30 Mar 2017 13:26:13 -0000 On 30.03.2017 14:23, Andriy Gapon wrote: > On 30/03/2017 12:34, Andrey Chernov wrote: >> On 30.03.2017 12:23, Andrey Chernov wrote: >>> Yes, only for reboot/shutdown. The system does not do anythings wrong >>> even under high load. On reboot or hang those lines are never printed: >>> >>> kernel: Waiting (max 60 seconds) for system process `vnlru' to stop...done >>> kernel: Waiting (max 60 seconds) for system process `bufdaemon' to >>> stop...done >>> kernel: Waiting (max 60 seconds) for system process `syncer' to stop... >>> kernel: Syncing disks, vnodes remaining...5 3 0 1 0 0 done >>> kernel: All buffers synced. >>> (it is from 10-stable sample, old -current samples are lost) >>> >>> Moreover, GELI swap deactivation lines are never printed too (I already >>> mention that I change swap to normal, but nothing is changed). >> >> I start to have raw guess that _any_ kernel printf in shutdown mode >> cause not printf but premature reboot. > > This sounds somewhat familiar... > I vaguely recall an opposite issue that happened in the past. After one of my > changes the reboot started hanging for one user. Turned out that the actual bug > was always there, but previously the system rebooted because of a printf that > caused a LOR (between spinlocks, AFAIR), witness tried to report it... using > printf, and that recursed and there was a triple fault in the end. > > Let me try to dig some details, maybe the current issue is related in some ways. > > By chance, do you have WITNESS but not WITNESS_SKIPSPIN in your kernel config? No, I don't have WITNESS* I think removing all vt* lines from the kernel confing (and leaving sc) will be enough to reproduce it, but I am not sure. From owner-freebsd-current@freebsd.org Thu Mar 30 13:44:49 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 EEF87D26070 for ; Thu, 30 Mar 2017 13:44:49 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id CC4D635B for ; Thu, 30 Mar 2017 13:44:49 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mailman.ysv.freebsd.org (Postfix) id CBA01D2606F; Thu, 30 Mar 2017 13:44:49 +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 CB42AD2606E for ; Thu, 30 Mar 2017 13:44:49 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f66.google.com (mail-lf0-f66.google.com [209.85.215.66]) (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 7EA7B35A for ; Thu, 30 Mar 2017 13:44:49 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f66.google.com with SMTP id x137so4658285lff.1 for ; Thu, 30 Mar 2017 06:44:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=zSY/zXTtijF0y1I6ZX4o8cg9gwQVOKgohU0QDCJZeXA=; b=aO/XNwE+UJmS8CH3+oFzsatWSXu9JRtcb1CI+3EQSoUNwaQpSLvjnJiK+IX+EPqZkM +dyr2RWsFg2QmoNATzCLCQmlqHRgMr3YWaj7aaH6xJwmZSOPms/R1INI9OSm95ZU5Xs6 c95ABa/gJBlrqXipJFvsXTsKEDRD/i/HcsSGRJ+9uG7lpFTN0YJw1/fSl7XNrO0UIV39 myDmYPo5L9ZlAQuiCg91HmxJ21RrrGJxbmAWfOofQ//KX7pDfcdY4boZXJISyYJ8Lnsf JFQ2kYccEnIEoq1kVgfIzPgEJjOoksaX+utCT1cHMBRtQJI13YbCSNtQon+gcXe2i+xF yNhg== X-Gm-Message-State: AFeK/H2HIp8EnBgeeBohsx2q3GazTN/3S0RMwA9u5fz/uZSzvnhjfBeS/UlKL7opiGTxFg== X-Received: by 10.46.21.94 with SMTP id 30mr2414220ljv.118.1490881487056; Thu, 30 Mar 2017 06:44:47 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id y17sm384782lja.61.2017.03.30.06.44.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 06:44:46 -0700 (PDT) Subject: Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others To: Bruce Evans References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> <8C24D1BA-1607-4C19-BA38-39256E82C7AF@gmail.com> <51045bee-a626-efb3-4b1e-0c3d36abb1ab@freebsd.org> <20170329132927.U882@besplex.bde.org> <20170330150449.R1061@besplex.bde.org> <3534bbeb-9f73-4e37-8f89-c05dd9f89f8c@freebsd.org> <20170330183716.W1655@besplex.bde.org> <4085b441-74ee-796f-adc0-713dfc198b03@freebsd.org> <1772f54a-4268-577a-8e7f-abce929d39c8@freebsd.org> Cc: "Ngie Cooper (yaneurabeya)" , avg@FreeBSD.org, bde@freebsd.org, current@freebsd.org From: Andrey Chernov Message-ID: Date: Thu, 30 Mar 2017 16:44:45 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1772f54a-4268-577a-8e7f-abce929d39c8@freebsd.org> Content-Type: text/plain; charset=us-ascii 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, 30 Mar 2017 13:44:50 -0000 On 30.03.2017 12:34, Andrey Chernov wrote: > On 30.03.2017 12:23, Andrey Chernov wrote: >> Yes, only for reboot/shutdown. The system does not do anythings wrong >> even under high load. On reboot or hang those lines are never printed: >> >> kernel: Waiting (max 60 seconds) for system process `vnlru' to stop...done >> kernel: Waiting (max 60 seconds) for system process `bufdaemon' to >> stop...done >> kernel: Waiting (max 60 seconds) for system process `syncer' to stop... >> kernel: Syncing disks, vnodes remaining...5 3 0 1 0 0 done >> kernel: All buffers synced. >> (it is from 10-stable sample, old -current samples are lost) >> >> Moreover, GELI swap deactivation lines are never printed too (I already >> mention that I change swap to normal, but nothing is changed). > > I start to have raw guess that _any_ kernel printf in shutdown mode > cause not printf but premature reboot. Finally I have good news and bad news with today's -current: 1) It seems your latest commit r316136 fix premature reboot issue. 2) I still can't enter KDB using Ctrl-Alt-ESC, while booting, after booting, after login and while shutdown - nothing happens. boot -d enters KDB normally, but the keyboard sequence handler is broken, not boot -d. From owner-freebsd-current@freebsd.org Thu Mar 30 14:32:09 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 15B3ED26E20 for ; Thu, 30 Mar 2017 14:32:09 +0000 (UTC) (envelope-from brde@optusnet.com.au) 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 F166CFFD for ; Thu, 30 Mar 2017 14:32:08 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: by mailman.ysv.freebsd.org (Postfix) id F0AC4D26E1F; Thu, 30 Mar 2017 14:32:08 +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 F04B9D26E1E for ; Thu, 30 Mar 2017 14:32:08 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 818C5FF9; Thu, 30 Mar 2017 14:32:08 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 6758B424E39; Fri, 31 Mar 2017 01:32:05 +1100 (AEDT) Date: Fri, 31 Mar 2017 01:32:03 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Andrey Chernov cc: Bruce Evans , "Ngie Cooper (yaneurabeya)" , bde@freebsd.org, current@freebsd.org Subject: Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others In-Reply-To: <4085b441-74ee-796f-adc0-713dfc198b03@freebsd.org> Message-ID: <20170331012114.G3075@besplex.bde.org> References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> <8C24D1BA-1607-4C19-BA38-39256E82C7AF@gmail.com> <51045bee-a626-efb3-4b1e-0c3d36abb1ab@freebsd.org> <20170329132927.U882@besplex.bde.org> <20170330150449.R1061@besplex.bde.org> <3534bbeb-9f73-4e37-8f89-c05dd9f89f8c@freebsd.org> <20170330183716.W1655@besplex.bde.org> <4085b441-74ee-796f-adc0-713dfc198b03@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=VbSHBBh9 c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=BwQVPUagxSYhzVETn80A:9 a=CjuIK1q_8ugA:10 X-Mailman-Approved-At: Thu, 30 Mar 2017 16:02:14 +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: Thu, 30 Mar 2017 14:32:09 -0000 On Thu, 30 Mar 2017, Andrey Chernov wrote: >> We don't understand the bug yet. It might not even be in sc. Do you only >> see problems for shutdown? The shutdown environment is special for >> locking. > > Yes, only for reboot/shutdown. The system does not do anythings wrong > even under high load. On reboot or hang those lines are never printed: > > kernel: Waiting (max 60 seconds) for system process `vnlru' to stop...done > kernel: Waiting (max 60 seconds) for system process `bufdaemon' to > stop...done > kernel: Waiting (max 60 seconds) for system process `syncer' to stop... > kernel: Syncing disks, vnodes remaining...5 3 0 1 0 0 done > kernel: All buffers synced. > (it is from 10-stable sample, old -current samples are lost) > > Moreover, GELI swap deactivation lines are never printed too (I already > mention that I change swap to normal, but nothing is changed). > >> A hang in sc means that deadlock occurred and sc's new deadlock detection >> didn't work. > > Hangs are rare. Most common are premature reboots. > >> Check that ddb works before shutdown, or just put a lot of printfs in > > I can't check it ddb because I can't enter ddb in sc mode, as I already > write, nothing happens. Only vt mode allows Ctrl-Alt-ESC, but the bug > does not exist in vt mode, so it is pointless. That is signficant. My changes were initially all about making ddb work almost perfectly with sc. ddb is entered by kdb first calling cngrab(), which does much the same things as cnputc(), but more to set up for using the keyboard. If the sc part of cngrab() detects a problem, it should return and then the sc part of cnputc() should detect the same problem and do emergency output which might be just to buffer it. Nothing at all happening looks like a simpler problem, with Ctrl-Alt-ESC not being recognized. There are too many ways to enable/disable this entry, but I didn't change this. >>>> You might have entered ddb in a context which used to race or deadlock. >>> >>> No. I try about 20 times on machine which does nothing and can't enter >>> KDB in sc only mode, but got one dead hang instead, when start to repeat >>> it too fast. >> >> Even earlier than shutdown, and when booting? > > I mean in normal operation mode after booting, earlier than shutdown. > Shutdown with premature reboot is too fast to press anything at the > right time. I don't try to enter ddb when booting yet, but tell you > results later. Look early in kern_reboot(), where it does print_uptime() then cngrab(). Console output before this cngrab() should work normally, and I suspect that something in cngrab() reboots. But syncing the file systems is done before this. I think they are unmounted later, so are fscked but don't need more than fsck -p if they have been synced. Bruce From owner-freebsd-current@freebsd.org Thu Mar 30 14:57:16 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 00764D245BF for ; Thu, 30 Mar 2017 14:57:16 +0000 (UTC) (envelope-from brde@optusnet.com.au) 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 DA7B47BE for ; Thu, 30 Mar 2017 14:57:15 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: by mailman.ysv.freebsd.org (Postfix) id D6F4AD245BE; Thu, 30 Mar 2017 14:57: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 D6955D245BC for ; Thu, 30 Mar 2017 14:57:15 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6D13E7BD; Thu, 30 Mar 2017 14:57:14 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id 887A93C5ECB; Fri, 31 Mar 2017 01:57:12 +1100 (AEDT) Date: Fri, 31 Mar 2017 01:57:10 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Andrey Chernov cc: Andriy Gapon , Bruce Evans , "Ngie Cooper (yaneurabeya)" , bde@FreeBSD.org, current@FreeBSD.org Subject: Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others In-Reply-To: <365b1846-ee24-00f5-9498-63b3a290483a@freebsd.org> Message-ID: <20170331014521.Y3330@besplex.bde.org> References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> <8C24D1BA-1607-4C19-BA38-39256E82C7AF@gmail.com> <51045bee-a626-efb3-4b1e-0c3d36abb1ab@freebsd.org> <20170329132927.U882@besplex.bde.org> <20170330150449.R1061@besplex.bde.org> <3534bbeb-9f73-4e37-8f89-c05dd9f89f8c@freebsd.org> <20170330183716.W1655@besplex.bde.org> <4085b441-74ee-796f-adc0-713dfc198b03@freebsd.org> <1772f54a-4268-577a-8e7f-abce929d39c8@freebsd.org> <365b1846-ee24-00f5-9498-63b3a290483a@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=AYLBJzfG c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=ya3bOPw4yOU25IaWPrIA:9 a=CjuIK1q_8ugA:10 X-Mailman-Approved-At: Thu, 30 Mar 2017 16:02:46 +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: Thu, 30 Mar 2017 14:57:16 -0000 On Thu, 30 Mar 2017, Andrey Chernov wrote: > On 30.03.2017 14:23, Andriy Gapon wrote: >> On 30/03/2017 12:34, Andrey Chernov wrote: >>> On 30.03.2017 12:23, Andrey Chernov wrote: >>>> Yes, only for reboot/shutdown. The system does not do anythings wrong >>>> even under high load. On reboot or hang those lines are never printed: >>>> >>>> kernel: Waiting (max 60 seconds) for system process `vnlru' to stop...done >>>> kernel: Waiting (max 60 seconds) for system process `bufdaemon' to >>>> stop...done >>>> kernel: Waiting (max 60 seconds) for system process `syncer' to stop... >>>> kernel: Syncing disks, vnodes remaining...5 3 0 1 0 0 done >>>> kernel: All buffers synced. >>>> (it is from 10-stable sample, old -current samples are lost) >>>> >>>> Moreover, GELI swap deactivation lines are never printed too (I already >>>> mention that I change swap to normal, but nothing is changed). >>> >>> I start to have raw guess that _any_ kernel printf in shutdown mode >>> cause not printf but premature reboot. >> >> This sounds somewhat familiar... >> I vaguely recall an opposite issue that happened in the past. After one of my >> changes the reboot started hanging for one user. Turned out that the actual bug >> was always there, but previously the system rebooted because of a printf that >> caused a LOR (between spinlocks, AFAIR), witness tried to report it... using >> printf, and that recursed and there was a triple fault in the end. >> >> Let me try to dig some details, maybe the current issue is related in some ways. >> >> By chance, do you have WITNESS but not WITNESS_SKIPSPIN in your kernel config? > > No, I don't have WITNESS* > I think removing all vt* lines from the kernel confing (and leaving sc) > will be enough to reproduce it, but I am not sure. INVARIANTS with WITNESS is not a bad way to debug problems :-). I just remembered to try it with recent changes. It didn't find any problems for rebooting. The problems reported in Andriy's 2012 threads are almost exactly the ones that I have mostly fixed in syscons -- LORs and deadlocks, and endless recursion in WITNESS to report the problem. Syscons now detects and handles most LORs and deadlocks in itself, but I haven't committed the fixes for upper layers yet, so syscons mostly doesn't get called. cnputs() was "fixed" to silently drop the output. There is still an annoying LOR for devfs vs ufs in reboot. This is reported with no problems since it is not related to consoles. Bruce From owner-freebsd-current@freebsd.org Thu Mar 30 15:13:50 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 43DA2D2603E for ; Thu, 30 Mar 2017 15:13:50 +0000 (UTC) (envelope-from brde@optusnet.com.au) 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 2A79FDC7 for ; Thu, 30 Mar 2017 15:13:50 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: by mailman.ysv.freebsd.org (Postfix) id 270B9D2603D; Thu, 30 Mar 2017 15:13:50 +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 26BC7D2603C for ; Thu, 30 Mar 2017 15:13:50 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id E0216DC5; Thu, 30 Mar 2017 15:13:49 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id D2EF3D62EA3; Fri, 31 Mar 2017 02:13:46 +1100 (AEDT) Date: Fri, 31 Mar 2017 02:13:46 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Andrey Chernov cc: Bruce Evans , "Ngie Cooper (yaneurabeya)" , avg@FreeBSD.org, bde@FreeBSD.org, current@FreeBSD.org Subject: Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others In-Reply-To: Message-ID: <20170331015718.X3330@besplex.bde.org> References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> <8C24D1BA-1607-4C19-BA38-39256E82C7AF@gmail.com> <51045bee-a626-efb3-4b1e-0c3d36abb1ab@freebsd.org> <20170329132927.U882@besplex.bde.org> <20170330150449.R1061@besplex.bde.org> <3534bbeb-9f73-4e37-8f89-c05dd9f89f8c@freebsd.org> <20170330183716.W1655@besplex.bde.org> <4085b441-74ee-796f-adc0-713dfc198b03@freebsd.org> <1772f54a-4268-577a-8e7f-abce929d39c8@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=AYLBJzfG c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=2xpFQjCbXMi36Pbmm-kA:9 a=CjuIK1q_8ugA:10 X-Mailman-Approved-At: Thu, 30 Mar 2017 16:03:11 +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: Thu, 30 Mar 2017 15:13:50 -0000 On Thu, 30 Mar 2017, Andrey Chernov wrote: > On 30.03.2017 12:34, Andrey Chernov wrote: >> On 30.03.2017 12:23, Andrey Chernov wrote: >>> Yes, only for reboot/shutdown. The system does not do anythings wrong >>> even under high load. On reboot or hang those lines are never printed: >>> >>> kernel: Waiting (max 60 seconds) for system process `vnlru' to stop...done >>> kernel: Waiting (max 60 seconds) for system process `bufdaemon' to >>> stop...done >>> kernel: Waiting (max 60 seconds) for system process `syncer' to stop... >>> kernel: Syncing disks, vnodes remaining...5 3 0 1 0 0 done >>> kernel: All buffers synced. >>> (it is from 10-stable sample, old -current samples are lost) >>> >>> Moreover, GELI swap deactivation lines are never printed too (I already >>> mention that I change swap to normal, but nothing is changed). >> >> I start to have raw guess that _any_ kernel printf in shutdown mode >> cause not printf but premature reboot. > > Finally I have good news and bad news with today's -current: > > 1) It seems your latest commit r316136 fix premature reboot issue. Now I need to know how that helped. Do you used a non-default mode? The change had 2 parts and I should have split it for testing. It fixes the window sizing and constructors. > 2) I still can't enter KDB using Ctrl-Alt-ESC, while booting, after > booting, after login and while shutdown - nothing happens. > boot -d enters KDB normally, but the keyboard sequence handler is > broken, not boot -d. Try "~b". It is an old bug that Ctrl-Alt-ESC (and Ctrl-PrtScr) are misconfigured by default. But I think the misconfiguration is the same for vt. There are about 3 layers of options that have to be set to "enable" or not set to "disable" to enable these keys. Bruce From owner-freebsd-current@freebsd.org Thu Mar 30 16:52:56 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 53000D26A9E for ; Thu, 30 Mar 2017 16:52:56 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp002.me.com (st13p35im-asmtp002.me.com [17.164.199.65]) (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 267A577D for ; Thu, 30 Mar 2017 16:52:56 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp002.me.com by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0ONM00O00X63U000@st13p35im-asmtp002.me.com> for freebsd-current@freebsd.org; Thu, 30 Mar 2017 15:52:40 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1490889160; bh=r6a0l4ljLG0QLZ8yw8ApvpnspTWZ8aFdOwXMfbSF+2M=; h=From:Content-type:Subject:Date:To:Message-id:MIME-version; b=OFjcEZYYB1ZfDDa3IIM1QTZ1dWSuYMTqC9m4ZDCSBaqT70+vy5Q/CYX3kzEc0SFsP HCd9vEKOesFrsNrnw4A1rLZShgvfCcmUg2q3lhcaUNJXnei2GKofcsAt1tiUEB/8RG T0kOEH27tYuNNykUlpE2N6PdC7S4gkFixHLrQR5hSTwR16NcTBXLXVz6tRVuwj5DU5 CjeY0NKlrUBxAzMrSbqG5Mr9PYdND/RmFGKgV2d8Yvb6uvWAUqeTMXWsnGycRwzqCw kYlL6kafh1o/V5n3QuWbOXycjz73pLdT5oDUztYaFa4leQuk2LqjI/343zjCt51cx6 ffrzvu7F1Lyag== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0ONM00FYNXFO3B00@st13p35im-asmtp002.me.com> for freebsd-current@freebsd.org; Thu, 30 Mar 2017 15:52:39 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-30_13:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=6 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1703300139 From: Toomas Soome X-Priority: 3 Subject: D10203: loader: zfs reader should check all labels Date: Thu, 30 Mar 2017 18:52:35 +0300 References: To: FreeBSD Current Message-id: MIME-version: 1.0 (Mac OS X Mail 10.3 \(3273\)) X-Mailer: Apple Mail (2.3273) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Thu, 30 Mar 2017 16:52:56 -0000 Hi! Sorry about forward, but this patch is something a bit more complicated = and if we have some people willing to test, it would be really nice:) I = have had it around for my illumos port for some time now, but those = small details about the zfsboot/gptzfsboot etc sometimes do count a = lot=E2=80=A6=20 thanks, toomas > Begin forwarded message: >=20 > From: "tsoome (Toomas Soome)" > Subject: [Differential] D10203: loader: zfs reader should check all = labels > Date: 30. m=C3=A4rts 2017 18:39.44 GMT+3 > To: tsoome@me.com > Reply-To: D10203+574+d76c8a36ba3c3f0a@reviews.freebsd.org >=20 > tsoome created this revision. > Herald added a subscriber: delphij. >=20 > REVISION SUMMARY > The current zfs reader is only checking first label from each device, = however, > we do have 4 labels on device and we should check all 4 to be = protected > against disk failures and incomplete label updates. >=20 > The difficulty is about the fact that 2 label copies are in front of = the > pool data, and 2 are at the end, which means, we have to know the = size of > the pool data area. >=20 > Since we have now the mechanism from common/disk.c to use the = partition > information, it does help us in this task; however, there are still = some > corner cases. >=20 > Namely, if the pool is created without partition, directly on the = disk, > and firmware will give us the wrong size for the disk, we only can = check > the first two label copies. >=20 > REPOSITORY > rS FreeBSD src repository >=20 > REVISION DETAIL > https://reviews.freebsd.org/D10203 >=20 > AFFECTED FILES > sys/boot/efi/boot1/zfs_module.c > sys/boot/efi/loader/main.c > sys/boot/i386/common/drv.h > sys/boot/i386/loader/main.c > sys/boot/i386/zfsboot/zfsboot.c > sys/boot/zfs/libzfs.h > sys/boot/zfs/zfsimpl.c >=20 > EMAIL PREFERENCES > https://reviews.freebsd.org/settings/panel/emailpreferences/ >=20 > To: tsoome, allanjude, imp, avg > Cc: delphij From owner-freebsd-current@freebsd.org Thu Mar 30 17:06:49 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 54192D26F6C; Thu, 30 Mar 2017 17:06:49 +0000 (UTC) (envelope-from danfe@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 3167C1D6; Thu, 30 Mar 2017 17:06:49 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1033) id 755D742BA; Thu, 30 Mar 2017 17:06:48 +0000 (UTC) Date: Thu, 30 Mar 2017 17:06:48 +0000 From: Alexey Dokuchaev To: Dimitry Andric Cc: Mark Millard , Johannes M Dieterich , Matthew Rezny , FreeBSD Current , FreeBSD Toolchain , FreeBSD Ports , FreeBSD PowerPC ML Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) Message-ID: <20170330170648.GA38004@FreeBSD.org> References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> User-Agent: Mutt/1.7.1 (2016-10-04) 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, 30 Mar 2017 17:06:49 -0000 On Mon, Mar 27, 2017 at 11:41:40AM +0200, Dimitry Andric wrote: > On 26 Mar 2017, at 23:36, Mark Millard wrote: > > ... > > Also interesting was: > > > > Installed packages to be REMOVED: > > llvm40-4.0.0.r4 > > > > Number of packages to be removed: 1 > > > > The operation will free 49 GiB. > > Yes, this is big. But there is no real need to build the llvm ports > with debug information, unless you want to hack on llvm itself. Cc'ing jmd@ and rezny@. I've been watching increasing size of our LLVM packages with increasing worry. This is from my tinderbox cache: $ % env LANG=C ls -lh llvm3* -rw-r--r-- 1 root wheel 17M Jan 29 2016 llvm35-3.5.2_1.txz -rw-r--r-- 1 root wheel 18M Mar 7 2016 llvm36-3.6.2_2.txz -rw-r--r-- 1 root wheel 27M Feb 28 01:05 llvm37-3.7.1_4.txz -rw-r--r-- 1 root wheel 207M Jan 19 18:20 llvm38-3.8.1_5.txz -rw-r--r-- 1 root wheel 244M Mar 23 16:42 llvm39-3.9.1_2.txz Dimitry, do you know what had causes such a huge bump in 37 -> 38? They take lots of time to build and package. And given that llvm is indirect dependency of any X11-related port, it pessimises their build times as well (devel/libclc now requires devel/llvm40 after r437268). With 49 GiB llvm40, I guess I won't be able to build-test post as my hardware would just not be capable enough. ./danfe From owner-freebsd-current@freebsd.org Thu Mar 30 17:14:28 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 AFD72D2635D for ; Thu, 30 Mar 2017 17:14:28 +0000 (UTC) (envelope-from mailing-machine@vniz.net) 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 8BFA1BDB for ; Thu, 30 Mar 2017 17:14:28 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mailman.ysv.freebsd.org (Postfix) id 88607D2635C; Thu, 30 Mar 2017 17:14:28 +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 87D53D2635B for ; Thu, 30 Mar 2017 17:14:28 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f68.google.com (mail-lf0-f68.google.com [209.85.215.68]) (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 2A8E6BD7 for ; Thu, 30 Mar 2017 17:14:28 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f68.google.com with SMTP id n78so5217861lfi.3 for ; Thu, 30 Mar 2017 10:14:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=JiybC0ppcTDXkBPxrShhGg8Poin8oSN1TRv/eB29D3E=; b=jNYX1hkEvlKJGCbztBj8jlsg2sXYSseXS7GLP9rVfxOsvd20AQf37OfvTqxjPsxhiP XZCJZg3MKaT/knAUfwX6xKP+Q6nFkgKO5eLWqUMCJsgkCtl8Lak/lDQnp7ovWZ77ONUW Jc3P2s1QlCAH9MtP6AMfrSyUsihKWRUFqywwKjFf2GDGBR04gDS3fMBdLyHt6SNmuiCe QgjmksRn3djjewLFXfGvmdhDc6qEX40NJJGw+n1sPaDZ+okHdCYIxsoE7fBkqw90Zeow o+Oc7ViuNYfBUxqcJQxADEWfVTkjJ5+E3ySfREA/wQqR/iPkjhRFH0la2mrNKBO648sk z0pw== X-Gm-Message-State: AFeK/H3E5CjGrEEFp2PPt267wNZS2gKD7RFtdlrQjteh/wu+pfn3hpbanH2paPdOoRV2BQ== X-Received: by 10.46.1.85 with SMTP id 82mr335295ljb.122.1490894065108; Thu, 30 Mar 2017 10:14:25 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id u195sm479194lja.29.2017.03.30.10.14.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 10:14:24 -0700 (PDT) Subject: Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others To: Bruce Evans References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> <8C24D1BA-1607-4C19-BA38-39256E82C7AF@gmail.com> <51045bee-a626-efb3-4b1e-0c3d36abb1ab@freebsd.org> <20170329132927.U882@besplex.bde.org> <20170330150449.R1061@besplex.bde.org> <3534bbeb-9f73-4e37-8f89-c05dd9f89f8c@freebsd.org> <20170330183716.W1655@besplex.bde.org> <4085b441-74ee-796f-adc0-713dfc198b03@freebsd.org> <1772f54a-4268-577a-8e7f-abce929d39c8@freebsd.org> <20170331015718.X3330@besplex.bde.org> Cc: "Ngie Cooper (yaneurabeya)" , avg@FreeBSD.org, bde@FreeBSD.org, current@FreeBSD.org From: Andrey Chernov Message-ID: Date: Thu, 30 Mar 2017 20:14:23 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170331015718.X3330@besplex.bde.org> Content-Type: text/plain; charset=us-ascii 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, 30 Mar 2017 17:14:28 -0000 On 30.03.2017 18:13, Bruce Evans wrote: > On Thu, 30 Mar 2017, Andrey Chernov wrote: > >> On 30.03.2017 12:34, Andrey Chernov wrote: >>> On 30.03.2017 12:23, Andrey Chernov wrote: >>>> Yes, only for reboot/shutdown. The system does not do anythings wrong >>>> even under high load. On reboot or hang those lines are never printed: >>>> >>>> kernel: Waiting (max 60 seconds) for system process `vnlru' to >>>> stop...done >>>> kernel: Waiting (max 60 seconds) for system process `bufdaemon' to >>>> stop...done >>>> kernel: Waiting (max 60 seconds) for system process `syncer' to stop... >>>> kernel: Syncing disks, vnodes remaining...5 3 0 1 0 0 done >>>> kernel: All buffers synced. >>>> (it is from 10-stable sample, old -current samples are lost) >>>> >>>> Moreover, GELI swap deactivation lines are never printed too (I already >>>> mention that I change swap to normal, but nothing is changed). >>> >>> I start to have raw guess that _any_ kernel printf in shutdown mode >>> cause not printf but premature reboot. >> >> Finally I have good news and bad news with today's -current: >> >> 1) It seems your latest commit r316136 fix premature reboot issue. > > Now I need to know how that helped. Do you used a non-default mode? Perhaps it isn't really helped, but just hide the problem, changing some another race time parameters. I use 80x30 text mode on all screens. >> 2) I still can't enter KDB using Ctrl-Alt-ESC, while booting, after >> booting, after login and while shutdown - nothing happens. >> boot -d enters KDB normally, but the keyboard sequence handler is >> broken, not boot -d. > > Try "~b". What? It just prints \n, new csh prompt and ~b > It is an old bug that Ctrl-Alt-ESC (and Ctrl-PrtScr) Ctrl-PrtScr does nothing too. > But I think the misconfiguration is the > same for vt. No, Ctrl-Alt-ESC works for vt at every phase of the system lifecycle. I use Russian keymap for syscons, but Ctrl, Alt, ESC of course are not remapped. I surely remember it works for syscons long time ago. Just to not forget it, I use PS/2 keyboard and have no vt* lines in the kernel config. From owner-freebsd-current@freebsd.org Thu Mar 30 17:26: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 8B4E0D26804; Thu, 30 Mar 2017 17:26:41 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1658D6F1; Thu, 30 Mar 2017 17:26:40 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::6071:fd3d:eb67:3bb1] (unknown [IPv6:2001:470:7a58:0:6071:fd3d:eb67:3bb1]) (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 06975150D4; Thu, 30 Mar 2017 19:26:31 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_F55303D9-0BDF-4643-A726-2AE9AE62151C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) Date: Thu, 30 Mar 2017 19:26:19 +0200 In-Reply-To: <20170330170648.GA38004@FreeBSD.org> Cc: Mark Millard , Johannes M Dieterich , Matthew Rezny , FreeBSD Current , FreeBSD Toolchain , FreeBSD Ports , FreeBSD PowerPC ML To: Alexey Dokuchaev References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <20170330170648.GA38004@FreeBSD.org> 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: Thu, 30 Mar 2017 17:26:41 -0000 --Apple-Mail=_F55303D9-0BDF-4643-A726-2AE9AE62151C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 30 Mar 2017, at 19:06, Alexey Dokuchaev wrote: >=20 > On Mon, Mar 27, 2017 at 11:41:40AM +0200, Dimitry Andric wrote: >> On 26 Mar 2017, at 23:36, Mark Millard wrote: >>> ... >>> Also interesting was: >>>=20 >>> Installed packages to be REMOVED: >>> llvm40-4.0.0.r4 >>>=20 >>> Number of packages to be removed: 1 >>>=20 >>> The operation will free 49 GiB. >>=20 >> Yes, this is big. But there is no real need to build the llvm ports >> with debug information, unless you want to hack on llvm itself. >=20 > Cc'ing jmd@ and rezny@. >=20 > I've been watching increasing size of our LLVM packages with = increasing > worry. This is from my tinderbox cache: >=20 > $ % env LANG=3DC ls -lh llvm3* > -rw-r--r-- 1 root wheel 17M Jan 29 2016 llvm35-3.5.2_1.txz > -rw-r--r-- 1 root wheel 18M Mar 7 2016 llvm36-3.6.2_2.txz > -rw-r--r-- 1 root wheel 27M Feb 28 01:05 llvm37-3.7.1_4.txz > -rw-r--r-- 1 root wheel 207M Jan 19 18:20 llvm38-3.8.1_5.txz > -rw-r--r-- 1 root wheel 244M Mar 23 16:42 llvm39-3.9.1_2.txz >=20 > Dimitry, do you know what had causes such a huge bump in 37 -> 38? Yes, up to llvm37, the ports were split in devel/llvmXY and lang/clangXY parts, with separate ports for e.g. compiler-rt and other LLVM projects. For llvm38 and later, the devel/llvmXY port contains almost *all* upstream LLVM components, which are then selectable at port configure time. For instance, devel/llvm40 shows: = =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 = llvm40-4.0.0 = =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=90 =E2=94=82 = =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=90 =E2=94=82 =E2=94=82 =E2=94=82 [x] CLANG Build clang = =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 [x] COMPILER_RT Sanitizer libraries = =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 [x] DOCS Build and/or install documentation = =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 [x] EXTRAS Extra clang tools = =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 [x] GOLD Build the LLVM Gold plugin for LTO = =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 [x] LIT Install lit and FileCheck test = tools =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 [x] LLD Install lld, the LLVM linker = =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 [x] LLDB Install lldb, the LLVM debugger = (ignored on 9.x) =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 [x] OPENMP Install libomp, the LLVM OpenMP = runtime library =E2=94=82 =E2=94=82 =E2=94=82 = =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=98 =E2=94=82 = =E2=94=9C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=A4 =E2=94=82 < OK > = =E2=94=82 = =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=98 If you want to reduce the size of the package, only select the part(s) you need. I think you can get by with just the CLANG option, for most dependent ports. > They take lots of time to build and package. And given that llvm > is indirect dependency of any X11-related port, it pessimises their > build times as well (devel/libclc now requires devel/llvm40 after > r437268). The previous split looks pretty hard to maintain, so that is most likely the reason for combining all components in one port after 3.8. Unfortunately the side effect is that it is way less granular. If we ever get infrastructure for generating multiple packages out of one port, the devel/llvm* ports are very good candidates. :) > With 49 GiB llvm40, I guess I won't be able to build-test post as my > hardware would just not be capable enough. As said, this is because of WITH_DEBUG. Don't use that for the llvm ports, for now. It will also allow you to build them with much less RAM in the machine: especially linking can take multiple GB when debuginfo is enabled, and optimization is off. -Dimitry --Apple-Mail=_F55303D9-0BDF-4643-A726-2AE9AE62151C 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 iEYEARECAAYFAljdP8gACgkQsF6jCi4glqPpTQCfWKrhpPQ3itwI8ayvAi2wiv1m HoIAoNyxWbVgd3qM9nxp54fU42E7oxkx =5acw -----END PGP SIGNATURE----- --Apple-Mail=_F55303D9-0BDF-4643-A726-2AE9AE62151C-- From owner-freebsd-current@freebsd.org Thu Mar 30 17:26: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 E172DD2685E; Thu, 30 Mar 2017 17:26:44 +0000 (UTC) (envelope-from rezny@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 BCB9A773; Thu, 30 Mar 2017 17:26:44 +0000 (UTC) (envelope-from rezny@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1406) id 14ED14A61; Thu, 30 Mar 2017 17:26:44 +0000 (UTC) From: Matthew Rezny To: Alexey Dokuchaev Cc: Dimitry Andric , Mark Millard , Johannes M Dieterich , FreeBSD Current , FreeBSD Toolchain , FreeBSD Ports , FreeBSD PowerPC ML Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) Date: Thu, 30 Mar 2017 19:26:43 +0200 Message-ID: <2502554.oHoOYGyFJH@workstation.reztek> Organization: FreeBSD User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <20170330170648.GA38004@FreeBSD.org> References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <20170330170648.GA38004@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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, 30 Mar 2017 17:26:45 -0000 On Thursday 30 March 2017 17:06:48 Alexey Dokuchaev wrote: > On Mon, Mar 27, 2017 at 11:41:40AM +0200, Dimitry Andric wrote: > > On 26 Mar 2017, at 23:36, Mark Millard wrote: > > > ... > > > Also interesting was: > > > > > > Installed packages to be REMOVED: > > > llvm40-4.0.0.r4 > > > > > > Number of packages to be removed: 1 > > > > > > The operation will free 49 GiB. > > > > Yes, this is big. But there is no real need to build the llvm ports > > with debug information, unless you want to hack on llvm itself. > > Cc'ing jmd@ and rezny@. > > I've been watching increasing size of our LLVM packages with increasing > worry. This is from my tinderbox cache: > > $ % env LANG=C ls -lh llvm3* > -rw-r--r-- 1 root wheel 17M Jan 29 2016 llvm35-3.5.2_1.txz > -rw-r--r-- 1 root wheel 18M Mar 7 2016 llvm36-3.6.2_2.txz > -rw-r--r-- 1 root wheel 27M Feb 28 01:05 llvm37-3.7.1_4.txz > -rw-r--r-- 1 root wheel 207M Jan 19 18:20 llvm38-3.8.1_5.txz > -rw-r--r-- 1 root wheel 244M Mar 23 16:42 llvm39-3.9.1_2.txz > > Dimitry, do you know what had causes such a huge bump in 37 -> 38? > > They take lots of time to build and package. And given that llvm > is indirect dependency of any X11-related port, it pessimises their > build times as well (devel/libclc now requires devel/llvm40 after > r437268). > > With 49 GiB llvm40, I guess I won't be able to build-test post as my > hardware would just not be capable enough. > > ./danfe LLVM 3.8 introduced the option to build a shared LLVM library, which is what Mesa needs for use at runtime (for e.g. compiling shaders), separate from linking to it. Previous versions only had one option, if the library was built then all the LLVM binaries were staticly linked to it. LLVM devs state that static linking the LLVM binaries is only for developer use, users should not do that. Mesa's need was causing distributions to ship static linked LLVM binaries against that advice. So, they added a pair of switches so that we can separately control whether that library is built (required for Mesa) and used to link LLVM binaries (not desired). llvm{35,36,37} are statically linked and thus smaller than normal. llvm38 switched to dynamic linking, the default, thus the size grew. llvm39 added the library Mesa needs (we didn't turn on the option in llvm38 since Mesa jumped from 37 to 39), so it grew a little more. I assume llvm40 will be a bit bigger, but do not expect to see another jump as you've observed. From owner-freebsd-current@freebsd.org Thu Mar 30 17:55:28 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 13501D26412; Thu, 30 Mar 2017 17:55:28 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 C449D1B5; Thu, 30 Mar 2017 17:55:27 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id B6AA45A9F15; Thu, 30 Mar 2017 17:55:19 +0000 (UTC) Date: Thu, 30 Mar 2017 17:55:19 +0000 From: Brooks Davis To: Dimitry Andric Cc: Alexey Dokuchaev , FreeBSD Current , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Ports , Johannes M Dieterich , Matthew Rezny Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) Message-ID: <20170330175519.GA34411@spindle.one-eyed-alien.net> References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <20170330170648.GA38004@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline In-Reply-To: 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: Thu, 30 Mar 2017 17:55:28 -0000 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 30, 2017 at 07:26:19PM +0200, Dimitry Andric wrote: > On 30 Mar 2017, at 19:06, Alexey Dokuchaev wrote: > >=20 > > On Mon, Mar 27, 2017 at 11:41:40AM +0200, Dimitry Andric wrote: > >> On 26 Mar 2017, at 23:36, Mark Millard wrote: > >>> ... > >>> Also interesting was: > >>>=20 > >>> Installed packages to be REMOVED: > >>> llvm40-4.0.0.r4 > >>>=20 > >>> Number of packages to be removed: 1 > >>>=20 > >>> The operation will free 49 GiB. > >>=20 > >> Yes, this is big. But there is no real need to build the llvm ports > >> with debug information, unless you want to hack on llvm itself. > >=20 > > Cc'ing jmd@ and rezny@. > >=20 > > I've been watching increasing size of our LLVM packages with increasing > > worry. This is from my tinderbox cache: > >=20 > > $ % env LANG=3DC ls -lh llvm3* > > -rw-r--r-- 1 root wheel 17M Jan 29 2016 llvm35-3.5.2_1.txz > > -rw-r--r-- 1 root wheel 18M Mar 7 2016 llvm36-3.6.2_2.txz > > -rw-r--r-- 1 root wheel 27M Feb 28 01:05 llvm37-3.7.1_4.txz > > -rw-r--r-- 1 root wheel 207M Jan 19 18:20 llvm38-3.8.1_5.txz > > -rw-r--r-- 1 root wheel 244M Mar 23 16:42 llvm39-3.9.1_2.txz > >=20 > > Dimitry, do you know what had causes such a huge bump in 37 -> 38? >=20 > Yes, up to llvm37, the ports were split in devel/llvmXY and lang/clangXY > parts, with separate ports for e.g. compiler-rt and other LLVM projects. It's mostly that we build both shared and static libraries. llvm37 merged clang and llvm (with a clang37 metaport). Dynamic builds were broken for a while too which blew up program size. > > They take lots of time to build and package. And given that llvm > > is indirect dependency of any X11-related port, it pessimises their > > build times as well (devel/libclc now requires devel/llvm40 after > > r437268). >=20 > The previous split looks pretty hard to maintain, so that is most likely > the reason for combining all components in one port after 3.8. > Unfortunately the side effect is that it is way less granular. I kept it up for several revisions past when it was desupported, but it's absolutly impossible with the cmake infrastructure unless we want want to build all of LLVM four times to get clang, llvm, lldb, and lld. I'm pretty sure that would case more complaints. :) > If we ever get infrastructure for generating multiple packages out of > one port, the devel/llvm* ports are very good candidates. :) Very much so. > > With 49 GiB llvm40, I guess I won't be able to build-test post as my > > hardware would just not be capable enough. >=20 > As said, this is because of WITH_DEBUG. Don't use that for the llvm > ports, for now. It will also allow you to build them with much less RAM > in the machine: especially linking can take multiple GB when debuginfo > is enabled, and optimization is off. I'm looking into improving WITH_DEBUG. -- Brooks P.S. Somewhat off topice, but related. FAIR WARNING: the days of self-hosted 32-bit systems are numbered. Switching to lld from our ancient BFD linker will probably buy us some time, but I'd be surprised if you will be able to build LLVM+CLANG with a 2GB address space in 5 years. The sooner people make their peace with this, the better. --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJY3UaGAAoJEKzQXbSebgfAkBMIAIN/F/30yZoenplFbYojBOM2 J7c3G/3Gey/MbnSPpZtiXBUnmZ110yBviXv570T1+CXR1g0DNXUTsdfV4S1aw7Pm 2EfGY53bfTphWkckadGRyYSeH9lNAP4POj0UXCs28gS+7LB9HkJ+U0Gt7VfFNQhu xxHuTFbGUBso6Cgu7gDAsYaboNxoWqO6l3oTzCOoM38xgHkTQAYfhZs8fbZdaGK7 QT81QTQBvE9k/p+6j4jE+KWfFG4L7PZzZuM+hAGv7Mu5PmYfXcx0BzAmNtPyCRpc i9/uSjLFbP7bdn2Y48+6I2lLNUcGudouFJW1tQBhvd3yjkEYhkRux5hCRsiG7vo= =vLBg -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j-- From owner-freebsd-current@freebsd.org Thu Mar 30 18:18: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 D980FD26D57 for ; Thu, 30 Mar 2017 18:18:04 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from vps-mail.nomadlogic.org (unknown [IPv6:2607:f2f8:a098::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B54386E3 for ; Thu, 30 Mar 2017 18:18:04 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [10.44.135.229] (nat-192-187-90-114.nat.tribpub.com [192.187.90.114]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id d59a3bf2 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO for ; Thu, 30 Mar 2017 11:18:03 -0700 (PDT) To: freebsd-current@freebsd.org From: Pete Wright Subject: Realtek Audio On Kabylake Message-ID: <7e4448d5-7458-5361-4105-b19b203a67a3@nomadlogic.org> Date: Thu, 30 Mar 2017 11:18:02 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US 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, 30 Mar 2017 18:18:04 -0000 Hello, I have a new Kabylake based Intel laptop running CURRENT (well drm-next). Everything has "just worked" so far except audio. Here is the output of /dev/sndstat: $ cat /dev/sndstat Installed devices: pcm0: (play/rec) default pcm1: (play) No devices installed from userspace. I am unable to get audio output on the laptop's speakers using the Analog device at pcm0, I was wondering if this was due to the Realtek device not being recognized? I would expect the model number or something similar as opposed to "0x0225". Here's the output of pciconf for reference: $ pciconf -lv hostb0@pci0:0:0:0: class=0x060000 card=0x07431028 chip=0x59048086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI vgapci0@pci0:0:2:0: class=0x030000 card=0x07431028 chip=0x59168086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = display subclass = VGA none0@pci0:0:4:0: class=0x118000 card=0x07431028 chip=0x19038086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'Skylake Processor Thermal Subsystem' class = dasp none1@pci0:0:19:0: class=0x000000 card=0x07431028 chip=0x9d358086 rev=0x21 hdr=0x00 vendor = 'Intel Corporation' class = old subclass = non-VGA display device xhci0@pci0:0:20:0: class=0x0c0330 card=0x07431028 chip=0x9d2f8086 rev=0x21 hdr=0x00 vendor = 'Intel Corporation' device = 'Sunrise Point-LP USB 3.0 xHCI Controller' class = serial bus subclass = USB none2@pci0:0:20:2: class=0x118000 card=0x07431028 chip=0x9d318086 rev=0x21 hdr=0x00 vendor = 'Intel Corporation' device = 'Sunrise Point-LP Thermal subsystem' class = dasp none3@pci0:0:21:0: class=0x118000 card=0x07431028 chip=0x9d608086 rev=0x21 hdr=0x00 vendor = 'Intel Corporation' device = 'Sunrise Point-LP Serial IO I2C Controller' class = dasp none4@pci0:0:21:1: class=0x118000 card=0x07431028 chip=0x9d618086 rev=0x21 hdr=0x00 vendor = 'Intel Corporation' device = 'Sunrise Point-LP Serial IO I2C Controller' class = dasp none5@pci0:0:22:0: class=0x078000 card=0x07431028 chip=0x9d3a8086 rev=0x21 hdr=0x00 vendor = 'Intel Corporation' device = 'Sunrise Point-LP CSME HECI' class = simple comms ahci0@pci0:0:23:0: class=0x010601 card=0x07431028 chip=0x9d038086 rev=0x21 hdr=0x00 vendor = 'Intel Corporation' device = 'Sunrise Point-LP SATA Controller [AHCI mode]' class = mass storage subclass = SATA pcib1@pci0:0:28:0: class=0x060400 card=0x07431028 chip=0x9d148086 rev=0xf1 hdr=0x01 vendor = 'Intel Corporation' device = 'Sunrise Point-LP PCI Express Root Port' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x07431028 chip=0x9d588086 rev=0x21 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = PCI-ISA none6@pci0:0:31:2: class=0x058000 card=0x07431028 chip=0x9d218086 rev=0x21 hdr=0x00 vendor = 'Intel Corporation' device = 'Sunrise Point-LP PMC' class = memory hdac0@pci0:0:31:3: class=0x040380 card=0x07431028 chip=0x9d718086 rev=0x21 hdr=0x00 vendor = 'Intel Corporation' class = multimedia subclass = HDA none7@pci0:0:31:4: class=0x0c0500 card=0x07431028 chip=0x9d238086 rev=0x21 hdr=0x00 vendor = 'Intel Corporation' device = 'Sunrise Point-LP SMBus' class = serial bus subclass = SMBus iwm0@pci0:1:0:0: class=0x028000 card=0x44108086 chip=0x31658086 rev=0x79 hdr=0x00 vendor = 'Intel Corporation' device = 'Wireless 3165' class = network Any pointers would be really helpful. Thanks! -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Thu Mar 30 18:53:26 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 CC96DD26AEB for ; Thu, 30 Mar 2017 18:53:26 +0000 (UTC) (envelope-from brde@optusnet.com.au) 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 B1F356E2 for ; Thu, 30 Mar 2017 18:53:26 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: by mailman.ysv.freebsd.org (Postfix) id B1351D26AEA; Thu, 30 Mar 2017 18:53:26 +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 AF3BDD26AE9 for ; Thu, 30 Mar 2017 18:53:26 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id 558816E1; Thu, 30 Mar 2017 18:53:25 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id 8ABC2D607D1; Fri, 31 Mar 2017 05:53:23 +1100 (AEDT) Date: Fri, 31 Mar 2017 05:53:22 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Andrey Chernov cc: Bruce Evans , "Ngie Cooper (yaneurabeya)" , avg@freebsd.org, bde@freebsd.org, current@freebsd.org Subject: Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others In-Reply-To: Message-ID: <20170331042950.F840@besplex.bde.org> References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> <8C24D1BA-1607-4C19-BA38-39256E82C7AF@gmail.com> <51045bee-a626-efb3-4b1e-0c3d36abb1ab@freebsd.org> <20170329132927.U882@besplex.bde.org> <20170330150449.R1061@besplex.bde.org> <3534bbeb-9f73-4e37-8f89-c05dd9f89f8c@freebsd.org> <20170330183716.W1655@besplex.bde.org> <4085b441-74ee-796f-adc0-713dfc198b03@freebsd.org> <1772f54a-4268-577a-8e7f-abce929d39c8@freebsd.org> <20170331015718.X3330@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=AYLBJzfG c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=bHFY8iiebgpokPJhGwoA:9 a=CjuIK1q_8ugA:10 X-Mailman-Approved-At: Thu, 30 Mar 2017 19:11:06 +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: Thu, 30 Mar 2017 18:53:26 -0000 On Thu, 30 Mar 2017, Andrey Chernov wrote: > On 30.03.2017 18:13, Bruce Evans wrote: >> On Thu, 30 Mar 2017, Andrey Chernov wrote: >>> ... >>> Finally I have good news and bad news with today's -current: >>> >>> 1) It seems your latest commit r316136 fix premature reboot issue. >> >> Now I need to know how that helped. Do you used a non-default mode? > > Perhaps it isn't really helped, but just hide the problem, changing some > another race time parameters. > I use 80x30 text mode on all screens. I think it was the sizing. The non-updated mode is 80x25, so the row address can be out of bounds in the teken layer. >>> 2) I still can't enter KDB using Ctrl-Alt-ESC, while booting, after >>> booting, after login and while shutdown - nothing happens. >>> boot -d enters KDB normally, but the keyboard sequence handler is >>> broken, not boot -d. >> >> Try "~b". > > What? It just prints \n, new csh prompt and ~b This takes ALT_BREAK_TO_DEBUGGER. >> It is an old bug that Ctrl-Alt-ESC (and Ctrl-PrtScr) GENERIC is even more broken than I remembered. It doesn't even have ALT_BREAK_TO_DEBUGGER. In old versions, this didn't affect the syscons key. The key was controlled by the SC_DISABLE_DDBKEY option so defaulted to enabled. There was no tunable or sysctl to change the default. Serial consoles had a BREAK_TO_DEBUGGER option to control entering the debugger on a serial line break. This was not per-device or even per-driver. Things were broken by conflating serial line BREAKs with entering the debugger using a breakpoint instruction. Now there are many sysctls and tunable,s but the basic enable is the conflated BREAK_TO_DEBUGGER. This now gives the default setting for entering kdb using a breakpoint instruction. Syscons calls the function kdb_break() which calls kdb_enter() which does the breakpoint instruction. Arches that don't have such an instruction must have a virtual one. The default setting can be modified using a tunable or sysctl. So to have a chance of the syscons debugger keys working, you first have to configure this setting, using either: - BREAK_TO_DEBUGGER in static config file. This is documented in ddb(4), but only for its unbroken meaning for serial consoles - tunable debug.kdb.break_to_debugger. This seems to be undocumented - sysctl debug.kdb.break_to_debugger. This is documented in ddb(4), but only as equivalent to the unbroken BREAK_TO_DEBUGGER. You have to set the variable using 1 or more of these knobs if you want the syscons and vt debugger keys to work, but this also enables debugger entry for serial line breaks and thus breaks the reason for existence of the unbroken BREAK_TO_DEBUGGER option. Normally you don't want to enter the debugger for serial line breaks, since then unplugging the cable or noise on the cable may enter the debugger, and the option exists to enable the entry for the rare cases where it is safe. Next there are the sysctl and vt knobs to set, but these have correct defaults so are enabled automatically. SC_DISABLE_DDBKEY is now named SC_DISABLE_KDBKEY. It always disabled not only the key, but the code to enable it. It actually controls 2 keys and 1 sequence of keys. When it is not configured, the Ctrl-PtrScr and Ctrl-Alt-ESC keys are enabled by default. This can be changed by a sysctl but not by a tunable. The sysctl is confusingly named with "kbd" (keyboard) in its name, while the configu option has KDB (kerel debugger) in its name. The variable for this also controls the sequences of keys which are more than ddb keys and are controlled by the ALT_BREAK_TO_DEBUGGER option and its knobs. vt doesn't have a static config knob to enable the enables. It has a tunable as well as a sysctl. This sysctl only controls the keys, not key sequences. (There may be more than 2 debugger keys. keymap allows any key to be a debugger key.) syscons and/or vt also have knobs to control halt, poweroff, reboot and panic, bug not suspend. Many of these are defeated by the sequences enabled by ALT_BREAK_TO_DEBUGGER. This is a larger bug in vt. In vt, ALT_BREAK_TO_DEBUGGER is limited by the sysctl for the kdb keys. If kdb entry is allowed, then there is no point in disallowing anything since anything can be done using kdb if it has a backend. This complexity is not enough to give enough control. The control should be per-device. You might have 1 secure console and 1 insecure console. Then enable kdb on at most the secure console. Or 1 remote serial console with a good cable and serial console with a bad cable. Then enable kdb entry for serial line breaks on at most the one with the good cable. With per-device control, the 6 knobs for controlling entry at the kdb level would be sillier, but at least 1 knowb is needed there to prevent all ddb use. > Ctrl-PrtScr does nothing too. > >> But I think the misconfiguration is the >> same for vt. > > No, Ctrl-Alt-ESC works for vt at every phase of the system lifecycle. My point it that it is easy to misconfigure the maze of knobs. However, since sc used to work and vt still works, you must have something like BREAK_TO_DEBUGGER configured, so they should both work. > I use Russian keymap for syscons, but Ctrl, Alt, ESC of course are not > remapped. I surely remember it works for syscons long time ago. I didn't change this, except for th usb keyboard some keys near or equal to Ctrl-PrtScr were broken and I fixed them. I normally use that instead of Ctrl-Alt-Esc. I also rarely enable BREAK_TO_DEBUGGER even for systems that don't have a serial console, but enable the sysctl dynamically on systems where this is safe. This gives the annoying behaviour that the syscons keys don't work until late in the boot, so I have to type ~b. Bruce From owner-freebsd-current@freebsd.org Thu Mar 30 19:16: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 50A4AD2620E for ; Thu, 30 Mar 2017 19:16:38 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (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 ED765A09 for ; Thu, 30 Mar 2017 19:16:37 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wr0-x22b.google.com with SMTP id w43so74256627wrb.0 for ; Thu, 30 Mar 2017 12:16:37 -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=fdnFjT5BjDzbfHDAPp0b40CQivmDQjmdAlvj2bnED0E=; b=iGsGTzBEDWVrUDLgw8KMHqnfjAapiaFrhXQMWBTQr3qLBO/Asbzi2PhmtzeGVOfrJ8 Svm9OCt3dE0uS9xkZ1otXeqUsiqDO6Uc+Nrq2/aqMeM8uhEfDkYnjvs2fJQKEiiZlUzY 3HhoBBynbdOWfWyjF3uNFX4j0U93HMXO1MYJ5wTK4HpGhBPfT/ZNhSpHLgvTuNJAlylq O6HtUMbJjSIwyzWp6rR+dnszfIRbFVaS8FbfMl3vW3J59oZz9rkVaq6AWtdIa6bW6U5w BqZBF5W0rEkPFDgTmBFNd4oCFhQrEyDoGa+DM9Nqeyw2VSiqTEqihOszlf93ru2CzEpj 0DkQ== 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=fdnFjT5BjDzbfHDAPp0b40CQivmDQjmdAlvj2bnED0E=; b=apgjuh60T2HgXKN9limHyMdOGrn/2bNqXMJwrCWQms4MdcssbjG/29+OrvbXhgH1xQ 8x5F70vWYzKkwqeBjrvguuH9YM6kT3yr39zh81m9CNv2Q+mrfk4vqc73A/n6R/FjjeX1 lbmjA6yQFIYFByIH4zJmtrquXOXJtBf8egyZZA8SsHIL4Qn5tviZkN9mUHLtmAcQjBOC HJ0DBnwCUchLmqQ5Qq7p5zngouWk4pZZeGzSC0pl3e0EecpKQJY/2iIp+p8Xg+H5iHQm M5Nk5xUoNeUisXPfEp1UFSYkM99O6Bog4w5S7w0ignMnGrMHrq81dOvkT43jC4kt9rm2 Sn7Q== X-Gm-Message-State: AFeK/H2QQZZHj4pPg0wKAmSeWZ8UurNHk2Rowva6futjqyUQhOjYbbgZSKXq0y/mfblHiPOddTod4zAFij1G4g== X-Received: by 10.28.64.133 with SMTP id n127mr4805647wma.138.1490901396291; Thu, 30 Mar 2017 12:16:36 -0700 (PDT) MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.28.128.133 with HTTP; Thu, 30 Mar 2017 12:16:35 -0700 (PDT) In-Reply-To: References: From: Adrian Chadd Date: Thu, 30 Mar 2017 12:16:35 -0700 X-Google-Sender-Auth: 6QSYu1TgErkYsmOyfCEMU8ZoUxE Message-ID: Subject: Re: increased power consumption lately? To: Johannes Lundberg 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, 30 Mar 2017 19:16:38 -0000 I don't /think/ so - which thread is it on your end? Can you run pmcstat -S instructions -T to see what's taking your CPU? -adrian On 28 March 2017 at 13:36, Johannes Lundberg wrote: > Hi > > Personally I got some acpi-something kernel thread at 100% CPU constant > usage. Need to lock CPU freq at lower value otherwise it runs with > turboboost all the time. > > Could it be the same for you? > > On Tue, 28 Mar 2017 at 20:58, Adrian Chadd wrote: >> >> hiya, >> >> I've noticed that my battery life on my haswell laptop (T540p) seems >> to have taken a nosedive lately. I could've /sworn/ it was getting >> better than 15-16W at idle. >> >> Has anyone noticed any massive decrease in battery life lately? >> >> >> >> -adrian >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Thu Mar 30 20:49: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 E8616D26620 for ; Thu, 30 Mar 2017 20:49:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-17.reflexion.net [208.70.210.17]) (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 99EA0C25 for ; Thu, 30 Mar 2017 20:49:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28246 invoked from network); 30 Mar 2017 20:22:19 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 30 Mar 2017 20:22:19 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Thu, 30 Mar 2017 16:22:19 -0400 (EDT) Received: (qmail 2257 invoked from network); 30 Mar 2017 20:22:19 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Mar 2017 20:22:19 -0000 Received: from [192.168.1.119] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id B6849EC8807; Thu, 30 Mar 2017 13:22:18 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) From: Mark Millard In-Reply-To: <20170329155316.GK59667@spindle.one-eyed-alien.net> Date: Thu, 30 Mar 2017 13:22:17 -0700 Cc: FreeBSD Ports , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current Content-Transfer-Encoding: 7bit Message-Id: References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <45E32F4F-A238-47AA-8E1E-7AD4D9E857D9@dsl-only.net> <20170329155316.GK59667@spindle.one-eyed-alien.net> To: Brooks Davis , Dimitry Andric 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: Thu, 30 Mar 2017 20:49:02 -0000 On 2017-Mar-29, at 8:53 AM, Brooks Davis wrote: > On Mon, Mar 27, 2017 at 03:25:04AM -0700, Mark Millard wrote: >> On 2017-Mar-27, at 2:41 AM, Dimitry Andric wrote: >> >>> On 26 Mar 2017, at 23:36, Mark Millard wrote: >>>> >>>> I upgraded from llvm40 r4 to final. An interesting result was >>>> its creation of a backup package for llvm40-4.0.0.r4: >>>> >>>> about 13 cpu-core-hours running pkg create >>>> >>>> (Remember: I've been building with WITH_DEBUG= ) Its >>>> single-threaded status stands out via elapsed time >>>> approximately matching. >>>> >>>> I'll note that it was somewhat under 6 elapsed hours for >>>> staging to have been populated (-j4 with 4 cores present >>>> helps for this part). >>>> >>>> (Of course these elapsed-time figures are rather system >>>> dependent, although the ratio might be more stable.) >>>> >>>> >>>> >>>> Also interesting was: >>>> >>>> Installed packages to be REMOVED: >>>> llvm40-4.0.0.r4 >>>> >>>> Number of packages to be removed: 1 >>>> >>>> The operation will free 49 GiB. >>> >>> Yes, this is big. But there is no real need to build the llvm ports >>> with debug information, unless you want to hack on llvm itself. And >>> in that case, you are better served by a Subversion checkout or Git >>> clone from upstream instead. >>> >>> -Dimitry >> >> FYI: >> >> Historically unless something extreme like this ends up >> involved I build everything using WITH_DEBUG= or explicit >> -g's in order to have better information on any failure. >> >> This is extreme enough that next time I synchronize >> /usr/ports and it has a devel/llvm40 update I'll >> likely rebuild devel/llvm40 without using WITH_DEBUG= . >> I'm more concerned with the time it takes than with >> the file system space involved. > > In the case of LLVM, enabling debug builds does a LOT more than adding > symbols. It's much more like enabling WITNESS and INVARIANTS in your > kernel, except that the performance of the resulting binary is much > worse than a WITNESS kernel (more like 10x slowdown). > > As Dimitry points out, these builds are of questionable value in ports > so garbage collecting the knob might be the sensable thing to do. Sounds like the ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG technique would not change the "WITNESS and INVARIANTS"-like part of the issue. In fact if WITH_DEBUG= causes the cmake debug-style llvm40 build ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG might not make any difference: separate enforcing of lack of optimization. But just to see what results I've done "pkg delete llvm40" and am doing another build with ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG= and its supporting code in place in addition to using WITH_DEBUG= as the type of build fro FreeBSD's viewpoint. If you know that the test is a waste of machine cycles, you can let me know if you want. === Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Thu Mar 30 20:54:21 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 6E572D26992 for ; Thu, 30 Mar 2017 20:54:21 +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 1DF9512AC for ; Thu, 30 Mar 2017 20:54:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25896 invoked from network); 30 Mar 2017 20:54:19 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 30 Mar 2017 20:54:19 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Thu, 30 Mar 2017 16:54:19 -0400 (EDT) Received: (qmail 23200 invoked from network); 30 Mar 2017 20:54:19 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Mar 2017 20:54:19 -0000 Received: from [192.168.1.119] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 71EAFEC8675; Thu, 30 Mar 2017 13:54:18 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) From: Mark Millard In-Reply-To: <20170330175519.GA34411@spindle.one-eyed-alien.net> Date: Thu, 30 Mar 2017 13:54:17 -0700 Cc: Dimitry Andric , FreeBSD Current , FreeBSD Toolchain , FreeBSD Ports , Johannes M Dieterich , Matthew Rezny , FreeBSD PowerPC ML Content-Transfer-Encoding: 7bit Message-Id: References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <20170330170648.GA38004@FreeBSD.org> <20170330175519.GA34411@spindle.one-eyed-alien.net> To: Brooks Davis 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: Thu, 30 Mar 2017 20:54:21 -0000 On 2017-Mar-30, at 10:55 AM, Brooks Davis wrote: > P.S. Somewhat off topice, but related. FAIR WARNING: the days of > self-hosted 32-bit systems are numbered. Switching to lld from our > ancient BFD linker will probably buy us some time, but I'd be surprised > if you will be able to build LLVM+CLANG with a 2GB address space in 5 > years. The sooner people make their peace with this, the better. Yep. It fights with time preferences as well: when I tried building gcc6 "full bootstrap" via poudriere cross- builds on amd64 (4 cores/threads used) and native on a bpim3 (-mcpu=cortex-a7 with 4 cores supported by FreeBSD and 2GB if RAM) the native build was much faster as I remember. Of course once the cross build was using the gcc6 internal bootstrap compiler not much was running native cross-toolchain materials. (Building that internal bootstrap compiler did have a native-clang cross-compiler involved.) [I do not have access to server-class thread counts or RAM either. And the non-multithread stages contribute even in those contexts as well.] So I'm not looking forward to the issue from that point of view. === Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Thu Mar 30 21:04:23 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 D869BD26E9C; Thu, 30 Mar 2017 21:04:23 +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 8F8011A7D; Thu, 30 Mar 2017 21:04:23 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::6071:fd3d:eb67:3bb1] (unknown [IPv6:2001:470:7a58:0:6071:fd3d:eb67:3bb1]) (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 A3B98150F0; Thu, 30 Mar 2017 23:04:20 +0200 (CEST) From: Dimitry Andric Message-Id: <7C9A1030-E489-489C-A17B-4981DE429FEA@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_592CEB00-EFD3-48EB-AA9E-58C9F49FC2FF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) Date: Thu, 30 Mar 2017 23:04:15 +0200 In-Reply-To: <20170330175519.GA34411@spindle.one-eyed-alien.net> Cc: Alexey Dokuchaev , FreeBSD Current , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Ports , Johannes M Dieterich , Matthew Rezny To: Brooks Davis References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <20170330170648.GA38004@FreeBSD.org> <20170330175519.GA34411@spindle.one-eyed-alien.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: Thu, 30 Mar 2017 21:04:24 -0000 --Apple-Mail=_592CEB00-EFD3-48EB-AA9E-58C9F49FC2FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 30 Mar 2017, at 19:55, Brooks Davis wrote: >=20 > On Thu, Mar 30, 2017 at 07:26:19PM +0200, Dimitry Andric wrote: ... >>=20 >> As said, this is because of WITH_DEBUG. Don't use that for the llvm >> ports, for now. It will also allow you to build them with much less = RAM >> in the machine: especially linking can take multiple GB when = debuginfo >> is enabled, and optimization is off. >=20 > I'm looking into improving WITH_DEBUG. I stole the following method from graphics/darktable: Index: devel/llvm40/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- devel/llvm40/Makefile (revision 436685) +++ devel/llvm40/Makefile (working copy) @@ -236,6 +236,11 @@ NOT_FOR_ARCH=3D ia64 .include +.if defined(WITH_DEBUG) +CMAKE_BUILD_TYPE=3D RelWithDebInfo +STRIP=3D +.endif + _CRTLIBDIR=3D = ${LLVM_PREFIX:S|${PREFIX}/||}/lib/clang/${LLVM_RELEASE}/lib/freebsd .if ${ARCH} =3D=3D "amd64" _COMPILER_RT_LIBS=3D \ This appears to work for me. > P.S. Somewhat off topice, but related. FAIR WARNING: the days of > self-hosted 32-bit systems are numbered. Switching to lld from our > ancient BFD linker will probably buy us some time, but I'd be = surprised > if you will be able to build LLVM+CLANG with a 2GB address space in 5 > years. The sooner people make their peace with this, the better. Yes, with that above RelWithDebInfo change, GNU ld tends to use ~5G of memory to link the larger llvm executables, so that is definitely beyond i386, even if you run it in a jail on an amd64 host. And if you would want to use link time optimization, the requirements will increase even more... -Dimitry --Apple-Mail=_592CEB00-EFD3-48EB-AA9E-58C9F49FC2FF 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 iEYEARECAAYFAljdctQACgkQsF6jCi4glqOAPACg7xTJA7vHB7TjgbXTSEJIZWYZ IncAoIDyrx2mNKWkPlV8Xathqx4p1FY9 =4mOQ -----END PGP SIGNATURE----- --Apple-Mail=_592CEB00-EFD3-48EB-AA9E-58C9F49FC2FF-- From owner-freebsd-current@freebsd.org Thu Mar 30 21:26:25 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 B4836D24A28 for ; Thu, 30 Mar 2017 21:26:25 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6FA6CE51 for ; Thu, 30 Mar 2017 21:26:25 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::6071:fd3d:eb67:3bb1] (unknown [IPv6:2001:470:7a58:0:6071:fd3d:eb67:3bb1]) (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 E521B150F3; Thu, 30 Mar 2017 23:26:21 +0200 (CEST) From: Dimitry Andric Message-Id: <0F3671DA-704C-4E78-A080-45B351E29367@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_F054BCE1-CF2D-4FF8-964A-CC3DCB19FF85"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Realtek Audio On Kabylake Date: Thu, 30 Mar 2017 23:26:11 +0200 In-Reply-To: <7e4448d5-7458-5361-4105-b19b203a67a3@nomadlogic.org> Cc: freebsd-current@freebsd.org To: Pete Wright References: <7e4448d5-7458-5361-4105-b19b203a67a3@nomadlogic.org> 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: Thu, 30 Mar 2017 21:26:25 -0000 --Apple-Mail=_F054BCE1-CF2D-4FF8-964A-CC3DCB19FF85 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 30 Mar 2017, at 20:18, Pete Wright wrote: > > Hello, > I have a new Kabylake based Intel laptop running CURRENT (well > drm-next). Everything has "just worked" so far except audio. Here is > the output of /dev/sndstat: > > $ cat /dev/sndstat > Installed devices: > pcm0: (play/rec) default > pcm1: (play) > No devices installed from userspace. > > I am unable to get audio output on the laptop's speakers using the > Analog device at pcm0, I was wondering if this was due to the Realtek > device not being recognized? I would expect the model number or > something similar as opposed to "0x0225". Here's the output of > pciconf for reference: > > $ pciconf -lv ... Hmm, that output didn't contain any Realtek device? What does dmesg say about the pcm devices? Also, can you get any sound via pcm1? -Dimitry --Apple-Mail=_F054BCE1-CF2D-4FF8-964A-CC3DCB19FF85 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 iEYEARECAAYFAljdd/0ACgkQsF6jCi4glqOnCACgj069gpSlHvhIZGRwAHeD1ZER YdYAoORpF2pLVLPh9vpwDh4YvBR+epl7 =Fxi3 -----END PGP SIGNATURE----- --Apple-Mail=_F054BCE1-CF2D-4FF8-964A-CC3DCB19FF85-- From owner-freebsd-current@freebsd.org Thu Mar 30 21:31:00 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 31B65D24B9B for ; Thu, 30 Mar 2017 21:31:00 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from vps-mail.nomadlogic.org (unknown [IPv6:2607:f2f8:a098::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 10561169; Thu, 30 Mar 2017 21:31:00 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [10.44.135.229] (nat-192-187-90-114.nat.tribpub.com [192.187.90.114]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id cc552015 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO; Thu, 30 Mar 2017 14:30:58 -0700 (PDT) Subject: Re: Realtek Audio On Kabylake To: Dimitry Andric Cc: freebsd-current@freebsd.org References: <7e4448d5-7458-5361-4105-b19b203a67a3@nomadlogic.org> <0F3671DA-704C-4E78-A080-45B351E29367@FreeBSD.org> From: Pete Wright Message-ID: <9bafb460-0583-b7af-f24d-593a4f0565fd@nomadlogic.org> Date: Thu, 30 Mar 2017 14:30:57 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <0F3671DA-704C-4E78-A080-45B351E29367@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US 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, 30 Mar 2017 21:31:00 -0000 On 03/30/2017 14:26, Dimitry Andric wrote: > On 30 Mar 2017, at 20:18, Pete Wright wrote: >> Hello, >> I have a new Kabylake based Intel laptop running CURRENT (well >> drm-next). Everything has "just worked" so far except audio. Here is >> the output of /dev/sndstat: >> >> $ cat /dev/sndstat >> Installed devices: >> pcm0: (play/rec) default >> pcm1: (play) >> No devices installed from userspace. >> >> I am unable to get audio output on the laptop's speakers using the >> Analog device at pcm0, I was wondering if this was due to the Realtek >> device not being recognized? I would expect the model number or >> something similar as opposed to "0x0225". Here's the output of >> pciconf for reference: >> >> $ pciconf -lv > ... > > Hmm, that output didn't contain any Realtek device? What does dmesg > say about the pcm devices? Also, can you get any sound via pcm1? yea i thought that was odd as well. here's what i think is relevant from my dmesg buffer: $ dmesg|grep hdaa hdaa0: at nid 1 on hdacc0 pcm0: at nid 33 and 18 on hdaa0 hdaa1: at nid 1 on hdacc1 pcm1: at nid 3 on hdaa1 i have not attempted to output audio via pcm1 via an HDMI connected panel - but I can test that tonight. using pcm1 does *not* work with the headphone jack or laptop speakers but i think that's expected. thanks! -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Fri Mar 31 02:51:48 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 9E91DD231C4 for ; Fri, 31 Mar 2017 02:51:48 +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 6212EBBD for ; Fri, 31 Mar 2017 02:51:47 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 32648 invoked from network); 31 Mar 2017 02:52:42 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 31 Mar 2017 02:52:42 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Thu, 30 Mar 2017 22:51:46 -0400 (EDT) Received: (qmail 26095 invoked from network); 31 Mar 2017 02:51:46 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 31 Mar 2017 02:51:46 -0000 Received: from [192.168.1.119] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 62F64EC78CC; Thu, 30 Mar 2017 19:51:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) From: Mark Millard In-Reply-To: Date: Thu, 30 Mar 2017 19:51:44 -0700 Cc: FreeBSD Ports , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current Content-Transfer-Encoding: 7bit Message-Id: References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <45E32F4F-A238-47AA-8E1E-7AD4D9E857D9@dsl-only.net> <20170329155316.GK59667@spindle.one-eyed-alien.net> To: Brooks Davis , Dimitry Andric 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, 31 Mar 2017 02:51:48 -0000 On 2017-Mar-30, at 1:22 PM, Mark Millard wrote: > On 2017-Mar-29, at 8:53 AM, Brooks Davis wrote: > >> On Mon, Mar 27, 2017 at 03:25:04AM -0700, Mark Millard wrote: >>> On 2017-Mar-27, at 2:41 AM, Dimitry Andric wrote: >>> >>>> On 26 Mar 2017, at 23:36, Mark Millard wrote: >>>>> >>>>> I upgraded from llvm40 r4 to final. An interesting result was >>>>> its creation of a backup package for llvm40-4.0.0.r4: >>>>> >>>>> about 13 cpu-core-hours running pkg create >>>>> >>>>> (Remember: I've been building with WITH_DEBUG= ) Its >>>>> single-threaded status stands out via elapsed time >>>>> approximately matching. >>>>> >>>>> I'll note that it was somewhat under 6 elapsed hours for >>>>> staging to have been populated (-j4 with 4 cores present >>>>> helps for this part). >>>>> >>>>> (Of course these elapsed-time figures are rather system >>>>> dependent, although the ratio might be more stable.) >>>>> >>>>> >>>>> >>>>> Also interesting was: >>>>> >>>>> Installed packages to be REMOVED: >>>>> llvm40-4.0.0.r4 >>>>> >>>>> Number of packages to be removed: 1 >>>>> >>>>> The operation will free 49 GiB. >>>> >>>> Yes, this is big. But there is no real need to build the llvm ports >>>> with debug information, unless you want to hack on llvm itself. And >>>> in that case, you are better served by a Subversion checkout or Git >>>> clone from upstream instead. >>>> >>>> -Dimitry >>> >>> FYI: >>> >>> Historically unless something extreme like this ends up >>> involved I build everything using WITH_DEBUG= or explicit >>> -g's in order to have better information on any failure. >>> >>> This is extreme enough that next time I synchronize >>> /usr/ports and it has a devel/llvm40 update I'll >>> likely rebuild devel/llvm40 without using WITH_DEBUG= . >>> I'm more concerned with the time it takes than with >>> the file system space involved. >> >> In the case of LLVM, enabling debug builds does a LOT more than adding >> symbols. It's much more like enabling WITNESS and INVARIANTS in your >> kernel, except that the performance of the resulting binary is much >> worse than a WITNESS kernel (more like 10x slowdown). >> >> As Dimitry points out, these builds are of questionable value in ports >> so garbage collecting the knob might be the sensable thing to do. > > Sounds like the ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG technique > would not change the "WITNESS and INVARIANTS"-like part of the > issue. In fact if WITH_DEBUG= causes the cmake debug-style > llvm40 build ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG might not > make any difference: separate enforcing of lack of optimization. > > But just to see what results I've done "pkg delete llvm40" > and am doing another build with ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG= > and its supporting code in place in addition to using WITH_DEBUG= > as the type of build fro FreeBSD's viewpoint. > > If you know that the test is a waste of machine cycles, you can > let me know if you want. The experiment showed that ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG use made no difference for devel/llvm40 so devel/llvm40 itself has to change such as what Dimitry Andric reported separately as a working change to the Makefile . (ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG would still have its uses for various other ports.) === Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Fri Mar 31 03:21:58 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 0897BD23EDB for ; Fri, 31 Mar 2017 03:21:58 +0000 (UTC) (envelope-from mailing-machine@vniz.net) 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 D7E2A964 for ; Fri, 31 Mar 2017 03:21:57 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mailman.ysv.freebsd.org (Postfix) id D7078D23EDA; Fri, 31 Mar 2017 03:21:57 +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 D68F9D23ED9 for ; Fri, 31 Mar 2017 03:21:57 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f66.google.com (mail-lf0-f66.google.com [209.85.215.66]) (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 62506961 for ; Fri, 31 Mar 2017 03:21:56 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f66.google.com with SMTP id r36so6173606lfi.0 for ; Thu, 30 Mar 2017 20:21:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=gt9FRnMVHKtALAxNJTK/x0svqT+rN8vQszB4kRjcK5g=; b=eK/MV9dhJwTKr9gpyvm9xEUE2ebXq4rl5feJqR+2LcMAiF8uEKmGE7A0Y5MlrIF9xx 1nQdk4A4HyCqcPFa4rYs7ddRimWXCsh2Q/h22wXWX7s+cMI9Mu5L0uBav8TAMO0iQfz9 0fw94WGk142FWvZau5ebGfgg5l/CuoiEe3X2Am0kfcbMam95MHwbRxML0bYWvyksR/9u ie2hRTXhS9TPDm1xN9Obj+7vKW2pwMgzSHh6nf0W1F2Rl7umL8rTyPf5RRmV+IE3CMDE 4hFLxc/uA1oSD7ejATqDXE35t3kCDHJOVZd6TFs6n1maJkT+Fa8JGTYMrgVsSYzhT49V KBYA== X-Gm-Message-State: AFeK/H2VeeWr+v4wxi/ZXqQgHN26unwqZc5l90KAGj/zYCpdkQjzhiizjBBSsJ2Mmq00Sg== X-Received: by 10.46.87.13 with SMTP id l13mr212904ljb.85.1490930514646; Thu, 30 Mar 2017 20:21:54 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id f187sm673916lfg.37.2017.03.30.20.21.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 20:21:54 -0700 (PDT) Subject: Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others To: Bruce Evans References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> <8C24D1BA-1607-4C19-BA38-39256E82C7AF@gmail.com> <51045bee-a626-efb3-4b1e-0c3d36abb1ab@freebsd.org> <20170329132927.U882@besplex.bde.org> <20170330150449.R1061@besplex.bde.org> <3534bbeb-9f73-4e37-8f89-c05dd9f89f8c@freebsd.org> <20170330183716.W1655@besplex.bde.org> <4085b441-74ee-796f-adc0-713dfc198b03@freebsd.org> <1772f54a-4268-577a-8e7f-abce929d39c8@freebsd.org> <20170331015718.X3330@besplex.bde.org> <20170331042950.F840@besplex.bde.org> Cc: "Ngie Cooper (yaneurabeya)" , avg@freebsd.org, bde@freebsd.org, current@freebsd.org From: Andrey Chernov Message-ID: <6258c93b-3771-887a-0c35-4286b2f63dbd@freebsd.org> Date: Fri, 31 Mar 2017 06:21:52 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170331042950.F840@besplex.bde.org> Content-Type: text/plain; charset=us-ascii 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: Fri, 31 Mar 2017 03:21:58 -0000 On 30.03.2017 21:53, Bruce Evans wrote: > I think it was the sizing. The non-updated mode is 80x25, so the row > address can be out of bounds in the teken layer. I have text 80x30 mode set at rc stage, and _after_ that may have many kernel messages on console, all without causing reboot. How it is different from shutdown stage? Syscons mode is unchanged since rc stage. > - sysctl debug.kdb.break_to_debugger. This is documented in ddb(4), but > only as equivalent to the unbroken BREAK_TO_DEBUGGER. Thanx. Setting debug.kdb.break_to_debugger=1 makes both Ctrl-Alt-ESC and Ctrl-PrtScr works in sc only mode and "c" exit don't cause all chars beeps like in vt. I.e. it works. But I don't understand why debugging via serial involved in sc case while not involved in vt case and fear that some serial noise may provoke break. Is there a chance to untie serial and sc console debuggers? From owner-freebsd-current@freebsd.org Fri Mar 31 04:04:21 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 AB590D26B3D for ; Fri, 31 Mar 2017 04:04:21 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from vps-mail.nomadlogic.org (unknown [IPv6:2607:f2f8:a098::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6F9FF28C for ; Fri, 31 Mar 2017 04:04:21 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [IPv6:2605:e000:1313:b3:9a54:1bff:fe63:848b] (2605:e000:1313:b3:9a54:1bff:fe63:848b [IPv6:2605:e000:1313:b3:9a54:1bff:fe63:848b]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 482d3771 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO for ; Thu, 30 Mar 2017 21:04:20 -0700 (PDT) Subject: Re: Realtek Audio On Kabylake To: freebsd-current@freebsd.org References: <7e4448d5-7458-5361-4105-b19b203a67a3@nomadlogic.org> <0F3671DA-704C-4E78-A080-45B351E29367@FreeBSD.org> <9bafb460-0583-b7af-f24d-593a4f0565fd@nomadlogic.org> From: Pete Wright Message-ID: <98a090f7-0224-7736-6879-59ad31dd88d7@nomadlogic.org> Date: Thu, 30 Mar 2017 21:04:19 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <9bafb460-0583-b7af-f24d-593a4f0565fd@nomadlogic.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US 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, 31 Mar 2017 04:04:21 -0000 On 03/30/2017 14:30, Pete Wright wrote: > > > On 03/30/2017 14:26, Dimitry Andric wrote: >> On 30 Mar 2017, at 20:18, Pete Wright wrote: >>> Hello, >>> I have a new Kabylake based Intel laptop running CURRENT (well >>> drm-next). Everything has "just worked" so far except audio. Here is >>> the output of /dev/sndstat: >>> >>> $ cat /dev/sndstat >>> Installed devices: >>> pcm0: (play/rec) default >>> pcm1: (play) >>> No devices installed from userspace. >>> >>> I am unable to get audio output on the laptop's speakers using the >>> Analog device at pcm0, I was wondering if this was due to the Realtek >>> device not being recognized? I would expect the model number or >>> something similar as opposed to "0x0225". Here's the output of >>> pciconf for reference: >>> >>> $ pciconf -lv >> ... >> >> Hmm, that output didn't contain any Realtek device? What does dmesg >> say about the pcm devices? Also, can you get any sound via pcm1? > > yea i thought that was odd as well. here's what i think is relevant > from my dmesg buffer: > > $ dmesg|grep hdaa > hdaa0: at nid 1 on hdacc0 > pcm0: at nid 33 and 18 on hdaa0 > hdaa1: at nid 1 on hdacc1 > pcm1: at nid 3 on hdaa1 > > i have not attempted to output audio via pcm1 via an HDMI connected > panel - but I can test that tonight. using pcm1 does *not* work with > the headphone jack or laptop speakers but i think that's expected. hrm no luck with HDMI either. FWIW this is the specific chipset: Realtek ALC3253 I grep'd through the source tree and didn't see any references to this chipset, I suspect this is a new driver/codec that needs to be created or imported? It looks like linux only added support with the 4.11 kernel... Cheers, -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Fri Mar 31 06:05:29 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 CBBB9D279B9 for ; Fri, 31 Mar 2017 06:05:29 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id B08CFE9F for ; Fri, 31 Mar 2017 06:05:29 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: by mailman.ysv.freebsd.org (Postfix) id AD18DD279B8; Fri, 31 Mar 2017 06:05:29 +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 AB059D279B7 for ; Fri, 31 Mar 2017 06:05:29 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id 556A4E9E; Fri, 31 Mar 2017 06:05:28 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id DC93AD63F33; Fri, 31 Mar 2017 17:05:26 +1100 (AEDT) Date: Fri, 31 Mar 2017 17:05:26 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Andrey Chernov cc: Bruce Evans , "Ngie Cooper (yaneurabeya)" , avg@freebsd.org, bde@freebsd.org, current@freebsd.org Subject: Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others In-Reply-To: <6258c93b-3771-887a-0c35-4286b2f63dbd@freebsd.org> Message-ID: <20170331152306.M1037@besplex.bde.org> References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> <8C24D1BA-1607-4C19-BA38-39256E82C7AF@gmail.com> <51045bee-a626-efb3-4b1e-0c3d36abb1ab@freebsd.org> <20170329132927.U882@besplex.bde.org> <20170330150449.R1061@besplex.bde.org> <3534bbeb-9f73-4e37-8f89-c05dd9f89f8c@freebsd.org> <20170330183716.W1655@besplex.bde.org> <4085b441-74ee-796f-adc0-713dfc198b03@freebsd.org> <1772f54a-4268-577a-8e7f-abce929d39c8@freebsd.org> <20170331015718.X3330@besplex.bde.org> <20170331042950.F840@besplex.bde.org> <6258c93b-3771-887a-0c35-4286b2f63dbd@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=KeqiiUQD c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=-scLr05SpDXOSetW9vkA:9 a=CjuIK1q_8ugA:10 X-Mailman-Approved-At: Fri, 31 Mar 2017 10:50:43 +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: Fri, 31 Mar 2017 06:05:29 -0000 On Fri, 31 Mar 2017, Andrey Chernov wrote: > On 30.03.2017 21:53, Bruce Evans wrote: >> I think it was the sizing. The non-updated mode is 80x25, so the row >> address can be out of bounds in the teken layer. > > I have text 80x30 mode set at rc stage, and _after_ that may have many > kernel messages on console, all without causing reboot. How it is > different from shutdown stage? Syscons mode is unchanged since rc stage. Probably just because their weren't enough messages to go past row 24. I had no difficulty reproducing the crash today for entering ddb and reboot starting 80x30 and rows > 24, after removing just the window size update in the fix. I missed seeing it the other day because I tested with 80x60 to see the smaller console window more clarly, but must have only tried rebooting with row <= 24. Another recent fix for sc reduced the problem a little. Mode changes are supposed to clear the screen and move the cursor to home, but they only clear the screen. You should have noticed the ugliness from that after the the switch to 80x30. There are enough boot messages to reach row 24 and messages continued from there. Now they start at the top of the screen again. Clearing the messages is not ideal, but syscons always did it. Syscons also has new and old bugs preserving colors across mode changes: - it never preserved changes to the palette (FBIO_SETPALETTE ioctl). Some mode changes should reset the palette, but some should not. Especially not ones for a vt switch - BIOSes should reset the palette for mode changes (even to the same mode). Some BIOSes are confused by syscons setting the DAC to 8 bit mode and reset to a garbage (dark) palette then. They always switch back to 6 bit mode - syscons used to maintain the current colors and didn't change them for mode changes. This was slightly broken, since for a mode change from a mode with full color to one with less color, the interpretation of the color indexes might change. The colors are now maintained by teken and syscons tells teken to do a full window size change which resets the entire teken state including colors. This bug is normally hidden by vidcontrol refreshing the colors. vidcontrol could be held responsible for refreshing or resetting everything after a mode change ioctl, but I think this is backwards since there are many low-level details that are better handled in the driver. Switching to graphics modes is already a complicated 2-ioctl process with not enough options and poor error handling. Like a too-simple wrapper for fork-exec. vt has some interesting related bugs. It doesn't support mode switches of course, and even changing the font seems to be unsupported in text mode. But in graphics mode, changing the font works and even redraws the screen where syscons would clear it for the mode change. But there are bugs redrawing the screen -- often old history is redrawn. This should work like in xterm or a general X window refresh where the redrawing must be done for lots of other events than resize (exposure, etc.). >> - sysctl debug.kdb.break_to_debugger. This is documented in ddb(4), but >> only as equivalent to the unbroken BREAK_TO_DEBUGGER. > > Thanx. Setting debug.kdb.break_to_debugger=1 makes both Ctrl-Alt-ESC and > Ctrl-PrtScr works in sc only mode and "c" exit don't cause all chars > beeps like in vt. I.e. it works. But I don't understand why debugging > via serial involved in sc case while not involved in vt case and fear > that some serial noise may provoke break. This is because only syscons has full conflation of serial line breaks with entering the debugger via a breakpoint instuction. Syscons does: kdb_break(); for its KDB keys, while vt does: kdb_enter(KDB_WHY_BREAK, ...) for its KDB keys. The latter bypasses KDB's permissions on entering the debugger with a BREAK. It is unclear if this is a layering violation in vt or incorrect use of kdb_break() in syscons. It is certainly wrong for vt to use the KDB_WHY_BREAK code if it is avoiding using kdb_break() to fix the conflation. > Is there a chance to untie > serial and sc console debuggers? This is easy to do by copying vt's arguable layering violation. A little more is necessary to unconflate serial breaks: - agree that kdb_break() and KDB_WHY_BREAK are only for serial line breaks - don't use kdb_break() and KDB_WHY_BREAK for console KDB keys of course. vt already has a string saying that the entry is a "manual escape to debugger". Here "to debugger" is redundant, "manual escape" means "DDB key hit manaually by the user" and the driver that saw the key is left out. "vt KDB key" would be a more useful message. syscons used to print a similar message, but it now calls kdb_break() which produces the conflated code KDB_WHY_BREAK and the consistently conflated message "Break to debugger". This is also used for serial line breaks. Capitalization is also inconsistent. - remove kdb_break(). The only correct use of it now is in 1 serial driver. It saves that driver having its own enable knobs. This doesn't work for multiple serial driver or even multiple console devices within a single driver. Multiple console devices within a single driver are not supported, but the gdb device can be separate and needs a separate knob. - add a global enable for all debugger entries in kdb_enter() - unconflate kdb_alt_break() and ALT_BREAK_TO_DEBUGGER, starting with their names. The ~b sequences maps to the conflated KDB_WHY_BREAK, but is closer to a DDB key. The message doesn't say exactly which key and doesn't know it at the level after the keymap maps a physical key to a virtual DDB key. It is not very useful to distinguish this sequence from a DDB key, but easy to do so in the message. - kdb_alt_break() also does reboots and panics, with a single enable knob (but 3 ways to configure it) for the 3 things it does. Console drivers also have keys for this, with separate enable knobs and 2 or 3 ways to configure each. Unconflate and unobfuscate this too. The conflation is mostly in the names. Who would think that a knob for controlling an alernative kdb entry method to serial line breaks also controls rebooting and panics? Certainly not the writers of its documentation. There seems to be none: kdb is undocumented. sysctl -da debug.kdb says "Enable alternative break to debugger". ddb(4) says that it enables "The (sic) alternate (sic) sequence to enter the debugger". I like the sysctl message using the English spelling of "alternative", but after expanding it, its name is wronger since "alternative" suggests a single alternative almost as much as "alternate". The existence of the reboot and panic "breaks" is a larger bug. It is impossible to do a clean reboot starting from "fast" interrupt handler context and difficult starting from normal interrupt handler context. Panicing is not so bad since it is inherently unclean. The existence of similar commands (and dump) in ddb is another bug. I never use them, but use the reset command which on x86's normally uses the keyboard controller. A triple fault would be another good way to get a clean panic. Neither is very clean for multiple CPUs which are probably still running while you are panicing. OTOH, kdb entry has to work here. It has very large complications to give it a chance of working. First it has to stop other CPUs and wait for them to stop. Panic now does the same. Panic is not as careful as kdb entry, but doesn't need to be because it is not restartable. Reboot from kdb_alt_break() doesn't even know that the context is special. Bruce From owner-freebsd-current@freebsd.org Fri Mar 31 13:57: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 5876CD27010 for ; Fri, 31 Mar 2017 13:57:27 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (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 2EEB7D42 for ; Fri, 31 Mar 2017 13:57:27 +0000 (UTC) (envelope-from timp87@gmail.com) Received: by mail-pg0-x22c.google.com with SMTP id g2so71150160pge.3 for ; Fri, 31 Mar 2017 06:57:27 -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=ctsBDxItxm1jhLs4yHuvu5JET3Si6gGMsOZlbupSIfM=; b=eg4QZTFyxlSpxxFVnScZ5BkwFF0UbR76hzhtOGxEF7KhQ7iDANS40Xv4pJLS81PB+D k0spTzxKomcsM3nLadKsAuOVwtxKPUZUgOP3vpwTGRNQQ/LGBuH2E5Rmp2LsPSkXz6uv WYV9Satq+46IivU8jCzm8sh42FMNYEE9gYxLy5hdS77S+2wf+ukFS2/9oWez8yfI0PEN kVNi2Sy3aybmshrwbk3vxaZtWk9p2wWVLEgJM9ojwXalDy2V0tVXMucasAlwtiTEsDF9 dJHPJu3jtRP8DdhqTmvhyKENoNmzMma6+W5WWuyawVmv1oLpqG7seEDMHfQqlqVuP9YV y5JQ== 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=ctsBDxItxm1jhLs4yHuvu5JET3Si6gGMsOZlbupSIfM=; b=GZLPqRkpZsSbQN3JpKeIgoMw6hRUBWD9gmXJqK/LjwJEIwDdsgHC6sjPGqzbHdK3W7 YlfL9uuRQhzbUauOXUD4xnh+iw6ixyCaOLaR+4BOfd1afbwpqrf/c1yNz/XeVzhsrupj ti7zzmVys8qhIt56m1JqJOM17t1tSsfhyRfYF2Mx5wOz/a0InuoiEzULLfm/aXCpjVrN YqPwoHqGRma5vKOgO1EHpBKmFJLZzP3g+WZKkHWNmJBZsq+m4EJ2nLwKZj8SH9S27nUz EUMAdHrKc/wXOeg8XVmFJL6/jHQXGyy4NdSpcUfHNUDcZm/JmG+kK2FRJk59mfSYLeuT d1Bg== X-Gm-Message-State: AFeK/H0hEgE/7fbp83DJ4cFy6FoG6LhIrPXeq2yEuB2BUc4rVJEWOdXG8QTxCexHoktu7Ij+8EU5ojB5s8C7FQ== X-Received: by 10.84.215.213 with SMTP id g21mr3760145plj.159.1490968646533; Fri, 31 Mar 2017 06:57:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.183.34 with HTTP; Fri, 31 Mar 2017 06:57:26 -0700 (PDT) From: Pavel Timofeev Date: Fri, 31 Mar 2017 16:57:26 +0300 Message-ID: Subject: VNET branch destiny To: 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: Fri, 31 Mar 2017 13:57:27 -0000 Hello, dear freebsd-current@! There was FreeBSD Foundation report back in 2016Q2 where it told us about VNET (VIMAGE) update project sponsored by foundation. What is the current situation? Is it committed into base? If not what's the plan? From owner-freebsd-current@freebsd.org Fri Mar 31 14:40: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 50BB9D27C70 for ; Fri, 31 Mar 2017 14:40:15 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 151561DC for ; Fri, 31 Mar 2017 14:40:14 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id E8AB225D37C2; Fri, 31 Mar 2017 14:40:10 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 70BF0D1F7F5; Fri, 31 Mar 2017 14:40:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id Y5nbxDokA0Et; Fri, 31 Mar 2017 14:40:09 +0000 (UTC) Received: from [10.111.64.116] (unknown [IPv6:fde9:577b:c1a9:4410:6886:a86f:e3c7:3fa1]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 38D31D1F7EB; Fri, 31 Mar 2017 14:40:09 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Pavel Timofeev" Cc: freebsd-current Subject: Re: VNET branch destiny Date: Fri, 31 Mar 2017 14:40:07 +0000 Message-ID: <0136F3BE-4B47-4677-8D81-3FE0F5E67E79@lists.zabbadoz.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (2.0BETAr6080) 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, 31 Mar 2017 14:40:15 -0000 On 31 Mar 2017, at 13:57, Pavel Timofeev wrote: > Hello, dear freebsd-current@! > > There was FreeBSD Foundation report back in 2016Q2 where it told us > about VNET (VIMAGE) update project sponsored by foundation. > What is the current situation? Is it committed into base? If not > what's the plan? Changes are in 12 and 11. 12 has seen more slight fixes due to other changes that other committers are tracking and I hope they merge to 11. /bz From owner-freebsd-current@freebsd.org Fri Mar 31 21:57:26 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 896C9D27435 for ; Fri, 31 Mar 2017 21:57:26 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 696E979A for ; Fri, 31 Mar 2017 21:57:25 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id v2VLw9Ra040999 for ; Fri, 31 Mar 2017 14:58:15 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: "FreeBSD CURRENT" From: "Chris H" Subject: GEOM has amnesia Date: Fri, 31 Mar 2017 14:58:15 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <6b1476532d8534c90a48b8353d9f0db2@ultimatedns.net> Content-Transfer-Encoding: 8bit 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, 31 Mar 2017 21:57:26 -0000 Hi I brought this up earlier, but didn't have as much to go on as I do now. So I'd like to try this again; On a recent(ish) install of CURRENT followed by a new kernel/world. I'm finding I can't depend on geom(8) for anything, but the primary (SATA3) drive, it's installed on (if even that). To the point; Blanking/partitioning/formatting a usb memstick to to dump(8) this system to, works fine *until* I reboot. Where I'm greeted with GEOM: da0: the secondary secondary GPT table is corrupt or invalid .. GEOM: diskid/DISK-... : the secondary GTP table is corrupt or invalid .. using the primary only -- gpart recover returns the status to OK, *until* I reboot. Where I'm greeted by the same BS. OK I can't live with this, so I grab a usb2 external drive off the shelf, and try it again. blank/partition/newfs && fsck mounted the partitions on /mnt and performed a restore. Reboot; && get the corrupt GPT message. So. I spin up an old 11 server I have sitting in the closet, with this external drive attached to it. I do *NOT* get the corrupt GPT message. So I blank/partition/newfs the external drive && mount the partitions individually to /mnt && restore again. When I reboot to the external drive still connected to the old 11 server, I do *NOT* receive the corrupt GPT message. WooHoo! I think. So I re-attach the drive to the new 12 server. Reboot, and can't boot to it && get the corrupt GPT message. GEOM seems to be broken in 12, maybe even (recent) 11. As the 11 server I used for testing is ~9 mos out. What can I do to (help?) fix this mess? --Chris See also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218026 Thanks! From owner-freebsd-current@freebsd.org Fri Mar 31 22:37:42 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 5603DD27ECC for ; Fri, 31 Mar 2017 22:37:42 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward2m.cmail.yandex.net (forward2m.cmail.yandex.net [IPv6:2a02:6b8:b030::19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E74BEFAD for ; Fri, 31 Mar 2017 22:37:41 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp3h.mail.yandex.net (smtp3h.mail.yandex.net [84.201.186.20]) by forward2m.cmail.yandex.net (Yandex) with ESMTP id 43BDE21402; Sat, 1 Apr 2017 01:37:29 +0300 (MSK) Received: from smtp3h.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp3h.mail.yandex.net (Yandex) with ESMTP id 8221F440E49; Sat, 1 Apr 2017 01:37:27 +0300 (MSK) Received: by smtp3h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 5BrzMvO8Bt-bRImlgi1; Sat, 01 Apr 2017 01:37:27 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1490999847; bh=zOV2fjc5vYmvhShLu2SgF14KecsQzm2195JHgnkIktc=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=ou6hK11yw95+9+ty4nk5CxUd4C4Gd0wZKC1EuozjhboAdog6diMgkGBBwWWf3mgpf 4OMEieKNREmVvp/Y5o4r1e+EEdC2tuVuAUzx7bKv3qYPC2hfrvGkFwlu44Lw2jt03q 91AyY7N9KitVXxAz8jl8g8WPFpHklPwSQE4eJiPM= Authentication-Results: smtp3h.mail.yandex.net; dkim=pass header.i=@yandex.ru X-Yandex-Suid-Status: 1 0,1 0 Subject: Re: GEOM has amnesia To: Chris H , FreeBSD CURRENT References: <6b1476532d8534c90a48b8353d9f0db2@ultimatedns.net> From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Message-ID: Date: Sat, 1 Apr 2017 01:36:54 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <6b1476532d8534c90a48b8353d9f0db2@ultimatedns.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JRqLa4A52BwdoRQFOiFIR4h4qtvpdKrTE" 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, 31 Mar 2017 22:37:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JRqLa4A52BwdoRQFOiFIR4h4qtvpdKrTE Content-Type: multipart/mixed; boundary="Ae5n7VGeqMqm1QfpHnv57KHURQkTRC7A1"; protected-headers="v1" From: "Andrey V. Elsukov" To: Chris H , FreeBSD CURRENT Message-ID: Subject: Re: GEOM has amnesia References: <6b1476532d8534c90a48b8353d9f0db2@ultimatedns.net> In-Reply-To: <6b1476532d8534c90a48b8353d9f0db2@ultimatedns.net> --Ae5n7VGeqMqm1QfpHnv57KHURQkTRC7A1 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 01.04.2017 00:58, Chris H wrote: > So. I spin up an old 11 server I have sitting in the closet, with > this external drive attached to it. I do *NOT* get the corrupt GPT > message. So I blank/partition/newfs the external drive && > mount the partitions individually to /mnt && restore again. When I > reboot to the external drive still connected to the old 11 server, > I do *NOT* receive the corrupt GPT message. WooHoo! I think. > So I re-attach the drive to the new 12 server. Reboot, and can't > boot to it && get the corrupt GPT message. >=20 > GEOM seems to be broken in 12, maybe even (recent) 11. As the 11 > server I used for testing is ~9 mos out. >=20 > What can I do to (help?) fix this mess? Just a guess, BIOS on the system, where FreeBSD 12 is installed overwrites the last sector of your disks. I have seen such reports, and always this was the cause. You can do the following steps to make sure: * on the old 11 system with the sane GPT save the last sector to some fil= e. * reboot, save the sector again to another file and compare both files. * attach the disk to your 12 system, GPT should become corrupted. Save the last sector and compare with previous file. You can look at the hexdump of this file, and probably it should be obviously what is extraneous in the data. To save the last sector you need to know its number, it can be found by this command: # diskinfo da0 | awk '{print $4-1}' Then use dd to save it: # dd if=3D/dev/da0 of=3D./sector skip=3D`diskinfo da0 | awk '{print $4-1= }'` # hexdump -C ./sector You should see something like this: 00000000 45 46 49 20 50 41 52 54 00 00 01 00 5c 00 00 00 |EFI PART....\...| 00000010 d7 b2 b7 bc 00 00 00 00 af 32 cf 1d 00 00 00 00 |.........2......| 00000020 01 00 00 00 00 00 00 00 28 00 00 00 00 00 00 00 |........(.......| 00000030 87 32 cf 1d 00 00 00 00 a0 4a 4a e0 b0 0a e7 11 |.2.......JJ.....| 00000040 ba c4 54 ee 75 ad 8c c7 8f 32 cf 1d 00 00 00 00 |..T.u....2......| 00000050 80 00 00 00 80 00 00 00 22 88 eb 6d 00 00 00 00 |........"..m....| 00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000200 The dump of correct GPT header should not have more lines. --=20 WBR, Andrey V. Elsukov --Ae5n7VGeqMqm1QfpHnv57KHURQkTRC7A1-- --JRqLa4A52BwdoRQFOiFIR4h4qtvpdKrTE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAlje2gcACgkQAcXqBBDI oXrv5QgAqb8MKJqmbZxUFMRMW9MVytMLgk2Eddy9RYxtswgTd5uXe1+1R3beOD+B B/SwRfrvdtFuLG6mMH6tWS7yQOeoWOzIfay95hHD3u2M7xfd11t4BCjVSMCSgH+p oI2TsPo9Mz+DWHDX8lZ82do8mx4DZv3eNF0SYwMMzCjBiU/vMVGIFqkbCxBQGA6h pEvJNZfXgyY02scbrBBbzF/EQmUYwtCmr/7eAM/WhGsSxauC2m9LrC0cllwq5/ED z/fFY20dn2DhfTvv6z8BefwaNch1gul/DGOvzhUliFZXXqaf+1YyU1ycOV2l7X9v CRO8WDGkw7b8aKHIMh9UfI0YF8XL2Q== =QG9o -----END PGP SIGNATURE----- --JRqLa4A52BwdoRQFOiFIR4h4qtvpdKrTE-- From owner-freebsd-current@freebsd.org Fri Mar 31 23:52: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 3BE6BD27F69 for ; Fri, 31 Mar 2017 23:52:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-77.reflexion.net [208.70.210.77]) (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 F3624E9A for ; Fri, 31 Mar 2017 23:52:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5082 invoked from network); 31 Mar 2017 23:52:57 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 31 Mar 2017 23:52:57 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Fri, 31 Mar 2017 19:52:01 -0400 (EDT) Received: (qmail 11760 invoked from network); 31 Mar 2017 23:52:01 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 31 Mar 2017 23:52:01 -0000 Received: from [192.168.1.119] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 718D4EC8FE4; Fri, 31 Mar 2017 16:52:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) From: Mark Millard In-Reply-To: Date: Fri, 31 Mar 2017 16:51:59 -0700 Cc: FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <45E32F4F-A238-47AA-8E1E-7AD4D9E857D9@dsl-only.net> <20170329155316.GK59667@spindle.one-eyed-alien.net> To: Brooks Davis , Dimitry Andric , FreeBSD Ports 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, 31 Mar 2017 23:52:04 -0000 On 2017-Mar-30, at 7:51 PM, Mark Millard wrote: > On 2017-Mar-30, at 1:22 PM, Mark Millard wrote: >=20 >> Sounds like the ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG technique >> would not change the "WITNESS and INVARIANTS"-like part of the >> issue. In fact if WITH_DEBUG=3D causes the cmake debug-style >> llvm40 build ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG might not >> make any difference: separate enforcing of lack of optimization. >>=20 >> But just to see what results I've done "pkg delete llvm40" >> and am doing another build with ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG=3D >> and its supporting code in place in addition to using WITH_DEBUG=3D >> as the type of build fro FreeBSD's viewpoint. >>=20 >> If you know that the test is a waste of machine cycles, you can >> let me know if you want. >=20 > The experiment showed that ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG > use made no difference for devel/llvm40 so devel/llvm40 itself > has to change such as what Dimitry Andric reported separately > as a working change to the Makefile . >=20 > (ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG would still have its uses > for various other ports.) I've now tried with both ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG and: # svnlite diff /usr/ports/devel/llvm40/ Index: /usr/ports/devel/llvm40/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/ports/devel/llvm40/Makefile (revision 436747) +++ /usr/ports/devel/llvm40/Makefile (working copy) @@ -236,6 +236,11 @@ =20 .include =20 +.if defined(WITH_DEBUG) +CMAKE_BUILD_TYPE=3D RelWithDebInfo +STRIP=3D +.endif + _CRTLIBDIR=3D = ${LLVM_PREFIX:S|${PREFIX}/||}/lib/clang/${LLVM_RELEASE}/lib/freebsd .if ${ARCH} =3D=3D "amd64" _COMPILER_RT_LIBS=3D \ pkg delete after the build reports: Installed packages to be REMOVED: llvm40-4.0.0 Number of packages to be removed: 1 The operation will free 42 GiB. So down by 7 GiBytes from 49 GiBytes. (I did not actually delete it.) Also: # du -sg /usr/obj/portswork/usr/ports/devel/llvm40 102 /usr/obj/portswork/usr/ports/devel/llvm40 which is down by 16 GiBytes from 118 GiBytes. Reminder: These are from portmaster -DK so no cleanup after the build, which is what leaves the source code and such around in case of needing to look at a problem. (102+42) GiBytes =3D=3D 146 GiBytes. vs. (118+49) GiBytes =3D=3D 167 GiBytes. So a difference of 21 GiBytes (or so). But that is for everything in each case (and WITH_DEBUG=3D in use): # more /var/db/ports/devel_llvm40/options # This file is auto-generated by 'make config'. # Options for llvm40-4.0.0.r4 _OPTIONS_READ=3Dllvm40-4.0.0.r4 _FILE_COMPLETE_OPTIONS_LIST=3DCLANG DOCS EXTRAS LIT LLD LLDB OPTIONS_FILE_SET+=3DCLANG OPTIONS_FILE_SET+=3DDOCS OPTIONS_FILE_SET+=3DEXTRAS OPTIONS_FILE_SET+=3DLIT OPTIONS_FILE_SET+=3DLLD OPTIONS_FILE_SET+=3DLLDB So avoiding WITH_DEBUG=3D and/or various build options is still the major way of avoiding use of lots of space if it is an issue. Why no RAM+SWAP total report this time: As far as I know FreeBSD does not track or report peak swap-space usage since the last boot. And, unfortunately I was not around to just sit and watch a top display this time and I did not set up any periodic recording into a file. That is why I've not reported on the RAM+SWAP total this time. It will have to be another experiment some other time. [I do wish FreeBSD had a way of reporting peak swap-space usage.] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sat Apr 1 00:09:09 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 3EF6DD2781C for ; Sat, 1 Apr 2017 00:09:09 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 11E15BF7 for ; Sat, 1 Apr 2017 00:09:08 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id v3109vda065281; Fri, 31 Mar 2017 17:10:03 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: FreeBSD CURRENT , "Andrey V. Elsukov" In-Reply-To: References: <6b1476532d8534c90a48b8353d9f0db2@ultimatedns.net>, From: "Chris H" Subject: Re: GEOM has amnesia Date: Fri, 31 Mar 2017 17:10:04 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <4f5583cfe1ebb0edb49efbf0dff3c7d2@ultimatedns.net> Content-Transfer-Encoding: 8bit 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, 01 Apr 2017 00:09:09 -0000 On Sat, 1 Apr 2017 01:36:54 +0300 "Andrey V. Elsukov" wrote > On 01.04.2017 00:58, Chris H wrote: > > So. I spin up an old 11 server I have sitting in the closet, with > > this external drive attached to it. I do *NOT* get the corrupt GPT > > message. So I blank/partition/newfs the external drive && > > mount the partitions individually to /mnt && restore again. When I > > reboot to the external drive still connected to the old 11 server, > > I do *NOT* receive the corrupt GPT message. WooHoo! I think. > > So I re-attach the drive to the new 12 server. Reboot, and can't > > boot to it && get the corrupt GPT message. > > > > GEOM seems to be broken in 12, maybe even (recent) 11. As the 11 > > server I used for testing is ~9 mos out. > > > > What can I do to (help?) fix this mess? > > Just a guess, BIOS on the system, where FreeBSD 12 is installed > overwrites the last sector of your disks. > I have seen such reports, and always this was the cause. > > You can do the following steps to make sure: > * on the old 11 system with the sane GPT save the last sector to some file. > * reboot, save the sector again to another file and compare both files. > * attach the disk to your 12 system, GPT should become corrupted. Save > the last sector and compare with previous file. > > You can look at the hexdump of this file, and probably it should be > obviously what is extraneous in the data. > > To save the last sector you need to know its number, it can be found by > this command: > > # diskinfo da0 | awk '{print $4-1}' > > Then use dd to save it: > > # dd if=/dev/da0 of=./sector skip='diskinfo da0 | awk '{print $4-1}'' > # hexdump -C ./sector > > You should see something like this: > 00000000 45 46 49 20 50 41 52 54 00 00 01 00 5c 00 00 00 |EFI > PART....\...| ... > * > 00000200 > > The dump of correct GPT header should not have more lines. > Andrey, Thank you! OK I'm having trouble with the concept. But *indeed* the output indicates *always* good on the 11 server (confirmed following your steps above). Moving it to the new 12 server, returns corrupt secondary GPT table message && hexdump output is: 00000000 45 46 49 20 50 41 52 54 00 00 01 00 5c 00 00 00 |EFI PART....\...| 00000010 65 12 5c 16 00 00 00 00 2f 60 38 3a 00 00 00 00 |e.\...../`8:....| 00000020 01 00 00 00 00 00 00 00 28 00 00 00 00 00 00 00 |........(.......| 00000030 07 60 38 3a 00 00 00 00 91 e5 f5 c1 0d 16 e7 11 |.`8:............| 00000040 8d 49 00 24 81 ce ba 87 08 60 38 3a 00 00 00 00 |.I.$.....`8:....| 00000050 80 00 00 00 80 00 00 00 00 00 00 00 86 da fa 98 |................| 00000060 61 66 13 80 09 fe d0 54 35 59 db 8e 43 b8 7e 37 |af.....T5Y..C.~7| 00000070 c9 77 0e 9d 35 fd 45 04 de 9a d3 ff 30 83 8f b4 |.w..5.E.....0...| 00000080 b9 84 1d 41 59 44 ef fd fd 89 3e 1e 9e c6 23 e1 |...AYD....>...#.| 00000090 83 17 a7 53 e1 e7 51 c8 5f 87 2b 76 f8 60 c4 ca |...S..Q._.+v.`..| 000000a0 e2 3e 1e eb 12 69 12 32 33 c3 29 42 d6 aa 1a bc |.>...i.23.)B....| 000000b0 90 af fc 4f d0 e1 58 c3 52 f5 5c 54 ca bd 05 8c |...O..X.R.\T....| 000000c0 89 04 8d 7b 11 a3 b2 1e 07 6e fe 1b 79 00 c0 15 |...{.....n..y...| 000000d0 1a 39 79 28 91 a3 e8 24 93 1a 35 ef e9 f8 e5 17 |.9y(...$..5.....| 000000e0 e6 93 f1 a2 5d aa 3e 2f 40 dc b3 17 19 4c f6 05 |....].>/@....L..| 000000f0 cf 75 3e 88 ad a4 2a 68 8c 04 c4 99 a1 bb a2 1c |.u>...*h........| 00000100 9c 8d fe c7 3e e4 cb 56 ce 3d 33 5b 28 a5 c9 45 |....>..V.=3[(..E| 00000110 c7 3f aa e2 1e 98 bc e2 6d 9d 91 12 84 24 d6 13 |.?......m....$..| 00000120 3d b5 14 bd 9a 44 e9 ee 3f b5 91 31 73 86 79 7e |=....D..?..1s.y~| 00000130 09 bd 4e 01 cb 06 81 b4 41 11 cd cf 97 dd 97 a1 |..N.....A.......| 00000140 a7 73 e5 f7 c5 a4 75 c9 1f 6b 5e 88 fe 1a 92 d2 |.s....u..k^.....| 00000150 3a cc 70 21 1f b8 30 34 b9 0e 5c b2 d0 14 5e 82 |:.p!..04..\...^.| 00000160 56 60 04 35 77 c9 25 04 7a af ce e1 8d 24 37 53 |V`.5w.%.z....$7S| 00000170 a3 0c dd 63 3c 15 fe 9f a4 46 00 97 c1 b0 27 be |...c<....F....'.| 00000180 f5 c7 f9 b5 71 9e 1b 90 f7 9c ee 8a 8e 7b 77 61 |....q........{wa| 00000190 23 13 4a 93 0b e0 f0 9e 3f dc 8e 12 f9 19 d3 75 |#.J.....?......u| 000001a0 f2 52 6d bd 12 30 cd bf 0c 91 79 10 1a bd 5b d4 |.Rm..0....y...[.| 000001b0 0f 9c 1b ff 7b 60 74 79 d7 fa bb 02 6f 19 be e4 |....{`ty....o...| 000001c0 06 fd f4 7c cb 05 23 eb 89 2f 7f cc 9b 01 fa f7 |...|..#../......| 000001d0 4c 07 c4 72 55 9f 3d 39 f3 71 64 94 bf 7e 74 b0 |L..rU.=9.qd..~t.| 000001e0 49 80 c1 37 4f 49 91 e0 54 a7 e5 4d 83 8f b8 32 |I..7OI..T..M...2| 000001f0 62 f2 61 50 6f f2 16 05 a4 60 2f 06 be 45 a6 72 |b.aPo....`/..E.r| 00000200 gpart recover da0 && hexdump output from newly captured last sector: 00000000 45 46 49 20 50 41 52 54 00 00 01 00 5c 00 00 00 |EFI PART....\...| 00000010 aa 9c 5f 36 00 00 00 00 2f 60 38 3a 00 00 00 00 |.._6..../`8:....| 00000020 01 00 00 00 00 00 00 00 28 00 00 00 00 00 00 00 |........(.......| 00000030 07 60 38 3a 00 00 00 00 91 e5 f5 c1 0d 16 e7 11 |.`8:............| 00000040 8d 49 00 24 81 ce ba 87 09 60 38 3a 00 00 00 00 |.I.$.....`8:....| 00000050 80 00 00 00 80 00 00 00 65 12 5c 16 00 00 00 00 |........e.\.....| 00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000200 My problem with your theory; 3 reasons I question it 1) The internal SATA3 disk never experiences this 2) When I first plugged in the external drive, it had ghostbsd on it, and the server attempted to boot it w/o error. It wasn't until I blanked/partitioned/newfs'd it, that the trouble(s) manifest 3) This server is brand new hardware and the *only* media that has ever touched this prior to the anomaly was the FreeBSD install DVD (I'm trying to eliminate the possibility of VIRII here). Can you please elaborate on how/why the BIOS should/would modify boot media && only USB boot media? Thank you again, Andrey, for all your input on this! --Chris From owner-freebsd-current@freebsd.org Sat Apr 1 05:56: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 92B69D2C2E6 for ; Sat, 1 Apr 2017 05:56:47 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 6C350FE for ; Sat, 1 Apr 2017 05:56:47 +0000 (UTC) (envelope-from timp87@gmail.com) Received: by mail-pf0-x236.google.com with SMTP id o126so13076338pfb.3 for ; Fri, 31 Mar 2017 22:56:47 -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=hBI/xoUSfNZMnAj/XPXJwtk/9VnMKHeNcx5vrbxJosU=; b=qlUQDZCEXwkRAsBTMd5ZDjDtQo+s+RrLgqn4QKqAE8qxy07Oic+kH10BijKJzQEZUp zpIDGEGK88PSX9cW5YdV7FYZvjLiXNYMSJmvqcgCwd9/rcAhBOnteOa/SUALOmJLSmKk KBnWdLNIWBo41orNR1UZDqYWlvaQ0kbsilNgE+qmWwADjMf96AGvtJ3YQD2EwbDJj/QQ QWyPw5Jpbb0J6XeG+bWcNj3sh75xjeDLOenGlhHbqAhZuTXvOk8VjskXTlghSDmS8rlg UB72ihGmp1FpAp2b9UuV5oDqFeESuGOS0CT3UPg3ZrIrrkZSC4AYAy5bfJvZ5J97HYga xXgA== 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=hBI/xoUSfNZMnAj/XPXJwtk/9VnMKHeNcx5vrbxJosU=; b=qn5rpFvv6QUjsEUINhA5lAfXcEbZ05f42eNRTLNk0M+uqMAL0ki8cY+3Zs22BiAhb9 452qUjLm+IuGzf3I/YAZ1ux9KCEmm8R7MGhCbzQcNpEUm9R2cO/TIKiGH8V6FIJ8t9IF bVib4vVpNcXtB8MGNkn0Q4tEim3M9xdu++utkC/a8QS4fwE4njUm4w4/BO4Rec/8Aj7C qY4BrRlM1BCER8Rx4+ysY3218zf8ZzQRE9OICi0o4s41EmrF0qf1l/tvywB2lf+HbSGg bdpHbdCJVXnfKeuZbJyK1MR+mvA3oBgt3DtQ+SlHKaZFoO176RlGxeC0ganQ00lJhzSw Qr4A== X-Gm-Message-State: AFeK/H1fmyjIqqU9MjiNHSn+S9+D3c6Hcg64A9kP02jMTZvxHoAKEiRh3s/rVE5cjs46Ol3s1P6L+xqiFZ8zKA== X-Received: by 10.84.215.213 with SMTP id g21mr7398834plj.159.1491026206538; Fri, 31 Mar 2017 22:56:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.183.34 with HTTP; Fri, 31 Mar 2017 22:56:45 -0700 (PDT) Received: by 10.100.183.34 with HTTP; Fri, 31 Mar 2017 22:56:45 -0700 (PDT) In-Reply-To: References: <0136F3BE-4B47-4677-8D81-3FE0F5E67E79@lists.zabbadoz.net> From: Pavel Timofeev Date: Sat, 1 Apr 2017 08:56:45 +0300 Message-ID: Subject: Re: VNET branch destiny To: "Bjoern A. Zeeb" Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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, 01 Apr 2017 05:56:47 -0000 31 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2017 =D0=B3. 17:40 =D0=BF=D0=BE=D0=BB=D1= =8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C "Bjoern A. Zeeb" < bzeeb-lists@lists.zabbadoz.net> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: On 31 Mar 2017, at 13:57, Pavel Timofeev wrote: Hello, dear freebsd-current@! > > There was FreeBSD Foundation report back in 2016Q2 where it told us > about VNET (VIMAGE) update project sponsored by foundation. > What is the current situation? Is it committed into base? If not > what's the plan? > Changes are in 12 and 11. 12 has seen more slight fixes due to other changes that other committers are tracking and I hope they merge to 11. /bz Thanks a lot for the reply! From owner-freebsd-current@freebsd.org Sat Apr 1 10:51: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 807A6D2915E for ; Sat, 1 Apr 2017 10:51:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-78.reflexion.net [208.70.210.78]) (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 3CC2E323 for ; Sat, 1 Apr 2017 10:51:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9513 invoked from network); 1 Apr 2017 10:51:11 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 1 Apr 2017 10:51:11 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sat, 01 Apr 2017 06:51:11 -0400 (EDT) Received: (qmail 23165 invoked from network); 1 Apr 2017 10:51:11 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 1 Apr 2017 10:51:11 -0000 Received: from [192.168.1.119] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 97D6FEC8630; Sat, 1 Apr 2017 03:51:10 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) From: Mark Millard In-Reply-To: Date: Sat, 1 Apr 2017 03:51:10 -0700 Cc: FreeBSD Current , FreeBSD PowerPC ML , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <45E32F4F-A238-47AA-8E1E-7AD4D9E857D9@dsl-only.net> <20170329155316.GK59667@spindle.one-eyed-alien.net> To: Brooks Davis , Dimitry Andric , FreeBSD Ports 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, 01 Apr 2017 10:51:14 -0000 On 2017-Mar-31, at 4:51 PM, Mark Millard wrote: > On 2017-Mar-30, at 7:51 PM, Mark Millard = wrote: >=20 >> On 2017-Mar-30, at 1:22 PM, Mark Millard = wrote: >>=20 >>> Sounds like the ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG technique >>> would not change the "WITNESS and INVARIANTS"-like part of the >>> issue. In fact if WITH_DEBUG=3D causes the cmake debug-style >>> llvm40 build ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG might not >>> make any difference: separate enforcing of lack of optimization. >>>=20 >>> But just to see what results I've done "pkg delete llvm40" >>> and am doing another build with ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG=3D >>> and its supporting code in place in addition to using WITH_DEBUG=3D >>> as the type of build fro FreeBSD's viewpoint. >>>=20 >>> If you know that the test is a waste of machine cycles, you can >>> let me know if you want. >>=20 >> The experiment showed that ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG >> use made no difference for devel/llvm40 so devel/llvm40 itself >> has to change such as what Dimitry Andric reported separately >> as a working change to the Makefile . >>=20 >> (ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG would still have its uses >> for various other ports.) >=20 > I've now tried with both ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG and: I may have had a textual error that prevented ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG from even potentially contributing. So I'll re-run this test. For now I presume that what I reported was okay and so I continue to refer to these figures later below. > # svnlite diff /usr/ports/devel/llvm40/ > Index: /usr/ports/devel/llvm40/Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/ports/devel/llvm40/Makefile (revision 436747) > +++ /usr/ports/devel/llvm40/Makefile (working copy) > @@ -236,6 +236,11 @@ >=20 > .include >=20 > +.if defined(WITH_DEBUG) > +CMAKE_BUILD_TYPE=3D RelWithDebInfo > +STRIP=3D > +.endif > + > _CRTLIBDIR=3D = ${LLVM_PREFIX:S|${PREFIX}/||}/lib/clang/${LLVM_RELEASE}/lib/freebsd > .if ${ARCH} =3D=3D "amd64" > _COMPILER_RT_LIBS=3D \ >=20 >=20 >=20 > pkg delete after the build reports: >=20 > Installed packages to be REMOVED: > llvm40-4.0.0 >=20 > Number of packages to be removed: 1 >=20 > The operation will free 42 GiB. >=20 > So down by 7 GiBytes from 49 GiBytes. >=20 > (I did not actually delete it.) >=20 > Also: >=20 > # du -sg /usr/obj/portswork/usr/ports/devel/llvm40 > 102 /usr/obj/portswork/usr/ports/devel/llvm40 >=20 > which is down by 16 GiBytes from 118 GiBytes. >=20 > Reminder: These are from portmaster -DK so no > cleanup after the build, which is what leaves > the source code and such around in case of > needing to look at a problem. >=20 > (102+42) GiBytes =3D=3D 146 GiBytes. > vs. > (118+49) GiBytes =3D=3D 167 GiBytes. >=20 > So a difference of 21 GiBytes (or so). >=20 > But that is for everything in each case (and > WITH_DEBUG=3D in use): >=20 > # more /var/db/ports/devel_llvm40/options > # This file is auto-generated by 'make config'. > # Options for llvm40-4.0.0.r4 > _OPTIONS_READ=3Dllvm40-4.0.0.r4 > _FILE_COMPLETE_OPTIONS_LIST=3DCLANG DOCS EXTRAS LIT LLD LLDB > OPTIONS_FILE_SET+=3DCLANG > OPTIONS_FILE_SET+=3DDOCS > OPTIONS_FILE_SET+=3DEXTRAS > OPTIONS_FILE_SET+=3DLIT > OPTIONS_FILE_SET+=3DLLD > OPTIONS_FILE_SET+=3DLLDB >=20 > So avoiding WITH_DEBUG=3D and/or various build options > is still the major way of avoiding use of lots of space > if it is an issue. >=20 >=20 >=20 > Why no RAM+SWAP total report this time: >=20 > As far as I know FreeBSD does not track or report peak > swap-space usage since the last boot. And, unfortunately > I was not around to just sit and watch a top display this > time and I did not set up any periodic recording into a > file. >=20 > That is why I've not reported on the RAM+SWAP total > this time. It will have to be another experiment > some other time. >=20 > [I do wish FreeBSD had a way of reporting peak swap-space > usage.] I've also tried without WITH_DEBUG=3D and now. . . # pkg delete llvm40 Checking integrity... done (0 conflicting) Deinstallation has been requested for the following 1 packages (of 0 = packages in the universe): Installed packages to be REMOVED: llvm40-4.0.0 Number of packages to be removed: 1 The operation will free 1 GiB. Proceed with deinstalling packages? [y/N]: n # du -sg /usr/obj/portswork/usr/ports/devel/llvm40/ 5 /usr/obj/portswork/usr/ports/devel/llvm40/ So the alternatives (with everything built each time): (5+1) GiBytes =3D=3D 6 GiBytes. (without WITH_DEBUG=3D) vs. (102+42) GiBytes =3D=3D 146 GiBytes. (WITH_DEBUG=3D but the adjusted = llvm40/Makefiele) vs. (118+49) GiBytes =3D=3D 167 GiBytes. (WITH_DEBUG=3D with Makefile = adjustment) I'll likely end up having /etc/make.conf contain something like the following for most or all of my FreeBSD environments: # # =46rom a local /usr/ports/Mk/bsd.port.mk extension: ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG=3D # .if ${.CURDIR:M*/devel/llvm*} #WITH_DEBUG=3D .else WITH_DEBUG=3D .endif WITH_DEBUG_FILES=3D Along with using: # svnlite diff /usr/ports/Mk/ Index: /usr/ports/Mk/bsd.port.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/ports/Mk/bsd.port.mk (revision 436747) +++ /usr/ports/Mk/bsd.port.mk (working copy) @@ -1646,7 +1646,11 @@ STRIP_CMD=3D ${TRUE} .endif DEBUG_FLAGS?=3D -g +.if defined(ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG) +CFLAGS:=3D ${CFLAGS} ${DEBUG_FLAGS} +.else CFLAGS:=3D ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS} +.endif .if defined(INSTALL_TARGET) INSTALL_TARGET:=3D ${INSTALL_TARGET:S/^install-strip$/install/g} .endif [Although apparently the ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG use has no effect for devel/llvm40 .] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sat Apr 1 17:28:18 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 56BBAD290BF for ; Sat, 1 Apr 2017 17:28:18 +0000 (UTC) (envelope-from luzar722@gmail.com) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 1C6F03AF for ; Sat, 1 Apr 2017 17:28:18 +0000 (UTC) (envelope-from luzar722@gmail.com) Received: by mail-it0-x22a.google.com with SMTP id y18so26134993itc.1 for ; Sat, 01 Apr 2017 10:28:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-transfer-encoding; bh=y7w0A1tww2LyGg9F6bhlG+n+eVSPHnnadz7NFSvf3dk=; b=a/4mJCagKKR/Qms6ai8WJ+CPGScXVu09xhxANJtxFS2RREBVu2BSDEsz+Ea+da8V8Q rQzgldkLE6900fYCBCeC7HLQwlrpRZ1RuQpTTKbp1Ktrupuu1LpTKymkBqKYGUBphe6Q v2GIIQrfzuRzoymhor+0+stWEQzEhsxMNzFXDwbz/gwmTrM+T8nn4m3jmpXIoYVl0Ady Tcfc0Vcsn+HI6pXpkefjQmYctGeNBBc1zGYCkwymLtdiJW+d7LWdVjGmyn8HyPbUK1Vd udsYRzZfW6tXzYwqMbOa7d5pq9rg6Ap4y314BU52xaQqzBdqrBF/XLKJYM+q8WRB4xeI zj/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-transfer-encoding; bh=y7w0A1tww2LyGg9F6bhlG+n+eVSPHnnadz7NFSvf3dk=; b=Yd6Kn3dDAVmNOsmFvLs62MxgLsNxvO25xkgL4iHAdCcDvytlPwrc43AzjobFGszq9J CpEoiAvYG45f6LRLH498i471rOsy205lGMNAOndFlHqMkDR6H0Rj8E8o0S+mBd9zsbZR /XbGxyvUPm2PyVSmwpAvmptZxCq8XOqo79xZhPNfzETLlrLNQEwhReYm1PvQ4tFQ/kJS HsNupJF7on8PVhJeSziWG8LBdvAOAN6Q+qkJQwi5NU9ogy47wdz6AfnwE7kgvsY2MFKk esBziB9ew4nrkEmLW1Owm/NRMGF1ZQJcmM45CUksEnid2iqRwy0ONnN8oi+G24pf2WbD trag== X-Gm-Message-State: AFeK/H2q3Lh3cn+h5D4L32UVZcrgvakTKyAbX7veNmnYC4/+4nm2r4dGJyGm+egOeubMNA== X-Received: by 10.36.213.3 with SMTP id a3mr3611428itg.106.1491067697273; Sat, 01 Apr 2017 10:28:17 -0700 (PDT) Received: from [10.0.10.3] (cpe-74-141-88-57.neo.res.rr.com. [74.141.88.57]) by smtp.googlemail.com with ESMTPSA id x26sm5070677ioi.5.2017.04.01.10.28.16 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 01 Apr 2017 10:28:16 -0700 (PDT) Message-ID: <58DFE332.2030107@gmail.com> Date: Sat, 01 Apr 2017 13:28:18 -0400 From: Ernie Luzar User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: freebsd-current Subject: vt(4) bugs needing attention References: <0136F3BE-4B47-4677-8D81-3FE0F5E67E79@lists.zabbadoz.net> In-Reply-To: <0136F3BE-4B47-4677-8D81-3FE0F5E67E79@lists.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 01 Apr 2017 17:28:18 -0000 Is anyone working the these outstanding vt(4) bug reports? Bug 210431 - vt(4) copy/paste mode does not work in hw.vga.textmode=1 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210431 Bug 210432 - vt(4) does not support boot time splash screen https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210432 Bug 210446 - vt(4) when switching between virtual consoles there is a 4 second hesitation in graph mode. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210446 Are fixes for these going to be in 11.1 release?