From owner-freebsd-current@freebsd.org Sun May 14 01:12: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 D41C7D6124D for ; Sun, 14 May 2017 01:12:14 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660053.outbound.protection.outlook.com [40.107.66.53]) (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 839596EB for ; Sun, 14 May 2017 01:12:13 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0190.CANPRD01.PROD.OUTLOOK.COM (10.165.218.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.16; Sun, 14 May 2017 01:12:11 +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.1084.026; Sun, 14 May 2017 01:12:11 +0000 From: Rick Macklem To: Slawa Olhovchenkov CC: "freebsd-current@freebsd.org" Subject: Re: more default uid/gid for NFS in mountd Thread-Topic: more default uid/gid for NFS in mountd Thread-Index: AQHSx++rThRkes9J306I64SeGCJfAKHqceCAgAiaBnc= Date: Sun, 14 May 2017 01:12:11 +0000 Message-ID: References: , <20170508134203.GA3165@zxy.spb.ru> In-Reply-To: <20170508134203.GA3165@zxy.spb.ru> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTXPR01MB0190; 7:c7lGQIUUtDds4YYYulpKMxooeGL/je+pR8Jhr1xBRsNZrmGcfhMlWB71NrSoh9WnQTEI8c9XFG75aBrVAttDaQS+YhOfprhL2RYwvGeycnJjUDKUfvLuKumm49u7qVOAaOSWg2LSWceLexmkj7yOi9RHlpetwyCcnvF79a70vYXd8dzg7YfabJDFG93h3H7KiYCncOUSCH2GAa0rOEKD59043R49vZ5nuTgI42GRaT5o5MQpI6F898FbudlLKtMcilZmWyn7j33jDjwN62FizRQe4rqV8ZQel7hRpxrnKtEjEl4KcxrnayJYaOepi1RKLhemMk0MljEY846uwcXCbA== x-ms-office365-filtering-correlation-id: 8b74b717-58b0-4664-6781-08d49a663fdf x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:YTXPR01MB0190; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123558100)(20161123560025)(20161123564025)(6072148); SRVR:YTXPR01MB0190; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0190; x-forefront-prvs: 03077579FF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39840400002)(39400400002)(39450400003)(39850400002)(51914003)(24454002)(2900100001)(305945005)(25786009)(74316002)(3660700001)(4326008)(3280700002)(2906002)(8676002)(81166006)(74482002)(122556002)(54356999)(76176999)(50986999)(33656002)(86362001)(551544002)(7696004)(8936002)(6506006)(189998001)(110136004)(6436002)(229853002)(6246003)(38730400002)(2950100002)(6916009)(77096006)(53936002)(102836003)(55016002)(5660300001)(9686003)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0190; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:sfv; 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: 14 May 2017 01:12:11.4248 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0190 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, 14 May 2017 01:12:14 -0000 Slawa Olhovchenkov wrote: >Rick Macklem wrote: >> Hi, >> >> Five years ago (yea, it slipped through a crack;-), Slawa reported that = files >> created by root would end up owned by uid 2**32-2 (-2 as uint32_t). >> This happens if there is no "-maproot=3D" in the /etc/exports line= . >> >> The cause is obvious. The value is set to -2 by default. >> >> The question is... Should this be changed to 65534 (ie "nobody")? >> - It would seem more consistent to make it the uid of nobody, but I can = also see >> the argument that since it has been like this *forever*, that changing= it would be >> a POLA violation. >> What do others think? > >IMHO uid 2**32-2 is POLA violation. >Nobody expect this uid. Too much number. This is like bug. This is what I have just committed. Thanks for the comments. >> It is also the case that mountd.c doesn't look "nobody" up in the passwo= rd database >> to set the default. It would be nice to do this, but it could result in = the mountd daemon >> getting "stuck" during a boot waiting for an unresponsive LDAP service o= r similar. >> Does doing this sound like a good idea? > >This is (stuck at boot) already do for case of using NIS and nfsuserd. There is a difference here. nfsuserd mpas between uid/names, so it can't wo= rk without the password database. mountd can work without the password database, so I held off on doing this = for now. >I am regular see this for case of DNS failed at boot. >You offer don't impair current behaviour. As an aside, if you have the critical entries in the local files (/etc/host= s, /etc/passwd, /etc/group) and then tell the libraries to search these first in /etc/nsswi= tch.conf, then you usually avoid this problem. Thanks for the comments, rick From owner-freebsd-current@freebsd.org Sun May 14 07:11: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 C5F14D6C600 for ; Sun, 14 May 2017 07:11:18 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 839DBE19 for ; Sun, 14 May 2017 07:11:18 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1d9ngK-0005vU-Cu; Sun, 14 May 2017 10:11:08 +0300 Date: Sun, 14 May 2017 10:11:08 +0300 From: Slawa Olhovchenkov To: Rick Macklem Cc: "freebsd-current@freebsd.org" Subject: Re: more default uid/gid for NFS in mountd Message-ID: <20170514071108.GK1188@zxy.spb.ru> References: <20170508134203.GA3165@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-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, 14 May 2017 07:11:18 -0000 On Sun, May 14, 2017 at 01:12:11AM +0000, Rick Macklem wrote: > >> It is also the case that mountd.c doesn't look "nobody" up in the password database > >> to set the default. It would be nice to do this, but it could result in the mountd daemon > >> getting "stuck" during a boot waiting for an unresponsive LDAP service or similar. > >> Does doing this sound like a good idea? > > > >This is (stuck at boot) already do for case of using NIS and nfsuserd. > There is a difference here. nfsuserd mpas between uid/names, so it can't work > without the password database. > mountd can work without the password database, so I held off on doing this for now. > > >I am regular see this for case of DNS failed at boot. > >You offer don't impair current behaviour. > As an aside, if you have the critical entries in the local files (/etc/hosts, /etc/passwd, > /etc/group) and then tell the libraries to search these first in /etc/nsswitch.conf, then > you usually avoid this problem. Same as for 'nobody' for mountd? > Thanks for the comments, rick > Thanks! From owner-freebsd-current@freebsd.org Sun May 14 07:41:33 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 7496DD6CD4B for ; Sun, 14 May 2017 07:41:33 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (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 144A31E55; Sun, 14 May 2017 07:41:32 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from fortune.joker.local (124-18-21-125.dz.commufa.jp [124.18.21.125]) (authenticated bits=0) by dec.sakura.ne.jp (8.15.2/8.15.2/[SAKURA-WEB]/20080708) with ESMTPA id v4E73tfC081724; Sun, 14 May 2017 16:03:55 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sun, 14 May 2017 16:03:55 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Cc: bapt@FreeBSD.org, alexander@wittig.name Subject: ports-mgmt/pkg_rmleaves stops working properly on -head after bsdiff became default diff (r317209) Message-Id: <20170514160355.5da31fb2f3c8a163e024acdf@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Sun__14_May_2017_16_03_55_+0900_4PmVibRYbPkIk1b_" 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, 14 May 2017 07:41:33 -0000 This is a multi-part message in MIME format. --Multipart=_Sun__14_May_2017_16_03_55_+0900_4PmVibRYbPkIk1b_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi. Posting on freebsd-current as this only affects -head. I recently noticed ports-mgmt/pkg_rmleaves failes to process new leaf ports after removal of leaf ports on -head with error messages below. > diff: unrecognized option `--unchanged-line-format=' > usage: diff [-abdilpTtw] [-c | -e | -f | -n | -q | -u] [--ignore-case] > [--no-ignore-case] [--normal] [--strip-trailing-cr] > [--tabsize] [-I pattern] [-L label] file1 file2 > diff [-abdilpTtw] [-I pattern] [-L label] [--ignore-case] > [--no-ignore-case] [--normal] [--strip-trailing-cr] > [--tabsize] -C number file1 file2 > diff [-abdiltw] [-I pattern] [--ignore-case] [--no-ignore-case] > [--normal] [--strip-trailing-cr] [--tabsize] -D string > file1 file2 diff [-abdilpTtw] [-I pattern] [-L label] [--ignore-case] > [--no-ignore-case] [--normal] [--tabsize] > [--strip-trailing-cr] -U number file1 file2 > diff [-abdilNPprsTtw] [-c | -e | -f | -n | -q | -u] > [--ignore-case] [--no-ignore-case] [--normal] [--tabsize] [-I pattern] > [-L label] [-S name] [-X file] [-x pattern] dir1 dir2 stable/11 was OK, and the difference is that stable/11 has gnu diff as diff, while -head has bsdiff as diff. There's 2 (or possibly 3) options. a) Let pkg_rmleaves use gnu diff via textprocs/diffutils. This is easiest (Minimal diff is attached), but doesn't help any other ports affected. Just change diff to gdiff and RUN_DEPENDS on textproc/diffutils. b) Update bsdiff to support missing options below. This is over my hand, but if possible, would help others. c) If the missing options below are implemented as different (non-documented) options on bsdiff, use them for bsdiff instead. Will need OSVERSION check in ports Makefile. Please note that attached diff is really MINIMAL to work on -head. No OSVERSION switching is implemented and no bumps so forcibly installs textproc/diffutils on revisions with gnu diff is /usr/bin/diff. And patch wouldn't work properly as files directory doesn't exist in pkg-mgmt/pkg_rmleaves. (At least system patch.) I wonder which option should be taken, so not yet filed PR on bugzilla. It should be filed differently with which option is taken. -- Tomoaki AOKI --Multipart=_Sun__14_May_2017_16_03_55_+0900_4PmVibRYbPkIk1b_ Content-Type: text/x-diff; name="pkg_rmleaves.diff" Content-Disposition: attachment; filename="pkg_rmleaves.diff" Content-Transfer-Encoding: 7bit diff -u -r -P -p ports-mgmt/pkg_rmleaves/Makefile.orig ports-mgmt/pkg_rmleaves/Makefile --- ports-mgmt/pkg_rmleaves/Makefile.orig 2015-09-09 02:00:03.629555000 +0900 +++ ports-mgmt/pkg_rmleaves/Makefile 2017-05-14 02:20:31.547549000 +0900 @@ -13,6 +13,8 @@ LICENSE= BSD2CLAUSE NO_BUILD= yes +RUN_DEPENDS= gdiff:textproc/diffutils + WRKSRC= ${WRKDIR} PLIST_FILES= sbin/pkg_rmleaves man/man1/pkg_rmleaves.1.gz diff -u -r -P -p ports-mgmt/pkg_rmleaves/files/patch-pkg_rmleaves.orig ports-mgmt/pkg_rmleaves/files/patch-pkg_rmleaves --- ports-mgmt/pkg_rmleaves/files/patch-pkg_rmleaves.orig 1970-01-01 09:00:00.000000000 +0900 +++ ports-mgmt/pkg_rmleaves/files/patch-pkg_rmleaves 2017-05-14 02:22:57.050609000 +0900 @@ -0,0 +1,11 @@ +--- pkg_rmleaves.orig 2014-02-22 21:21:47.000000000 +0900 ++++ pkg_rmleaves 2017-05-14 02:16:55.751443000 +0900 +@@ -74,7 +74,7 @@ checkLeafs() { + fi | sort | sed -e "y/\"/'/" -e 's/#"#/"/g' > "$PKGFILE" + + if [ -f "$PREV" ]; then +- diff --unchanged-line-format='' --old-line-format='' --new-line-format='%L' "$PREV" "$PKGFILE" > "$TMPFILE" ++ gdiff --unchanged-line-format='' --old-line-format='' --new-line-format='%L' "$PREV" "$PKGFILE" > "$TMPFILE" + else + cp "$PKGFILE" "$TMPFILE" + fi --Multipart=_Sun__14_May_2017_16_03_55_+0900_4PmVibRYbPkIk1b_-- From owner-freebsd-current@freebsd.org Sun May 14 10:43:03 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 ECF42D6C4F6 for ; Sun, 14 May 2017 10:43:03 +0000 (UTC) (envelope-from bugzilla-noreply@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 D656219F3 for ; Sun, 14 May 2017 10:43:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id D28A8D6C4F4; Sun, 14 May 2017 10:43:03 +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 D2315D6C4F2 for ; Sun, 14 May 2017 10:43:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 C1E6019F2 for ; Sun, 14 May 2017 10:43:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4EAgxU6078504 for ; Sun, 14 May 2017 10:43:03 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: current@FreeBSD.org Subject: [Bug 218849] Remove rc.conf jail configuration via jail_* variables Date: Sun, 14 May 2017 10:43:00 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: conf X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: thomas@gibfest.dk X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: mfc-stable9- mfc-stable10- mfc-stable11- X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 14 May 2017 11:29:58 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 10:43:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218849 Thomas Steen Rasmussen / Tykling changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |thomas@gibfest.dk --- Comment #25 from Thomas Steen Rasmussen / Tykling -= -- I believe the only reason the original poster insists on removing this now = is to deliberately break ezjail, so people will switch to his qjail tool rather than stay with ezjail. Obviously this kind of behaviour does not belong her= e. _Please_ keep the compatibility code in place until something else has been sorted. To solve ezjails problem of jail.conf being difficult to manage from sh scr= ipts erdgeist (ezjail author) offered to extend jail(8) with config file managem= ent capabilities earlier in this thread. I do suggest we take him up on the off= er. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-current@freebsd.org Sun May 14 14:53: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 33A82D6C473 for ; Sun, 14 May 2017 14:53:25 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward14p.cmail.yandex.net (forward14p.cmail.yandex.net [IPv6:2a02:6b8:0:1465::be]) (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 E64CD1165 for ; Sun, 14 May 2017 14:53:24 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from smtp3j.mail.yandex.net (smtp3j.mail.yandex.net [IPv6:2a02:6b8:0:801:1::12]) by forward14p.cmail.yandex.net (Yandex) with ESMTP id 6FC3C20E20 for ; Sun, 14 May 2017 17:53:13 +0300 (MSK) Received: from smtp3j.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp3j.mail.yandex.net (Yandex) with ESMTP id 49BE36240E2E for ; Sun, 14 May 2017 17:53:12 +0300 (MSK) Received: by smtp3j.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id ZUPmi9Bgsf-rCf4693i; Sun, 14 May 2017 17:53:12 +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=passap.ru; s=mail; t=1494773592; bh=GRQrk2lHEL9TGIm5pruHvSlCubR0LVgfwDiwjyJbhqs=; h=To:From:Subject:Message-ID:Date; b=gVPypDRmzPBaST6WZhm569F/Uo01IcKUznby5GcMH4lAe0YtSlBHuc+9ndlmtb9PQ enazOH8LxbujNVqjTNn6aWtz3MxVBWGZRQAodShNH/OgKZzFlG0CGT4zvO5vcknFiR lU0qYQlR0H9XoNev6jkrHUne31O1tEwpTb+so2BU= Authentication-Results: smtp3j.mail.yandex.net; dkim=pass header.i=@passap.ru X-Yandex-Suid-Status: 1 0 To: freebsd-current@FreeBSD.org From: Boris Samorodov Subject: misc/mc, diff and compare two files Message-ID: Date: Sun, 14 May 2017 17:53:22 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: ru-RU 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: Sun, 14 May 2017 14:53:25 -0000 Hi All, FYI: For those who use FreeBSD-HEAD, misc/mc and it's awesome "compare two files" feature: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219277 HTH -- WBR, bsam From owner-freebsd-current@freebsd.org Sun May 14 17:46:22 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 98F41D6D2BB; Sun, 14 May 2017 17:46:22 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [5.135.182.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 37C1F1C5F; Sun, 14 May 2017 17:46:21 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=2001:41d0:8:bdbe:1:1::; helo=restart.be; envelope-from=hlh@restart.be; receiver=freebsd-arm@freebsd.org DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 3wQrjf2sRNzsMS DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=restart.be; s=tignes; t=1494783974; bh=ZkdTVxlzKG3GivQ1EXI1AI+/4d8yMYD1l66HlJAIYHQ=; h=Subject:From:To:Cc:References:Date:In-Reply-To; z=Subject:=20Re:=20DTB=20provided=20by=20loader.efi=20from=20head=2 0-r317181=20on=20pine64=20smashed=0D=0A=20by=20zfs.ko=20?|From:=20 Henri=20Hennebert=20|To:=20freebsd-arm=20|Cc:=20freebsd-current=20|References:=20<818a6074-7d4b-a87e-d89e-ce1f4a30ff3c@restart.b e>|Date:=20Sun,=2014=20May=202017=2019:46:12=20+0200|In-Reply-To:= 20<818a6074-7d4b-a87e-d89e-ce1f4a30ff3c@restart.be>; b=uzNACtSavxOAGZyTh2jbP6if6lNKQOlq3RPyWOnq+LS1jGHeKZVZ/EIA9ij/iN2mP s1u+vzMMLRKJlllFTzI37nZWanTdKsc07IbbEqyqi/SmURFTQoYIehjm/ja3p2BwNz tnTk2zxXkMQTAz2GtZp1LcoxbquRVU8E9oT6DH6VC99DRY9mPYWLItQ4EoVpJgsKMH gBzi7l9ZTlZ7a9YJdjm8P4pUcetSa8+ZVtE216Go3IqGUR2QOINlsxATAgW1rXiGmD p4ldiwvrTbiji/5niQdsM/XYrZy8AwkWaoTrDN07YaMB2kteBeJPg3+Sl+DTfZlC8e WE1ZZ9tdWfTlw== Received: from restart.be (avoriaz.restart.be [IPv6:2001:41d0:8:bdbe:1:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3wQrjf2sRNzsMS; Sun, 14 May 2017 19:46:13 +0200 (CEST) Received: from chamonix.restart.bel (chamonix.restart.bel [IPv6:2001:41d0:8:bdbe:1:9:0:0]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id v4EHkC60057607 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 14 May 2017 19:46:13 +0200 (CEST) (envelope-from hlh@restart.be) Subject: Re: DTB provided by loader.efi from head -r317181 on pine64 smashed by zfs.ko ? From: Henri Hennebert To: freebsd-arm Cc: freebsd-current References: <818a6074-7d4b-a87e-d89e-ce1f4a30ff3c@restart.be> Message-ID: <6877ef26-1c40-7883-70c4-5fbb37c4b3db@restart.be> Date: Sun, 14 May 2017 19:46:12 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <818a6074-7d4b-a87e-d89e-ce1f4a30ff3c@restart.be> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr-classic 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: Sun, 14 May 2017 17:46:22 -0000 On 05/09/2017 12:07, Henri Hennebert wrote: > Hello, > > I build current -r317181 with crochet for my PINE64. > > the kernel can boot with loader.conf.local: > > geom_mirror_load="YES" > > If I add to loader.conf.local: > > zfs_load="YES" > > or if I strike the space bar during loader.efi and I load zfs manually: > > OK load zfs > ... > OK boot With a slimmed down kernel config, I can load zfs.ko and boot the kernel BUT opensolaris is not loaded and I get at kernel boot: OK load zfs /boot/kernel/zfs.ko text=0x9d980 text=0xe0480 data=0x214c8+0x9eb78 syms=[0x8+0x1d6a0+0x8+0x187bd] OK boot Booting... KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2017 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT #0 r317181M: Sun May 14 14:01:52 CEST 2017 root@norquay.restart.bel:/usr/obj/usr/src/sys/NORQUAY arm64 FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) VT: init without driver. KLD file zfs.ko is missing dependencies Starting CPU 1 (1) Starting CPU 2 (2) Starting CPU 3 (3) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs random: unblocking device. note the message: KLD file zfs.ko is missing dependencies > > the kernel don't boot and the console stay with the last line: > > Using DTB provided by EFI at 0x49000000. > > Moreover the opensolaris.ko is not loader. > > Maybe DTB is smashed by zfs.ko > > Any idea ? > > Henri > > PS with r312006M from RaspBSD all is OK and I can user zfs as root > filesystem. > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Sun May 14 18:44:22 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 13C95D6C77C for ; Sun, 14 May 2017 18:44:22 +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 700251F29 for ; Sun, 14 May 2017 18:44:20 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.52.68.13]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MB1C4-1dJpqy1M3Q-009x6H for ; Sun, 14 May 2017 20:44:12 +0200 Date: Sun, 14 May 2017 20:44:04 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: Mplayer on CURRENT: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" Message-ID: <20170514204404.42cc5d3c@thor.intern.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/m12CRUofrnYDiRnD5yLLo=6"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:BS2YjiWHBkjwBV1Xd6Q9CtC+zFbud7/+pcqJ1wZN13D1YS6V79h a3eh359Y1T4jP7o0DgLSA4IQzDLuCGxemFQwjP5a6OZWBBMPJHASdt+0AQr/RXD4iSDWpvk lFURp824zqpHD6/wOrQZ4Jn8S0du/Iq2dDEk7dIajzb74ugYlXF9fD56CDCoBP7xuAg0uJU TLmMoEJ8wo1p6V4PYrFKQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:y0MvQchmApQ=:Iz3vpe7cdyxkm/KYVpLbM9 9J2T9htJtcjJIR/OiVxbwtabqjHZpGE+CHCAa5eiBGjPN3rTdXLV+EF9NK24ijeX2MIJHDT8c rRF+Qn/Qyun0ODL63mhpUuuUpy8zrltmAHbaiB/CsDssO880ICBPZY2gnyAIKouqHLu0JKYSa 7SxUxEe1iTa+Md+0erb2H4nZzbhLh5yhprBq+DPBCZdVjDkGjBHzR5WFs+4EPDZDLWGXlQAxo tvomyTQ6anJy9N5YeplIQ+50mF63k+Z3kAu6D8LbTA+DYYXY3I1sF/J+ftmVRHyv6XyVzqHQx hO6Vl915pyJQMIXE8+AvCk13af4Fioqr3Wkv/SYhus5K+4bzn0l7FD2cedydzrkV+UZEoQECm KENAA3Od5e+6WO5u//OXnAempnImHgMfPfHSl9d32vzO24QPM+AHttp5LirjtSzMiTflSeuCe ImFKMPFosR3xFGhKr0kNYbtYET0ifIvp/jcFQoYKwpq9DPlRSGZ/INM/BRrdhbNSmrggqqnGW NaisHjXb0E2BB5iMEFTR8xmIDTKka366yVpgVYPtrS0/zBgykmv6OZPWns4UEQbZsUuuVxnAw WsVMc/tkAXBRiOk4eche2yPkOeL+ZfjQyknNvpOBQHAhCBTABZZj152ugRMB6VkTOJPmG7L7J nR5jjRuJTBLETZrBhorcFfxydr/qKJqcpnYf4GgWTUAb0JwRBtptr73x2mSwcVgWApwKP7VX3 4EBKeeTooVKtimdFIKggOFlYC+Pci6TCYwLRFMxIkBvZ/B08jRD2B2GUlW0= 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, 14 May 2017 18:44:22 -0000 --Sig_/m12CRUofrnYDiRnD5yLLo=6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On recent CURRENT, FreeBSD 12.0-CURRENT #82 r318277: Sun May 14 19:34:54 CE= ST 2017 amd64, with WITH_LLD_IS_LD=3Dyes set, mplayer rejects to work and fails to start and quits immediately with: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" I already tried to recompile mplayer with "portmaster -df" to hit all ports= required or especially recompiled libglib-2.0, but without success. Its strange ... Is there any hint? Kind regards and thanks in advance, O. Hartmann --=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_/m12CRUofrnYDiRnD5yLLo=6 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWRildQAKCRDS528fyFhY lDncAgCMaNZQBubcnS+S0f6N7xVvrGzCyjnuGQlDp9JLbnC8IDe2knKMbpnnB2Ca EKGTado0ekWGoP/NkyQLJWGTVZ6iAgCjpB7yzj8VeM9wuryG2W73wagwdeGhtwsy +Dyp9PkMYntAKo6TgSMC0n0g163H0wZKAGZWnuDw6zs1PRgIlYuR =1FPm -----END PGP SIGNATURE----- --Sig_/m12CRUofrnYDiRnD5yLLo=6-- From owner-freebsd-current@freebsd.org Sun May 14 19:30:12 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0BF1DD6DA90 for ; Sun, 14 May 2017 19:30:12 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 915EC85B; Sun, 14 May 2017 19:30:11 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-wm0-x231.google.com with SMTP id d127so54841161wmf.0; Sun, 14 May 2017 12:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=DfDTz5tcYpVFO8E/TMKNQmQsuoIezAZozm7ZSxdqJm0=; b=LHsGnD3DcC0Yci0XzQFaGAcIXJafHOcGq5lTVq1zeQDy6mnQyGGfEpCh4yMsggvuDC pZ94sIZ0vxIpMrArh/dc5XQXLANxqEeiohDRcW2zqCBKbEKaET7KbbYTliKBAVjHusUs 2KCND2pTe6kTK505K9RuRfVgTBAVYkbnzdom+8S1yMtJULPTAPxRPZkyiShx5cRItC41 9px21Uy4IBkciUbslxaIKsURRJOp6FfYOHk03POzhX2BU2S5EuLvCK280DOr1UXbThtN 0MFcATTwtWOIb2lN2rMCK2WbhkGx2U/U/+Ob6rt74W1nGGqfhmMm9HU65zL6XR6XgSIA m/2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=DfDTz5tcYpVFO8E/TMKNQmQsuoIezAZozm7ZSxdqJm0=; b=dlEapAZwP4DFtR7R534BtMBaxVlPLJ/no+3r1s3tx4OgzhGLX1cQL62vtZ+tu9r2/1 zy8rhQ34NAR2UnXtCH9NnKRqpTaydUKe9pcBgeAhFrfBhfw6oVXf97kG9FLXrRfbe8WM KKVHBLkmhmTCHUP5jPJCmG6V30/c4bEFQzUltlDhv6qtyV9rGPsve6/5unu1wYP49HBr 4Az/li5+wDmb7BC4YPoFT6MEBtXtrV3N9aaqlIs8xngifva63ttl5zh75QTtpWofHzI6 A8x+LcaWA0hcah8t1NKjUgJ8QtKyBA7XK8g02r/Bny8uL2O+q2zgqM4xSTFqy4Bpas7o /yNQ== X-Gm-Message-State: AODbwcCKivEZ6OZIAENOuyC2NcQrzhiwKZ64BXPTaUq2bLIlpPTyI34r 4pBWBg1dX63OC93+ X-Received: by 10.28.65.213 with SMTP id o204mr1745630wma.43.1494790209986; Sun, 14 May 2017 12:30:09 -0700 (PDT) Received: from brick (cpc92310-cmbg19-2-0-cust934.5-4.cable.virginm.net. [82.9.227.167]) by smtp.gmail.com with ESMTPSA id j126sm14326912wmd.29.2017.05.14.12.30.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 May 2017 12:30:09 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Sun, 14 May 2017 20:30:06 +0100 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Manuel =?iso-8859-1?Q?St=FChn?= Cc: freebsd-current@freebsd.org, kib@FreeBSD.org Subject: Re: regression suspend/resume on Lenovo T420 Message-ID: <20170514193006.GA1298@brick> Mail-Followup-To: Manuel =?iso-8859-1?Q?St=FChn?= , freebsd-current@freebsd.org, kib@FreeBSD.org References: <5746a37cd73e062c963512df1a6d24c6@email.freenet.de> <20170506090341.GA12163@freebsd-t420.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170506090341.GA12163@freebsd-t420.fritz.box> User-Agent: Mutt/1.8.2 (2017-04-18) 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, 14 May 2017 19:30:12 -0000 On 0506T1103, Manuel Stühn wrote: > On Sat, May 06, 2017 at 10:52:56AM +0200, Manuel Stühn wrote: > >On Wed, 03 May 2017 22:28:41 +0200, Freebsdnewbie wrote > >> > >>> Von: Adrian Chadd > >>> Gesendet: Mo. 01.05.2017 23:31 > >>> An: Manuel Stühn , > >>> Kopie: freebsd-current , > >>> Betreff: Re: regression suspend/resume on Lenovo T420 > >>> > >>> There were lots of commits that could break things. :-) > >>> > >>> > >>> Can you compile up some intermediary versions between 315141 and > >>> r317559 to find which commit range broke things? That'll make chasing > >>> it down much quicker! > >>> > >> > >> I'm following your advice and building some intermediary versions. This will take some time... > > > >So, after keep building some more worlds i've discovered the commit > >after which resume does not work anymore. r316736 is the last working > >one, r316737 breaks it for me (There is also no mouse cursor on the > >console anymore after this commit). > > Sorry, my fault: r316734 was the last working revision!! I've tried to verify that, and sadly it wasn't it for me. The commit that does break resume for me is r316767. The current -CURRENT with this one commit reverted ("svn merge -c -r316767 .") suspends and resumes correctly, at least in VT; I decided to take X out of the picture for now. There is still the issue of backlight being off after resume in VT; one needs to switch consoles to restore it, but it's 1. minor and 2. broken for a really long time now. There's also another problem, which kind of looks like an inability to resume if the machine is hot (as in, thermally), but this might be just because of its age. From owner-freebsd-current@freebsd.org Sun May 14 20:03: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 92A95D6D1D0 for ; Sun, 14 May 2017 20:03:02 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 5A23117EB; Sun, 14 May 2017 20:03:02 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 412A7273DF; Sun, 14 May 2017 20:02:54 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id v4EK2q1G001191; Sun, 14 May 2017 20:02:52 GMT (envelope-from phk@phk.freebsd.dk) To: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= cc: Manuel =?iso-8859-1?Q?St=FChn?= , freebsd-current@freebsd.org, kib@FreeBSD.org Subject: Re: regression suspend/resume on Lenovo T420 In-reply-to: <20170514193006.GA1298@brick> From: "Poul-Henning Kamp" References: <5746a37cd73e062c963512df1a6d24c6@email.freenet.de> <20170506090341.GA12163@freebsd-t420.fritz.box> <20170514193006.GA1298@brick> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1189.1494792172.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Sun, 14 May 2017 20:02:52 +0000 Message-ID: <1190.1494792172@critter.freebsd.dk> 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, 14 May 2017 20:03:02 -0000 -------- In message <20170514193006.GA1298@brick>, Edward Tomasz =3D?utf-8?Q?Napier= a=3DC5=3D82 a?=3D writes: >I've tried to verify that, and sadly it wasn't it for me. The commit >that does break resume for me is r316767. The current -CURRENT with >this one commit reverted ("svn merge -c -r316767 .") suspends and resumes >correctly, at least in VT; I decided to take X out of the picture for >now. I can confirm that this also makes resume work on my T430s running: FreeBSD 12.0-CURRENT #0 r318250M amd64 -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-current@freebsd.org Mon May 15 07:20: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 4F6B4D6DA4B for ; Mon, 15 May 2017 07:20:54 +0000 (UTC) (envelope-from mueller6722@twc.com) Received: from dnvrco-oedge-vip.email.rr.com (dnvrco-outbound-snat.email.rr.com [107.14.73.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "dnvrco-oedge-vip.email.rr.com", Issuer "dnvrco-oedge-vip.email.rr.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 304C915B7 for ; Mon, 15 May 2017 07:20:53 +0000 (UTC) (envelope-from mueller6722@twc.com) Received: from [74.134.208.22] ([74.134.208.22:65532] helo=localhost) by dnvrco-omsmta03 (envelope-from ) (ecelerity 3.6.9.48312 r(Core:3.6.9.0)) with ESMTP id B3/44-25473-3D659195; Mon, 15 May 2017 07:20:52 +0000 Date: Mon, 15 May 2017 07:20:51 +0000 Message-ID: From: "Thomas Mueller" To: freebsd-current@freebsd.org CC: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Problems with re(4) Ethernet driver in 11-STABLE and HEAD X-RR-Connecting-IP: 107.14.64.88: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: Mon, 15 May 2017 07:20:54 -0000 I remember having problems with Realtek 8111E Ethernet on this Intel Ivy Bridge computer a couple years ago, and now the problem has resurfaced. I am fresh from updating FreeBSD to 11-STABLE and HEAD on two partitions, and in both cases can not connect with onboard Ethernet. >From NetBSD 7.99.1 /var/run/dmesg.boot : re0 at pci2 dev 0 function 0: RealTek 8168/8111 PCIe Gigabit Ethernet (rev. 0x06) re0: interrupting at ioapic0 pin 17 re0: Ethernet address d4:3d:7e:97:17:e2 re0: using 256 tx descriptors rgephy0 at re0 phy 7: RTL8169S/8110S/8211 1000BASE-T media interface, rev. 5 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto NetBSD 7.99.1, an old build, and NetBSD going back to 5.x, worked well with this Ethernet, but the bug has come back in FreeBSD. Before giving up hope on FreeBSD 11-STABLE and HEAD on this computer, I have Hiro H50191 USB wi-fi adapter, driver rsu, haven't used it recently but see where I will try to bring it back. "dhclient re0" on HEAD (amd64) gave a couple lines of screen output before crashing into debugger (db>), whereupon I simply did "reboot". On 11-STABLE, also amd64, I got some lines before it gave up , "sleeping". On an old FreeBSD-current, svn r286653M, Aug 12, 2015, this Ethernet starts properly with dhclient. Now I am afraid to update except by installing onto a separate partition. I have plenty of space on 3 TB hard drive with GPT. I am not completely sure on which FreeBSD list is most appropriate for this issue. Tom From owner-freebsd-current@freebsd.org Mon May 15 08:20: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 E655FD6DCF0 for ; Mon, 15 May 2017 08:20:29 +0000 (UTC) (envelope-from zaphod@berentweb.com) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (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 BFF951241 for ; Mon, 15 May 2017 08:20:29 +0000 (UTC) (envelope-from zaphod@berentweb.com) Received: by mail-pf0-x229.google.com with SMTP id 9so19399291pfj.1 for ; Mon, 15 May 2017 01:20:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb-com.20150623.gappssmtp.com; s=20150623; h=sender:date:from:to:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=RCnBIHFUKNtOCWEloLIM78Q08jbdONfxCP9mXiBEBvM=; b=TZq7w0qHBhqKd1WgBPdbgS6FxcRp8Rr0fG88xlLGSTka2Fdj0l/S+/GKhMGNzQTfNX jurdqgTjC/Tlmc4nnVJ162PpQwZSoFp/iQJlFRpxtM6D8tQe88CZvAgYcDexX525Xj3L 0JQ6yZXm6wI4IxOEoM0HrzHt8/BTzsHcPmiktWr5l1WFN8iqlzlxrA2cYeVzoh+Vqg3x a8lewHCY3lLc9yxNkrVpO25FN2IO0Ljf4PJJ1YTqSMfB2IePph9NE7rCSFVCpC8lptlI 3rS54UXWktlBc66FG5ohjCNYvz8FBLg09SvhQQTojOx/NJesvnP81ZNA69j+I+0hITxo jWkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:subject:message-id :in-reply-to:references:mime-version:content-transfer-encoding; bh=RCnBIHFUKNtOCWEloLIM78Q08jbdONfxCP9mXiBEBvM=; b=bRpqLp3Vrfw9l13Xldv0mASU941JqwGMzwkU6xB74ywHOEqH7A+O7HTFVSsrw7y9ut Afo9Vp1AHyuTBZ5pWmt9cEufkKhsc1LyQKPChBmJaGhuynuegjixYr9gxmPqjv6kW/f0 X+88dJUGmtYYsJ08jDMmRBZxYVDTsSabvp5Ga1BcphDxODURU0klfguhgyItr2+76A5X eLIezn2ZYWpj1fQVDnGbqZl9y3y7JokuWvJXoHc2x1pvf4gRRk7UQd+SQfOseptldUjr 3RvACS5OKMFGg5xe3QD5zfRK6vK328LXctsvk7pbsDb4YzzSNqi/46tAozdKxLdppe0N ukOw== X-Gm-Message-State: AODbwcARuNUA197LnN8hN3wa5okO78pE1PTcPdq5bW9CiQXtwhxT/PU8 GCWpXWLgmGKMMp/h X-Received: by 10.84.229.15 with SMTP id b15mr6864066plk.14.1494836428714; Mon, 15 May 2017 01:20:28 -0700 (PDT) Received: from rsbsd ([24.133.238.42]) by smtp.gmail.com with ESMTPSA id k79sm20905793pfj.6.2017.05.15.01.20.25 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 15 May 2017 01:20:27 -0700 (PDT) Sender: "Raif S. Berent" Date: Mon, 15 May 2017 11:20:03 +0300 From: Beeblebrox To: freebsd-current Current Subject: Anyone having ccache errors? Message-ID: <20170515112003.49aef487@rsbsd> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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, 15 May 2017 08:20:30 -0000 I have been getting ccache errors during buildworld. Ports for example does= not have this problem. I compleely reset the cache data some 2 months ago = and ccache seemed to play with that much more nicely. Apart from the error below, I'm also getting some "cc not found" errors whe= n doing src stuff, whether ccache is enabled or not. For example installwor= ld (no ccache) broke with that message so I decided to re-build. uname: 12.0-CURRENT 1200028 bedc15ffb71(drm-next)-dirty: Thu Apr 20 2017 /etc/make.conf CC:=3D${CC:C,^cc,/usr/local/libexec/ccache/world/clang,1} CXX:=3D${cxx:c,^C\+\+,/usr/local/libexec/ccache/world/clang++,1} ls /usr/local/libexec/ccache/world/ c++ CC clang clang++40 g++5 cc ccache clang++ clang40 gcc5 # make buildworld =3D> make: Unknown modifier 'c' make: Unknown modifier 'c' make[1]: Unknown modifier 'c' make[1]: Unknown modifier 'c' make[2]: Unknown modifier 'c' make[2]: Unknown modifier 'c' make[2]: Unknown modifier 'c' make[2]: Unknown modifier 'c' -------------------------------------------------------------- >>> World build started ..... >>> stage 1.2: bootstrap tools -------------------------------------------------------------- cd /asp/git/src; MAKEOBJDIRPREFIX=3D/asp/obj/asp/git/src/tmp INSTALL=3D"sh= /asp/git/src/tools/install.sh" TOOLS_PREFIX=3D/asp/obj/asp/git/src/tmp P= ATH=3D/asp/obj/asp/git/src/tmp/legacy/usr/sbin:/asp/obj/asp/git/src/tmp/leg= acy/usr/bin:/asp/obj/asp/git/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/b= in WORLDTMP=3D/asp/obj/asp/git/src/tmp MAKEFLAGS=3D"-m /asp/git/src/tools= /build/mk -m /asp/git/src/share/mk" make -f Makefile.inc1 DESTDIR=3D BO= OTSTRAPPING=3D1200030 SSP_CFLAGS=3D MK_HTML=3Dno NO_LINT=3Dyes MK_MAN=3Dn= o -DNO_PIC MK_PROFILE=3Dno -DNO_SHARED -DNO_CPU_CFLAGS MK_WARNS=3Dno MK_C= TF=3Dno MK_CLANG_EXTRAS=3Dno MK_CLANG_FULL=3Dno MK_LLDB=3Dno MK_TESTS=3Dn= o MK_INCLUDES=3Dyes bootstrap-tools make[2]: Unknown modifier 'c' make[2]: Unknown modifier 'c' =3D=3D=3D> lib/clang/libllvmminimal (obj,all,install) make[3]: Unknown modifier 'c' make[3]: Unknown modifier 'c' make[3]: Unknown modifier 'c' make[3]: Unknown modifier 'c' make[3]: Unknown modifier 'c' -O2 -pipe -I/asp/git/src/lib/clang/include -I/asp/git/src/contrib/llvm/incl= ude -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTAN= T_MACROS -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"x86_64-unknown-freebsd12.0\" -DLL= VM_HOST_TRIPLE=3D\"x86_64-unknown-freebsd12.0\" -DDEFAULT_SYSROOT=3D\"/asp/= obj/asp/git/src/tmp\" -ffunction-sections -fdata-sections -DNDEBUG -MD -MF.= depend.Support_APInt.o -MTSupport/APInt.o -Qunused-arguments -I/asp/obj/asp= /git/src/tmp/legacy/usr/include -std=3Dc++11 -fno-exceptions -fno-rtti -st= dlib=3Dlibc++ -Wno-c++11-extensions -c /asp/git/src/contrib/llvm/lib/Suppo= rt/APInt.cpp -o Support/APInt.o /bin/sh: -O2: not found *** Error code 127 Stop. make[3]: stopped in /asp/git/src/lib/clang/libllvmminimal * I had asked this before, but got no answer. I assume it's not possible th= en? > 1. For buildworld, my /etc/src.conf uses default CROSS_COMPILER, > CLANG_BOOTSTRAP, CLANG_FULL for amd64, but I would like clang to > xbuild only for target i386 as I do not need the others (like > Target/arm). Is there a knob for this? --=20 FreeBSD_amd64_12-Current_RadeonKMS Please CC my email when responding, mail from list is not delivered. From owner-freebsd-current@freebsd.org Mon May 15 09:56: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 CC87FD6DAA1 for ; Mon, 15 May 2017 09:56:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4489D1E05; Mon, 15 May 2017 09:56:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v4F9um84074543 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 15 May 2017 12:56:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v4F9um84074543 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v4F9ulDC074542; Mon, 15 May 2017 12:56:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 15 May 2017 12:56:47 +0300 From: Konstantin Belousov To: Poul-Henning Kamp Cc: Edward Tomasz Napiera??a , Manuel St?hn , freebsd-current@freebsd.org Subject: Re: regression suspend/resume on Lenovo T420 Message-ID: <20170515095647.GA1622@kib.kiev.ua> References: <5746a37cd73e062c963512df1a6d24c6@email.freenet.de> <20170506090341.GA12163@freebsd-t420.fritz.box> <20170514193006.GA1298@brick> <1190.1494792172@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1190.1494792172@critter.freebsd.dk> User-Agent: Mutt/1.8.2 (2017-04-18) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 09:56:54 -0000 On Sun, May 14, 2017 at 08:02:52PM +0000, Poul-Henning Kamp wrote: > -------- > In message <20170514193006.GA1298@brick>, Edward Tomasz =?utf-8?Q?Napiera=C5=82 > a?= writes: > > >I've tried to verify that, and sadly it wasn't it for me. The commit > >that does break resume for me is r316767. The current -CURRENT with > >this one commit reverted ("svn merge -c -r316767 .") suspends and resumes > >correctly, at least in VT; I decided to take X out of the picture for > >now. > > I can confirm that this also makes resume work on my T430s running: > > FreeBSD 12.0-CURRENT #0 r318250M amd64 Try this. If it works, I will write a proper patch. diff --git a/sys/amd64/amd64/cpu_switch.S b/sys/amd64/amd64/cpu_switch.S index 33437ad16e6..9c0cd05ebea 100644 --- a/sys/amd64/amd64/cpu_switch.S +++ b/sys/amd64/amd64/cpu_switch.S @@ -369,6 +369,11 @@ END(savectx) * Resuming processor state from pcb. */ ENTRY(resumectx) + movl $MSR_EFER,%ecx + rdmsr + orl $EFER_NXE,%eax + wrmsr + /* Switch to KPML4phys. */ movq KPML4phys,%rax movq %rax,%cr3 From owner-freebsd-current@freebsd.org Mon May 15 08:15: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 CFDCFD6DC24 for ; Mon, 15 May 2017 08:15:48 +0000 (UTC) (envelope-from bugzilla-noreply@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 B93761103 for ; Mon, 15 May 2017 08:15:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id B5D43D6DC23; Mon, 15 May 2017 08:15:48 +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 B3D25D6DC22 for ; Mon, 15 May 2017 08:15:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 95ED11102 for ; Mon, 15 May 2017 08:15:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4F8FmU9047280 for ; Mon, 15 May 2017 08:15:48 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: current@FreeBSD.org Subject: [Bug 218849] Remove rc.conf jail configuration via jail_* variables Date: Mon, 15 May 2017 08:15:48 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: conf X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: 000.fbsd@quip.cz X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: mfc-stable9- mfc-stable10- mfc-stable11- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 15 May 2017 12:07:07 +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, 15 May 2017 08:15:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218849 --- Comment #26 from Miroslav Lachman <000.fbsd@quip.cz> --- (In reply to Thomas Steen Rasmussen / Tykling from comment #25) Are you serious? Then why Joe provided the idea how to make ezjail survive = this code removal? Did you read the comment from Jamie? Did you compare rc.d/jail with legacy support and without it? The legacy support is a mess compared to new style and some functionalities are missin= g. As I already stated - ezjail is not the only one tool to manage jails and should not be used to take FreeBSD base as hostage. There are many alternat= ives and migration path is very trivial. It's time to move on. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-current@freebsd.org Mon May 15 13:58: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 36B61D6D7B1 for ; Mon, 15 May 2017 13:58:56 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002: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 F22C510CB for ; Mon, 15 May 2017 13:58:55 +0000 (UTC) (envelope-from ray@ddteam.net) Received: by mail-yw0-x22c.google.com with SMTP id b68so37858430ywe.3 for ; Mon, 15 May 2017 06:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ddteam-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EfA2QqwfuzXzJn0T+TbKxa/piwFWgIoJi3sLYURvN/s=; b=hUG45/fxqZDlMu/33HgadQHNrFBDL9P0XCxeQx/+96v8WniwJ+GfwDQ6NDumEneW0R a00/UQ5taGo9oBL48Akkw8+gFJ7XmDNrznNRoZevohUGP8Yag24LNm7H2vPX6tDOZqnK pZzyhCSHvFnex4dJ+LSoHBLEVW8BA+Sfmw8tKXTo1EKzUxhUqqxDuSVjDqzsHTaAKlt+ oUQM4CsOHdtEocSofyye+hYztCL5kICAFiDXgujFfhevgKnyP8ypIU/MeiNslmUAhRxI LC1EraryZc8LxKgQsyGmh0+k+Uli7QKkumIMYGLyCfh8ntdSh1jMht8gRZ3930q0x/um RpMg== 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=EfA2QqwfuzXzJn0T+TbKxa/piwFWgIoJi3sLYURvN/s=; b=s6U2DCDkuc+OPOCEQGjxq7cUO5N0a9bdYXK7PO4LzqQsj7KTLpaL8BoWhv/ukAMZuq BmeEabc2O92WGS8IqieShSS1nyko6ZZvdeHk7KnsEn/UYZUYhIU3oToP5YdVItitRJjE f8K90lYh6JFmyu92F+I6WIbEvi6DvHbmx/UkRkVEJfziBN+dyfnWgSeJ4zbmrAj6y+pA vQK0xt62LM+X/BF6tANj1H7OH3fjnuCH3YOyOdt8MjpkN+Z13jfwOTJK/qQceMKj47OG vMcVDikZ7YQYLiJ73ZF2dw3GZvMJRR8QXhO2vjtOTaIVCHsFq9osT9drMH+mpoLSaxam OHhw== X-Gm-Message-State: AODbwcCgeVHqmeorTX+PuHfYTVavaRVsO3u1uA+ltue5EtKbZyFxkTjL h1ZbxEFETvD4cipOSIYr9LBlma1kwQ== X-Received: by 10.129.0.138 with SMTP id 132mr5169227ywa.27.1494856735048; Mon, 15 May 2017 06:58:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.161.194 with HTTP; Mon, 15 May 2017 06:58:54 -0700 (PDT) In-Reply-To: References: <84817.1481960079@critter.freebsd.dk> From: Aleksandr Rybalko Date: Mon, 15 May 2017 16:58:54 +0300 Message-ID: Subject: Re: vt(4) odd scrolling behavior To: Kyle Evans Cc: Poul-Henning Kamp , freebsd-current 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: Mon, 15 May 2017 13:58:56 -0000 Looks like video driver reports double buffer as single frame buffer, so vt draw it as big screen, but video card draw it as two layers. From owner-freebsd-current@freebsd.org Mon May 15 14:15: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 5741ED6DE33 for ; Mon, 15 May 2017 14:15:44 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 439B81E97 for ; Mon, 15 May 2017 14:15:44 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: by mailman.ysv.freebsd.org (Postfix) id 3F4D4D6DE2D; Mon, 15 May 2017 14:15: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 3EE0DD6DE2C; Mon, 15 May 2017 14:15:44 +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 055911E93; Mon, 15 May 2017 14:15:43 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.127] (helo=rmmprod05.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1dAGFh-0005Wk-Eh; Mon, 15 May 2017 15:41:33 +0200 Received: from mail by rmmprod05.runbox with local (Exim 4.86_2) (envelope-from ) id 1dAGFh-0001jh-7M; Mon, 15 May 2017 15:41:33 +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, 15 May 2017 13:41:33 GMT From: "Jeffrey Bouquet" Reply-To: To: "current" CC: "ports" , "timothy.bouquet" Subject: [RFC] rename nvidia-driver port binaries [ and other comments] Date: Mon, 15 May 2017 06:41:33 -0700 (PDT) X-Mailer: RMM6 Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 14:15:44 -0000 Just had a unique to me, unbootable backup [beside the point, just a sidebar comment... ] quandry dealing with the nvidia-driver update that mesa-libs needed. [ or was appurtenant to it, unsure... ] 12.0 - CURRENT [ my previous 'saves' -- files to consult... were in .jpg, so no avail f= or me to peruse as I was in the terminal ] Lessons I learned, maybe [RFC] rename nvidia-driver.ko to include its version, for instance nvidia-= modeset-37539.ko which would make one's diagnosis a fix easier.=20 [suggestions] ... Document that the kernel will load a /boot/modules/_nvidia.ko if you'd = thus made it 'unavailable' ... document better that one can load nvidia[modeset] later than /boot/load= er.conf [cli, rc.conf...] [ mini 'what fixed it for you ' and/or stalled the same ...=20 ]=20 ... I had a make.conf in place, 'trapping' a make -DMAKE_JOBS_UNSAFE=3Dyes CC=3D".../clang39" [and the other two...= ] install in failure ... I had no clue if Xorg was at fault, and luckily did not have to rebuild. ... I had no access to the forums, as the desktop could not be loaded [yet] ... I had to do strings nvidia.ko |grep 26 [39] | less to detect the not us= able module numbers, THUS THE REQ FOR RENAME of the nvidia.ko binary [vs port] to include it= s 5 digit number as above. ... I was taken aback by the less infomative this client has the .39 but the module has the .26 ...=20 specifically stating which file/port/kernel module the 'client' refers = to and which specific modules 'this module' was referring to. Unknown if t= hat is fixable here in a .c, .h , or is closed-source upstream in nvidia [corp = ] where we can ask them to be more specific or code in some more verbose error message= s. ... Relieved I did not have to rebuild Xorg nor the kernel, just move file= s out of the way and do a simple rebuild of the nvidia-driver. [... Not relieved that the nvidia-driver needed install during the mesa-lib= reshuffle, maybe did not need to be, just a hazy recollection on my part. So ignore this= little bit ] ... All in all a learning experience. Howsoever, I would like this nvidia = stuff to be put eventuall in /usr/src/UPDATING so the half or third of persons who run into this yea= rly will have a more authoritative flowchart of sorts to determine the next course of action. something like if ... this thta if... this that if ... this that OTOH... error message... a... you may need to... ... error message ... r... you may need to... ... And it would have maybe saved a bit of time here, and I would almost i= f eventually possible be sure to copy /usr/src/UPDATING to /usr/ports/x11/nvidia-dr= iver for more easy access if the desktop was broken.... Apologies for the hurried post. Indeed, I have tasked myself to write it up= here locally [ still in scribbled notations...] so I can forestall/fix more quic= kly this error the next time. also... Running late in other personal matters, and out of time. Respectfully.. J. Bouquet=20= From owner-freebsd-current@freebsd.org Mon May 15 14:19: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 BF650D6DFFE for ; Mon, 15 May 2017 14:19:46 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (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 244BA147; Mon, 15 May 2017 14:19:46 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from fortune.joker.local (124-18-21-125.dz.commufa.jp [124.18.21.125]) (authenticated bits=0) by dec.sakura.ne.jp (8.15.2/8.15.2/[SAKURA-WEB]/20080708) with ESMTPA id v4FEJbEY008561; Mon, 15 May 2017 23:19:37 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Mon, 15 May 2017 23:19:36 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Cc: bapt@FreeBSD.org, alexander@wittig.name Subject: Re: ports-mgmt/pkg_rmleaves stops working properly on -head after bsdiff became default diff (r317209) Message-Id: <20170515231936.9aba0763a8eef73f64ced0c1@dec.sakura.ne.jp> In-Reply-To: <20170514160355.5da31fb2f3c8a163e024acdf@dec.sakura.ne.jp> References: <20170514160355.5da31fb2f3c8a163e024acdf@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Mon__15_May_2017_23_19_36_+0900_1DgCE4km7A6rwgdD" 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, 15 May 2017 14:19:46 -0000 This is a multi-part message in MIME format. --Multipart=_Mon__15_May_2017_23_19_36_+0900_1DgCE4km7A6rwgdD Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Revised like Boris did for misc/mc [1]. Now attached raw Makefile and patch (renamed), as patch does not handle new files on nonexistent files directory. :-( PORTREVISION bumped, as this port is small enough and NO_BUILD, and need updating for recent -head. But at least 2 ports is affected for now, and possibly more. IMHO, these Gnu diff compatible group-format related options would be worth implemented by bsdiff. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219277 On Sun, 14 May 2017 16:03:55 +0900 Tomoaki AOKI wrote: > Hi. > Posting on freebsd-current as this only affects -head. > > I recently noticed ports-mgmt/pkg_rmleaves failes to process > new leaf ports after removal of leaf ports on -head with error > messages below. > > > diff: unrecognized option `--unchanged-line-format=' > > usage: diff [-abdilpTtw] [-c | -e | -f | -n | -q | -u] [--ignore-case] > > [--no-ignore-case] [--normal] [--strip-trailing-cr] > > [--tabsize] [-I pattern] [-L label] file1 file2 > > diff [-abdilpTtw] [-I pattern] [-L label] [--ignore-case] > > [--no-ignore-case] [--normal] [--strip-trailing-cr] > > [--tabsize] -C number file1 file2 > > diff [-abdiltw] [-I pattern] [--ignore-case] [--no-ignore-case] > > [--normal] [--strip-trailing-cr] [--tabsize] -D string > > file1 file2 diff [-abdilpTtw] [-I pattern] [-L label] [--ignore-case] > > [--no-ignore-case] [--normal] [--tabsize] > > [--strip-trailing-cr] -U number file1 file2 > > diff [-abdilNPprsTtw] [-c | -e | -f | -n | -q | -u] > > [--ignore-case] [--no-ignore-case] [--normal] [--tabsize] [-I pattern] > > [-L label] [-S name] [-X file] [-x pattern] dir1 dir2 > > stable/11 was OK, and the difference is that stable/11 has gnu diff > as diff, while -head has bsdiff as diff. > > There's 2 (or possibly 3) options. > > a) Let pkg_rmleaves use gnu diff via textprocs/diffutils. > This is easiest (Minimal diff is attached), but doesn't help > any other ports affected. Just change diff to gdiff and RUN_DEPENDS > on textproc/diffutils. > > b) Update bsdiff to support missing options below. > This is over my hand, but if possible, would help others. > > c) If the missing options below are implemented as different > (non-documented) options on bsdiff, use them for bsdiff instead. > Will need OSVERSION check in ports Makefile. > > Please note that attached diff is really MINIMAL to work on -head. > No OSVERSION switching is implemented and no bumps so forcibly > installs textproc/diffutils on revisions with gnu diff is /usr/bin/diff. > And patch wouldn't work properly as files directory doesn't exist > in pkg-mgmt/pkg_rmleaves. (At least system patch.) > > I wonder which option should be taken, so not yet filed PR on bugzilla. > It should be filed differently with which option is taken. > > -- > Tomoaki AOKI -- Tomoaki AOKI --Multipart=_Mon__15_May_2017_23_19_36_+0900_1DgCE4km7A6rwgdD Content-Type: application/octet-stream; name="Makefile" Content-Disposition: attachment; filename="Makefile" Content-Transfer-Encoding: base64 IyBDcmVhdGVkIGJ5OiBUaW1vdGh5IFJlZGFlbGxpIDxkcml6enRAZ3VmaS5vcmc+CiMgJEZyZWVC U0Q6IGhlYWQvcG9ydHMtbWdtdC9wa2dfcm1sZWF2ZXMvTWFrZWZpbGUgMzQ1Njg4IDIwMTQtMDIt MjMgMDE6NTE6MjRaIGpoYWxlICQKClBPUlROQU1FPQlwa2dfcm1sZWF2ZXMKUE9SVFZFUlNJT049 CTIwMTQwMjIyClBPUlRSRVZJU0lPTj0JMQpDQVRFR09SSUVTPQlwb3J0cy1tZ210Ck1BU1RFUl9T SVRFUz0JaHR0cDovL2FsZXgud2l0dGlnLm5hbWUvJHtQT1JUTkFNRX0vCgpNQUlOVEFJTkVSPQlh bGV4YW5kZXJAd2l0dGlnLm5hbWUKQ09NTUVOVD0JSW50ZXJhY3RpdmUgc2NyaXB0IGZvciBkZWlu c3RhbGxpbmcgbGVhZiBwYWNrYWdlcwoKTElDRU5TRT0JQlNEMkNMQVVTRQoKLmluY2x1ZGUgPGJz ZC5wb3J0LnByZS5taz4KCi5pZiAke09QU1lTfSA9PSBGcmVlQlNEICYmICR7T1NWRVJTSU9OfSA+ PSAxMjAwMDMwClJVTl9ERVBFTkRTPQlnZGlmZjp0ZXh0cHJvYy9kaWZmdXRpbHMKCkVYVFJBX1BB VENIRVM9CSR7RklMRVNESVJ9L2V4dHJhLXBhdGNoLXBrZ19ybWxlYXZlcwouZW5kaWYKCk5PX0JV SUxEPQl5ZXMKCldSS1NSQz0JCSR7V1JLRElSfQoKUExJU1RfRklMRVM9CXNiaW4vcGtnX3JtbGVh dmVzIG1hbi9tYW4xL3BrZ19ybWxlYXZlcy4xLmd6Cgpkby1pbnN0YWxsOgoJJHtJTlNUQUxMX1ND UklQVH0gJHtXUktTUkN9L3BrZ19ybWxlYXZlcyAke1NUQUdFRElSfSR7UFJFRklYfS9zYmluL3Br Z19ybWxlYXZlcwoJJHtJTlNUQUxMX01BTn0gJHtXUktTUkN9L3BrZ19ybWxlYXZlcy4xICR7U1RB R0VESVJ9JHtNQU4xUFJFRklYfS9tYW4vbWFuMQoKLmluY2x1ZGUgPGJzZC5wb3J0LnBvc3QubWs+ Cg== --Multipart=_Mon__15_May_2017_23_19_36_+0900_1DgCE4km7A6rwgdD Content-Type: application/octet-stream; name="extra-patch-pkg_rmleaves" Content-Disposition: attachment; filename="extra-patch-pkg_rmleaves" Content-Transfer-Encoding: base64 LS0tIHBrZ19ybWxlYXZlcy5vcmlnCTIwMTQtMDItMjIgMjE6MjE6NDcuMDAwMDAwMDAwICswOTAw CisrKyBwa2dfcm1sZWF2ZXMJMjAxNy0wNS0xNCAwMjoxNjo1NS43NTE0NDMwMDAgKzA5MDAKQEAg LTc0LDcgKzc0LDcgQEAgY2hlY2tMZWFmcygpIHsKIAlmaSB8IHNvcnQgfCBzZWQgLWUgInkvXCIv Jy8iIC1lICdzLyMmcXVvdDsjLyIvZycgPiAiJFBLR0ZJTEUiCiAKIAlpZiBbIC1mICIkUFJFViIg XTsgdGhlbgotCQlkaWZmIC0tdW5jaGFuZ2VkLWxpbmUtZm9ybWF0PScnIC0tb2xkLWxpbmUtZm9y bWF0PScnIC0tbmV3LWxpbmUtZm9ybWF0PSclTCcgIiRQUkVWIiAiJFBLR0ZJTEUiID4gIiRUTVBG SUxFIgorCQlnZGlmZiAtLXVuY2hhbmdlZC1saW5lLWZvcm1hdD0nJyAtLW9sZC1saW5lLWZvcm1h dD0nJyAtLW5ldy1saW5lLWZvcm1hdD0nJUwnICIkUFJFViIgIiRQS0dGSUxFIiA+ICIkVE1QRklM RSIKIAllbHNlCiAJCWNwICIkUEtHRklMRSIgIiRUTVBGSUxFIgogCWZpCgo= --Multipart=_Mon__15_May_2017_23_19_36_+0900_1DgCE4km7A6rwgdD-- From owner-freebsd-current@freebsd.org Mon May 15 14:53: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 01736D6EDAB; Mon, 15 May 2017 14:53:14 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (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 C39FAA8A; Mon, 15 May 2017 14:53:13 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from fortune.joker.local (124-18-21-125.dz.commufa.jp [124.18.21.125]) (authenticated bits=0) by dec.sakura.ne.jp (8.15.2/8.15.2/[SAKURA-WEB]/20080708) with ESMTPA id v4FErA7I009142; Mon, 15 May 2017 23:53:11 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Mon, 15 May 2017 23:53:10 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Cc: jbtakk@iherebuywisely.com, freebsd-ports@freebsd.org Subject: Re: [RFC] rename nvidia-driver port binaries [ and other comments] Message-Id: <20170515235310.9f60289e486c202cc5be7978@dec.sakura.ne.jp> In-Reply-To: References: Organization: Junchoon corps X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 15 May 2017 14:53:14 -0000 Hi. If including its version to nvidia.ko and nvidia-modeset.ko, [hard / symbolic] link to it with current name should be needed not to bother admins every time upgrading. BTW, I personally using below in rc.conf for safety. This only helps situations that... *Insufficient loader memory, but OK after kernel is started. *Accidentally backed to older version that doesn't have nvidia-modeset.ko and only nvidia-modeset.ko is written in /boot/loader.conf. ## Temporary settings for nvidia-driver when failed loading via loader.conf kldstat -q -n nvidia.ko if [ 0 -ne $? ] ; then echo "Loading nvidia-driver modules via rc.conf." # kldload nvidia if [ -e /boot/modules/nvidia-modeset.ko ] ; then # kldload nvidia-modeset kld_list="${kld_list} nvidia-modeset.ko" else # kldload nvidia kld_list="${kld_list} nvidia.ko" fi fi On Mon, 15 May 2017 06:41:33 -0700 (PDT) "Jeffrey Bouquet" wrote: > Just had a unique to me, unbootable backup [beside the point, > just a sidebar comment... ] quandry dealing with the nvidia-driver update > that mesa-libs needed. [ or was appurtenant to it, unsure... ] > > 12.0 - CURRENT > > [ my previous 'saves' -- files to consult... were in .jpg, so no avail for me to peruse as I was in the terminal ] > > Lessons I learned, maybe > > [RFC] rename nvidia-driver.ko to include its version, for instance nvidia-modeset-37539.ko > which would make one's diagnosis a fix easier. > > [suggestions] > > ... Document that the kernel will load a /boot/modules/_nvidia.ko if you'd thus made it 'unavailable' > ... document better that one can load nvidia[modeset] later than /boot/loader.conf [cli, rc.conf...] > > [ mini 'what fixed it for you ' and/or stalled the same ... > ] > ... I had a make.conf in place, 'trapping' a > make -DMAKE_JOBS_UNSAFE=yes CC=".../clang39" [and the other two...] install in failure > ... I had no clue if Xorg was at fault, and luckily did not have to rebuild. > ... I had no access to the forums, as the desktop could not be loaded [yet] > ... I had to do strings nvidia.ko |grep 26 [39] | less to detect the not usable module numbers, > THUS THE REQ FOR RENAME of the nvidia.ko binary [vs port] to include its 5 digit number > as above. > ... I was taken aback by the less infomative > this client has the .39 but the module has the .26 ... > specifically stating which file/port/kernel module the 'client' refers to > and which specific modules 'this module' was referring to. Unknown if that is > fixable here in a .c, .h , or is closed-source upstream in nvidia [corp ] where we can > ask them to be more specific or code in some more verbose error messages. > ... Relieved I did not have to rebuild Xorg nor the kernel, just move files out of the > way and do a simple rebuild of the nvidia-driver. > [... Not relieved that the nvidia-driver needed install during the mesa-lib reshuffle, maybe > did not need to be, just a hazy recollection on my part. So ignore this little bit ] > > ... All in all a learning experience. Howsoever, I would like this nvidia stuff to be put eventuall > in /usr/src/UPDATING so the half or third of persons who run into this yearly will have a more > authoritative flowchart of sorts to determine the next course of action. > something like > if ... this thta > if... this that > if ... this that > OTOH... error message... a... you may need to... > ... > error message ... r... you may need to... > > ... And it would have maybe saved a bit of time here, and I would almost if eventually > possible be sure to copy /usr/src/UPDATING to /usr/ports/x11/nvidia-driver for > more easy access if the desktop was broken.... > > > Apologies for the hurried post. Indeed, I have tasked myself to write it up here > locally [ still in scribbled notations...] so I can forestall/fix more quickly this > error the next time. > also... > Running late in other personal matters, and out of time. > > Respectfully.. > > J. Bouquet > _______________________________________________ > 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" > -- Tomoaki AOKI From owner-freebsd-current@freebsd.org Mon May 15 16:43: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 AD4F9D6E306 for ; Mon, 15 May 2017 16:43:11 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 77DA61B60 for ; Mon, 15 May 2017 16:43:11 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pf0-x22d.google.com with SMTP id e193so65790452pfh.0 for ; Mon, 15 May 2017 09:43:11 -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=/lFLRwkVHvSb1lD6SZGMk/J0aC0RMcyRfRlCTMg6xms=; b=F6oeL5Bvlx4DWDtMHm3qJMFFxlsaaKSzevxAAO3wQK6r8BU1oeReq/rD764nhS82vk D5VE7VSNQM4X7aq5hvlAs8Glt4YfWREwMWtLFNRG5RhIluez/xZqFC9iGVqdb4aa0zZS Bjmj55dOlXThVqRmmXdumwiJ+mFhMgxcqO1rgzrmrh9s2lEuNM7t7KZ1empwE4oEXvSf LtRhIcYxiWwx+z0jMn36RBzXGoWY3YG35JxsvjtUJpC77lk8p56H05/RXSERHdH7+Qc4 DmIGmvZCR0AgPrTU3VWc7urIlqT13g+kZ4jZzGVGHFg6Dpc8Y59V+4HdkYn8VbHGMwAZ iP8A== 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=/lFLRwkVHvSb1lD6SZGMk/J0aC0RMcyRfRlCTMg6xms=; b=nDpVrL7Vimy8mLEuM1ACrm8/qFneG0vA91OGrRYaoQfpOKY00eKBJb7wlLGHYdztVk 7ooGYjhDmP7sWWMaJlQvdp61GB6OQpeg6SJYYnIcB5nVgoL7UjfuLk/UPXXwhRULKibH 3giORq3KkXX/uZoluDsFdhR1rJr9pZW7oZ0/SkXIPi8kZphe6QE+haykmE/0dj6ERDZh jzCgefdB5KDQN2QlpoZN8PBD7tH6hBXSvmeTTt9VB5+hy14XWWsQsdf9mdTi5WAUgZHc kJxEIX5f6UtSN9YEnlMyxd4dtM5pj/6YJfrzsWNFWVk87H71mS2yPySwUpiuC2+RRNdp Ob6A== X-Gm-Message-State: AODbwcD5d6niIYErQDG4hWmZcNgzBkpjid6R5jweB8XYptjJjwedHYHz ulSTdrIluagEmz54DlI= X-Received: by 10.99.1.85 with SMTP id 82mr2136831pgb.74.1494866590676; Mon, 15 May 2017 09:43:10 -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 n23sm4442172pfh.44.2017.05.15.09.43.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 15 May 2017 09:43:09 -0700 (PDT) Subject: Re: Anyone having ccache errors? Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A05CEA7D-3A23-4585-B8D2-8E3DF62F0537"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Ngie Cooper (yaneurabeya)" In-Reply-To: <20170515112003.49aef487@rsbsd> Date: Mon, 15 May 2017 09:43:08 -0700 Cc: freebsd-current Current Message-Id: References: <20170515112003.49aef487@rsbsd> To: Beeblebrox 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: Mon, 15 May 2017 16:43:11 -0000 --Apple-Mail=_A05CEA7D-3A23-4585-B8D2-8E3DF62F0537 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 15, 2017, at 01:20, Beeblebrox wrote: >=20 > I have been getting ccache errors during buildworld. Ports for example = does not have this problem. I compleely reset the cache data some 2 = months ago and ccache seemed to play with that much more nicely. >=20 > Apart from the error below, I'm also getting some "cc not found" = errors when doing src stuff, whether ccache is enabled or not. For = example installworld (no ccache) broke with that message so I decided to = re-build. >=20 > uname: 12.0-CURRENT 1200028 bedc15ffb71(drm-next)-dirty: Thu Apr 20 = 2017 >=20 > /etc/make.conf > CC:=3D${CC:C,^cc,/usr/local/libexec/ccache/world/clang,1} > CXX:=3D${cxx:c,^C\+\+,/usr/local/libexec/ccache/world/clang++,1} >=20 > ls /usr/local/libexec/ccache/world/ > c++ CC clang clang++40 g++5 > cc ccache clang++ clang40 gcc5 >=20 > # make buildworld =3D> > make: Unknown modifier 'c' > make: Unknown modifier 'c' > make[1]: Unknown modifier 'c' > make[1]: Unknown modifier 'c' > make[2]: Unknown modifier 'c' > make[2]: Unknown modifier 'c' > make[2]: Unknown modifier 'c' > make[2]: Unknown modifier 'c' > -------------------------------------------------------------- >>>> World build started > ..... >>>> stage 1.2: bootstrap tools > -------------------------------------------------------------- > cd /asp/git/src; MAKEOBJDIRPREFIX=3D/asp/obj/asp/git/src/tmp = INSTALL=3D"sh /asp/git/src/tools/install.sh" = TOOLS_PREFIX=3D/asp/obj/asp/git/src/tmp = PATH=3D/asp/obj/asp/git/src/tmp/legacy/usr/sbin:/asp/obj/asp/git/src/tmp/l= egacy/usr/bin:/asp/obj/asp/git/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/us= r/bin WORLDTMP=3D/asp/obj/asp/git/src/tmp MAKEFLAGS=3D"-m = /asp/git/src/tools/build/mk -m /asp/git/src/share/mk" make -f = Makefile.inc1 DESTDIR=3D BOOTSTRAPPING=3D1200030 SSP_CFLAGS=3D = MK_HTML=3Dno NO_LINT=3Dyes MK_MAN=3Dno -DNO_PIC MK_PROFILE=3Dno = -DNO_SHARED -DNO_CPU_CFLAGS MK_WARNS=3Dno MK_CTF=3Dno = MK_CLANG_EXTRAS=3Dno MK_CLANG_FULL=3Dno MK_LLDB=3Dno MK_TESTS=3Dno = MK_INCLUDES=3Dyes bootstrap-tools > make[2]: Unknown modifier 'c' > make[2]: Unknown modifier 'c' > =3D=3D=3D> lib/clang/libllvmminimal (obj,all,install) > make[3]: Unknown modifier 'c' > make[3]: Unknown modifier 'c' > make[3]: Unknown modifier 'c' > make[3]: Unknown modifier 'c' > make[3]: Unknown modifier 'c' > -O2 -pipe -I/asp/git/src/lib/clang/include = -I/asp/git/src/contrib/llvm/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD = -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"x86_64-unknown-freebsd12.0\" = -DLLVM_HOST_TRIPLE=3D\"x86_64-unknown-freebsd12.0\" = -DDEFAULT_SYSROOT=3D\"/asp/obj/asp/git/src/tmp\" -ffunction-sections = -fdata-sections -DNDEBUG -MD -MF.depend.Support_APInt.o = -MTSupport/APInt.o -Qunused-arguments = -I/asp/obj/asp/git/src/tmp/legacy/usr/include -std=3Dc++11 = -fno-exceptions -fno-rtti -stdlib=3Dlibc++ -Wno-c++11-extensions -c = /asp/git/src/contrib/llvm/lib/Support/APInt.cpp -o Support/APInt.o > /bin/sh: -O2: not found > *** Error code 127 Upgrade make =E2=80=94 it was a bug with it, fixed in the past few days. HTH, -Ngie --Apple-Mail=_A05CEA7D-3A23-4585-B8D2-8E3DF62F0537 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 iQIcBAEBCgAGBQJZGdqcAAoJEPWDqSZpMIYV720QAMCJAKGpNTphS4Lj3/1cvGtt N3hliNbDDQA4ceDV2l04+nbxm+FMbn5ZwQYIMKxmlW6lXn5QXTBNd5Vzt5SV6ADt otczPQge0neVFcckP+Jn4YiXp5gW4pbdrM7lt1vddgZcB9KgOdxxkNTOpy/lVejy GBuoo1doSTKyie9yAldOqoTsPlj9okADPkRVRWsCy8kyOqQtxhDIEIBrJ0B4yMgO NNIauQhERusrBdW/VZH6m8LDaQqbK+LHy1N6x/8dhBqOhDV9D9EJUmCcHvBU83Iv 3tFH/FJFNtk4f4FnL9ucGrJlAozGBWpzy8T92tkf4Odxh6DUiZTFtUOA3HNzop5K 2ZnM1nMKohYmRPQvu2daC2J3ERTiTgdTzrqkrxfTPrU7nDtmLHWslBE0683x+HsS WiwvnuDZdTNYlaH7u3L9cDDv9SaERuWU9rqxTDiT/kOTUndMhXUrrTmNGAUj4Esj pgJ3QkMuFcD67oJrGd5bQA0L0O4uSCQlqffobT2aC4+z7EaFQ4MDOx70Prrm/nPo us9pZn8g2p9eK7oZE1CmtAADpeA0kUG3KB3Ry7qzXG0/6fInAWrU9myGbbMmPibl V2FDrls9/HuUQKulB/JX9f/LXrDDQamtZyVMw43dmXAzPEPANLx+4F4ib/C0MWxa UpiKLpX+cli0ZkVmxbWP =7kr/ -----END PGP SIGNATURE----- --Apple-Mail=_A05CEA7D-3A23-4585-B8D2-8E3DF62F0537-- From owner-freebsd-current@freebsd.org Mon May 15 17:07: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 490EAD6E9F7 for ; Mon, 15 May 2017 17:07:18 +0000 (UTC) (envelope-from jonathan@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 1E8D5AD1; Mon, 15 May 2017 17:07:18 +0000 (UTC) (envelope-from jonathan@FreeBSD.org) Received: from [134.153.0.231] (unknown [127.0.1.132]) by freefall.freebsd.org (Postfix) with ESMTP id D99EB4CE9; Mon, 15 May 2017 17:07:16 +0000 (UTC) (envelope-from jonathan@FreeBSD.org) From: "Jonathan Anderson" To: "Konstantin Belousov" Cc: "Poul-Henning Kamp" , "Edward Tomasz Napiera??a" , "Manuel St?hn" , freebsd-current@freebsd.org Subject: Re: regression suspend/resume on Lenovo T420 Date: Mon, 15 May 2017 14:37:16 -0230 Message-ID: In-Reply-To: <20170515095647.GA1622@kib.kiev.ua> References: <5746a37cd73e062c963512df1a6d24c6@email.freenet.de> <20170506090341.GA12163@freebsd-t420.fritz.box> <20170514193006.GA1298@brick> <1190.1494792172@critter.freebsd.dk> <20170515095647.GA1622@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) 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, 15 May 2017 17:07:18 -0000 On 15 May 2017, at 7:26, Konstantin Belousov wrote: > > Try this. If it works, I will write a proper patch. > > diff --git a/sys/amd64/amd64/cpu_switch.S > b/sys/amd64/amd64/cpu_switch.S > index 33437ad16e6..9c0cd05ebea 100644 > --- a/sys/amd64/amd64/cpu_switch.S > +++ b/sys/amd64/amd64/cpu_switch.S > @@ -369,6 +369,11 @@ END(savectx) > * Resuming processor state from pcb. > */ > ENTRY(resumectx) > + movl $MSR_EFER,%ecx > + rdmsr > + orl $EFER_NXE,%eax > + wrmsr > + > /* Switch to KPML4phys. */ > movq KPML4phys,%rax > movq %rax,%cr3 Running drm-next (which has -CURRENT last merged somewhere around r317651), this patch fixes one of the two problems I've been experiencing with suspend/resume. Definite progress. :) Thanks! Jon -- Jonathan Anderson jonathan@FreeBSD.org From owner-freebsd-current@freebsd.org Mon May 15 17:27:32 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0677DD6D065 for ; Mon, 15 May 2017 17:27:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 72C9517E9; Mon, 15 May 2017 17:27:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v4FHRPpx074671 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 15 May 2017 20:27:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v4FHRPpx074671 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v4FHRP1W074670; Mon, 15 May 2017 20:27:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 15 May 2017 20:27:25 +0300 From: Konstantin Belousov To: Jonathan Anderson Cc: Poul-Henning Kamp , Edward Tomasz Napiera??a , Manuel St?hn , freebsd-current@freebsd.org Subject: Re: regression suspend/resume on Lenovo T420 Message-ID: <20170515172725.GE1622@kib.kiev.ua> References: <5746a37cd73e062c963512df1a6d24c6@email.freenet.de> <20170506090341.GA12163@freebsd-t420.fritz.box> <20170514193006.GA1298@brick> <1190.1494792172@critter.freebsd.dk> <20170515095647.GA1622@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.2 (2017-04-18) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 17:27:32 -0000 On Mon, May 15, 2017 at 02:37:16PM -0230, Jonathan Anderson wrote: > On 15 May 2017, at 7:26, Konstantin Belousov wrote: > > > > Try this. If it works, I will write a proper patch. > > > > diff --git a/sys/amd64/amd64/cpu_switch.S > > b/sys/amd64/amd64/cpu_switch.S > > index 33437ad16e6..9c0cd05ebea 100644 > > --- a/sys/amd64/amd64/cpu_switch.S > > +++ b/sys/amd64/amd64/cpu_switch.S > > @@ -369,6 +369,11 @@ END(savectx) > > * Resuming processor state from pcb. > > */ > > ENTRY(resumectx) > > + movl $MSR_EFER,%ecx > > + rdmsr > > + orl $EFER_NXE,%eax > > + wrmsr > > + > > /* Switch to KPML4phys. */ > > movq KPML4phys,%rax > > movq %rax,%cr3 > > Running drm-next (which has -CURRENT last merged somewhere around > r317651), this patch fixes one of the two problems I've been > experiencing with suspend/resume. Definite progress. :) Could you, please, clarify. Does the resume work after this ? If not, how did you diagnosed that 'one of two problems' is solved with the change ? From owner-freebsd-current@freebsd.org Mon May 15 17:34: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 C2BBDD6D67A for ; Mon, 15 May 2017 17:34:18 +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 AA77622D for ; Mon, 15 May 2017 17:34:18 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [10.44.135.177] (nat-192-187-90-116.nat.tribpub.com [192.187.90.116]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id faea8aac TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO for ; Mon, 15 May 2017 10:34:17 -0700 (PDT) Subject: Re: regression suspend/resume on Lenovo T420 To: freebsd-current@freebsd.org References: <5746a37cd73e062c963512df1a6d24c6@email.freenet.de> <20170506090341.GA12163@freebsd-t420.fritz.box> <20170514193006.GA1298@brick> <1190.1494792172@critter.freebsd.dk> <20170515095647.GA1622@kib.kiev.ua> <20170515172725.GE1622@kib.kiev.ua> From: Pete Wright Message-ID: <0203e71c-657a-386e-55e1-1d1c4a0b48d9@nomadlogic.org> Date: Mon, 15 May 2017 10:34:16 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <20170515172725.GE1622@kib.kiev.ua> 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: Mon, 15 May 2017 17:34:18 -0000 On 05/15/2017 10:27, Konstantin Belousov wrote: > On Mon, May 15, 2017 at 02:37:16PM -0230, Jonathan Anderson wrote: >> On 15 May 2017, at 7:26, Konstantin Belousov wrote: >>> Try this. If it works, I will write a proper patch. >>> >>> diff --git a/sys/amd64/amd64/cpu_switch.S >>> b/sys/amd64/amd64/cpu_switch.S >>> index 33437ad16e6..9c0cd05ebea 100644 >>> --- a/sys/amd64/amd64/cpu_switch.S >>> +++ b/sys/amd64/amd64/cpu_switch.S >>> @@ -369,6 +369,11 @@ END(savectx) >>> * Resuming processor state from pcb. >>> */ >>> ENTRY(resumectx) >>> + movl $MSR_EFER,%ecx >>> + rdmsr >>> + orl $EFER_NXE,%eax >>> + wrmsr >>> + >>> /* Switch to KPML4phys. */ >>> movq KPML4phys,%rax >>> movq %rax,%cr3 >> Running drm-next (which has -CURRENT last merged somewhere around >> r317651), this patch fixes one of the two problems I've been >> experiencing with suspend/resume. Definite progress. :) > Could you, please, clarify. Does the resume work after this ? If not, > how did you diagnosed that 'one of two problems' is solved with the change ? I can confirm that suspending to a S3 state and resuming now works on the drm-next branch as well. this matches the previous behavior on my systems before recent updates which broke suspend/resume - so i believe this patch works from a functional POV. -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Mon May 15 17:38:03 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 5D4EED6D899 for ; Mon, 15 May 2017 17:38:03 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 E12627ED for ; Mon, 15 May 2017 17:38:02 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-wm0-x241.google.com with SMTP id d127so30195051wmf.1 for ; Mon, 15 May 2017 10:38:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=WJm7VG+CDzSYuW0asmnlgroTsiF3NjxIVLw5NBds2Wk=; b=bmBUogZ51YIzgnXrsBJKoXU2akWSVlpyy71Qw0bGbQbDr74t8fDtdeIExabnt+MZ8l ugu3ZSU6+P38NO8PGb0zprccPXifUCzyvo/KSyge0WbgTZf7Pf+4Cn2OVCqsz8B5m71R qtbrcux3aRQsOnDAuo9zziWSs/pyy5oIwn13NvumMYYwKWJQsj/3aU1Mx/YMwx5/dM/k Sswsg33di86cppaQfLyDiaHWOXCqax7/vHN4jJir1rZstI+KaV8z2rsOx5P5ftNfwr7/ hCosd172c/gkiunLSOgcU5uGGy8y6IIonNHI5Pg/ZBGagWbghu+x8BbIlthN5UaujRDn R/xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=WJm7VG+CDzSYuW0asmnlgroTsiF3NjxIVLw5NBds2Wk=; b=b+faPgMDwcBy9mRPONWF+7Rt3rU6SgozzkLhH5XOwrJ3rlqYnk6JV2W8ba54ZA8+eR D7xisW9W8rJZeeAkP9vXUCyHHuvkEz8l09RYRguuirXowJ+58vcIh5+ZgCZKJ7piB0BX hK+6bFWP84jBxTQDkX5CyWMKca0gtmqL4raG5tsJxe2OQ4Mlucm/0J/A3kDLfSQi20v2 ukCc0IhT/FivJvwDMHyAxFpvRD+zwwcaqzVJxexNvE8X0QZrZ1Anma0vTA06Ij9ZliCw ucszhTTmNwoU4jPjOOn+7uGL3zgnSgfowcxgj7Yek5JzFoxFQKuaIymeEK77PYHz6U9V 7DhA== X-Gm-Message-State: AODbwcDZiU88lzXFw6x4UYTMaTBQWv1mmN1OvyGdKNJSLjrrex1JUoof YUGieS+9cuarHQ== X-Received: by 10.28.127.193 with SMTP id a184mr5201395wmd.110.1494869881206; Mon, 15 May 2017 10:38:01 -0700 (PDT) Received: from brick (cpc92310-cmbg19-2-0-cust934.5-4.cable.virginm.net. [82.9.227.167]) by smtp.gmail.com with ESMTPSA id x133sm6869253wme.0.2017.05.15.10.38.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 May 2017 10:38:00 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Mon, 15 May 2017 18:37:58 +0100 From: Edward Tomasz Napiera??a To: Konstantin Belousov Cc: Poul-Henning Kamp , Manuel St?hn , freebsd-current@freebsd.org Subject: Re: regression suspend/resume on Lenovo T420 Message-ID: <20170515173758.GA1730@brick> Mail-Followup-To: Konstantin Belousov , Poul-Henning Kamp , Manuel St?hn , freebsd-current@freebsd.org References: <5746a37cd73e062c963512df1a6d24c6@email.freenet.de> <20170506090341.GA12163@freebsd-t420.fritz.box> <20170514193006.GA1298@brick> <1190.1494792172@critter.freebsd.dk> <20170515095647.GA1622@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170515095647.GA1622@kib.kiev.ua> User-Agent: Mutt/1.8.2 (2017-04-18) 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, 15 May 2017 17:38:03 -0000 On 0515T1256, Konstantin Belousov wrote: > On Sun, May 14, 2017 at 08:02:52PM +0000, Poul-Henning Kamp wrote: > > -------- > > In message <20170514193006.GA1298@brick>, Edward Tomasz =?utf-8?Q?Napiera=C5=82 > > a?= writes: > > > > >I've tried to verify that, and sadly it wasn't it for me. The commit > > >that does break resume for me is r316767. The current -CURRENT with > > >this one commit reverted ("svn merge -c -r316767 .") suspends and resumes > > >correctly, at least in VT; I decided to take X out of the picture for > > >now. > > > > I can confirm that this also makes resume work on my T430s running: > > > > FreeBSD 12.0-CURRENT #0 r318250M amd64 > > Try this. If it works, I will write a proper patch. > > diff --git a/sys/amd64/amd64/cpu_switch.S b/sys/amd64/amd64/cpu_switch.S > index 33437ad16e6..9c0cd05ebea 100644 > --- a/sys/amd64/amd64/cpu_switch.S > +++ b/sys/amd64/amd64/cpu_switch.S > @@ -369,6 +369,11 @@ END(savectx) > * Resuming processor state from pcb. > */ > ENTRY(resumectx) > + movl $MSR_EFER,%ecx > + rdmsr > + orl $EFER_NXE,%eax > + wrmsr > + > /* Switch to KPML4phys. */ > movq KPML4phys,%rax > movq %rax,%cr3 Thanks! The patch fixes resume for me, for both vt(4) and X11. From owner-freebsd-current@freebsd.org Mon May 15 17:42: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 C6C17D6DC2A for ; Mon, 15 May 2017 17:42:44 +0000 (UTC) (envelope-from jonathan@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 A5A65CB3; Mon, 15 May 2017 17:42:44 +0000 (UTC) (envelope-from jonathan@FreeBSD.org) Received: from [134.153.0.231] (unknown [127.0.1.132]) by freefall.freebsd.org (Postfix) with ESMTP id 653A359F7; Mon, 15 May 2017 17:42:43 +0000 (UTC) (envelope-from jonathan@FreeBSD.org) From: "Jonathan Anderson" To: "Konstantin Belousov" Cc: "Poul-Henning Kamp" , "Edward Tomasz Napiera??a" , "Manuel St?hn" , freebsd-current@freebsd.org Subject: Re: regression suspend/resume on Lenovo T420 Date: Mon, 15 May 2017 15:12:43 -0230 Message-ID: <70A6E833-37A3-45F1-BA61-95A2A4378DB4@FreeBSD.org> In-Reply-To: <20170515172725.GE1622@kib.kiev.ua> References: <5746a37cd73e062c963512df1a6d24c6@email.freenet.de> <20170506090341.GA12163@freebsd-t420.fritz.box> <20170514193006.GA1298@brick> <1190.1494792172@critter.freebsd.dk> <20170515095647.GA1622@kib.kiev.ua> <20170515172725.GE1622@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) 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, 15 May 2017 17:42:44 -0000 On 15 May 2017, at 14:57, Konstantin Belousov wrote: > On Mon, May 15, 2017 at 02:37:16PM -0230, Jonathan Anderson wrote: >> >> Running drm-next (which has -CURRENT last merged somewhere around >> r317651), this patch fixes one of the two problems I've been >> experiencing with suspend/resume. Definite progress. :) > > Could you, please, clarify. Does the resume work after this ? If > not, > how did you diagnosed that 'one of two problems' is solved with the > change ? Sorry, I'll try to clarify. My problems were: 1. since at least late March, I've had visual artifacts on resume that make the screen unusable; 2. more recently, the machine didn't resume at all. Applying your patch, I can successfully suspend to S3 and resume again, so problem #2 is resolved. This leaves me in a better position to try and test solutions for problem #1 (which might be an issue related to the Mar 13 firmware update on drm-next rather than a -CURRENT problem). Thanks, Jon -- Jonathan Anderson jonathan@FreeBSD.org From owner-freebsd-current@freebsd.org Mon May 15 17:46: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 E1ADCD6DF25 for ; Mon, 15 May 2017 17:46:43 +0000 (UTC) (envelope-from zaphod@berentweb.com) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 ADE91123D for ; Mon, 15 May 2017 17:46:43 +0000 (UTC) (envelope-from zaphod@berentweb.com) Received: by mail-qk0-x22f.google.com with SMTP id u75so104017835qka.3 for ; Mon, 15 May 2017 10:46:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb-com.20150623.gappssmtp.com; s=20150623; h=sender:date:from:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=l06OjsCJU7wX+q+s+OoS0lH5QoUOyU/8jwC5UPG+6KQ=; b=GtuqrZOvWNS2Pz32xSr4ijcd/grSZOOlxVb0ZYgn8MjNhwScmNxZW7hSpzrIRdPtTT aMeo0j4d/qukARW2lxnrVQ4+C6AM6TXDL0NAos+X7P0uFAKDwl7/DCeaizAcI41TosfT UUVNAflwNtlxGfmGUBhbI1/QuBnVlSZAth+LjQGgO2nuUSGQJjRAHQ/wJpuoI3nUNUrL efrN1YSWIub8UJ+cAMDgn28JhJ71kQFhYxTEeeP7Rgs/J4NLDUlQLEpKmR90V/AkO3G9 8BmpBpZh5R680Y5RHmXgXEFzzohWKEoGIHwXRgqpRkea3XtXGIZqPPgLA+e0gJ54Q6Qp 9Oeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:cc:subject:message-id :in-reply-to:references:mime-version:content-transfer-encoding; bh=l06OjsCJU7wX+q+s+OoS0lH5QoUOyU/8jwC5UPG+6KQ=; b=prN5HB2hh4ys0Zy8/90lIw5YQ4MCILaLACgSb73kQ1mkq8r3/SZLKkupcHrNb06YIg b3N6p7THWwiF2Q7L+DnfF1JNBwaWHsLbBUfX8ZccpYHfAb9xxwcrjyJ7NMQCPP4cTFd+ 2ataA8lyRymz7TzH86gdYBMqsAa1nfMlpHChrfxFnRcFL7gvT6q9Io6avwBTJynbZeIY coDVwJJpw0buwucGjZ0/uACdZEW0L5mnPcZA2At0mSwQXR+3dQLTXNJTWZELUNVFt4xU cNksc6QTvei24hKnXeqcgf6HPn+XR7qIeyxSvf94Px3lapClJA95nBMJFlyxlRRrLD2k ZO/A== X-Gm-Message-State: AODbwcBinIG5zihXaRg7efL5Siamxh5fzSVEmhVGigj9CCUZg4pGbrsZ Kdk75YRC0HoelWQt X-Received: by 10.55.108.196 with SMTP id h187mr6347002qkc.40.1494870402487; Mon, 15 May 2017 10:46:42 -0700 (PDT) Received: from rsbsd ([24.133.238.42]) by smtp.gmail.com with ESMTPSA id t66sm638528qkt.29.2017.05.15.10.46.40 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 15 May 2017 10:46:41 -0700 (PDT) Sender: "Raif S. Berent" Date: Mon, 15 May 2017 20:46:27 +0300 From: Beeblebrox Cc: freebsd-current Current Subject: Re: Anyone having ccache errors? Message-ID: <20170515204613.11b37643@rsbsd> In-Reply-To: References: <20170515112003.49aef487@rsbsd> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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, 15 May 2017 17:46:44 -0000 > Upgrade make =E2=80=94 it was a bug with it, fixed in the past few days. > HTH, I just rebuilt and installed a clean world without using ccache After reboot I tried buildworld with ccache enabled, but got same error. So, did not work unless you meant a particular port? --=20 FreeBSD_amd64_12-Current_RadeonKMS Please CC my email when responding, mail from list is not delivered. From owner-freebsd-current@freebsd.org Mon May 15 17:48:59 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F31B9D6E135 for ; Mon, 15 May 2017 17:48:59 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::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 B59F615C1 for ; Mon, 15 May 2017 17:48:59 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-io0-x230.google.com with SMTP id k91so78491168ioi.1 for ; Mon, 15 May 2017 10:48:59 -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=05BBuVigz3UshIHb0k4s/yAG5MmcMpoRpAzwweK6t5M=; b=LvM8EF+Vv4SeBcoANHgEDbeU4bSQqpJMh2SoIkdZZdAkJuJaH3TfVEmtI5sqxvrtqR o/k3RPGVJJJw4upIfK2uRNE2bLz1yBouaKOCQKsMldML7WDRstp8GUHWtpWF+m3j+nH3 ZqBtppPuP96kcKigpoeqNodR6rP3PJN9EKtllJujSZJmZClyyeSlE6yBylniYxScb/jU 5u7vsjAJQMtwNd1/rgcXGvxB5zWcKQ2oB6eBLhU446r35XuHXUzQG3OTzbxJTXrPmVeq GLXI3AUUe8bmSQkeCJTq+dLZ2TcK+diQqq+FvuBvAXVTPnWGKP1nTBmlpHRmPCaffHuB iQGg== 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=05BBuVigz3UshIHb0k4s/yAG5MmcMpoRpAzwweK6t5M=; b=r78C0OaIjvFGpwZd6pyyVtYYTHBoBkIKz6lXea5PFP2/f+A9RQaEIx0N+tgoO8/Vyx VGw8Bc3bPKCIg2jQIhO5/noqhto6eienZDnRrmc193f/z97e8NvqoPrgDOA8fqI4p2eo DjwFC0dDI2xOwRwnNvHXViPWXVvRATIhKpDIIbuq8piyrJV98mfqNVIs2/YlNCpsevr+ Yy6061iOWsXejPUArV0d5Y5a8uU/FrVvgsnARDMOM66xJrMBbtspSZ2E2PYfBYjhJetI TURRz5Z7IYTT+th5aSTtqGvmmEzHBF6P49cr8MxihJxHiOLHp+WrvD39ATBV942Oo3hr wbmg== X-Gm-Message-State: AODbwcDxCYe1LTWEqR302+ja3QiOukz0OyTz/43C8FxJMjyfU5E5wh9G HWFBShjr6UPmi03np5Y= X-Received: by 10.107.135.100 with SMTP id j97mr6674107iod.16.1494870539154; Mon, 15 May 2017 10:48:59 -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 i74sm4820955itb.5.2017.05.15.10.48.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 15 May 2017 10:48:58 -0700 (PDT) Subject: Re: Anyone having ccache errors? Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F4D3D0C7-A985-479E-A7F3-1C226AA1DE7D"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Ngie Cooper (yaneurabeya)" In-Reply-To: <20170515204613.11b37643@rsbsd> Date: Mon, 15 May 2017 10:48:57 -0700 Cc: freebsd-current Current Message-Id: References: <20170515112003.49aef487@rsbsd> <20170515204613.11b37643@rsbsd> To: Beeblebrox 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: Mon, 15 May 2017 17:49:00 -0000 --Apple-Mail=_F4D3D0C7-A985-479E-A7F3-1C226AA1DE7D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 15, 2017, at 10:46, Beeblebrox wrote: >=20 >> Upgrade make =E2=80=94 it was a bug with it, fixed in the past few = days. >> HTH, >=20 > I just rebuilt and installed a clean world without using ccache > After reboot I tried buildworld with ccache enabled, but got same = error. >=20 > So, did not work unless you meant a particular port? I was looking at the "make: Unknown modifier =E2=80=98c=E2=80=99=E2=80=9D = warnings =E2=80=94 which were a symptom of the bug that was fixed late = last week. I don=E2=80=99t genuinely know if ccache works or doesn=E2=80=99= t work. Thanks, -Ngie --Apple-Mail=_F4D3D0C7-A985-479E-A7F3-1C226AA1DE7D 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 iQIcBAEBCgAGBQJZGeoJAAoJEPWDqSZpMIYVWooP/3ONV6ltSBhmqjRk6w7CMxqU QcgKxD6BziU0NGsHicu65lj8q/i028i8Ei5v2qan5EMfVA1dHKQJOFrFBxGTW7K2 xRd4vqt07iKCCyIOZkRIjR5Dgz/4O5qozmN3ZoXCrHbykTwZnk2mWS7ijHG3wmYO 0UOJ9GMT/GNF73vUhdE5QBnnKPAZkUioH4lkVSIzcTFaY6zKTiKMF770NNM3iUXz 4vnTTLxWz8VvzyxsisuUzHeX2HHBf7lX0vGl7eEjBssXgl2aFkt0sph7TEDvryET Te9Atkj7uT+WW6ASrnKa1E3BKmVlSAXeGejlNEGIlu431Z78fxTFLIlk6Ib4vjbu iT7i2hlDyqewYMoHqFl+KEnWrWutX9fo8c7QLMwJblfbf9bSrUrf4VDYniTvMf7x CEsUaJ1fAnGfb7vZN6j1DUMFo87iR77Q/GSxdmt+5XPYwYE8qrVczi4bjiZ9tNM6 dFXoaiyRxVQBlnB+P43HanIs5FiNVPL3OGk1KuhkeCzwiO7dhFI2mw8k5R8xV0Pj NzcHEjWNnrL9zX9slSWtnolEcHlk7i3PlKKotzZZk6KEtH0zVrusy1RPqCFmTtRb L6/APzKvPKL0/9ma4nLFw6xZEAcyGdvbJaCaBNEljaVN3ihIvsZx585K2pE7LUR+ YjEQzq0kikS9IbAMixn5 =jsmZ -----END PGP SIGNATURE----- --Apple-Mail=_F4D3D0C7-A985-479E-A7F3-1C226AA1DE7D-- From owner-freebsd-current@freebsd.org Mon May 15 17:51:55 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 858BBD6E5D7; Mon, 15 May 2017 17:51:55 +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 4A7F81DDE; Mon, 15 May 2017 17:51:54 +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 1dAK9v-0004aQ-De; Mon, 15 May 2017 19:51:51 +0200 Received: from mail by rmmprod05.runbox with local (Exim 4.86_2) (envelope-from ) id 1dAK9v-0006wx-9u; Mon, 15 May 2017 19:51:51 +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, 15 May 2017 17:51:51 GMT From: "Jeffrey Bouquet" Reply-To: To: "Tomoaki AOKI" CC: "freebsd-current" , "freebsd-ports" Subject: Re: [RFC] rename nvidia-driver port binaries [ and other comments] Date: Mon, 15 May 2017 10:51:51 -0700 (PDT) X-Mailer: RMM6 In-Reply-To: <20170515235310.9f60289e486c202cc5be7978@dec.sakura.ne.jp> 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, 15 May 2017 17:51:55 -0000 On Mon, 15 May 2017 23:53:10 +0900, Tomoaki AOKI wrote: > Hi. > If including its version to nvidia.ko and nvidia-modeset.ko, > [hard / symbolic] link to it with current name should be needed > not to bother admins every time upgrading. >=20 > BTW, I personally using below in rc.conf for safety. > This only helps situations that... >=20 > *Insufficient loader memory, but OK after kernel is started. >=20 > *Accidentally backed to older version that doesn't have > nvidia-modeset.ko and only nvidia-modeset.ko is written in > /boot/loader.conf. >=20 > ## Temporary settings for nvidia-driver when failed loading via loader.co= nf > kldstat -q -n nvidia.ko > if [ 0 -ne $? ] ; then > echo "Loading nvidia-driver modules via rc.conf." > # kldload nvidia > if [ -e /boot/modules/nvidia-modeset.ko ] ; then > # kldload nvidia-modeset > kld_list=3D"${kld_list} nvidia-modeset.ko" > else > # kldload nvidia > kld_list=3D"${kld_list} nvidia.ko" > fi > fi >=20 >=20 > On Mon, 15 May 2017 06:41:33 -0700 (PDT) > "Jeffrey Bouquet" wrote: >=20 > > Just had a unique to me, unbootable backup [beside the point, > > just a sidebar comment... ] quandry dealing with the nvidia-driver upd= ate > > that mesa-libs needed. [ or was appurtenant to it, unsure... ] > >=20 > > 12.0 - CURRENT > >=20 > > [ my previous 'saves' -- files to consult... were in .jpg, so no ava= il for me to peruse as I was in the terminal ] > >=20 > > Lessons I learned, maybe > >=20 > > [RFC] rename nvidia-driver.ko to include its version, for instance nvi= dia-modeset-37539.ko > > which would make one's diagnosis a fix easier.=20 > >=20 > > [suggestions] > >=20 > > ... Document that the kernel will load a /boot/modules/_nvidia.ko if yo= u'd thus made it 'unavailable' > > ... document better that one can load nvidia[modeset] later than /boot/= loader.conf [cli, rc.conf...] > >=20 > > [ mini 'what fixed it for you ' and/or stalled the same ...=20 > > ]=20 > > ... I had a make.conf in place, 'trapping' a > > make -DMAKE_JOBS_UNSAFE=3Dyes CC=3D".../clang39" [and the other tw= o...] install in failure > > ... I had no clue if Xorg was at fault, and luckily did not have to reb= uild. > > ... I had no access to the forums, as the desktop could not be loaded [= yet] > > ... I had to do strings nvidia.ko |grep 26 [39] | less to detect the no= t usable module numbers, > > THUS THE REQ FOR RENAME of the nvidia.ko binary [vs port] to includ= e its 5 digit number > > as above. > > ... I was taken aback by the less infomative > > this client has the .39 but the module has the .26 ...=20 > > specifically stating which file/port/kernel module the 'client' ref= ers to > > and which specific modules 'this module' was referring to. Unknown = if that is > > fixable here in a .c, .h , or is closed-source upstream in nvidia [c= orp ] where we can > > ask them to be more specific or code in some more verbose error mes= sages. > > ... Relieved I did not have to rebuild Xorg nor the kernel, just move = files out of the > > way and do a simple rebuild of the nvidia-driver. > > [... Not relieved that the nvidia-driver needed install during the mesa= -lib reshuffle, maybe > > did not need to be, just a hazy recollection on my part. So ignore = this little bit ] > >=20 > > ... All in all a learning experience. Howsoever, I would like this nvi= dia stuff to be put eventuall > > in /usr/src/UPDATING so the half or third of persons who run into this= yearly will have a more > > authoritative flowchart of sorts to determine the next course of actio= n. > > something like > > if ... this thta > > if... this that > > if ... this that > > OTOH... error message... a... you may need to... > > ... > > error message ... r... you may need to... > >=20 > > ... And it would have maybe saved a bit of time here, and I would almo= st if eventually > > possible be sure to copy /usr/src/UPDATING to /usr/ports/x11/nvidi= a-driver for > > more easy access if the desktop was broken.... > >=20 > >=20 > > Apologies for the hurried post. Indeed, I have tasked myself to write i= t up here > > locally [ still in scribbled notations...] so I can forestall/fix more = quickly this > > error the next time. > > also... > > Running late in other personal matters, and out of time. > >=20 > > Respectfully.. > >=20 > > J. Bouquet=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.o= rg" > >=20 >=20 >=20 > --=20 > Tomoaki AOKI I found just then that one can load it manually first, though the nvidia.ko [ one has newly built ] THEN the nvidia-modeset.ko=20=20 if it has not been loaded via /boot/loader.conf which did not load it in the session in which I am typing this, for example. [ wondering if /usr/ports/UPDATING or the pkg-message should be=20 updated to state that... upon a second verification ... ]=20 YMMV=20= From owner-freebsd-current@freebsd.org Mon May 15 18:01: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 03AEFD6EA41 for ; Mon, 15 May 2017 18:01:20 +0000 (UTC) (envelope-from zaphod@berentweb.com) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B08299FF for ; Mon, 15 May 2017 18:01:19 +0000 (UTC) (envelope-from zaphod@berentweb.com) Received: by mail-qt0-x235.google.com with SMTP id c13so42201898qtc.1 for ; Mon, 15 May 2017 11:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb-com.20150623.gappssmtp.com; s=20150623; h=sender:date:from:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=FX7ZhdTyDHVhUxfO4oAmxC+6knOjmAwdakguaiW1184=; b=toXR/vjXHEWzF7+iQaZd+77HBdFaaXuulc2vLxZPDpFY6ePmYPGaJ7SZ/IVBFfQca5 W2aiOPTlXVD5c+w1v2mciVVy59Tf0Jf9jxqtlRq9d692Guv+BrtQFsrZYPKb5KFLdsPJ 9VmtDBPrce0RPX6QouulqlYEcpoE9cjNih/4w8R5OcFX/DbhnLJ7ldZUmYzwJPFcXWXL XAyPFB4uMmgoOl5EY1JU29w0gsUnQqIIDiZ9Z8x1q0V6nkqhZf2k34Jh6prNK0Yl6eAQ 5kk0QPiAKRaXe56t7YJDCM5XncgZjAweQqZepsWdJio/Uqg5WxhyXxCQJjjdMmyiVWpE 4n5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:cc:subject:message-id :in-reply-to:references:mime-version:content-transfer-encoding; bh=FX7ZhdTyDHVhUxfO4oAmxC+6knOjmAwdakguaiW1184=; b=tV7q96POdgf9E+EZ9pmybxHQn5ku7YffOPhiSZvWkm/J1SjNb7e8jatLPZTrWJ6pFb lg8WuApO1v26PfWQcf+hUttyDoX7X+6+jvDRar2n7Yb5+pzVNqJVnhk2uIufUn/gr3gd jk6vwhLEcZplDeN9OLw+/NvSlPfyRBhhlHWfsYqVzRp9lIwDC+M7cUfitRN3rSmFAkrI aKG2pzzYwX7dE5CBiQyuxBx9XvkpPTto/OOrfTxvP/mdsHOatp0AZaCLj7MKYydJrKXs CGAc9kYP7In+Ef8f/xfcUr6lZ2f3awatKRDMRtBG6pL8H12EthqatocI86sqKbs7KTh0 +rLQ== X-Gm-Message-State: AODbwcBeUKo66/awggMciLqrpiu7r/mp+nUtnpa9Ud3qVFJAfP7war4Q hG6yC5znXB3rT6kG X-Received: by 10.200.41.105 with SMTP id z38mr6740104qtz.270.1494871278380; Mon, 15 May 2017 11:01:18 -0700 (PDT) Received: from rsbsd ([24.133.238.42]) by smtp.gmail.com with ESMTPSA id a76sm8945297qkj.42.2017.05.15.11.01.16 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 15 May 2017 11:01:17 -0700 (PDT) Sender: "Raif S. Berent" Date: Mon, 15 May 2017 21:01:04 +0300 From: Beeblebrox Cc: freebsd-current Current Subject: Re: Anyone having ccache errors? Message-ID: <20170515210057.2c90eed0@rsbsd> In-Reply-To: References: <20170515112003.49aef487@rsbsd> <20170515204613.11b37643@rsbsd> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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, 15 May 2017 18:01:20 -0000 > I was looking at the "make: Unknown modifier =E2=80=98c=E2=80=99=E2=80=9D= warnings =E2=80=94 which > were a symptom of the bug that was fixed late last week. I don=E2=80=99t > genuinely know if ccache works or doesn=E2=80=99t work. Thanks, -Ngie Thanks, I still do see those exact "make: Unknown modifier =E2=80=98c=E2=80=99=E2= =80=9D warnings along with the original fail. --=20 FreeBSD_amd64_12-Current_RadeonKMS Please CC my email when responding, mail from list is not delivered. From owner-freebsd-current@freebsd.org Mon May 15 18:15:37 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 1F58DD6E481 for ; Mon, 15 May 2017 18:15:37 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::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 DEA0A18AE for ; Mon, 15 May 2017 18:15:36 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pf0-x22a.google.com with SMTP id e193so66983790pfh.0 for ; Mon, 15 May 2017 11:15:36 -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=aWe5Hkv+Tp4gIssAhiae/FwsUar/uwu3A8MiRttbRpo=; b=q6RSZTyzbelZt+hCe2EZumuPVj29CXV3L+W8NXk8pZkR2Ufgb2m62wfrxyEUEEu+c8 e6imoInqvjURXWrUP7XcIkcBdjt+2zXXgzwYzCLgVeH/1GydQFHBbiI1J39UF1HiQR1q IZIVQQ5I4gZQCdvHI36ifct26iqwVwsDaOneMdXAkVLCiPEkCeMm5T0EMWvX78cpmIbR lQqHw/n6/q4YQQE9P4F/54H/XyGAfax34HaLouR6cpCt4hneD8vpRp0tk4jAugV9k9Do 4v7p3jvmRx/6Okavzt5tIkDeEBDJx1wQ4br8OtPV/OZE8LQcRVHQE9TV+n3Di6OQH0FY M4SQ== 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=aWe5Hkv+Tp4gIssAhiae/FwsUar/uwu3A8MiRttbRpo=; b=FmcJLGT7SbAIlzwfwx+QOC3+/n3N9gg12ZHe1cLVeFnJ0uUaJ8RmGFDBWB55GwTB5+ APSormB2njVVbNMxgHAFLk2nUZ/xYlxjYhaaZHN0ChDrlbfR/L9ZiZuX28+cfo6MVtSk 76z5Zf8Y5R5ksb9lhovtme+Trpro79IW+ut2kew4vJhFz/THXc4v8JtLg2eCy2j3PFFg otww/Sm45WXXYje0prmJF2LO1qIrA58Z4VDG7PHfzwohbcy/cas6b3s97h/smLq627a/ PLzhkMrutH8hM94YNyOuvZhY7ZmM003eVA5iL+2U46UMHfGcQE1WbB59yF7e+rnVQ8lJ ozug== X-Gm-Message-State: AODbwcBtjy7VPRUw61HvhjHZTOK5Picqubv/T/uvYTU6c7sjiZ1GscXi U8FYc3Xi1Ry4UKy4P0g= X-Received: by 10.84.233.205 with SMTP id m13mr10247076pln.72.1494872136510; Mon, 15 May 2017 11:15:36 -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 a19sm21895967pfe.81.2017.05.15.11.15.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 15 May 2017 11:15:35 -0700 (PDT) Subject: Re: Anyone having ccache errors? Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7FADEB9B-2E73-4DCC-9946-49C2B0E5238C"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Ngie Cooper (yaneurabeya)" In-Reply-To: <20170515210057.2c90eed0@rsbsd> Date: Mon, 15 May 2017 11:15:34 -0700 Cc: freebsd-current Current Message-Id: <320A6363-65D8-46CF-9265-23B4E638125A@gmail.com> References: <20170515112003.49aef487@rsbsd> <20170515204613.11b37643@rsbsd> <20170515210057.2c90eed0@rsbsd> To: Beeblebrox 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: Mon, 15 May 2017 18:15:37 -0000 --Apple-Mail=_7FADEB9B-2E73-4DCC-9946-49C2B0E5238C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 15, 2017, at 11:01, Beeblebrox wrote: >=20 >> I was looking at the "make: Unknown modifier =E2=80=98c=E2=80=99=E2=80=9D= warnings =E2=80=94 which >> were a symptom of the bug that was fixed late last week. I don=E2=80=99= t >> genuinely know if ccache works or doesn=E2=80=99t work. Thanks, -Ngie >=20 > Thanks, > I still do see those exact "make: Unknown modifier =E2=80=98c=E2=80=99=E2= =80=9D warnings > along with the original fail. More up-to-date information would help someone trying to diagnose your = issue. Based on the original report, you are currently using sources = from April 20th, which means that you would be affected by the bmake = bug. Would you please execute the following and attach your output? $ make -VMAKE_VERSION 20170510 Thanks, -Ngie --Apple-Mail=_7FADEB9B-2E73-4DCC-9946-49C2B0E5238C 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 iQIcBAEBCgAGBQJZGfBHAAoJEPWDqSZpMIYVmf4QAIFntuXsdb3GkOHv7CZlO4Cu xt+6R5ustj5WVtNWi48o2DyIaRa8nHx3XWds6lMxE00ZNiKGHXmZumJ+0sPEw9b/ RD9U2Uld/DXGNPy5Bvd81XIDRL3bVo8rQi4JO52VuGox1AuHmEdfQmNLLNBxB98U smxf3FJIEfn3J+lnmAZqonax2xHEEA0n//hf6RMpsyGMPrU/WpJSh7LAv7FYIHZ9 XkQBZ0sg0rW4SNumOkObHtvgJwuCpNGtDIojbJx8xkOgQ8Wh6/db1SHiq3Mfthdm i/o8ayZM5c9puCqSph4OaDgn49OS9CqM0ijaoRcNOeFjoSLLRnPlS39Ue+Vrcftp 536mI+OUVECMJjkRN1j9+qHmi+v689zYJnSKG8dtl4wFmSkbQIorFcuVyPw6ZbDc xWVMejm6mNRRlRJ/+7zy3NU+ljG5Pm2rWF087WZ1X1Ed4CwmpCq8w6InKfigjcpL 3XSX32ISux12oyyQdnfiXBRnZrYVzfYD9V+rGo0bK75c8/FPeOZ1ID6NilaEDNFt z4v8hLmLf8pEuUHkO7Q/0F5BJn2y4faqNM6kBrB2frvyWMMb/jsttKljiJ/wNIga mUTOb+T12gx1xooBu5xxvxbrVN1NAGe2TE9wIGp4N7PUghZgBngTSJDe5/ZGHwfq XxmZgQC4DEzLSqvhRDYU =lYYc -----END PGP SIGNATURE----- --Apple-Mail=_7FADEB9B-2E73-4DCC-9946-49C2B0E5238C-- From owner-freebsd-current@freebsd.org Mon May 15 18: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 4BA72D6EBF0 for ; Mon, 15 May 2017 18:33:51 +0000 (UTC) (envelope-from zaphod@berentweb.com) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 039CABBB for ; Mon, 15 May 2017 18:33:51 +0000 (UTC) (envelope-from zaphod@berentweb.com) Received: by mail-qk0-x22f.google.com with SMTP id y201so106034622qka.0 for ; Mon, 15 May 2017 11:33:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb-com.20150623.gappssmtp.com; s=20150623; h=sender:date:from:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=IzDc+/K+qkrLuP98tO9216topZA4/o7uzyVkcagsL4E=; b=PwnmPqQ7bH0f4vuzWReFKTn1m0Dl6ditK0OuQXHuFVDd8wq3Knpck/Eu9/Mn6JBesa EeNCIJ182G5NDwdEEqV13jkfI3kjtKDdlwm8cYlx+11UKM0ALO2kFl8ca4xCIaeGIB0o doWy9MpBNGIf0ZizGQTq4xxiQgv10jn5gmBufulvX5Z3kuCbnAlRPtAMfEXjpDm3nU6U hDyHruZXEYqWEvp+HZrMzQNxCUvs3MeonlkfpdEhQ/9ncwbmfNLiIMxq7IMeVwngXXVF mPQeSCGxFMFfdStRKzn9jeHJq1ANwPHu9vUo2hxmLgJDzQo/Vvn1GdqEV3mmCPWznBYo ExuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:cc:subject:message-id :in-reply-to:references:mime-version:content-transfer-encoding; bh=IzDc+/K+qkrLuP98tO9216topZA4/o7uzyVkcagsL4E=; b=qx6hQo19sJYVOi49OKWMMLCYP2/yBI7/OfWZfI7TDrgYdQrzqwbRekJnsa3+is0P4n it84ZXv0X+5SLCMEu0bX1nWmx5F9oWkWTw0mRDXoQszefDJ7gVbCOYcQ5FFWzPH4VENX zL8vdY0fX227Dow/DBwkwscx0y9K35VSLoAQOr+LpbXnc3T+Mw55h1OMLmGc6Tfp7wX4 ArlylO6ORI33XhmM8tDLxfuZQX94+952IyauNHECa/LXQJsJui3kY4cwJhWJf0k1jGIT zQSbEdqkTJNXKIz+cIjsp6GBV1LZZSobQ5pgE57Fpzejp6XA7lqqDEkW3hoKbGlxnjK2 LfQw== X-Gm-Message-State: AODbwcAe0LkPh4TX5/R7wUFRMh14dbtWj4DzMVuUHA8Jiz+2Z0R7mhIH XXj8yEZ9zpJT0jzO X-Received: by 10.55.69.72 with SMTP id s69mr6115320qka.175.1494873229863; Mon, 15 May 2017 11:33:49 -0700 (PDT) Received: from rsbsd ([24.133.238.42]) by smtp.gmail.com with ESMTPSA id b23sm9484776qkb.31.2017.05.15.11.33.47 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 15 May 2017 11:33:48 -0700 (PDT) Sender: "Raif S. Berent" Date: Mon, 15 May 2017 21:33:35 +0300 From: Beeblebrox Cc: freebsd-current Current Subject: Re: Anyone having ccache errors? Message-ID: <20170515213328.606281a8@rsbsd> In-Reply-To: <320A6363-65D8-46CF-9265-23B4E638125A@gmail.com> References: <20170515112003.49aef487@rsbsd> <20170515204613.11b37643@rsbsd> <20170515210057.2c90eed0@rsbsd> <320A6363-65D8-46CF-9265-23B4E638125A@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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, 15 May 2017 18:33:51 -0000 > Would you please execute the following and attach your output? > $ make -VMAKE_VERSION make ver: 20170510 uname -U: 1200030 In my original post I also stated: also getting "cc not found" errors whether ccache is enabled or not. For example installworld (no ccache) broke with that message so I decided to re-build. So there's some strange clang stuff going on... --=20 FreeBSD_amd64_12-Current_RadeonKMS Please CC my email when responding, mail from list is not delivered. From owner-freebsd-current@freebsd.org Mon May 15 18:41: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 EF4B0D6EEFE for ; Mon, 15 May 2017 18:41:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 93BE21377; Mon, 15 May 2017 18:41:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v4FIewJV091356 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 15 May 2017 21:40:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v4FIewJV091356 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v4FIewHH091339; Mon, 15 May 2017 21:40:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 15 May 2017 21:40:58 +0300 From: Konstantin Belousov To: Poul-Henning Kamp , Manuel St?hn , Jonathan Anderson , freebsd-current@freebsd.org Subject: Re: regression suspend/resume on Lenovo T420 Message-ID: <20170515184058.GF1622@kib.kiev.ua> References: <5746a37cd73e062c963512df1a6d24c6@email.freenet.de> <20170506090341.GA12163@freebsd-t420.fritz.box> <20170514193006.GA1298@brick> <1190.1494792172@critter.freebsd.dk> <20170515095647.GA1622@kib.kiev.ua> <20170515173758.GA1730@brick> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170515173758.GA1730@brick> User-Agent: Mutt/1.8.2 (2017-04-18) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 18:41:06 -0000 On Mon, May 15, 2017 at 06:37:58PM +0100, Edward Tomasz Napiera??a wrote: > Thanks! The patch fixes resume for me, for both vt(4) and X11. Thanks everybody for testing, patch below should be committable, modulo bugs. I did not tested it and ask for the same test as the previous debugging patch. diff --git a/sys/amd64/acpica/acpi_wakecode.S b/sys/amd64/acpica/acpi_wakecode.S index 6b36d55e7d2..a63b5b8b769 100644 --- a/sys/amd64/acpica/acpi_wakecode.S +++ b/sys/amd64/acpica/acpi_wakecode.S @@ -156,11 +156,12 @@ wakeup_32: /* * Enable EFER.LME so that we get long mode when all the prereqs are * in place. In this case, it turns on when CR0_PG is finally enabled. - * Pick up a few other EFER bits that we'll use need we're here. + * Also it picks up a few other EFER bits that we'll use need we're + * here, like SYSCALL and NX enable. */ movl $MSR_EFER, %ecx - rdmsr - orl $EFER_LME | EFER_SCE, %eax + movl wakeup_efer - wakeup_start(%ebx), %eax + movl wakeup_efer + 4 - wakeup_start(%ebx), %edx wrmsr /* @@ -276,6 +277,8 @@ wakeup_pcb: .quad 0 wakeup_ret: .quad 0 +wakeup_efer: + .quad 0 wakeup_gdt: .word 0 .quad 0 diff --git a/sys/amd64/amd64/cpu_switch.S b/sys/amd64/amd64/cpu_switch.S index 33437ad16e6..86198ab1a8c 100644 --- a/sys/amd64/amd64/cpu_switch.S +++ b/sys/amd64/amd64/cpu_switch.S @@ -396,7 +396,7 @@ ENTRY(resumectx) movl 4 + PCB_KGSBASE(%rdi),%edx wrmsr - /* Restore EFER. */ + /* Restore EFER one more time. */ movl $MSR_EFER,%ecx movl PCB_EFER(%rdi),%eax wrmsr diff --git a/sys/x86/acpica/acpi_wakeup.c b/sys/x86/acpica/acpi_wakeup.c index 4a10ac7b304..74f4fedc28f 100644 --- a/sys/x86/acpica/acpi_wakeup.c +++ b/sys/x86/acpica/acpi_wakeup.c @@ -223,7 +223,9 @@ acpi_sleep_machdep(struct acpi_softc *sc, int state) WAKECODE_FIXUP(resume_beep, uint8_t, (acpi_resume_beep != 0)); WAKECODE_FIXUP(reset_video, uint8_t, (acpi_reset_video != 0)); -#ifndef __amd64__ +#ifdef __amd64__ + WAKECODE_FIXUP(wakeup_efer, uint64_t, rdmsr(MSR_EFER)); +#else WAKECODE_FIXUP(wakeup_cr4, register_t, pcb->pcb_cr4); #endif WAKECODE_FIXUP(wakeup_pcb, struct pcb *, pcb); From owner-freebsd-current@freebsd.org Mon May 15 18:51:19 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 6A9B1D6E44F for ; Mon, 15 May 2017 18:51:19 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from mout3.freenet.de (mout3.freenet.de [IPv6:2001:748:100:40::2:5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.freenet.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 30E8270 for ; Mon, 15 May 2017 18:51:19 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from [195.4.92.142] (helo=mjail2.freenet.de) by mout3.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (port 25) (Exim 4.85 #1) id 1dAL5O-0004tV-QE; Mon, 15 May 2017 20:51:14 +0200 Received: from localhost ([::1]:37382 helo=mjail2.freenet.de) by mjail2.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.85 #1) id 1dAL5O-0000ik-MK; Mon, 15 May 2017 20:51:14 +0200 Received: from mx17.freenet.de ([195.4.92.27]:40950) by mjail2.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.85 #1) id 1dAL3H-0007Hc-MC; Mon, 15 May 2017 20:49:03 +0200 Received: from p5ddd4a8e.dip0.t-ipconnect.de ([93.221.74.142]:56483 helo=[192.168.178.45]) by mx17.freenet.de with esmtpsa (ID freebsdnewbie@freenet.de) (TLSv1.2:DHE-RSA-AES128-SHA:128) (port 587) (Exim 4.85 #1) id 1dAL3H-0003dZ-Is; Mon, 15 May 2017 20:49:03 +0200 Subject: Re: regression suspend/resume on Lenovo T420 To: Konstantin Belousov Cc: freebsd-current@freebsd.org References: <5746a37cd73e062c963512df1a6d24c6@email.freenet.de> <20170506090341.GA12163@freebsd-t420.fritz.box> <20170514193006.GA1298@brick> <1190.1494792172@critter.freebsd.dk> <20170515095647.GA1622@kib.kiev.ua> From: =?UTF-8?Q?Manuel_St=c3=bchn?= Message-ID: <9ef73eef-bfb7-0980-3da6-03a28ee18a0a@freenet.de> Date: Mon, 15 May 2017 20:49:02 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <20170515095647.GA1622@kib.kiev.ua> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originated-At: 93.221.74.142!56483 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, 15 May 2017 18:51:19 -0000 On Mon, 15 May 2017 12:56:47 +0300, Konstantin Belousov wrote > On Sun, May 14, 2017 at 08:02:52PM +0000, Poul-Henning Kamp wrote: >> -------- >> In message <20170514193006.GA1298@brick>, Edward Tomasz =?utf-8?Q?Napiera=C5=82 >> a?= writes: >> >>> I've tried to verify that, and sadly it wasn't it for me. The commit >>> that does break resume for me is r316767. The current -CURRENT with >>> this one commit reverted ("svn merge -c -r316767 .") suspends and resumes >>> correctly, at least in VT; I decided to take X out of the picture for >>> now. >> >> I can confirm that this also makes resume work on my T430s running: >> >> FreeBSD 12.0-CURRENT #0 r318250M amd64 > > Try this. If it works, I will write a proper patch. > > diff --git a/sys/amd64/amd64/cpu_switch.S b/sys/amd64/amd64/cpu_switch.S > index 33437ad16e6..9c0cd05ebea 100644 > --- a/sys/amd64/amd64/cpu_switch.S > +++ b/sys/amd64/amd64/cpu_switch.S > @@ -369,6 +369,11 @@ END(savectx) > * Resuming processor state from pcb. > */ > ENTRY(resumectx) > + movl $MSR_EFER,%ecx > + rdmsr > + orl $EFER_NXE,%eax > + wrmsr > + > /* Switch to KPML4phys. */ > movq KPML4phys,%rax > movq %rax,%cr3 > This patch makes resume work on my machine also (at least in VT; X is unfortunately still not working). From owner-freebsd-current@freebsd.org Mon May 15 18:39: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 619FDD6EE60 for ; Mon, 15 May 2017 18:39:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4B1FC117A for ; Mon, 15 May 2017 18:39:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 47BC7D6EE5E; Mon, 15 May 2017 18:39: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 476B8D6EE5D for ; Mon, 15 May 2017 18:39:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 373551178 for ; Mon, 15 May 2017 18:39:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4FIdsUw046388 for ; Mon, 15 May 2017 18:39:57 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: current@FreeBSD.org Subject: [Bug 218849] Remove rc.conf jail configuration via jail_* variables Date: Mon, 15 May 2017 18:39:54 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: conf X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: jonathan@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: mfc-stable9- mfc-stable10- mfc-stable11- X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 15 May 2017 19:01: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, 15 May 2017 18:39:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218849 Jonathan Anderson changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan@FreeBSD.org --- Comment #27 from Jonathan Anderson --- (In reply to Miroslav Lachman from comment #26) > ezjail is not the only one tool to manage jails and should not be used > to take FreeBSD base as hostage. There are many alternatives and migration > path is very trivial. > > It's time to move on. ezjail may not be the only jail management utility, but it's the only one in the Handbook. Before we "move on" from ezjail, perhaps the alternatives sho= uld be be documented in the same place? --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-current@freebsd.org Mon May 15 19:41: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 6312AD6EF2C for ; Mon, 15 May 2017 19:41:49 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 1880924B for ; Mon, 15 May 2017 19:41:49 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qt0-x22a.google.com with SMTP id c13so45283215qtc.1 for ; Mon, 15 May 2017 12:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=kk6YmktLZ90EXUODxct/GBFagHVIXuQphNj950k2Y0U=; b=nJ4WfrbUvgRSsL+7lg/9V4MAh/l+X2hsY/p6rb7pPxLytDuyxjCTImO96rb9pqKz+X DcbLZrANVbLNJUdPMKeMUJ3YgDsGkL7EvHoFsPUGbzagWgNb9bPOXMhDCcZ/k8aQxJDS ZJspjBQPRmDNY4qH4JSYWnbH5PrOXBuy/Vcrz1htXRruWYCEHLpWKTc76ATpAUMIYPP1 xGTySKtwOnQ6rZk/upIShc86A71AGrRnXaMyR20aBE9FeCtrqR9c0O4R4duq/b4jIAnG oqaMxeglPagocAB+QLxkxi5DDRUXm3Hcc+co//3Xqzfsf1Sv47HE+/Pz52yS1VcPpeyY 1arA== 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=kk6YmktLZ90EXUODxct/GBFagHVIXuQphNj950k2Y0U=; b=MblzEAmPtiTAJiNezH3Ab2IXZgDOH4vm7z36w/Wa9KmJ3LJD/o6fTkKFPhjdOYmVf1 Wk3qE4O5FXJEFGKIVTR0ZzDPbYqL412Ov3jRd5iNq+dgMdEJMxi9fJ7yt28fBa5zEBS/ 1O+ObVIjyGvOgWpXaHVYugEWjpySmMm2F76mGoQ/j18Uds2WxKSPItU5eTEmTQdxEwyA cJu+z+Wd7x1OLl7VFGLOD091v3PVdS3XFTFdDFFa5kKHJ3pV4KDZJ6QoZWX/DX9+C6KQ qQeTYHHKJXvGu6DvRIBw//1I5WK2BCqEWbZ0K4DxaNfMvKX38U1zFAul/BqqzAdLsz1p qDNA== X-Gm-Message-State: AODbwcBxAUVfJgLY8ykHkahjxS3PWIhAB+pJBz9Dfaj6+E5pxj9vqZCN Wbd4zd6azdXr0QukSGEHoA== X-Received: by 10.200.34.242 with SMTP id g47mr6901497qta.109.1494877308112; Mon, 15 May 2017 12:41:48 -0700 (PDT) Received: from mutt-hbsd ([63.88.83.66]) by smtp.gmail.com with ESMTPSA id t35sm9134628qta.62.2017.05.15.12.41.47 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 15 May 2017 12:41:47 -0700 (PDT) Date: Mon, 15 May 2017 15:41:45 -0400 From: Shawn Webb To: Konstantin Belousov Cc: freebsd-current@freebsd.org, freebsd-fs@freebsd.org, freebsd-ports@freebsd.org, emaste@freebsd.org, Kirk McKusick Subject: Re: 64-bit inodes (ino64) Status Update and Call for Testing Message-ID: <20170515194145.tx2mp6gxjxbcpbng@mutt-hbsd> References: <20170420194314.GI1788@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="meq5xjd7oh4cv4tt" Content-Disposition: inline In-Reply-To: <20170420194314.GI1788@kib.kiev.ua> X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20170306 (1.8.0) 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, 15 May 2017 19:41:49 -0000 --meq5xjd7oh4cv4tt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 20, 2017 at 10:43:14PM +0300, Konstantin Belousov wrote: > Inodes are data structures corresponding to objects in a file system, > such as files and directories. FreeBSD has historically used 32-bit > values to identify inodes, which limits file systems to somewhat under > 2^32 objects. Many modern file systems internally use 64-bit identifiers > and FreeBSD needs to follow suit to properly and fully support these > file systems. >=20 > The 64-bit inode project, also known as ino64, started life many years > ago as a project by Gleb Kurtsou (gleb@). After that time several > people have had a hand in updating it and addressing regressions, after > mckusick@ picked up and updated the patch, and acted as a flag-waver. >=20 > Sponsored by the FreeBSD Foundation I have spent a significant effort > on outstanding issues and integration -- fixing compat32 ABI, NFS and > ZFS, addressing ABI compat issues and investigating and fixing ports > failures. rmacklem@ provided feedback on NFS changes, emaste@ and > jhb@ provided feedback and review on the ABI transition support. pho@ > performed extensive testing and identified a number of issues that > have now been fixed. kris@ performed an initial ports investigation > followed by an exp-run by antoine@. emaste@ helped with organization > of the process. >=20 > This note explains how to perform useful testing of the ino64 branch, > beyond typical smoke tests. >=20 > 1. Overview. >=20 > The ino64 branch extends the basic system types ino_t and dev_t from > 32-bit to 64-bit, and nlink_t from 16-bit to 64-bit. The struct dirent > layout is modified due to the larger size of ino_t, and also gains a > d_off (directory offset) member. As ino64 implies an ABI change anyway > the struct statfs f_mntfromname[] and f_mntonname[] array length > MNAMELEN is increased from 88 to 1024, to allow for longer mount path > names. >=20 > ABI breakage is mitigated by providing compatibility using versioned > symbols, ingenious use of the existing padding in structures, and by > employing other tricks. Unfortunately, not everything can be fixed, > especially outside the base system. For instance, third-party APIs > which pass struct stat around are broken in backward and forward- > incompatible way. >=20 > 2. Motivation. >=20 > The main risk of the ino64 change is the uncontrolled ABI breakage. > Due to expansion of the basic types dev_t, ino_t and struct dirent, > the impact is not limited to one part of the system, but affects: > - kernel/userspace interface (syscalls ABI, mostly stat(2), kinfo > and more) > - libc interface (mostly related to the readdir(3), FTS(3)) > - collateral damage in other libraries that happens to use changed types > in the interfaces. See, for instance, libprocstat, for which compat > was provided using symbol versioning, and libutil, which shlib version > was bumped. >=20 > 3. Quirks. >=20 > We handled kinfo sysctl MIBs, but other MIBs which report structures > depended on the changed type, are not handled in general. It was > considered that the breakage is either in the management interfaces, > where we usually allow ABI slip, or is not important. >=20 > Struct xvnode changed layout, no compat shims are provided. >=20 > For struct xtty, dev_t tty device member was reduced to uint32_t. It > was decided that keeping ABI compat in this case is more useful than > reporting 64bit dev_t, for the sake of pstat. >=20 > 4. Testing procedure. >=20 > The ino64 project can be tested by cloning the project branch from > GitHub or by applying the patch at URL | attached> to a working tree. The authorative source is the > GitHub, I do not promise to update the review for each update. >=20 > To clone from GitHub: > % git clone -b ino64 https://github.com/FreeBSDFoundation/freebsd.git ino= 64 >=20 > To fetch the patch from Phabricator: > - Visit https://reviews.freebsd.org/D10439 > - Click "Download Raw Diff" at the upper right of the page >=20 > Or > % arc patch D10439 >=20 > After that, in the checkout directory do > % (cd sys/kern && touch syscalls.master && make sysent) > % (cd sys/compat/freebsd32 && touch syscalls.master && make sysent) > If you use custom kernel configuration, ensure that > options COMPAT_FREEBSD11 > is included into the config. Then build world and kernel in the > usual way, install kernel, reboot, install new world. Do not make > shortcuts in the update procedure. Hey Kostik, On my HardenedBSD system, world compiled fine with the patch, but the kernel didn't compile. I've uploaded the log to: https://hardenedbsd.org/~shawn/2017-05-15_ino64-r01.log This was from importing the patch from Phabricator into hardened/current/master in HardenedBSD. Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --meq5xjd7oh4cv4tt Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlkaBHYACgkQaoRlj1JF bu7DVQ//dkA0Nm4bCMZ0B4Iv3TwZAoWP+EyzLwUAW3ywzM3KhMJyLuGnOIcb+UZ3 szb7jAQEbnOQN3IYsKxKIGmMr0/XFJsdeTGPo29yQ5WFfEpQPZRVkWtC162YrFiE fH9Xuizw3puetGAxlzE3JNM6rBmlJUq0GB1FhUoKlMYD22p6/HTQ3Rn+tJp8oR5R xr0v3F18JcyIbean0RhzXwQZtdTcHpuCL1kgdz+RdrVspY8cw48baJhzburX6ITg XnaU1JSTwWYE58HBfWd6/S5g2/nW9xYfQMNHjuq7vOLPVpy3PWIwelYtcfKMULtt KF/tIsWqPEbPmHhh2BbtzKW95oRruY0M9V8y04cSGFGRaGixXSBJCQ4yQTS0yegy zBpEgY/zZ21MQCrzPIdp7CzfRqWrpIjVS94gska5uER9xI3bq28nWnGwPjeoca4D 5SmNMM6TMWBU2occWwFkaXIURXY+sBxLDbPlBcLGEMkkfm/BajUOrk8YJydCMZeq 73s4b7dKQKWS5Aa18V6Y9/rWMbSQqx/FD7Dvc8rqc49jwv9nRKO6AteEGMvBvKUs NHj1PdeExdtMnuSZd3CFDdTfU0RRy0gqqfISw9ns5aPz0Ofdo9xAjGSEpUGF2Tpu LyX+6X/DlSApPZyC8QsSItKBicuOScXHIQs8AYxX3q7TF8wAbXE= =gxsk -----END PGP SIGNATURE----- --meq5xjd7oh4cv4tt-- From owner-freebsd-current@freebsd.org Mon May 15 20:22:33 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 48F0AD6EFC8 for ; Mon, 15 May 2017 20:22:33 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::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 DDB47AD7; Mon, 15 May 2017 20:22:32 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-wm0-x244.google.com with SMTP id u65so30961796wmu.3; Mon, 15 May 2017 13:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=EAd/B45kTQAbqtY0IQ0L39MSTimUTdURl6jj5lXAfoI=; b=TTZhfVR6Hr9/i/TbS9sfnziStTsmSRy3Fie3R9N/bdKXaAsIGi3ohcyPeKt1LV1OgJ rCtImNtDL5D+eFRp8+VymaN1PP5HIbOr6o+SNX9U8FnAIqIUiaYlP1CYM1tTy5AErOwb 2Vzhs3O3W+RZEqOoB13Kw12+sMN9EiYuanJTuegC9vSuLU2zt81NkCrlmGpAwb2Xohoj pLRR93R3s7VftWrDyGdd9MSIBJdvvAGpTo1F7NVUfqU6MutsgtsxX2eQjW8gWqzj4t2+ ugeoti5yN6npIUQ2duiB0Ubu73tXaHO7bNap9n+WTbOAqVg402quHZ2tPrBODgBYaU2e l3Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=EAd/B45kTQAbqtY0IQ0L39MSTimUTdURl6jj5lXAfoI=; b=ZRC91oUYQtcTjwj0PSTul9YxypLQyo4NmGXfexWX26b+UD/eaPiypv8ovIFuiVddbC fNj/RncsXN7o2rjqhm+PjPpdO8pt5D6DjoP1B2Qw2WJMnDFg7th6PkQ8EBngWSXbCXoV ct5yG9qgRApAkwzulYoWDJxvw6sdoGlaTC1ldMkAF83JtkhqJHSTXisGzxIPPLKlRMJO EFhuGhvobadQv29qeCg9xs1u+5OfoAe96LjVsS/1/0666Tj+BEMtQlSEl/dnR2p3YOeG CirIQpk8kGsawl/iTKi0TD6ekag8ERZ/R7u/642UvCZ/3p79QGAz5lf53IS27EIWiyLf hWlA== X-Gm-Message-State: AODbwcCnQZnUO7uhARUhbAalwP4WFIbnQUi223ebjiAXZWff5I78e0l9 Ts/Q168N/KkFEw== X-Received: by 10.28.27.75 with SMTP id b72mr4698594wmb.34.1494879751179; Mon, 15 May 2017 13:22:31 -0700 (PDT) Received: from brick (cpc92310-cmbg19-2-0-cust934.5-4.cable.virginm.net. [82.9.227.167]) by smtp.gmail.com with ESMTPSA id i24sm7456409wrc.40.2017.05.15.13.22.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 May 2017 13:22:30 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Mon, 15 May 2017 21:22:28 +0100 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Konstantin Belousov Cc: Poul-Henning Kamp , Manuel St?hn , Jonathan Anderson , freebsd-current@freebsd.org Subject: Re: regression suspend/resume on Lenovo T420 Message-ID: <20170515202228.GA2010@brick> Mail-Followup-To: Konstantin Belousov , Poul-Henning Kamp , Manuel St?hn , Jonathan Anderson , freebsd-current@freebsd.org References: <5746a37cd73e062c963512df1a6d24c6@email.freenet.de> <20170506090341.GA12163@freebsd-t420.fritz.box> <20170514193006.GA1298@brick> <1190.1494792172@critter.freebsd.dk> <20170515095647.GA1622@kib.kiev.ua> <20170515173758.GA1730@brick> <20170515184058.GF1622@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170515184058.GF1622@kib.kiev.ua> User-Agent: Mutt/1.8.2 (2017-04-18) 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, 15 May 2017 20:22:33 -0000 On 0515T2140, Konstantin Belousov wrote: > On Mon, May 15, 2017 at 06:37:58PM +0100, Edward Tomasz Napiera??a wrote: > > Thanks! The patch fixes resume for me, for both vt(4) and X11. > > Thanks everybody for testing, patch below should be committable, modulo > bugs. I did not tested it and ask for the same test as the previous > debugging patch. [..] Works just fine, thanks! From owner-freebsd-current@freebsd.org Mon May 15 22:01:37 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 2FF1FD6E86D for ; Mon, 15 May 2017 22:01:37 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DA6291332 for ; Mon, 15 May 2017 22:01:36 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk0-x22d.google.com with SMTP id a72so111608818qkj.2 for ; Mon, 15 May 2017 15:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=PKAVcDKkyQx9ntzPsSXWZAMOkhBQFpfaAyy7s7oIdSM=; b=L1mYS0CsICQjW9gkwvmDteLkabuDMQEJz4f8spMVSEIyVT1ZB4iKxmGtaGW339WWk4 kEdl9UYpqbGCoXUHmJgSZXRFCc8uIprGBa9K1L6kltJ4g0pnn+gpMh9pQmu/GyKNn3oC fAu2lEkNMjeFWQOXCbBwt3zd3+BOsK9DGUrc6sIubuzSx61Y8tbyWIuU6TwfPcmLAm21 ydjOlIUrVF/BQ5kOuVBQHvfYe+RORgi1I5TO5qKFxREFglU8np2n/weO9mCHmTMteKWu 3IlM/ddgP3urinElSausp2kHmVDAnAuURPF+XxJYxVszsMaBYK/3w68BBkl5M1dwLVof FGTA== 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=PKAVcDKkyQx9ntzPsSXWZAMOkhBQFpfaAyy7s7oIdSM=; b=Az5Faa3eWQzbVCrKByKSv9cVVyrBOEwngknIkDHHLwaXQ4E1lCyDdNnkSofWW0SDHY 8A4s2n7n2OsbuB0xYh/22/7KGVVM3MAQY4K5dkeKM6FHy9ZmfCAwXfUEAquBlG2na3ZP M2NjXpksyM7Nuk19cW2ty3L2BfeI5XO116FcP/8ZzjILe4HQGXTojAf0eDnFAX1kyLVW zo8NIYbO0bYdxORMMvf6SNEG6CcKNtIPKHUKaEvKqE7eHTsZmiIr+462WezOLmaPqOON tjRx3tDjFhSTxcbFfGsQ+LYUDNKfXhDzsgXG27dyb9wjP3rvbVz5kT73n4OJAe9yxJKW yfEw== X-Gm-Message-State: AODbwcDmGajdBJvbBSRLICjODXX5tpZfJRsgpcaUv9gNu0nhsjqaO8gw CBXysapKkcviscvS X-Received: by 10.233.237.72 with SMTP id c69mr8068210qkg.201.1494885695903; Mon, 15 May 2017 15:01:35 -0700 (PDT) Received: from mutt-hbsd ([63.88.83.66]) by smtp.gmail.com with ESMTPSA id t35sm9400920qta.62.2017.05.15.15.01.35 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 15 May 2017 15:01:35 -0700 (PDT) Date: Mon, 15 May 2017 18:01:33 -0400 From: Shawn Webb To: Konstantin Belousov Cc: freebsd-current@freebsd.org, freebsd-fs@freebsd.org, freebsd-ports@freebsd.org, emaste@freebsd.org, Kirk McKusick Subject: Re: 64-bit inodes (ino64) Status Update and Call for Testing Message-ID: <20170515220133.hxp6x2zvlfdilsiq@mutt-hbsd> References: <20170420194314.GI1788@kib.kiev.ua> <20170515194145.tx2mp6gxjxbcpbng@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="h36hr3agvrxrlxsc" Content-Disposition: inline In-Reply-To: <20170515194145.tx2mp6gxjxbcpbng@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20170306 (1.8.0) 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, 15 May 2017 22:01:37 -0000 --h36hr3agvrxrlxsc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 15, 2017 at 03:41:45PM -0400, Shawn Webb wrote: > On Thu, Apr 20, 2017 at 10:43:14PM +0300, Konstantin Belousov wrote: > > Inodes are data structures corresponding to objects in a file system, > > such as files and directories. FreeBSD has historically used 32-bit > > values to identify inodes, which limits file systems to somewhat under > > 2^32 objects. Many modern file systems internally use 64-bit identifiers > > and FreeBSD needs to follow suit to properly and fully support these > > file systems. > >=20 > > The 64-bit inode project, also known as ino64, started life many years > > ago as a project by Gleb Kurtsou (gleb@). After that time several > > people have had a hand in updating it and addressing regressions, after > > mckusick@ picked up and updated the patch, and acted as a flag-waver. > >=20 > > Sponsored by the FreeBSD Foundation I have spent a significant effort > > on outstanding issues and integration -- fixing compat32 ABI, NFS and > > ZFS, addressing ABI compat issues and investigating and fixing ports > > failures. rmacklem@ provided feedback on NFS changes, emaste@ and > > jhb@ provided feedback and review on the ABI transition support. pho@ > > performed extensive testing and identified a number of issues that > > have now been fixed. kris@ performed an initial ports investigation > > followed by an exp-run by antoine@. emaste@ helped with organization > > of the process. > >=20 > > This note explains how to perform useful testing of the ino64 branch, > > beyond typical smoke tests. > >=20 > > 1. Overview. > >=20 > > The ino64 branch extends the basic system types ino_t and dev_t from > > 32-bit to 64-bit, and nlink_t from 16-bit to 64-bit. The struct dirent > > layout is modified due to the larger size of ino_t, and also gains a > > d_off (directory offset) member. As ino64 implies an ABI change anyway > > the struct statfs f_mntfromname[] and f_mntonname[] array length > > MNAMELEN is increased from 88 to 1024, to allow for longer mount path > > names. > >=20 > > ABI breakage is mitigated by providing compatibility using versioned > > symbols, ingenious use of the existing padding in structures, and by > > employing other tricks. Unfortunately, not everything can be fixed, > > especially outside the base system. For instance, third-party APIs > > which pass struct stat around are broken in backward and forward- > > incompatible way. > >=20 > > 2. Motivation. > >=20 > > The main risk of the ino64 change is the uncontrolled ABI breakage. > > Due to expansion of the basic types dev_t, ino_t and struct dirent, > > the impact is not limited to one part of the system, but affects: > > - kernel/userspace interface (syscalls ABI, mostly stat(2), kinfo > > and more) > > - libc interface (mostly related to the readdir(3), FTS(3)) > > - collateral damage in other libraries that happens to use changed types > > in the interfaces. See, for instance, libprocstat, for which compat > > was provided using symbol versioning, and libutil, which shlib version > > was bumped. > >=20 > > 3. Quirks. > >=20 > > We handled kinfo sysctl MIBs, but other MIBs which report structures > > depended on the changed type, are not handled in general. It was > > considered that the breakage is either in the management interfaces, > > where we usually allow ABI slip, or is not important. > >=20 > > Struct xvnode changed layout, no compat shims are provided. > >=20 > > For struct xtty, dev_t tty device member was reduced to uint32_t. It > > was decided that keeping ABI compat in this case is more useful than > > reporting 64bit dev_t, for the sake of pstat. > >=20 > > 4. Testing procedure. > >=20 > > The ino64 project can be tested by cloning the project branch from > > GitHub or by applying the patch > at URL | attached> to a working tree. The authorative source is the > > GitHub, I do not promise to update the review for each update. > >=20 > > To clone from GitHub: > > % git clone -b ino64 https://github.com/FreeBSDFoundation/freebsd.git i= no64 > >=20 > > To fetch the patch from Phabricator: > > - Visit https://reviews.freebsd.org/D10439 > > - Click "Download Raw Diff" at the upper right of the page > >=20 > > Or > > % arc patch D10439 > >=20 > > After that, in the checkout directory do > > % (cd sys/kern && touch syscalls.master && make sysent) > > % (cd sys/compat/freebsd32 && touch syscalls.master && make sysent) > > If you use custom kernel configuration, ensure that > > options COMPAT_FREEBSD11 > > is included into the config. Then build world and kernel in the > > usual way, install kernel, reboot, install new world. Do not make > > shortcuts in the update procedure. >=20 > Hey Kostik, >=20 > On my HardenedBSD system, world compiled fine with the patch, but the > kernel didn't compile. I've uploaded the log to: >=20 > https://hardenedbsd.org/~shawn/2017-05-15_ino64-r01.log >=20 > This was from importing the patch from Phabricator into > hardened/current/master in HardenedBSD. Update: I missed a step. Kernel and world built fine. It seems the patch is working fine for me in a limited test. I'll do a more involved test tomorrow. Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --h36hr3agvrxrlxsc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlkaJToACgkQaoRlj1JF bu5Q8A//UjtI66Dxx4vNYviBvrqUXZf+cpY+FsGWUnCiIsNYpmZoLmkNjGqyW5PF OBlq7wpC6R5gUlKLsaV4/7Qe6biGKv8JIr1CujjQKX/gGfHZ7ILrVWyQE6uHFM/a YvFQ3GX4j45fOZGx5Fh7IjzfUaCeBMj0+apdbUyeUZr8h3uqtVy6qY0n0g4i5X0L P6bS57cNXWhSin2lXA98/b89p2DCOOH6TjqvAjB9gbwFs5mzujkS7KgZruaOFWnT csnfgoaqqdzLQDLXrLqURnL50rAE6ALvzUb/+C+TYnNnXTMCzbvRNOJOqhuZ2WiH USbn0IH9bB87cIWTaeYce171dTbBuAAyoAiGSaYEAMhJC+QRirl4M6L1VrJdFLVd VKGkWrtXGJ28u8UlEB+yOp9e/t11DnvVLuU6kqiGlQFlPPP9cu2Kmqcq7bcKwPE1 3Rl4jJjbCiD7LPMKgs3u3IEoSiM90yFUsXf7UByyGpE2ViGMqUH7i+pPQxFYTWQ1 sKiimmCvOxAz0h93lFS3CC5Vti3Gc+rY2tpuCwbyuctBGbJ5VzzVwjinKgOVHVj3 4Mb/1EEId99LWRIt7OVvvmuzs4lWn9MZnK0G/Trpa0lJmHpSFiGN9lZ8Xk7j1B8m DqL9fh8ZCnGhtWiicwWcSOgYpHOF0WpbvXEuuEOpued6GSDezXc= =SIYn -----END PGP SIGNATURE----- --h36hr3agvrxrlxsc-- From owner-freebsd-current@freebsd.org Mon May 15 23:14:12 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6E646D6E068; Mon, 15 May 2017 23:14:12 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (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 3B58B9CD; Mon, 15 May 2017 23:14:11 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from fortune.joker.local (124-18-21-125.dz.commufa.jp [124.18.21.125]) (authenticated bits=0) by dec.sakura.ne.jp (8.15.2/8.15.2/[SAKURA-WEB]/20080708) with ESMTPA id v4FNE9xF018210; Tue, 16 May 2017 08:14:09 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Tue, 16 May 2017 08:14:08 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Cc: , freebsd-ports@freebsd.org Subject: Re: [RFC] rename nvidia-driver port binaries [ and other comments] Message-Id: <20170516081408.f3ee7b429aa8048dccb8ebec@dec.sakura.ne.jp> In-Reply-To: References: <20170515235310.9f60289e486c202cc5be7978@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 15 May 2017 23:14:12 -0000 On Mon, 15 May 2017 10:51:51 -0700 (PDT) "Jeffrey Bouquet" wrote: > > > On Mon, 15 May 2017 23:53:10 +0900, Tomoaki AOKI wrote: > > > Hi. > > If including its version to nvidia.ko and nvidia-modeset.ko, > > [hard / symbolic] link to it with current name should be needed > > not to bother admins every time upgrading. > > > > BTW, I personally using below in rc.conf for safety. > > This only helps situations that... > > > > *Insufficient loader memory, but OK after kernel is started. > > > > *Accidentally backed to older version that doesn't have > > nvidia-modeset.ko and only nvidia-modeset.ko is written in > > /boot/loader.conf. > > > > ## Temporary settings for nvidia-driver when failed loading via loader.conf > > kldstat -q -n nvidia.ko > > if [ 0 -ne $? ] ; then > > echo "Loading nvidia-driver modules via rc.conf." > > # kldload nvidia > > if [ -e /boot/modules/nvidia-modeset.ko ] ; then > > # kldload nvidia-modeset > > kld_list="${kld_list} nvidia-modeset.ko" > > else > > # kldload nvidia > > kld_list="${kld_list} nvidia.ko" > > fi > > fi > > > > > > On Mon, 15 May 2017 06:41:33 -0700 (PDT) > > "Jeffrey Bouquet" wrote: > > > > > Just had a unique to me, unbootable backup [beside the point, > > > just a sidebar comment... ] quandry dealing with the nvidia-driver update > > > that mesa-libs needed. [ or was appurtenant to it, unsure... ] > > > > > > 12.0 - CURRENT > > > > > > [ my previous 'saves' -- files to consult... were in .jpg, so no avail for me to peruse as I was in the terminal ] > > > > > > Lessons I learned, maybe > > > > > > [RFC] rename nvidia-driver.ko to include its version, for instance nvidia-modeset-37539.ko > > > which would make one's diagnosis a fix easier. > > > > > > [suggestions] > > > > > > ... Document that the kernel will load a /boot/modules/_nvidia.ko if you'd thus made it 'unavailable' > > > ... document better that one can load nvidia[modeset] later than /boot/loader.conf [cli, rc.conf...] > > > > > > [ mini 'what fixed it for you ' and/or stalled the same ... > > > ] > > > ... I had a make.conf in place, 'trapping' a > > > make -DMAKE_JOBS_UNSAFE=yes CC=".../clang39" [and the other two...] install in failure > > > ... I had no clue if Xorg was at fault, and luckily did not have to rebuild. > > > ... I had no access to the forums, as the desktop could not be loaded [yet] > > > ... I had to do strings nvidia.ko |grep 26 [39] | less to detect the not usable module numbers, > > > THUS THE REQ FOR RENAME of the nvidia.ko binary [vs port] to include its 5 digit number > > > as above. > > > ... I was taken aback by the less infomative > > > this client has the .39 but the module has the .26 ... > > > specifically stating which file/port/kernel module the 'client' refers to > > > and which specific modules 'this module' was referring to. Unknown if that is > > > fixable here in a .c, .h , or is closed-source upstream in nvidia [corp ] where we can > > > ask them to be more specific or code in some more verbose error messages. > > > ... Relieved I did not have to rebuild Xorg nor the kernel, just move files out of the > > > way and do a simple rebuild of the nvidia-driver. > > > [... Not relieved that the nvidia-driver needed install during the mesa-lib reshuffle, maybe > > > did not need to be, just a hazy recollection on my part. So ignore this little bit ] > > > > > > ... All in all a learning experience. Howsoever, I would like this nvidia stuff to be put eventuall > > > in /usr/src/UPDATING so the half or third of persons who run into this yearly will have a more > > > authoritative flowchart of sorts to determine the next course of action. > > > something like > > > if ... this thta > > > if... this that > > > if ... this that > > > OTOH... error message... a... you may need to... > > > ... > > > error message ... r... you may need to... > > > > > > ... And it would have maybe saved a bit of time here, and I would almost if eventually > > > possible be sure to copy /usr/src/UPDATING to /usr/ports/x11/nvidia-driver for > > > more easy access if the desktop was broken.... > > > > > > > > > Apologies for the hurried post. Indeed, I have tasked myself to write it up here > > > locally [ still in scribbled notations...] so I can forestall/fix more quickly this > > > error the next time. > > > also... > > > Running late in other personal matters, and out of time. > > > > > > Respectfully.. > > > > > > J. Bouquet > > > _______________________________________________ > > > 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" > > > > > > > > > -- > > Tomoaki AOKI > > > I found just then that one can load it manually > first, though the nvidia.ko [ one has newly built ] THEN > the nvidia-modeset.ko nvidia-modeset.ko requires nvidia.ko and loads it automatically if not yet loaded. So trying nvidia-modeset.ko first if exists, and if not, trying nvidia.ko would be sufficient. > if it has not been loaded via /boot/loader.conf which did not load it > in the session in which I am typing this, for example. > > [ wondering if /usr/ports/UPDATING or the pkg-message should be > updated to state that... upon a second verification ... ] In /usr/ports/UPDATING, stated below: 20160829: AFFECTS: users of x11/nvidia-driver AUTHOR: cem@FreeBSD.org The NVidia driver has been updated to version 367.35. Starting with version 358.09, new kernel module was added, nvidia-modeset.ko. This new driver component works in conjunction with the nvidia.ko kernel module to program the display engine of the GPU. Users that experience hangs when starting X11 server, or observe (II) NVIDIA(0): Validated MetaModes: (II) NVIDIA(0): "NULL" messages in their /var/log/Xorg.0.log file should replace ``nvidia'' with ``nvidia-modeset'' in /boot/loader.conf or /etc/rc.conf files, depending on how they prefer to load NVidia driver kernel module. > > > YMMV > _______________________________________________ > 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" > -- Tomoaki AOKI From owner-freebsd-current@freebsd.org Tue May 16 04:48:03 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 EB5BED6FFE9; Tue, 16 May 2017 04:48:03 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 2B4211FC4; Tue, 16 May 2017 04:48:02 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074425-507ff700000001c7-56-591a834c83a1 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 dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 16.A8.00455.C438A195; Tue, 16 May 2017 00:42:52 -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 v4G4goDV021949; Tue, 16 May 2017 00:42:50 -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 v4G4gjbp022836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 May 2017 00:42:48 -0400 Date: Mon, 15 May 2017 23:42:45 -0500 From: Benjamin Kaduk To: freebsd-hackers@FreeBSD.org Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: FreeBSD Quarterly Status Report - First Quarter 2017 Message-ID: <20170516044244.GD39245@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="A6N2fC+uXW/VQSAv" Content-Disposition: inline User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKKsWRmVeSWpSXmKPExsUixCmqrevTLBVp8POpiMWua6fZLea8+cBk sX3zP0aLw81CDiweMz7NZwlgjOKySUnNySxLLdK3S+DK2NL+hKlgwXumirV35BsY18xj6mLk 5JAQMJE48v85YxcjF4eQwGImia4rB9khnI2MEuvWvWSBcK4ySfROXsIK0sIioCpxaOdMZhCb TUBNYv2Ka2C2iIC8xL6m9+wgNrOAtcS/B41gcWEBW4nPU2eD9fICrbt1pIUdwhaUODnzCQtE fZlEc+taIJsDyJaWWP6PAyQsKqAs8ffwPZYJjHyzkHTMQtIxC6EDIqwu8WfeJWYMYW2JZQtf M0PYtkCPvWdZwMi+ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdCLzezRC81pXQTIyi82V1UdzDO +et1iFGAg1GJh3fFCslIIdbEsuLK3EOMkhxMSqK8adVSkUJ8SfkplRmJxRnxRaU5qcWHGFWA dj3asPoCoxRLXn5eqpIIb50JUB1vSmJlVWpRPkyZNAeLkjivuEZjhJBAemJJanZqakFqEUxW hoNDSYJ3QyNQo2BRanpqRVpmTglCmomD8xCjBAcP0PDiBpDhxQWJucWZ6RD5U4zGHO+WfnjP xNF15s97JiGwO6TEeWeCjBMAKc0ozYObBkpdEtn7a14xigM9Ksy7uAmoigeY9uDmvQJaxQS0 KuylOMiqkkSElFQDo/3BIM76SQf0Z86OCNl9ySjpaPXaR3ckz2g8OuSt1XzMaOeR+q9b+s9p vnoz5WXyvGN7vkuEnEu2W5Xovt5tr1IRZ1Rl+RHhVd4Bqgu0Hi9c6MURdOx/ZEtGjEfR04tT uDbGy00WLDLiXrCq/Oi8zbIpShn94VEPHjs+XnVaoL3g2Qqjl6kHEpRYijMSDbWYi4oTAVsv EUM4AwAA 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, 16 May 2017 04:48:04 -0000 --A6N2fC+uXW/VQSAv Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable FreeBSD Project Quarterly Status Report - 1st Quarter 2017 While a few of these projects indicate they are a "plan B" or an "attempt III", many are still hewing to their original plans, and all have produced impressive results. Please enjoy this vibrant collection of reports, covering the first quarter of 2017. --Benjamin Kaduk __________________________________________________________________ The deadline for submissions covering the period from April to June 2017 is July 7, 2017. __________________________________________________________________ FreeBSD Team Reports * The FreeBSD Core Team * The FreeBSD Foundation * The FreeBSD Ports Collection * The FreeBSD Release Engineering Team Projects * Ceph on FreeBSD * OpenBSM * Porting Software to CloudABI: Sandboxed Bitcoin! * Support for eMMC Flash and Faster SD Card Modes * TrustedBSD Kernel * FreeBSD on Hyper-V and Azure * Intel 10G and 40G Network Driver Updates * Linuxulator * MMC Stack Using the CAM Framework * pNFS Server Plan B Architectures * 64-bit PowerPC Book-E Support * FreeBSD on Marvell Armada38x * FreeBSD/s390x Attempt III Ports * MySQL * Rust Documentation * The FreeBSD Dutch Documentation Project __________________________________________________________________ FreeBSD Team Reports The FreeBSD Core Team Contact: FreeBSD Core Team Core's primary function is to ensure the long-term viability of the FreeBSD project. A very large part of that is to ensure that the interactions between developers remain cordial, and consequently that the project appears welcoming to newcomers. Normally, most of Core's activities around this are done in private -- a quiet word in the right ear, some discrete peacemaking, occasional reading of the riot act. Most of the time, this is all that is necessary. Unfortunately, this quarter we had an instance where such private measures failed to achieve the desired result, and we ended up ejecting a developer. This developer is an extremely talented programmer and has made significant contributions to the Ports Collection. Despite this, portmgr found him to be sufficiently disruptive and abrasive that in their judgement, the project was better off overall to sever his connection to itself, and core backed them up in that. We are sorry that events came to this sad conclusion, but we remain convinced that this was a necessary step to safeguard the character of our community. In a more positive light, Core has been working on a proposal to recognise notable contributors to the FreeBSD project who are not (or perhaps not yet) suitable to be put forward as new committers. In addition to the usual routes of recognising people that write numbers of good bug reports or that supply patches or that volunteer to maintain ports, this will also allow recognition of people who contribute by such things as organising FreeBSD events or who promote FreeBSD through social media. A formal announcement of Core's proposal is imminent. During January, the core secretary held an exercise to contact all source committers who had been inactive for more than 18 months and persuade them to hand in their commit bits if they were not planning to resume working on FreeBSD in the near future. This is meant to be a routine function -- the "grim reaper" -- that aims to keep the list of people with the ability to commit pretty much in synchrony with the list of people that are actively committing. The regular process had fallen out of activity several years ago, and we needed to clear the decks before restarting. Ultimately, this resulted in some 20 developers-emeritus handing in their commit bits. No new commit bits were awarded during this quarter. Core is also taking soundings on producing a 10.4-RELEASE. This is not in the current plan, but a number of developers and important FreeBSD users would be keen to see it happen, given some of the work that has gone into the stable/10 branch since 10.3-RELEASE. On the other hand, this would represent an additional support burden for the Security Team, including maintaining versions of software that have been declared obsolete upstream, in particular OpenSSL. As an even-numbered release, 10.4-RELEASE would have a "normal" rather than an "extended" lifetime which means it should not result in extending the support lifetime of the stable/10 branch. In other news, Core arranged for the old and largely inactive marketing@FreeBSD.org mailing list to be wound up, and for any remaining activities to be transferred to the FreeBSD Foundation. Core also asked clusteradm to turn off Internet-wide access to the finger server on freefall.freebsd.org. Many developers have included details such as phone numbers into the GECOS field of their FreeBSD password database entries, and these would be revealed by the finger server -- details which are nowadays generally felt inadvisable to expose publicly. finger is still available internally within freefall.freebsd.org. Core recommends that GECOS data is limited to just your full name, and we have updated the standard "new committer" e-mail template to reflect that. Core is looking for new volunteers to help out with several of the teams that manage various aspects of the project. In particular, Postmaster and the Security Team are in need of new blood. Recruiting for a new member of the Security Team is well under way, but anyone interested in joining any of the teams is encouraged to make themselves known either to Core or directly to the teams concerned. __________________________________________________________________ The FreeBSD Foundation Links FreeBSD Foundation Website URL: https://www.FreeBSDFoundation.org/ Quarterly Newsletter URL: https://www.FreeBSDfoundation.org/wp-content/uploads/2017/03/FreeB= SD-Foundation-Q1-2017-Update.pdf 2017 Storage Summit URL: https://wiki.FreeBSD.org/201702StorageSummit Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Funding comes from individual and corporate donations and is used to fund and manage software development projects, conferences and developer summits, and provide travel grants to FreeBSD contributors. The Foundation purchases and supports hardware to improve and maintain FreeBSD infrastructure; publishes marketing material to promote, educate, and advocate for the FreeBSD Project; facilitates collaboration between commercial vendors and FreeBSD developers; and finally, represents the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity. Our work is 100% funded by your donations. We kicked off the new year with some large contributions from Intel and NetApp, to help us raise over $400,000 last quarter! We engaged in discussions with new and old commercial users to help facilitate collaboration, explain how the Project works, and to ask for financial contributions to help us keep FreeBSD the innovative, secure, and reliable operating system they depend on. Please consider making a donation today! https://www.FreeBSDfoundation.org/donate/. The Foundation improves the FreeBSD operating system by employing our technical staff to maintain and improve critical kernel subsystems, add features and functionality, and fix problems. Our contributions also include funding separate project grants like the arm64 port, blacklistd access control daemon, and integration of VIMAGE support, to make sure FreeBSD remains a viable solution for research, education, computing, products and more. This quarter's project development highlights include: * 168 commits sponsored by the FreeBSD Foundation in the src tree (base system) development branch, across three staff members and four grant recipients/other developers. * Multiple funded grants, including the cfumass project, now committed to FreeBSD-HEAD, and improvements to the blacklistd daemon and FreeBSD/arm64 port. * Staff contributions including improvements to toolchain and build tool components, run time libraries, arm64, mips64 and 32- and 64-bit x86 architectures, release image build tooling, packaged base, and VM subsystem bug fixes. * Significant progress on the 64-bit inode project, which is nearly ready for commit. FreeBSD Advocacy and Education A large part of our efforts are dedicated to advocating for the Project. This includes promoting work being done by others with FreeBSD; producing advocacy literature to teach people about FreeBSD and help make the path to starting to use FreeBSD or contribute to the Project easier; and attending and getting other FreeBSD contributors to volunteer to run FreeBSD events, staff FreeBSD tables, and give FreeBSD presentations. Some of the highlights of our advocacy and education work over the last quarter: * Promoted FreeBSD at: FOSDEM, SCALE, AsiaBSDcon, and FOSSASIA * Promoted BSDCan, SCALE, USENIX LISA, vBSDcon and EuroBSDcon Calls for Participation * Promoted Google Summer of Code participation on social media and created a flyer for people to post at their universities * Published a New Faces of FreeBSD Story: Joseph Kong * Set up a Marketing Partnership with the USENIX Association and SNIA * Published and Promoted the Jan/Feb 2017 issue of the FreeBSD Journal: https://www.FreeBSDfoundation.org/journal/ * Published monthly Development Projects Updates on our blog * Secured a FreeBSD table at OSCON and promoted available discounts Conferences and Events The FreeBSD Foundation sponsors many conferences, events, and summits around the globe. These events can be BSD-related, open source, or technology events geared towards underrepresented groups. We support the FreeBSD-focused events to help provide a venue for sharing knowledge, to work together on projects, and to facilitate collaboration between developers and commercial users; this all helps provide a healthy ecosystem. We support the non-FreeBSD events to promote and raise awareness about FreeBSD, to increase the use of FreeBSD in different applications, and to recruit more contributors to the Project. We also sponsored and/or attended the following events last quarter: * FOSDEM FreeBSD developer summit (sponsor) * AsiaBSDCon -- Tokyo, Japan (sponsor) * Organized and ran the FreeBSD Storage Summit in Santa Clara, CA * Board member Philip Paeps gave a FreeBSD presentation at FOSSASIA * Attended FOSSASIA, FOSDEM, and SCALE Release Engineering The Foundation provides a full-time staff member to lead the release engineering efforts. This has provided timely and reliable releases over the last few years. Some highlights from last quarter include: * Continued the production of weekly development snapshots for the 12-CURRENT, 11-STABLE, and 10-STABLE branches. * Published the initial FreeBSD 11.1-RELEASE schedule to the Project website. Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We continued to review requests and grant permission to use the trademarks. Many more details about how we supported FreeBSD last quarter can be found in our Q1 newsletter! __________________________________________________________________ The FreeBSD Ports Collection Links About FreeBSD Ports URL: https://www.FreeBSD.org/ports/ Contributing to Ports URL: https://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributing/= ports-contributing.html FreeBSD Ports Monitoring URL: http://portsmon.FreeBSD.org/index.html Ports Management Team URL: https://www.FreeBSD.org/portmgr/index.html FreeBSD portmgr on Twitter (@FreeBSD_portmgr) URL: https://twitter.com/FreeBSD_portmgr/ FreeBSD Ports Management Team on Facebook URL: https://www.facebook.com/portmgr FreeBSD Ports Management Team on Google+ URL: https://plus.google.com/communities/108335846196454338383 Contact: Ren=C3=A9 Ladan Contact: FreeBSD Ports Management Team The number of ports is currently just 500 short of 30,000. The current number of PRs is close to 2,400, of which 620 are unassigned. The last quarter saw 6656 commits from 167 comitters. Both the number of ports and the number of unassigned PRs have increased in the last quarter. In the last quarter, we welcomed 7 new committers: Eugene Grosbein (eugen), Johannes Dieterich (jmd), Larry Rosenman (ler), Mahdi Mokhtari (mmohki), Matthew Rezny (rezny), Tobias Kortkamp (tobik), and Vladimir Kondratyev (wulf). dumbbell@ was already a src committer and got an extension for the Ports Tree. We also welcomed back krion@ and miwi@. We took 6 bits in for safe-keeping: itetcu@, leeym@, mva@, olivierd@, pgollucci@, and sanpei@. There were no changes to the membership of portmgr. antoine@ worked on USES=3Dsamba to prepare for the removal of the long-outdated Samba 3.6 ports and replace them with modern versions. The new default versions are: FreePascal 3.0.2, Ruby 2.3, and Samba 4.4. A new variable USE_LOCALE was created to add the LANG and LC_ALL environment variables to all builds. Out-of-tree patches can now be added with the new EXTRA_PATCH_TREE variable. The error messages for invalid OPTIONS_SINGLE options were improved. Some of the major port updates last quarter were: pkg 1.10.1, linux c6_64, Firefox 52.0.2, Chromium 57.0.2987.110, GCC 4.9.4, Gnome 3.18.0, Xorg 1.18.4, Qt 4.8.7 and 5.7.1, and PHP 7.1. antoine@ ran 31 exp-runs to test version updates and under-the-hood changes. Open tasks: 1. The number of unassigned and open PRs is still growing, so if you have some spare time, please close some of those. __________________________________________________________________ The FreeBSD Release Engineering Team Links FreeBSD 11.1-RELEASE Schedule URL: https://www.freebsd.org/releases/11.1R/schedule.html FreeBSD development Snapshots URL: http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes, and maintaining the respective branches, among other things. The FreeBSD Release Engineering Team continued producing weekly development snapshots for the 12-CURRENT, 11-STABLE, and 10-STABLE branches. In addition, the FreeBSD 11.1-RELEASE schedule was added to the Project website. Please note, however, the schedule on the website is still subject to change. This project was sponsored by The FreeBSD Foundation. __________________________________________________________________ Projects Ceph on FreeBSD Links Ceph Main Site URL: http://ceph.com Main Repository URL: https://github.com/ceph/ceph My FreeBSD Fork URL: https://github.com/wjwithagen/ceph Contact: Willem Jan Withagen Ceph is a distributed object store and file system designed to provide excellent performance, reliability and scalability. * Object Storage Ceph provides seamless access to objects using native language bindings or radosgw, a REST interface that is compatible with applications written for S3 and Swift. * Block Storage Ceph's RADOS Block Device (RBD) provides access to block device images that are striped and replicated across the entire storage cluster. * File System Ceph provides a POSIX-compliant network file system that aims for high performance, large data storage, and maximum compatibility with legacy applications. I started looking into Ceph because the HAST solution with CARP and ggate did not really do what I was looking for. But I aim to run a Ceph storage cluster of storage nodes that are running ZFS. User stations would be running bhyve on RBD disks that are stored in Ceph. Compiling for FreeBSD will now build most of the tools available in Ceph. Notable progress since the last report: * The most important change is that a port has been submitted: net/ceph-devel. However, it does not yet contain ceph-fuse. * Regular updates to the ceph-devel port are expected, with the next one coming in April. * ceph-fuse works, allowing one to mount a CephFS filesystem on a FreeBSD system and perform normal operations. * ceph-disk prepare and activate work for FileStore on ZFS, allowing for easy creation of OSDs. * RBD is actually buildable and can be used to manage RADOS BLOCK DEVICEs. * Most of the awkward dependencies on Linux-isms are deleted -- only /bin/bash is here to stay. To get things running on a FreeBSD system, run pkg install net/ceph-devel or clone https://github.com/wjwithagen/ceph and build manually by running ./do_freebsd.sh in the checkout root. Parts not (yet) included: * KRBD: Kernel Rados Block Devices are implemented in the Linux kernel, but not yet in the FreeBSD kernel. It is possible that ggated could be used as a template, since it does similar things, just between two disks. It also has a userspace counterpart, which could ease development. * BlueStore: FreeBSD and Linux have different AIO APIs, and that incompatibility needs to resolved somehow. Additionally, there is discussion in FreeBSD about aio_cancel not working for all devicetypes. * CephFS as native filesystem: though ceph-fuse works, it can be advantageous to have an in-kernel implementation for heavy workloads. Cython tries to access an internal field in struct dirent, which does not compile. Open tasks: 1. Run integration tests to see if the FreeBSD daemons will work with a Linux Ceph platform. 2. Compile and test the userspace RBD (Rados Block Device). This currently works but testing has been limitted. 3. Investigate and see if an in-kernel RBD device could be developed akin to ggate. 4. Investigate the keystore, which can be embedded in the kernel on Linux and currently prevents building Cephfs and some other parts. The first question is whether it is really required, or only KRBD requires it. 5. Scheduler information is not used at the moment, because the schedulers work rather differently between Linux and FreeBSD. But at a certain point in time, this will need some attention (in src/common/Thread.cc). 6. Improve the FreeBSD init scripts in the Ceph stack, both for testing purposes and for running Ceph on production machines. Work on ceph-disk and ceph-deploy to make it more FreeBSD- and ZFS-compatible. 7. Build a test cluster and start running some of the teuthology integration tests on it. Teuthology wants to build its own libvirt and that does not quite work with all the packages FreeBSD already has in place. There are many details to work out here. 8. Design a vitual disk implementation that can be used with bhyve and attached to an RBD image. __________________________________________________________________ OpenBSM Links OpenBSM: Open Source Basic Security Module (BSM) Audit Implementation URL: http://www.openbsm.org OpenBSM on GitHub URL: https://github.com/openbsm/openbsm FreeBSD Audit Handbook Chapter URL: https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/audit.h= tml DTrace Audit Provider URL: https://reviews.FreeBSD.org/D10149 DARPA CADETS project URL: https://www.cl.cam.ac.uk/research/security/cadets/ TODO List on GitHub URL: https://github.com/openbsm/openbsm/blob/master/TODO Contact: Christian Brueffer Contact: Robert Watson Contact: TrustedBSD audit mailing list OpenBSM is a BSD-licensed implementation of Sun's Basic Security Module (BSM) API and file format. It is the userspace side of the CAPP Audit implementations in FreeBSD and Mac OS X. Additionally, the audit trail processing tools are expected to work on Linux. During this quarter, experimental support for UUIDs in BSM trails was added to OpenBSM. A DTrace audit provider using this functionality has been developed as part of the DARPA CADETS project and is in review (https://reviews.FreeBSD.org/D10149). In the OpenBSM GitHub repository, support for Coverity static analysis was added via TravisCI. Additionally, the OpenBSM 1.2-alpha5 release has been merged into the FreeBSD HEAD branch. This project was sponsored by DARPA/AFRL (in part). Open tasks: 1. Test the latest release on different versions of FreeBSD, Mac OS X and Linux. Testing on the latest versions of Mac OS X would be particularly appreciated. 2. Fix problems that have been reported via GitHub and the FreeBSD bug tracker. 3. Implement the features mentioned in the TODO list on GitHub. __________________________________________________________________ Porting Software to CloudABI: Sandboxed Bitcoin! Links How to Use CloudABI on FreeBSD URL: https://nuxi.nl/cloudabi/freebsd/ LevelDB for CloudABI URL: https://nuxi.nl/blog/2017/02/18/porting-leveldb-to-cloudabi.html Memcached for CloudABI URL: https://nuxi.nl/blog/2017/03/15/sandboxed-memcached.html Bitcoin for CloudABI URL: https://laanwj.github.io/2017/03/02/porting-bitcoin-core-to-clouda= bi.html Contact: Ed Schouten CloudABI is a framework that allows you to develop strongly sandboxed applications a lot more easily. It is a programming environment that exclusively uses FreeBSD's Capsicum facilities. Any features incompatible with Capsicum have been removed entirely, which means that it is easier to determine how code needs to be adjusted to behave correctly while sandboxed. In essence, you only need to patch up the code until it builds. Last year we have managed to port a lot of exciting libraries over to CloudABI. Highlights include sandboxing aware versions of Boost and LevelDB. Now that these libraries are readily available, we are at the point where we can shift our focus towards porting full applications. In late February one of the lead developers of the Bitcoin reference implementation got in touch, as he is very interested in creating a copy of Bitcoin that is better protected against security bugs. You do not want a security bug in the networking/consensus code to allow an attacker to steal coins from your local wallet! As I think that this is a use case that demonstrates the strength of CloudABI well, I've made addressing any issues reported by the Bitcoin developers a top priority. Once the Bitcoin port is complete, we want to provide binary packages of it as well. This project was sponsored by Nuxi, the Netherlands. Open tasks: 1. Though getting Bitcoin to work is pretty awesome, don't let that distract us from porting other pieces of software over as well! Are you the maintainer of a piece of software that could benefit from sandboxing? Be sure to try building it using the CloudABI toolchain! 2. One of the pieces of software that got ported over to CloudABI some time ago is Memcached. Are you a user of Memcached? If so, feel free to give the sandboxed version of Memcached for CloudABI a try! 3. So far, CloudABI can be used to run software written in C, C++ and Python. Would you like to see any other programming language work on CloudABI as well? Be sure to help out! __________________________________________________________________ Support for eMMC Flash and Faster SD Card Modes Contact: Marius Strobl In r315430, support for eMMC partitions has been added to mmc(4) and mmcsd(4) in FreeBSD 12. Besides the user data area, i.e., the default partition, eMMC v4.41 and later devices can additionally provide up to: * 1 enhanced user data area partition * 2 boot partitions * 1 RPMB (Replay Protected Memory Block) partition * 4 general purpose partitions (optionally with an enhanced or extended attribute) Apart from simply subdividing eMMC flash devices or having UEFI code in the boot partition, as is done on some Intel NUCs, another use case for partition support is the activation of pseudo-SLC mode, which manufacturers of eMMC chips typically associate with the enhanced user data area and/or the "enhanced" attribute of general purpose partitions. In order to be able to partition eMMC devices, r315430 also added a Linux-compatible ioctl(2) interface to mmcsd(4). This allows the use of the GNU mmc-utils (found in ports as sysutils/mmc-utils) on FreeBSD. Besides partitioning eMMC devices, the mmc tool can also be used to query for lifetime estimates and pre-EOL information of eMMC flash, as well as to query some basic information from SD cards. CAVEAT EMPTOR: Partitioning eMMC devices is a one-time operation. Additionally, in order to make eMMC flash devices more usable, support for DDR (Dual Data Rate) bus speed mode at a maximum of 52 MHz (DDR52) has been added to mmc(4) and sdhci(4) in r315598, which will appear in FreeBSD 12. Compared to high speed mode (the previous maximum) at 52 MHz, DDR52 mode increases the performance of the tested eMMC chips from ~45 MB/s to ~80 MB/s. So far, support for DDR52 mode has been enabled for the eMMC controllers found in the Intel Apollo Lake, Bay Trail and Braswell chipsets. Note, however, that the eMMC and SDHCI controllers of the Apollo Lake variant occasionally lock up due to a silicon bug (which is independent of running in DDR52 mode). The only viable workaround for that problem appears to be the implementation of support for ADMA2 mode in sdhci(4) (currently, sdhci(4) supports only the encumbered SDMA mode or no DMA at all). However, r315598 also brought in infrastructure and a fair amount of code for using even faster transfer modes with eMMC devices and SD cards respectively, i.e., up to HS400ES with eMMC and the UHS-I modes up to SDR104 with SD cards. The intent is to merge these changes back to FreeBSD 10 and 11. Open tasks: 1. Add support for eMMC HS200, HS400, and HS400ES transfer modes. 2. Add support for SD card UHS-I transfer modes (SDR12 to SDR104). 3. Make mmcsd(4) more robust and correctly follow the relevant specifications for existing features, e.g., calculate and handle erase timeouts, do a SEND_STATUS when CMD6 is invoked with an R1B response to the extent not already fixed as part of r315430, get the remainder of the existing code to properly check and handle return codes, etc. __________________________________________________________________ TrustedBSD Links TrustedBSD Website URL: http://www.trustedbsd.org TrustedBSD on GitHub URL: https://github.com/trustedbsd Contact: Christian Brueffer Contact: Robert Watson Contact: TrustedBSD announce mailing list The TrustedBSD Project is an open-source community developing advanced security features for the open-source FreeBSD operating system. Started in April 2000, the project developed support for extended attributes, access control lists (ACLs), UFS2, OpenPAM, security event auditing, OpenBSM, a flexible kernel access control framework, mandatory access control, and the GEOM storage layer. The results of this work may be found not just in FreeBSD, but also NetBSD, OpenBSD, Linux, and Apple's Mac OS X and iOS operating systems. Today, the project continues to maintain and enhance these mature features in FreeBSD. During this quarter, the TrustedBSD project transitioned from the FreeBSD Perforce server to GitHub. This was made possible by Alexis Sarghel, who owned the user "trustedbsd" on GitHub and graciously transferred this account to the TrustedBSD project. To date, the repositories hosting the TrustedBSD website and the SEBSD repository have been moved. __________________________________________________________________ Kernel FreeBSD on Hyper-V and Azure Links FreeBSD Virtual Machines on Microsoft Hyper-V URL: https://wiki.FreeBSD.org/HyperV Supported Linux and FreeBSD Virtual Machines for Hyper-V on Windows URL: https://technet.microsoft.com/en-us/library/dn531030.aspx Contact: Sepherosa Ziehau Contact: Hongjiang Zhang Contact: Dexuan Cui Contact: Kylie Liang SR-IOV support for NICs is implemented. So far, we have only tested with the Mellanox ConnectX-3 VF card, which works despite some issues (Bug 216493: https://bugs.FreeBSD.org/bugzilla/show_bug.cgi?id=3D216493). Updates for UEFI VMs (i.e., Hyper-V Generation 2 VMs): 1. After the loader issue (Bug 211746) is fixed, UEFI VMs can now boot with Secure Boot disabled; 2. A synthetic keyboard driver has been added. Currently it is only in HEAD, but MFCs to stable/10 and stable/11 are planned to occur soon; 3. A SCSI DVD detection issue (Bug 218248) was fixed. Without the fix, the VM would fail to boot. This project was sponsored by Microsoft. __________________________________________________________________ Intel 10G and 40G Network Driver Updates Links Commit adding X553 ix/ixv Support for iflib URL: https://reviews.FreeBSD.org/D9851 Commit converting ixgbe to iflib URL: https://reviews.FreeBSD.org/D5213 Contact: Jeb Cramer Contact: Eric Joyner Contact: Krzysztof Galazka This driver update is for the Intel ix/ixv and ixl/ixlv network drivers, and includes support for several new hardware releases. ix/ixv: * Added support for X553 SoC devices based on the Denverton platform ixl/ixlv: * Added support for X722 10G SoC devices based on the Lewisburg chipset * Added an interface for the upcoming iWarp driver for X722 devices * Added support for XXV710 25G devices Open tasks: 1. ix/ixv iflib support is currently under review in Phabricator. It will be refactored to include D5213. 2. Initial work for ixl/ixlv iflib support is in progress. __________________________________________________________________ Linuxulator Contact: Dimitry Chagin Contact: Edward Tomasz Napiera=C5=82a Contact: Mahdi Mokhtari In this quarter, we are pleased to announce two (of many) works achieved in the Linuxulator. We added a new placeholder marker UNIMPLEMENTED to accompany the previously existing DUMMY, for distinguishing syscalls that the Linux kernel itself does not implement from those that we currently do not implement. Now our linux_dummy.c is clearer for newcomers to follow, and they will quickly know which areas they can start working on. Support for two new syscalls, preadv and pwritev, was added to the Linuxulator. Open tasks: 1. We plan to implement the execveat syscall for the native FreeBSD syscall table and then port/wrap it for use in the Linuxulator. __________________________________________________________________ MMC Stack Using the CAM Framework Links Project Information URL: https://bakulin.de/freebsd/mmccam.html Source Code URL: https://github.com/kibab/FreeBSD/tree/mmccam-collapsed-commits Contact: Ilya Bakulin The goal of this project is to reimplement the existing MMC/SD stack using the CAM framework. This will permit utilizing the well-tested CAM locking model and debugging features. It will also be possible to process interrupts generated by the inserted card, which is a prerequisite for implementing the SDIO interface. SDIO support is necessary for communicating with the WiFi/BT modules found on many development boards, such as the Raspberry Pi 3. Another feature that the new stack will have is support for sending SD commands from userland applications using cam(3). This will allow for building device drivers in userland and make debugging much easier. The new stack is able to attach to an SD card and bring it to an operational state so that it is possible to read and write to the card. The stack has been tested to work on the Beaglebone Black and Wandboard Quad platforms. Currently the code is being prepared for inclusion in the FreeBSD source tree. cam(3) is being extended to support SDIO-specific functions (reading registers, managing interrupts, etc.). Open tasks: 1. Integrate the code into FreeBSD HEAD to facilitate testing. 2. Begin writing a driver for Broadcom-based WLAN chips (found on the Raspberry Pi 3 and Wandboard). 3. Begin writing a driver for Marvell-based WLAN chips (found on the GlobalScale Dreamplug and some Chromebooks). __________________________________________________________________ pNFS Server Plan B Contact: Rick Macklem Parallel NFS (pNFS) is an extension to the NFSv4 protocol that allows for file accesses within a single logical mount to be performed against multiple file servers, with the potential for data access to occur in parallel. The pNFS "layout" in use specifies how the division occurs, with metadata operations occurring against the main server, and bulk data operations (read/write/setattr/etc.) occurring via a layout-specific scheme between the client and data servers. My first attempt at a pNFS server using GlusterFS was a dud. It worked, but performance was so poor that it was not usable. This attempt that I call "Plan B", only uses FreeBSD, with one FreeBSD server handling the metadata operations and multiple FreeBSD servers configured to serve data. An NFSv4.1 client that supports the pNFS File Layout will be able to read and write to the data servers directly, spreading out the RPC load and allowing growth beyond that of what a single FreeBSD NFS server could achieve. There is no support for the Flex Files Layout or mirroring at this time. I hope to use the Flex Files Layout to add mirroring support over the next year or so. Striping is also not supported, but I have no plans for implementing it at the moment. Plan B is working quite well now and should be available for testing by the end of April. I will announce how to do this on the freebsd-fs@FreeBSD.org mailing list when it is available. Open tasks: 1. Testing by others will be needed, once it is available. __________________________________________________________________ Architectures 64-bit PowerPC Book-E Support Contact: Justin Hibbits The Book-E platform target now supports 64-bit mode ("powerpc64"). It includes a 63-bit address space split, but the page table directory list uses holes to expand to the full address space, leaving gaps in the address space where page mappings are repeated. This may change in the future. As with the AIM powerpc64 port, Book-E supports running powerpc (32-bit) binaries as well, and has even been tested with a 32-bit init and 64-bit shell. Several of the SoC drivers are supported, however, the dTSEC ethernet controller is not yet supported. Work is ongoing to support it. A QORIQ64 config is included, targeting the P5 and T* series SoCs from Freescale. Thanks to Juniper Networks for providing patches against an older internally maintained FreeBSD version, which enabled this porting effort, and for providing historical context for quirks of the pmap changes. Open tasks: 1. Port the dTSEC driver to 64-bit. There are assumptions in the reference driver of operating in a 32-bit environment. It may be easier to port the Linux driver instead, which would also give ARM support for this ethernet controller. 2. Take advantage of pointer alignment to squeeze more bits out of the page tables; it should be possible to squeeze at least 3 more bits out, one at each level. __________________________________________________________________ FreeBSD on Marvell Armada38x Contact: Marcin Wojtas Contact: Zbigniew Bodek Final testing and productionization of support for the Marvell Armada38x platform is under way. The rebase and cleanup is going well, with patches functioning on top of HEAD and ready for upstreaming. Specific tasks completed include: * Platform benchmarking and low-level optimizations (internal bus, L1/L2 cache prefetch) -- already submitted) * Enable the PL310 L2 cache controller -- currently under review * NETA tests, optimizations and PHY-handling rework * e6000sw PHY handling rework and fixes * Fix and enable performance counter support * Fix timers and extract watchdog support to a separate driver * Crypto driver fixes -- merged * AHCI controller support -- merged * Thermal driver -- merged * Merge additional support for new boards (SolidRun ClearFog and DB-88F6285-AP) This project was sponsored by Stormshield, and Semihalf. Open tasks: 1. Submit the remaining fixes and drivers. __________________________________________________________________ FreeBSD/s390x Attempt III Contact: Bjoern A. Zeeb A long time ago, in the FreeBSD 5 times, there was an initial port of FreeBSD to s390 (32bit) and s390x (64bit) which booted past init on good days in an emulator. As an attempt to revive the s390x/systemz efforts I started to get FreeBSD s390x to build with clang/llvm 3.9. At this time, it is possible to build world and a GENERIC kernel skeleton (not doing anything yet) using external binutils. The primary idea of this initial work was to allow for incremental addition of the necessary architecture-specific code. Having the build framework in place will allow third-party developers to simply type make, as they are willing to contribute to the port without having to know FreeBSD build specifics. After some cleanup and further updates to a more recent HEAD I am planning to push the current work to a public repo to facilitate collaboration. Open tasks: 1. Write a wiki page with per-architecture specific tasks that need to be done, based on the current work and the experience from arm64 and riscv. 2. Implement both the userspace and kernel per-architecture gaps. 3. Figure out a way to get access to IBM's zPDT or better emulators to ease implementation, testing, and debugging. __________________________________________________________________ Ports MySQL Links MySQL80 Overview URL: https://www.mysql.com/why-mysql/presentations/mysql-80-overview/ MySQL80 InnoDB New Features URL: https://www.mysql.com/why-mysql/presentations/innodb-whats-new-mys= ql-80/ Contact: Mahdi Mokhtari Contact: Mark Felder This quarter a new -dev version of MySQL landed in the Ports Collection, MySQL 8.0. It introduces many new features, though we had to (re)-patch parts of it which were merged by MySQL from MySQL5.7. We also updated MySQL 5.6 to its latest version and closed many PRs related to it, mostly relating to using FreeBSD-provided ports for libraries instead of the bundled copies. And of course there were plenty of security updates. We can also report that the problem of having to specify ${mysql_optfile}, which some people encountered while using MySQL, is now considered to be solved in all MySQL versions: 5.6, 5.7, and 8.0. Now the init script will search all default locations, for backwards compatibility with the variety of locations used for configuration files, before it gives up and reports an error. Open tasks: 1. Test the new version and report problems. __________________________________________________________________ Rust Links Wiki Portal URL: https://wiki.FreeBSD.org/Rust Guide to Bootstraping Rust on FreeBSD URL: https://gist.github.com/dumbbell/b587da50ef014078da9e732a4331ebad Bug Report to Track Progress on Bootstrapping URL: https://bugs.FreeBSD.org/bugzilla/show_bug.cgi?id=3D216143 Contact: Jean-S=C3=A9bastien P=C3=A9dron Contact: Thomas Zander In the Ports Collection, Rust was updated to 1.16.0 and Cargo to 0.17.0, the latest versions at the time of this writing. lang/rust-nightly was also updated to a snapshot from February and it is now enabled on i386. It is lagging a bit behind upstream, but Rustup works nicely on FreeBSD if you need to try any versions/channels of Rust. Work has started to bootstrap Rust on non-x86 architectures. Patches to add FreeBSD/aarch64 support were submitted and accepted upstream. FreeBSD/sparc64 is in progress. The lang/rust-nightly port is also being adapted to compile natively on FreeBSD/aarch64. This work is critical, in particular because Firefox will shortly require Rust. If you want to help, please refer to the guide linked above. The compiler, rustc, is crashing sometimes when there is a compilation error. Therefore, there is a bit of work to do to improve stability. There is some code duplication between lang/rust* and devel/cargo. Those Makefiles deserve a bit of cleanup. It might be useful to create a USES=3Drust Makefile helper. Open tasks: 1. Bootstrap Rust on more platforms. 2. Investigate compiler crashes. 3. Create a USES=3Drust Makefile helper and simplify the Rust and Cargo ports. 4. Investigate how to speed up lang/rust* compilation time. __________________________________________________________________ Documentation The FreeBSD Dutch Documentation Project Links The Dutch Translation Project URL: https://www.FreeBSD.org/docproj/translations.html#dutch Contact: Ren=C3=A9 Ladan Contact: Remko Lodder Work has started on an initial translation of the FreeBSD Handbook to the Dutch language via the "po" system. While we have an (outdated) version of the Handbook available via the older XML files, we are now trying to get back into shape with the PO file. Rene started working on two articles already and did some translation of strings for the FDP-Primer, while Remko has started working on the Handbook. If you think you can assist with either, please send Rene and Remko an email so that we can start coordinating work. In addition, since we have a translation set already from the XML files, it would be interesting to see whether we can merge them easily into the PO structure. If you have ideas on that, contact us a.s.a.p. This project was sponsored by Snow B.V. (in part). Open tasks: 1. Identify a way to merge the current XML translations into the nl_NL.po files. 2. Merge the translations into the .po files. 3. Update the remaining open items into the po files. 4. Remove the old/outdated translation files from the main repo and use the po and book.xml files to generate the Dutch handbook and other files. 5. Identify whether we can also translate the htdocs pages via the PO system. __________________________________________________________________ --A6N2fC+uXW/VQSAv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGgBAABCgAGBQJZGoM+AAoJECjZpvNk63UShiEMHiNj+z/V8LxFhIyFRTsKOJNQ KgEiR6NuUgGSYoanKkzSf2BO5MnhfbN3tSnxMx+WphyoV1WFdSiYBpgZEHOGWmta Z3pG6ov4n8IrHwhX71CoWcwawumDcA6aUrPoHlkJcG0HfLiyfp47BjHS85RmneR0 6BxcrvaCBkguL1fyiQUBlHqyhpFK0GqUBdihvkAUKFBjfXmPFLvmlJczrrDghbn6 ALD948qxIrGvvjAidp19gwft+9BMi6uxxLr+WAHQD5MejF3y8w7D1KPv3cJiaUV8 NULjQr+bGqkfvtRGKs94MyQdsvM+71QLsrpaVTdckMFlxTsRbRSkzzNGKWoi6vNR HF34QWqEE3upiqIEncSpDQY1wHi0yaL8VqAANavfUQT/xY1ZVwxdGaqx8mtUts4r T2solV102RYjVtXeS97/8u+1nqq8h9IVmttmQPLI8hj6MKCkurE0uOr169gXBmoy IV0A+cxjC6D2cKVRS5UwOjapt32l6bQQbgwADf+D8gwNHMk= =D2eA -----END PGP SIGNATURE----- --A6N2fC+uXW/VQSAv-- From owner-freebsd-current@freebsd.org Tue May 16 04:56: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 7F5D5D6E73D for ; Tue, 16 May 2017 04:56:38 +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 F331BCD2 for ; Tue, 16 May 2017 04:56:37 +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 0MBnSJ-1dK92A2bm3-00Ak45 for ; Tue, 16 May 2017 06:56:29 +0200 Date: Tue, 16 May 2017 06:56:23 +0200 From: "O. Hartmann" To: freebsd-current Subject: IFLIB: em0/igb0 broken: No buffer space available/TX(0) desc avail = 1024, pidx = 0 Message-ID: <20170516065623.6e2de036@freyja.zeit4.iv.bundesimmobilien.de> Organization: Walstatt X-Mailer: Claws Mail 3.15.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Bj4OyTOIZQIKyQEpSn2Yc4eLCy9eBIH7oBGCoUOvjugt7simTnz xY4TtTFrPMbHwFyms4rcJ0XT0aK0IVg8+gqL1CLOwXsGyMZcfRPIb8YZxo14mIl6greItk0 CVGY8SUoo25yIsNQcrwqRe5M3UJ83sTRlZDWH3GBirgqQVk9DLldXldg5Bqf3s3qUJey1ai AUpGRUoIAbf2nPn7X6piA== X-UI-Out-Filterresults: notjunk:1;V01:K0:ZtgsmVS1v+o=:eWR0XXMlowEa1vkR8dnaMM JFkC6EMWZZtDZrRLdZloaEyUC7K1eOk9MwK4uXRsPcBxr4YNWtmM95xN0fLng9fhknKTmknnV 82QgNwXyqNNwx72v1/2i/2w5aCTZ2N1b4oS5/b0EvsMCcZw67TDoCT96GyhSsTfDTTfJ2clSh qiqDjlf3bxtZEVjBqE8Czf/IjdUb27pTfNY7reqSK9ISQ0BlgwoGK6QHWCGuvp9KXkBr4vKn7 9s1ETs9pgmQTR6UbFjM+4sUwwz0PGZVkVS8slw6SagVIev+tSalzZ/VqkhSvRitqQAeb7IsPF 9P2n9ngO6+iBc66lHqT2CRktkPPIGKi44335/tj9FjdwOH1eJG3fiaZOQ/RRfuEXFFblZPoPZ CP5Rn49f75pfZbE5aahRHC3UAzjbutgR7fA9LhKkfhX3J+UhVZc3ryXIJbPCwRtFGXtW8ccS4 irhzptFm6NC8wdHdv6eeEwTKrT55cNdrk6CdfSSAc/YK/G67kKoXz2nNOc1XY634LK5MntAhE 6kbzdIVc4HaQZ9EfMEHzE8XouZI2eKwysH/+xdPEzpXEA6njgEmvs4dUTLFlxTrE13jMPEI8U 66efNEyxRNgAAI/E3mjgkyPq1RZYfq0R8O3bwY7n6lnbrK9XCLkwhVjVCazc59chIAi3UqS1a dj5OWyS9yzC4PqrTCgVfvM4JnB40vvP1qH01Onb6s3UweRReMYT1Y67SI/DfPMOh+XRNtrTnp dvhMy2hazXAeNaDrqB9UWwBI8MsiCwL6KqitE1DJyc9mqNGC/lhf0+CTob93JR2/FaMgJvtDC hHmBAKK 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, 16 May 2017 04:56:38 -0000 Since the introduction of IFLIB, I have big trouble with especially a certain type of NIC, namely formerly known igb and em. The worst device is an Intel NIC known as i217-LM em0@pci0:0:25:0: class=0x020000 card=0x11ed1734 chip=0x153a8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Ethernet Connection I217-LM' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xfb300000, size 131072, enabled bar [14] = type Memory, range 32, base 0xfb339000, size 4096, enabled bar [18] = type I/O Port, range 32, base 0xf020, size 32, enabled This NIC is widely used by Fujitsu's workstations CELSIUS M740 and the fate would have it, that I have to use one of these. When syncing data over the network from the workstation to an older C2D/bce based server via NFSv4, since introduction of IFLIB the connection to the NFS get stuck and I receive on the console messages like em0: TX(0) desc avail = 1024, pidx = 0 em0: TX(0) desc avail = 42, pidx = 985 Hitting "Ctrl-T" on the terminal doing the sync via "rsync", I see then this message: load: 0.01 cmd: rsync 68868 [nfsaio] 395.68r 4.68u 4.64s 0% 3288k (just for the record) Server and client(s) are on 12-CURRENT: ~ FreeBSD 12.0-CURRENT #38 r318285: Mon May 15 12:27:29 CEST 2017 amd64, customised kernels and "netmap" enabled (just for the record if that matters). In the past, I was able to revive the connection by simply putting the NIC down and then up again and while I had running a ping as a trace indication of the state of the NIC, I got very often ping: sendto: No buffer space available Well, today I checked via dmesg the output to gather again those messages and realised that the dmesg is garbled: [...] nfs nfs servnnfs servefs r server19 2.19162n.fs snerver fs1 s9nfs s2er.nfs server er192.168.0.31:/pool/packages: not responding v er 192.168.0.31ver :/po1ol/packages9: 2.168.0.31:/pool/packagesn: noot responding t <6>n fs serverespondinngf s server 192.168.1rn nfs server 192.168.0.31:/pool/packages: not1 responding 9 2.168.1f7s 0.31:/pool/packagenfs sesrver 19serv2er .168.0.31:/poo: not respolnding / packages: not responding nfs server 19192.168.0.31:/pool/pa2c.k168.0.31:a/gpserver ne1s92.168.0.31:/pool/pac: knot respaof1s68 gs.e17rve8r.2 3192.168.0.31:/pool/packa1:/pool/packages: not responding o goes: nl/packages: not responding o t responding nfs server 192.168.0.31:/poes: ol/packages: nfns server 192.168.0.31:/pool/paot responding c kages: not respondinnfs server n192.1f68.0.31:/pool/packagess: ndi server 192.168.0.31:/pool/packages: not responding [...] Earlier this year after introduction of IFLIB, I checked out servers equipted with Intels very popular i350T2v2 NIC and I had similar problems when dd'ing large files over NFSv4 (ZFS backed) from a client (em0, a client/consumer grade older NIC from 2010, forgot its ID, towards server with i350, but the server side got stuck with the messages seen similar to those reported with the i217-LM). Since my department uses lots of those server grade NICs, I will swap the i217 with a i350T2 and check again. Nevertheless, the situation is very uncomfortable! Kind regards, Oliver From owner-freebsd-current@freebsd.org Tue May 16 06:03: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 A4B9CD6F11F for ; Tue, 16 May 2017 06:03:20 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 3DA8DDCD for ; Tue, 16 May 2017 06:03:20 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: by mail-wm0-x229.google.com with SMTP id b84so116590290wmh.0 for ; Mon, 15 May 2017 23:03:20 -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=UAZUOK8T6CQc0NE/HimgADNu9ggKVhAN3XUMZ+W5AyQ=; b=LZQxeukbSlHdD+KSxlupQiASLHeQWxiGuD5rfP2Pd36tJ4HEkRn5vwKHN3aPy5FwEJ d78p4uYJiB9BKrhVUWU1JovjZrDaoKNevctvfMIkyxCzg5N5DT8zVBaee0daSos9FNH9 SI75etpRF6VW6Ax+v/uMbaipGgqyer2osFE4wmyG1x2OR0K64NcRTyv/PJhlkmpDN7io Cffm8oUUEoGruEBd/tujxhcG99bYU3UM0yKNWasJ/eCCNKneEV/NHEgCV06tGZIiP+64 lSx0CmLYK+O86IC0s8m81zhp9Wbs3Cfrov2k9IH80kYKkXJCMaLTVwg1Zitj8APj+G8N SC4w== 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=UAZUOK8T6CQc0NE/HimgADNu9ggKVhAN3XUMZ+W5AyQ=; b=RrDacfrPrpqlTySqIiveAdxpfMbDz3ST0Xe5k3KLFIvuvEPQ2hQH9+Ngysv7rB3AFF dlfWFXyLDI9S9qf3Jbc4wEQxCfUFRxqX9VRqZYGc5t/4pa3dNRzIuT6bffQwE9oidpIe pK4p3JMv+KXu9rG0Y7BrsidgCbqJAsq4Yuw003FEFXIiou/Y6SIQFxe+z/u8Nbsjsw9L Za7tf2RtqeyHBi/2LpyoG1CpeLnP45lAZ/hgWczwWxocVXQqrQVOvCSSKd8PjVLhDJUa cJstTz+DSEHOBN11CEjkoXe4jggieiHl50SO02BFfhRlHW1tt89NMqCBmHIsjvU10tG/ 6foA== X-Gm-Message-State: AODbwcBI/qvq2sagUPUXFsd3XVL8y6xIENnu8WAwwnMsFRis57SZUapw xfFCEAk+NbmlZ+LfgNn4ZrpMkSEsCQ== X-Received: by 10.223.148.132 with SMTP id 4mr7880430wrr.119.1494914598543; Mon, 15 May 2017 23:03:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.164.11 with HTTP; Mon, 15 May 2017 23:03:18 -0700 (PDT) From: Johannes Lundberg Date: Tue, 16 May 2017 08:03:18 +0200 Message-ID: Subject: build src with colored output? To: freebsd-current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 06:03:20 -0000 Hi I'm sure this has been discussed but my Google-fu couldn't find me any information.. I get colored output when building kernel with a single thread, however, for -j > 1 colored output is disabled. Anyone know what's the reason for this? /Johannes From owner-freebsd-current@freebsd.org Tue May 16 06:42:17 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 90833D6FE42 for ; Tue, 16 May 2017 06:42:17 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 2F541EA for ; Tue, 16 May 2017 06:42:17 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: by mail-wm0-x231.google.com with SMTP id v15so78479607wmv.1 for ; Mon, 15 May 2017 23:42:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=eJjbqeNz1MQRxHZSkxU+4+jWwMhlWAnyvFIDdW3Vfq0=; b=KDJt9gWCga+zoSxGvL8mSu9pLxr1YXddtoxH1diNLjvAk+0UrAM18lvP73ABPg3WiS lGGt3UawKxJGCW2VVKwaQLspOvTeX9H90IUNtJ2VEuOv4Wr9xrDxMIiq7+DPVmqf4GxC aTXyz3+mYpISz4JTfc5w/qtOFN9g4JnUobcL3R07EneP/1rqOhhPGv2MdzICsYeIHjuL dDqqvcimXJqzgwP91vvcv+mHsMbREaUWTqBuXbfMyWEwUEphjNJLKeC7VUmKba82KFwj 5lfKiaoQEHErG0firtIKWXtITh9CXapm1KMiI+02PenAfP3vrF9iY+DUop4479bLw/ho y27w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=eJjbqeNz1MQRxHZSkxU+4+jWwMhlWAnyvFIDdW3Vfq0=; b=chAK6bUvRdyWofzzSXp1UVD97wQY1Dp60ykB1mqykeCcIj9+l8pCCSPUaMycL6VPbG UYDFvKz57w8p+MP0+SSDVvXmjQPbMfEO2BoCmm3H4jrJc3gi6MbbqHn2sKtYTCCaJaCp 2MujRQIU66uMwWo8kD2ltxaelWbGOh8kFdAW+jK1GH/TxBHWzvyJwTUCbzkraeXMQCG5 G++4gno2QBFr1TDDLhk1tzNktTCoJf8RbVIjGjIQn3ZB8SZfLejCucu8SNYl9JCs1Xgc ABsyMOh0jvtA3tmJMYIATw+RVxj05nXNWzB3BLE//lkwXrNnmBtrpA8LovExLyeUtRcX 4jwg== X-Gm-Message-State: AODbwcA0E5qHX+IfKbzB7PX31ABpIwIsXivsEuV5tI0LnUHNSNP1ISrF 9dAl6WAGbOESg6YGT7fW1ys6jnypYZoc X-Received: by 10.223.151.146 with SMTP id s18mr6442906wrb.40.1494916934823; Mon, 15 May 2017 23:42:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.164.11 with HTTP; Mon, 15 May 2017 23:42:14 -0700 (PDT) In-Reply-To: References: From: Johannes Lundberg Date: Tue, 16 May 2017 08:42:14 +0200 Message-ID: Subject: Re: build src with colored output? To: freebsd-current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 06:42:17 -0000 Gonna answer myself here. Think I found a way. Add CFLAGS=-fcolor-diagnostics to env or /etc/src.conf Do clean build, that is no -DNO_CLEAN,KERNFAST, etc. Makes it a lot easier to find the errors in a 16 threads build output... The mystery still remains though, why is color disabled for parallel builds? On Tue, May 16, 2017 at 8:03 AM, Johannes Lundberg wrote: > Hi > > I'm sure this has been discussed but my Google-fu couldn't find me any > information.. > > I get colored output when building kernel with a single thread, however, > for -j > 1 colored output is disabled. > > Anyone know what's the reason for this? > > /Johannes > > From owner-freebsd-current@freebsd.org Tue May 16 06:47:37 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 39C0BD6FF97 for ; Tue, 16 May 2017 06:47:37 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 D4F33333 for ; Tue, 16 May 2017 06:47:36 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: by mail-wm0-x22a.google.com with SMTP id b84so118164505wmh.0 for ; Mon, 15 May 2017 23:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=JHd05vqpCjrMzcdFCMEf/H8La7ZRSNVF25fHLliUFP4=; b=CKAAiIBn+STlRl59OANqgpcp1+/JP1LB7O+E5ypFrROaPm9KO0FZccR/bHpf/tfEcM qYvvLuWAEyYD8N/eQrWHGCD0fOujv+krF2/35Wtn8aWFs6v+Ug0KTk5YkM8f+H/32W2+ BcM3PYv6IFQ3Wqouc0dvcHMlIhp9Knbvwmq/55Z0KghZKGEwV1iyOSIFyFQPiMXVvFNd IKJp4Hu6/puXbOnKGMulF0KPSuu+0SkSyylLSbCpZY2oy0i2p60ypaULNxCrwOqI7GQ1 ngBellyT4Adeb0e6q51x0KfaBpoBAcwaZolRaBHQe9o9qz6fQUfDZgnAwF24MiCnjdJ1 KTOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=JHd05vqpCjrMzcdFCMEf/H8La7ZRSNVF25fHLliUFP4=; b=PBujAY2aNcegMK8lDayCDT++HdPsMHN1g7zjW9dcUnyU+xWCfmn2QnR0hLTSXkcaT0 ohiu3D1jwdwQRAyg67PMis/NA5CgJS21DL0hmKOG+HUglfl35tRZSky39vZAYP5PTOJf vlLj6R7MFDyNLLXUEh6QoW71FUvmYyDorHUv1I7DBs+Z78y6q1yRe1Xio7uoXx8RBtP6 wZJII+08c1d4jFRsDmlu7+9nf0Y5zdvrFvBXc/0BubVpu8sgWGedU19rVdpDz7AUcbkE srZFWQwjTziJC9JcrPGi4KALbfUH6x0caC/G1TwG5y1oW4FQ8FGszlSHZ7s4YZREkuNV wb8A== X-Gm-Message-State: AODbwcCMAbJr1EzetAd6JpOVp68DZYcQm1CPERYbERXs9kjCp3cUgVL4 IJn46MKQt0B9gSSmD2dnJJ+nlqb6oQ== X-Received: by 10.223.148.132 with SMTP id 4mr8039141wrr.119.1494917255153; Mon, 15 May 2017 23:47:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.164.11 with HTTP; Mon, 15 May 2017 23:47:34 -0700 (PDT) In-Reply-To: References: From: Johannes Lundberg Date: Tue, 16 May 2017 08:47:34 +0200 Message-ID: Subject: Re: build src with colored output? To: freebsd-current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 06:47:37 -0000 Hmm, with the previously mentioned solution, colored output was lost half way through the build... Going to do a single thread clean build later when I have the time to wait and see what the results are. On Tue, May 16, 2017 at 8:42 AM, Johannes Lundberg wrote: > Gonna answer myself here. Think I found a way. > > Add CFLAGS=-fcolor-diagnostics to env or /etc/src.conf > Do clean build, that is no -DNO_CLEAN,KERNFAST, etc. > > Makes it a lot easier to find the errors in a 16 threads build output... > > The mystery still remains though, why is color disabled for parallel > builds? > > > On Tue, May 16, 2017 at 8:03 AM, Johannes Lundberg > wrote: > >> Hi >> >> I'm sure this has been discussed but my Google-fu couldn't find me any >> information.. >> >> I get colored output when building kernel with a single thread, however, >> for -j > 1 colored output is disabled. >> >> Anyone know what's the reason for this? >> >> /Johannes >> >> > From owner-freebsd-current@freebsd.org Tue May 16 08:40: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 C8DB3D6FDB1 for ; Tue, 16 May 2017 08:40:28 +0000 (UTC) (envelope-from prvs=302023821=roger.pau@citrix.com) Received: from SMTP.EU.CITRIX.COM (smtp.ctxuk.citrix.com [185.25.65.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "DigiCert SHA2 Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 507491BA2 for ; Tue, 16 May 2017 08:40:27 +0000 (UTC) (envelope-from prvs=302023821=roger.pau@citrix.com) X-IronPort-AV: E=Sophos;i="5.38,348,1491264000"; d="scan'208";a="46116120" Date: Tue, 16 May 2017 09:39:11 +0100 From: Roger Pau =?iso-8859-1?Q?Monn=E9?= To: Subject: buildworld not working with MAKEOBJDIRPREFIX Message-ID: <20170516083911.agudcf7m62xiyhui@dhcp-3-128.uk.xensource.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: NeoMutt/20170428 (1.8.2) X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) 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, 16 May 2017 08:40:28 -0000 Hello, I'm trying to build world as a regular user, using sources fetched into my home directory and a different object directory. The rune I'm using to build is: $ cd /home/royger/buildjob/freebsd $ make -j30 buildworld MAKEOBJDIRPREFIX=/home/royger/buildjob/obj/ And this leads to the following build error: --- all_subdir_rescue --- --- cat.lo --- cc -target x86_64-unknown-freebsd12.0 --sysroot=/home/royger/buildjob/obj//usr/home/royger/buildjob/freebsd/tmp -B/home/royger/buildjob/obj//usr/home/royger/buildjob/freebsd/tmp/usr/bin -O2 -pipe -std=gnu99 -Qunused-arguments -nostdlib -Wl,-dc -r -o cat.lo cat_stub.o /home/royger/buildjob/obj//usr/home/royger/buildjob/freebsd/rescue/rescue//usr/home/royger/buildjob/freebsd/bin/cat/cat.o cc: error: no such file or directory: '/home/royger/buildjob/obj//usr/home/royger/buildjob/freebsd/rescue/rescue//usr/home/royger/buildjob/freebsd/bin/cat/cat.o' *** [cat.lo] Error code 1 AFAIK this should work fine, does anyone has any clues about what causes this failure? Thanks, Roger. From owner-freebsd-current@freebsd.org Tue May 16 10:13: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 D4155D6E8FB; Tue, 16 May 2017 10:13:02 +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 08FA21221; Tue, 16 May 2017 10:13:01 +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 NAA04494; Tue, 16 May 2017 13:12:54 +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 1dAZTJ-0005IB-SI; Tue, 16 May 2017 13:12:53 +0300 Subject: Re: zfs recv panic To: Kristof Provost , Freebsd current , freebsd-fs@FreeBSD.org References: <18A74EE1-3358-4276-88EA-C13E28D8563A@sigsegv.be> From: Andriy Gapon Message-ID: <98df7d70-4ecb-34f2-7db2-d11a4b0c854a@FreeBSD.org> Date: Tue, 16 May 2017 13:11:32 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <18A74EE1-3358-4276-88EA-C13E28D8563A@sigsegv.be> Content-Type: text/plain; charset=utf-8 Content-Language: en-US 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, 16 May 2017 10:13:02 -0000 On 10/05/2017 12:37, Kristof Provost wrote: > Hi, > > I have a reproducible panic on CURRENT (r318136) doing > (jupiter) # zfs send -R -v zroot/var@before-kernel-2017-04-26 | nc dual 1234 > (dual) # nc -l 1234 | zfs recv -v -F tank/jupiter/var > > For clarity, the receiving machine is CURRENT r318136, the sending machine is > running a somewhat older CURRENT version. > > The receiving machine panics a few seconds in: > > receiving full stream of zroot/var@before-kernel-2017-04-03 into > tank/jupiter/var@before-kernel-2017-04-03 > panic: solaris assert: dbuf_is_metadata(db) == arc_is_metadata(buf) (0x0 == > 0x1), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c, > line: 2007 Kristof, could you please try to revert commits related to the compressed send and see if that helps? I assume that the sending machine does not have (does not use) the feature while the target machine is capable of the feature. The commits are: r317648 and r317414. Mot that I really suspect that change, but just to eliminate the possibility. Thank you. > cpuid = 0 > time = 1494408122 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0120cad930 > vpanic() at vpanic+0x19c/frame 0xfffffe0120cad9b0 > panic() at panic+0x43/frame 0xfffffe0120cada10 > assfail3() at assfail3+0x2c/frame 0xfffffe0120cada30 > dbuf_assign_arcbuf() at dbuf_assign_arcbuf+0xf2/frame 0xfffffe0120cada80 > dmu_assign_arcbuf() at dmu_assign_arcbuf+0x170/frame 0xfffffe0120cadad0 > receive_writer_thread() at receive_writer_thread+0x6ac/frame 0xfffffe0120cadb70 > fork_exit() at fork_exit+0x84/frame 0xfffffe0120cadbb0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0120cadbb0 > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > KDB: enter: panic > [ thread pid 7 tid 100672 ] > Stopped at kdb_enter+0x3b: movq $0,kdb_why > db> > > > kgdb backtrace: > #0 doadump (textdump=0) at pcpu.h:232 > #1 0xffffffff803a208b in db_dump (dummy=, dummy2= optimized out>, dummy3=, dummy4=) at > /usr/src/sys/ddb/db_command.c:546 > #2 0xffffffff803a1e7f in db_command (cmd_table=) at > /usr/src/sys/ddb/db_command.c:453 > #3 0xffffffff803a1bb4 in db_command_loop () at /usr/src/sys/ddb/db_command.c:506 > #4 0xffffffff803a4c7f in db_trap (type=, code= optimized out>) at /usr/src/sys/ddb/db_main.c:248 > #5 0xffffffff80a93cb3 in kdb_trap (type=3, code=-61456, tf= out>) at /usr/src/sys/kern/subr_kdb.c:654 > #6 0xffffffff80ed3de6 in trap (frame=0xfffffe0120cad860) at > /usr/src/sys/amd64/amd64/trap.c:537 > #7 0xffffffff80eb62f1 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:236 > #8 0xffffffff80a933eb in kdb_enter (why=0xffffffff8143d8f5 "panic", msg= optimized out>) at cpufunc.h:63 > #9 0xffffffff80a51cf9 in vpanic (fmt=, > ap=0xfffffe0120cad9f0) at /usr/src/sys/kern/kern_shutdown.c:772 > #10 0xffffffff80a51d63 in panic (fmt=) at > /usr/src/sys/kern/kern_shutdown.c:710 > #11 0xffffffff8262b26c in assfail3 (a=, lv= out>, op=, rv=, f= out>, l=) > at /usr/src/sys/cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:91 > #12 0xffffffff822ad892 in dbuf_assign_arcbuf (db=0xfffff8008f23e560, > buf=0xfffff8008f09fcc0, tx=0xfffff8008a8d5200) at > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:2007 > #13 0xffffffff822b87f0 in dmu_assign_arcbuf (handle=, > offset=0, buf=0xfffff8008f09fcc0, tx=0xfffff8008a8d5200) at > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:1542 > #14 0xffffffff822bf7fc in receive_writer_thread (arg=0xfffffe0120a1d168) at > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_send.c:2284 > #15 0xffffffff80a13704 in fork_exit (callout=0xffffffff822bf150 > , arg=0xfffffe0120a1d168, frame=0xfffffe0120cadbc0) at > /usr/src/sys/kern/kern_fork.c:1038 > #16 0xffffffff80eb682e in fork_trampoline () at > /usr/src/sys/amd64/amd64/exception.S:611 > #17 0x0000000000000000 in ?? () > > Let me know if there’s any other information I can provide, or things I can test. > Fortunately the target machine is not a production machine, so I can panic it as > often as required. -- Andriy Gapon From owner-freebsd-current@freebsd.org Tue May 16 08:29: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 D82BED6FB16 for ; Tue, 16 May 2017 08:29:25 +0000 (UTC) (envelope-from dc552@hermes.cam.ac.uk) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) (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 991941789 for ; Tue, 16 May 2017 08:29:25 +0000 (UTC) (envelope-from dc552@hermes.cam.ac.uk) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from host109-151-49-114.range109-151.btcentralplus.com ([109.151.49.114]:49903 helo=[192.168.1.65]) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587) with esmtpsa (PLAIN:dc552) (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1dAXr9-0003tW-RY (Exim 4.89) (return-path ); Tue, 16 May 2017 09:29:23 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: build src with colored output? From: David Chisnall In-Reply-To: Date: Tue, 16 May 2017 09:29:25 +0100 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Johannes Lundberg X-Mailer: Apple Mail (2.3124) Sender: "Dr D. Chisnall" X-Mailman-Approved-At: Tue, 16 May 2017 11:05: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: Tue, 16 May 2017 08:29:25 -0000 On 16 May 2017, at 07:42, Johannes Lundberg wrote: >=20 > Gonna answer myself here. Think I found a way. >=20 > Add CFLAGS=3D-fcolor-diagnostics to env or /etc/src.conf > Do clean build, that is no -DNO_CLEAN,KERNFAST, etc. >=20 > Makes it a lot easier to find the errors in a 16 threads build = output... >=20 > The mystery still remains though, why is color disabled for parallel > builds? It=E2=80=99s disabled for two reasons. The first is aesthetic - some = people don=E2=80=99t like coloured output. I=E2=80=99m not going to = debate that one. The other is technical. Unlike modern build tools, = such as Ninja, bmake=E2=80=99s handling of multithreaded output is very = bad. It simply allows each task the same output device, whereas ninja = gives each parallel job a pipe back to the build process and then merges = the output itself. This means that you periodically encounter the case = where one child process has sent a colour escape sequence to the output = and then another process sends the next line, giving weird visual = effects and reducing the utility of colour outputs. Ideally, we=E2=80=99d solve this by fixing bmake to behave more like a = modern build tool and: - Giving each sub-process its own pipe. - Emitting the full compile command for all failed tasks. - Displaying only a summary for successful commands Or we could find someone with the time to spend giving FreeBSD a modern = build system, which would probably save us 1-2 man years of developer = time each year overall. David From owner-freebsd-current@freebsd.org Tue May 16 10:43: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 0B8C8D6F4C2 for ; Tue, 16 May 2017 10:43:47 +0000 (UTC) (envelope-from bugzilla-noreply@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 E67C632C for ; Tue, 16 May 2017 10:43:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id E5C85D6F4C1; Tue, 16 May 2017 10:43: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 E3B49D6F4C0 for ; Tue, 16 May 2017 10:43:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 CDD4F32B for ; Tue, 16 May 2017 10:43:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4GAhkr2043292 for ; Tue, 16 May 2017 10:43:46 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: current@FreeBSD.org Subject: [Bug 218849] Remove rc.conf jail configuration via jail_* variables Date: Tue, 16 May 2017 10:43:47 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: conf X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: 000.fbsd@quip.cz X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: mfc-stable9- mfc-stable10- mfc-stable11- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 16 May 2017 11:11:23 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 10:43:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218849 --- Comment #28 from Miroslav Lachman <000.fbsd@quip.cz> --- (In reply to Jonathan Anderson from comment #27) I think the opposite way. Or we end up with the same problems as with ezjai= l, portupgrade, portmaster etc. now. Some features in base are stalled or very complicated just to not break 3rd party tools with no active maintainer. "because they are in Handbook" It would be better to document jails with base tools and just some list of = 3rd party tools with brief info about them and link to homepage of those projec= ts. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-current@freebsd.org Tue May 16 12:18: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 649AED70B95 for ; Tue, 16 May 2017 12:18:44 +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 BF522D3E for ; Tue, 16 May 2017 12:18:43 +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 0LomJ1-1dcnRN1GUV-00gouc; Tue, 16 May 2017 14:18:38 +0200 Date: Tue, 16 May 2017 14:18:36 +0200 From: "O. Hartmann" To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= Cc: Subject: Re: buildworld not working with MAKEOBJDIRPREFIX Message-ID: <20170516141836.6974fdf5@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <20170516083911.agudcf7m62xiyhui@dhcp-3-128.uk.xensource.com> References: <20170516083911.agudcf7m62xiyhui@dhcp-3-128.uk.xensource.com> Organization: Walstatt X-Mailer: Claws Mail 3.15.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:uLPdpbXmv29UYtnYfyl9/qbgfFE5XmeLENw487gPOXPeAbQ7gAb 6xC2XqO9qG2gjJyKa1SUwXzYjxLpfXJe1WchifRS2TyGhWEjwcxP1dgFe/CRIj/Xe59IgRb pgkuhQrVL2QmVR0JN+X/muGSAuF0AsDE506OgDD31elye+Qph3efoWpW8y1foHvfhK/E/Y/ oi4iHIra038CQ0RQ60Alw== X-UI-Out-Filterresults: notjunk:1;V01:K0:vOGcVATuuD8=:dwsp9Ms/i6eNHeyZS8KMFo klTOtLqRf6EY68eZTdlnxJu5lE0KyhK5aEUhvet1AnqWVauXsYefWlgpjJbJ0Ad6ApxybLnMV BubQ8HfEKMH2gSkt2sR356dzZP2axIIblIVlDaweB+mBoypF3Lbl80vzVMS9vJ958Ue5pxcMx wlZMfcgjpoEQ1qOyiLRQ7g+8a2d7eaW2CLZPWoJOHUwvVnif0XtEUXI0fRw0gzrxk/mLg+0jH 7dGiD4ox6+LrF3H+sGNbydyqG+psXNosUHVHRFjAXJqUuEBwbutmR3JVlj7lpdDjIHIF+1Fk9 GuV5iWEZjGcM88glnB0feLQusrDVZpxJI8Svxh9A0eUxbje1Rh9DJehrayF7DCXl20naO0OlG +fyju4hf+piouI3w50d+fkqC6+05r2eQKuJwcdXqWCEKN0LmJnkynU33Qpy2IEraf61RjrzCm Go4CxOrMvPzZBb08bTkGtv8CqBPIDDbjEy+xMDAjj5oRWl4frksK1XhKmGt1u8TTfaTWNLT8g ND3PkFwrOADb8beqV3W01YGKjA/KiOmEUCtxfruslGNUEh9s4O+kon6AWHyCxen1PMA460BhU AdRFquhntaV4gltZXS1hpNyZnZL3d8EPIJBSObc9HN43HEp8vjc20fk7SY74iIlZjPO0fuGZc n5r8/Yj/y3Fwmu15l4QEPriaktjhoyVcOCK8EUBweySa0p4geCQKSEteIdnTjw5o2hhNnO078 Lc73v5mA55HONy/DicDS50pblZbjDFNuzuLRkphqY/XDo2RF6bXeeqLkTKVqwIm6V//u9FbW7 7yZ3xm1 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, 16 May 2017 12:18:44 -0000 On Tue, 16 May 2017 09:39:11 +0100 Roger Pau Monn=C3=A9 wrote: > Hello, >=20 > I'm trying to build world as a regular user, using sources fetched into my > home directory and a different object directory. The rune I'm using to bu= ild > is: >=20 > $ cd /home/royger/buildjob/freebsd > $ make -j30 buildworld MAKEOBJDIRPREFIX=3D/home/royger/buildjob/obj/ As far as I know, in this construct, MAKEOBJDIRPREFIX is an argument to mak= e, but MAKEOBJDIRPREFIX is strictly required to be set in the environment! Have you tried the following setting: env MAKEOBJDIRPREFIX=3D/home/royger/buildjob/obj/ make -j30 buildworld I do this kind of task as root this way (as it doesn't work as you showed, either). Kind regards, Oliver >=20 > And this leads to the following build error: >=20 > --- all_subdir_rescue --- > --- cat.lo --- > cc -target x86_64-unknown-freebsd12.0 > --sysroot=3D/home/royger/buildjob/obj//usr/home/royger/buildjob/freebsd/t= mp > -B/home/royger/buildjob/obj//usr/home/royger/buildjob/freebsd/tmp/usr/bin= -O2 > -pipe -std=3Dgnu99 -Qunused-arguments -nostdlib -Wl,-dc -r -o cat.= lo > cat_stub.o /home/royger/buildjob/obj//usr/home/royger/buildjob/freebsd/re= scue/rescue//usr/home/royger/buildjob/freebsd/bin/cat/cat.o > cc: error: no such file or directory: > '/home/royger/buildjob/obj//usr/home/royger/buildjob/freebsd/rescue/rescu= e//usr/home/royger/buildjob/freebsd/bin/cat/cat.o' > *** [cat.lo] Error code 1 >=20 > AFAIK this should work fine, does anyone has any clues about what causes = this > failure? >=20 > Thanks, Roger. >=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 Tue May 16 13:21: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 DA470D6CA88 for ; Tue, 16 May 2017 13:21:05 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 A1682C32 for ; Tue, 16 May 2017 13:21:05 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [2.247.251.225] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1dAcPI-0005Fa-4M for freebsd-current@freebsd.org; Tue, 16 May 2017 15:20:56 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id v4GDKmZf035328 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 16 May 2017 15:20:48 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id v4GDKmgP035324 for freebsd-current@freebsd.org; Tue, 16 May 2017 15:20:48 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Tue, 16 May 2017 15:20:48 +0200 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: Re: buildworld not working with MAKEOBJDIRPREFIX Message-ID: <20170516132048.GA34249@c720-r314251> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , freebsd-current@freebsd.org References: <20170516083911.agudcf7m62xiyhui@dhcp-3-128.uk.xensource.com> <20170516141836.6974fdf5@freyja.zeit4.iv.bundesimmobilien.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170516141836.6974fdf5@freyja.zeit4.iv.bundesimmobilien.de> X-Operating-System: FreeBSD 12.0-CURRENT r314251 (amd64) User-Agent: Mutt/1.8.0 (2017-02-23) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 2.247.251.225 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, 16 May 2017 13:21:05 -0000 El día Tuesday, May 16, 2017 a las 02:18:36PM +0200, O. Hartmann escribió: > On Tue, 16 May 2017 09:39:11 +0100 > Roger Pau Monné wrote: > > > Hello, > > > > I'm trying to build world as a regular user, using sources fetched into my > > home directory and a different object directory. The rune I'm using to build > > is: > > > > $ cd /home/royger/buildjob/freebsd > > $ make -j30 buildworld MAKEOBJDIRPREFIX=/home/royger/buildjob/obj/ > > As far as I know, in this construct, MAKEOBJDIRPREFIX is an argument to make, > but MAKEOBJDIRPREFIX is strictly required to be set in the environment! I used it many times that way, as well # make installworld DESTDIR=/mnt This should work. Can you try with a smaller -j value? matthias -- Matthias Apitz, ✉ guru@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/ccid--export-key-guru.pub 8. Mai 1945: Wer nicht feiert hat den Krieg verloren. 8 de mayo de 1945: Quien no festeja perdió la Guerra. May 8, 1945: Who does not celebrate lost the War. From owner-freebsd-current@freebsd.org Tue May 16 13:49:22 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 284FFD6E3A6; Tue, 16 May 2017 13:49:22 +0000 (UTC) (envelope-from srs0=fzxa=4w=sigsegv.be=kristof@codepro.be) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E790019FC; Tue, 16 May 2017 13:49:21 +0000 (UTC) (envelope-from srs0=fzxa=4w=sigsegv.be=kristof@codepro.be) Received: from [172.16.32.137] (unknown [103.210.33.250]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id 77B0F9B97; Tue, 16 May 2017 15:49:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigsegv.be; s=mail; t=1494942559; bh=RxHjyppW7+6vB8x0AhdWEGMLnLkVHQvK9G2ERfdkCKA=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=EkrR0fKwJWQhApXo10EwfkPFMknYt5gAPdiNOHMxfDD0FKhiQFfy26u5pvlzBtuG4 Ysv5WPu0UWcUl1HG+1RvByQp9aMNS+u26xrJQX8LsgJfUgkjWXIVwu0TjUHTw0H66U vsYvvG+1vMr/BUs5H2/oi+C/47JVGUx3KXZapZ7Q= From: "Kristof Provost" To: "Andriy Gapon" Cc: "Freebsd current" , freebsd-fs@FreeBSD.org Subject: Re: zfs recv panic Date: Tue, 16 May 2017 19:19:16 +0530 Message-ID: In-Reply-To: <98df7d70-4ecb-34f2-7db2-d11a4b0c854a@FreeBSD.org> References: <18A74EE1-3358-4276-88EA-C13E28D8563A@sigsegv.be> <98df7d70-4ecb-34f2-7db2-d11a4b0c854a@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (2.0BETAr6082) 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, 16 May 2017 13:49:22 -0000 On 16 May 2017, at 15:41, Andriy Gapon wrote: > On 10/05/2017 12:37, Kristof Provost wrote: >> I have a reproducible panic on CURRENT (r318136) doing >> (jupiter) # zfs send -R -v zroot/var@before-kernel-2017-04-26 | nc >> dual 1234 >> (dual) # nc -l 1234 | zfs recv -v -F tank/jupiter/var >> >> For clarity, the receiving machine is CURRENT r318136, the sending >> machine is >> running a somewhat older CURRENT version. >> >> The receiving machine panics a few seconds in: >> >> receiving full stream of zroot/var@before-kernel-2017-04-03 into >> tank/jupiter/var@before-kernel-2017-04-03 >> panic: solaris assert: dbuf_is_metadata(db) == arc_is_metadata(buf) >> (0x0 == >> 0x1), file: >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c, >> line: 2007 > > could you please try to revert commits related to the compressed send > and see if > that helps? I assume that the sending machine does not have (does not > use) the > feature while the target machine is capable of the feature. > > The commits are: r317648 and r317414. Mot that I really suspect that > change, > but just to eliminate the possibility. Those commits appear to be the trigger. I’ve not changed the sender, but with those reverted I don’t see the panic any more. Regards, Kristof From owner-freebsd-current@freebsd.org Tue May 16 14:29: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 9E089D6EEB6; Tue, 16 May 2017 14:29:59 +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 B982D106D; Tue, 16 May 2017 14:29:58 +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 RAA05221; Tue, 16 May 2017 17:29:56 +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 1dAdU4-0005UF-4V; Tue, 16 May 2017 17:29:56 +0300 Subject: Re: zfs recv panic To: Kristof Provost Cc: Freebsd current , freebsd-fs@FreeBSD.org References: <18A74EE1-3358-4276-88EA-C13E28D8563A@sigsegv.be> <98df7d70-4ecb-34f2-7db2-d11a4b0c854a@FreeBSD.org> From: Andriy Gapon Message-ID: <51bbf691-a8e2-2d16-6a95-c37a474c1dfe@FreeBSD.org> Date: Tue, 16 May 2017 17:28:35 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US 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, 16 May 2017 14:29:59 -0000 On 16/05/2017 16:49, Kristof Provost wrote: > On 16 May 2017, at 15:41, Andriy Gapon wrote: >> On 10/05/2017 12:37, Kristof Provost wrote: >>> I have a reproducible panic on CURRENT (r318136) doing >>> (jupiter) # zfs send -R -v zroot/var@before-kernel-2017-04-26 | nc dual 1234 >>> (dual) # nc -l 1234 | zfs recv -v -F tank/jupiter/var >>> >>> For clarity, the receiving machine is CURRENT r318136, the sending machine is >>> running a somewhat older CURRENT version. >>> >>> The receiving machine panics a few seconds in: >>> >>> receiving full stream of zroot/var@before-kernel-2017-04-03 into >>> tank/jupiter/var@before-kernel-2017-04-03 >>> panic: solaris assert: dbuf_is_metadata(db) == arc_is_metadata(buf) (0x0 == >>> 0x1), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c, >>> line: 2007 >> >> could you please try to revert commits related to the compressed send and see if >> that helps? I assume that the sending machine does not have (does not use) the >> feature while the target machine is capable of the feature. >> >> The commits are: r317648 and r317414. Mot that I really suspect that change, >> but just to eliminate the possibility. > > Those commits appear to be the trigger. > I’ve not changed the sender, but with those reverted I don’t see the panic any > more. Thank you for testing. Do you still have the old kernel / module and the crash dump? It would interesting to poke around in frame 14. -- Andriy Gapon From owner-freebsd-current@freebsd.org Tue May 16 15:23:07 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 A304BD70468 for ; Tue, 16 May 2017 15:23:07 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 8E66C14A9 for ; Tue, 16 May 2017 15:23:07 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: by mailman.ysv.freebsd.org (Postfix) id 8AF2FD70467; Tue, 16 May 2017 15:23:07 +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 88E1DD70466 for ; Tue, 16 May 2017 15:23:07 +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 471A114A8; Tue, 16 May 2017 15:23:06 +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 1dAeJN-0006fo-PE; Tue, 16 May 2017 17:22:57 +0200 Received: from mail by rmmprod05.runbox with local (Exim 4.86_2) (envelope-from ) id 1dAeJN-0001Zr-Kj; Tue, 16 May 2017 17:22:57 +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); Tue, 16 May 2017 15:22:57 GMT From: "Jeffrey Bouquet" Reply-To: To: "bugzilla-noreply" CC: "current" Subject: Re: [Bug 218849] Remove rc.conf jail configuration via jail_* variables Date: Tue, 16 May 2017 08:22:57 -0700 (PDT) X-Mailer: RMM6 In-Reply-To: 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: Tue, 16 May 2017 15:23:07 -0000 Just commenting on past ideas of mine. *spend no time replying* . Thanks! ... inline comments below... sort of like 'overhear my typing into my bsd wish list nano-file.' and as such, scribble a not to thyself, not the list= nor I, as I am out of time this [year] and # commenting not # coding an email ... .... On Tue, 16 May 2017 10:43:47 +0000, bugzilla-noreply@freebsd.org wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218849 >=20 > --- Comment #28 from Miroslav Lachman <000.fbsd@quip.cz> --- > (In reply to Jonathan Anderson from comment #27) > I think the opposite way. Or we end up with the same problems as with ezj= ail, > portupgrade, portmaster etc. now.=20 I applaud each of those tools, as well as the extinct portmanager, and wis= h they be fully pkg compliant and/or the fallback for a resurrected /var/db/pkg plain= -text version of .sqlite (s) for those urgent times [ once yearly for instance ] here whe= re a newbie failure by inexperience and/or unresolved bug eclipses my day with a few ho= urs of backup-worked-but-not-as-smoothly-as-I-thought successes... Some features in base are stalled or very > complicated just to not break 3rd party tools with no active maintainer. > "because they are in Handbook" I welcome a fully salaried handbook full time 'synchronizer', too advanced= in years on my part, but yes I could pay yearly a share. > It would be better to document jails with base tools and just some list o= f 3rd > party tools with brief info about them and link to homepage of those proj= ects. ............................. off topic, snuck in: Some .htm,.php,.aspx, I save in .htm .txt manner a .htm[ or... ] for rea= d-later, many of which .htm[etc] I save, vs xclip > disk , appear once loaded on disk as a jumble of text within interspersed /tags/ and /css/ stu= ff making it transcrible yes, but readable, no, so I give up and re-google the page I sa= ved. If anyone has any best practice to educate me on a better save-to-disk-htm[php][aspx]= method that is foolproof. comparatively,=20 to reload from disk later [ for presentations, etc...] I may, if can, also= paypal/snail mail a 'finders fee', if, say after a few months of usage I could frame it on the wall, actually, so I do= not continue as I presently do, and feel of more use to others in pulling up saved files vs= [ oh, I thought I could read that, it is 2/3 mime-glyphs... ] 'stuff that happens' to me an= d my sometimes guests.=20=20=20=20 cc: the handbook guy, above, but that is in the distant future... so to sp= eak. Or, add filler to an email. Sorry, or, continue as/until I de-procrastinate and 's= end' to my=20 understanding fellow list-readers [ tl/dr : see header, unfortunately top= posted... we are looking over the shoulder at my nano file, that 'just this once, I p= romise' is publicly posted to the list so others can treat it as the off-topic it purp= orts to be,=20 comprises, asserts, mitigates itself as, and ... ]=20=20 Have a very pleasant day, and I do not mean that with any insincerity.=20=20 Thanks!=20 ......................... >=20 > --=20 > You are receiving this mail because: > You are on the CC list for the bug. > _______________________________________________ > 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 May 16 16:32: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 CFBD2D70CAA for ; Tue, 16 May 2017 16:32:35 +0000 (UTC) (envelope-from prvs=302023821=roger.pau@citrix.com) Received: from SMTP.EU.CITRIX.COM (smtp.eu.citrix.com [185.25.65.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "DigiCert SHA2 Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9FE60D5D for ; Tue, 16 May 2017 16:32:34 +0000 (UTC) (envelope-from prvs=302023821=roger.pau@citrix.com) X-IronPort-AV: E=Sophos;i="5.38,349,1491264000"; d="scan'208";a="46155266" Date: Tue, 16 May 2017 17:18:25 +0100 From: Roger Pau =?iso-8859-1?Q?Monn=E9?= To: "O. Hartmann" CC: Subject: Re: buildworld not working with MAKEOBJDIRPREFIX Message-ID: <20170516161825.xk456vqqmllyenj4@dhcp-3-128.uk.xensource.com> References: <20170516083911.agudcf7m62xiyhui@dhcp-3-128.uk.xensource.com> <20170516141836.6974fdf5@freyja.zeit4.iv.bundesimmobilien.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170516141836.6974fdf5@freyja.zeit4.iv.bundesimmobilien.de> User-Agent: NeoMutt/20170428 (1.8.2) X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) 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, 16 May 2017 16:32:35 -0000 On Tue, May 16, 2017 at 02:18:36PM +0200, O. Hartmann wrote: > On Tue, 16 May 2017 09:39:11 +0100 > Roger Pau Monné wrote: > > > Hello, > > > > I'm trying to build world as a regular user, using sources fetched into my > > home directory and a different object directory. The rune I'm using to build > > is: > > > > $ cd /home/royger/buildjob/freebsd > > $ make -j30 buildworld MAKEOBJDIRPREFIX=/home/royger/buildjob/obj/ > > As far as I know, in this construct, MAKEOBJDIRPREFIX is an argument to make, > but MAKEOBJDIRPREFIX is strictly required to be set in the environment! > > Have you tried the following setting: > > env MAKEOBJDIRPREFIX=/home/royger/buildjob/obj/ make -j30 buildworld > > I do this kind of task as root this way (as it doesn't work as you showed, > either). Hello, Yes, that's right, MAKEOBJDIRPREFIX is strictly required to be set in the environment, setting it fixes the issue. It always confuses me how some of those (like DESTDIR) can be passed as an arguments while others don't. Thanks, Roger. From owner-freebsd-current@freebsd.org Tue May 16 18:53:30 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 299FED70F06; Tue, 16 May 2017 18:53:30 +0000 (UTC) (envelope-from srs0=fzxa=4w=sigsegv.be=kristof@codepro.be) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DD6A8E39; Tue, 16 May 2017 18:53:29 +0000 (UTC) (envelope-from srs0=fzxa=4w=sigsegv.be=kristof@codepro.be) Received: from [172.16.32.137] (unknown [103.210.33.250]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id C68059033; Tue, 16 May 2017 20:53:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigsegv.be; s=mail; t=1494960807; bh=r5MlwkYi2hUMbdIHRH6Bn+5pm2QMc6BxZZ8lhLDGe8M=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=2vGoSeqc6IyFSqD4jU15sIi+gwDwpnTeBuCpOjW31soQpZUCd4E9YXbluGk6Id3bZ vk5FVdQAexje7if2PcSyw+3+XZZF10fDvWmrxEZPh9JfKmpf3HodGmmXuGFfM6hZsg mkiDC2g/x6vcVZSgr7ZUpPEIYSBDCJt5JdeHaSzg= From: "Kristof Provost" To: "Andriy Gapon" Cc: "Freebsd current" , freebsd-fs@FreeBSD.org Subject: Re: zfs recv panic Date: Wed, 17 May 2017 00:23:24 +0530 Message-ID: <96BF657D-34A8-4044-BC73-E0BCD1E98E52@sigsegv.be> In-Reply-To: <51bbf691-a8e2-2d16-6a95-c37a474c1dfe@FreeBSD.org> References: <18A74EE1-3358-4276-88EA-C13E28D8563A@sigsegv.be> <98df7d70-4ecb-34f2-7db2-d11a4b0c854a@FreeBSD.org> <51bbf691-a8e2-2d16-6a95-c37a474c1dfe@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-Mailer: MailMate (2.0BETAr6082) 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, 16 May 2017 18:53:30 -0000 On 16 May 2017, at 19:58, Andriy Gapon wrote: > On 16/05/2017 16:49, Kristof Provost wrote: >> On 16 May 2017, at 15:41, Andriy Gapon wrote: >>> On 10/05/2017 12:37, Kristof Provost wrote: >>>> I have a reproducible panic on CURRENT (r318136) doing >>>> (jupiter) # zfs send -R -v zroot/var@before-kernel-2017-04-26 | nc >>>> dual 1234 >>>> (dual) # nc -l 1234 | zfs recv -v -F tank/jupiter/var >>>> >>>> For clarity, the receiving machine is CURRENT r318136, the sending >>>> machine is >>>> running a somewhat older CURRENT version. >>>> >>>> The receiving machine panics a few seconds in: >>>> >>>> receiving full stream of zroot/var@before-kernel-2017-04-03 into >>>> tank/jupiter/var@before-kernel-2017-04-03 >>>> panic: solaris assert: dbuf_is_metadata(db) == arc_is_metadata(buf) >>>> (0x0 == >>>> 0x1), file: >>>> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c, >>>> line: 2007 >>> >>> could you please try to revert commits related to the compressed >>> send and see if >>> that helps? I assume that the sending machine does not have (does >>> not use) the >>> feature while the target machine is capable of the feature. >>> >>> The commits are: r317648 and r317414. Mot that I really suspect >>> that change, >>> but just to eliminate the possibility. >> >> Those commits appear to be the trigger. >> I’ve not changed the sender, but with those reverted I don’t see >> the panic any >> more. > > Thank you for testing. > Do you still have the old kernel / module and the crash dump? > It would interesting to poke around in frame 14. > > This contains the kernel and crash files: https://www.sigsegv.be/files/zfs_recv_kernel_crash.tar.bz2 I was running r318356 at the time of this panic. Regards, Kristof From owner-freebsd-current@freebsd.org Tue May 16 19:52: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 EFB24D7093D for ; Tue, 16 May 2017 19:52:26 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::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 A88BC145 for ; Tue, 16 May 2017 19:52:26 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk0-x22c.google.com with SMTP id u75so139099884qka.3 for ; Tue, 16 May 2017 12:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Dxjmrl1iIxeRQLT3VsuzUu2w0o/0uJcGgAbnJgu+U+E=; b=mqS0zPAOSvxM3UUZzoR0QsCYmd6x1gjK6eT0AzffEz+zBrcDUyFHwXxXbhn5TVYQQc LDC3c/TMgnUrzcoTpXTdd7JgwKvGZ51iMXVE/fwKSGk98uX+S7+QI0RbL7kiADd+KOoJ A7hTPL48wc9YxpOJ64QwsgreiBUUMiYhl39qCGGFMjVclQrvOTbBrXs65ovuvJQM4j8D HNs1U5mslq995GjMOyrqTxTMANSo0i0cPVTg7DotsyYMcY9ph5SQ5fOMxJ8Tv1LESROa 3957fyD0wNsCnqPkppb0EISbSt1yCctIAL6mIGYYm/Gn2yaN+loOxTOkDAMHMUHhR+c5 ocLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=Dxjmrl1iIxeRQLT3VsuzUu2w0o/0uJcGgAbnJgu+U+E=; b=elAlKExIzJzcBMTZWiIcLjfJCvSamFTzsymazqp+lokVpNOGl3SI8AzGbdZzz/zPgh 88G58c4VeWvVtrhON7tmJoVhuove9PtbAYmHMVu/Km5Zg3y9OV4RlLu17ntTzbfQCL/x lK6XYsUxWZS+DdEl94EYhGPlaAL0XcKpIChz2mJFOswSkLWYQuFQd+sg6TtrxFy4gKX7 KuzRdRnZYv23d13/liCDqlR9882eEc9/xQJBaFtgGHR1wAyFWoNDfAPLHsg3Xc6uK6QK BYpBkROiXsBkO8VBL/bolbmoFvrNpMpcU8zM83oZBjq2jM58cX9NFHUdzpf1qxtAmp0q cR3w== X-Gm-Message-State: AODbwcDUAp+hguK5fG7Ns5L0/WN1iBD6L1wDq4KSEm4SHuPeo1Hwsqyl ieXYoX0PsP3v9l/J X-Received: by 10.55.163.20 with SMTP id m20mr13194735qke.265.1494964345728; Tue, 16 May 2017 12:52:25 -0700 (PDT) Received: from wkstn-mjohnston.west.isilon.com (c-76-104-201-218.hsd1.wa.comcast.net. [76.104.201.218]) by smtp.gmail.com with ESMTPSA id b23sm184990qkb.31.2017.05.16.12.52.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 May 2017 12:52:25 -0700 (PDT) Sender: Mark Johnston Date: Tue, 16 May 2017 12:52:20 -0700 From: Mark Johnston To: "O. Hartmann" Cc: freebsd-current Subject: Re: IFLIB: em0/igb0 broken: No buffer space available/TX(0) desc avail = 1024, pidx = 0 Message-ID: <20170516195220.GA38599@wkstn-mjohnston.west.isilon.com> References: <20170516065623.6e2de036@freyja.zeit4.iv.bundesimmobilien.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170516065623.6e2de036@freyja.zeit4.iv.bundesimmobilien.de> User-Agent: Mutt/1.8.2 (2017-04-18) 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, 16 May 2017 19:52:27 -0000 On Tue, May 16, 2017 at 06:56:23AM +0200, O. Hartmann wrote: > Since the introduction of IFLIB, I have big trouble with especially a certain > type of NIC, namely formerly known igb and em. > > The worst device is an Intel NIC known as i217-LM > > em0@pci0:0:25:0: class=0x020000 card=0x11ed1734 chip=0x153a8086 rev=0x05 > hdr=0x00 vendor = 'Intel Corporation' > device = 'Ethernet Connection I217-LM' > class = network > subclass = ethernet > bar [10] = type Memory, range 32, base 0xfb300000, size 131072, enabled > bar [14] = type Memory, range 32, base 0xfb339000, size 4096, enabled > bar [18] = type I/O Port, range 32, base 0xf020, size 32, enabled > > This NIC is widely used by Fujitsu's workstations CELSIUS M740 and the fate > would have it, that I have to use one of these. > > When syncing data over the network from the workstation to an older C2D/bce > based server via NFSv4, since introduction of IFLIB the connection to the NFS > get stuck and I receive on the console messages like > > em0: TX(0) desc avail = 1024, pidx = 0 > em0: TX(0) desc avail = 42, pidx = 985 > > Hitting "Ctrl-T" on the terminal doing the sync via "rsync", I see then this > message: > > load: 0.01 cmd: rsync 68868 [nfsaio] 395.68r 4.68u 4.64s 0% 3288k (just for > the record) > > Server and client(s) are on 12-CURRENT: ~ FreeBSD 12.0-CURRENT #38 r318285: Mon > May 15 12:27:29 CEST 2017 amd64, customised kernels and "netmap" enabled (just > for the record if that matters). > > In the past, I was able to revive the connection by simply putting the NIC down > and then up again and while I had running a ping as a trace indication of the > state of the NIC, I got very often > > ping: sendto: No buffer space available > > Well, today I checked via dmesg the output to gather again those messages and > realised that the dmesg is garbled: > > [...] > nfs nfs servnnfs servefs r server19 2.19162n.fs snerver fs1 s9nfs s2er.nfs > server er192.168.0.31:/pool/packages: not responding v > er 192.168.0.31ver :/po1ol/packages9: 2.168.0.31:/pool/packagesn: noot > responding t > <6>n fs serverespondinngf > s > server 192.168.1rn nfs server 192.168.0.31:/pool/packages: not1 responding > 9 > 2.168.1f7s 0.31:/pool/packagenfs sesrver 19serv2er .168.0.31:/poo: not > respolnding / > packages: not responding > nfs server 19192.168.0.31:/pool/pa2c.k168.0.31:a/gpserver > ne1s92.168.0.31:/pool/pac: knot respaof1s68 gs.e17rve8r.2 > 3192.168.0.31:/pool/packa1:/pool/packages: not responding o goes: nl/packages: > not responding o > t responding > nfs server 192.168.0.31:/poes: ol/packages: nfns server > 192.168.0.31:/pool/paot responding c > kages: not respondinnfs server n192.1f68.0.31:/pool/packagess: ndi server > 192.168.0.31:/pool/packages: not responding > [...] > > Earlier this year after introduction of IFLIB, I checked out servers equipted > with Intels very popular i350T2v2 NIC and I had similar problems when dd'ing > large files over NFSv4 (ZFS backed) from a client (em0, a client/consumer grade > older NIC from 2010, forgot its ID, towards server with i350, but the server > side got stuck with the messages seen similar to those reported with the > i217-LM). Since my department uses lots of those server grade NICs, I will swap > the i217 with a i350T2 and check again. > > Nevertheless, the situation is very uncomfortable! I'm able to reproduce this (watchdog timeouts followed by a link bounce, garbled dmesg) on my workstation by dd'ing to a file on an NFSv3 mount of a local file server. This is with: em0@pci0:0:25:0: class=0x020000 card=0x102717aa chip=0x15028086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '82579LM Gigabit Network Connection' class = network subclass = ethernet From owner-freebsd-current@freebsd.org Tue May 16 23:01: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 3BF82D6ED67 for ; Tue, 16 May 2017 23:01:56 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0119.outbound.protection.outlook.com [104.47.34.119]) (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 D0EE210CB for ; Tue, 16 May 2017 23:01:55 +0000 (UTC) (envelope-from sjg@juniper.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=X7HjIMAB+4Lf1ct7JJ91doDWa6eQaiMMSolU9vRZbOk=; b=bJE6izk+YOzQMn5gj3Dfmk3kj+wB8uenH/oRDuLTlGaG5HjJaTThceydDMfQ/h3fjwBOUJSoCb/cReCHXZjIvmM4MEaKG3aLJKZDKlzcv3np2fnzZYHPcgLJ/TIX3GAH+qrO54fmrNl9rw0ZoIyrZ9AAEo04P8HWE/UvQjFlaJ0= Received: from CO2PR05CA0083.namprd05.prod.outlook.com (10.166.88.179) by CY1PR0501MB1308.namprd05.prod.outlook.com (10.160.226.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.8; Tue, 16 May 2017 23:01:54 +0000 Received: from CO1NAM05FT016.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e50::201) by CO2PR05CA0083.outlook.office365.com (2603:10b6:102:2::51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.8 via Frontend Transport; Tue, 16 May 2017 23:01:54 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; citrix.com; dkim=none (message not signed) header.d=none;citrix.com; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by CO1NAM05FT016.mail.protection.outlook.com (10.152.96.123) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1075.12 via Frontend Transport; Tue, 16 May 2017 23:01:53 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 16 May 2017 16:01:41 -0700 Received: from kaos.jnpr.net (kaos.jnpr.net [172.21.30.60]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v4GN1eVo011250; Tue, 16 May 2017 16:01:41 -0700 (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id AAEF838551F; Tue, 16 May 2017 16:01:40 -0700 (PDT) To: Roger Pau =?us-ascii?Q?=3D=3Fiso-8859-1=3FQ=3FMonn=3DE9=3F=3D?= CC: , Subject: Re: buildworld not working with MAKEOBJDIRPREFIX In-Reply-To: <20170516083911.agudcf7m62xiyhui@dhcp-3-128.uk.xensource.com> References: <20170516083911.agudcf7m62xiyhui@dhcp-3-128.uk.xensource.com> Comments: In-reply-to: Roger Pau =?us-ascii?Q?=3D=3Fiso-8859-1=3FQ=3FMonn?= =?us-ascii?Q?=3DE9=3F=3D?= message dated "Tue, 16 May 2017 09:39:11 +0100." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 May 2017 16:01:40 -0700 Message-ID: <55605.1494975700@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39400400002)(39850400002)(39410400002)(39860400002)(39450400003)(2980300002)(199003)(24454002)(189002)(9170700003)(77096006)(6246003)(7696004)(86362001)(76176999)(2810700001)(47776003)(478600001)(2950100002)(50986999)(106466001)(105596002)(38730400002)(2906002)(107886003)(110136004)(6916009)(6266002)(55016002)(117636001)(53416004)(76506005)(356003)(50466002)(9686003)(305945005)(189998001)(53936002)(7126002)(54906002)(4326008)(23676002)(50226002)(8666007)(229853002)(81166006)(8936002)(8746002)(8676002)(5660300001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1308; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM05FT016; 1:+0U0hFqQShhjVjd+31QKeUzNH7cDxlsUeGHCussWhztzXVZ4feOsvljBW4JQWnmnHrKYOkR/E3iZWR3XMQpao/bziuorMqUCRZlHjpZJRUpviW7t7Axvc9pKsY5gBjR0dSGBvuLTewBYb0XUTICIuE2KCvRTH6LU8suqXm8yoU8leW+cJ7Bjn9tCAMoF2RUqS3GnC7z0xnniKN+BhukwWLbyArFV2e0SBxYeh5cvoyEQ5QSARq/W1c3torcZFhZEnlXVASeXKw7g6nWF50fdiUtjUNQSk0BTNLf8CYIV5sUTAsmDabfk7YdndORbE02SxR/W9L3naqS0gO0x3Zai6RXh1fWn1wypzoNFz33CWCO6x6Vo7ftH2LCDHcUEwv+YNY4duHwuS0BpwoAz3o7fHPvXb4+q8qUoXSD1sF6vhevFGOIkKzbIepjC1Eg+4acVHUnNKwdPN6mhdhnFgYLgXxBJMZYXDPQoD5S0GsTUjKKAdX4AP4f3vEZEmHxh4xPMW8tU8Z/K8Gf3rsMzfa05CFQx8py3p9zYVIkibw3Go0h8WrGHWSNeW0ET2ddXpS3T X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY1PR0501MB1308: X-MS-Office365-Filtering-Correlation-Id: 67a01158-90b1-4fd9-617b-08d49caf8b87 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:CY1PR0501MB1308; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1308; 3:Aeykvb7IkG4/rr5Uzn064zQa3sB8qPJrXoVLYch74pfsSlUfZzfT/cUn+9y7a6XH7HG4H/PiVEE2it4+8PHg8Flg65SLb6PplX6svWtRNijwI1vQJWUyJGrcIwYn/RE/1RUwuBhvDkUmSxVZlDbHU9gTHcDxR7FEBuNm+CHiS6fPCoc9vrdp/RESxglcDesijm7uAz9gt8YQtSR+Od7Ojykxy1fPXjYAk+rSHt8am2ofTYORU9a+3DcpuRhMmw+oP9Oqn/RkA1172QQPcnCbXBBsYIb/m4DHqq6bJrFOVIN+Htk8ZX/yKR90V3IQpRIQUdW/N+oqbS/KDxEfiLntQcg47amgtEXpuxsUEdS9GeU26Gel+rzivc19lQEVMidskSpSeR3ehy5AqIqKudVuYTPvRtr/c7PWgnQgAf3+y2EIVYOIqiewiY3O2FqQ1xFbt31T5EQPZs1E5WykEXkKMA== X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1308; 25:KPfRMrf09KG+VOcshmVTm66lyTOyX4iTuFhg36AUZ2WeVmibuscD8EPLj76tlZ7iRZbA3DeTWgAaAMhx2AO4pQktTjgsemG7+vLXR0I0l4Aj3YDN+oJ0a1n1KbGmJ0tQ/EXpGD70OEDwnIebTy8OLwqEK1sh9fWR/MxkCZLxIOnkKgTe7mK33OcXkYdK73cPy37WtjX1I5bP6I4dcGasL8PMC05lsi4QCxTIlhf7jGmnwRpwu74DarVYZINwOhaDl2XiYWIwHJrybIK/KBymPXXmYmF/Yf7sgVZ+EAdup0CIzk1iTABbrmW2AS3NmB7U9YiqseXUjKHDFMIZrr7yw6hWgx97qRY4ACs9zy/LVK2xcqQcyhvzvXzS6br6T6FZYdYQTdxP65hh/b/yGkEyAAs5hxTGtvJ4TL+UogYvc8jjLC3mT3Z1q0taECTNYby6BoIMJpZot7z1ZwpjmwIeb/t5TnsGfKuo8Xf1zhiJrUw=; 31:JFWdt7QBEfmesdEAABKVIeee/6vKHAZGblcPZJXFHjjcxC5b6unjzlve9iP8blpNhUGYeJKzNzm9fw8gK5AIzJ18SzYQBnpgNLBWY1dw7kXOBPxyu79BOZLQitjGjRKzdcQAhinTd7we3REFZD2id3NAhhvwNL33mVHx5OeQx86czGj7kKSWKwRR9V1jcHSuDUbnksKcGRQq/MomK8UTwQwAEchBFV7NPfP8BfTH/MOyF3qqmGf6EJfo+9DaF7gG X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1308; 20:P3RrKf4Up4OgVo1rbx38SGl6l7y0oMkm+ZMK6BhngTz0oqg9LFVy+KygVOwb94xjO0QCI/RBF6c01AZfZXAirL+uR+mO1jG9d+C9VTY/125K4OvzfhYRKzHNClNGnqo9WnXlZgkEPrV8vNZByYAs9Zrlq1qJXjGqB3xgbqP5sY/vJ1omCl4zcdx5xXO0/n5ioxD8PvnY3k8TH1W1O9jOK8ubKXIFB1IJCKHllbGZm4erj6z2eXx5Po+spSJ2H7lvpzixexofYHi6Hwt7k7dPyDsFT1kHW+AZlXZZ3e6rvyGye/g1qXe+YSob3bDAIoYfiBmlPhmUd3d2bq/9QG8BE4yboHQuk0FmZNcWioxqoK3JdvQPIDGcjeu4HIrMHlErwxJxylN1XNegAU1pBUrFqzjga6N4ZaDjRb1KpvU6pMoBbqmAL3O6beDWrJUFIwkLnyswXXV91oClgWQYxcPLo8AQzKD6LsZlpTJqIsGl5ZZ+Ioic0ATKP7xZO1rOxwIg X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(70601490899591); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700036)(100105000095)(100000701036)(100105300095)(100000702036)(100105100095)(6040450)(601004)(2401047)(5005006)(13015025)(13017025)(8121501046)(13018025)(13024025)(13023025)(10201501046)(93006095)(93003095)(100000703036)(100105400095)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(20161123558100)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704036)(100105200095)(100000705036)(100105500095); SRVR:CY1PR0501MB1308; BCL:0; PCL:0; RULEID:(100000800036)(100110000095)(100000801036)(100110300095)(100000802036)(100110100095)(100000803036)(100110400095)(100000804036)(100110200095)(100000805036)(100110500095); SRVR:CY1PR0501MB1308; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjA1MDFNQjEzMDg7NDpZU01rcDRpcC9zUTg5YVJPV3V5K1pnaTZL?= =?utf-8?B?VjFKb0lyQjJqWDFqQ1VMWWpzOG5LUEk4cUFtVkpYbjdJRjhzeFVMNFJUWkFC?= =?utf-8?B?MzVvenBlSlJNMy9RTlZXRGcyRXYyYUlYRlpiZUpONmZMZi9PNnRqcDNDcXlW?= =?utf-8?B?V3pIVERkSVRicE1YWEdyOWdlaXpUUEVBOXhxeXVMNDlQSG9KYW1Hd21JZ3h1?= =?utf-8?B?bjNoUFJuS0I4K1hIQ09qbUQ3aTl1N1prT3dEME1jTytXSExrM2lHU2VWbmFV?= =?utf-8?B?ZWNlaHBVb3RtMEg4UVAwNjhQSmdwSkVsemZhWStqWXg0b3hYZ1NiWFR3OUcr?= =?utf-8?B?ZWREN2FmdjBIdXl0d2l2SmovQ3luUmdzTUtjWE95RHVwT2psaStSQnc0aTlk?= =?utf-8?B?WXhqY1ZIZGdnWWowNko1M1k5WWdiWU1pcHhSZGpYSHlZQzJBTUdXUjgwMXhK?= =?utf-8?B?Z21rZFVhaWd1MjV3RzB4aXlZcityYU10ZjAyZUdXcUcrSmJiMzF5UDBDd2Y0?= =?utf-8?B?WEswdzdmakVReURnLzh2Q0hLNUJMUHJ1dmgvT2Y5ZGhNbmxBOTV0WDhvUXd2?= =?utf-8?B?SHpnc0tUYWVoSzhpM2VUb05XUXg4V2dJNjJ5cGdtVTlVTHA0L1NMQTR3NFpD?= =?utf-8?B?ZlZkSW03bzloOTVkSklaZVE5U2tzOEJZNytJbHhaVnYxYnUrTWI2YklYdVRB?= =?utf-8?B?ZWs3TUtYdENpZzhGN3NDMlIwOGJUUHpJMjRqY3ZmMTJnOWZpWnFjaDFjbzNB?= =?utf-8?B?V2dFTnpzandlcXpSdW8xb1RLdWNFeXkxTGVRVmFDWWpBc1JoclVlVmFzRGhm?= =?utf-8?B?Y2dwZjJHYmdnNVFCSGZRaTFrSWpGczR5SDUrMzFDdkdPMXFRMWgwMkVZd3Jr?= =?utf-8?B?T0lsOVdUb1ZzMlArOElKN21YVkJMM2ZqREZHdWgwZkZrVUJOV1ViRGZBNUpG?= =?utf-8?B?TC9aTnljbmxNZGpxdndOTFcwSTJMMG9aeGk2SlF6cEpxTlpNZUd4NVIvT2Fr?= =?utf-8?B?Z2lXeS9DdTVhQnFsQTYwT1pnUVA0aG5PcGo5SmVTSUttVktxbitmUlY1Q0tm?= =?utf-8?B?dEV4NjRmSCtOUFlHWXpaU0R5SXF5OG1zbVZkeWptZUpYTXpEZFRPVDlWQ0hv?= =?utf-8?B?dkhPeUs2b2pxdnppYTlLY2U5UDc1N2dubnFTalZLakJrMzV6bjM2blBDQjNQ?= =?utf-8?B?eVppZVdwbFdITDlvdnFCbEh4Q0paMjdwZHA5MWNtQzF0Q0NZb1ZNbkNVYnBs?= =?utf-8?B?SWJyc3E0M2N3bFZZTFNnaDZ3VVAxdjZabG9jckNDcDZmenl4UU51U2JDY2xt?= =?utf-8?B?WXhaVVFna2hMWXI2WFJudHcyUHZZcnJZeFBna1pxcUgyVTAzSFVhaDh2R2dz?= =?utf-8?B?Z051bkZ6a2c0UFNSbkxucS9LQjd6VTRKeFdyYXlrUWdFWkozaTFuVUpyNHRJ?= =?utf-8?B?RDdrbktqdFJYZVlLQVp3YTBrcTdibG85TUtQTDBCQjkrb0VTdTJyT0ZxMnQx?= =?utf-8?B?UnpiTlZCOWdpTC9mRldEcXpObkRPeGVTejFRVHZOaEg4eHRVKzZSOGpZYzB4?= =?utf-8?B?UUtsTnBocmRaeWdTNDNOV0R6bm82QjZCRGhtZHNmWlUwYlkrSEt3T0dLa1VR?= =?utf-8?B?RnE0THBPenIzVFRkSnNmby9oUmVpNXF5Y25CWEZHU0RDTHdGd0Q2RzdjVjRK?= =?utf-8?B?cDYvSWlaVGFzTjQyckZDWDU4elk4QUkwTks4MURGTEhYdHVVdytPSllaQmdL?= =?utf-8?B?NUp6VHBqbEhxRnlQMkxucXc9PQ==?= X-Forefront-PRVS: 03094A4065 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjA1MDFNQjEzMDg7MjM6U0laeGc2d0xiK24rNXdaVWU5MzdrYi8z?= =?utf-8?B?elE0M3dIVXpYS1drMmtVaEZRYWM2YXJxWHlXTzJVZHNhb2lNWHFKNXhxTzBq?= =?utf-8?B?QmRMeGlHeVg5cDRpVmJxU01ZZWY3R3A1YklIVTVSL3NkYjJOUE5Pc1NZSHVi?= =?utf-8?B?VVVoUFphbFpIbmZOTGdnbCt1VXFsVENYbXhaNUM0NkRaNWVWSDBZTEZQNllJ?= =?utf-8?B?ZlowYXY2dEw5eU5GVGpLaVA2TUk0VGtTSWIvdGN5M3pEOUsxZHRHZ3ZwaU45?= =?utf-8?B?TXdsclZWYnhkSW50N3oyeXlPUkpTUW10aFV0cWlQMVVTQm01bHlrdnMwYUpn?= =?utf-8?B?dXpDeXc2YnN3TCtnRHdlWEZoVXpIM3k4blRhaUdaUG9wNkEvSTRVeTBuenpH?= =?utf-8?B?R0Q5MzRLREZqNit5b0lyV2RCaGJmekFocVM0S0d5UGJ6M1MwN0YybTVtUVRy?= =?utf-8?B?KzdTbVV3UkhVQURWaDBZKzVJSnNYcURaU0NZTVk4QnBaMHhNRXV0UDlFREsy?= =?utf-8?B?SlY0K3h6K3cwcHdQK2hsVVo0QXYyWit2QVFlUDRHbk1MTGRoUU5McTJDOUdz?= =?utf-8?B?T1lHQmpndVBUWVpocHFObFZNdjFQaXlsZ1JJcEJhYnJxS1dhL1lsTW80VWZR?= =?utf-8?B?SVZzOXZSMWhPN2dzdlRMRyswWjJYZ3NDYXgrbkRwdVpCWlRYbWVSSUp1cTUr?= =?utf-8?B?SktqbTNoU1dPMW5TZ0dNT3RtczZ6VUZWSDFXTE5raDY1MTNiaXNQcUFxaXRs?= =?utf-8?B?L2VwMkVtRlhzcW55Q08xUWJPdm9pV3BlUWdabXk2Z3R2ejhMTnE4WmllK1Bi?= =?utf-8?B?aVVlQ05LdTFaT0xpWnRSVG9zWjJRZ0J5TXlKVjRIajNIK0xKdVJ3Vk1pb05q?= =?utf-8?B?T3BLUjVpWkdhTlVTS0tOVEswUEdRQnJza28vUThGd0I5REJMNGNrS1I0eDlN?= =?utf-8?B?K0pFQVFoUzhvQ21jYzMvODVIalNMQ2hzeHVnOE5kUlNyM2tTWGtkZ3FMekhK?= =?utf-8?B?dVc4Qm5xSnRXcXZMaDIyeDNjQ2Y1Wi8rVis2cDVMR2g1V1Rzc2Q5UHlPbEhk?= =?utf-8?B?dG15cTE1V3Rnd3RVdGdBQzY2RFI5YVVRcEM5by9YaDFHc0I5RmwvV2c1eFgw?= =?utf-8?B?c0p5V2VKZ29taUg2RktoYjIwY2JZbk5BYkRibXZab0xXVGdLamFCRVJiMStT?= =?utf-8?B?amhrOTBCaVpKazkxWjU0V2xSZjM2Sy9oYkg3enJQU2x3cTg4NWpCQWdsdkR4?= =?utf-8?B?L29iSkJPNWRPUzJMQkZyWU5jWHBEaDR2RDlXeUw5cUVVMnpsRjV6Vno4WDNy?= =?utf-8?B?aU5kZldiUE1PTFdzdVpGVGJpQ3ErZzZCTHNETnFsRktKdDZReTI4OUZ2MS9E?= =?utf-8?B?bWtaRlRLNVFoUWIxMDBqQ1pJRTdMWGp1ZjBzTGVxcW0vT1E2Q25WbGFCcGNU?= =?utf-8?B?Y0FMMU1PUlFHdjhMSkxSb0F1UkRLOVZqMW5wbEh4Z2ZKRmJzQzRnaXBZOE4r?= =?utf-8?B?WTlHTSt0ZWRrQVJheFQyd1JhOElreXcvTUZsSWlQcmd4aG1VaER0djBQRzhJ?= =?utf-8?B?UFVrc2NzTHZOb1JJTDcrUVliYlB5dkJLZHpyQ2ZkS0ZVaG9lYllWdDBtc09M?= =?utf-8?B?NWpmRDk1NHlBMTZraXUyREI2UVFySDdrSEFSekQrME8vTEo0OWttMEhwaHVh?= =?utf-8?B?d01UZG1JV1I2U2MwWUcyWGxKZ01xbUJxRk5pTTlISVBUZWdENWwrVHFFOVRD?= =?utf-8?B?SVlZRGJWdU5RUEVJa0thVDNnPT0=?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1308; 6:gmjnPPj5bSCWEbGDVCOFx1BvMqSuvxqXSJoE+1zABOU1QTNCuKBU0JsvnRnFcqZUgAmV3uzHCeWdfmuzfhSSXqMAx3ZWUN6j3TMW+wrvWcYaLjItYRP+0N+mwmPBAXUqyYQcpp43anlE5xhJII+OMpgzvCAXXe68fWPmdhUVM97yEfXh9jYqxZ8j4Gu7TgzIag78DFLvRYq99i9iMlAY+KxAut8MTHl19b5zV5GyZbXAz05tkntRvypdplPzfxXc2QT+m9bORy55R0bSdJ0FazBcEs0SmXyFeO1oTBQVvMuZs3VYjYxBGnc74m4u5qKexcyGJoLPwl5qMxaMWY39QgQa3PlgoYpZWqn5D3CsTIRniY1Q+9pw6ZHlgNHnKX68ysrrcNd2QKYJ7MTuoIsAKT7+df+suXmgtDd7nYo7MAtuAxfuUqVoKVg6aLOKz84mJCVx0/iWxgq/uFUBqlrJ/WuozM+EQFXZSqjVYbqx1PZrQwOZW4avM1tYVaumAtYvTnmxUgBFB1pkk7X8bFbIXqP0y5ZxNrlsjsLH+4DicUM= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1308; 5:tD6nbLtVeAGQsddbWcLefzND4y4Ivd6I+88eOir9Xdh57Q5C87PzNm6DmpuKC67VAAnC3wvZmt8shrMnz1160wJvj7A5EGuTy0a6QAsmUTkMkcCakYHuHHK8r8ZPoGkN0k3f92w793g0aQbCbNOfICIeY8bKZjgdNqpM2WXhKr2h+kw+XtBbSm37DI6Y9NDFhetq4Ebrzse2Fc0xGk/Xi7yOyIO3drmhXeJRbTro/SqBIXRwlw01nchHL2VxmJeg0w7JLYnXQ2ShemE+UkKIhLZzetvuwi1OejPN9AX4EoJUvp1lTcqX5Zl8VhrS1PCdIY7yyPHvqcMODoJFP3x4RI4TrXBz7r0ThhlQDg80wG/2fYgJX7bQ0FhQIYC51/+77DvcibUd6gUtSd+bdn/bwdVUiEPUZ2f19EXUsCFVLbIjjYY4e28hdXwv9CdB0ZsggxXb7jK4k4a60C+RFlmeNbb+OFQLxAogo53PJJua8TiBGoMAmibqvy05jzg/kBcL; 24:Lr2jfRlbT7MUdGsbHdkpKuaI9yMqkBzrczmgUNq4RnVBC43XDrMDYX6C9HHlYv6K/tYiWRe9oYOxznGATg0o9V6nD9QF90ZOcATlHOjukOM= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1308; 7:56cE2daPug4KmfvFgA4j9cnUOa/6nV4NgnexaEvDCGEVRxhLizi58LAuDhWHd+E/dkSlbeNlDD95HfQJWubkjA5bzDTU86COLlf0zTGwUIKmJq+R0QKdu9KdhWo8LhW0HHPwdiWbylsmkDRAKPbfaKr2X/98EmwnU19JdCYd80bK6RYVZsh5i07+pOMrosE4lcJMOb+8tN+K5YqqhY18c6I1eOUHkBszKw5wUOWcUvDyK3E3V6pH3Ttu4bFABmhTSHaeD7BrIQzvx4/BLtHssRHJt6O3dvXViaos7cst7Zn5XKyh8I/smuaV2m6WnB2QKu0E6TlQY+t5GB+aaZC8xg== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 May 2017 23:01:53.7405 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1308 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, 16 May 2017 23:01:56 -0000 Roger Pau Monn=C3=A9 wrote: > $ cd /home/royger/buildjob/freebsd > $ make -j30 buildworld MAKEOBJDIRPREFIX=3D/home/royger/buildjob/obj/ That will not work as desired. When you set VAR=3Dval as an argument to make, it overrides anything the makefiles want to do and there are a number of points where the top level makefiles want to play with MAKEOBJDIRPREFIX By contrast; MAKEOBJDIRPREFIX=3D/home/royger/buildjob/obj/ make -j30 buildworld=20 or for csh users; env MAKEOBJDIRPREFIX=3D/home/royger/buildjob/obj/ make -j30 buildworld provides the same value via the environment, this leaves the makefiles able to do as they will. From owner-freebsd-current@freebsd.org Tue May 16 23:04: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 07684D70012 for ; Tue, 16 May 2017 23:04:36 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0091.outbound.protection.outlook.com [104.47.36.91]) (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 8EA14146A for ; Tue, 16 May 2017 23:04:34 +0000 (UTC) (envelope-from sjg@juniper.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=22SPjNNx2jbffKDGfpNsellBtvdHw0gjh0Iu5exKPyY=; b=VNyPAaQFn/XivEwMr6S6iqhhxy/U84yNPz/Voqh7TPGzAcLansnDoDQOOZtwfcRyRrxGgmE/il30aYaLsdTN5vAiJKif7aQdwOZGzQ7BDBm4x0LiRA7VroSvcpkQWZFvxeo9QIetoaAv8x1ZGAOnCl339FzNgRcrVWB3Csl+4vw= Received: from BY1PR0501CA0009.namprd05.prod.outlook.com (10.162.139.19) by BLUPR05MB1972.namprd05.prod.outlook.com (10.162.224.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.8; Tue, 16 May 2017 23:04:33 +0000 Received: from BY2NAM05FT058.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::202) by BY1PR0501CA0009.outlook.office365.com (2a01:111:e400:4821::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.8 via Frontend Transport; Tue, 16 May 2017 23:04:32 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; cl.cam.ac.uk; dkim=none (message not signed) header.d=none;cl.cam.ac.uk; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by BY2NAM05FT058.mail.protection.outlook.com (10.152.100.195) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1075.12 via Frontend Transport; Tue, 16 May 2017 23:04:32 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 16 May 2017 16:04:19 -0700 Received: from kaos.jnpr.net (kaos.jnpr.net [172.21.30.60]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v4GN4IFP011787; Tue, 16 May 2017 16:04:19 -0700 (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id B9C1E38551F; Tue, 16 May 2017 16:04:18 -0700 (PDT) To: David Chisnall CC: Johannes Lundberg , freebsd-current , Subject: Re: build src with colored output? In-Reply-To: References: Comments: In-reply-to: David Chisnall message dated "Tue, 16 May 2017 09:29:25 +0100." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 May 2017 16:04:18 -0700 Message-ID: <55662.1494975858@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39410400002)(39850400002)(39450400003)(39840400002)(39860400002)(2980300002)(199003)(24454002)(189002)(9170700003)(81166006)(4326008)(5660300001)(8676002)(50466002)(7126002)(76506005)(53416004)(305945005)(117636001)(6246003)(68736007)(38730400002)(39060400002)(106466001)(6266002)(105596002)(110136004)(107886003)(53936002)(2906002)(7696004)(47776003)(55016002)(86362001)(229853002)(9686003)(23676002)(6916009)(2950100002)(54906002)(189998001)(478600001)(2810700001)(50986999)(76176999)(50226002)(77096006)(356003)(8746002)(8936002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB1972; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:ovrnspm; A:1; MX:1; PTR:InfoDomainNonexistent; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT058; 1:8aSxnF/NY7HUtClBR3mfpZngtxnauP50HBWRj9D1TacXg1ozMYo7SUgTG+pSUzgqCbxjH1ZrIkUAhgyyPKfTbOxeCF4RlT1BL3Ju1ZTPPjC3E+MWVsGVDVvyppEKzaR1wsRBaokjK5odj3Gqh5trRNel8zm7f7GngXrVLSunM4tr8pvb20eZoKRgqyq5EHdw9BiLhSizzD7FWGydULxhPXEYcq8RYs+KSdVXFy1r7yHMGyTeWxW18LjtFRiPAFV0eu8V9j3hk6d+IkWbpP9CQioUt4I7mOAbT2yfYGNYPzwFJIHI7V7nEhqbpiTvV8cgnwLsbCHDRj0cYe4ZAf3XpeNNgDyMY8Dlw2yjATnaiCYzeCq2/f3NE/qU3PXLHTUWRzH5V8NZSOQAg/+4pH70TOICeZtig5gAglXTLHVTDwcXpaDcGfS0KLAz5H3VheFkC6bPxIh2TvQHe6lPh+ba/DZ8teE4rQ/RT/n4unfGHzcVN57fsTMWxKDsBr0aKNPsnFzxvO8tF0DutfC5LLs94ub/LrcTTtXzotQwzNdAGgO8YzzP4HoaVPJXoPlk3pFf4rxDsWwkCMTXUrbS6RJxvQ== X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BLUPR05MB1972: X-MS-Office365-Filtering-Correlation-Id: b2d8484c-95c2-46b1-cc62-08d49cafe9f5 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BLUPR05MB1972; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1972; 3:l8OvUjAK6f9pOqmYxauM4ccPgG+zEoGUE+1egfC01NOHcLD17MlcuKIEY4/KsTr+K1G5bMvBVggA9xGc4w/earX8YV9aDR8Eqpv2tMmgPrnXvaxCcfmGBvK3QbMfiv3igOHglFPB2EDtLoE5xsuE9f+qVJQOCraEPkq9sXwwAZ02n6OzYArGPVs+NDJe40sonwEKmBrbiV+QJZtmYPN2RAf2FZc7L9bXbITEMrE54udVCO9191j+ziT2HB5aZ5rJNA7NrO9iZjCORZk8bdXZMqR2vwFV1UPKGNQ9DvCmcSwvzZl6mTJQw3gKcVzlaWeMz5mUndTeW5k0t6M2VHxbQv7oMuPDMrTzS1vKXMDAFOB4nb0yHeJZP4LlwzkH2LqBxbBexmHeNvzmG7HyM/z4qrPIueFcC96krabSGEbDQ1lAx8CfWFInwKx4hKGZC9TlT1SrWUbz8cbqGZvI2mxv9A== X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1972; 25:JrOFxxm/6+wuwtml503VemZNiC2aVpMQdqgLe3CnJhcMeVv5l7+0ty1/ajzjOgMCCJMKVx54wVD15n4TF5S0UlqVY1SNvY6kMhf+CjPqidAifBqOuLjErTFAnE0MUG83kLzyemYF7oKc3wx0KIUT8pZ5u+cyiS+nn2Z4IdMEuNVEWR8kVhonDs8EZgxuDMm06d4PDJ4hZAIMiTAtQHB/dn3cny/6e4GsQTCRtJ0H9IU/GTzVrSYvWAonNAGPef9q1uby4c9CQTTUSozRTzJI6Ir///Le/fxIu90jTyTwvL53HSAPpc8CjnJJ5XfW+WXTCDd1PTwk8I4xPufVtZVwduFmI84joKRZ9o0nU2ibUDJDIjt6JY/ntjB9aVk3ylsjRr7UVickhaAMpxTvaPCAQ9//1zNgIb6Jxc3rI3iwhzbAijT50WdN183RSbGpqXX8Odu/+OwuSEAcsmCI4U6IrvGCmwfmJSJ9+i78c6sMJ9k=; 31:5tIRYZBwCq4jDSMf7S6dspAMzS0g+4+esNAKktbOGHREGSYPXGeILR0ChE8iiUJIqJVv60X0jiZLSVz5PiP2aCWBK9SzwavgCKND+w+5qkBrJnBrq5TyJxixDVzxhoICjnxCwj+GNHb33DPuUBSOxS5+XLW3OetAmoFlTj4UYBZMikKOek+F6t3c6pfMvVpFli7nrDSi255RhgsH3QKZCb/ojlg95woLV4sA6+bJlZRx4BgWuYrP2568tbyQmHal X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1972; 20:4lmHGNeYYJANC+69z9BLaqDGEDzYnQfb8JDiyrTgT3IM8TMw8OoT1LZZq6F9neaFOHsKKSABEKK5GHM4yWHqQFK4QdmRinCJmloldmciu/gvwpBOVobCDaP6VmAri7ICb9DCkzD8BCOKUnl5nZ127XaI+p59ukZdebMve3zorOqvJ32MAxJ+u+YnAM9hVS7t59//cdmkv4gq8kBkDJg3oDhILGR1AN6hLe3lWekuXEbHE4tJ8VzqwGLq+++UY4h1IqOoGgTQDylEqO4HplmlKABDLV6MK7WL3n4Q9cH1Jv/avykb8B/jT0iBfZbwz9zT3L44RpX8nXVuZ1fXJ5ENl2p2gwpkeJzg7R4ASylxo+ZHKhieELKtqryTJq6A2c91iW+j+t4HlT89gx+soRApmo1fySam1/Vuq+WeZZtki1QZ0JwehPvTZc97ArDChTbkt1IP387TDckPTcJ5Hp0A3Y0pg/z29HaElknf9bkBCVdtJyyOsjWiDlxMO0E2AfyN X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700036)(100105000095)(100000701036)(100105300095)(100000702036)(100105100095)(6040450)(601004)(2401047)(13024025)(13018025)(5005006)(13023025)(13015025)(13017025)(8121501046)(3002001)(10201501046)(100000703036)(100105400095)(93006095)(93003095)(6055026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123555025)(20161123564025)(6072148)(100000704036)(100105200095)(100000705036)(100105500095); SRVR:BLUPR05MB1972; BCL:0; PCL:0; RULEID:(100000800036)(100110000095)(100000801036)(100110300095)(100000802036)(100110100095)(100000803036)(100110400095)(100000804036)(100110200095)(100000805036)(100110500095); SRVR:BLUPR05MB1972; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTFVQUjA1TUIxOTcyOzQ6MTY4RGt2RGRDL0xUNUc3cDFtbkVmbHpDOVV1?= =?utf-8?B?WGRxcjRGejBKLzJ3UGtsT3pvWG0xK3A0dTY1c1ozdEJWTHZ5MUNrZ3V6YVYr?= =?utf-8?B?LzJ2cGdzVnZwMVM0UnpKTjVFcTBUc2lXM2J3cERCaDliZEhkQm45b1U4c0Zx?= =?utf-8?B?ZzluTmJ2aGUzU2pXTGplK05ZU3p2Vmw4Rnp6VmJYUktGK3FZeW9DUXhpNlUv?= =?utf-8?B?QWE1eFJ1VUtPYTVDN0xONkt1QU1WUGJVU1BTTGUxY1NWeE8vb2dUZGxINUd0?= =?utf-8?B?MVpNUmRraSswR0Q1MXh2Z3JFelhnTVYxdllGQ2ZFU3Y1WWtxdkNBam9nTDJr?= =?utf-8?B?MThaYmN4UW4wSXBDajJ1SmhrWFJWN2pVdUl2R2h5UHF3anNMY1NvbWl3aU96?= =?utf-8?B?S2dLSko0QzlkZnRkVXV0dnhGdmt4SnVDMGVzSXlnMkdoR3IwYlQzR3RPMVhj?= =?utf-8?B?N1FWeCtIalUzdnl4RHE4YVhXTURXYlpqR2tGYzNSWUp3ak5hdCs3R2ZMdG5z?= =?utf-8?B?NXdJalBUUFg1Sjcwa0Q4eTZHYlIvK2krR1dIWXorbmZmMGlpVCt2dnloRzBC?= =?utf-8?B?TmljZ051dkJycmt6NmRudi9Ub0R4R1lsNW95NEFQSHdRdktaNURLZGFJUFN0?= =?utf-8?B?NkdIaHBzS1BIZ2RJUHVZR3NTMVNyd1VaTUlEN2Qydkk3Vnp4MUpIWFZlczFy?= =?utf-8?B?bytYZ0hlVzRBU2hlaWMzVXhTS2x2ZTFPSDk3di9VZXY2dUdDbXJGN0U1aEN1?= =?utf-8?B?NWRUeDRkeUlaUTdORlJYa2NxYjVhVENGcVprVDkvNlZPeEVOZ3lTUnM4WVQ3?= =?utf-8?B?OFZ4UW8xZHMrZnphRExkaU5PU0hPMTFNckF1ZGgxeEk4UDlMZnpjUXlBUHhZ?= =?utf-8?B?VGtBL0RXWmxpRjlxV2lxQURITWZqbndoOHFxVkZhR1gvMHZ0aVdaNUNua0xT?= =?utf-8?B?aVI3NUhUSGVhQkNRYWh3ZTVTOXVOQlA1U0lObXExWTJ4QzBNaHNDbTF1RVhV?= =?utf-8?B?a3RMeXlnOXprN3grZDVIUDNyV0ZHQjhxeklob01mbzcwTllhcHNBaks5ZGN4?= =?utf-8?B?bnZYUEd0a3RPWVVtY0Z6RTNzbm8zN0dLcm1SZDk2aXhGOHRySkE2NjZGMEM4?= =?utf-8?B?U25wSXFsdHVHcXVrUUVOMmJnMHR4VDdGZWhsbi9jbHRyczFrR04weTRBeUFl?= =?utf-8?B?SWkxSFBlYXNIM3ZtNFMrWHN3QzNScmRsUGpFNjNVNGJpVDRYOXJSYlRxTDhI?= =?utf-8?B?bW1FSFZpeGFpdncvVXE3V3RGOFBBejdMajRTaWFYQVpKV01FN0JDb0V4Vkl3?= =?utf-8?B?UmRnaHBnYjViL3pkamJnUWNmYUFaNDN6YUFYV0FNeGxBNVJSYm45ZW1xSjhV?= =?utf-8?B?L29UVEhaeld1WGRDUGRzYmp2NHkxcXVCNnFySHptVlZWYS9CZE5lVWw1eFU2?= =?utf-8?B?Qk9uc1lBOUFQb0NLaDBaVGVFVitGTGhlblZUVzd1MXVuQzZVZVlzMHU0b1VB?= =?utf-8?B?Vm1mdC9rSUdHVFJvM1NwQXpnbjkzVFJ3VkJ6TGRLLzdiMHU4S2ZTb2c1bHhU?= =?utf-8?B?b2xaTzhEVlFKQ3AvNTNkR1NnRWlMK1FrczVVNzBHUWNHVHo3NWVoK0RHMkJS?= =?utf-8?B?SnJ1OEV1M2lKN2tTMlFBbVRFNTBrYnU2NGRIUFMzdEZUamJyY04vZHJKVUMx?= =?utf-8?Q?m2wCjvOg7QTMMWaug=3D?= X-Forefront-PRVS: 03094A4065 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTFVQUjA1TUIxOTcyOzIzOk9rVnJ3WWlMUytqTE1MUFI4dUcvZ1N6UGxa?= =?utf-8?B?NWFhY1JwOUZyc1BBcVJacXBCckJtR2dXNmZ3SGp4Nnp6d2RRM2tDcnZBNkFk?= =?utf-8?B?K2FrWjZIb2lYbTV6WkdlMEFndHAwWUg2aW15VDFGUC9NUUtaQUNRTkhndkpm?= =?utf-8?B?VXR0SUdISitORzhFaUdrVFlncnNpT1hBbmFwZ2lRTC82dkw1aG5ERUdNNUJB?= =?utf-8?B?Umt6UmVkdHF0cEVPMEZ1ZkpDdEFLNFdBdTg0OTZKdUtkL1ZXSUdkb0NDcTQy?= =?utf-8?B?LzJEai8xcEN6OGdBMVczOW1IaW9tcHlxN0tteElRS1FVRlRsMlowb2w1bmpu?= =?utf-8?B?YkI3cjJGYmd6Ri9FWFMrZ3JlZlU0NlZKeU9BVGdYMkVqY0x0T3pQUTE4ZnY0?= =?utf-8?B?bkpFUEROVWE2OHFuL2hienRjQXZHT01uLzRSbjQwTGcrWmVGT3MzOUZiNGIy?= =?utf-8?B?R29PUm1zZFc2TlVFZUZzUU9rQXJadlEya2tFYTd3Nnh4SVp5Z1hkMXY3Y1d1?= =?utf-8?B?ZTBhT09ITzB6M0hFSWEyLzEySzkySk1SRklUaEhnZExPb3BiZ3piNWFSVzVO?= =?utf-8?B?ZFgwSU0zOWhKVUlxV3JwUUk0QWwxVk1nQm9PZGNnZEh1b1lZS0svVVNpRmhS?= =?utf-8?B?VWhyZkdONUc0djBMZmV1enlQUEJwMU5mdUFDVTNZVUNnZ0VxLzR2STllQW11?= =?utf-8?B?bFc4NlJsZDMzMUhpdWI0dmJ4VU04angyc0FxUUxtTndvdHlVVzZzend3dFlr?= =?utf-8?B?anVwT3IrRVh3U3pidit5MVl0MGdoWWRLT1AxVDZGUkt4WW11V0Y1RitDR21h?= =?utf-8?B?dHhsZG9nMkpFVCtwR21CaU83aDZFRmMvT1V1clpEMXFtMlZrVFlSWExBK3ZI?= =?utf-8?B?enE0djVIVzc3TUd2Z3lPeVNBTjlUcThiRFRPVlZjWUlKMktaNVdaeXp2L1hW?= =?utf-8?B?eXlLcGFCN3pGeFE2ZDlHeVJsdUw3elVMZys5bzdrdjArWmlvU01NN2FoTzlJ?= =?utf-8?B?NFNkaGZKOFR5NTV0L1AyZENDSkJuQ0FybUNLa09iMW5tT0dNa3hDRXRHY3Bs?= =?utf-8?B?eldhU2xlNllrazg0eDZiWlY5dWVYaC93TGdFOUF0bUJua3RYdTd5NnhDVzUr?= =?utf-8?B?MFJPMTE1Mmg5Vkl0eE1PaGpQb2VBUnVxVStOUE1JaEFGZkpBK2RWK1RsUUg1?= =?utf-8?B?VTQwU0hZQ0l3Z0lrRzlCZE5TZXlwQ01SREhFenJuayt5K0o3SjJtWmlwOWkz?= =?utf-8?B?MUZVbmUzS2JyWEZmL0pqVytUUFZnZmwvV1hJWWJ2NGJoa1ozTU4yNUxFQjRm?= =?utf-8?B?aWd0V0YyTWcwVHRoSHZ3cGc0NmZraXQ2U2JqN0xNMWNyZW5JLzRLdTNtbEN0?= =?utf-8?B?SUN2Zk9BSk5Kb3o5dHgwWG9SUUtXL2hRMjkrbG5EQ296dFNBczREVGQrUWlz?= =?utf-8?B?NUJzMUtIOTk3bHdRY1Y1anFXd1VLOWdjME1scUEzOFNxU3RkbTZJOEJSUXhi?= =?utf-8?B?MU94MkxBb0R2aTdIUSt6VlZBNkFJZGtJMlRBMFkxMWx3OGx5dHA3aDRUMVVR?= =?utf-8?B?SUhHSkxKdG5yazVEZlJ3S25walNlVEQwK3gxWEVXNkw5QXkwUk80QnlWc1g0?= =?utf-8?B?UXNlemFxcmhoZVZ3TC8wMnFpTjBhNUFZY3UwbGVJNHZndkRBdk51b2VHdFRt?= =?utf-8?B?S3k4RmgrNnJudytuYlkzN0l4WEhQT21NUlJNM2N5eVNLWC8wUGRTUU9KWFB2?= =?utf-8?Q?9abtgOGQIu5HRDhfW/JWO93uroG0zHzv0SBws=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1972; 6:2Kfjm3ATnhhQRCJrWbP8fn0FDJUlNPfFbXxHiTgnURgtRc/BQXHaodZE1sKEsvBmhPeWOjZI4rFFcsTjK7goLXj2niHsTC5773lX4q6aGgSXBLa/nV1WQJkK5z45LFgcxBa1sq5e4WD4TrdADp5IAslbX8PbhOViC++UfDiN7gU3/vmy9ZQTW/qDaDWEtvP8Dzci7L6+uiQgNhZc+uE88000jOG7bZ5wbpkt/WPNjJkVEXAgJAcNjZO6NuF2hHWksM2hRMnBXIeVgndkHk6jpMUMNmqjFXBA+R3v/vF+1NvmFszGgtlYiu93OHHzVD8WfJ5p/SdUcvIdlMNiRfEQ2sStDZbOw0hExE8lO9kXdpkrh0ENsRUZPUPjjz+wGfpNixHXBaju6t83yBojJjL/rUAxlKIGdC3s2mj/sNbfiSHBVAxGQEAwHNsMhUiil34Q6prLfqKS78dvy250Tki4qCha0UFkFuhnw4Kk2UpA0YA0iuS8WQK4EVYHSmGvvYeMJT0RvLGRC9g30LnuVGFdglFfbbgwpxUqGXJsbbZk+i0= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1972; 5:p9Otk1F2Y/Rmh/d4csOGRrMDV5D+Kd3MNB27hBzaOWp7Y1JCzPtoo2eqf7M2jraV7PSjAwmRsihYoGc/NWdMrGMVQEwK08iGzFIaTs78k90Vs9E2HZKBzrEWlPPbvvHM19q8DVmHsPOtL1lsG30tosoYUyvbAVt6E368HqLH+0IjWn3tqVdHG8Uq7eAvXpPrFp2cnivMD+TI2LmFjmeHgNMQDZ1Gye+/TSeoPeKNAPPTRAEJk6zXjtbzmdfGN1JRQiOR3DbhlyV2lMtjbE8eBs9YNMvi4Yua6tp8j2LySvFU/1Na43saR6rNwFS+hm5UyZGVF28ZA0lRyYBNWrX3PV0hJhWacekvD7ZCowQPDyJ04kyRaiCbTq4DUGv2ZsAnPXh5/mlVSH2b2Xzm+SqPnMpv+vaw0ZWlDd4OJL2AAuH1Z/A6AD+qRjfEOvt0zen7y3yxmKHf0DJcFMaqczxTxUrxIEfC5Mz9RuBYBCVMZjk/nTpYn0q7OJ0WSCWP+eDA; 24:sEfPnQK537kebhA3NRjwGNOZr0gvRWFasNmo4WzrdhUNhzBvugLZwLn1sAMVHpJj1V4RpCF6/2DcIY8FnqVQTgJ32gkmSllAHap36iwaCQk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1972; 7:3pXC1+HlEl5rj1fGWUognpK982wUJAYjBdR29ZT2wiPJ+SgGlLpTAZExHayHzpflTlNwrk+JmyNGzqLPjlbJ1fMn+3nsQZHd3rGx3ktvpBmIxtGX1uJBpabOntymnUUKttdXugUejC7cVaI6kxU8IfmXKbyGYW/CxTfyoeQMx1z/AoMAI0tHZ957phv7dCVNmCnvxjXQp81PEVz9IFVTD9udG+J+lqvD2MBrZVRZqCpvzxe9C5/pNFitVbB+lChPack3uZo2anlko84EvEcshA6nN7diZr1nxXDhD6sLACzF8CJA6FKGnikP3udaDvZyp6Y6tqPVqpfxIPgEPA6tCw== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 May 2017 23:04:32.2160 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB1972 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, 16 May 2017 23:04:36 -0000 David Chisnall wrote: > Ideally, we=E2=80=99d solve this by fixing bmake to behave more like a mo= dern > build tool and: It's called meta mode ;-) and makes the OP's real issue much easier - when build fails, the failing .meta file is saved in src/../error/ providing no doubt and no need to search. From owner-freebsd-current@freebsd.org Wed May 17 00:23: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 16D05D6D5A9; Wed, 17 May 2017 00:23:48 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D4B9E1B9E; Wed, 17 May 2017 00:23:47 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v4H0NkMH042616 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 16 May 2017 17:23:46 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v4H0NkKx042615; Tue, 16 May 2017 17:23:46 -0700 (PDT) (envelope-from sgk) Date: Tue, 16 May 2017 17:23:46 -0700 From: Steve Kargl To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: UC Berkeley 4-clause copyright Message-ID: <20170517002346.GA42582@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 00:23:48 -0000 The files in lib/msun/bsdsrc contain the 4-clause UC Berkeley Copyright. Supposedly UCB no longer enforces clause 3. Can clause 3 be removed? -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-current@freebsd.org Wed May 17 00:37: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 664EED6DC9A for ; Wed, 17 May 2017 00:37:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 38EC1792 for ; Wed, 17 May 2017 00:37:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22e.google.com with SMTP id f102so282258ioi.2 for ; Tue, 16 May 2017 17:37:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=fXXe8+2YgEyttyOuSwHpJX3RCuS5qAYVozHpGSSwWmQ=; b=K+rEZH9iGSCRpWWIooE9lAH780JVQoW5Cx5SSc5wgBVRydJVxnUpTVwZ2KkOwzJRZu ciZ1nagSTQxKMc+V9Qgt7kTQl1AmGc4vihkZxoMBEdjkuavN+7HGYseZlo5TbfI7oHRi MPdyYG5SOzhbos7xKW7pXDtQaSbGUojrE58UT9s1/3OBs0h2guYmhpsAk2EH+NAzqJmN 48ckUUmYfR2iP/y0KS7100bBJ6VHXlraeavSiI6Zt/HPzcCA06vxLIz6qg/wOfBIaX4r HBrfPgkwfzn6do45NfyqT0WfTFtPuaGL/t56FdNXw26biYCjAAB6CKcalCxKojig4WOj W0zA== 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=fXXe8+2YgEyttyOuSwHpJX3RCuS5qAYVozHpGSSwWmQ=; b=ZV2Kka9L8+mPvdtxZbZFkrKnFSk11rEzzu8PCjoxHgaiBvnU85X1jGbLRSxkgfMCIx Nn/y48soymAd9wQ2xvblKMv68UhOIKoI8O8h3jCS0lVegEivjQrmaXdG8oKNQ45w4u61 4ryfLr0k5FazwFLTVT7oQVOEebqKTJEhXinl5PmfnOEjr/uFI9E6RnY1ftgn61DdyAHh WyVHYQMfdZxL8cR9tlLuErzQkN9K+CohGOOVCXsm6r5CHmD9zGx8K50GZfRBboquvSDJ CKjDYQ1w0kTSWkAytcyLY4tz+UCnRKnv7q7EbItqWUCdAAUFpK0BKAHGrJA63leTCTMG Me1w== X-Gm-Message-State: AODbwcAok9QqJjub22gmH8+m3mgLeq1oaOg12humnrmcHChENG+Hd/8O f+bbhzZSSzAv2boNcwe4PBKf3mojS5TF X-Received: by 10.107.188.132 with SMTP id m126mr806501iof.148.1494981476918; Tue, 16 May 2017 17:37:56 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.126.6 with HTTP; Tue, 16 May 2017 17:37:56 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:51cb:c6:1f52:3765] In-Reply-To: <20170517002346.GA42582@troutmask.apl.washington.edu> References: <20170517002346.GA42582@troutmask.apl.washington.edu> From: Warner Losh Date: Tue, 16 May 2017 18:37:56 -0600 X-Google-Sender-Auth: 7Hh09TITOTM88aHOVnW52KQlAuQ Message-ID: Subject: Re: UC Berkeley 4-clause copyright To: Steve Kargl Cc: FreeBSD Current , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 00:37:58 -0000 Yes. Remove it. It's convention these days to also renumber. It was likely missed. Are there other copyright holders? If so, that would be why I didn't remove it at the time years ago.... But I may have missed them too. Warner On Tue, May 16, 2017 at 6:23 PM, Steve Kargl wrote: > The files in lib/msun/bsdsrc contain the 4-clause UC Berkeley > Copyright. Supposedly UCB no longer enforces clause 3. Can > clause 3 be removed? > > -- > Steve > 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 > 20161221 https://www.youtube.com/watch?v=IbCHE-hONow > _______________________________________________ > 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 Wed May 17 00:48: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 D95BED7019A; Wed, 17 May 2017 00:48:40 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B02E0E42; Wed, 17 May 2017 00:48:40 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v4H0md8k042823 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 16 May 2017 17:48:39 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v4H0mdCS042822; Tue, 16 May 2017 17:48:39 -0700 (PDT) (envelope-from sgk) Date: Tue, 16 May 2017 17:48:39 -0700 From: Steve Kargl To: Warner Losh Cc: FreeBSD Current , "freebsd-hackers@freebsd.org" Subject: Re: UC Berkeley 4-clause copyright Message-ID: <20170517004839.GA42771@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170517002346.GA42582@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Wed, 17 May 2017 00:48:41 -0000 On Tue, May 16, 2017 at 06:37:56PM -0600, Warner Losh wrote: > On Tue, May 16, 2017 at 6:23 PM, Steve Kargl > wrote: > > The files in lib/msun/bsdsrc contain the 4-clause UC Berkeley > > Copyright. Supposedly UCB no longer enforces clause 3. Can > > clause 3 be removed? > > > Yes. Remove it. It's convention these days to also renumber. It was > likely missed. > > Are there other copyright holders? If so, that would be why I didn't > remove it at the time years ago.... But I may have missed them too. > lib/msun/b_log.c and lib/msun/mathimpl.h have appear to have onlu UCB in file (other than bde and das in the RCS string). lib/msun/b_tgamma.c has a standard 4-clause BSD license with the years 1992 and 1993 listed. But, later in the file there is the comment /* * This code by P. McIlroy, Oct 1992; * * The financial support of UUNET Communications Services is greatfully * acknowledged. */ IANAL, so I don't know if this triggers the "and its contributors." portion of clause 3. lib/msun/b_exp.c has a standard 4-clause BSD license with the years 1985 and 1993 listed. Later in the file is KC Ng's ChangeLog like annotation /* EXP(X) * RETURN THE EXPONENTIAL OF X * DOUBLE PRECISION (IEEE 53 bits, VAX D FORMAT 56 BITS) * CODED IN C BY K.C. NG, 1/19/85; * REVISED BY K.C. NG on 2/6/85, 2/15/85, 3/7/85, 3/24/85, 4/16/85, 6/14/86. Again, IANAL. -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-current@freebsd.org Wed May 17 00:51:31 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 7873DD704FF for ; Wed, 17 May 2017 00:51:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 388AD1288 for ; Wed, 17 May 2017 00:51:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22e.google.com with SMTP id k91so427753ioi.1 for ; Tue, 16 May 2017 17:51:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=enY0NG/TmAzj+fZe4bIAchRLuJf7YCu5LCBPoVMKWMs=; b=dA2RWT48hxHannltGEcGIGi0U1kuW59FGiYKk07k0f4xwmyx4T0/iX/FaubxNB/r53 c/4p44mmKuvqFu+szlff3G7TuRINtrDZfiv4eDH2RhE/BX6oHul028smMSoQd0f0DX6H AhPI9drbtkJ6HGo/mVfUpntVXzFY9rpePhwPtIpWwkr+8XeNJNblJI18FxQWJhiSl2I2 8KrBFKN4u5rxUOswturQKCEeC54cimviHtVhv3oDf6k0J3yQCNTgSPZSsGapXpJx48VB 1WhGhJeraEmZ2Usde+BjwTDV3GXhntlz8oo1R9jAZgnKr21unJoSyhB3yNWRRhAT4YLh GfmQ== 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=enY0NG/TmAzj+fZe4bIAchRLuJf7YCu5LCBPoVMKWMs=; b=bTYjmOjmX8ZQGZI84+lnVfo7BBV67VOtuGTjOvB7+3xyKlQ8jKEsWJyeT6GjI0ExmW rr0bADXiEC7c6XbU7lB2MK6HJzoK8gcwCT0+H53H/EC7jAeSLZdP8KabJVunTnbkjwik VUkBEJmvmChuZh3qKrtMjFPW9lyulfXQsVJYNaELGmprNgXaK3lvK0ulITMD/8zvMwo4 UwbDG5zJWMvfQy58jwb8kj/4bh++xLeD/PUXJTq4q3rj/v1KvmTQLb0cwMRc6q6e4pfs tX+kb7TdJSEU//OG0oyjjYW7rCMNiMS/OnxnFjFZLhhcuwPnoNC/6RzniK5+i0vnzK86 /FdQ== X-Gm-Message-State: AODbwcDhz0Sjbw2FbDAz7dX89bAThZwMux9iDn/0CF6zPubvdDyQLhJs qJXWqmh6ztl0VmRS7ME+6hWRMNPS6y70 X-Received: by 10.107.188.132 with SMTP id m126mr851122iof.148.1494982290519; Tue, 16 May 2017 17:51:30 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.126.6 with HTTP; Tue, 16 May 2017 17:51:30 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:6897:8c9a:30f5:4de8] In-Reply-To: <20170517004839.GA42771@troutmask.apl.washington.edu> References: <20170517002346.GA42582@troutmask.apl.washington.edu> <20170517004839.GA42771@troutmask.apl.washington.edu> From: Warner Losh Date: Tue, 16 May 2017 18:51:30 -0600 X-Google-Sender-Auth: Bk8LDw0yXNKnVOdZZt4tmjdw3X8 Message-ID: Subject: Re: UC Berkeley 4-clause copyright To: Steve Kargl Cc: FreeBSD Current , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 00:51:31 -0000 If it says that it's copyright those people, that's an issue. If it doesn't then there's no issue. Doesn't look like it does. If you'd like, I can look at it an DTRT if you're unsure. Warner On Tue, May 16, 2017 at 6:48 PM, Steve Kargl wrote: > On Tue, May 16, 2017 at 06:37:56PM -0600, Warner Losh wrote: >> On Tue, May 16, 2017 at 6:23 PM, Steve Kargl >> wrote: >> > The files in lib/msun/bsdsrc contain the 4-clause UC Berkeley >> > Copyright. Supposedly UCB no longer enforces clause 3. Can >> > clause 3 be removed? >> > >> Yes. Remove it. It's convention these days to also renumber. It was >> likely missed. >> >> Are there other copyright holders? If so, that would be why I didn't >> remove it at the time years ago.... But I may have missed them too. >> > > lib/msun/b_log.c and lib/msun/mathimpl.h have appear to have > onlu UCB in file (other than bde and das in the RCS string). > > lib/msun/b_tgamma.c has a standard 4-clause BSD license with > the years 1992 and 1993 listed. But, later in the file there > is the comment > > /* > * This code by P. McIlroy, Oct 1992; > * > * The financial support of UUNET Communications Services is greatfully > * acknowledged. > */ > > IANAL, so I don't know if this triggers the "and its contributors." > portion of clause 3. > > lib/msun/b_exp.c has a standard 4-clause BSD license with the > years 1985 and 1993 listed. Later in the file is KC Ng's ChangeLog > like annotation > > /* EXP(X) > * RETURN THE EXPONENTIAL OF X > * DOUBLE PRECISION (IEEE 53 bits, VAX D FORMAT 56 BITS) > * CODED IN C BY K.C. NG, 1/19/85; > * REVISED BY K.C. NG on 2/6/85, 2/15/85, 3/7/85, 3/24/85, 4/16/85, 6/14/86. > > Again, IANAL. > > -- > Steve > 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 > 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-current@freebsd.org Wed May 17 00:55: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 5EC29D707A3; Wed, 17 May 2017 00:55:25 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A01917FC; Wed, 17 May 2017 00:55:25 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v4H0tOqV042928 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 16 May 2017 17:55:24 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v4H0tOVD042927; Tue, 16 May 2017 17:55:24 -0700 (PDT) (envelope-from sgk) Date: Tue, 16 May 2017 17:55:24 -0700 From: Steve Kargl To: Warner Losh Cc: FreeBSD Current , "freebsd-hackers@freebsd.org" Subject: Re: UC Berkeley 4-clause copyright Message-ID: <20170517005524.GA42906@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170517002346.GA42582@troutmask.apl.washington.edu> <20170517004839.GA42771@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Wed, 17 May 2017 00:55:25 -0000 I don't have a commit bit. I just checked OpenBSD/NetBSD. They use a 3-clause license. -- steve On Tue, May 16, 2017 at 06:51:30PM -0600, Warner Losh wrote: > If it says that it's copyright those people, that's an issue. If it > doesn't then there's no issue. Doesn't look like it does. If you'd > like, I can look at it an DTRT if you're unsure. > > Warner > > On Tue, May 16, 2017 at 6:48 PM, Steve Kargl > wrote: > > On Tue, May 16, 2017 at 06:37:56PM -0600, Warner Losh wrote: > >> On Tue, May 16, 2017 at 6:23 PM, Steve Kargl > >> wrote: > >> > The files in lib/msun/bsdsrc contain the 4-clause UC Berkeley > >> > Copyright. Supposedly UCB no longer enforces clause 3. Can > >> > clause 3 be removed? > >> > > >> Yes. Remove it. It's convention these days to also renumber. It was > >> likely missed. > >> > >> Are there other copyright holders? If so, that would be why I didn't > >> remove it at the time years ago.... But I may have missed them too. > >> > > > > lib/msun/b_log.c and lib/msun/mathimpl.h have appear to have > > onlu UCB in file (other than bde and das in the RCS string). > > > > lib/msun/b_tgamma.c has a standard 4-clause BSD license with > > the years 1992 and 1993 listed. But, later in the file there > > is the comment > > > > /* > > * This code by P. McIlroy, Oct 1992; > > * > > * The financial support of UUNET Communications Services is greatfully > > * acknowledged. > > */ > > > > IANAL, so I don't know if this triggers the "and its contributors." > > portion of clause 3. > > > > lib/msun/b_exp.c has a standard 4-clause BSD license with the > > years 1985 and 1993 listed. Later in the file is KC Ng's ChangeLog > > like annotation > > > > /* EXP(X) > > * RETURN THE EXPONENTIAL OF X > > * DOUBLE PRECISION (IEEE 53 bits, VAX D FORMAT 56 BITS) > > * CODED IN C BY K.C. NG, 1/19/85; > > * REVISED BY K.C. NG on 2/6/85, 2/15/85, 3/7/85, 3/24/85, 4/16/85, 6/14/86. > > > > Again, IANAL. > > > > -- > > Steve > > 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 > > 20161221 https://www.youtube.com/watch?v=IbCHE-hONow > _______________________________________________ > 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" -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-current@freebsd.org Wed May 17 00:58: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 43556D70989; Wed, 17 May 2017 00:58:04 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A5641AF5; Wed, 17 May 2017 00:58:04 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v4H0w3U6042970 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 16 May 2017 17:58:03 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v4H0w3lW042969; Tue, 16 May 2017 17:58:03 -0700 (PDT) (envelope-from sgk) Date: Tue, 16 May 2017 17:58:02 -0700 From: Steve Kargl To: Warner Losh Cc: "freebsd-hackers@freebsd.org" , FreeBSD Current Subject: Re: UC Berkeley 4-clause copyright Message-ID: <20170517005802.GB42906@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170517002346.GA42582@troutmask.apl.washington.edu> <20170517004839.GA42771@troutmask.apl.washington.edu> <20170517005524.GA42906@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170517005524.GA42906@troutmask.apl.washington.edu> 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, 17 May 2017 00:58:04 -0000 In looking at NetBSD/OpenBSD's math_private.h, it seems the content of mathimpl.h have been tacked onto it. -- steve On Tue, May 16, 2017 at 05:55:24PM -0700, Steve Kargl wrote: > I don't have a commit bit. I just checked OpenBSD/NetBSD. > They use a 3-clause license. > > -- > steve > > On Tue, May 16, 2017 at 06:51:30PM -0600, Warner Losh wrote: > > If it says that it's copyright those people, that's an issue. If it > > doesn't then there's no issue. Doesn't look like it does. If you'd > > like, I can look at it an DTRT if you're unsure. > > > > Warner > > > > On Tue, May 16, 2017 at 6:48 PM, Steve Kargl > > wrote: > > > On Tue, May 16, 2017 at 06:37:56PM -0600, Warner Losh wrote: > > >> On Tue, May 16, 2017 at 6:23 PM, Steve Kargl > > >> wrote: > > >> > The files in lib/msun/bsdsrc contain the 4-clause UC Berkeley > > >> > Copyright. Supposedly UCB no longer enforces clause 3. Can > > >> > clause 3 be removed? > > >> > > > >> Yes. Remove it. It's convention these days to also renumber. It was > > >> likely missed. > > >> > > >> Are there other copyright holders? If so, that would be why I didn't > > >> remove it at the time years ago.... But I may have missed them too. > > >> > > > > > > lib/msun/b_log.c and lib/msun/mathimpl.h have appear to have > > > onlu UCB in file (other than bde and das in the RCS string). > > > > > > lib/msun/b_tgamma.c has a standard 4-clause BSD license with > > > the years 1992 and 1993 listed. But, later in the file there > > > is the comment > > > > > > /* > > > * This code by P. McIlroy, Oct 1992; > > > * > > > * The financial support of UUNET Communications Services is greatfully > > > * acknowledged. > > > */ > > > > > > IANAL, so I don't know if this triggers the "and its contributors." > > > portion of clause 3. > > > > > > lib/msun/b_exp.c has a standard 4-clause BSD license with the > > > years 1985 and 1993 listed. Later in the file is KC Ng's ChangeLog > > > like annotation > > > > > > /* EXP(X) > > > * RETURN THE EXPONENTIAL OF X > > > * DOUBLE PRECISION (IEEE 53 bits, VAX D FORMAT 56 BITS) > > > * CODED IN C BY K.C. NG, 1/19/85; > > > * REVISED BY K.C. NG on 2/6/85, 2/15/85, 3/7/85, 3/24/85, 4/16/85, 6/14/86. > > > > > > Again, IANAL. > > > > > > -- > > > Steve > > > 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 > > > 20161221 https://www.youtube.com/watch?v=IbCHE-hONow > > _______________________________________________ > > 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" > > -- > Steve > 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 > 20161221 https://www.youtube.com/watch?v=IbCHE-hONow > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-current@freebsd.org Wed May 17 06:56: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 87799D70077 for ; Wed, 17 May 2017 06:56:45 +0000 (UTC) (envelope-from kob6558@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 5906B1451 for ; Wed, 17 May 2017 06:56:45 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-pg0-x22c.google.com with SMTP id u187so2584857pgb.0 for ; Tue, 16 May 2017 23:56:45 -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=Oib95cGnCwQokSjbYD9Joej5Ol6Y7O+EVn76c5KVV48=; b=BctdFuIE6lSESMPUmCE5hVJrSBkOTYQOwM3U+OpmGRh06IA+cUPI5uBLE47vuhJmh8 06VTEZ0FE0dhVIbuS7ode29+jQRU7eEhxZXtJrSqkPU5FuT/o4HPtOIduBmrE2xG+ME6 2eAohgeRXJdgx8ZeBqYpuXXZ+nrAgMi/XM33GkRlP1mDnJAipy1moXacEM9UXlk6kQ0G 6yiGjwv9XFQOCcNmDSisyPyHe4Lv/xDeY7aQFGJ6zyHt432E8LDl/juQEF2iuSX30A4i 50FGrQnQujD8sGmqkqhg25wUvd/I5pSs+oXbsWN1RgHtFb1WVd9VV7JE/MHa5CJoJixH FhsQ== 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=Oib95cGnCwQokSjbYD9Joej5Ol6Y7O+EVn76c5KVV48=; b=jmBAEsJqyY7lqT7IXGx006gTbmNjNssRIf7cTMMeDdsJu3VLtAp1Z5UfCVo2WPlVuS fGzZZSJEmuPBOsG18Dx/QYFMgTdgV0gnt8tImPwW2p/RajUPF+J+Cd7SJf324TG4W4q2 qD8wGGh/IGpuOd8r/js7sfysVxI94oQiotACxJEJnfWuy0S8/jK1qBSxH2SgIbyD8OCm +clleZkc6KdQFUbFtz1XUzYIfW95B3zH8IGSeUaRG+A7VRJby6aZ4Qo+xtfTvXeRPZ+4 uzdSHBtxoWX53S7IBwpLW9aQ1LqiKjv+uLTdrf3zEIocD8ii59haZ6AA3OusBLt2WTr2 YOrA== X-Gm-Message-State: AODbwcC7RQCICC3WBkvcOxmdIwZFF4ZuCCg05MITVFD6eZK1Ao5dj7mk AHR/i+d+9e9xZ2fH70jASp1VgH3HX58788o= X-Received: by 10.84.232.3 with SMTP id h3mr2539437plk.42.1495004204851; Tue, 16 May 2017 23:56:44 -0700 (PDT) MIME-Version: 1.0 Sender: kob6558@gmail.com Received: by 10.100.176.201 with HTTP; Tue, 16 May 2017 23:56:44 -0700 (PDT) In-Reply-To: References: From: Kevin Oberman Date: Tue, 16 May 2017 23:56:44 -0700 X-Google-Sender-Auth: wi9j_JdDwyAzuIJVYQiiaOjlB0o Message-ID: Subject: Re: misc/mc, diff and compare two files To: Boris Samorodov Cc: 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: Wed, 17 May 2017 06:56:45 -0000 On Sun, May 14, 2017 at 7:53 AM, Boris Samorodov wrote: > Hi All, > > FYI: For those who use FreeBSD-HEAD, misc/mc and it's awesome "compare > two files" feature: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219277 > > HTH > -- > WBR, bsam Or use the "compare [two|three] [buffers|files]" tool in emacs. Being able to deal with three files can be surprisingly handy. emacs is a great tool for many things and I even find it has a pretty good editor, though most vim? users seem to disagree. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 From owner-freebsd-current@freebsd.org Wed May 17 10:53:03 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 9D45DD71268 for ; Wed, 17 May 2017 10:53:03 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5541EC6D; Wed, 17 May 2017 10:53:03 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.87 (FreeBSD)) (envelope-from ) id 1dAwZj-000OwD-58; Wed, 17 May 2017 12:53:03 +0200 Date: Wed, 17 May 2017 12:53:03 +0200 From: Kurt Jaeger To: Mark Johnston Cc: "O. Hartmann" , freebsd-current Subject: Re: IFLIB: em0/igb0 broken: No buffer space available/TX(0) desc avail = 1024, pidx = 0 Message-ID: <20170517105303.GI87900@home.opsec.eu> References: <20170516065623.6e2de036@freyja.zeit4.iv.bundesimmobilien.de> <20170516195220.GA38599@wkstn-mjohnston.west.isilon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170516195220.GA38599@wkstn-mjohnston.west.isilon.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: Wed, 17 May 2017 10:53:03 -0000 Hi! > On Tue, May 16, 2017 at 06:56:23AM +0200, O. Hartmann wrote: > > Since the introduction of IFLIB, I have big trouble with especially a certain > > type of NIC, namely formerly known igb and em. Please submit a PR, if there is no PR yet. I'll try to find this board on the systems I maintain to reproduce. -- pi@opsec.eu +49 171 3101372 3 years to go ! From owner-freebsd-current@freebsd.org Wed May 17 17:37:55 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 4018CD70929 for ; Wed, 17 May 2017 17:37:55 +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 A05AC1E78 for ; Wed, 17 May 2017 17:37:53 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([85.179.172.118]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M2WgT-1e0xDr14mT-00sPVE; Wed, 17 May 2017 19:37:38 +0200 Date: Wed, 17 May 2017 19:37:30 +0200 From: "O. Hartmann" To: "Simon J. Gerraty" Cc: Roger Pau =?iso-8859-1?Q?Monn=E9?= , Subject: Re: buildworld not working with MAKEOBJDIRPREFIX Message-ID: <20170517193730.63fab9d3@thor.intern.walstatt.dynvpn.de> In-Reply-To: <55605.1494975700@kaos.jnpr.net> References: <20170516083911.agudcf7m62xiyhui@dhcp-3-128.uk.xensource.com> <55605.1494975700@kaos.jnpr.net> 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_/GlrvZyl8wx+1+w10wEcEK0H"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:ZjPgLliiOGQznIjHx5DYya62vDRpAFcD/IzDjnzrJirxQWz0YG+ UpK+sQqpzU4HBHHjzrCKPZV4BPnIHNgVOw0nhm786BhUwRvmuKcJ1cUSZhaFqEvJTr+TKtJ 5v5ec9qzXli8csQbOEpfhYAsHO49gEg5ZyhGBB3+w7CG2IgsvkVsDJxsta9eCqEq8QyZCtl R4zIMFOXYdFvEaWilmRGw== X-UI-Out-Filterresults: notjunk:1;V01:K0:IhCodsh42ik=:dbPL87P5pscSam0nKqEVvP YhHCCWWsZ6pa03/AwVqhA1/myCUjsD3bqR2ORTXF5CNbQEhMkBst1aN4rE3aTKLvxsnB6xHk6 AtQGBNPlupuj8Zh4gP8sYSw9jsxrftIBEQSBElPdi3f5e9PR4CafYpvizC/ZZnAE3Jkbc6yja ngnDyylltvkT6Ei+VCUwMt54Iftflz6buzJSaeF4BxZHbp8FxzhEwntsFR6fGDAzjQktP5Zsa eNzb1T532cs5KcVTYDNEfl8Yj8JtPACzP50h77UNHskmQuytro7ttMhC1OCT2p7hEL9ouxCJg pJ7opMHMg7dREseT4fQwnCAOM28QavSiB02dPvWuF20pF3mMfB1XTS0Yws8JaC6jLtFsySM04 /RwNfg5IP7KeADd4kkkTFRXueUN3qWDkJGSnNAfO+EMN1Jg02cr2HKJxIi1uLI6vHkOu+v6Qi 7luIWzPIjFSzvbB3tJT9dMjNfJqzLLc2yD32aihC5hMXy7YXVLk/v3PZf7AT1FZ9tJTHDXU/k 42Ww3AmW3yG07qV5OMngnm2QXdFTRm4279RmooxsCAJ9/vZZxiTFX5EBpUUrSqTxe4WWoy7mX 5OTSCCpK1MY7Saojv0JNl3tbuGHbr9X14jBo1DxoiTJFafHE0Ig7bwvbUazHVWCw/8A3MoUMh Ok1FX28e0gfxiKclMAQXUuvlsXoVXUwN0fC5twUdPkKZWBoHhNFRLyBgWsKfYvWCzVkFJJzXp L47g5YABLc3F818EZ3SjE3KKtvYS9/Kz/aQtDLN1AY1+vCYv2ywqdcASawg= 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, 17 May 2017 17:37:55 -0000 --Sig_/GlrvZyl8wx+1+w10wEcEK0H Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Am Tue, 16 May 2017 16:01:40 -0700 "Simon J. Gerraty" schrieb: > Roger Pau Monn=C3=A9 wrote: > > $ cd /home/royger/buildjob/freebsd > > $ make -j30 buildworld MAKEOBJDIRPREFIX=3D/home/royger/buildjob/obj/ =20 >=20 > That will not work as desired. >=20 > When you set VAR=3Dval as an argument to make, > it overrides anything the makefiles want to do > and there are a number of points where the top level makefiles want to > play with MAKEOBJDIRPREFIX >=20 > By contrast; >=20 > MAKEOBJDIRPREFIX=3D/home/royger/buildjob/obj/ make -j30 buildworld=20 >=20 > or for csh users; >=20 > env MAKEOBJDIRPREFIX=3D/home/royger/buildjob/obj/ make -j30 buildworld >=20 > provides the same value via the environment, this leaves the makefiles > able to do as they will. > _______________________________________________ > 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" Thanks for this clarification. Kind regards, Oliver --=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_/GlrvZyl8wx+1+w10wEcEK0H Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWRyKWgAKCRDS528fyFhY lC0/Af9CzFP9LABCxqp5nwGsdBYWnOSZ1mce71iYPVTk6S0YftelXz+OGOZVT0qT XqPRIh7DJ9Xq9Fv879Ag77dgqZO5Af41BQZ7XpzTjmmEwrShTHb5vHbvmXIjFYxv R0OaWhSa7zI8bAqM9NSKwFUXhTG8UMFQ2byJ1cUV5ow/i4nioqQ/ =+Wwe -----END PGP SIGNATURE----- --Sig_/GlrvZyl8wx+1+w10wEcEK0H-- From owner-freebsd-current@freebsd.org Thu May 18 00:46:17 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D2A1CD7045F; Thu, 18 May 2017 00:46:17 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 6C2A61B0D; Thu, 18 May 2017 00:46:17 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wm0-x22c.google.com with SMTP id v15so34635735wmv.1; Wed, 17 May 2017 17:46:17 -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=gfVq3TojoDqkMiOWcRtpXZVwS62ksm8yNdKeS0rwaes=; b=rU/2EDXRzi1E6qDY4Yl4Vf2i8qOcyuYTMMhvBXXjfCN6+ujf9cAUEVs79KmncZV7lZ ywHhh4UZSj6mH+9RSSra9ojdjgwGZpRrGl/ZmNjJyQbbGFvlXY5J/MJ8tvJBdL+9NDSm slm5Ub7e0TAXPXfMhWKChC5BuOakqN2RUWjexUlbpIg0r0NP4smR4Szs+zQ33FlTwbsf q1GGCGKgZCvweSMzJBEQKdVOMdkUMJabClY4ajv6Ii7Blu1IiRBGu4trzSViTKtlrBN/ Ef3VXGWGvxGExO8Y625FuNceZkWfcm9ZH5mcmsqOpmRu5HkYPTUDYf5rWAIvAHZoa/Zh ft1A== 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=gfVq3TojoDqkMiOWcRtpXZVwS62ksm8yNdKeS0rwaes=; b=bw6KjIOUK+cZPjI2kLttRJOHp+ZXM5lETbbExed5vZy9U3eEXz3EHMisM1K0TAzQHT oe7/ejClofLGVCs+qbMnavqac8vQkm91MB4pl68z3JzOdfrdp7UBtKu7UmxsuUiKry9w ovZYRIy4/jUBznj/3CveaEDzEY80vYAvwy0hPpDT3/wTwvaYomjsR7d9J4GTJUEkMsAS 7MAwbDfrQnKHNLED7S3Aa3PaOp4N5UFcrN9pPBMeDpuTD+mfHB1qTt0kmm1VKZOlF3za FF4lDud+AZZpxHxbVZO0eV1+6nXBnt9siaJt5HOU6aTbckUxiIAjy8KfAV0NBSJd9c6n HH5A== X-Gm-Message-State: AODbwcA1/eKTD/7X8fg/P7yhGtcak3nhPCHGs/+IsST7sOJlVBloC41C Eiv6mMijxER+hbT0ewazE3QPdbNM8W5A X-Received: by 10.28.214.211 with SMTP id n202mr845740wmg.105.1495068374783; Wed, 17 May 2017 17:46:14 -0700 (PDT) MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.28.193.134 with HTTP; Wed, 17 May 2017 17:46:14 -0700 (PDT) From: Adrian Chadd Date: Wed, 17 May 2017 17:46:14 -0700 X-Google-Sender-Auth: kc8mwDQHwQq0pTukRJ5tFF9oqWA Message-ID: Subject: make concurrency kit a module To: freebsd-current , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 00:46:17 -0000 hi, this is a quick change that makes concurrency_kit a module. Right now the only thing using it is linuxkpi so it's all dead code on non-linuxkpi platforms. -adrian From owner-freebsd-current@freebsd.org Thu May 18 01:04:12 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C27D5D70BEC; Thu, 18 May 2017 01:04:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 6B1E61930; Thu, 18 May 2017 01:04:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wr0-x232.google.com with SMTP id l9so22399181wre.1; Wed, 17 May 2017 18:04:12 -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; bh=zbi9Xv0fbzE66OaYG9LoiZZb4+qG9aPTQSz4IB1LLRI=; b=fJqdWfToEdB3+rv7+H7g8EuhSfgYUE/YIefk+7kOEx+5dLzOdj+U3Mu/Aw0nER5ur0 8T6IA+Rbo0GLHtCK1HKeJYKUPvV6gzaqBQ1DK/c/XA8G3u7XgaNlDfkbudMXaT0KvYmD H97KNEZ6QSAVK1atgP0LDAo3wj2KPxyoqXgJWA/SSBz4eLdcNfLBi92RIxGWVdt9onIZ 93KxRSr9XJI+agT1OFlngAdX6IDlyOpP5SjRfbRjQJ05WozapyMV6gIcDHYkwC/cfwdh vCOxPwcEp7BWnfBT56suN8qBPTj+DmMwINJZuH5KMlHDujQywF7iYJKvxFTXFdxAaYhc rqkg== 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; bh=zbi9Xv0fbzE66OaYG9LoiZZb4+qG9aPTQSz4IB1LLRI=; b=XihynrA3TfHQ1e+KEyIBp63mA478mLVEts7tE7Ax95evpLwx2situBMLlyn4c7EXYs LbJrYvK7pCQ6+A6JS8vZ3XDX9bB+E4OWa9YU6pyqRZa+uCvNgMJE/vOJr+V5+ekOd3EF wGjHXCj4HXwAqTGymXElqrJEKE5KmB/V4Jv1+2gbqahc5Cydh9nuJx+cHXAPgdDTEm3Q nJLtRC+lol89bmSbDB54Mxokys/nK1SU2IQ9upV4hZZNAKR2QK1770MiiIKNh62ntXub nwLL7hYoViVQqdGmGr72g3vEoxbY3rI/d1HdlhmOx3S4DuOxbZdtYpKVFtKeevn6TK1I B0rg== X-Gm-Message-State: AODbwcB3YPF03wYbH8l8sM5lN9uUT3bygh09anai1FunMtPYPRZkvYxh xkvw60XTqfhxLP7oX40yA18+UwsJKXmIWG4= X-Received: by 10.223.152.6 with SMTP id v6mr756661wrb.60.1495069450476; Wed, 17 May 2017 18:04:10 -0700 (PDT) MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.28.193.134 with HTTP; Wed, 17 May 2017 18:04:09 -0700 (PDT) In-Reply-To: References: From: Adrian Chadd Date: Wed, 17 May 2017 18:04:09 -0700 X-Google-Sender-Auth: vecR6FgiaCtiptN4C-DsGVWc31w Message-ID: Subject: Re: make concurrency kit a module To: freebsd-current , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 01:04:12 -0000 https://reviews.freebsd.org/D10778 -a On 17 May 2017 at 17:46, Adrian Chadd wrote: > hi, > > this is a quick change that makes concurrency_kit a module. Right now > the only thing using it is linuxkpi so it's all dead code on > non-linuxkpi platforms. > > > > -adrian From owner-freebsd-current@freebsd.org Thu May 18 05:53: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 B3E32D72F5A; Thu, 18 May 2017 05:53:53 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9446C153B; Thu, 18 May 2017 05:53:53 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by freefall.freebsd.org (Postfix, from userid 1235) id BEB001E4A; Thu, 18 May 2017 05:53:52 +0000 (UTC) Date: Thu, 18 May 2017 07:53:52 +0200 From: Baptiste Daroussin To: Adrian Chadd Cc: freebsd-current , "freebsd-arch@freebsd.org" Subject: Re: make concurrency kit a module Message-ID: <20170518055352.bflapm6mmfhgl4y4@ivaldir.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uymr6tqxazdnlunm" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170428 (1.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 05:53:53 -0000 --uymr6tqxazdnlunm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 17, 2017 at 06:04:09PM -0700, Adrian Chadd wrote: > https://reviews.freebsd.org/D10778 >=20 Except there are plans to use it elsewhere. Many areas may be improved usin= g it. Having it as a module would mean some devs might refrain from using it beca= use there is no waranty for it to be there Areas like VFS and network stack could have a good benefice from using it. Out of curiousity what size is saved? Bapt --uymr6tqxazdnlunm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAlkdNuUACgkQY4mL3PG3 PlrhBw//ULYy43sP+b/Tq+1cJ20UzEc0+V1B+CBMaLkjftS7tUy9kN7d6egzCAYC jSC3Yr0CiMkH2QwlVPYcSqWirxIeBp5ceGBFDOkAOHE0litUlusdYmm4id3LkiZO VNSWGFMEUMzdONKl6DmLfUds3HUtTIwQhC6qWtapq7yBw6a8jCrhcI2qpMoteaO6 0qWBDRMNTZTNL0I5QzgyxBZYUj+jlj1lP+z4BuQvL/oOIyjQpp/D7udtXALD69te vRN4D7ETycUWfZvzdYUUmxSMU8DzCyS2QHtbGTJPo1ecqlXM3T5tcSqWWUYNnB5u j1w/ymn53focH3sx1N1MOKEGAVqw8UTBjZWqx/D2w/2znyYGTB5nYwpv5VuY0FGs eYYpa6mpPP0etLXhsKlte388VoGxA6ilF/aRE8O/6sBsUwwO7pHhDvTPiatfCIwV nEG7UWTYt81i0UEyTM8sVewF/IZ0+y1OvfDDycJw4sTUi4oiZZIzO5zdraIK5wGX rC1LT1DqLHqzvik9GATFZHKwuQCuxvREjpjGIGh/Pfwr+4wXcAOd2mZXkjJoo5/g fWXA7pjfWzGAd3rhHrKcPgRdBRM3VFZEjTrDyyG+oDOljQY6QrI53Z1FGU2EZZ7F 3ZA/4RRqtSEy481ALeXUdiPrapZIoy5RpaB8ax068a32lWmYRW8= =aHG9 -----END PGP SIGNATURE----- --uymr6tqxazdnlunm-- From owner-freebsd-current@freebsd.org Thu May 18 06:37: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 08727D72F76 for ; Thu, 18 May 2017 06:37:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 C92801E01 for ; Thu, 18 May 2017 06:37:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22c.google.com with SMTP id p24so22917725ioi.0 for ; Wed, 17 May 2017 23:37:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=AKk4Tl1GkTLbvhAADMKYGgQPzA+4YXUx+Q/oqYkhew8=; b=eecAOJ4s1VyAnxiOBMpFArH8rFrseupBNJgIjUNk5u3HQXDR/AbYnBFQRrxNvVXnUS +30bDAMVqWE7SDnon91Xw4UR+CvTtHd4LdQo+EedJPlprRmx+dbr9w+UO4+CVvRvqf6o tqjRQf1wJcVICSEHwiJrxdhWwFa4pqxPXkWbvF56VmHLOWL/lpg088tvWoGOJifBFQvV ronTqFbEpdy4ITT4pR5MTa6JZCYQWxPhqbNoo2098l2AFGxPSmxt+/mAfOo4PRkvdUxA yCR0eF1FVm8dM5Rpqz4mdiWnqIJl/EnmtR/Ob8SUaEJqkeZoEJBjlazYxYAUlmkCk1yl zeZw== 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=AKk4Tl1GkTLbvhAADMKYGgQPzA+4YXUx+Q/oqYkhew8=; b=Y7zmNE73wJkfQ4Oy0wkHmi1K1NmCWxmrT7R2gGPN86zL4MUkwhHo3RIOd/b6tixdO4 D6p7zmBBre7MsG50y5c7SbCZ12pclz4g7hehX8lTwVv8+sNx+DZVMhGubeA911vC0cuq rYaVKJArg/g/Fet+ejDGr1iTzdnVFcnD4NTsRJ3h9J/t8QES9QP87XMbXVUgOg+luo+J MBB38ZpzJKgUMEOs234HuW8qAMQVTKhzqWl1UY9tVXASdPtZCVaNegquHPaAixnOaK7I Pk/bqpc52ZfdLwM25ihtvMhX3qRXKpcoWlDPYzNwCeSjXJMVDB7eSR+4Fj38Fpb9p7yK ob0A== X-Gm-Message-State: AODbwcDsSHsBUEXcbhy1nUAXoeYvo/X5GAsodcm91gjjhE2rFCZX8ck/ +9H/KK6KYifPT1/29L2FqMlPoXTOxpnv X-Received: by 10.107.188.132 with SMTP id m126mr3190458iof.148.1495089445063; Wed, 17 May 2017 23:37:25 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.126.6 with HTTP; Wed, 17 May 2017 23:37:24 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:cdd4:9b25:be09:9f7d] In-Reply-To: <20170518055352.bflapm6mmfhgl4y4@ivaldir.net> References: <20170518055352.bflapm6mmfhgl4y4@ivaldir.net> From: Warner Losh Date: Thu, 18 May 2017 00:37:24 -0600 X-Google-Sender-Auth: ayzyUdRe3l1S8tzHXH9yHZce0ME Message-ID: Subject: Re: make concurrency kit a module To: Baptiste Daroussin Cc: Adrian Chadd , freebsd-current , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 06:37:26 -0000 On Wed, May 17, 2017 at 11:53 PM, Baptiste Daroussin wrote: > On Wed, May 17, 2017 at 06:04:09PM -0700, Adrian Chadd wrote: >> https://reviews.freebsd.org/D10778 >> > > Except there are plans to use it elsewhere. Many areas may be improved using it. > > Having it as a module would mean some devs might refrain from using it because > there is no waranty for it to be there > > Areas like VFS and network stack could have a good benefice from using it. > > Out of curiousity what size is saved? I'd planned on using it newbus to solve the lifetime issues we have with device_t's.... Warner From owner-freebsd-current@freebsd.org Thu May 18 07:06: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 39A62D6C97D for ; Thu, 18 May 2017 07:06:20 +0000 (UTC) (envelope-from mueller6722@twc.com) Received: from dnvrco-oedge-vip.email.rr.com (dnvrco-outbound-snat.email.rr.com [107.14.73.225]) (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 1A6BA1D70 for ; Thu, 18 May 2017 07:06:19 +0000 (UTC) (envelope-from mueller6722@twc.com) Received: from [74.134.208.22] ([74.134.208.22:62875] helo=localhost) by dnvrco-omsmta01 (envelope-from ) (ecelerity 3.6.9.48312 r(Core:3.6.9.0)) with ESMTP id 63/BF-09002-3974D195; Thu, 18 May 2017 07:04:52 +0000 Date: Thu, 18 May 2017 07:04:51 +0000 Message-ID: <63.BF.09002.3974D195@dnvrco-omsmta01> From: "Thomas Mueller" To: freebsd-stable@freebsd.org CC: freebsd-current@freebsd.org Subject: Problem with re(4) Ethernet driver has resurfaced in 11-STABLE and HEAD 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: Thu, 18 May 2017 07:06:20 -0000 I recently updated my 10.1-STABLE to 11.0-STABLE and find I can no longer connect with the Ethernet. dhclient re0 produces DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 4 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 11 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 19 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 7 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 14 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 5 No DHCPOFFERS received. No working leases in persistent database - sleeping. uname -a shows FreeBSD amelia2 11.0-STABLE FreeBSD 11.0-STABLE #1 r317932: Mon May 8 23:23:37 UTC 2017 root@amelia2:/usr/obj/usr/src11/sys/SANDY11NC amd64 Relevant lines from /var/run/dmesg.boot are re0: port 0xe000-0xe0ff mem 0xf7d04000-0xf7d04fff,0xf7d00000-0xf7d03fff irq 17 at device 0.0 on pci2 re0: Using 1 MSI-X message re0: Chip rev. 0x2c800000 re0: MAC rev. 0x00100000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Using defaults for TSO: 65518/35/2048 re0: Ethernet address: d4:3d:7e:97:17:e2 re0: netmap queues/slots: TX 1/256, RX 1/256 Problem shows much quicker in my recent build of HEAD (12-current), where dhclient re0 gives just a couple lines screen output before crashing into debugger db> prompt Build host for 12-current installation was the recent build of 11.0-STABLE amd64. Kernel strings there show __page_fault.read __page_fault.write amd64 @(#)FreeBSD 12.0-CURRENT #1 r318262: Sun May 14 09:37:30 UTC 2017 FreeBSD 12.0-CURRENT #1 r318262: Sun May 14 09:37:30 UTC 2017 root@amelia4:/BETA1/usr/obj/BETA1/usr/src/sys/SANDY12NC FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) FreeBSD 12.0-CURRENT SANDY11NC It looks like I can connect to Internet with Hiro H50191 USB wireless adapter, driver rsu, but I am not sure of its stability on 11.0-STABLE and 12.0-current.. Tom From owner-freebsd-current@freebsd.org Thu May 18 13:44: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 1A09ED7321B; Thu, 18 May 2017 13:44:20 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [5.135.182.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AC0FE19F7; Thu, 18 May 2017 13:44:19 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=2001:41d0:8:bdbe:1:1::; helo=restart.be; envelope-from=hlh@restart.be; receiver=freebsd-arm@freebsd.org DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 3wTC8R0Gd4zrm2 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=restart.be; s=tignes; t=1495115047; bh=2RKZ6MKnZnJCKqlMebit5G0Cy1HwW4fNJ8vlVxK/GHo=; h=Subject:From:To:References:Date:In-Reply-To; z=Subject:=20Re:=20DTB=20provided=20by=20loader.efi=20from=20head=2 0-r317181=20on=20pine64=20smashed=0D=0A=20by=20zfs.ko=20?|From:=20 Henri=20Hennebert=20|To:=20freebsd-arm=20,=20freebsd-current@freebsd.org|References:=20<818 a6074-7d4b-a87e-d89e-ce1f4a30ff3c@restart.be>=0D=0A=20<6877ef26-1c 40-7883-70c4-5fbb37c4b3db@restart.be>|Date:=20Thu,=2018=20May=2020 17=2015:44:04=20+0200|In-Reply-To:=20<6877ef26-1c40-7883-70c4-5fbb 37c4b3db@restart.be>; b=dvo8+c1Bl5ClcoFtJU1zscMZ48kcgOoi14w2Qe0aIFyAjBllmA/yIH1MpoXcG7OM9 9IXyJ5F6VLb2evrdnUUbAM7diuo3FHHTQwCyorhVhjsal8M8b7EsrRqBAryFJYLYy3 dFBY3fbl23PajN6iYtobePSHRtc6q6kO7n5XUhopbSAd9v3FdigB29VUkrCmUeOSLL HisHCtVIYCpwnO3BC+E8U3YeT4DgE4oCVpbP3vjrJ6AEBJZezSznZYnByoaQ72Pf7L 0ZaC8poI4Wye/Kco97Vf1PatePp3BDcleqKROMLUfQQ22FkyVq8Qk4bq8hNk+mLICz BNkCX18D4SJ8A== Received: from restart.be (avoriaz.restart.be [IPv6:2001:41d0:8:bdbe:1:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3wTC8R0Gd4zrm2; Thu, 18 May 2017 15:44:05 +0200 (CEST) Received: from chamonix.restart.bel (chamonix.restart.bel [IPv6:2001:41d0:8:bdbe:1:9:0:0]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id v4IDi4TM079518 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 18 May 2017 15:44:04 +0200 (CEST) (envelope-from hlh@restart.be) Subject: Re: DTB provided by loader.efi from head -r317181 on pine64 smashed by zfs.ko ? From: Henri Hennebert To: freebsd-arm , freebsd-current@freebsd.org References: <818a6074-7d4b-a87e-d89e-ce1f4a30ff3c@restart.be> <6877ef26-1c40-7883-70c4-5fbb37c4b3db@restart.be> Message-ID: Date: Thu, 18 May 2017 15:44:04 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <6877ef26-1c40-7883-70c4-5fbb37c4b3db@restart.be> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr-classic 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, 18 May 2017 13:44:20 -0000 On 05/14/2017 19:46, Henri Hennebert wrote: > On 05/09/2017 12:07, Henri Hennebert wrote: >> Hello, >> >> I build current -r317181 with crochet for my PINE64. >> >> the kernel can boot with loader.conf.local: >> >> geom_mirror_load="YES" >> >> If I add to loader.conf.local: >> >> zfs_load="YES" >> >> or if I strike the space bar during loader.efi and I load zfs manually: >> >> OK load zfs >> ... >> OK boot > With a slimmed down kernel config, I can load zfs.ko and boot the kernel > BUT opensolaris is not loaded and I get at kernel boot: > > OK load zfs > /boot/kernel/zfs.ko text=0x9d980 text=0xe0480 data=0x214c8+0x9eb78 > syms=[0x8+0x1d6a0+0x8+0x187bd] If I load opensolaris manually, I can mount My root filesystem from zfs OK load opensolaris /boot/kernel/opensolaris.ko text=0x19d8 text=0xda0 data=0x10178+0x125b8 syms=[0x8+0x1020+0x8+0x8ca] OK boot -s Booting... Using DTB provided by EFI at 0x49000000. KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2017 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT #0 r317181M: Sun May 14 14:01:52 CEST 2017 root@norquay.restart.bel:/usr/obj/usr/src/sys/NORQUAY arm64 FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) VT: init without driver. Starting CPU 1 (1) Starting CPU 2 (2) Starting CPU 3 (3) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs random: unblocking device. random: entropy device external interface kbd0 at kbdmux0 ofwbus0: aw_ccu0: on ofwbus0 clk_fixed0: on aw_ccu0 clk_fixed1: on aw_ccu0 aw_pll0: mem 0x1c20000-0x1c20003 on aw_ccu0 aw_pll1: mem 0x1c20028-0x1c2002b on aw_ccu0 clk_fixed2: on aw_ccu0 aw_pll2: mem 0x1c2002c-0x1c2002f on aw_ccu0 aw_cpuclk0: mem 0x1c20050-0x1c20053 on aw_ccu0 aw_axiclk0: mem 0x1c20050-0x1c20053 on aw_ccu0 aw_ahbclk0: mem 0x1c20054-0x1c20057 on aw_ccu0 aw_ahbclk1: mem 0x1c2005c-0x1c2005f on aw_ccu0 aw_apbclk0: mem 0x1c20054-0x1c20057 on aw_ccu0 aw_apbclk1: mem 0x1c20058-0x1c2005b on aw_ccu0 aw_gate0: mem 0x1c20060-0x1c20073 on aw_ccu0 aw_modclk0: mem 0x1c20088-0x1c2008b on aw_ccu0 aw_modclk1: mem 0x1c2008c-0x1c2008f on aw_ccu0 aw_modclk2: mem 0x1c20090-0x1c20093 on aw_ccu0 aw_pll3: mem 0x1c20044-0x1c20047 on aw_ccu0 aw_usbclk0: mem 0x1c200cc-0x1c200cf on aw_ccu0 aw_thsclk0: mem 0x1c20074-0x1c20077 on aw_ccu0 simplebus0: on ofwbus0 aw_reset0: mem 0x1c202c0-0x1c202cb on simplebus0 aw_reset1: mem 0x1c202d0-0x1c202d3 on simplebus0 aw_reset2: mem 0x1c202d8-0x1c202db on simplebus0 regfix0: on simplebus0 psci0: on ofwbus0 aw_sid0: mem 0x1c14000-0x1c143ff on simplebus0 awusbphy0: mem 0x1c19400-0x1c19423,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on simplebus0 gic0: mem 0x1c81000-0x1c81fff,0x1c82000-0x1c83fff,0x1c84000-0x1c85fff,0x1c86000-0x1c87fff irq 0 0 gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 224 gpio0: mem 0x1c20800-0x1c20bff irq 8,9,10 on simplebus0 gpiobus0: on gpio0 aw_nmi0: mem 0x1f00c0c-0x1f00c43 irq 23 on simplebus0 generic_timer0: irq 1,2,3,4 on ofwbus0 Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 rtc0: mem 0x1f00000-0x1f00053 irq 16,17 on simplebus0 cpulist0: on ofwbus0 cpu0: on cpulist0 cpufreq_dt0: on cpu0 cpufreq_dt0: no regulator for cpu@0 device_attach: cpufreq_dt0 attach returned 6 cpu1: on cpulist0 cpu2: on cpulist0 cpu3: on cpulist0 a10_mmc0: mem 0x1c0f000-0x1c0ffff irq 5 on simplebus0 mmc0: on a10_mmc0 gpioc0: on gpio0 uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 11 on simplebus0 uart0: console (115384,n,8,1) awg0: mem 0x1c30000-0x1c300ff,0x1c00030-0x1c00033 irq 21 on simplebus0 miibus0: on awg0 rgephy0: PHY 0 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, w rgephy1: PHY 1 on miibus0 rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, w awg0: Ethernet address: 02:ba:4c:17:07:8b aw_wdog0: mem 0x1c20ca0-0x1c20cbf irq 22 on simplebus0 aw_thermal0: mem 0x1c25000-0x1c253ff irq 25 on simplebus0 ohci0: mem 0x1c1a400-0x1c1a4ff irq 26 on simplebus0 usbus0 on ohci0 ehci0: mem 0x1c1a000-0x1c1a0ff irq 27 on simplebus0 usbus1: EHCI version 1.0 usbus1 on ehci0 ohci1: mem 0x1c1b400-0x1c1b4ff irq 28 on simplebus0 usbus2 on ohci1 ehci1: mem 0x1c1b000-0x1c1b0ff irq 29 on simplebus0 usbus3: EHCI version 1.0 usbus3 on ehci1 cryptosoft0: cpufreq_dt0: on cpu0 cpufreq_dt0: no regulator for cpu@0 device_attach: cpufreq_dt0 attach returned 6 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Henri > OK boot > Booting... > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2017 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 12.0-CURRENT #0 r317181M: Sun May 14 14:01:52 CEST 2017 > root@norquay.restart.bel:/usr/obj/usr/src/sys/NORQUAY arm64 > FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on > LLVM 4.0.0) > VT: init without driver. > KLD file zfs.ko is missing dependencies > Starting CPU 1 (1) > Starting CPU 2 (2) > Starting CPU 3 (3) > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > random: unblocking device. > > > note the message: > KLD file zfs.ko is missing dependencies > >> >> the kernel don't boot and the console stay with the last line: >> >> Using DTB provided by EFI at 0x49000000. >> >> Moreover the opensolaris.ko is not loader. >> >> Maybe DTB is smashed by zfs.ko >> >> Any idea ? >> >> Henri >> >> PS with r312006M from RaspBSD all is OK and I can user zfs as root >> filesystem. >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Thu May 18 13:50: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 738D7D73452; Thu, 18 May 2017 13:50:38 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [5.135.182.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0FC4F1EA6; Thu, 18 May 2017 13:50:37 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=2001:41d0:8:bdbe:1:1::; helo=restart.be; envelope-from=hlh@restart.be; receiver=freebsd-arm@freebsd.org DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 3wTCHv1H6Mzrrf DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=restart.be; s=tignes; t=1495115435; bh=dWb8lEUihI18ZghJxEf+uxlbcSCeW+FId8tuKerYg5Q=; h=Subject:From:To:Cc:References:Date:In-Reply-To; z=Subject:=20Re:=20DTB=20provided=20by=20loader.efi=20from=20head=2 0-r317181=20on=20pine64=20smashed=0D=0A=20by=20zfs.ko=20?|From:=20 Henri=20Hennebert=20|To:=20freebsd-arm=20|Cc:=20freebsd-current=20|References:=20<818a6074-7d4b-a87e-d89e-ce1f4a30ff3c@restart.b e>=0D=0A=20<6877ef26-1c40-7883-70c4-5fbb37c4b3db@restart.be>|Date: =20Thu,=2018=20May=202017=2015:50:33=20+0200|In-Reply-To:=20<6877e f26-1c40-7883-70c4-5fbb37c4b3db@restart.be>; b=KaaSb2HYdqFoc1eYjVUHwN45uF3bD4uJroJRFk27Z6354C9mzI//ZWxBLJnnp7hVW LkXhyjXYh2KykO2tMQwk/SJN/gq/loe+6PYJXFsL9LDgy8VqxmJ3JBlEU1BF98+Tx2 3R5zmLba+umW/HJUIFs0dXyji9CcrOpoMexFfAMiHJOcRNYTI3gb+GmWZ31xNy6+a9 hf5hk8NqdvitBSIg1NUfDfYK87ByiU2iTOiS3uhKtc7+sQvJrbNFacD/XI4AiT9P62 dsCxjsu42/HIuepDpXMSNy7a4g7FlfLfi2A+FV2308wAEtf6sUHwTsAAIJEYH1qUGU sj75G5z0hmuLw== Received: from restart.be (avoriaz.restart.be [IPv6:2001:41d0:8:bdbe:1:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3wTCHv1H6Mzrrf; Thu, 18 May 2017 15:50:34 +0200 (CEST) Received: from chamonix.restart.bel (chamonix.restart.bel [IPv6:2001:41d0:8:bdbe:1:9:0:0]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id v4IDoXiO079953 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 18 May 2017 15:50:33 +0200 (CEST) (envelope-from hlh@restart.be) Subject: Re: DTB provided by loader.efi from head -r317181 on pine64 smashed by zfs.ko ? From: Henri Hennebert To: freebsd-arm Cc: freebsd-current References: <818a6074-7d4b-a87e-d89e-ce1f4a30ff3c@restart.be> <6877ef26-1c40-7883-70c4-5fbb37c4b3db@restart.be> Message-ID: <0ace532e-aca6-6144-f467-832dc04ba80b@restart.be> Date: Thu, 18 May 2017 15:50:33 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <6877ef26-1c40-7883-70c4-5fbb37c4b3db@restart.be> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr-classic 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, 18 May 2017 13:50:38 -0000 On 05/14/2017 19:46, Henri Hennebert wrote: > On 05/09/2017 12:07, Henri Hennebert wrote: >> Hello, >> >> I build current -r317181 with crochet for my PINE64. >> >> the kernel can boot with loader.conf.local: >> >> geom_mirror_load="YES" >> >> If I add to loader.conf.local: >> >> zfs_load="YES" >> >> or if I strike the space bar during loader.efi and I load zfs manually: >> >> OK load zfs If I load opensolaris manually, I can mount My root filesystem from zfs OK load opensolaris /boot/kernel/opensolaris.ko text=0x19d8 text=0xda0 data=0x10178+0x125b8 syms=[0x8+0x1020+0x8+0x8ca] OK boot -s Booting... Using DTB provided by EFI at 0x49000000. KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2017 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT #0 r317181M: Sun May 14 14:01:52 CEST 2017 root@norquay.restart.bel:/usr/obj/usr/src/sys/NORQUAY arm64 FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) VT: init without driver. Starting CPU 1 (1) Starting CPU 2 (2) Starting CPU 3 (3) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs random: unblocking device. random: entropy device external interface kbd0 at kbdmux0 ofwbus0: aw_ccu0: on ofwbus0 clk_fixed0: on aw_ccu0 clk_fixed1: on aw_ccu0 aw_pll0: mem 0x1c20000-0x1c20003 on aw_ccu0 aw_pll1: mem 0x1c20028-0x1c2002b on aw_ccu0 clk_fixed2: on aw_ccu0 aw_pll2: mem 0x1c2002c-0x1c2002f on aw_ccu0 aw_cpuclk0: mem 0x1c20050-0x1c20053 on aw_ccu0 aw_axiclk0: mem 0x1c20050-0x1c20053 on aw_ccu0 aw_ahbclk0: mem 0x1c20054-0x1c20057 on aw_ccu0 aw_ahbclk1: mem 0x1c2005c-0x1c2005f on aw_ccu0 aw_apbclk0: mem 0x1c20054-0x1c20057 on aw_ccu0 aw_apbclk1: mem 0x1c20058-0x1c2005b on aw_ccu0 aw_gate0: mem 0x1c20060-0x1c20073 on aw_ccu0 aw_modclk0: mem 0x1c20088-0x1c2008b on aw_ccu0 aw_modclk1: mem 0x1c2008c-0x1c2008f on aw_ccu0 aw_modclk2: mem 0x1c20090-0x1c20093 on aw_ccu0 aw_pll3: mem 0x1c20044-0x1c20047 on aw_ccu0 aw_usbclk0: mem 0x1c200cc-0x1c200cf on aw_ccu0 aw_thsclk0: mem 0x1c20074-0x1c20077 on aw_ccu0 simplebus0: on ofwbus0 aw_reset0: mem 0x1c202c0-0x1c202cb on simplebus0 aw_reset1: mem 0x1c202d0-0x1c202d3 on simplebus0 aw_reset2: mem 0x1c202d8-0x1c202db on simplebus0 regfix0: on simplebus0 psci0: on ofwbus0 aw_sid0: mem 0x1c14000-0x1c143ff on simplebus0 awusbphy0: mem 0x1c19400-0x1c19423,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on simplebus0 gic0: mem 0x1c81000-0x1c81fff,0x1c82000-0x1c83fff,0x1c84000-0x1c85fff,0x1c86000-0x1c87fff irq 0 0 gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 224 gpio0: mem 0x1c20800-0x1c20bff irq 8,9,10 on simplebus0 gpiobus0: on gpio0 aw_nmi0: mem 0x1f00c0c-0x1f00c43 irq 23 on simplebus0 generic_timer0: irq 1,2,3,4 on ofwbus0 Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 rtc0: mem 0x1f00000-0x1f00053 irq 16,17 on simplebus0 cpulist0: on ofwbus0 cpu0: on cpulist0 cpufreq_dt0: on cpu0 cpufreq_dt0: no regulator for cpu@0 device_attach: cpufreq_dt0 attach returned 6 cpu1: on cpulist0 cpu2: on cpulist0 cpu3: on cpulist0 a10_mmc0: mem 0x1c0f000-0x1c0ffff irq 5 on simplebus0 mmc0: on a10_mmc0 gpioc0: on gpio0 uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 11 on simplebus0 uart0: console (115384,n,8,1) awg0: mem 0x1c30000-0x1c300ff,0x1c00030-0x1c00033 irq 21 on simplebus0 miibus0: on awg0 rgephy0: PHY 0 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, w rgephy1: PHY 1 on miibus0 rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, w awg0: Ethernet address: 02:ba:4c:17:07:8b aw_wdog0: mem 0x1c20ca0-0x1c20cbf irq 22 on simplebus0 aw_thermal0: mem 0x1c25000-0x1c253ff irq 25 on simplebus0 ohci0: mem 0x1c1a400-0x1c1a4ff irq 26 on simplebus0 usbus0 on ohci0 ehci0: mem 0x1c1a000-0x1c1a0ff irq 27 on simplebus0 usbus1: EHCI version 1.0 usbus1 on ehci0 ohci1: mem 0x1c1b400-0x1c1b4ff irq 28 on simplebus0 usbus2 on ohci1 ehci1: mem 0x1c1b000-0x1c1b0ff irq 29 on simplebus0 usbus3: EHCI version 1.0 usbus3 on ehci1 cryptosoft0: cpufreq_dt0: on cpu0 cpufreq_dt0: no regulator for cpu@0 device_attach: cpufreq_dt0 attach returned 6 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) ZFS is running before the root filesystem is mounted! Henri >> ... >> OK boot > With a slimmed down kernel config, I can load zfs.ko and boot the kernel > BUT opensolaris is not loaded and I get at kernel boot: > > OK load zfs > /boot/kernel/zfs.ko text=0x9d980 text=0xe0480 data=0x214c8+0x9eb78 > syms=[0x8+0x1d6a0+0x8+0x187bd] > OK boot > Booting... > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2017 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 12.0-CURRENT #0 r317181M: Sun May 14 14:01:52 CEST 2017 > root@norquay.restart.bel:/usr/obj/usr/src/sys/NORQUAY arm64 > FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on > LLVM 4.0.0) > VT: init without driver. > KLD file zfs.ko is missing dependencies > Starting CPU 1 (1) > Starting CPU 2 (2) > Starting CPU 3 (3) > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > random: unblocking device. > > > note the message: > KLD file zfs.ko is missing dependencies > >> >> the kernel don't boot and the console stay with the last line: >> >> Using DTB provided by EFI at 0x49000000. >> >> Moreover the opensolaris.ko is not loader. >> >> Maybe DTB is smashed by zfs.ko >> >> Any idea ? >> >> Henri >> >> PS with r312006M from RaspBSD all is OK and I can user zfs as root >> filesystem. >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Fri May 19 02:28: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 48457D74C53 for ; Fri, 19 May 2017 02:28:24 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 286CDF28 for ; Fri, 19 May 2017 02:28:24 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (125-209-146-2.dyn.iinet.net.au [125.209.146.2]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v4J2SJ6i069517 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 18 May 2017 19:28:22 -0700 (PDT) (envelope-from julian@freebsd.org) To: freebsd-current From: Julian Elischer Subject: Ssh.. can we please have HPN back? Message-ID: <65e88d85-ca38-26dc-fe0a-910db11d470b@freebsd.org> Date: Fri, 19 May 2017 10:28:13 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; 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: Fri, 19 May 2017 02:28:24 -0000 So after stripping out the HPN version of ssh from our product becasue "it was no longer needed" we dicovered that we were premature in doing so. Apparently ssh still really needs HPN to get any throughput at all when there are latencies involved. For example, with HPN we get 13MB/sec between the Azure US west Data center and the Azure East data center.But the standard ssh in 10.3 (with HPN stripped out) can barely manage 2MB/sec transfers. I did ask at the time whether it was proved that the new ssh didn't require the HPN changes, and was assured, "no" but it would appear that the picture isn't as clear. tht seems silly to have to import the port when we have what would otherwise be a perfectly good ssh as part of hte system, and it's really annoying having to specify /usr/local/bin/scp or /usr/local/bin/ssh in every script. So can we please have the latest version of the HPN changes back in the default system please? It seem rather odd that the upstream openssh has had this problem for SO LONG and not fixed it. Julian From owner-freebsd-current@freebsd.org Fri May 19 04:01: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 EA82FD72088 for ; Fri, 19 May 2017 04:01:45 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B94851E12; Fri, 19 May 2017 04:01:45 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v4J41fKH069452; Thu, 18 May 2017 21:01:42 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v4J41fL5069451; Thu, 18 May 2017 21:01:41 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201705190401.v4J41fL5069451@pdx.rh.CN85.dnsmgr.net> Subject: Re: Ssh.. can we please have HPN back? In-Reply-To: <65e88d85-ca38-26dc-fe0a-910db11d470b@freebsd.org> To: Julian Elischer Date: Thu, 18 May 2017 21:01:41 -0700 (PDT) CC: freebsd-current X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Fri, 19 May 2017 10:56:41 +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, 19 May 2017 04:01:46 -0000 > So after stripping out the HPN version of ssh from our product becasue > "it was no longer needed" we dicovered that we were premature in doing so. > Apparently ssh still really needs HPN to get any throughput at all when > there are latencies involved. > > > For example, with HPN we get 13MB/sec between the Azure US west > Data center and the Azure East data center.But the standard ssh in 10.3 > (with HPN stripped out) can barely manage 2MB/sec transfers. > > I did ask at the time whether it was proved that the new ssh didn't > require the HPN changes, > and was assured, "no" but it would appear that the picture isn't as clear. > tht seems silly to have to import the port when we have what would > otherwise be a > perfectly good ssh as part of hte system, and it's really annoying > having to specify > /usr/local/bin/scp or /usr/local/bin/ssh in every script. > > So can we please have the latest version of the HPN changes back in > the default system please? > It seem rather odd that the upstream openssh has had this problem for > SO LONG and not fixed it. Allan Jude has recently done a bunch of work on this though I do not know its current status of being either upstreamed (I know some of it well not be accepted from conversations with Allan) or commited to the tree. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Fri May 19 11:43: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 5DF70D74B18; Fri, 19 May 2017 11:43:41 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::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 19C8D126A; Fri, 19 May 2017 11:43:37 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 7BB882615C0; Fri, 19 May 2017 13:43:34 +0200 (CEST) Subject: [CFT] New version of webcamd, now v4.12.0.1 From: Hans Petter Selasky To: FreeBSD Current , "freebsd-multimedia@freebsd.org" , "freebsd-x11@FreeBSD.org" References: Message-ID: <0b090565-51d0-8ff1-488e-f1d568bcb9c1@selasky.org> Date: Fri, 19 May 2017 13:41:36 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed 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: Fri, 19 May 2017 11:43:41 -0000 Hi, If you are using webcamd, please help test the latest version which includes the most recent Linux v4.12-rc1 media tree sources. The latest webcamd port is available from here: svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b/trunk/ports/multimedia/webcamd Please test and report any regression issues to me or freebsd-multimedia@freebsd.org Changes: - updated all Linux kernel sources to the latest Linux' Torvalds - fixed a minor I2C related bug in the webcamd Linux kernel emulation - improved Linux kernel emulation support Related work: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196678 --HPS From owner-freebsd-current@freebsd.org Fri May 19 15:04:19 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 AADD5D73591 for ; Fri, 19 May 2017 15:04:19 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (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 7E0EDD9F for ; Fri, 19 May 2017 15:04:19 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id D15D413EEE for ; Fri, 19 May 2017 15:04:11 +0000 (UTC) Subject: Re: Ssh.. can we please have HPN back? To: freebsd-current@freebsd.org References: <201705190401.v4J41fL5069451@pdx.rh.CN85.dnsmgr.net> From: Allan Jude Message-ID: Date: Fri, 19 May 2017 11:03:59 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <201705190401.v4J41fL5069451@pdx.rh.CN85.dnsmgr.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="df1CVOKdiclfIr689J2QeNvPwA5J8S11o" 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, 19 May 2017 15:04:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --df1CVOKdiclfIr689J2QeNvPwA5J8S11o Content-Type: multipart/mixed; boundary="k4csHIEQXvUld1e9I0BWwml6MwlVd886k"; protected-headers="v1" From: Allan Jude To: freebsd-current@freebsd.org Message-ID: Subject: Re: Ssh.. can we please have HPN back? References: <201705190401.v4J41fL5069451@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201705190401.v4J41fL5069451@pdx.rh.CN85.dnsmgr.net> --k4csHIEQXvUld1e9I0BWwml6MwlVd886k Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2017-05-19 00:01, Rodney W. Grimes wrote: >> So after stripping out the HPN version of ssh from our product becasue= >> "it was no longer needed" we dicovered that we were premature in doing= so. >> Apparently ssh still really needs HPN to get any throughput at all whe= n >> there are latencies involved. >> >> >> For example, with HPN we get 13MB/sec between the Azure US west >> Data center and the Azure East data center.But the standard ssh in 10.= 3 >> (with HPN stripped out) can barely manage 2MB/sec transfers. >> >> I did ask at the time whether it was proved that the new ssh didn't=20 >> require the HPN changes, >> and was assured, "no" but it would appear that the picture isn't as cl= ear. >> tht seems silly to have to import the port when we have what would=20 >> otherwise be a >> perfectly good ssh as part of hte system, and it's really annoying=20 >> having to specify >> /usr/local/bin/scp or /usr/local/bin/ssh in every script. >> >> So can we please have the latest version of the HPN changes back in=20 >> the default system please? >> It seem rather odd that the upstream openssh has had this problem for = >> SO LONG and not fixed it. >=20 > Allan Jude has recently done a bunch of work on this though I do > not know its current status of being either upstreamed (I know > some of it well not be accepted from conversations with Allan) > or commited to the tree. >=20 I hope to have the most important part of the patch rebased on the latest upstream version of OpenSSH by the end of this weekend. The versions I built and benchmarked for AsiaBSDCon were based on the HPN patched openssh-portable from ports, but I think the change required to actually make ssh not suck will only be a few lines, and will be acceptable by upstream. The big issue is in the channel_check_window() The condition for growing the SSH window is if we have received 3 times the max packet size. For some reason this constant small growth of the SSH window never lets the TCP socket buffer grow. This behaviour was added in OpenSSH 4.7 (Jun 2007), and makes sense for interactive ssh sessions. More detail in my paper, see the 'Broken Windows' chapter: http://allanjude.com/bsd/AsiaBSDCon2017_-_SSH_Performance.pdf Anyway, my fix was to only allow that condition to result in moving the SSH window forward if packet_is_interactive(). In the bulk transfer case, it falls back to using the other (original) condition of 'half of the local window max has been consumed'. The other condition is a modified version of one of the HPN patches. We do a getsockopt SO_RCVBUF to check the size of the tcp socket buffer, and if the remaining part of the SSH window has fall below the size of the socket buffer, we grow the SSH window by 150%, up to SSHBUF_SIZE_MAX https://github.com/rapier1/openssh-portable/compare/master...allanjude:dy= namic_window_fix.diff I just need to rejigger it a bit so it doesn't depend on the HPN support functions and becomes an independent patch. Figure 3 and Figure 4 show what difference HPN makes when you add latency, but also show without my patch, HPN only solves the recv case, not the send case. --=20 Allan Jude --k4csHIEQXvUld1e9I0BWwml6MwlVd886k-- --df1CVOKdiclfIr689J2QeNvPwA5J8S11o Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJZHwlrAAoJEBmVNT4SmAt+i68QAMZmEEs3c3R5yg+QihxrGJjX OcOjYOJGriyuKU/7PJNebalP4q/YRvuHG1KvMbijq1dX52c/YXWSnZXOuWY44lI8 9nhxXam/GTClHPD+PX9NJuUs5JlcxX+cYO38QFV9t2tmrkBsgKLyYRaVdTcBQbsb UWHutsWBi+h/zoXAY8VGU7SD0XS1MkZpXVELbK+fLrNZzneIhnwAAMWlUL9edk2k zCYBnOJF04nD5bnUAMJqNV1hWhuPAmei67C4YYu4+e6728seb7gAkgOp0isUlR5U PJce/wKdCzY/L1HC76tbo+/9V3d734n/Kfl5Grjj9rDgadUrf7N2erSoMxNFAWyR LwB1Sl7LbSPHZDaLBfZPzYfS81zeVfBAvUclyuz87KTr+9L0K6URErOvTa1MBC3U ncs7gw2A/9Panfn3764Ou2FUUE1kHE1J4wc62rlFIewcdT5JRpr0KZf5UESjXIgU aZy0/8Zpz1TVP8j/qIWq0WYBFzeIvjLQD7LhSr3yfZ0pW/4W9zisjncISXnKpUuz zYHUDe2ys6A1Bqyx10gK2A3XW2zdOpZ10hrY62g/ROVvieWU7f0owF4b7OTUnJ0S H4XCiy+1IFjVoBD0Z/BP7wkiP0PZQ+cCSOO4XooG45rl6Q0pT16pkpi0sVq0h5tz uzV2VepkWoPCXAj4s74X =q3xB -----END PGP SIGNATURE----- --df1CVOKdiclfIr689J2QeNvPwA5J8S11o-- From owner-freebsd-current@freebsd.org Fri May 19 15:34:33 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 7081FD73F05; Fri, 19 May 2017 15:34:33 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wr0-x244.google.com (mail-wr0-x244.google.com [IPv6:2a00:1450:400c:c0c::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 EE9AD1CE5; Fri, 19 May 2017 15:34:32 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wr0-x244.google.com with SMTP id v42so3313197wrc.3; Fri, 19 May 2017 08:34:32 -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=qTPSeb6VJikBzJZt6MVUfYj6q5Ij10UcnZd+0Aefra4=; b=Cd+hy7SzpRLOvcEYylp1wltqgEAP1iSkPN9WtUO1yp/4M8sz9RkdSc75xZdSn+T0Jf yWRDXktGl8vob8bISReEpbpucQG+jWHGG61q9mkmokQb4UG0ek0Jm/daPWrgbQRaLYC4 sZw6iIVUd7ek4+hYi7EtQkG1xJUz6JAEplyU1JllG1mTw0nsoTvRHgQnzoWmhi72Ku6+ CozD3TC83vTYpetkqM1gQ8e3Z7ZKebK3STQrWm7Kbyi+Qnwbf/Z7KH+M+rsQHZGJF6DJ i2AFdoTEnFoL97fEpIa8MbKBtBRAkG7EiC7H/R87iqurgOfiYJzr4CQkD5WyyuWFTeLt CN1w== 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=qTPSeb6VJikBzJZt6MVUfYj6q5Ij10UcnZd+0Aefra4=; b=nt90J3lQjl0XY5NgzItlO5NCC6Inzwmo4BmqniOSP3FWH2KqVVrxXp6Q8K6laMBQL7 Asv0klmckYGFxAG4rcy9tYs/P67CiG3qiEdjVT2e9xi84TKaCWxgE195rh0eOqccRuYs BBekJxOfDYPgQWEMuIQukvB2yV1zquQxTn2bqqQD8PFW5Gwg9FSBCvMEJ3PEiLjS6PQ1 mGQEBVfTT3r2gSYrfDhqHdyUcZcDAJMjVritzgOM2nn76vl+iO98aYLZwtVvHdE29cHh UxXjYArQmY8T2BpgA49+kWPUE0MIi1BUm9dNeLcvitId5VW9TFCtDSscZnnFO7oVN18s kU1g== X-Gm-Message-State: AODbwcBPRwJaa4Nx8zpBeOPTnpbkm1Fp2BJzM2fJZVt2xc/ffRqrPqbd fYjdMLh4/rekFN9EUrxNrs/k6cJ1oA== X-Received: by 10.223.152.6 with SMTP id v6mr3369123wrb.60.1495208071402; Fri, 19 May 2017 08:34:31 -0700 (PDT) MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.28.193.134 with HTTP; Fri, 19 May 2017 08:34:30 -0700 (PDT) In-Reply-To: References: <20170518055352.bflapm6mmfhgl4y4@ivaldir.net> From: Adrian Chadd Date: Fri, 19 May 2017 08:34:30 -0700 X-Google-Sender-Auth: nhkRr2IcIG19ygdWsTbGPiWnkFg Message-ID: Subject: Re: make concurrency kit a module To: Warner Losh Cc: Baptiste Daroussin , freebsd-current , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 15:34:33 -0000 On 17 May 2017 at 23:37, Warner Losh wrote: > On Wed, May 17, 2017 at 11:53 PM, Baptiste Daroussin wrote: >> On Wed, May 17, 2017 at 06:04:09PM -0700, Adrian Chadd wrote: >>> https://reviews.freebsd.org/D10778 >>> >> >> Except there are plans to use it elsewhere. Many areas may be improved using it. >> >> Having it as a module would mean some devs might refrain from using it because >> there is no waranty for it to be there >> >> Areas like VFS and network stack could have a good benefice from using it. >> >> Out of curiousity what size is saved? > > I'd planned on using it newbus to solve the lifetime issues we have > with device_t's.... I'm happy with things using it in base outside of the linuxkpi. I'm just trying to push back on the "death by a thousand cuts" that the IOT platforms face for size constraints. There's plenty of stuff in the base kernel that storage challenged platforms don't need but they're not introduced or kept as modules. It's 2017 and people /are still/ making embedded boards with 8MB of NOR flash. -adrian From owner-freebsd-current@freebsd.org Fri May 19 17:27:37 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 C8EDAD73579; Fri, 19 May 2017 17:27:37 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 917821647; Fri, 19 May 2017 17:27:36 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id F042D2615C0; Fri, 19 May 2017 19:27:33 +0200 (CEST) Subject: Re: make concurrency kit a module To: Adrian Chadd , Warner Losh Cc: Baptiste Daroussin , freebsd-current , "freebsd-arch@freebsd.org" References: <20170518055352.bflapm6mmfhgl4y4@ivaldir.net> From: Hans Petter Selasky Message-ID: <3c4c6496-9a80-a45b-b3a1-9cdfb094c0a2@selasky.org> Date: Fri, 19 May 2017 19:25:34 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed 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: Fri, 19 May 2017 17:27:37 -0000 On 05/19/17 17:34, Adrian Chadd wrote: > On 17 May 2017 at 23:37, Warner Losh wrote: >> On Wed, May 17, 2017 at 11:53 PM, Baptiste Daroussin wrote: >>> On Wed, May 17, 2017 at 06:04:09PM -0700, Adrian Chadd wrote: >>>> https://reviews.freebsd.org/D10778 >>>> >>> >>> Except there are plans to use it elsewhere. Many areas may be improved using it. >>> >>> Having it as a module would mean some devs might refrain from using it because >>> there is no waranty for it to be there >>> >>> Areas like VFS and network stack could have a good benefice from using it. >>> >>> Out of curiousity what size is saved? >> >> I'd planned on using it newbus to solve the lifetime issues we have >> with device_t's.... > > I'm happy with things using it in base outside of the linuxkpi. > > I'm just trying to push back on the "death by a thousand cuts" that > the IOT platforms face for size constraints. There's plenty of stuff > in the base kernel that storage challenged platforms don't need but > they're not introduced or kept as modules. > > It's 2017 and people /are still/ making embedded boards with 8MB of NOR flash. Hi, Please make sure that the CK can still be built as part of the kernel, if you plan to make it a module by default. --HPS From owner-freebsd-current@freebsd.org Sat May 20 00:07: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 908AED75909; Sat, 20 May 2017 00:07:54 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 74221FD4; Sat, 20 May 2017 00:07:54 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v4K07lce026869 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 19 May 2017 17:07:47 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v4K07lg2026868; Fri, 19 May 2017 17:07:47 -0700 (PDT) (envelope-from sgk) Date: Fri, 19 May 2017 17:07:47 -0700 From: Steve Kargl To: freebsd-current@freebsd.org, freebsd-toolchain@freebsd.org Subject: cpp behavior? Message-ID: <20170520000747.GA26861@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2017 00:07:54 -0000 % which cpp /usr/bin/cpp troutmask:kargl[408] cpp --version FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) Target: x86_64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin troutmask:kargl[409] cpp --help |grep trad -traditional-cpp Enable some traditional CPP emulation troutmask:kargl[410] cpp -traditional-cpp boxmuller.F90 cpp: error: unable to execute command: Executable "gcc" doesn't exist! OK, so what is the preprocessor for clang? -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-current@freebsd.org Sat May 20 03:02:22 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 8D586D75DC3 for ; Sat, 20 May 2017 03:02:22 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7A7541184 for ; Sat, 20 May 2017 03:02:22 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: by mailman.ysv.freebsd.org (Postfix) id 79C8BD75DBF; Sat, 20 May 2017 03:02:22 +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 79461D75DBE; Sat, 20 May 2017 03:02:22 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail5.asahi-net.or.jp (mail5.asahi-net.or.jp [202.224.39.201]) by mx1.freebsd.org (Postfix) with ESMTP id 559451183; Sat, 20 May 2017 03:02:21 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from localhost (pool-71-172-4-245.nwrknj.fios.verizon.net [71.172.4.245]) (Authenticated sender: NR2Y-OOT) by mail5.asahi-net.or.jp (Postfix) with ESMTPSA id 402BC11990D; Sat, 20 May 2017 11:56:41 +0900 (JST) Date: Fri, 19 May 2017 22:55:30 -0400 From: Yoshihiro Ota To: stable@freebsd.org Cc: current@freebsd.org, net@freebsd.org Subject: ndis wireless on 11.0-RELESE has been broken and its patch Message-Id: <20170519225530.92dddbb2b18dddbcae5c9f5f@j.email.ne.jp> In-Reply-To: <20170103234048.3e77722e1728a3666377f829@j.email.ne.jp> References: <20150731121226.GJ889@FreeBSD.org> <20170103234048.3e77722e1728a3666377f829@j.email.ne.jp> X-Mailer: Sylpheed 3.4.3 (GTK+ 2.24.29; i386-portbld-freebsd10.1) 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: Sat, 20 May 2017 03:02:22 -0000 Hi, I've been chasing a NDIS wireless bug for a while as I realized network stopped working on some of hardware. I have its PR and also attached a patch. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213237 It will be nice if someone can follow up so that we can have 11.1-RELEASE NDIS wireless working. Regards, Hiro On Tue, 3 Jan 2017 23:40:48 -0500 Yoshihiro Ota wrote: > Hi Gleb, > > Are you still accepting a bug report on this? > I have a laptop that I need to use NDIS driver. > This change impacted and causes kernel panic. > I haven't used this laptop for a quite while and > didn't realize it had stopped working. > > When I setup a wlan0 device with NDIS in wepmode, > "ifconfig wlan0 up" causes kernel memory currupption > and causes next ioctl/sysctl access programs such > as "ps" and "sysctl -a" crash the kernel. > > Regards, > Hiro > > On Fri, 31 Jul 2015 15:12:26 +0300 > Gleb Smirnoff wrote: > > > Hi! > > > > I need to make couple of non-functional but rather large changes > > to the if_ndis driver and will appreciate if anyone signs up to > > test my changes. Please contact me if you can provide help. > > > > -- > > Totus tuus, Glebius. > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > _______________________________________________ > 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 Sat May 20 04:48: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 13628D74E7A for ; Sat, 20 May 2017 04:48:53 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-10.reflexion.net [208.70.210.10]) (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 BA8011C7F for ; Sat, 20 May 2017 04:48:52 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19142 invoked from network); 20 May 2017 04:42:11 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 20 May 2017 04:42:11 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sat, 20 May 2017 00:42:11 -0400 (EDT) Received: (qmail 30179 invoked from network); 20 May 2017 04:42:11 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 20 May 2017 04:42:11 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 5C899EC86B0; Fri, 19 May 2017 21:42:10 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: TARGET_ARCH=powerpc head -r317820 production-style kernel: periodic panics always in pid=11 (the Idle threads) From: Mark Millard In-Reply-To: <831804AB-1BEB-40C7-BA8B-94DF07E314E5@dsl-only.net> Date: Fri, 19 May 2017 21:42:08 -0700 Cc: FreeBSD PowerPC ML , FreeBSD Current Content-Transfer-Encoding: 7bit Message-Id: <1F50B6D9-4E41-4367-860D-E2A0E13AE661@dsl-only.net> References: <831804AB-1BEB-40C7-BA8B-94DF07E314E5@dsl-only.net> To: Justin Hibbits , Nathan Whitehorn 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, 20 May 2017 04:48:53 -0000 On 2017-May-9, at 2:00 PM, Mark Millard wrote: . . . > fatal kernel trap: > exception = 0x903a64e (unknown) > srr0 = 0x7ff760 > srr1 = 0xc1007c > lr = 0x907f > curthread = 0x147d6c0 > pid = 11, comm = idle: cpu0 > [ thread pid 11 tid 100003 ] > Stopped at ffs_truncate+0x1080: stw r11, 0xf8(r31) > > 1 contains (cpu1 instead of cpu0, so different tid): > > fatal kernel trap: > exception = 0x903a64e (unknown) > srr0 = 0x7ff760 > srr1 = 0xc1007c > lr = 0x907f > curthread = 0x147d360 > pid = 11, comm = idle: cpu1 > [ thread pid 11 tid 100004 ] > Stopped at ffs_truncate+0x1080: stw r11, 0xf8(r31) > > 1 contains: I've discovered where to find the trapframe in the vmcore.* files for these specific examples with 0x903a64e as the exception and such. In the vmcore the memory image starts at byte offset 0x1000. To see the values reported the only place in the image file to start that produces those values at the offsets for in side the powerpc trapframe is: offset 0x1001 in the vmcore.* file. So memory address 0x1 is being used as the trapframe address when that odd exception information is being displayed. Yep: misaligned. The decoding is not of the actual trapframe: it is garbage that is not to be believed. Note: I lucked out after the above and got a somewhat different odd trap information that lead to actually getting a backtrace that included the actual pid 11 cpu 1 kernel thread stack bt associated with that odd information display. I'll send a separate reply for that information as it will take some transcribing from camera pictures and such. === Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sat May 20 09:01: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 9AF74D752E0 for ; Sat, 20 May 2017 09:01:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-10.reflexion.net [208.70.210.10]) (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 60DDA10AC for ; Sat, 20 May 2017 09:01:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 8520 invoked from network); 20 May 2017 09:01:57 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 20 May 2017 09:01:57 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sat, 20 May 2017 05:01:57 -0400 (EDT) Received: (qmail 23378 invoked from network); 20 May 2017 09:01:57 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 20 May 2017 09:01:57 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 5EA73EC81B0; Sat, 20 May 2017 02:01:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: TARGET_ARCH=powerpc head -r317820 production-style kernel: periodic panics always in pid=11 (the Idle threads) From: Mark Millard In-Reply-To: <1F50B6D9-4E41-4367-860D-E2A0E13AE661@dsl-only.net> Date: Sat, 20 May 2017 02:01:55 -0700 Cc: FreeBSD PowerPC ML , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <81F7A2D8-4C3A-426D-B957-9DC937006D88@dsl-only.net> References: <831804AB-1BEB-40C7-BA8B-94DF07E314E5@dsl-only.net> <1F50B6D9-4E41-4367-860D-E2A0E13AE661@dsl-only.net> To: Justin Hibbits , Nathan Whitehorn 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, 20 May 2017 09:01:59 -0000 On 2017-May-19, at 9:42 PM, Mark Millard wrote: > On 2017-May-9, at 2:00 PM, Mark Millard wrote: >=20 > . . . >> fatal kernel trap: >> exception =3D 0x903a64e (unknown) >> srr0 =3D 0x7ff760 >> srr1 =3D 0xc1007c >> lr =3D 0x907f >> curthread =3D 0x147d6c0 >> pid =3D 11, comm =3D idle: cpu0 >> [ thread pid 11 tid 100003 ] >> Stopped at ffs_truncate+0x1080: stw r11, 0xf8(r31) >>=20 >> 1 contains (cpu1 instead of cpu0, so different tid): >>=20 >> fatal kernel trap: >> exception =3D 0x903a64e (unknown) >> srr0 =3D 0x7ff760 >> srr1 =3D 0xc1007c >> lr =3D 0x907f >> curthread =3D 0x147d360 >> pid =3D 11, comm =3D idle: cpu1 >> [ thread pid 11 tid 100004 ] >> Stopped at ffs_truncate+0x1080: stw r11, 0xf8(r31) >>=20 >> 1 contains: >=20 > I've discovered where to find the trapframe > in the vmcore.* files for these specific > examples with 0x903a64e as the exception > and such. >=20 > In the vmcore the memory image starts at > byte offset 0x1000. >=20 > To see the values reported the only > place in the image file to start that > produces those values at the offsets > for in side the powerpc trapframe is: >=20 > offset 0x1001 in the vmcore.* file. >=20 > So memory address 0x1 is being used > as the trapframe address when that > odd exception information is being > displayed. Yep: misaligned. >=20 > The decoding is not of the actual > trapframe: it is garbage that is > not to be believed. >=20 >=20 > Note: I lucked out after the above and > got a somewhat different odd trap information > that lead to actually getting a backtrace > that included the actual pid 11 cpu 1 kernel > thread stack bt associated with that odd > information display. Typo: That should have been "cpu 2". > I'll send a separate reply for that information > as it will take some transcribing from camera > pictures and such. As indicated, I got a different odd trap report that gave a backtrace. . . fatal user trap exception =3D 0x4210000 (unknown) srr0 =3D 0xc1007c09 srr1 =3D 0x3a64e80 lr =3D 0xc0807fc9 curthread =3D 0x147d000 pid =3D 11, comm =3D idle: cpu 2 Now at this point it attempted to db_print_loc_and_inst and got another exception (at offset +0x60 in the routine). So the backtrace has both the consequences of that and what lead up to that: an EXI trap was attempting to report trap frame information but was using a bad address for the supposed frame. The details of the backtrace: panic: data storage interrupt trap cpuid =3D 2 time =3D 145187154 KDB: stack backtrace 0xdf5ef2c0: at kdb_backtrace+0x5c 0xdf5ef3a0: at panic+0x54 0xdf5ef3f0: at trap_fatal+0x1cc 0xdf5ef420: at powerpc_interrupt+0x180 0xdf5ef5c0: kernel DSI read trap @ 0xc1007c09 by db_disasm+0x30: srr1=3D0x1032 r1 =3D0xdf5ef6b0 cr =3D0x24009022 xer =3D0 ctr =3D0x1852cc sr =3D0x40000000 0xdf5ef6b0: at 0x1007480 0xdf5ef6d0: at db_print_loc_and_inst+0x60 0xdf5ef700: at db_trap+0x104 0xdf5ef790: at kdb_trap+0x1bc 0xdf5ef810: at trap_fatal+0x1b0 0xdf5ef840: at trap+0x1184 0xdf5ef870: kernel EXI trap by cpu_idle_60x+0x88: srr1=3D0x1032 r1 =3D0xdf5ef930 cr =3D0x40000042 xer =3D0x20000000 ctr =3D0x8e3bd8 saved LR(0x2) is invalid. So an EXI trap was attempting to report a trap frame. (Note: the LR's for pid 11 cpu threads normally report an invalid LR in ddb.) The actual EXI trapframe starts at 013f0878 in vmcore.5: 013f0870 df 5e f9 30 00 10 08 f8 00 04 90 32 df 5e f9 30 = |.^.0.......2.^.0| 013f0880 01 47 d0 00 00 00 00 00 25 94 48 3f 00 00 00 00 = |.G......%.H?....| 013f0890 25 94 48 3f 00 4a a9 c8 00 00 00 00 00 00 00 44 = |%.H?.J.........D| 013f08a0 01 fc a0 55 00 00 90 32 df 5d 1d 00 00 00 00 00 = |...U...2.]......| 013f08b0 00 d4 bd ec 00 cb 98 98 00 c9 66 bc 00 c4 5d 08 = |..........f...].| 013f08c0 00 c9 66 bc 00 d4 c5 3c df 5e f9 e0 00 eb a7 80 = |..f....<.^......| 013f08d0 00 c9 66 bc 01 47 d0 00 df 5e f9 8c 00 00 00 06 = |..f..G...^......| 013f08e0 00 00 00 06 00 eb b5 80 00 00 00 00 00 8e 3b d8 = |..............;.| 013f08f0 00 d2 6b f0 df 5e f9 30 00 8e 3b f4 40 00 00 42 = |..k..^.0..;.@..B| 013f0900 20 00 00 00 00 8e 3b d8 00 8e 3c 60 00 00 90 32 | = .....;...<`...2| 013f0910 00 00 05 00 41 a1 d5 d4 42 00 00 00 00 00 00 00 = |....A...B.......| So: r0 =3D 0x00049032 r1 =3D 0xdf5ef930 r2 =3D 0x0147d000 r3 =3D 0x00000000 r4 =3D 0x2594483f r5 =3D 0x00000000 r6 =3D 0x2594483f r7 =3D 0x004aa9c8 r8 =3D 0x00000000 r9 =3D 0x00000044 r10 =3D 0x01fca055 r11 =3D 0x00009032 r12 =3D 0xdf5d1d00 r13 =3D 0x00000000 r14 =3D 0x00d4bdec r15 =3D 0x00cb9898 r16 =3D 0x00c966bc r17 =3D 0x00c45d08 r18 =3D 0x00c966bc r19 =3D 0x00d4c53c r20 =3D 0xdf5ef9e0 r21 =3D 0x00eba780 r22 =3D 0x00c966bc r23 =3D 0x1047d000 r24 =3D 0xdf5ef98c r25 =3D 0x00000006 (this value shows up later in a bad spot) r26 =3D 0x00000006 (this value shows up next to that) r27 =3D 0x00ebb580 r28 =3D 0x00000000 r29 =3D 0x008e3bd8 r30 =3D 0x00d26bf0 r31 =3D 0xdf5ef930 lr =3D 0x008e3bf4 cr =3D 0x40000042 xer =3D 0x20000000 ctr =3D 0x008e3bd8 srr0 =3D 0x008e3c60 srr1 =3D 0x00009032 exc =3D 0x00000500 dar =3D 0x41a1d5d4 dsisr =3D 0x42000000 Other elements of the stack leading to this are: 013f0920 45 8b a7 b5 b1 fd 96 be 00 00 00 00 00 00 00 04 = |E...............| 013f0930 df 5e f9 50 00 00 00 06 00 00 00 06 00 eb b5 80 = |.^.P............| (odd lr value; value repeats above, not ; here. r25/r26 a multiple ; pair saved of 4 even. ; in those? matches r25 ; matches r26 in trapframe; in trapframe) 013f0940 00 00 00 00 00 d4 ca 34 00 d2 6b f0 df 5e f9 50 = |.......4..k..^.P| 013f0950 df 5e f9 70 00 8e 31 7c 00 00 00 02 00 eb b5 80 = |.^.p..1|........| 013f0960 00 f2 d5 fc 00 00 00 06 00 d1 ca ac df 5e f9 70 = |.............^.p| 013f0970 df 5e fa 50 00 53 6e 58 df 5e f9 80 00 00 00 00 = |.^.P.SnX.^......| . . . 013f0a50 df 5e fa 80 00 4a 3c b4 df 5e fa 60 fa 50 05 af = |.^...J<..^.`.P..| 013f0a60 df 5e fa 80 00 00 00 00 00 00 00 00 00 00 00 00 = |.^..............| 013f0a70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| 013f0a80 00 00 00 00 00 8f 18 90 00 53 69 84 00 00 00 00 = |.........Si.....| =46rom which I get from the stack backpointer/lr-value pairs(via objdump on the kernel): 00000006: ???????????????????? 008e317c: cpu_idle+0x58 00536e58: scheduletd+0x4d4 004a3cb4: fork_exit+0xf8 008f1890: fork_trampoline+0x10 But cpu_idle+0x58 is the bl ,cpu_activeclock> in the below and the prior bctrl after the bl is what made the call. 008e3124 stwu r1,-32(r1) 008e3128 mflr r0 008e312c stw r29,20(r1) 008e3130 stw r30,24(r1) 008e3134 stw r31,28(r1) 008e3138 stw r0,36(r1) 008e313c mr r31,r1 008e3140 bcl- 20,4*cr7+so,008e3144 008e3144 mflr r30 008e3148 lwz r0,-36(r30) 008e314c add r30,r0,r30 008e3150 lwz r29,-32768(r30) 008e3154 lwz r0,0(r29) 008e3158 cmpwi cr7,r0,0 008e315c beq- cr7,008e3198 008e3160 cmpwi cr7,r3,0 008e3164 bne- cr7,008e3188 008e3168 bl 005002a4 008e316c bl 008ad894 008e3170 lwz r29,0(r29) 008e3174 mtctr r29 008e3178 bctrl 008e317c bl 008ad794 But ctr was reported as: 0x8e3bd8 which is cpu_idle_60x. (So no surprises so far.) The code through the reported cpu_idle_60x+0x88 is: 008e3bd8 stwu r1,-32(r1) 008e3bdc mflr r0 008e3be0 stw r30,24(r1) 008e3be4 stw r31,28(r1) 008e3be8 stw r0,36(r1) 008e3bec mr r31,r1 008e3bf0 bcl- 20,4*cr7+so,008e3bf4 = 008e3bf4 mflr r30 008e3bf8 lwz r0,-32(r30) 008e3bfc add r30,r0,r30 008e3c00 lwz r9,-32756(r30) 008e3c04 lwz r0,0(r9) 008e3c08 cmpwi cr7,r0,0 008e3c0c beq- cr7,008e3c78 008e3c10 mfmsr r11 008e3c14 mfsprg r0,7 008e3c18 rlwinm r9,r0,16,16,31 008e3c1c cmpwi cr7,r9,68 008e3c20 beq- cr7,008e3c4c 008e3c24 cmplwi cr7,r9,68 008e3c28 bgt- cr7,008e3c40 008e3c2c cmpwi cr7,r9,57 008e3c30 beq- cr7,008e3c4c 008e3c34 cmpwi cr7,r9,60 008e3c38 bne+ cr7,008e3c64 008e3c3c b 008e3c4c 008e3c40 addi r0,r9,-32768 008e3c44 cmplwi cr7,r0,4 008e3c48 bgt- cr7,008e3c64 008e3c4c oris r0,r11,4 008e3c50 dssall 008e3c54 sync =20 008e3c58 mtmsr r0 008e3c5c isync 008e3c60 b 008e3c78 So that is the context for the EXI trap. The "mtsmr r0" merged in PSL_POW to the msr value when it was originally not set. (r11 vs. r0 value comparison in the trapframe.) Why it would be going from without POW for so long and then merging in POW I do not know. (Or may be I just did not find code that turns POW back off on occasion.) Still setting POW in msr seems to be what is unique to the failure context. Mkes me wonder if smu_doorbell_intr and its irq is somehow involved. There is no obvious, local tie to r25 and r26 in/for the spots identified earlier for the 013f0930 line of the thread stack area. Interestingly when I looked up POW in mtsmsr use what I found reported: Synchronization Required Prior: implementation dependent Synchronization Required After: implementation dependent The source code looks like: static void cpu_idle_60x(sbintime_t sbt) { register_t msr; uint16_t vers; if (!powerpc_pow_enabled) return; msr =3D mfmsr(); vers =3D mfpvr() >> 16; #ifdef AIM switch (vers) { case IBM970: case IBM970FX: case IBM970MP: case MPC7447A: case MPC7448: case MPC7450: case MPC7455: case MPC7457: __asm __volatile("\ dssall; sync; mtmsr %0; isync" :: "r"(msr | PSL_POW)); break; default: powerpc_sync(); mtmsr(msr | PSL_POW); isync(); break; } #endif } I've not yet figured out how to check that the details are right here for IBM970MP used via 32-bit FreeBSD. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sat May 20 17:39:22 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 8DCA1D761DC for ; Sat, 20 May 2017 17:39:22 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 73E8E1A4C for ; Sat, 20 May 2017 17:39:22 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 54fb0bf9-3d83-11e7-bfb5-0d159cd3c324 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 54fb0bf9-3d83-11e7-bfb5-0d159cd3c324; Sat, 20 May 2017 17:39:53 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v4KHdEb0006915; Sat, 20 May 2017 11:39:15 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1495301954.89384.39.camel@freebsd.org> Subject: Re: cpp behavior? From: Ian Lepore To: sgk@troutmask.apl.washington.edu, freebsd-current@freebsd.org, freebsd-toolchain@freebsd.org Date: Sat, 20 May 2017 11:39:14 -0600 In-Reply-To: <20170520000747.GA26861@troutmask.apl.washington.edu> References: <20170520000747.GA26861@troutmask.apl.washington.edu> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 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, 20 May 2017 17:39:22 -0000 On Fri, 2017-05-19 at 17:07 -0700, Steve Kargl wrote: > % which cpp > /usr/bin/cpp > troutmask:kargl[408] cpp --version > FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on > LLVM 4.0.0) > Target: x86_64-unknown-freebsd12.0 > Thread model: posix > InstalledDir: /usr/bin > troutmask:kargl[409] cpp --help |grep trad >   -traditional-cpp        Enable some traditional CPP emulation > troutmask:kargl[410] cpp -traditional-cpp boxmuller.F90  > cpp: error: unable to execute command: Executable "gcc" doesn't > exist! > > OK, so what is the preprocessor for clang? > It looks like the problem is that it sees the .F90 and wants to "do the right thing" for fortran sources, which is "invoke gcc".  I got a clue by adding '-###' (quotes required) to see what cpp was trying to do internally. You might get the effect you want by either adding something like -x assembler-with-cpp, or maybe by hiding the filetype from cpp:  cat boxmuller.F90 | cpp -traditional-cpp -- Ian From owner-freebsd-current@freebsd.org Sat May 20 20:12: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 AEFE1D76D17; Sat, 20 May 2017 20:12:09 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 95E981D87; Sat, 20 May 2017 20:12:09 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v4KKC8kB033111 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 20 May 2017 13:12:08 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v4KKC8Q9033110; Sat, 20 May 2017 13:12:08 -0700 (PDT) (envelope-from sgk) Date: Sat, 20 May 2017 13:12:08 -0700 From: Steve Kargl To: Ian Lepore Cc: freebsd-current@freebsd.org, freebsd-toolchain@freebsd.org Subject: Re: cpp behavior? Message-ID: <20170520201208.GA33085@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170520000747.GA26861@troutmask.apl.washington.edu> <1495301954.89384.39.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1495301954.89384.39.camel@freebsd.org> 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: Sat, 20 May 2017 20:12:09 -0000 On Sat, May 20, 2017 at 11:39:14AM -0600, Ian Lepore wrote: > On Fri, 2017-05-19 at 17:07 -0700, Steve Kargl wrote: > > % which cpp > > /usr/bin/cpp > > troutmask:kargl[408] cpp --version > > FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on > > LLVM 4.0.0) > > Target: x86_64-unknown-freebsd12.0 > > Thread model: posix > > InstalledDir: /usr/bin > > troutmask:kargl[409] cpp --help |grep trad > >   -traditional-cpp        Enable some traditional CPP emulation > > troutmask:kargl[410] cpp -traditional-cpp boxmuller.F90  > > cpp: error: unable to execute command: Executable "gcc" doesn't > > exist! > > > > OK, so what is the preprocessor for clang? > > > > It looks like the problem is that it sees the .F90 and wants to "do the > right thing" for fortran sources, which is "invoke gcc".  I got a clue > by adding '-###' (quotes required) to see what cpp was trying to do > internally. Thanks. I did not know about the -### option. > You might get the effect you want by either adding something like -x > assembler-with-cpp, or maybe by hiding the filetype from cpp: I'm checking out the new devel/flang port (a Fortran front-end for clang). Although flang recognizes the .F90 extension, 'flang -c boxmuller.F90' dies a horrible death because it assumes a modern cpp syntax. AFAIK, the traditional syntax that gcc uses with the -traditional-cpp option is required by those who use C preprocessing directives in their Fortran. Modern cpp can corrupt valid Fortran. Having clang invoke gcc when I tried cpp caught me off guard. -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow