From owner-freebsd-current@freebsd.org Sun Jun 17 08:00:06 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 44EBA1013CC8 for ; Sun, 17 Jun 2018 08:00:06 +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 9ECBD84396 for ; Sun, 17 Jun 2018 08:00:05 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([85.181.109.113]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LhkiL-1fzgjq2NxR-00moRk for ; Sun, 17 Jun 2018 09:59:55 +0200 Date: Sun, 17 Jun 2018 09:59:21 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: r335282: first stage boot failure on PCengines APU 2C4 Message-ID: <20180617095948.6357f96a@thor.intern.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Provags-ID: V03:K1:O3Ru3hwfu5d2C7k6atNGtm8oerN8VsGRzgCRMiIBaUMDb/nxs90 NUArsuhRCnNGTTBf1RaCBOJYTHA6vq0P77FNpXghEYH0puUge4SAm3Y2S9N3LA+3W68eZ0A 11k7eV4OZEEYcMB2SCsYnGWH9yUJnMoL7wHIS26+Inke9xqQqIdl/ecrQGf9prqlJgG4qVe 8McCH8TmwNaJliVFBoTGg== X-UI-Out-Filterresults: notjunk:1;V01:K0:au65KA9IE/M=:6ZezCOZtwsV97aHSSofGKY wdcXPrnW+YVVa06aobGqwLv/lJxB4hHBAevd49PZFSrXAArMRbxQFQGMTpg8gGzUSfDhQK1Z6 6XD62ZmTiyWAELajLoXd1QHGPyMGBwD6OJAPorwEvDB/bm1LUbhTKnlQrxVU4VZHQ6fEIEHsQ KLveQ0ph48mNdGF7c0DCC+9UP6iVIqeEf/nToTW0ysRjI8Yyi/l/vpPnEKuIdKAUxhu67ncO4 yzK3SL4j7ofxLG0nw1V6o9sH16PJ37yR3v6SqHmQaP7nNaREqies/2PlQLBC6PfTAFScce2dU FMtfqs8FA0eulm1/CaIW9DhLvYsUjBI2X6rhmzyZ7UBJNR4BHkkoR2fwldXQSCMWPfRameqw4 LTbwhAVJpSeLpVA2AMNzu3jj0wJvgs3yLG1OQ+Z9PM7TrDnq0MCSICNRTcrOn54rJBwGAufHT 6PpjAEdE3hVI6XIAGUCCx82dA/Sa5AWrrrCq3wYPMomdyJB8Dl2cYix5o9/LzrV/Ow+Lyj+ju I/fwyRSUnk58riy8yeeEjeHmrxheP9ZntRpKfIWdfS4nJqcHb/Jq2zD5WOdZ+G4mrl9v+MYmu 6TzscWsUo3gYL0Mb1YqLbMXCjav7HTJ2PtZdws5Jql70jt2FwR25YzOwion2vVKD06czc5gay Mc60AlIV3FOtLXpStXshaZNX+LzdCJYjdUAgNn69mMKMkKtDjx/wlQK7RGS7vjL4eIGe0l6du nr10Aem0uexf06wMNJZw5HaqCOTaxAOxksqsDw+nnQ9oiFUlHBDvLPeQICA90pU0TWXnYx5nt MT/a6Gz X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 17 Jun 2018 08:00:06 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBNTEyDQoNClJ1bm5p bmcgQ1VSUkVOVCBhcyByb3V0aW5nIGFuZCBmaXJld2FsbGluZyBhcHBsaWFuY2Ugb24gYSBQQ2Vu Z2luZXMgQVBVIDJDNCB3aXRoIHRoZQ0KbGF0ZXN0IChvZmZpY2lhbCkgU0VBQmlvcyBhdmFpbGFi bGUgZm9yIHRoaXMgcHJvZHVjdCwgTmFub0JTRCAoRnJlZUJTRCBDVVJSRU5UIEZyZWVCU0QNCjEy LjAtQ1VSUkVOVCAjNjAgcjMzNTI3ODogU3VuIEp1biAxNyAwNzo1NzoyMCBDRVNUIDIwMTggYW1k NjQpaXMgdW5hYmxlIHRvIGJvb3QgcmVjZW50DQpPUyBhdCB0aGUgZmlyc3Qgc3RhZ2UgKEdQVCBw YXJ0aXRpb25pbmcsIFNEIGNhcmQgbWVtb3J5KS4NCg0KTGFzdCBrbm93biBnb29kIGltYWdlIHdp dGhvdXQgYm9vdCBpc3N1ZXMgaXMgRnJlZUJTRCAxMi4wLUNVUlJFTlQgIzUyIHIzMzUyMjI6IEZy aSBKdW4gMTUNCjIwOjI0OjQxIENFU1QgMjAxOCBhbWQ2NC4NCg0KVGhlIGlzc3VlIGlzIHJldmVh bGluZyBpdHNlbGYgYnkgc2hvd2luZyBub3RoaW5nIGJ1dCBhIHN0YXRpYyBzY3JlZW4gdGVsbGlu ZyBpdCBpcw0KYm9vdGluZyBmcm9tIGhhcmQgZGlzayB3aGVyZSB1c3VhbGx5IHRoZSByb3RhdGlu ZyBpbmRpY2F0b3IgcG9wcHMgdXAuDQpCb290aW5nIHRoZSAgQVBVd2l0aCAgbXkgaW5zdGFsbGF0 aW9uIFVTQiBkZXZpY2UgYW5kICJncGFydCAtYiBwbWJyIC1wIC9ib290L2dwdGJvb3QgLWkgMg0K bW1jc2QwIiAtIHdoaWNoIGlzIGEgcXVpdGUgb2xkIGltYWdlIGZyb20gRGVjZW1iZXIgMjAxNyBi eSB0aGUgd2F5LCBtYWRlIHRoZSBTRCBjYXJkDQpib290aW5nIGFnYWluIC0gd2l0aCByMzM1Mjc4 IG5vdyBwcm9wZXJseS4NCg0KQXQgdGhlIHZlcnkgbW9tZW50LCBJIGRvIG5vdCBkYXJlIHRvIGNo ZWNrIHdoZXRoZXIgdGhlIGJvb3Rjb2RlIGlzIGJyb2tlbiBvbiB0aG9zZSBib3hlcw0KSSBib290 IHZpYSBNQlIvR1BUQk9PVC4NCg0KQ2FuIHNvbWVvbmUgZ2l2ZSBtZSBzb21lIGhpbnRzIGhvdyB0 byBjaGVjayB0aGlzIGZ1cnRoZXIgb3IgaXMgdGhpcyBpc3N1ZSBhbHJlYWR5IGtub3duPw0KDQpL aW5kIHJlZ2FyZHMsDQoNCm9oDQoNCi0gLS0gDQpPLiBIYXJ0bWFubg0KDQpJY2ggd2lkZXJzcHJl Y2hlIGRlciBOdXR6dW5nIG9kZXIgw5xiZXJtaXR0bHVuZyBtZWluZXIgRGF0ZW4gZsO8cg0KV2Vy YmV6d2Vja2Ugb2RlciBmw7xyIGRpZSBNYXJrdC0gb2RlciBNZWludW5nc2ZvcnNjaHVuZyAowqcg MjggQWJzLiA0IEJEU0cpLg0KLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NCg0KaUxVRUFS TUtBQjBXSVFRWlZaTXpBdHdDMlQvODZUclM1MjhmeUZoWWxBVUNXeVlVOUFBS0NSRFM1MjhmeUZo WQ0KbENyYUFmNHg2L3ZrejJFNlI4MDJxTnNFN3ozdlN2NUR1ZEdWUlBMWk5EQkF5V01pTW8xNU44 eGEvSkp2R3lYbg0KNnlPOE9wUjBicUtZd2FCazQ0M0tndGxxVEJha0Fma0JEdk5jWlJzVTdSM0Z3 RW1ackNvbERJT1doZFp3S1Q5YQ0KSHBaUk1pdVlMTjN5Z2wrT1FKOHRHaG9ZMHR3bDJGQUtieGNM U05QUGVId2lVUkJ1cWFSeQ0KPWt0K2ENCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0K From owner-freebsd-current@freebsd.org Sun Jun 17 10:46:51 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EFE611019A0A; Sun, 17 Jun 2018 10:46:50 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::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 6EDA369579; Sun, 17 Jun 2018 10:46:50 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: by mail-vk0-x22f.google.com with SMTP id q135-v6so7978381vkh.1; Sun, 17 Jun 2018 03:46:50 -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=yQQQvEItdWKGYqL+ZzwBYYq+CfZCIc+YIAUBJ5A07e4=; b=kxgTHUsyeIReo6HQre8KjaaepGIxC4Cuk8nvjU1SCy+cPMEHAtEZzuq6HyVqg6CWws 0hM6/Q22u9zxkRCbV+eU18LnQgHQco4K9jqaxWFhWKODVy/CieTCp4n6o+joG5vJ+Wdp oL/8YzDJFOB4igYQ5nHacktXSIcZNephl/bqO8keBuAujhDcyrVn219gpPvn7hZVgay5 wLT9EoM0uvW+jwjnYW/qjyMvCEGMULVzj1F8wINOaX1P7Hr8WEfeE/WYIPnvjJAujNsl dJhIO6SlR5gktxIS9g4f9IUWVskKW90SVuMVK9dztHLGYURREcM57ew1HHzYgZim+xXO Y8MA== 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=yQQQvEItdWKGYqL+ZzwBYYq+CfZCIc+YIAUBJ5A07e4=; b=RtOEsuMLPxhucYb7WCfQWvEqzqJIeGeXuWWAKdCJ75u7LejIzXfazUQemL2caarJ5A Su3fyLdtXoohWJBbVG3uDAJjHno3X84RBZt1oQjrOE6dZTcwggk1PEsn9sai6h24uSaC vQoyaRlL22US6YjhAzKUL2VKqn7ywtKSykG344WXls9NV8XjyBKlSoDe6yWAQVWt2CXc WGhOGok+ncKOG+aXj8yBb8NVs7p+0zZ4JBWDL06Cn5NNY48DRHmctCDvy9U/3yPCj1YA 8jJbNPSyLyKx4A2/2A/rlD/RNPVA6hSIT6P/9EsQ3JSTVWSLBkOI6i3m0E/myQJzlgAS 7QOA== X-Gm-Message-State: APt69E1WW/dnkTaMSV3kr/IDSrodD5z6dAD/2o8Jl53pd+YSZa+c1lpl 5KRtSpBpmoI6SDkirCqQQWvZhbL8nvyz3qLs0pPdPw== X-Google-Smtp-Source: ADUXVKJ7tFubujTPo68/pJejbyphNbYs1PnNc+Wkw5ZZqlXT5liCX3zsv0IOlSWdSkep7InV2bNMbJNNuGrA0IpuugE= X-Received: by 2002:a1f:a302:: with SMTP id m2-v6mr4783332vke.31.1529232409563; Sun, 17 Jun 2018 03:46:49 -0700 (PDT) MIME-Version: 1.0 From: Tom Vijlbrief Date: Sun, 17 Jun 2018 12:46:38 +0200 Message-ID: Subject: Panic on RPI boot with revision 335282 To: freebsd-arm , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 17 Jun 2018 10:46:51 -0000 I get an: panic: Assertion zone->uz_flags & UMA_ZONE_PCPU failed at /media/swan/src.svn/sys/vm/uma_core.c:2239 A one month old kernel runs fine, uma_core.c was edited at that location 9 days ago From owner-freebsd-current@freebsd.org Sun Jun 17 10:56:46 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 471501019F26; Sun, 17 Jun 2018 10:56:46 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (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 DE49D69A67; Sun, 17 Jun 2018 10:56:45 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 3DBD521399; Sun, 17 Jun 2018 06:56:45 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sun, 17 Jun 2018 06:56:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=rz3JbmkgJfBn5pMfukXITymWi/XHE fOq/+qhsDoE2vY=; b=Le7VeSBaiJRCjSVIyRwallQt01Anf/k2yDDtFkJG7rlPf 7zqW1NibGQUTj192P0K1cxHaDbuo9nmu6Mz8kf1UxyjfMCQfqteM2/WScQvl8dcA dkwwJg1xq7PjHpTycx4AT0+qfJ36X5Uv7uz6fYnub0jTIvHgYSUGgcoX6l3ycLAv 42bBnzAgeYXR6Q/0UNXfypEb7q+jrYN+8AdGarQ1PgCWWBglrKpWlNJyqq+0B25f 8+NggCV+Osc+5mP+2cTCrfs9k0sjNXvldTdMcHLGJzPq9gXjMI6cJH8pcKP1/FGZ Flwhz0oy7dncBATK9Yc+Z54mhtuaZV+MCck05BmrQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=rz3Jbm kgJfBn5pMfukXITymWi/XHEfOq/+qhsDoE2vY=; b=F51LqPx7phhZN19MeSIFap uCzKFrdxAknvamwMVGW0Dl6rZwmu4VANxE52PMlGr7/ugGu2nR4UmkogljBT+hT4 r2Dl440Lr/Jsx5F1IVlqhTUseyU8PyucKS1zJeYCy5XZLbR5s7gl3vkgTYScByUX w5GY2Fs0LZ5NEOLhlC8iFV4CzjnPu7ukbs4wddas4QhPtfydWN8EJglW5WQAqVQX p8NdeAc/7Zqkc9Jn5TNVRzGkVz744irAwUj8rL319Dn1shEKzd9rqBGqZ7eEXoi6 sopDqalfB9hbgMdB46i7j/WGDOR/tUrJjCD5iX6BhtoRIPDDsLitkVf4AZdEq1jg == X-ME-Proxy: X-ME-Sender: Received: from desktop.local (parsley.growveg.org [82.70.91.97]) by mail.messagingengine.com (Postfix) with ESMTPA id 89B5510255; Sun, 17 Jun 2018 06:56:44 -0400 (EDT) Subject: Re: freebsd bhyve instance does not show kernel messages after boot screen References: <201806151402.w5FE26Xm050793@pdx.rh.CN85.dnsmgr.net> To: freebsd-current@freebsd.org, freebsd-virtualization@freebsd.org From: tech-lists Organization: none Message-ID: <714a9e4e-d57e-efc4-eb4b-2ca36def8489@zyxst.net> Date: Sun, 17 Jun 2018 11:56:42 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <201806151402.w5FE26Xm050793@pdx.rh.CN85.dnsmgr.net> 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.26 Precedence: 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, 17 Jun 2018 10:56:46 -0000 On 15/06/2018 15:02, Rodney W. Grimes wrote: > With the VM shutdown look in /dev/vmm for the same name as the VM, > if you see it there, make sure you do not have a running instnace > of it, then do: > bhyvectl --destroy --name=fbsd11-vm > > You may have remanants of a prior/crashed VM hanging around > causing you issues. Unfortunately this made no difference either. If someone can tell me what to do to debug [1] this, I'll make a problem report? [1] unfortunately debugging this particular thing is outside of my realm of expertise. I know how to start/stop bhyve but not much else outside of that. thanks, -- J. From owner-freebsd-current@freebsd.org Sun Jun 17 12:35:15 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23726101D75B for ; Sun, 17 Jun 2018 12:35:15 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660056.outbound.protection.outlook.com [40.107.66.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT TLS CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 94E1D6CCAE for ; Sun, 17 Jun 2018 12:35:14 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM (52.132.44.24) by YTOPR0101MB0746.CANPRD01.PROD.OUTLOOK.COM (52.132.43.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.19; Sun, 17 Jun 2018 12:35:12 +0000 Received: from YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM ([fe80::d0eb:3783:7c99:2802]) by YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM ([fe80::d0eb:3783:7c99:2802%3]) with mapi id 15.20.0863.016; Sun, 17 Jun 2018 12:35:12 +0000 From: Rick Macklem To: "freebsd-current@freebsd.org" CC: "andreas.nagy@frequentis.com" Subject: ESXi NFSv4.1 client id is nasty Thread-Topic: ESXi NFSv4.1 client id is nasty Thread-Index: AQHUBjX1G4uSBXqIhUeci7+GbxFK0w== Date: Sun, 17 Jun 2018 12:35:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB0746; 7:2GCER1YYgXmSACK1D8MTZHMc7LtJJ/EseXpun1ItmEisLdrqQSXASMt7FjjM2WtNVMfZXO4WhjJJkXiEP+5iCN4Isk8laujChM0lmb4RR3/W+X4TRbYT3aQ0DVX2v7uPo9OZYrXMphQNZSFyt0GtL7IH8GFNiIOOhnIYbVLW3wJ4iNUjMBPBRncnP7lYDcXLI4FowWOUEFktfAMPtu29E4mRqoQntVG4iYeawBbx5OdoY2PjtjoKqcIkqVJ73EGN x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: f78b3922-0bdb-4be3-d95f-08d5d44ec523 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:YTOPR0101MB0746; x-ms-traffictypediagnostic: YTOPR0101MB0746: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(149027)(150027)(6041310)(20161123558120)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:YTOPR0101MB0746; BCL:0; PCL:0; RULEID:; SRVR:YTOPR0101MB0746; x-forefront-prvs: 07063A0A30 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(376002)(39380400002)(366004)(39860400002)(199004)(189003)(51874003)(26005)(5660300001)(6436002)(74482002)(786003)(2351001)(4326008)(3280700002)(25786009)(5640700003)(105586002)(186003)(316002)(106356001)(486006)(476003)(59450400001)(7696005)(68736007)(6506007)(102836004)(55016002)(6916009)(9686003)(3660700001)(2906002)(53936002)(99286004)(86362001)(74316002)(97736004)(2900100001)(33656002)(305945005)(5250100002)(14454004)(2501003)(478600001)(8936002)(81156014)(81166006)(8676002)(12363001); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB0746; H:YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-microsoft-antispam-message-info: qbIxzPNRguRIRsfLGjEtzpP/ujzzz6rCmxKjK3SNdcfeqhi+rqqO6pTNzB4L7jN0+sTpATdpSgd49GNjqty/XZOo4LZjVVF282cC+EpYadSFX/KuWok9uKQcFI8ppJyn6g2xI5vpJss9dykZZ8edaB0cy1udy2Wf+UtQ83bDoHJtp5X93FXCZ5H3KA5I1jqF 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-Network-Message-Id: f78b3922-0bdb-4be3-d95f-08d5d44ec523 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2018 12:35:12.2010 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB0746 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 17 Jun 2018 12:35:15 -0000 Hi, Andreas Nagy has been doing a lot of testing of the NFSv4.1 client in ESXi = 6.5u1 (VMware) against the FreeBSD server. I have given him a bunch of hackish pa= tches to try and some of them do help. However not all issues are resolved. The problem is that these hacks pretty obviously violate the NFSv4.1 RFC (5= 661). (Details on these come later, for those interested in such things.) I can think of three ways to deal with this: 1 - Just leave the server as is and point people to the issues that should = be addressed in the ESXi client. 2 - Put the hacks in, but only enable them based on a sysctl not enabled by= default. (The main problem with this is when the server also has non-ESXi mount= s.) 3 - Enable the hacks for ESXi client mounts only, using the implementation = ID it presents at mount time in its ExchangeID arguments. - This is my preferred solution, but the RFC says: An example use for implementation identifiers would be diagnostic software that extracts this information in an attempt to identify interoperability problems, performance workload behaviors, or general usage statistics. Since the intent of having access to this information is for planning or general diagnosis only, the client and server MUST NOT interpret this implementation identity information in a way that affects interoperational behavior of the implementation. The reason is that if clients and servers did such a thing, they might use fewer capabilities of the protocol than the peer can support, or the client and server might refuse to interoperate. Note the "MUST NOT" w.r.t. doing this. Of course, I could argue that, since= the hacks violate the RFC, then why not enable them in a way that violates the = RFC. Anyhow, I would like to hear from others w.r.t. how they think this should = be handled? Here's details on the breakage and workarounds for those interested, from l= ooking at packet traces in wireshark: Fairly benign ones: - The client does a ReclaimComplete with one_fs =3D=3D false and then does = a ReclaimComplete with one_fs =3D=3D true. The server returns NFS4ERR_COMPLETE_ALREADY for the second one, which the ESXi client doesn't like. Woraround: Don't return an error for the one_fs =3D=3D true case and just= assume that same as "one_fs =3D=3D false". There is also a case where the client only does the ReclaimComplete with one_fs =3D=3D true. Since FreeBSD exports a hierarch= y of file systems, this doesn't indicate to the server that all reclaims are d= one. (Other extant clients never do the "one_fs =3D=3D true" variant of ReclaimComplete.) This case of just doing the "one_fs =3D=3D true" variant is actually a li= mitation of the server which I don't know how to fix. However the same workaround as listed about gets around it. - The client puts random garbage in the delegate_type argument for Open/ClaimPrevious. Workaround: Since the client sets OPEN4_SHARE_ACCESS_WANT_NO_DELEG, it do= esn't want a delegation, so assume OPEN_DELEGATE_NONE or OPEN_DELEGATE_NONE= _EXT instead of garbage. (Not sure which of the two values makes it happie= r.) Serious ones: - The client does a OpenDowngrade with arguments set to OPEN_SHARE_ACCESS_B= OTH and OPEN_SHARE_DENY_BOTH. Since OpenDowngrade is supposed to decrease share_access and share_deny, the server returns NFS4ERR_INVAL. OpenDowngrade is not supposed to ever conflict with another Open. (A conflict happens when another Open has set an OPEN_SHARE_DENY that denies the result of the OpenDowngrade.) with NFS4ERR_SHARE_DENIED. I believe this one is done by the client for something it calls a "device lock" and really doesn't like this failing. Workaround: All I can think of is ignore the check for new bits not being= set and reply NFS_OK, when no conflicting Open exists. When there is a conflicting Open, returning NFS4ERR_INVAL seems to be= the only option, since NFS4ERR_SHARE_DENIED isn't listed for OpenDowngrad= e. - When a server reboots, client does not serialize ExchangeID/CreateSession= . When the server reboots, a client needs to do a serialized set of RPCs with ExchangeID followed by CreateSession to confirm it. The reply to ExchangeID has a sequence number (csr_sequence) in it and the CreateSession needs to have the same value in its csa_sequence argument to confirm the clientid issued by the ExchangeID. The client sends many ExchangeIDs and CreateSessions, so they end up fail= ing many times due to the sequence number not matching the last ExchangeID. (This might only happen in the trunked case.) Workaround: Nothing that I can think of. - ExchangeID sometimes sends eia_clientowner.co_verifier argument as all ze= ros. Sometimes the client bogusly fills in the eia_clientowner.co_verifier argument to ExchangeID with all 0s instead of the correct value. This indicates to the server that the client has rebooted (it has not) and results in the server discarding any state for the client and re-initializing the clientid. Workaround: The server can ignore the verifier changing and make the reco= very work better. This clearly violates RFC5661 and can only be done for ESXi clients, since ignoring this breaks a Linux client hard reboot. - The client doesn't seem to handle NFS4ERR_GRACE errors correctly. These occur when any non-reclaim operations are done during the grace period after a server boot. (A client needs to delay a while and then retry the operation, repeating for as long as NFS4ERR_GRACE is received from the server. This client does not do this.) Workaround: Nothing that I can think of. Thanks in advance for any comments, rick From owner-freebsd-current@freebsd.org Sun Jun 17 13:07:47 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2414D101E506 for ; Sun, 17 Jun 2018 13:07:47 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660063.outbound.protection.outlook.com [40.107.66.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT TLS CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8604F6DC48 for ; Sun, 17 Jun 2018 13:07:46 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM (52.132.44.24) by YTOPR0101MB1068.CANPRD01.PROD.OUTLOOK.COM (52.132.50.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.17; Sun, 17 Jun 2018 13:07:44 +0000 Received: from YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM ([fe80::d0eb:3783:7c99:2802]) by YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM ([fe80::d0eb:3783:7c99:2802%3]) with mapi id 15.20.0863.016; Sun, 17 Jun 2018 13:07:44 +0000 From: Rick Macklem To: "freebsd-current@freebsd.org" CC: "andreas.nagy@frequentis.com" Subject: NFSv4.1 server deficiencies fixed for ESXi client Thread-Topic: NFSv4.1 server deficiencies fixed for ESXi client Thread-Index: AQHUBjsXCbI4UKyOQkWL16OOOThmbg== Date: Sun, 17 Jun 2018 13:07:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB1068; 7:bDul9LBcqVx2vCcxQZbXmi9SmRcNGa5y3Qhz61nrzJIxSm6D44cSwGw91wgxbLE1pT5fN7gTc9F8FaV9dOyFKKPvEQwSjHOjc9hpP2fhCHnX0bGCc8EZgv25aZ6ZDjtNycysIApzbqWvRis3KTt2FOyfeZ758rB9kYKnQbikw3fyygME/KHRffU+sCOihtJTuV+qeSqKFzrzeSEgsegp4g+7sRu11ua+rgI30qr3f1AmH48S5WNMBpJ+esxOVEV6 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 4e19282d-9cdc-4bbe-afc4-08d5d4535101 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:YTOPR0101MB1068; x-ms-traffictypediagnostic: YTOPR0101MB1068: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(149027)(150027)(6041310)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:YTOPR0101MB1068; BCL:0; PCL:0; RULEID:; SRVR:YTOPR0101MB1068; x-forefront-prvs: 07063A0A30 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(346002)(396003)(376002)(39380400002)(199004)(189003)(53936002)(2900100001)(8936002)(25786009)(6916009)(3660700001)(59450400001)(3280700002)(2906002)(9686003)(478600001)(5640700003)(2501003)(86362001)(97736004)(68736007)(55016002)(305945005)(6436002)(5660300001)(5250100002)(186003)(105586002)(2351001)(106356001)(81156014)(81166006)(33656002)(4326008)(7696005)(74316002)(26005)(786003)(6506007)(99286004)(486006)(476003)(14454004)(8676002)(102836004)(316002)(74482002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB1068; H:YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-microsoft-antispam-message-info: B0EN0YIanl5Ypb6DEsqPy8/bZDAZinNIzjelKlcKk7Y+mcZ5WG2KnNor6CW3M/ME0oC7hMfS1wZmZ3WksJdJ47YyjDDnK/mVlOlVKJp85sKRY/y4L5pjzjJQ3cmZEL7HY3FkrVz2eF7Ruh39pB0HcNmaBhHh88v5rHbqvctypNc5slorHGvZ2S4Kc+UvaytM2XGypmvthsy3alozooA87pq7MfPq/0ER0i2vjXMEbzduaiRyVIXKS1E2CCMKsZ372V0afThMOE6OAgz4y0fG3Az4TWVjwxUXZJxXb6BpCO2eTTKnj3QT6ibIP2ivbiZz 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-Network-Message-Id: 4e19282d-9cdc-4bbe-afc4-08d5d4535101 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2018 13:07:44.8607 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB1068 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 17 Jun 2018 13:07:47 -0000 Hi, Since I posted w.r.t. issues that seem to violate the RFC, I figured I shou= ld also post ones that identified deficiencies in the FreeBSD server. These have ei= ther been patched in head/current or will be soon and will be MFC'd. - BindConnectiontoSession wasn't implemented. It is never used by the FreeB= SD client and not used during normal operation of the Linux client. --> Now in head and will be MFC'd soon. - OPEN_SHARE_ACCESS_WANT_NO_DELEG flag generated an error when set for OpenDowngrade. Since OpenDowngrade never issues a delegation, no other cl= ient sets this flag. However, since the RFC doesn't forbid it, the code in hea= d now just clears/ignores the flag instead of generating an error. - ESXi client generates warnings that "2" is not a valid reason for not iss= uing a delegation. Since "2" is in the list and the RFC says nothing about whe= n each reason is used, I don't know why it thinks it isn't valid. However, a pat= ch that changes the reason makes it happy and since other clients don't seem to care, thi= s patch will probably go in head soon. (Until then, all it does is generate warnings.) =20 rick From owner-freebsd-current@freebsd.org Sun Jun 17 14:42:09 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75BDA1021329 for ; Sun, 17 Jun 2018 14:42:09 +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 05E4C708DF for ; Sun, 17 Jun 2018 14:42:08 +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 w5HEg3V9060543; Sun, 17 Jun 2018 07:42:04 -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 w5HEg3pB060542; Sun, 17 Jun 2018 07:42:03 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201806171442.w5HEg3pB060542@pdx.rh.CN85.dnsmgr.net> Subject: Re: NFSv4.1 server deficiencies fixed for ESXi client In-Reply-To: To: Rick Macklem Date: Sun, 17 Jun 2018 07:42:03 -0700 (PDT) CC: "freebsd-current@freebsd.org" , "andreas.nagy@frequentis.com" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 17 Jun 2018 14:42:09 -0000 > Hi, > > Since I posted w.r.t. issues that seem to violate the RFC, I figured I should also > post ones that identified deficiencies in the FreeBSD server. These have either > been patched in head/current or will be soon and will be MFC'd. > > - BindConnectiontoSession wasn't implemented. It is never used by the FreeBSD > client and not used during normal operation of the Linux client. > --> Now in head and will be MFC'd soon. > - OPEN_SHARE_ACCESS_WANT_NO_DELEG flag generated an error when set for > OpenDowngrade. Since OpenDowngrade never issues a delegation, no other client > sets this flag. However, since the RFC doesn't forbid it, the code in head now just > clears/ignores the flag instead of generating an error. > - ESXi client generates warnings that "2" is not a valid reason for not issuing > a delegation. Since "2" is in the list and the RFC says nothing about when each > reason is used, I don't know why it thinks it isn't valid. However, a patch that changes > the reason makes it happy and since other clients don't seem to care, this patch > will probably go in head soon. > (Until then, all it does is generate warnings.) Have you any contact with VMWare so that they might fix the issues in thier code, rather than having to put hacks in FreeBSD for these issues? Thanks, -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Sun Jun 17 16:49:29 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ACBB61001566 for ; Sun, 17 Jun 2018 16:49:29 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670075.outbound.protection.outlook.com [40.107.67.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT TLS CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3AF73751AC for ; Sun, 17 Jun 2018 16:49:28 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM (52.132.44.24) by YTOPR0101MB1372.CANPRD01.PROD.OUTLOOK.COM (52.132.46.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.16; Sun, 17 Jun 2018 16:49:27 +0000 Received: from YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM ([fe80::d0eb:3783:7c99:2802]) by YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM ([fe80::d0eb:3783:7c99:2802%3]) with mapi id 15.20.0863.016; Sun, 17 Jun 2018 16:49:27 +0000 From: Rick Macklem To: "Rodney W. Grimes" CC: "freebsd-current@freebsd.org" , "andreas.nagy@frequentis.com" Subject: Re: NFSv4.1 server deficiencies fixed for ESXi client Thread-Topic: NFSv4.1 server deficiencies fixed for ESXi client Thread-Index: AQHUBjsXCbI4UKyOQkWL16OOOThmbqRkhj+AgAAghxg= Date: Sun, 17 Jun 2018 16:49:27 +0000 Message-ID: References: , <201806171442.w5HEg3pB060542@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201806171442.w5HEg3pB060542@pdx.rh.CN85.dnsmgr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB1372; 7:jh0Nxiszv/8kIyiYXMLH0Yv8qXzg/psIYTTYa/GPG3xBkpsaHsZ3C7RM7VnxhEW3P7pYDaWffzcGdDs2xxdHyz6fOdeko0pbTJRvBNr3KbO5Hwa95vEwGZHjWc5mHorN4FR2aewG0mHxC6v3LEODBworYCnYswdJ2x78BkfThT33x38V8u2Vjcl7CFxd4D5EpyR4AsN+ZObrcHrjtsowUnD2bH1JjTeVgVShjU/qoszEJOcnvCj1lgtFOkBPMMpr x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 25909005-dc31-4efc-a613-08d5d4724a26 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:YTOPR0101MB1372; x-ms-traffictypediagnostic: YTOPR0101MB1372: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:YTOPR0101MB1372; BCL:0; PCL:0; RULEID:; SRVR:YTOPR0101MB1372; x-forefront-prvs: 07063A0A30 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(39380400002)(396003)(376002)(346002)(366004)(189003)(199004)(2900100001)(25786009)(4326008)(86362001)(55016002)(5250100002)(8936002)(33656002)(81166006)(81156014)(74316002)(2906002)(14454004)(305945005)(53936002)(229853002)(9686003)(99286004)(8676002)(6436002)(3660700001)(5660300001)(6246003)(3280700002)(486006)(59450400001)(74482002)(68736007)(476003)(102836004)(11346002)(7696005)(26005)(446003)(186003)(6506007)(54906003)(97736004)(478600001)(316002)(105586002)(106356001)(786003)(76176011)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB1372; H:YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-microsoft-antispam-message-info: vZqlNV1V7jpWDMIMkIhpTZl2w1/MbXYLZV5sSmGuPg0Vg5UPKqFvijAkeada82MzVTPWJ+Z289Pw9ta8SO+kf/BWAq+zttwZc1nLedOGdHCCrvITXOBKQ4vDSkD7pUY5DIkakXi4aMcL1gmvNEiaB3f9CBwHH6yQn7o0F2G3ZNRwEz9uM/FLMiMAR0mEFESQdpCpnBJFAvau/fGtIm/RchvPQH06yS4C/bxneMm2sgQbY8HvDv5Q+vtxwegHkUEU6NWHUtk7DVFojatCDgCC9XSCQq50+rnBzikpxwVyY96vYbAqs6KI5G+0cyFYOiMGP5JkRKJZopU1gNy4FFzx4w== 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-Network-Message-Id: 25909005-dc31-4efc-a613-08d5d4724a26 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2018 16:49:27.7262 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB1372 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 17 Jun 2018 16:49:30 -0000 Rodney W. Grimes wrote: [stuff snipped] >Have you any contact with VMWare so that they might fix the issues >in their code, rather than having to put hacks in FreeBSD for these >issues? Nope. I tried an email to nfsv4@ietf.org about one issue (that isn't yet re= solved related to it complaining that a directory changes too many times when stuf= f is being deleted from it) in the hopes that someone that worked on the client would respond, but no one made any technical comments on the post. Andreas mentioned that his company might have some sort of maintenance agreement so he could give them a bug report, but I don't think he's had an= y opportunity to do that? To be honest, I'm amazed it works with any NFSv4.1 server, but apparently i= t does? So if anyone can get the list of problems in the "ESXi NFSv4.1 client is na= sty" post to VMware's engineering people, it would be appreciated. Thanks, rick From owner-freebsd-current@freebsd.org Mon Jun 18 01:45:08 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D41E1011A93 for ; Mon, 18 Jun 2018 01:45:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-22.consmr.mail.ne1.yahoo.com (sonic303-22.consmr.mail.ne1.yahoo.com [66.163.188.148]) (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 D86D9687B6 for ; Mon, 18 Jun 2018 01:45:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: gPthVwIVM1lAtUYXzoagkbo2WqxjaNeuRrllGFMFG6pBOaD6w2E1qyt8v4kEBoG qauBPUWD9AWLMIkriQYjDqk9TZoa0xv83zVA80rVvPr9y9Iu5UhvN28Ku3YpL1Rl1CbD0qrVJczm etfYisYPviDrp4A1kXwBAcx9OjT9qgB0N8N_MFLTW8eu1zPdFooovaCWDy9SA3n2iLqBd7aBcn7k hiINGxvWfxAShBl7a5zcL0fYEZ.KVjl1mFjKSCTRpzJBnmP8jJIVf6UIqORQS0HB06WhheXRNW17 XMFMxWPQwZUIXyDxPaWqr5G_jrDUxYXuGzszpDStZ8nnjAnJIMYCbvsz.5BwCHIuXssfAK61C8WI V7X6lyrd9blKQgttCd.9f10J.mzSNbe1L1W3F87.YVjGy.CLUUmQBLNCt92EJqRbq1OkSUSnN4uq JKYUWWYtJ8e.FIp9wEv_Sb_tFugDpEL2wUxNObDSObAu.krAXLoJ7l.E_MT27mGmEwyO7A2MDadV 3Z3p3QIYIPC8o9H7Cp0bfRAz6fEyIntWk2VBH_7Z6qpnLIM27A_t_vIA7GQY7jTjYVHqhlpLgApO IbvUf8riuaupQJhhlhswzNyGf1uIw3wGpInrbB6R.ATzHOWQS6bi9QMSQS_eiwrjUUNOwxPAtYjO q0Ekrx82VWHSDarzuBFhkIhUimTbhuip6urUB4FQNImUXCO5Jw7B_zlzPI7REpxmYNKEYF1lZyDb 9gn_g8ur7xLT9Va8qzu12byRMEta28KELBiPq2GlZV2WEFO4xiHUNQby8EeDt690jqKY5XnxESFY 9xhXtMDxm7cFlxPMhkk4qBYS3jvAyH63y3nPTOxwQHy8KZrOOYj5xALx_UB1_OEe4uQ2nuZJ3B32 LPqzLm84iP33yQ1UwVU49FvNdfw.xXOw2lUgnFjylYu30yTP7SYTn0_1LtepfJhGR.eOpYg6y Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Mon, 18 Jun 2018 01:45:01 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp420.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 2cd608c8173a91e541b9a3a5af32f2ef; Mon, 18 Jun 2018 01:44:57 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: head -r335307 breaks various builds on ci.freebsd.org (powerpc64, mips64, sparc64) Message-Id: <12E3C728-E27E-49FD-8DEF-F2C10F5567B5@yahoo.com> Date: Sun, 17 Jun 2018 18:44:55 -0700 To: asomers@FreeBSD.org, FreeBSD PowerPC ML , FreeBSD Current X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 18 Jun 2018 01:45:08 -0000 https://ci.freebsd.org/job/FreeBSD-head-powerpc64-build/6086/consoleText = (and later) shows: --- all_subdir_tests --- cc1: warnings being treated as errors /usr/src/tests/sys/audit/inter-process.c: In function = 'atfu_shmat_success_body': /usr/src/tests/sys/audit/inter-process.c:463: warning: cast from pointer = to integer of different size The following (and later) are similar: https://ci.freebsd.org/job/FreeBSD-head-mips64-build/2927/consoleText https://ci.freebsd.org/job/FreeBSD-head-sparc64-build/8245/consoleText =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Mon Jun 18 01:48:07 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E80BE1011C41 for ; Mon, 18 Jun 2018 01:48:06 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 903ED68930 for ; Mon, 18 Jun 2018 01:48:06 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074423-e29ff70000003bcd-6f-5b270e24b0c3 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 73.04.15309.42E072B5; Sun, 17 Jun 2018 21:43:00 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w5I1gx79009117; Sun, 17 Jun 2018 21:42:59 -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 w5I1gtHs001308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 17 Jun 2018 21:42:57 -0400 Date: Sun, 17 Jun 2018 20:42:55 -0500 From: Benjamin Kaduk To: Rick Macklem Cc: "freebsd-current@freebsd.org" , "andreas.nagy@frequentis.com" Subject: Re: ESXi NFSv4.1 client id is nasty Message-ID: <20180618014254.GC64971@kduck.kaduk.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixG6nrqvCpx5tsOi3vMXJGatYLea8+cBk 8XDZNSYHZo8Zn+azeDTe7mDz+L15L1MAcxSXTUpqTmZZapG+XQJXxoH1J1gKtptU3F10j7mB cb1mFyMnh4SAicSMz5/Yuxi5OIQEFjNJfHn6gxHC2cgo8eP3K6jMVSaJnoX32UFaWARUJW7t vsQEYrMJqEg0dF9mBrFFBNQlNq/uZwZpYBZoZZT4uWsmK0hCWEBH4ui852wgNi/QvsXLjoA1 CAkkSLx7Mo8ZIi4ocXLmExYQm1lAS+LGv5dACziAbGmJ5f84QMKcAokSf0/OANsrKqAssbfv EPsERoFZSLpnIemehdC9gJF5FaNsSm6Vbm5iZk5xarJucXJiXl5qka6ZXm5miV5qSukmRnDw uijvYHzZ532IUYCDUYmH12KiWrQQa2JZcWXuIUZJDiYlUd7vLSrRQnxJ+SmVGYnFGfFFpTmp xYcYJTiYlUR4m7NUo4V4UxIrq1KL8mFS0hwsSuK8OYsYo4UE0hNLUrNTUwtSi2CyMhwcShK8 0rzq0UKCRanpqRVpmTklCGkmDk6Q4TxAw7u5gWp4iwsSc4sz0yHypxgVpcR5G0CaBUASGaV5 cL2g5CKRvb/mFaM40CvCvE4gVTzAxATX/QpoMBPQ4P0LVUAGlyQipKQaGOUYrtt0T5IrU/5m 4/JEsXDpj1AjvoZJZfkRnzzfaC3hTbg7OX2CbsrdVOUZKVN40vpakh+Z/5vsrfWlvzGJcU5V jTrj5mzfM0b9bPsafKPcI8/9eTPrVWzF/ppor1PuV/xPLlx197eoiezaRz8snCa/KWX12lju LvfC9bLhYkujg2u/eP2dosRSnJFoqMVcVJwIABSC4zMJAwAA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 18 Jun 2018 01:48:07 -0000 On Sun, Jun 17, 2018 at 12:35:12PM +0000, Rick Macklem wrote: > Hi, > > Andreas Nagy has been doing a lot of testing of the NFSv4.1 client in ESXi 6.5u1 > (VMware) against the FreeBSD server. I have given him a bunch of hackish patches > to try and some of them do help. However not all issues are resolved. > The problem is that these hacks pretty obviously violate the NFSv4.1 RFC (5661). > (Details on these come later, for those interested in such things.) > > I can think of three ways to deal with this: > 1 - Just leave the server as is and point people to the issues that should be addressed > in the ESXi client. > 2 - Put the hacks in, but only enable them based on a sysctl not enabled by default. > (The main problem with this is when the server also has non-ESXi mounts.) > 3 - Enable the hacks for ESXi client mounts only, using the implementation ID > it presents at mount time in its ExchangeID arguments. > - This is my preferred solution, but the RFC says: > An example use for implementation identifiers would be diagnostic > software that extracts this information in an attempt to identify > interoperability problems, performance workload behaviors, or general > usage statistics. Since the intent of having access to this > information is for planning or general diagnosis only, the client and > server MUST NOT interpret this implementation identity information in > a way that affects interoperational behavior of the implementation. > The reason is that if clients and servers did such a thing, they > might use fewer capabilities of the protocol than the peer can > support, or the client and server might refuse to interoperate. None of these are great options, but adding in behavior dependency on the implementation ID feels really bad for the ecosystem, and I would be unhappy if it was enabled by default. Is it feasible to do one sysctl per workaround and have the sysctl set the implementation ID(s) to which to apply? -Ben P.S. I feel like the nfsv4 WG list should probably hear about this sort of issue, in addition to here. > Note the "MUST NOT" w.r.t. doing this. Of course, I could argue that, since the > hacks violate the RFC, then why not enable them in a way that violates the RFC. > > Anyhow, I would like to hear from others w.r.t. how they think this should be handled? > > Here's details on the breakage and workarounds for those interested, from looking > at packet traces in wireshark: > Fairly benign ones: > - The client does a ReclaimComplete with one_fs == false and then does a > ReclaimComplete with one_fs == true. The server returns > NFS4ERR_COMPLETE_ALREADY for the second one, which the ESXi client > doesn't like. > Woraround: Don't return an error for the one_fs == true case and just assume > that same as "one_fs == false". > There is also a case where the client only does the > ReclaimComplete with one_fs == true. Since FreeBSD exports a hierarchy of > file systems, this doesn't indicate to the server that all reclaims are done. > (Other extant clients never do the "one_fs == true" variant of > ReclaimComplete.) > This case of just doing the "one_fs == true" variant is actually a limitation > of the server which I don't know how to fix. However the same workaround > as listed about gets around it. > > - The client puts random garbage in the delegate_type argument for > Open/ClaimPrevious. > Workaround: Since the client sets OPEN4_SHARE_ACCESS_WANT_NO_DELEG, it doesn't > want a delegation, so assume OPEN_DELEGATE_NONE or OPEN_DELEGATE_NONE_EXT > instead of garbage. (Not sure which of the two values makes it happier.) > > Serious ones: > - The client does a OpenDowngrade with arguments set to OPEN_SHARE_ACCESS_BOTH > and OPEN_SHARE_DENY_BOTH. > Since OpenDowngrade is supposed to decrease share_access and share_deny, > the server returns NFS4ERR_INVAL. OpenDowngrade is not supposed to ever > conflict with another Open. (A conflict happens when another Open has > set an OPEN_SHARE_DENY that denies the result of the OpenDowngrade.) > with NFS4ERR_SHARE_DENIED. > I believe this one is done by the client for something it calls a > "device lock" and really doesn't like this failing. > Workaround: All I can think of is ignore the check for new bits not being set > and reply NFS_OK, when no conflicting Open exists. > When there is a conflicting Open, returning NFS4ERR_INVAL seems to be the > only option, since NFS4ERR_SHARE_DENIED isn't listed for OpenDowngrade. > > - When a server reboots, client does not serialize ExchangeID/CreateSession. > When the server reboots, a client needs to do a serialized set of RPCs > with ExchangeID followed by CreateSession to confirm it. The reply to > ExchangeID has a sequence number (csr_sequence) in it and the > CreateSession needs to have the same value in its csa_sequence argument > to confirm the clientid issued by the ExchangeID. > The client sends many ExchangeIDs and CreateSessions, so they end up failing > many times due to the sequence number not matching the last ExchangeID. > (This might only happen in the trunked case.) > Workaround: Nothing that I can think of. > > - ExchangeID sometimes sends eia_clientowner.co_verifier argument as all zeros. > Sometimes the client bogusly fills in the eia_clientowner.co_verifier > argument to ExchangeID with all 0s instead of the correct value. > This indicates to the server that the client has rebooted (it has not) > and results in the server discarding any state for the client and > re-initializing the clientid. > Workaround: The server can ignore the verifier changing and make the recovery > work better. This clearly violates RFC5661 and can only be done for > ESXi clients, since ignoring this breaks a Linux client hard reboot. > > - The client doesn't seem to handle NFS4ERR_GRACE errors correctly. > These occur when any non-reclaim operations are done during the grace > period after a server boot. > (A client needs to delay a while and then retry the operation, repeating > for as long as NFS4ERR_GRACE is received from the server. This client > does not do this.) > Workaround: Nothing that I can think of. > > Thanks in advance for any comments, rick > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Mon Jun 18 03:24:21 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95C421014406 for ; Mon, 18 Jun 2018 03:24:21 +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 323676B991 for ; Mon, 18 Jun 2018 03:24:21 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (203-59-175-75.dyn.iinet.net.au [203.59.175.75]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w5I3ODM6082929 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 17 Jun 2018 20:24:18 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: GELI attach issue from r326073 -> r334996 To: freebsd-current@freebsd.org, mikej@mikej.com References: <1aa4ba2a8313f602bd0b0445987c18ec@mikej.com> <1528918051.12122.70.camel@freebsd.org> <174be0c8f126d47300df51392655d028@mikej.com> From: Julian Elischer Message-ID: <0398d5c9-5da0-3fab-38a0-2e0a60ae460b@freebsd.org> Date: Mon, 18 Jun 2018 11:24:08 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <174be0c8f126d47300df51392655d028@mikej.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 18 Jun 2018 03:24:21 -0000 On 14/6/18 4:46 am, Michael Jung wrote: > On 2018-06-13 15:27, Ian Lepore wrote: >> On Wed, 2018-06-13 at 14:29 -0400, Michael Jung wrote: >>> Hi! >>> >>> I just tried updating current from r326073 -> r334996 and when >>> I try 'geli attach' I get the following error: >>> >>> # geli attach -p -k mykey.key /dev/gpt/da14 >>> geli: Missing keyno argument >>> # >>> >>> If I boot the old kernel GELI attaches just fine. >>> >>> I ran into this once before but can not find the thread.  I recall >>> it being a bug... with no resolution. >>> >>> I mount zfs partitions over GELI - my painful solution was to >>> nuke each GPT partition in the zpool, resilver, repeat and >>> rinse until everything was non-encrypted and repeat the cycle >>> to re-encrypt.  NOT FUN. >>> >>> Looking for suggestions to supply additional information to debug >>> and resolve. >>> >>> dmesg attached from working kernel. >>> >>> Thanks! >> >> r333439 added a '-n keyno' parameter to geli attach, but it's supposed >> to default to trying all keys if you don't use -n. Is it possible >> you're running a newer kernel (or geom_eli module) than your userland >> or vice versa? >> >> -- Ian >> >> >> _______________________________________________ >> 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" > > Ian: > > Yes you are correct.... Maybe not the best method but I normally > installkernel - > boot into single user mode - GELI attach, zfs mount -av, then > installworld. Yes that is the prescribed method. if it doesn't work then whoever changed the geli code should fix it to handle this. You should be able to run older code on newer kernels with very few exceptions. I don't know if this also affects upgrades form 11. Have you tested that? > > My boot volume is UFS, but many of the mount points are on zpools. > > What would be the best way to test a new kernel without a full > installworld > with new userland geli bits? > > I currently don't have a way to backup my 35TB of data :-( and don't > want to > lose anything..... and I need a back out method should a full > installworld fail. > > Thanks for you quick reply. > > --mikej > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@freebsd.org Mon Jun 18 08:59:43 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D17D101DAA2 for ; Mon, 18 Jun 2018 08:59:43 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BDD59756EC for ; Mon, 18 Jun 2018 08:59:42 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: from mail-pf0-f176.google.com (mail-pf0-f176.google.com [209.85.192.176]) (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)) (Authenticated sender: olivier/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 7474811BE9 for ; Mon, 18 Jun 2018 08:59:42 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: by mail-pf0-f176.google.com with SMTP id w7-v6so7821845pfn.9 for ; Mon, 18 Jun 2018 01:59:42 -0700 (PDT) X-Gm-Message-State: APt69E0SXDDorf6L4R4eOYITLaKhJjA+PZSNPAbjV1GfYk9His5iYyCm eTnJhh3dReN7IfNXcX+q0EKns4R/OeQvvbYP/E4= X-Google-Smtp-Source: ADUXVKIrV0meGjiTIYRLIG9WOfuTWSCMS/qrnVw4moyy04oLsGAUU9C9VxK253x72MBLjNqKlNIofd5St8iT43G+KKg= X-Received: by 2002:a65:5d09:: with SMTP id e9-v6mr10248640pgr.150.1529312381544; Mon, 18 Jun 2018 01:59:41 -0700 (PDT) MIME-Version: 1.0 References: <20180617095948.6357f96a@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20180617095948.6357f96a@thor.intern.walstatt.dynvpn.de> From: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Date: Mon, 18 Jun 2018 10:59:27 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: r335282: first stage boot failure on PCengines APU 2C4 To: "O. Hartmann" Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 18 Jun 2018 08:59:43 -0000 On Sun, Jun 17, 2018 at 10:01 AM O. Hartmann wrote= : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Running CURRENT as routing and firewalling appliance on a PCengines APU > 2C4 with the > latest (official) SEABios available for this product, NanoBSD (FreeBSD > CURRENT FreeBSD > 12.0-CURRENT #60 r335278: Sun Jun 17 07:57:20 CEST 2018 amd64)is unable t= o > boot recent > OS at the first stage (GPT partitioning, SD card memory). > > =E2=80=8BHi, My nanobsd images are based on : [root@apu2]~# uname -a FreeBSD apu2 12.0-CURRENT FreeBSD 12.0-CURRENT r335286M amd64 And I don't remember to have upgraded its BIOS: [root@apu2]~# kenv smbios.bios.reldate 03/07/2016 [root@apu2]~# kenv smbios.system.product apu2 But I'm using MBR partitionning on a mSATA disk. Regards From owner-freebsd-current@freebsd.org Mon Jun 18 13:42:33 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2FF471008408 for ; Mon, 18 Jun 2018 13:42:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::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 BB9FE7F947 for ; Mon, 18 Jun 2018 13:42:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x229.google.com with SMTP id g22-v6so16847015iob.7 for ; Mon, 18 Jun 2018 06:42:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UDszerYxj2b0zY+KHHclXND5v9UuoLyJXEA9E5+jNSA=; b=i543szbId0u36rf95WYrJF1M/Od/mv30mY+ueHVrm6uyZQpMXmYg4M3uKKsW03lTI2 56M+waCAAERgS2CXN0T7Uz1Xq4LZ303soGj2qsVUtBpBRCfdts4yGt1zygApNNVm8w/h tYT5RMM0EdQD2b+70CCzcnrJMNiU9PmqGFABTjMFaSpVzhQDVr0jZSViq8Saux4ABsRw Ga8CHq3CKDuwwdwsef80l0Dblx4kxpSz241JPzufyRUQDLsqQnPncttl7da2FaaGXqm2 A2K2+Z6N52JWG0HW6gum+FXZRtt+9+Ly5YaSItATt5DYVTLoBS7J8XKLTX6tOGNJNgYP AzQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UDszerYxj2b0zY+KHHclXND5v9UuoLyJXEA9E5+jNSA=; b=LhkNDmGsJQkDitNw6exkQYLCBeOgmFB3Q/gAFydzfZfkZrj5QFPc52Hqjk7J+T6E6C mOifbdJfQ1ku370Xa19wzjR0KIqagTlTkp71KRs3xs6H7sq3G/CC+BAIS6cIIx3sDNyR lkLmvZ6nMD4tFL7LwhxLhvEjuKmrzrG+vTYl8SgbHvFdBVLWav43oQz5r/eNT3cASu6b 9Jh+IXcUfWZfdH4yOUd6bOCPYI0HopvVf8MDzCyQfxN1htuYp8hnB+7VBkWL05LZVoIj fjgHCwxfR+WZD5O6UWkdrAI/LtxlM3PP+piBL2JxHj51ZVlfhq6PIAt/+WlnZ/z+TtHC KrtQ== X-Gm-Message-State: APt69E2+fF9OMJs0g+gPOMcDr11Ba2lKHuZDX5bH/P8caVmRW1c5Lj3H yQs2zj+aAJOfijKX9wa6YurNHxiYcR2Rkj62PTeakQ== X-Google-Smtp-Source: ADUXVKJGdSGPBlMMOu1v0uFhKfkoqcPIoqb2gCE2YFMeZF4AVzTieV5xZxmhh6dx++OVSrVrcBHF1PxnehOl0pERcds= X-Received: by 2002:a6b:284b:: with SMTP id o72-v6mr10055715ioo.168.1529329351893; Mon, 18 Jun 2018 06:42:31 -0700 (PDT) MIME-Version: 1.0 References: <20180617095948.6357f96a@thor.intern.walstatt.dynvpn.de> In-Reply-To: From: Warner Losh Date: Mon, 18 Jun 2018 07:42:20 -0600 Message-ID: Subject: Re: r335282: first stage boot failure on PCengines APU 2C4 To: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Cc: "O. Hartmann" , FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 18 Jun 2018 13:42:33 -0000 On Mon, Jun 18, 2018, 3:01 AM Olivier Cochard-Labb=C3=A9 wrote: > On Sun, Jun 17, 2018 at 10:01 AM O. Hartmann > wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > Running CURRENT as routing and firewalling appliance on a PCengines APU > > 2C4 with the > > latest (official) SEABios available for this product, NanoBSD (FreeBSD > > CURRENT FreeBSD > > 12.0-CURRENT #60 r335278: Sun Jun 17 07:57:20 CEST 2018 amd64)is unable > to > > boot recent > > OS at the first stage (GPT partitioning, SD card memory). > > > > =E2=80=8BHi, > > > My nanobsd images are based on : > [root@apu2]~# uname -a > FreeBSD apu2 12.0-CURRENT FreeBSD 12.0-CURRENT r335286M amd64 > > And I don't remember to have upgraded its BIOS: > [root@apu2]~# kenv smbios.bios.reldate > 03/07/2016 > [root@apu2]~# kenv smbios.system.product > apu2 > > But I'm using MBR partitionning on a mSATA disk. > Do you know the first version to have this problem? Are you using geli? Warner > From owner-freebsd-current@freebsd.org Mon Jun 18 14:09:32 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B5DE1009F5D for ; Mon, 18 Jun 2018 14:09:32 +0000 (UTC) (envelope-from mike@sentex.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9FBB180D37 for ; Mon, 18 Jun 2018 14:09:31 +0000 (UTC) (envelope-from mike@sentex.net) Received: by mailman.ysv.freebsd.org (Postfix) id 5FDAE1009F5B; Mon, 18 Jun 2018 14:09:31 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D7F51009F59 for ; Mon, 18 Jun 2018 14:09:31 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [IPv6:2607:f3e0:80:80::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DA3EA80D32; Mon, 18 Jun 2018 14:09:30 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5::11]) by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id w5IE9Ts7005498 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 18 Jun 2018 10:09:30 -0400 (EDT) (envelope-from mike@sentex.net) Received: from [192.168.43.26] (saphire3.sentex.net [192.168.43.26]) by lava.sentex.ca (8.15.2/8.15.2) with ESMTP id w5IE9SgQ052287; Mon, 18 Jun 2018 10:09:28 -0400 (EDT) (envelope-from mike@sentex.net) Subject: Re: Ryzen public erratas To: Konstantin Belousov , current@freebsd.org References: <20180613103535.GP2493@kib.kiev.ua> From: Mike Tancsa Openpgp: preference=signencrypt Autocrypt: addr=mike@sentex.net; prefer-encrypt=mutual; keydata= xsBNBEzcA24BCACpwI/iqOrs0GfQSfhA1v6Z8AcXVeGsRyKEKUpxoOYxXWc2z3vndbYlIP6E YJeifzKhS/9E+VjhhICaepLHfw865TDTUPr5D0Ed+edSsKjlnDtb6hfNJC00P7eoiuvi85TW F/gAxRY269A5d856bYrzLbkWp2lKUR3Bg6NnORtflGzx9ZWAltZbjYjjRqegPv0EQNYcHqWo eRpXilEo1ahT6nmOU8V7yEvT2j4wlLcQ6qg7w+N/vcBvyd/weiwHU+vTQ9mT61x5/wUrQhdw 2gJHeQXeDGMJV49RT2EEz+QVxaf477eyWsdQzPVjAKRMT3BVdK8WvpYAEfBAbXmkboOxABEB AAHNHG1pa2UgdGFuY3NhIDxtaWtlQHNlbnRleC5jYT7CwHgEEwECACIFAkzcA24CGwMGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEJXHwM2kc8rX+sMH/2V6pTBKsQ5mpWWLgs6wVP2k BC+6r/YKNXv9Rw/PrC6+9hTbgA+sSjJ+8gxsCbJsOQXZrxF0x3l9oYdYfuKcwdwXFX1/FS8p HfBeDkmlH+dI709xT9wgrR4dS5aMmKp0scPrXPIAKiYVOHjOlNItcLYTEEWEFBepheEVsgmk GrNbcrHwOx/u4igUQ8vcpyXPyUki+BsftPw8ZQvBU887igh0OxaCR8AurJppQ5UQd63r81cX E1ZjoFoWCaGK/SjPb/OhpYpu5swoZIhOxQbn7OtakYPsDd5t2A5KhvjI8BMTnd5Go+2xsCmr jlIEq8Bi29gCcfQUvNiClevi13ifmnnOwE0ETNwDbgEIALWGNJHRAhpd0A4vtd3G0oRqMBcM FGThQr3qORmEBTPPEomTdBaHcn+Xl+3YUvTBD/67/mutWBwgp2R5gQOSqcM7axvgMSHbKqBL 9sd1LsLw0UT2O5AYxv3EwzhG84pwRg3XcUqvWA4lA8tIj/1q4Jzi5qOkg1zxq4W9qr9oiYK5 bBR638JUvr3eHMaz/Nz+sDVFgwHmXZj3M6aE5Ce9reCGbvrae7H5D5PPvtT3r22X8SqfVAiO TFKedCf/6jbSOedPN931FJQYopj9P6b3m0nI3ZiCDVSqeyOAIBLzm+RBUIU3brzoxDhYR8pz CJc2sK8l6YjqivPakrD86bFDff8AEQEAAcLAXwQYAQIACQUCTNwDbgIbDAAKCRCVx8DNpHPK 1+iQB/99aqNtez9ZTBWELj269La8ntuRx6gCpzfPXfn6SDIfTItDxTh1hrdRVP5QNGGF5wus N4EMwXouskva1hbFX3Pv72csYSxxEJXjW16oV8WK4KjKXoskLg2RyRP4uXqL7Mp2ezNtVY5F 9nu3fj4ydpHCSaqKy5xd70A8D50PfZsFgkrsa5gdQhPiGGEdxhq/XSeAAnZ4uVLJKarH+mj5 MEhgZPEBWkGrbDZpezl9qbFcUem/uT9x8FYT/JIztMVh9qDcdP5tzANW5J7nvgXjska+VFGY ryZK4SPDczh74mn6GI/+RBi7OUzXXPgpPBrhS5FByjwCqjjsSpTjTds+NGIY Organization: Sentex Communications Message-ID: Date: Mon, 18 Jun 2018 10:09:29 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180613103535.GP2493@kib.kiev.ua> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.78 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 18 Jun 2018 14:09:32 -0000 On 6/13/2018 6:35 AM, Konstantin Belousov wrote: > > Please report the results. If the script helps, I will code the kernel > change to apply the workarounds. The hard lockups I was seeing on Ryzen and Epyc boxes are now gone with the microcode and script below. Not sure if its one or some combo of the settings, but all the steps below have made my 2 test systems stable on RELENG_11 anyways. This was on a Ryzen 5 1600X (ASUS PRIME X370-PRO BIOS from 04/19/2018) CPU Microcode patch level: 0x8001137 And EPYC 7281 16-Core (Supermicro H11SSL-i BIOS 04/27/2018 ) Microcode patch level: 0x8001227 Details of the issue were discussed at https://lists.freebsd.org/pipermail/freebsd-virtualization/2018-March/006187.html and https://lists.freebsd.org/pipermail/freebsd-stable/2018-January/088174.html TL;DR : Generating traffic via iperf3 between VMs either on bhyve or VirtualBox would make the box lockup-- no crash, just a blank screen ---Mike > > #!/bin/sh > > # Enable workarounds for erratas listed in > # https://developer.amd.com/wp-content/resources/55449_1.12.pdf > > # 1057, 1109 > sysctl machdep.idle_mwait=0 > sysctl machdep.idle=hlt > > for x in /dev/cpuctl*; do > # 1021 > cpucontrol -m '0xc0011029|=0x2000' $x > # 1033 > cpucontrol -m '0xc0011020|=0x10' $x > # 1049 > cpucontrol -m '0xc0011028|=0x10' $x > # 1095 > cpucontrol -m '0xc0011020|=0x200000000000000' $x > done > > _______________________________________________ > 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" > > -- ------------------- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada From owner-freebsd-current@freebsd.org Mon Jun 18 15:49:51 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 339BF100F4DC for ; Mon, 18 Jun 2018 15:49:51 +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 9E8A6850DB; Mon, 18 Jun 2018 15:49:50 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([85.180.179.66]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Mh9cj-1fqa1d1mlt-00MJBT; Mon, 18 Jun 2018 17:49:40 +0200 Date: Mon, 18 Jun 2018 17:49:06 +0200 From: "O. Hartmann" To: Warner Losh Cc: Olivier =?ISO-8859-1?Q?Cochard-Labb=E9?= , "O. Hartmann" , FreeBSD Current Subject: Re: r335282: first stage boot failure on PCengines APU 2C4 Message-ID: <20180618174933.2488349c@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <20180617095948.6357f96a@thor.intern.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Provags-ID: V03:K1:G7hJlKTgSRJxFkSujW+HJqz6nVhKUSDLNUmIHTMhpQcql9+3rgc 3dtZ+QmjDLb2XrGZXgxRK1/MalYHs19XC20TCBeJ9EULiUbWsnMsQwgfxvI9+12A6UELuOx eqn52Dm9mICdX9BX/hVfM8SrojhuWYnqLwYUBecVmCHAE+KW6W5+2gL3nJ8V172EmbNX+Fu b8gCck1YzYBR+K3cTqDYA== X-UI-Out-Filterresults: notjunk:1;V01:K0:TMxIs9eohG0=:K3Ocr7k0q4wjAIgMa0+uKf NxxcuNzaK+f4nKwt5/bV6GvSxmyzXh1Yh2Z1NSWG/yd3UoXUN8VKU9oLuvQsE1Z8zlgy5arvg d02hnx7qgL1kCRNMS7Eo8EdN7RTXpqOLI3kA5o8g5p6xrlDdgTwTBVhfrBxXeLUxGcPEhOVlU sRR1wuIJMmnDAcasUIczD7KfZP7CMsXp3EYFtdmMdp3q5pPpdeerHvxh6l3/PMbpL0/NptmB3 XKD0NlsFQyPpoalXL1+2UQauNPo6uJtRZ//k3BqNCof7QsakPlPDqPS2Mamxyp8Iy2CnD7L+9 4ybzVRNy5ZBV2wZfCMhV00fmKenTZuKOOtW5XLHSAbp4+fhtQw5WH6qZ5pLUp33gYSanT+yUU giAi2Zkh2Lv8QnAFmOnQ/i9wKYMobt7+pXP9j29GStbMnH6mKCRJF65X1MegjbEbAnH8aIEMs rne1jkvFEOmgrGkpv0uBQJUdNx/DjyttpTzCy3KbL7y2pOWhkggsRTej4rseK5iY+fUitZoAx wJzKwj7YaevdqmCADwXu4LnfVu1aNXuv8hiGcxjUjaQeDlSzYDyh4J/ezqJpRIUfPyWvWBgly Glgttk9fQfqwl6GVYwYkhMMWQdIKZV6c/32jgQ8uWfzD5uQXWwFxQbM5ScCTTZ+5F8EUA37Eb f73eT/fimcK/X3ctH+aGuFosTXbpXqQRzadSNVke4alyw6EURUwVsBz6r/2/5hHCdP6fcZ9xO i9m0sZL4XusokP4og+lDMpCu32W63hXPYIk4RR9oyOaKJVPojS/rbAyiRURSrhJRk/hvZsCRR OBiiFyz X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 18 Jun 2018 15:49:51 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBNTEyDQoNCkFtIE1v biwgMTggSnVuIDIwMTggMDc6NDI6MjAgLTA2MDANCldhcm5lciBMb3NoIDxpbXBAYnNkaW1wLmNv bT4gc2NocmllYjoNCg0KPiBPbiBNb24sIEp1biAxOCwgMjAxOCwgMzowMSBBTSBPbGl2aWVyIENv Y2hhcmQtTGFiYsOpIDxvbGl2aWVyQGZyZWVic2Qub3JnPg0KPiB3cm90ZToNCj4gDQo+ID4gT24g U3VuLCBKdW4gMTcsIDIwMTggYXQgMTA6MDEgQU0gTy4gSGFydG1hbm4gPG9oYXJ0bWFubkB3YWxz dGF0dC5vcmc+DQo+ID4gd3JvdGU6DQo+ID4gIA0KPiA+ID4gLS0tLS1CRUdJTiBQR1AgU0lHTkVE IE1FU1NBR0UtLS0tLQ0KPiA+ID4gSGFzaDogU0hBNTEyDQo+ID4gPg0KPiA+ID4gUnVubmluZyBD VVJSRU5UIGFzIHJvdXRpbmcgYW5kIGZpcmV3YWxsaW5nIGFwcGxpYW5jZSBvbiBhIFBDZW5naW5l cyBBUFUNCj4gPiA+IDJDNCB3aXRoIHRoZQ0KPiA+ID4gbGF0ZXN0IChvZmZpY2lhbCkgU0VBQmlv cyBhdmFpbGFibGUgZm9yIHRoaXMgcHJvZHVjdCwgTmFub0JTRCAoRnJlZUJTRA0KPiA+ID4gQ1VS UkVOVCBGcmVlQlNEDQo+ID4gPiAxMi4wLUNVUlJFTlQgIzYwIHIzMzUyNzg6IFN1biBKdW4gMTcg MDc6NTc6MjAgQ0VTVCAyMDE4IGFtZDY0KWlzIHVuYWJsZSAgDQo+ID4gdG8gIA0KPiA+ID4gYm9v dCByZWNlbnQNCj4gPiA+IE9TIGF0IHRoZSBmaXJzdCBzdGFnZSAoR1BUIHBhcnRpdGlvbmluZywg U0QgY2FyZCBtZW1vcnkpLg0KPiA+ID4NCj4gPiA+IOKAi0hpLCAgDQo+ID4NCj4gPg0KPiA+IE15 IG5hbm9ic2QgaW1hZ2VzIGFyZSBiYXNlZCBvbiA6DQo+ID4gW3Jvb3RAYXB1Ml1+IyB1bmFtZSAt YQ0KPiA+IEZyZWVCU0QgYXB1MiAxMi4wLUNVUlJFTlQgRnJlZUJTRCAxMi4wLUNVUlJFTlQgIHIz MzUyODZNICBhbWQ2NA0KPiA+DQo+ID4gQW5kIEkgZG9uJ3QgcmVtZW1iZXIgdG8gaGF2ZSB1cGdy YWRlZCBpdHMgQklPUzoNCj4gPiBbcm9vdEBhcHUyXX4jIGtlbnYgc21iaW9zLmJpb3MucmVsZGF0 ZQ0KPiA+IDAzLzA3LzIwMTYNCj4gPiBbcm9vdEBhcHUyXX4jIGtlbnYgc21iaW9zLnN5c3RlbS5w cm9kdWN0DQo+ID4gYXB1Mg0KPiA+DQo+ID4gQnV0IEknbSB1c2luZyBNQlIgcGFydGl0aW9ubmlu ZyBvbiBhIG1TQVRBIGRpc2suDQo+ID4gIA0KPiANCj4gRG8geW91IGtub3cgdGhlIGZpcnN0IHZl cnNpb24gdG8gaGF2ZSB0aGlzIHByb2JsZW0/IEFyZSB5b3UgdXNpbmcgZ2VsaT8NCj4gDQo+IFdh cm5lcg0KPiANCj4gPiAgDQoNCg0KSGVsbG8sIA0KDQppZiB5b3UgYWRkcmVzc2VkIG1lICh3YXNu J3Qgc28gY2xlYXIgZnJvbSB5b3VyIHJlcGx5IG9uIE9saXZpZXIgQ29jaGFyZC1MYWJiw6kncw0K cmVwbHkgdG8gbWUpLCBJIGNvdWxkIGdpdmUgeW91IHRoaXMgaW5mb3JtYXRpb24gKEkgcG9zdGVk IGl0IHRvIEFsbGVuIEp1ZGUgaW4gcmVzcG9uc2UgdG8NCg0Kc3ZuIGNvbW1pdDogcjMzNTI1NCAt IGluIGhlYWQvc3RhbmQvaTM4NjogbGliaTM4NiB6ZnNib290DQoNCnByb2JhYmx5IHRoZSB3cm9u ZyBjb21taXQuIFBsZWFzZSBhbGxvdyBtZSB0byBjb3B5LXBhc3RlOg0KDQpbLi4uXQ0KDQpJIHJl YWxpc2VkIHRoYXQgQ1VSUkVOVCByMzM1MjIyIGZyb20gRnJpZGF5LCAxMHRoIEp1bmUgMjAxOCBi b290ZWQgd2l0aG91dCBwcm9ibGVtcw0KKE5hbm9CU0QsIHNsaWdodGx5IG1vZGlmaWVkIHRvIGJv b3Qgb2ZmIEdQVC9VRUZJIHBhcnRpdGlvbnMsIGJ1dCBpbiBnZW5lcmFsIGEgc2ltcGxlDQoiZ3Bh cnQgYm9vdGNvZGUgLWIgcG1iciAtcCAvYm9vdC9ncHRib290IC1pIDIgbW1jc2QwIiBwcmVwYXJh dGlvbiBvZiBhIGRkJ2QgaW1hZ2UpLg0KQW5vdGhlciB0cnkgd2l0aCByZWNlbnQgcjMzNTI4MiBv biBhIEFQVSAyQzQsIGZyZXNobHkgYnVpbGQgTmFub0JTRCwgZmFpbHMgdG8gYm9vdA0KZmlyc3Rz dGFnZTogdGhlIChtb3N0IHJlY2VudCkgU0VBQmlvcyBzdG9wcHMgZm9yIGV2ZXIgYXQgdGVsbGlu ZyAiQm9vdGluZyBmcm9tIGhhcmQNCmRpc2siOyB3ZXJlIHVzdWFsbHkgYSBjYXJyZXQgc3RhcnRz IHRvIHNwaW5uIHRoZXJlIGlzIHZhc3QgZW1wdHluZXNzLiBQcmVwYXJpbmcgdGhlIGJvb3QNCnBh cnRpdGlvbiB3aXRoIGFuIG9sZGVyIGJvb3Rjb2RlIG9uIHRoYXQgdmVyeSBzYW1lIFNEIGNhcmQg dmlhICJncGFydCBib290Y29kZSAtYiBwbWJyDQotIC0gLXAgL2Jvb3QvZ3B0Ym9vdCAtaSAyIG1t Y3NkMCIgd2l0aCBhbiBvbGRlciBib290ZWQgaW1hZ2Ugb2YgQ1VSUkVOVCBoYXMgc29sdmVkIHRo ZQ0KcHJvYmxlbS4gVGhlIGxheW91dCBvZiB0aGUgU0QgY2FyZCBpcyBhcyBmb2xsb3dzLCBqdXN0 IGZvciB0aGUgcmVjb3JkOg0KDQojOiBncGFydCBzaG93IG1tY3NkMA0KPT4gICAgICA0MCAgNjA3 NTE3OTIgIG1tY3NkMCAgR1BUICAoMjlHKSAgDQogICAgICAgIDQwICAgICAgMTAyNCAgICAgICAy ICBmcmVlYnNkLWJvb3QgICg1MTJLKQ0KICAgICAgMTA2NCAgIDIyMDU5NDQgICAgICAgMyAgZnJl ZWJzZC11ZnMgICgxLjFHKQ0KICAgMjIwNzAwOCAgIDIyMTAxMjcgICAgICAgNCAgZnJlZWJzZC11 ZnMgICgxLjFHKQ0KICAgNDQxNzEzNSAgIDEwNDg1NzYgICAgICAgNSAgZnJlZWJzZC11ZnMgICg1 MTJNKQ0KICAgNTQ2NTcxMSAgNTUyODYxMjEgICAgICAgICAgLSBmcmVlIC0gICgyNkcpDQoNClsu Li5dDQoNCkkgZGlkbid0IGJpLXNlY3QgdGhlIGlzc3VlIGR1IHRvIHRpbWUgY29uc3RyYWludHMs IGJ1dCBpZiBpdCBoZWxwcywgSSBjb3VsZCB0cnkuIEkNCnJlc29sdmVkIHRoZSBwcm9ibGVtIHRl bXBvcmFyZWx5IGJ5IHdyaXRpbmcgdGhlIGJvb3Rjb2RlIGFuZCBwYXJ0aXRpb24gY29kZSBmcm9t IGFuIG9sZGVyDQppbWFnZS4NCg0KVGhlIEFQVSBpcyBzZXJpYWwgY29uc29sZSBvbmx5Lg0KDQpL aW5kIHJlZ2FyZHMsDQoNCk9saXZlciBIYXJ0bWFubg0KDQoNCi0gLS0gDQpPLiBIYXJ0bWFubg0K DQpJY2ggd2lkZXJzcHJlY2hlIGRlciBOdXR6dW5nIG9kZXIgw5xiZXJtaXR0bHVuZyBtZWluZXIg RGF0ZW4gZsO8cg0KV2VyYmV6d2Vja2Ugb2RlciBmw7xyIGRpZSBNYXJrdC0gb2RlciBNZWludW5n c2ZvcnNjaHVuZyAowqcgMjggQWJzLiA0IEJEU0cpLg0KLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJF LS0tLS0NCg0KaUxVRUFSTUtBQjBXSVFRWlZaTXpBdHdDMlQvODZUclM1MjhmeUZoWWxBVUNXeWZV alFBS0NSRFM1MjhmeUZoWQ0KbEpaNkFmd09lSG5BMDFrcE14UWdFdGtJYW9DWUdvYTF3ZXR5c3Mx SHZrSmova29scGx3SlQ5bVZSS3lwTGpaYg0KQ1d4UytsZEh5eTJsaHM5UTFkSXJybTY0VGZWYkFn Q0FjM29aeXVPdHpvTzkrQ2JNb3BtVXd0NUZxRkJHbi9iMA0KQUk3dzdtVnUrRXpXd3cvUXgvNzNF OThqNkx0WklqQjhqcEhHYzBscWxwRHdENkhMNUlIdA0KPW1GRDANCi0tLS0tRU5EIFBHUCBTSUdO QVRVUkUtLS0tLQ0K From owner-freebsd-current@freebsd.org Mon Jun 18 17:32:33 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A43601014DCF for ; Mon, 18 Jun 2018 17:32:33 +0000 (UTC) (envelope-from lausts@acm.org) Received: from cdptpa-cmomta01.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 153E469270 for ; Mon, 18 Jun 2018 17:32:32 +0000 (UTC) (envelope-from lausts@acm.org) Received: from mail.laus.org ([65.29.112.189]) by cmsmtp with ESMTP id Ux5pfKeSDsMBqUx61fbH3P; Mon, 18 Jun 2018 16:33:44 +0000 Received: from [192.168.1.100] (presario [192.168.1.100]) by mail.laus.org (8.15.2/8.15.2) with ESMTPS id w5IGgGEq053847 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 18 Jun 2018 12:42:17 -0400 (EDT) (envelope-from lausts@acm.org) X-Authentication-Warning: mail.laus.org: Host presario [192.168.1.100] claimed to be [192.168.1.100] Reply-To: lausts@acm.org To: FreeBSD Current From: Thomas Laus Subject: Current @ r335314 not bootable with Geli and ZFS Openpgp: preference=signencrypt Autocrypt: addr=lausts@acm.org; prefer-encrypt=mutual; keydata= xsDiBDx1NWwRBADARalI5I8kGeBYYYWnZB73T1fU4333yCuRokRvzlAZ5Zhb3hqsNdTEMheN FDjZSL8J5jeJtvSRinY2p09CxpAMoJR9zHLmHl+zEOY8fInbB+KiFtSfGf0blSEY9/+isQP9 xmUIQWUj0kwVtrns7m1HrYLiI07NVFzbHNKqQcbPuwCg0n/KKi+VJiUs5MqLKwGuPotGeZME AIluMetTQwfLyovundMwFYlSZ/Z8JjkMybqgKuiRrZnaBVVZ80NjAYZI73yAZPfQh9mvFxW9 ipc2tSALwDy/tYDpQRK0k+0EsDmwG/wM6OarkqSuFcYx+tP86+2+6Xitn6E/hriIWa/ZQVef /fx7dZzdwhXH6fd34v8o/BuqhawLBACs4MTMGbdSmyI56vCMXWY1yxRPmuygd4vUnXqYwlrM Ee/LjQdreg1zTAJnnW1K+PgOUW/jvS+uAbgxLa3i59/Z4Uu7nB6G1y+Y1cThojUsLnvoJlt1 4XE1U/vnOcvO3evo6knB1qjbAMsZGaVleiVKDq+7XE7swe4WtBJKbYJthc0cVGhvbWFzIExh dXMgPGxhdXN0c0BhY20ub3JnPsJ/BBMRAgA/AheAAh4BBgsJCAcDAgYVCAIJCgsEFgIDAQIZ ARYhBBloSoDtPqFEokqZd+v/gtRiCDbPBQJaRO3QBQkfyKbkAAoJEOv/gtRiCDbPi+UAnAm8 +zuC7S1JQEjx/OU4asYWvLdcAJ0V59C0iowNwnxyPHBnYBQpOoDScc7BTQRFspgcEAgAjXsi 9WqowAKZ7d2ix6t7fiYgu2QBGWq36NvN+cPBJIu0CnagL1v4W1UrRW/0cInLzgqlWrSU7SFg y1+rGBlusMHf8/faGeZD0XwMdYgTIYdjdK5VZ0GaRWUs0LbHAOJQkOFRHLMAEG8wrc3f1xrn uVJ4JPOA81kTmTXvYTyQNXJBySc0oNSgvSut8aBbNGBZhw9U2V3yXXnnMeWR8+DYrriYdOdR eK7S0LNN8TPY60PJx3KLN9vUY9Cb5Ly0NavF3wREPQqYlNfTMoG/GA/n8XB6SCoMj73oKCyw FLbckBUjFsl7wTeKKvU68V8kWG762fscXhOhRduETGrja09MbwADBQf/WiycmdfNtB41+vvT HQqz9tm3ZHAW2yE53CxfQpvlyS/KwnWgLjl/iV0SHRDede0NJ5yTEqPVhqq7WCdlqVsHPSpX FfvyOgbNmjPmOY/a1nW4UnWSqA7bgQvkthahhoLeHzkU8YKupW0m05RIBpqQER6HwBOksTq4 sWV/lUy1P0VT8GqqPLNklKe2BEu+KhuhLV6XwEG3VrHNoY6/R5CMGvBhZbtiUViCZktmxJAj Fq0VCcuj7+Oo52eq4BL2vMrzLX+2Ib1JSWid6t0N+grXxbr2mv7H2V2/4Vo0XI3IKxPX1mdG y9RBkbRUGyV9A8RlaS0QTnXvsxZTjOnmjxPX68JPBBgRAgAPAhsMBQJLQftKBQkHcJauAAoJ EOv/gtRiCDbPjFIAn3xxpJ7L5KEAO31jgTyxZX1iLIqYAJ9pXvy5sGrjA8HQlOy9BR0FM6IG JMJPBBgRAgAPAhsMBQJQ9ZV5BQkNJDDXAAoJEOv/gtRiCDbPHHkAn3yVaT4ZzTxbTzWFRPWF QceKmgYYAJ9Oowt+YhIp5mNPUOE6GT1oU9g5XMJmBBgRAgAmAhsMFiEEGWhKgO0+oUSiSpl3 6/+C1GIINs8FAlpE7dwFCRaLREAACgkQ6/+C1GIINs9JdgCfeHMtCRjzubbkAvAVg5wQo7gF moUAoL39iRV66xSZ0w/I00RnFU3jsmiz Message-ID: <61aeea9a-bb8b-65d0-1ffb-f8fb7b2f121d@acm.org> Date: Mon, 18 Jun 2018 12:42:16 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfGAgC0SXMD+SY5UC1C8e7XQ4M5vfwLPPiftsmQJQPWdI5ImQfmWmnLH9WsDeNMGxks4MATd3mqPBy7BwUomf3Wq8oiA7oHH7Z2iiS9K8APBsoB7gM+CO qH5pTYCF5oAViKn4HjgRgtJ0uTc702UXAAmP6VKKd5n2wol0s+W1/HQWh//k7eB9pgvv1J4KFLJfcymuW4a1WlXeIrlfjbwgEoHngn+Aqf/No75rPaHNY3jl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 18 Jun 2018 17:32:34 -0000 Something changed in /boot/gptzfsboot between r334610 and r335314. I built current this morning and my system is un-bootable. I am using redundant ZFS disks and only copied the updated /boot/gptzfsboot file to my ada0 drive. I was able to boot the ada1 drive that still had the gptzfsboot file from r334610. I had a similar issue a few months ago with the upgrades to the Geli + ZFS booting process. These were resolved and operation has been fine since the last 'hick-up' in the testing process. I might not be the only person running the combination of Geli encryption and using a ZFS filesystem, but it should not be that much uncommon setup that I am the first to report the problem. Let me know far back I need to revert my sources to identify the commit that broke gptzfsboot. My system goes into a continuous reboot loop before presenting the password prompt. It is very early in the startup process. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From owner-freebsd-current@freebsd.org Mon Jun 18 19:42:54 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2EBFC101D067; Mon, 18 Jun 2018 19:42:54 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CA1CE6F053; Mon, 18 Jun 2018 19:42:53 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 7B3C31F4AF; Mon, 18 Jun 2018 19:42:53 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 6B9DC1ED1; Mon, 18 Jun 2018 19:42:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id w5565oght_7j; Mon, 18 Jun 2018 19:42:50 +0000 (UTC) Subject: Re: A head buildworld race visible in the ci.freebsd.org build history DKIM-Filter: OpenDKIM Filter v2.10.3 mail.xzibition.com A186B1ECB To: FreeBSD Current , freebsd-toolchain@freebsd.org References: <74EAD684-0E0B-453A-B746-156777CF604A@yahoo.com> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Autocrypt: addr=bdrewery@FreeBSD.org; prefer-encrypt=mutual; keydata= xsBNBFJphmsBCADiFgmS4bIzwZijrS31SjEMzg+n5zNellgM+HkShwehpqCiyhXdWrvH6dTZ a6u50pbUIX7doTR7W7PQHCjCTqtpwvcj0eulZva+iHFp+XrbgSFHn+VVXgkYP2MFySyZRFab D2qqzJBEJofhpv4HvY6uQI5K99pMqKr1Z/lHqsijYYu4RH2OfwB5PinId7xeldzWEonVoCr+ rfxzO/UrgA6v/3layGZcKNHFjmc3NqoN1DXtdaEHqtjIozzbndVkH6lkFvIpIrI6i5ox8pwp VxsxLCr/4Musd5CWgHiet5kSw2SzNeA8FbxdLYCpXNVu+uBACEbCUP+CSNy3NVfEUxsBABEB AAHNJEJyeWFuIERyZXdlcnkgPGJkcmV3ZXJ5QEZyZWVCU0Qub3JnPsLAgAQTAQoAKgIbAwUL CQgHAwUVCgkICwUWAwIBAAIeAQIXgAIZAQUCWujOIgUJCmB7NwAKCRA113G7bkaXz/xpB/9b /UWIPbieY1IeIuHF2pyYPE7Hytkh3HVsxMA0F5Ma2AYQsXZZeKNKWrF7RPyDyDwUklLHJkhm k3EfClBbHxf08kMIm1vWCJRtgxic9knY/bzYGiWMpHjg3cSd1XfrYH1autYqTZAjDwIkgOjU dR//Tbn4V36sY7y2jz+kdMVWvK53U32aZqiwBbCn4DPe1wSZcUs17mV/0uZdIoGdj74B1orN A/0py5vHYo6HcbBNoaR8pKRLf5VZNRsxqGIMhTucx4SJWcHpuRBWYyvJSFzwvxdK4ZD4Yqoc kFGPVtOXktVMai9exrLvP3G77fKMu8DI6j4QRU4wCesnHuIfRPFuzsBNBFJphmsBCACiVFPf kNfaFtUSuY0395ueo/rMyHPGPQ2iwvERFCpeFGSQSgagpenNHLpFQKTg/dl6FOoST5tqyxMq fyHGHDzzU51bvA/IfaGoNi/BIhTe/toZNMRvpcI3PLjiGcnJnuwCCbAVOAGdb+t5cZtpNdOI cKYmrYG3u9RiBpe6dTF+qLrD/8Bs1wjhduQ8fcNNgnkXu8xDH4ZxY0lIc3QgvYWp9vimlQe6 iKjUd2/DX28ETZcD5h6pYV331KMPTrEI0p0yvFijUZce8c1XHFyL1j9sBAha5qpszJl6Uq5i LolhKRcGfcdmtD72vHQjUYglUyudSJUVyo2gMYjdbiFKzJulABEBAAHCwGUEGAEKAA8CGwwF AlrozigFCQpgez0ACgkQNddxu25Gl8+m5Af/R3VEdxNMAcDIes9ADhQyofj20SPV3eCJ3HYR OebTSuNdOudGt4AAyA8Ks94u9hiIp5IGsc6RDsT9W7O2vgXhd6eV3eiY5Oif5xLIYrIDVu1Y 1GyRxRrPEn/QOqDN6uFZCPwK1aOapGcYCrO9lB0gMuTVfgHanU61rgC9tMX0OoAOyRd+V3/M 8lDNhjJdF/IpO3SdYzKfkwduy4qamw4Gphcx/RfYQvYLq/eDkP8d50PphWdboqWBwNRHayro W/07OGzfxM5fJ5mBsXPQcO2QcRjkyHf6xCM6Hi1qQL4OnXMNE/ZTX0lnOj1/pH93TlzSHZMP TaiiA/MBD3vGsXBmBg== Organization: FreeBSD Message-ID: <1884103f-d1fb-aca6-2edd-062e11d05617@FreeBSD.org> Date: Mon, 18 Jun 2018 12:42:46 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <74EAD684-0E0B-453A-B746-156777CF604A@yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 18 Jun 2018 19:42:54 -0000 On 6/15/2018 10:55 PM, Mark Millard wrote: > In watching ci.freebsd.org builds I've seen a notable > number of one time failures, such as (example from > powerpc64): > > --- all_subdir_lib/libufs --- > ranlib -D libufs.a > ranlib: fatal: Failed to open 'libufs.a' > *** [libufs.a] Error code 70 > > where the next build works despite the change being > irrelevant to whatever ranlib complained about. > > Other builds failed similarly: > > --- all_subdir_lib/libbsm --- > ranlib -D libbsm_p.a > ranlib: fatal: Failed to open 'libbsm_p.a' > *** [libbsm_p.a] Error code 70 > > and: > > --- kerberos5/lib__L --- > ranlib -D libgssapi_spnego_p.a > --- libgssapi_spnego.a --- > ranlib -D libgssapi_spnego.a > --- libgssapi_spnego_p.a --- > ranlib: fatal: Failed to open 'libgssapi_spnego_p.a' > *** [libgssapi_spnego_p.a] Error code 70 > > and so on. > > > It is not limited to powerpc64. For example, for aarch64 > there are: > > --- libpam_exec.a --- > building static pam_exec library > ar -crD libpam_exec.a `NM='nm' NMFLAGS='' lorder pam_exec.o | tsort -q` > ranlib -D libpam_exec.a > ranlib: fatal: Failed to open 'libpam_exec.a' > *** [libpam_exec.a] Error code 70 > > and: > > --- all_subdir_lib/libusb --- > ranlib -D libusb.a > ranlib: fatal: Failed to open 'libusb.a' > *** [libusb.a] Error code 70 > > and: > > --- all_subdir_lib/libbsnmp --- > ranlib: fatal: Failed to open 'libbsnmp.a' > --- all_subdir_lib/ncurses --- > --- all_subdir_lib/ncurses/panelw --- > --- panel.pico --- > --- all_subdir_lib/libbsnmp --- > *** [libbsnmp.a] Error code 70 > > > Even amd64 gets such: > > --- libpcap.a --- > ranlib -D libpcap.a > ranlib: fatal: Failed to open 'libpcap.a' > *** [libpcap.a] Error code 70 > > and: > > > --- libkafs5.a --- > ranlib: fatal: Failed to open 'libkafs5.a' > --- libkafs5_p.a --- > ranlib: fatal: Failed to open 'libkafs5_p.a' > --- cddl/lib__L --- > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/lua/lbaselib.c:60:26: note: include the header or explicitly provide a declaration for 'toupper' > --- kerberos5/lib__L --- > *** [libkafs5_p.a] Error code 70 > > make[5]: stopped in /usr/src/kerberos5/lib/libkafs5 > --- libkafs5.a --- > *** [libkafs5.a] Error code 70 > > and: > > > --- lib__L --- > ranlib -D libclang_rt.asan_cxx-i386.a > ranlib: fatal: Failed to open 'libclang_rt.asan_cxx-i386.a' > *** [libclang_rt.asan_cxx-i386.a] Error code 70 > > > (Notice the variability in what .a the ranlib's fail for.) > > > > > I looked at this a few days ago and don't believe it's actually a build race. I think there is something wrong with the ar/ranlib on that system or something else. I've found no evidence of concurrent building of the .a files in question. -- Regards, Bryan Drewery From owner-freebsd-current@freebsd.org Mon Jun 18 20:45:15 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D2A4010210DD for ; Mon, 18 Jun 2018 20:45:14 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670058.outbound.protection.outlook.com [40.107.67.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT TLS CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B1F17277F for ; Mon, 18 Jun 2018 20:45:13 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM (52.132.44.24) by YTOPR0101MB0875.CANPRD01.PROD.OUTLOOK.COM (52.132.50.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.17; Mon, 18 Jun 2018 20:45:10 +0000 Received: from YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM ([fe80::d0eb:3783:7c99:2802]) by YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM ([fe80::d0eb:3783:7c99:2802%3]) with mapi id 15.20.0863.016; Mon, 18 Jun 2018 20:45:10 +0000 From: Rick Macklem To: "freebsd-current@freebsd.org" Subject: RFC: ESXi client is nasty, what should I do? Thread-Topic: ESXi client is nasty, what should I do? Thread-Index: AQHUB0T3g4YEIbGCQEirDTO8j4VRXQ== Date: Mon, 18 Jun 2018 20:45:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB0875; 7:QEi2t0i6MErxx8K9eTvwmEWLfo8zP6KZWkabl9av4vL8hswr0lvsIn8EoXY9XiAwWgh0uIf3IFr84l48qJxP0J8MUj3Uf1Q8YA0Y83bsC/BRAtXMOOw1cyxxM5ww/L08PPOilIAAcztsf+Hznx+EXH/EQtE/fD49fmbr8/8moS3c2cucvIYfx8dxO4ZRhvQgTTNMqn2ktgQACJR9aaSGJ7kvEyPeGO8hh3wZGftoW+f9xXCT0L0GOZFch3rN2LMO x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 632bee3b-1ce3-4d03-82cd-08d5d55c6256 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:YTOPR0101MB0875; x-ms-traffictypediagnostic: YTOPR0101MB0875: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:YTOPR0101MB0875; BCL:0; PCL:0; RULEID:; SRVR:YTOPR0101MB0875; x-forefront-prvs: 0707248B64 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39380400002)(396003)(366004)(39860400002)(189003)(199004)(106356001)(81156014)(2351001)(102836004)(478600001)(6506007)(53936002)(7696005)(3660700001)(14454004)(105586002)(74316002)(486006)(8676002)(3280700002)(476003)(305945005)(33656002)(5640700003)(68736007)(9686003)(5660300001)(81166006)(786003)(55016002)(2906002)(6436002)(316002)(26005)(86362001)(25786009)(2501003)(186003)(8936002)(97736004)(2900100001)(6916009)(5250100002)(74482002)(99286004)(12363001); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB0875; H:YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-microsoft-antispam-message-info: wZ2Cwazv4BFdtOUkryXvDFKJFm7+5ZKRrozKG4J3PcS62fFtGgPCTNKgLmS0p4g2mkfrDetWCqDpZjNI3pII8z8GmadAAXxKo6BMrj+jBZqjqA9k++UUClUGx8HF8Tgx53s1geViSGmq6VM7GnT7qYNluCsHIoKomB1He33KCLnvYfXwYQf2JwW3KWt6nJgVdBbJxEio6IvfiFMAKl8D7DkLNIQ7gAiyw70MgtIturlCJ6qTMDrDUHGhbp44b0iJcCkhxMjMYA0rUCb7elRoVThW/I0fJEoZ8uXpH3SmJaoLRwokSvR4omgprQSqK7YA+aOPLH7Fn35wIwQmviQ29Q== 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-Network-Message-Id: 632bee3b-1ce3-4d03-82cd-08d5d55c6256 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2018 20:45:10.5556 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB0875 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 18 Jun 2018 20:45:15 -0000 Hi, I realized that the subject line "ESXi NFSv4.1 client id is nasty" wouldn't= have indicated that I was looking for comments w.r.t. how to handle this poorly behaved client. Please go to the "ESXi NFSv4.1 client id is nasty" thread and comment. (It should be in the archive, if you already deleted it.) Thanks, rick= From owner-freebsd-current@freebsd.org Mon Jun 18 20:45:29 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94FC0102110E; Mon, 18 Jun 2018 20:45:29 +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 F3087727A4; Mon, 18 Jun 2018 20:45:28 +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 ESMTP id w5IKjIth018242; Mon, 18 Jun 2018 23:45:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w5IKjIth018242 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w5IKjIPp018240; Mon, 18 Jun 2018 23:45:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 18 Jun 2018 23:45:18 +0300 From: Konstantin Belousov To: Bryan Drewery Cc: FreeBSD Current , freebsd-toolchain@freebsd.org Subject: Re: A head buildworld race visible in the ci.freebsd.org build history Message-ID: <20180618204517.GD2430@kib.kiev.ua> References: <74EAD684-0E0B-453A-B746-156777CF604A@yahoo.com> <1884103f-d1fb-aca6-2edd-062e11d05617@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1884103f-d1fb-aca6-2edd-062e11d05617@FreeBSD.org> User-Agent: Mutt/1.10.0 (2018-05-17) 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.26 Precedence: 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, 18 Jun 2018 20:45:29 -0000 On Mon, Jun 18, 2018 at 12:42:46PM -0700, Bryan Drewery wrote: > On 6/15/2018 10:55 PM, Mark Millard wrote: > > In watching ci.freebsd.org builds I've seen a notable > > number of one time failures, such as (example from > > powerpc64): > > > > --- all_subdir_lib/libufs --- > > ranlib -D libufs.a > > ranlib: fatal: Failed to open 'libufs.a' > > *** [libufs.a] Error code 70 > > > > where the next build works despite the change being > > irrelevant to whatever ranlib complained about. > > > > Other builds failed similarly: > > > > --- all_subdir_lib/libbsm --- > > ranlib -D libbsm_p.a > > ranlib: fatal: Failed to open 'libbsm_p.a' > > *** [libbsm_p.a] Error code 70 > > > > and: > > > > --- kerberos5/lib__L --- > > ranlib -D libgssapi_spnego_p.a > > --- libgssapi_spnego.a --- > > ranlib -D libgssapi_spnego.a > > --- libgssapi_spnego_p.a --- > > ranlib: fatal: Failed to open 'libgssapi_spnego_p.a' > > *** [libgssapi_spnego_p.a] Error code 70 > > > > and so on. > > > > > > It is not limited to powerpc64. For example, for aarch64 > > there are: > > > > --- libpam_exec.a --- > > building static pam_exec library > > ar -crD libpam_exec.a `NM='nm' NMFLAGS='' lorder pam_exec.o | tsort -q` > > ranlib -D libpam_exec.a > > ranlib: fatal: Failed to open 'libpam_exec.a' > > *** [libpam_exec.a] Error code 70 > > > > and: > > > > --- all_subdir_lib/libusb --- > > ranlib -D libusb.a > > ranlib: fatal: Failed to open 'libusb.a' > > *** [libusb.a] Error code 70 > > > > and: > > > > --- all_subdir_lib/libbsnmp --- > > ranlib: fatal: Failed to open 'libbsnmp.a' > > --- all_subdir_lib/ncurses --- > > --- all_subdir_lib/ncurses/panelw --- > > --- panel.pico --- > > --- all_subdir_lib/libbsnmp --- > > *** [libbsnmp.a] Error code 70 > > > > > > Even amd64 gets such: > > > > --- libpcap.a --- > > ranlib -D libpcap.a > > ranlib: fatal: Failed to open 'libpcap.a' > > *** [libpcap.a] Error code 70 > > > > and: > > > > > > --- libkafs5.a --- > > ranlib: fatal: Failed to open 'libkafs5.a' > > --- libkafs5_p.a --- > > ranlib: fatal: Failed to open 'libkafs5_p.a' > > --- cddl/lib__L --- > > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/lua/lbaselib.c:60:26: note: include the header or explicitly provide a declaration for 'toupper' > > --- kerberos5/lib__L --- > > *** [libkafs5_p.a] Error code 70 > > > > make[5]: stopped in /usr/src/kerberos5/lib/libkafs5 > > --- libkafs5.a --- > > *** [libkafs5.a] Error code 70 > > > > and: > > > > > > --- lib__L --- > > ranlib -D libclang_rt.asan_cxx-i386.a > > ranlib: fatal: Failed to open 'libclang_rt.asan_cxx-i386.a' > > *** [libclang_rt.asan_cxx-i386.a] Error code 70 > > > > > > (Notice the variability in what .a the ranlib's fail for.) > > > > > > > > > > > > > I looked at this a few days ago and don't believe it's actually a build > race. I think there is something wrong with the ar/ranlib on that system > or something else. I've found no evidence of concurrent building of the > .a files in question. FWIW, I got the similar failure when I did last checks for the OFED commit. For me, it was libgcc.a. From owner-freebsd-current@freebsd.org Mon Jun 18 21:04:04 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EE83110220B9 for ; Mon, 18 Jun 2018 21:04:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-14.consmr.mail.bf2.yahoo.com (sonic315-14.consmr.mail.bf2.yahoo.com [74.6.134.124]) (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 8919A73492 for ; Mon, 18 Jun 2018 21:04:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 2.xnMiQVM1mPBDRCc8fgBS7k7RJUpmZIm9TVI9QnI1qilhqgYPWyIMDXs1xr3.o LpTh9ChGWYzH55cUlPODPav6WvmXQ9RiD0VSRDAVBeXz9YU8eSbQ.sAGszw53gD.sjaNfhdk1W.k wBLVsGKl30cYnBc6ZbwTRgFeP6.gzulPGTjtKklC9fGCKzRxRO7sT90MEulQ1E6m1zgSzYfxQraP b1e2I9v5elTN0IHB7z13zEDRIFQiYlTG8s9EGXTzesKJ.MiIbVoGrOW2CRyA2wji.8YEdTFOptcX 6UHZ_zxXZHbze.0Q1BMDj8rVbowmWnc3LUpIuD6GW2SbcOGiM8SWC2P.Iu4c7V5yJlAVuEQ.LEsx bmeIWWjIfGrVv7kGvGjbKNf9Cy.h1yuuZpnWQ5VOB_blpC6jXQrmQRGUNKZs6iLIxX1sKxj9D.tL HvELx2vJesXAkMrsTlq.ofb86vWcKzQPAWPA_gcUHb1ckwng9FISdsfAjnmpIThfsPuyO1coXNYk Y6YPIlmahNeWXRNCZv4GntWQMEmWnRmoOwGVUYHb.waMdGA6P68T6AZdEBFjRfxT8kjOdJSvAqfs l1nVg4WxbxGwgcZFSUwnik7u3tpjgM4sxYUISp36iDoUdWvFAo4arSdQdImKz8YKMekSMEnQneF1 XKiV9.RXrrrNh_.SxqtjbE.XNnoY2Zno9vh8LUCBNvvt2vwgmLgK8cOSjYVHrPGBdxJLW7k66TmR a_PWujsEJlE8D3Qi2k8RWsCOpr2bsgHyo9kIcHi6h0KlFtUfmswcWU3H1cCvKpT.QEA9hhvWbRXh jUlhA4WTz3uH7StVLBhST7KUv.gryTzs9x4uSP3DF60gfsI2C2mrOL6PFL0Efew4yilwlIGvPF4d 45EUmoacDjduxYLaGnzQYQ8i9t0Po21Qi9o3zhSRy0kKZgcKzgSQXHnUIfYZynYIsAWyNV77wstV X1ryWyjc- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Mon, 18 Jun 2018 21:04:02 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp425.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 36dabd92943931ea5e5de27a58f89af2; Mon, 18 Jun 2018 21:03:59 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: A head buildworld race visible in the ci.freebsd.org build history From: Mark Millard In-Reply-To: <1884103f-d1fb-aca6-2edd-062e11d05617@FreeBSD.org> Date: Mon, 18 Jun 2018 14:03:56 -0700 Cc: FreeBSD Current , freebsd-toolchain@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <74EAD684-0E0B-453A-B746-156777CF604A@yahoo.com> <1884103f-d1fb-aca6-2edd-062e11d05617@FreeBSD.org> To: Bryan Drewery X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 18 Jun 2018 21:04:04 -0000 On 2018-Jun-18, at 12:42 PM, Bryan Drewery = wrote: > On 6/15/2018 10:55 PM, Mark Millard wrote: >> In watching ci.freebsd.org builds I've seen a notable >> number of one time failures, such as (example from >> powerpc64): >>=20 >> --- all_subdir_lib/libufs --- >> ranlib -D libufs.a >> ranlib: fatal: Failed to open 'libufs.a' >> *** [libufs.a] Error code 70 >>=20 >> where the next build works despite the change being >> irrelevant to whatever ranlib complained about. >>=20 >> Other builds failed similarly: >>=20 >> --- all_subdir_lib/libbsm --- >> ranlib -D libbsm_p.a >> ranlib: fatal: Failed to open 'libbsm_p.a' >> *** [libbsm_p.a] Error code 70 >>=20 >> and: >>=20 >> --- kerberos5/lib__L --- >> ranlib -D libgssapi_spnego_p.a >> --- libgssapi_spnego.a --- >> ranlib -D libgssapi_spnego.a >> --- libgssapi_spnego_p.a --- >> ranlib: fatal: Failed to open 'libgssapi_spnego_p.a' >> *** [libgssapi_spnego_p.a] Error code 70 >>=20 >> and so on. >>=20 >>=20 >> It is not limited to powerpc64. For example, for aarch64 >> there are: >>=20 >> --- libpam_exec.a --- >> building static pam_exec library >> ar -crD libpam_exec.a `NM=3D'nm' NMFLAGS=3D'' lorder pam_exec.o | = tsort -q`=20 >> ranlib -D libpam_exec.a >> ranlib: fatal: Failed to open 'libpam_exec.a' >> *** [libpam_exec.a] Error code 70 >>=20 >> and: >>=20 >> --- all_subdir_lib/libusb --- >> ranlib -D libusb.a >> ranlib: fatal: Failed to open 'libusb.a' >> *** [libusb.a] Error code 70 >>=20 >> and: >>=20 >> --- all_subdir_lib/libbsnmp --- >> ranlib: fatal: Failed to open 'libbsnmp.a' >> --- all_subdir_lib/ncurses --- >> --- all_subdir_lib/ncurses/panelw --- >> --- panel.pico --- >> --- all_subdir_lib/libbsnmp --- >> *** [libbsnmp.a] Error code 70 >>=20 >>=20 >> Even amd64 gets such: >>=20 >> --- libpcap.a --- >> ranlib -D libpcap.a >> ranlib: fatal: Failed to open 'libpcap.a' >> *** [libpcap.a] Error code 70 >>=20 >> and: >>=20 >>=20 >> --- libkafs5.a --- >> ranlib: fatal: Failed to open 'libkafs5.a' >> --- libkafs5_p.a --- >> ranlib: fatal: Failed to open 'libkafs5_p.a' >> --- cddl/lib__L --- >> = /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/lua/lbaselib.c:60:= 26: note: include the header or explicitly provide a = declaration for 'toupper' >> --- kerberos5/lib__L --- >> *** [libkafs5_p.a] Error code 70 >>=20 >> make[5]: stopped in /usr/src/kerberos5/lib/libkafs5 >> --- libkafs5.a --- >> *** [libkafs5.a] Error code 70 >>=20 >> and: >>=20 >>=20 >> --- lib__L --- >> ranlib -D libclang_rt.asan_cxx-i386.a >> ranlib: fatal: Failed to open 'libclang_rt.asan_cxx-i386.a' >> *** [libclang_rt.asan_cxx-i386.a] Error code 70 >>=20 >>=20 >> (Notice the variability in what .a the ranlib's fail for.) >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 > I looked at this a few days ago and don't believe it's actually a = build > race. I think there is something wrong with the ar/ranlib on that = system > or something else. I've found no evidence of concurrent building of = the > .a files in question. Looking at a bunch of the failures, spanning multiple FreeBSD-head-*-build types of builds, I see only: NODE_LABELS bhyve_host butler1.nyi.freebsd.org jailer jailer_fast NODE_NAME butler1.nyi.freebsd.org for the failures that I looked at. So your "on that system" might well be correct. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Mon Jun 18 21:21:26 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0586B1022FD2 for ; Mon, 18 Jun 2018 21:21:26 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mouf.net", Issuer "mouf.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A0F4A73F29 for ; Mon, 18 Jun 2018 21:21:25 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from lrrr.mouf.net (cpe-24-163-43-246.nc.res.rr.com [24.163.43.246]) (authenticated bits=0) by mouf.net (8.14.9/8.14.9) with ESMTP id w5ILLGhD033385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 18 Jun 2018 21:21:22 GMT (envelope-from swills@FreeBSD.org) Subject: Re: ESXi NFSv4.1 client id is nasty To: Rick Macklem , "freebsd-current@freebsd.org" Cc: "andreas.nagy@frequentis.com" References: From: Steve Wills Message-ID: Date: Mon, 18 Jun 2018 17:21:10 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 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-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mouf.net [199.48.129.64]); Mon, 18 Jun 2018 21:21:23 +0000 (UTC) X-Spam-Status: No, score=1.3 required=4.5 tests=RCVD_IN_RP_RNBL autolearn=no autolearn_force=no version=3.4.1 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mouf.net X-Virus-Scanned: clamav-milter 0.99.2 at mouf.net X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 18 Jun 2018 21:21:26 -0000 Would it be possible or reasonable to use the client ID to log a message telling the admin to enable a sysctl to enable the hacks? Steve On 06/17/18 08:35, Rick Macklem wrote: > Hi, > > Andreas Nagy has been doing a lot of testing of the NFSv4.1 client in ESXi 6.5u1 > (VMware) against the FreeBSD server. I have given him a bunch of hackish patches > to try and some of them do help. However not all issues are resolved. > The problem is that these hacks pretty obviously violate the NFSv4.1 RFC (5661). > (Details on these come later, for those interested in such things.) > > I can think of three ways to deal with this: > 1 - Just leave the server as is and point people to the issues that should be addressed > in the ESXi client. > 2 - Put the hacks in, but only enable them based on a sysctl not enabled by default. > (The main problem with this is when the server also has non-ESXi mounts.) > 3 - Enable the hacks for ESXi client mounts only, using the implementation ID > it presents at mount time in its ExchangeID arguments. > - This is my preferred solution, but the RFC says: > An example use for implementation identifiers would be diagnostic > software that extracts this information in an attempt to identify > interoperability problems, performance workload behaviors, or general > usage statistics. Since the intent of having access to this > information is for planning or general diagnosis only, the client and > server MUST NOT interpret this implementation identity information in > a way that affects interoperational behavior of the implementation. > The reason is that if clients and servers did such a thing, they > might use fewer capabilities of the protocol than the peer can > support, or the client and server might refuse to interoperate. > > Note the "MUST NOT" w.r.t. doing this. Of course, I could argue that, since the > hacks violate the RFC, then why not enable them in a way that violates the RFC. > > Anyhow, I would like to hear from others w.r.t. how they think this should be handled? > > Here's details on the breakage and workarounds for those interested, from looking > at packet traces in wireshark: > Fairly benign ones: > - The client does a ReclaimComplete with one_fs == false and then does a > ReclaimComplete with one_fs == true. The server returns > NFS4ERR_COMPLETE_ALREADY for the second one, which the ESXi client > doesn't like. > Woraround: Don't return an error for the one_fs == true case and just assume > that same as "one_fs == false". > There is also a case where the client only does the > ReclaimComplete with one_fs == true. Since FreeBSD exports a hierarchy of > file systems, this doesn't indicate to the server that all reclaims are done. > (Other extant clients never do the "one_fs == true" variant of > ReclaimComplete.) > This case of just doing the "one_fs == true" variant is actually a limitation > of the server which I don't know how to fix. However the same workaround > as listed about gets around it. > > - The client puts random garbage in the delegate_type argument for > Open/ClaimPrevious. > Workaround: Since the client sets OPEN4_SHARE_ACCESS_WANT_NO_DELEG, it doesn't > want a delegation, so assume OPEN_DELEGATE_NONE or OPEN_DELEGATE_NONE_EXT > instead of garbage. (Not sure which of the two values makes it happier.) > > Serious ones: > - The client does a OpenDowngrade with arguments set to OPEN_SHARE_ACCESS_BOTH > and OPEN_SHARE_DENY_BOTH. > Since OpenDowngrade is supposed to decrease share_access and share_deny, > the server returns NFS4ERR_INVAL. OpenDowngrade is not supposed to ever > conflict with another Open. (A conflict happens when another Open has > set an OPEN_SHARE_DENY that denies the result of the OpenDowngrade.) > with NFS4ERR_SHARE_DENIED. > I believe this one is done by the client for something it calls a > "device lock" and really doesn't like this failing. > Workaround: All I can think of is ignore the check for new bits not being set > and reply NFS_OK, when no conflicting Open exists. > When there is a conflicting Open, returning NFS4ERR_INVAL seems to be the > only option, since NFS4ERR_SHARE_DENIED isn't listed for OpenDowngrade. > > - When a server reboots, client does not serialize ExchangeID/CreateSession. > When the server reboots, a client needs to do a serialized set of RPCs > with ExchangeID followed by CreateSession to confirm it. The reply to > ExchangeID has a sequence number (csr_sequence) in it and the > CreateSession needs to have the same value in its csa_sequence argument > to confirm the clientid issued by the ExchangeID. > The client sends many ExchangeIDs and CreateSessions, so they end up failing > many times due to the sequence number not matching the last ExchangeID. > (This might only happen in the trunked case.) > Workaround: Nothing that I can think of. > > - ExchangeID sometimes sends eia_clientowner.co_verifier argument as all zeros. > Sometimes the client bogusly fills in the eia_clientowner.co_verifier > argument to ExchangeID with all 0s instead of the correct value. > This indicates to the server that the client has rebooted (it has not) > and results in the server discarding any state for the client and > re-initializing the clientid. > Workaround: The server can ignore the verifier changing and make the recovery > work better. This clearly violates RFC5661 and can only be done for > ESXi clients, since ignoring this breaks a Linux client hard reboot. > > - The client doesn't seem to handle NFS4ERR_GRACE errors correctly. > These occur when any non-reclaim operations are done during the grace > period after a server boot. > (A client needs to delay a while and then retry the operation, repeating > for as long as NFS4ERR_GRACE is received from the server. This client > does not do this.) > Workaround: Nothing that I can think of. > > Thanks in advance for any comments, rick > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Mon Jun 18 21:31:27 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B953410238BF for ; Mon, 18 Jun 2018 21:31:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::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 546C474915 for ; Mon, 18 Jun 2018 21:31:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x244.google.com with SMTP id u4-v6so14237415itg.0 for ; Mon, 18 Jun 2018 14:31:26 -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=iktmIGj9ggR2zwG/U7+/mZseLuqsZ/bvB412HkYVsa4=; b=QyfoCMeJE/ywygXIHgb6lCyawu3yKaGIPJJTUytOCIWbVsnIAZel5XpeVYMBWCuauL l+sCRRpyHd/x2NjGV0A16gPCRWJsWFAbgJBNEoyKjBoCN6bDtRcKKXydIxbC1ABXQifx xbOsAskuldKTEg+23dz0n6et68d25xCuqoIDmSjCO8aTu7roVGsZkGfxJT6ZJnC2gLrF g11vt+0jbspMHNMTwzEh/1cv24FcbI1WbK4bEBn0IuZ3uiZpl9wu6Z2cEQXGhtBL5QxG 5MV4dglGT/HMWG1l+LeiHltbeBLQGZbL/oq3hNgU3N4R/eN/TJz3FS8bi7/mVLLz04fn 0RyQ== 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=iktmIGj9ggR2zwG/U7+/mZseLuqsZ/bvB412HkYVsa4=; b=Uw7dN8SYrBBP+IKprxyOQFIXvbZGXZDkHDG7uIY27sZy1QpQTTpLFfntwRXFEPrXiq Y48L6IDY0TEsoUFKXWLeSebewPNxY7HTqYn69M6WXWXt90kHeqZaHjZnEy+MuHZIiyt7 zaawFNVh9T/smCG2jGErq4RUPFjCiJ10y/FZdGquU3oYrIH1CYw562Ekcs4nfcLUZULF W5RmTpAptJyC8TUCnD9IUg+WRBVoiuSCr97CVYHXaMeRjY9vvlotBxBydceFDoWgLU+I lUGHEpbGgNfWkuVutikGZyDYBNRzYooiKbFhm/G/vX/vpPl/FnlaQMRrAZyxlEHfxaJT WoWg== X-Gm-Message-State: APt69E3jtOo8eLxsaOf/wWrN+sPXkCuWJSPWOHNzJVtLlgYNk+WDGley lL6/1orGzZ1h3dLHKFSBj2MWG2Z/Ba6Q/Z10svh/Qw== X-Google-Smtp-Source: ADUXVKJOnRnUfNyKri3/yU/F0J64og2bCCjDQJljQitFavx7dZkLxXX1oSlnHZZGzd3Sv2a0MxwXBMNmqjofXXmaUZ0= X-Received: by 2002:a02:6348:: with SMTP id j69-v6mr11745083jac.45.1529357485400; Mon, 18 Jun 2018 14:31:25 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:5945:0:0:0:0:0 with HTTP; Mon, 18 Jun 2018 14:31:24 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: From: Warner Losh Date: Mon, 18 Jun 2018 15:31:24 -0600 X-Google-Sender-Auth: ou34-M828jeK4kpPtlh7lR1Ki3s Message-ID: Subject: Re: ESXi NFSv4.1 client id is nasty To: Steve Wills Cc: Rick Macklem , "freebsd-current@freebsd.org" , "andreas.nagy@frequentis.com" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 18 Jun 2018 21:31:27 -0000 My thoughts on this are mixed. You need certain workarounds, but they sound like they need to be on a per-client-type basis. On the one hand, you don't want to chat with different clients differently, but on the other you want it to work. I'd suggest a two-tiered approach. First, have a sysctl per workaround that's a list of client types to apply the workaround to. Have these default to ESX client, but allow for others. Second, have a master sysctl to turn on/off per-client workarounds. Have this default to off. And finally, see if you can get ESXi to fix their flaws. This is by far the best solution. The above should really only be a stop-gap, but would be extensible should this sort of thing become more of the norm than is desired. Warner On Mon, Jun 18, 2018 at 3:21 PM, Steve Wills wrote: > Would it be possible or reasonable to use the client ID to log a message > telling the admin to enable a sysctl to enable the hacks? > > Steve > > On 06/17/18 08:35, Rick Macklem wrote: > >> Hi, >> >> Andreas Nagy has been doing a lot of testing of the NFSv4.1 client in >> ESXi 6.5u1 >> (VMware) against the FreeBSD server. I have given him a bunch of hackish >> patches >> to try and some of them do help. However not all issues are resolved. >> The problem is that these hacks pretty obviously violate the NFSv4.1 RFC >> (5661). >> (Details on these come later, for those interested in such things.) >> >> I can think of three ways to deal with this: >> 1 - Just leave the server as is and point people to the issues that >> should be addressed >> in the ESXi client. >> 2 - Put the hacks in, but only enable them based on a sysctl not enabled >> by default. >> (The main problem with this is when the server also has non-ESXi >> mounts.) >> 3 - Enable the hacks for ESXi client mounts only, using the >> implementation ID >> it presents at mount time in its ExchangeID arguments. >> - This is my preferred solution, but the RFC says: >> An example use for implementation identifiers would be diagnostic >> software that extracts this information in an attempt to identify >> interoperability problems, performance workload behaviors, or general >> usage statistics. Since the intent of having access to this >> information is for planning or general diagnosis only, the client and >> server MUST NOT interpret this implementation identity information in >> a way that affects interoperational behavior of the implementation. >> The reason is that if clients and servers did such a thing, they >> might use fewer capabilities of the protocol than the peer can >> support, or the client and server might refuse to interoperate. >> >> Note the "MUST NOT" w.r.t. doing this. Of course, I could argue that, >> since the >> hacks violate the RFC, then why not enable them in a way that violates >> the RFC. >> >> Anyhow, I would like to hear from others w.r.t. how they think this >> should be handled? >> >> Here's details on the breakage and workarounds for those interested, from >> looking >> at packet traces in wireshark: >> Fairly benign ones: >> - The client does a ReclaimComplete with one_fs == false and then does a >> ReclaimComplete with one_fs == true. The server returns >> NFS4ERR_COMPLETE_ALREADY for the second one, which the ESXi client >> doesn't like. >> Woraround: Don't return an error for the one_fs == true case and just >> assume >> that same as "one_fs == false". >> There is also a case where the client only does the >> ReclaimComplete with one_fs == true. Since FreeBSD exports a hierarchy >> of >> file systems, this doesn't indicate to the server that all reclaims >> are done. >> (Other extant clients never do the "one_fs == true" variant of >> ReclaimComplete.) >> This case of just doing the "one_fs == true" variant is actually a >> limitation >> of the server which I don't know how to fix. However the same >> workaround >> as listed about gets around it. >> >> - The client puts random garbage in the delegate_type argument for >> Open/ClaimPrevious. >> Workaround: Since the client sets OPEN4_SHARE_ACCESS_WANT_NO_DELEG, >> it doesn't >> want a delegation, so assume OPEN_DELEGATE_NONE or >> OPEN_DELEGATE_NONE_EXT >> instead of garbage. (Not sure which of the two values makes it >> happier.) >> >> Serious ones: >> - The client does a OpenDowngrade with arguments set to >> OPEN_SHARE_ACCESS_BOTH >> and OPEN_SHARE_DENY_BOTH. >> Since OpenDowngrade is supposed to decrease share_access and >> share_deny, >> the server returns NFS4ERR_INVAL. OpenDowngrade is not supposed to ever >> conflict with another Open. (A conflict happens when another Open has >> set an OPEN_SHARE_DENY that denies the result of the OpenDowngrade.) >> with NFS4ERR_SHARE_DENIED. >> I believe this one is done by the client for something it calls a >> "device lock" and really doesn't like this failing. >> Workaround: All I can think of is ignore the check for new bits not >> being set >> and reply NFS_OK, when no conflicting Open exists. >> When there is a conflicting Open, returning NFS4ERR_INVAL seems to >> be the >> only option, since NFS4ERR_SHARE_DENIED isn't listed for >> OpenDowngrade. >> >> - When a server reboots, client does not serialize >> ExchangeID/CreateSession. >> When the server reboots, a client needs to do a serialized set of RPCs >> with ExchangeID followed by CreateSession to confirm it. The reply to >> ExchangeID has a sequence number (csr_sequence) in it and the >> CreateSession needs to have the same value in its csa_sequence argument >> to confirm the clientid issued by the ExchangeID. >> The client sends many ExchangeIDs and CreateSessions, so they end up >> failing >> many times due to the sequence number not matching the last ExchangeID. >> (This might only happen in the trunked case.) >> Workaround: Nothing that I can think of. >> >> - ExchangeID sometimes sends eia_clientowner.co_verifier argument as all >> zeros. >> Sometimes the client bogusly fills in the eia_clientowner.co_verifier >> argument to ExchangeID with all 0s instead of the correct value. >> This indicates to the server that the client has rebooted (it has not) >> and results in the server discarding any state for the client and >> re-initializing the clientid. >> Workaround: The server can ignore the verifier changing and make the >> recovery >> work better. This clearly violates RFC5661 and can only be done for >> ESXi clients, since ignoring this breaks a Linux client hard >> reboot. >> >> - The client doesn't seem to handle NFS4ERR_GRACE errors correctly. >> These occur when any non-reclaim operations are done during the grace >> period after a server boot. >> (A client needs to delay a while and then retry the operation, >> repeating >> for as long as NFS4ERR_GRACE is received from the server. This client >> does not do this.) >> Workaround: Nothing that I can think of. >> >> Thanks in advance for any comments, rick >> _______________________________________________ >> 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 >> " >> >> _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Mon Jun 18 21:42:20 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C87410241E7 for ; Mon, 18 Jun 2018 21:42:20 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670086.outbound.protection.outlook.com [40.107.67.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT TLS CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E7F17511F; Mon, 18 Jun 2018 21:42:19 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM (52.132.44.24) by YTOPR0101MB1532.CANPRD01.PROD.OUTLOOK.COM (52.132.49.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.19; Mon, 18 Jun 2018 21:42:18 +0000 Received: from YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM ([fe80::d0eb:3783:7c99:2802]) by YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM ([fe80::d0eb:3783:7c99:2802%3]) with mapi id 15.20.0863.016; Mon, 18 Jun 2018 21:42:18 +0000 From: Rick Macklem To: Steve Wills , "freebsd-current@freebsd.org" CC: "andreas.nagy@frequentis.com" Subject: Re: ESXi NFSv4.1 client id is nasty Thread-Topic: ESXi NFSv4.1 client id is nasty Thread-Index: AQHUBjX1G4uSBXqIhUeci7+GbxFK06RmiCEAgAAFxog= Date: Mon, 18 Jun 2018 21:42:18 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB1532; 7:3onYG45slYVh2Ja4EVgymnqm2bnR7cIF3sFNtaE8polOpiM4x2r8/XoZ3+NCUPK2IKUMi/SHkneQGCDsZ2vxA6D5gIwbjp9NwA06a0DExAL2dKDNbPwyscCkmPPH2IWqXXRr0eaL11PSnwuSpXjM2SEiUsheFQVPXaurs2ENk7ozCOpQDS7/zTADwfn18JDpr+AXNNKzmzdJ/mSMbQf+8MT83rhIITmG3vTMSkJyQR4cs8MJF76YDsj9C0PXxrf2 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: da9cc615-6930-435d-6211-08d5d5645d59 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:YTOPR0101MB1532; x-ms-traffictypediagnostic: YTOPR0101MB1532: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(75325880899374); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231254)(944501410)(52105095)(10201501046)(3002001)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:YTOPR0101MB1532; BCL:0; PCL:0; RULEID:; SRVR:YTOPR0101MB1532; x-forefront-prvs: 0707248B64 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(39860400002)(346002)(366004)(39380400002)(51874003)(199004)(189003)(76176011)(102836004)(2906002)(476003)(99286004)(316002)(786003)(6506007)(110136005)(59450400001)(53546011)(5250100002)(97736004)(478600001)(8936002)(6306002)(966005)(2501003)(9686003)(14454004)(186003)(486006)(11346002)(26005)(446003)(7696005)(55016002)(86362001)(6436002)(81156014)(81166006)(53936002)(6246003)(74316002)(74482002)(5660300001)(305945005)(3660700001)(25786009)(4326008)(105586002)(229853002)(68736007)(33656002)(2900100001)(8676002)(3280700002)(106356001)(12363001); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB1532; H:YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-microsoft-antispam-message-info: ctcdNfvrHCVKYW1KV1L9hu0KVE1+O8PXQYnTDvg0gzxFca9ZOtFrdFfJlGepRBz9x4ZsoNPMFCfZPbvAzxl+sCC8DE9dQGjmsShe1HeO+IXzC7/8FUJ4k+m8tVvyc+cI422wZ7tKoIlFX0Zj4nKlupFAGiNKUMzSXXenvRyQbqnjpGxtqS3F644UDBzLohu3cDnpvqb08ypjmdS1SwyGJlFf7vEaSHi7jrnjrLNQFIxZxdSUHRRPjZIvqU/hpro6S96Hg90AReJeSxQ2Qv0YZEcFD7zAMgv9TMDkXWzAZXSx/KYNe3UnLxNxkMiqdkfA+04cJqqiV2iRZFWOTS4eig== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: da9cc615-6930-435d-6211-08d5d5645d59 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2018 21:42:18.1909 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB1532 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 18 Jun 2018 21:42:20 -0000 Steve Wills wrote: >Would it be possible or reasonable to use the client ID to log a message >telling the admin to enable a sysctl to enable the hacks? Yes. However, this client implementation id is only seen by the server when the client makes a mount attempt. I suppose it could log the message and fail the mount, if the "hack" sysctl= isn't set? rick [stuff snipped] ________________________________________ From: Steve Wills Sent: Monday, June 18, 2018 5:21:10 PM To: Rick Macklem; freebsd-current@freebsd.org Cc: andreas.nagy@frequentis.com Subject: Re: ESXi NFSv4.1 client id is nasty Would it be possible or reasonable to use the client ID to log a message telling the admin to enable a sysctl to enable the hacks? Steve On 06/17/18 08:35, Rick Macklem wrote: > Hi, > > Andreas Nagy has been doing a lot of testing of the NFSv4.1 client in ESX= i 6.5u1 > (VMware) against the FreeBSD server. I have given him a bunch of hackish = patches > to try and some of them do help. However not all issues are resolved. > The problem is that these hacks pretty obviously violate the NFSv4.1 RFC = (5661). > (Details on these come later, for those interested in such things.) > > I can think of three ways to deal with this: > 1 - Just leave the server as is and point people to the issues that shoul= d be addressed > in the ESXi client. > 2 - Put the hacks in, but only enable them based on a sysctl not enabled = by default. > (The main problem with this is when the server also has non-ESXi mo= unts.) > 3 - Enable the hacks for ESXi client mounts only, using the implementatio= n ID > it presents at mount time in its ExchangeID arguments. > - This is my preferred solution, but the RFC says: > An example use for implementation identifiers would be diagnostic > software that extracts this information in an attempt to identify > interoperability problems, performance workload behaviors, or general > usage statistics. Since the intent of having access to this > information is for planning or general diagnosis only, the client and > server MUST NOT interpret this implementation identity information in > a way that affects interoperational behavior of the implementation. > The reason is that if clients and servers did such a thing, they > might use fewer capabilities of the protocol than the peer can > support, or the client and server might refuse to interoperate. > > Note the "MUST NOT" w.r.t. doing this. Of course, I could argue that, sin= ce the > hacks violate the RFC, then why not enable them in a way that violates th= e RFC. > > Anyhow, I would like to hear from others w.r.t. how they think this shoul= d be handled? > > Here's details on the breakage and workarounds for those interested, from= looking > at packet traces in wireshark: > Fairly benign ones: > - The client does a ReclaimComplete with one_fs =3D=3D false and then doe= s a > ReclaimComplete with one_fs =3D=3D true. The server returns > NFS4ERR_COMPLETE_ALREADY for the second one, which the ESXi client > doesn't like. > Woraround: Don't return an error for the one_fs =3D=3D true case and j= ust assume > that same as "one_fs =3D=3D false". > There is also a case where the client only does the > ReclaimComplete with one_fs =3D=3D true. Since FreeBSD exports a hiera= rchy of > file systems, this doesn't indicate to the server that all reclaims ar= e done. > (Other extant clients never do the "one_fs =3D=3D true" variant of > ReclaimComplete.) > This case of just doing the "one_fs =3D=3D true" variant is actually a= limitation > of the server which I don't know how to fix. However the same workarou= nd > as listed about gets around it. > > - The client puts random garbage in the delegate_type argument for > Open/ClaimPrevious. > Workaround: Since the client sets OPEN4_SHARE_ACCESS_WANT_NO_DELEG, it= doesn't > want a delegation, so assume OPEN_DELEGATE_NONE or OPEN_DELEGATE_N= ONE_EXT > instead of garbage. (Not sure which of the two values makes it hap= pier.) > > Serious ones: > - The client does a OpenDowngrade with arguments set to OPEN_SHARE_ACCESS= _BOTH > and OPEN_SHARE_DENY_BOTH. > Since OpenDowngrade is supposed to decrease share_access and share_den= y, > the server returns NFS4ERR_INVAL. OpenDowngrade is not supposed to eve= r > conflict with another Open. (A conflict happens when another Open has > set an OPEN_SHARE_DENY that denies the result of the OpenDowngrade.) > with NFS4ERR_SHARE_DENIED. > I believe this one is done by the client for something it calls a > "device lock" and really doesn't like this failing. > Workaround: All I can think of is ignore the check for new bits not be= ing set > and reply NFS_OK, when no conflicting Open exists. > When there is a conflicting Open, returning NFS4ERR_INVAL seems to= be the > only option, since NFS4ERR_SHARE_DENIED isn't listed for OpenDowng= rade. > > - When a server reboots, client does not serialize ExchangeID/CreateSessi= on. > When the server reboots, a client needs to do a serialized set of RPCs > with ExchangeID followed by CreateSession to confirm it. The reply to > ExchangeID has a sequence number (csr_sequence) in it and the > CreateSession needs to have the same value in its csa_sequence argumen= t > to confirm the clientid issued by the ExchangeID. > The client sends many ExchangeIDs and CreateSessions, so they end up f= ailing > many times due to the sequence number not matching the last ExchangeID= . > (This might only happen in the trunked case.) > Workaround: Nothing that I can think of. > > - ExchangeID sometimes sends eia_clientowner.co_verifier argument as all = zeros. > Sometimes the client bogusly fills in the eia_clientowner.co_verifier > argument to ExchangeID with all 0s instead of the correct value. > This indicates to the server that the client has rebooted (it has not) > and results in the server discarding any state for the client and > re-initializing the clientid. > Workaround: The server can ignore the verifier changing and make the r= ecovery > work better. This clearly violates RFC5661 and can only be done fo= r > ESXi clients, since ignoring this breaks a Linux client hard reboo= t. > > - The client doesn't seem to handle NFS4ERR_GRACE errors correctly. > These occur when any non-reclaim operations are done during the grace > period after a server boot. > (A client needs to delay a while and then retry the operation, repeati= ng > for as long as NFS4ERR_GRACE is received from the server. This client > does not do this.) > Workaround: Nothing that I can think of. > > Thanks in advance for any comments, rick > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@freebsd.org Mon Jun 18 21:55:21 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85E3B1024FF0 for ; Mon, 18 Jun 2018 21:55:21 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mouf.net", Issuer "mouf.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 21AF575B06 for ; Mon, 18 Jun 2018 21:55:21 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from lrrr.mouf.net (cpe-24-163-43-246.nc.res.rr.com [24.163.43.246]) (authenticated bits=0) by mouf.net (8.14.9/8.14.9) with ESMTP id w5ILtD2b033735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 18 Jun 2018 21:55:19 GMT (envelope-from swills@FreeBSD.org) Subject: Re: ESXi NFSv4.1 client id is nasty To: Rick Macklem , "freebsd-current@freebsd.org" Cc: "andreas.nagy@frequentis.com" References: From: Steve Wills Message-ID: <8ceea008-f827-580b-8ca6-4a5fcb028e83@FreeBSD.org> Date: Mon, 18 Jun 2018 17:55:08 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 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-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mouf.net [199.48.129.64]); Mon, 18 Jun 2018 21:55:19 +0000 (UTC) X-Spam-Status: No, score=1.3 required=4.5 tests=RCVD_IN_RP_RNBL autolearn=no autolearn_force=no version=3.4.1 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mouf.net X-Virus-Scanned: clamav-milter 0.99.2 at mouf.net X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 18 Jun 2018 21:55:21 -0000 Hi, On 06/18/18 17:42, Rick Macklem wrote: > Steve Wills wrote: >> Would it be possible or reasonable to use the client ID to log a message >> telling the admin to enable a sysctl to enable the hacks? > Yes. However, this client implementation id is only seen by the server > when the client makes a mount attempt. > > I suppose it could log the message and fail the mount, if the "hack" sysctl isn't > set? I hadn't thought of failing the mount, just defaulting not enabling the hacks unless the admin chooses to enable them. But at the same time being proactive about telling the admin to enable them. I.E. keep the implementation RFC compliant since we wouldn't be changing the behavior based on the implementation ID, only based upon the admin setting the sysctl, which we told them to do based on the implementation ID. Just an idea, maybe Warner's suggestion is a better one. Steve From owner-freebsd-current@freebsd.org Mon Jun 18 22:27:11 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 825FE1001AB9; Mon, 18 Jun 2018 22:27:11 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B84B76DBD; Mon, 18 Jun 2018 22:27:11 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id E00082DF8; Mon, 18 Jun 2018 22:27:10 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id E7296A4B4; Mon, 18 Jun 2018 22:27:09 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id zJ59tngtV2kl; Mon, 18 Jun 2018 22:27:07 +0000 (UTC) Subject: Re: A head buildworld race visible in the ci.freebsd.org build history DKIM-Filter: OpenDKIM Filter v2.10.3 mail.xzibition.com BF557A4AE To: Konstantin Belousov Cc: FreeBSD Current , freebsd-toolchain@freebsd.org References: <74EAD684-0E0B-453A-B746-156777CF604A@yahoo.com> <1884103f-d1fb-aca6-2edd-062e11d05617@FreeBSD.org> <20180618204517.GD2430@kib.kiev.ua> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Autocrypt: addr=bdrewery@FreeBSD.org; prefer-encrypt=mutual; keydata= xsBNBFJphmsBCADiFgmS4bIzwZijrS31SjEMzg+n5zNellgM+HkShwehpqCiyhXdWrvH6dTZ a6u50pbUIX7doTR7W7PQHCjCTqtpwvcj0eulZva+iHFp+XrbgSFHn+VVXgkYP2MFySyZRFab D2qqzJBEJofhpv4HvY6uQI5K99pMqKr1Z/lHqsijYYu4RH2OfwB5PinId7xeldzWEonVoCr+ rfxzO/UrgA6v/3layGZcKNHFjmc3NqoN1DXtdaEHqtjIozzbndVkH6lkFvIpIrI6i5ox8pwp VxsxLCr/4Musd5CWgHiet5kSw2SzNeA8FbxdLYCpXNVu+uBACEbCUP+CSNy3NVfEUxsBABEB AAHNJEJyeWFuIERyZXdlcnkgPGJkcmV3ZXJ5QEZyZWVCU0Qub3JnPsLAgAQTAQoAKgIbAwUL CQgHAwUVCgkICwUWAwIBAAIeAQIXgAIZAQUCWujOIgUJCmB7NwAKCRA113G7bkaXz/xpB/9b /UWIPbieY1IeIuHF2pyYPE7Hytkh3HVsxMA0F5Ma2AYQsXZZeKNKWrF7RPyDyDwUklLHJkhm k3EfClBbHxf08kMIm1vWCJRtgxic9knY/bzYGiWMpHjg3cSd1XfrYH1autYqTZAjDwIkgOjU dR//Tbn4V36sY7y2jz+kdMVWvK53U32aZqiwBbCn4DPe1wSZcUs17mV/0uZdIoGdj74B1orN A/0py5vHYo6HcbBNoaR8pKRLf5VZNRsxqGIMhTucx4SJWcHpuRBWYyvJSFzwvxdK4ZD4Yqoc kFGPVtOXktVMai9exrLvP3G77fKMu8DI6j4QRU4wCesnHuIfRPFuzsBNBFJphmsBCACiVFPf kNfaFtUSuY0395ueo/rMyHPGPQ2iwvERFCpeFGSQSgagpenNHLpFQKTg/dl6FOoST5tqyxMq fyHGHDzzU51bvA/IfaGoNi/BIhTe/toZNMRvpcI3PLjiGcnJnuwCCbAVOAGdb+t5cZtpNdOI cKYmrYG3u9RiBpe6dTF+qLrD/8Bs1wjhduQ8fcNNgnkXu8xDH4ZxY0lIc3QgvYWp9vimlQe6 iKjUd2/DX28ETZcD5h6pYV331KMPTrEI0p0yvFijUZce8c1XHFyL1j9sBAha5qpszJl6Uq5i LolhKRcGfcdmtD72vHQjUYglUyudSJUVyo2gMYjdbiFKzJulABEBAAHCwGUEGAEKAA8CGwwF AlrozigFCQpgez0ACgkQNddxu25Gl8+m5Af/R3VEdxNMAcDIes9ADhQyofj20SPV3eCJ3HYR OebTSuNdOudGt4AAyA8Ks94u9hiIp5IGsc6RDsT9W7O2vgXhd6eV3eiY5Oif5xLIYrIDVu1Y 1GyRxRrPEn/QOqDN6uFZCPwK1aOapGcYCrO9lB0gMuTVfgHanU61rgC9tMX0OoAOyRd+V3/M 8lDNhjJdF/IpO3SdYzKfkwduy4qamw4Gphcx/RfYQvYLq/eDkP8d50PphWdboqWBwNRHayro W/07OGzfxM5fJ5mBsXPQcO2QcRjkyHf6xCM6Hi1qQL4OnXMNE/ZTX0lnOj1/pH93TlzSHZMP TaiiA/MBD3vGsXBmBg== Organization: FreeBSD Message-ID: <068108ab-76f2-0f2d-fd92-11c838a4d391@FreeBSD.org> Date: Mon, 18 Jun 2018 15:27:01 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180618204517.GD2430@kib.kiev.ua> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2DH8GpUXEouyl9XYdNs3BgDMzXwBQGvsu" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 18 Jun 2018 22:27:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2DH8GpUXEouyl9XYdNs3BgDMzXwBQGvsu Content-Type: multipart/mixed; boundary="AboYhTK5rYL94xyvtauER6Vq9g9UMysOI"; protected-headers="v1" From: Bryan Drewery To: Konstantin Belousov Cc: FreeBSD Current , freebsd-toolchain@freebsd.org Message-ID: <068108ab-76f2-0f2d-fd92-11c838a4d391@FreeBSD.org> Subject: Re: A head buildworld race visible in the ci.freebsd.org build history References: <74EAD684-0E0B-453A-B746-156777CF604A@yahoo.com> <1884103f-d1fb-aca6-2edd-062e11d05617@FreeBSD.org> <20180618204517.GD2430@kib.kiev.ua> In-Reply-To: <20180618204517.GD2430@kib.kiev.ua> --AboYhTK5rYL94xyvtauER6Vq9g9UMysOI Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/18/2018 1:45 PM, Konstantin Belousov wrote: > On Mon, Jun 18, 2018 at 12:42:46PM -0700, Bryan Drewery wrote: >> On 6/15/2018 10:55 PM, Mark Millard wrote: >>> In watching ci.freebsd.org builds I've seen a notable >>> number of one time failures, such as (example from >>> powerpc64): >>> >>> --- all_subdir_lib/libufs --- >>> ranlib -D libufs.a >>> ranlib: fatal: Failed to open 'libufs.a' >>> *** [libufs.a] Error code 70 >>> >>> where the next build works despite the change being >>> irrelevant to whatever ranlib complained about. >>> >>> Other builds failed similarly: >>> >>> --- all_subdir_lib/libbsm --- >>> ranlib -D libbsm_p.a >>> ranlib: fatal: Failed to open 'libbsm_p.a' >>> *** [libbsm_p.a] Error code 70 >>> >>> and: >>> >>> --- kerberos5/lib__L --- >>> ranlib -D libgssapi_spnego_p.a >>> --- libgssapi_spnego.a --- >>> ranlib -D libgssapi_spnego.a >>> --- libgssapi_spnego_p.a --- >>> ranlib: fatal: Failed to open 'libgssapi_spnego_p.a' >>> *** [libgssapi_spnego_p.a] Error code 70 >>> >>> and so on. >>> >>> >>> It is not limited to powerpc64. For example, for aarch64 >>> there are: >>> >>> --- libpam_exec.a --- >>> building static pam_exec library >>> ar -crD libpam_exec.a `NM=3D'nm' NMFLAGS=3D'' lorder pam_exec.o | t= sort -q`=20 >>> ranlib -D libpam_exec.a >>> ranlib: fatal: Failed to open 'libpam_exec.a' >>> *** [libpam_exec.a] Error code 70 >>> >>> and: >>> >>> --- all_subdir_lib/libusb --- >>> ranlib -D libusb.a >>> ranlib: fatal: Failed to open 'libusb.a' >>> *** [libusb.a] Error code 70 >>> >>> and: >>> >>> --- all_subdir_lib/libbsnmp --- >>> ranlib: fatal: Failed to open 'libbsnmp.a' >>> --- all_subdir_lib/ncurses --- >>> --- all_subdir_lib/ncurses/panelw --- >>> --- panel.pico --- >>> --- all_subdir_lib/libbsnmp --- >>> *** [libbsnmp.a] Error code 70 >>> >>> >>> Even amd64 gets such: >>> >>> --- libpcap.a --- >>> ranlib -D libpcap.a >>> ranlib: fatal: Failed to open 'libpcap.a' >>> *** [libpcap.a] Error code 70 >>> >>> and: >>> >>> >>> --- libkafs5.a --- >>> ranlib: fatal: Failed to open 'libkafs5.a' >>> --- libkafs5_p.a --- >>> ranlib: fatal: Failed to open 'libkafs5_p.a' >>> --- cddl/lib__L --- >>> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/lua/lbaselib.= c:60:26: note: include the header or explicitly provide a decla= ration for 'toupper' >>> --- kerberos5/lib__L --- >>> *** [libkafs5_p.a] Error code 70 >>> >>> make[5]: stopped in /usr/src/kerberos5/lib/libkafs5 >>> --- libkafs5.a --- >>> *** [libkafs5.a] Error code 70 >>> >>> and: >>> >>> >>> --- lib__L --- >>> ranlib -D libclang_rt.asan_cxx-i386.a >>> ranlib: fatal: Failed to open 'libclang_rt.asan_cxx-i386.a' >>> *** [libclang_rt.asan_cxx-i386.a] Error code 70 >>> >>> >>> (Notice the variability in what .a the ranlib's fail for.) >>> >>> >>> >>> >>> >> >> >> I looked at this a few days ago and don't believe it's actually a buil= d >> race. I think there is something wrong with the ar/ranlib on that syst= em >> or something else. I've found no evidence of concurrent building of th= e >> .a files in question. >=20 > FWIW, I got the similar failure when I did last checks for the OFED > commit. For me, it was libgcc.a. >=20 If it was -lgcc_s then it's a known rare build race due to tools/install.sh not handling -S. --=20 Regards, Bryan Drewery --AboYhTK5rYL94xyvtauER6Vq9g9UMysOI-- --2DH8GpUXEouyl9XYdNs3BgDMzXwBQGvsu 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 iQEcBAEBAgAGBQJbKDG5AAoJEDXXcbtuRpfP22cH/RriHbGCIrv/6MXVXhstjuKH j1dyPEpfYIv3WGzEhlvOMrRf9Oca/ns/h1GSPsRv7Z87zFgwFAKziB4r5mIZEan3 V5B1890C7NcFnGBekk5Wkt5X9YmZzLX21tLfLs6GYcI0sZjkKce8VfJqeXJGqLlG JWnEcOBCN1lXxeFpj8mORQ0wedJPSHQoIZm/8lDenkYmVefNsK93URbWsHOlSUDf g4u9rPfiPDxntgqKN4rhb88lvAyydgxv402GU1xUsN0j/c4akzM8biCAuCW4ZP9P +6R/R+ah67XCkATLGd7mKYgjkdEr48mTWawdRfHwyc/hU98Aoo4xnQKBS9L/3qA= =2+1S -----END PGP SIGNATURE----- --2DH8GpUXEouyl9XYdNs3BgDMzXwBQGvsu-- From owner-freebsd-current@freebsd.org Mon Jun 18 22:31:29 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3CEA310020AC; Mon, 18 Jun 2018 22:31:29 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: from mail-wm0-f65.google.com (mail-wm0-f65.google.com [74.125.82.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B37BA77249; Mon, 18 Jun 2018 22:31:28 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: by mail-wm0-f65.google.com with SMTP id x6-v6so16598201wmc.3; Mon, 18 Jun 2018 15:31:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8RpHs30NV5Os7ugVYxDPl5HhR5Nvs7RTdw3sWSVNngY=; b=ePrPh2J7n5K/Bf9zzsC/XhRTSW5yaeLLY8qT+33U2ePw8b/f+Tp/u7j5AQga9XEhLz 2KLSQxd619oiNxSSQZk2zTVg0w2olJBbG5kDcNY/3Orz5pPJMi7i5FbduYo17jn51d82 roH04PkdJC1I6liPgKrbpwCmAGuy8JAYhALTVuz/TaekZu0nbSeqIu4NSxJG2mjr9vJz U5bIAJeqzjF+9eC4t5Lv+rMQabfjwsp4WEqU4r8eRyMW1U9OL5OMCR2VeyvV026utuIe 4J3x1yw2l8o/nHPmT8dZA8e3NW8KW3vBylbQfv7mmfTuWF9KuRz5Xllw/10LjpM3HtVP 4ddw== X-Gm-Message-State: APt69E1eIF2C4TnUyDu1U2E94OQXld5JCObongcrnq54ydpvWhLnmbp9 D8OdoQ2X0g3YsfsGRAbKNBU0BKDXbREvNqeMYYOD9qw4 X-Google-Smtp-Source: ADUXVKLrtUIuSNTtr9+7R7HOfHKI+HxF2ie6yruw4BPO+jHgWLwxiCmu0bUcYZITbJm3rcllUlby5x0JNfXn573WVR4= X-Received: by 2002:a1c:42d7:: with SMTP id k84-v6mr9549420wmi.159.1529361087390; Mon, 18 Jun 2018 15:31:27 -0700 (PDT) MIME-Version: 1.0 References: <74EAD684-0E0B-453A-B746-156777CF604A@yahoo.com> <1884103f-d1fb-aca6-2edd-062e11d05617@FreeBSD.org> <20180618204517.GD2430@kib.kiev.ua> <068108ab-76f2-0f2d-fd92-11c838a4d391@FreeBSD.org> In-Reply-To: <068108ab-76f2-0f2d-fd92-11c838a4d391@FreeBSD.org> From: Li-Wen Hsu Date: Mon, 18 Jun 2018 18:31:14 -0400 Message-ID: Subject: Re: A head buildworld race visible in the ci.freebsd.org build history To: Bryan Drewery Cc: Konstantin Belousov , FreeBSD Current , FreeBSD Toolchain Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 18 Jun 2018 22:31:29 -0000 On Mon, Jun 18, 2018 at 6:27 PM Bryan Drewery wrote: > > On 6/18/2018 1:45 PM, Konstantin Belousov wrote: > > On Mon, Jun 18, 2018 at 12:42:46PM -0700, Bryan Drewery wrote: > >> On 6/15/2018 10:55 PM, Mark Millard wrote: > >>> In watching ci.freebsd.org builds I've seen a notable > >>> number of one time failures, such as (example from > >>> powerpc64): > >>> > >>> --- all_subdir_lib/libufs --- > >>> ranlib -D libufs.a > >>> ranlib: fatal: Failed to open 'libufs.a' > >>> *** [libufs.a] Error code 70 > >>> > >>> where the next build works despite the change being > >>> irrelevant to whatever ranlib complained about. > >>> > >>> Other builds failed similarly: > >>> > >>> --- all_subdir_lib/libbsm --- > >>> ranlib -D libbsm_p.a > >>> ranlib: fatal: Failed to open 'libbsm_p.a' > >>> *** [libbsm_p.a] Error code 70 > >>> > >>> and: > >>> > >>> --- kerberos5/lib__L --- > >>> ranlib -D libgssapi_spnego_p.a > >>> --- libgssapi_spnego.a --- > >>> ranlib -D libgssapi_spnego.a > >>> --- libgssapi_spnego_p.a --- > >>> ranlib: fatal: Failed to open 'libgssapi_spnego_p.a' > >>> *** [libgssapi_spnego_p.a] Error code 70 > >>> > >>> and so on. > >>> > >>> > >>> It is not limited to powerpc64. For example, for aarch64 > >>> there are: > >>> > >>> --- libpam_exec.a --- > >>> building static pam_exec library > >>> ar -crD libpam_exec.a `NM='nm' NMFLAGS='' lorder pam_exec.o | tsort -q` > >>> ranlib -D libpam_exec.a > >>> ranlib: fatal: Failed to open 'libpam_exec.a' > >>> *** [libpam_exec.a] Error code 70 > >>> > >>> and: > >>> > >>> --- all_subdir_lib/libusb --- > >>> ranlib -D libusb.a > >>> ranlib: fatal: Failed to open 'libusb.a' > >>> *** [libusb.a] Error code 70 > >>> > >>> and: > >>> > >>> --- all_subdir_lib/libbsnmp --- > >>> ranlib: fatal: Failed to open 'libbsnmp.a' > >>> --- all_subdir_lib/ncurses --- > >>> --- all_subdir_lib/ncurses/panelw --- > >>> --- panel.pico --- > >>> --- all_subdir_lib/libbsnmp --- > >>> *** [libbsnmp.a] Error code 70 > >>> > >>> > >>> Even amd64 gets such: > >>> > >>> --- libpcap.a --- > >>> ranlib -D libpcap.a > >>> ranlib: fatal: Failed to open 'libpcap.a' > >>> *** [libpcap.a] Error code 70 > >>> > >>> and: > >>> > >>> > >>> --- libkafs5.a --- > >>> ranlib: fatal: Failed to open 'libkafs5.a' > >>> --- libkafs5_p.a --- > >>> ranlib: fatal: Failed to open 'libkafs5_p.a' > >>> --- cddl/lib__L --- > >>> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/lua/lbaselib.c:60:26: note: include the header or explicitly provide a declaration for 'toupper' > >>> --- kerberos5/lib__L --- > >>> *** [libkafs5_p.a] Error code 70 > >>> > >>> make[5]: stopped in /usr/src/kerberos5/lib/libkafs5 > >>> --- libkafs5.a --- > >>> *** [libkafs5.a] Error code 70 > >>> > >>> and: > >>> > >>> > >>> --- lib__L --- > >>> ranlib -D libclang_rt.asan_cxx-i386.a > >>> ranlib: fatal: Failed to open 'libclang_rt.asan_cxx-i386.a' > >>> *** [libclang_rt.asan_cxx-i386.a] Error code 70 > >>> > >>> > >>> (Notice the variability in what .a the ranlib's fail for.) > >>> > >>> > >>> > >>> > >>> > >> > >> > >> I looked at this a few days ago and don't believe it's actually a build > >> race. I think there is something wrong with the ar/ranlib on that system > >> or something else. I've found no evidence of concurrent building of the > >> .a files in question. > > > > FWIW, I got the similar failure when I did last checks for the OFED > > commit. For me, it was libgcc.a. > > > > If it was -lgcc_s then it's a known rare build race due to > tools/install.sh not handling -S. It seems a more general problem, this one: https://ci.freebsd.org/job/FreeBSD-head-aarch64-build/8190/console calls for libcuse_p.a, while this one: https://ci.freebsd.org/job/FreeBSD-head-mips-build/2919/console calls for libfifolog.a -- Li-Wen Hsu https://lwhsu.org From owner-freebsd-current@freebsd.org Mon Jun 18 22:33:03 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 124C910022F9; Mon, 18 Jun 2018 22:33:03 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: from mail-wr0-f194.google.com (mail-wr0-f194.google.com [209.85.128.194]) (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 93F7777574; Mon, 18 Jun 2018 22:33:02 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: by mail-wr0-f194.google.com with SMTP id w10-v6so18449429wrk.9; Mon, 18 Jun 2018 15:33:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=r9Wj0z7HLzWRUnIIO9YK6F3UwbDg6QhGUkO5lX/l7Lk=; b=CQtjKVjG/2yjBPQsu/RFczl1yQ1+g//5by4CJnMY1rpHVknKxdjFKcSUeS9A0K9ZRD G/Xb8d1V5AUN9XKDemBoTgysbzh/TxghOmyJ94o9OVs4lnOx0VlxdmyzltMbfHn1Baws WVSYjZacvmp+j+eLV3va31rbK3dr2mc0ancsuJ7IEDo63GlIufywxK0znyLElxVl6wNh Fw5XKS6miNJqwQhIJFo0/Sw/LUHLeMXKDt4EfNGLAsrcyaPzE85PE+RD7q/Z2u43ztJX op+8uH+AJtKa/idNu/1Z6nWZIA/HdS0J5+orglB+HLDJihyzwqv0AznctRmHd5RKZQbr DvIQ== X-Gm-Message-State: APt69E3FgWIBF5LEllolrbgO2hEKTRVob8JuGRqSzEliKCfNFrQeR0Nk EAgwGWEv07FH6nlK3skbPouEvNZ3SnxB1avCGlk= X-Google-Smtp-Source: ADUXVKIkRjT6pu+maTgIWJiZ3Fv3PC8i0gBxShcdqQN0zyDX8jvTe5uxK2V244bYr7YbEjHGsaq6bHOyAZujULBx48I= X-Received: by 2002:adf:ea44:: with SMTP id j4-v6mr11973928wrn.224.1529360859237; Mon, 18 Jun 2018 15:27:39 -0700 (PDT) MIME-Version: 1.0 References: <74EAD684-0E0B-453A-B746-156777CF604A@yahoo.com> <1884103f-d1fb-aca6-2edd-062e11d05617@FreeBSD.org> In-Reply-To: From: Li-Wen Hsu Date: Mon, 18 Jun 2018 18:27:27 -0400 Message-ID: Subject: Re: A head buildworld race visible in the ci.freebsd.org build history To: Mark Millard Cc: Bryan Drewery , FreeBSD Current , FreeBSD Toolchain Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 18 Jun 2018 22:33:03 -0000 On Mon, Jun 18, 2018 at 5:04 PM Mark Millard via freebsd-toolchain wrote: > > On 2018-Jun-18, at 12:42 PM, Bryan Drewery wrote: > > > On 6/15/2018 10:55 PM, Mark Millard wrote: > >> In watching ci.freebsd.org builds I've seen a notable > >> number of one time failures, such as (example from > >> powerpc64): > >> > >> --- all_subdir_lib/libufs --- > >> ranlib -D libufs.a > >> ranlib: fatal: Failed to open 'libufs.a' > >> *** [libufs.a] Error code 70 > >> > >> where the next build works despite the change being > >> irrelevant to whatever ranlib complained about. > >> > >> Other builds failed similarly: > >> > >> --- all_subdir_lib/libbsm --- > >> ranlib -D libbsm_p.a > >> ranlib: fatal: Failed to open 'libbsm_p.a' > >> *** [libbsm_p.a] Error code 70 > >> > >> and: > >> > >> --- kerberos5/lib__L --- > >> ranlib -D libgssapi_spnego_p.a > >> --- libgssapi_spnego.a --- > >> ranlib -D libgssapi_spnego.a > >> --- libgssapi_spnego_p.a --- > >> ranlib: fatal: Failed to open 'libgssapi_spnego_p.a' > >> *** [libgssapi_spnego_p.a] Error code 70 > >> > >> and so on. > >> > >> > >> It is not limited to powerpc64. For example, for aarch64 > >> there are: > >> > >> --- libpam_exec.a --- > >> building static pam_exec library > >> ar -crD libpam_exec.a `NM='nm' NMFLAGS='' lorder pam_exec.o | tsort -q` > >> ranlib -D libpam_exec.a > >> ranlib: fatal: Failed to open 'libpam_exec.a' > >> *** [libpam_exec.a] Error code 70 > >> > >> and: > >> > >> --- all_subdir_lib/libusb --- > >> ranlib -D libusb.a > >> ranlib: fatal: Failed to open 'libusb.a' > >> *** [libusb.a] Error code 70 > >> > >> and: > >> > >> --- all_subdir_lib/libbsnmp --- > >> ranlib: fatal: Failed to open 'libbsnmp.a' > >> --- all_subdir_lib/ncurses --- > >> --- all_subdir_lib/ncurses/panelw --- > >> --- panel.pico --- > >> --- all_subdir_lib/libbsnmp --- > >> *** [libbsnmp.a] Error code 70 > >> > >> > >> Even amd64 gets such: > >> > >> --- libpcap.a --- > >> ranlib -D libpcap.a > >> ranlib: fatal: Failed to open 'libpcap.a' > >> *** [libpcap.a] Error code 70 > >> > >> and: > >> > >> > >> --- libkafs5.a --- > >> ranlib: fatal: Failed to open 'libkafs5.a' > >> --- libkafs5_p.a --- > >> ranlib: fatal: Failed to open 'libkafs5_p.a' > >> --- cddl/lib__L --- > >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/lua/lbaselib.c:60:26: note: include the header or explicitly provide a declaration for 'toupper' > >> --- kerberos5/lib__L --- > >> *** [libkafs5_p.a] Error code 70 > >> > >> make[5]: stopped in /usr/src/kerberos5/lib/libkafs5 > >> --- libkafs5.a --- > >> *** [libkafs5.a] Error code 70 > >> > >> and: > >> > >> > >> --- lib__L --- > >> ranlib -D libclang_rt.asan_cxx-i386.a > >> ranlib: fatal: Failed to open 'libclang_rt.asan_cxx-i386.a' > >> *** [libclang_rt.asan_cxx-i386.a] Error code 70 > >> > >> > >> (Notice the variability in what .a the ranlib's fail for.) > >> > >> > >> > >> > >> > > > > > > I looked at this a few days ago and don't believe it's actually a build > > race. I think there is something wrong with the ar/ranlib on that system > > or something else. I've found no evidence of concurrent building of the > > .a files in question. > > > Looking at a bunch of the failures, spanning multiple > FreeBSD-head-*-build types of builds, I see only: > > NODE_LABELS bhyve_host butler1.nyi.freebsd.org jailer jailer_fast > NODE_NAME butler1.nyi.freebsd.org > > for the failures that I looked at. > > So your "on that system" might well be correct. Thanks for the insight, the build is done in a 11.1-R jail on a -CURRENT host. butler1.nyi is running r333388 (as a canary) while other builders are mostly running r328278. I upgraded few others and it seems can reproduce the issue, and now I downgraded all the build slaves to r328278 before we find the root cause. Li-Wen -- Li-Wen Hsu https://lwhsu.org From owner-freebsd-current@freebsd.org Mon Jun 18 22:34:01 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B743F1002443; Mon, 18 Jun 2018 22:34:01 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 498BF7766F; Mon, 18 Jun 2018 22:34:01 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id EFF1431B3; Mon, 18 Jun 2018 22:34:00 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 1D267A4E8; Mon, 18 Jun 2018 22:34:00 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id Z0ObkPuIcP_D; Mon, 18 Jun 2018 22:33:57 +0000 (UTC) Subject: Re: A head buildworld race visible in the ci.freebsd.org build history DKIM-Filter: OpenDKIM Filter v2.10.3 mail.xzibition.com D9DD5A4E3 To: Li-Wen Hsu Cc: FreeBSD Current , FreeBSD Toolchain References: <74EAD684-0E0B-453A-B746-156777CF604A@yahoo.com> <1884103f-d1fb-aca6-2edd-062e11d05617@FreeBSD.org> <20180618204517.GD2430@kib.kiev.ua> <068108ab-76f2-0f2d-fd92-11c838a4d391@FreeBSD.org> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Autocrypt: addr=bdrewery@FreeBSD.org; prefer-encrypt=mutual; keydata= xsBNBFJphmsBCADiFgmS4bIzwZijrS31SjEMzg+n5zNellgM+HkShwehpqCiyhXdWrvH6dTZ a6u50pbUIX7doTR7W7PQHCjCTqtpwvcj0eulZva+iHFp+XrbgSFHn+VVXgkYP2MFySyZRFab D2qqzJBEJofhpv4HvY6uQI5K99pMqKr1Z/lHqsijYYu4RH2OfwB5PinId7xeldzWEonVoCr+ rfxzO/UrgA6v/3layGZcKNHFjmc3NqoN1DXtdaEHqtjIozzbndVkH6lkFvIpIrI6i5ox8pwp VxsxLCr/4Musd5CWgHiet5kSw2SzNeA8FbxdLYCpXNVu+uBACEbCUP+CSNy3NVfEUxsBABEB AAHNJEJyeWFuIERyZXdlcnkgPGJkcmV3ZXJ5QEZyZWVCU0Qub3JnPsLAgAQTAQoAKgIbAwUL CQgHAwUVCgkICwUWAwIBAAIeAQIXgAIZAQUCWujOIgUJCmB7NwAKCRA113G7bkaXz/xpB/9b /UWIPbieY1IeIuHF2pyYPE7Hytkh3HVsxMA0F5Ma2AYQsXZZeKNKWrF7RPyDyDwUklLHJkhm k3EfClBbHxf08kMIm1vWCJRtgxic9knY/bzYGiWMpHjg3cSd1XfrYH1autYqTZAjDwIkgOjU dR//Tbn4V36sY7y2jz+kdMVWvK53U32aZqiwBbCn4DPe1wSZcUs17mV/0uZdIoGdj74B1orN A/0py5vHYo6HcbBNoaR8pKRLf5VZNRsxqGIMhTucx4SJWcHpuRBWYyvJSFzwvxdK4ZD4Yqoc kFGPVtOXktVMai9exrLvP3G77fKMu8DI6j4QRU4wCesnHuIfRPFuzsBNBFJphmsBCACiVFPf kNfaFtUSuY0395ueo/rMyHPGPQ2iwvERFCpeFGSQSgagpenNHLpFQKTg/dl6FOoST5tqyxMq fyHGHDzzU51bvA/IfaGoNi/BIhTe/toZNMRvpcI3PLjiGcnJnuwCCbAVOAGdb+t5cZtpNdOI cKYmrYG3u9RiBpe6dTF+qLrD/8Bs1wjhduQ8fcNNgnkXu8xDH4ZxY0lIc3QgvYWp9vimlQe6 iKjUd2/DX28ETZcD5h6pYV331KMPTrEI0p0yvFijUZce8c1XHFyL1j9sBAha5qpszJl6Uq5i LolhKRcGfcdmtD72vHQjUYglUyudSJUVyo2gMYjdbiFKzJulABEBAAHCwGUEGAEKAA8CGwwF AlrozigFCQpgez0ACgkQNddxu25Gl8+m5Af/R3VEdxNMAcDIes9ADhQyofj20SPV3eCJ3HYR OebTSuNdOudGt4AAyA8Ks94u9hiIp5IGsc6RDsT9W7O2vgXhd6eV3eiY5Oif5xLIYrIDVu1Y 1GyRxRrPEn/QOqDN6uFZCPwK1aOapGcYCrO9lB0gMuTVfgHanU61rgC9tMX0OoAOyRd+V3/M 8lDNhjJdF/IpO3SdYzKfkwduy4qamw4Gphcx/RfYQvYLq/eDkP8d50PphWdboqWBwNRHayro W/07OGzfxM5fJ5mBsXPQcO2QcRjkyHf6xCM6Hi1qQL4OnXMNE/ZTX0lnOj1/pH93TlzSHZMP TaiiA/MBD3vGsXBmBg== Organization: FreeBSD Message-ID: Date: Mon, 18 Jun 2018 15:33:56 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qOqODywPw7sr1YLQU9do3M2p18zqeWgUz" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 18 Jun 2018 22:34:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qOqODywPw7sr1YLQU9do3M2p18zqeWgUz Content-Type: multipart/mixed; boundary="qlTVijLjr7Vess76ZBjTCf4WFmsuLr5Od"; protected-headers="v1" From: Bryan Drewery To: Li-Wen Hsu Cc: FreeBSD Current , FreeBSD Toolchain Message-ID: Subject: Re: A head buildworld race visible in the ci.freebsd.org build history References: <74EAD684-0E0B-453A-B746-156777CF604A@yahoo.com> <1884103f-d1fb-aca6-2edd-062e11d05617@FreeBSD.org> <20180618204517.GD2430@kib.kiev.ua> <068108ab-76f2-0f2d-fd92-11c838a4d391@FreeBSD.org> In-Reply-To: --qlTVijLjr7Vess76ZBjTCf4WFmsuLr5Od Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/18/2018 3:31 PM, Li-Wen Hsu wrote: > On Mon, Jun 18, 2018 at 6:27 PM Bryan Drewery wr= ote: >> >> On 6/18/2018 1:45 PM, Konstantin Belousov wrote: >>> On Mon, Jun 18, 2018 at 12:42:46PM -0700, Bryan Drewery wrote: >>>> On 6/15/2018 10:55 PM, Mark Millard wrote: >>>>> In watching ci.freebsd.org builds I've seen a notable >>>>> number of one time failures, such as (example from >>>>> powerpc64): >>>>> >>>>> --- all_subdir_lib/libufs --- >>>>> ranlib -D libufs.a >>>>> ranlib: fatal: Failed to open 'libufs.a' >>>>> *** [libufs.a] Error code 70 >>>>> >>>>> where the next build works despite the change being >>>>> irrelevant to whatever ranlib complained about. >>>>> >>>>> Other builds failed similarly: >>>>> >>>>> --- all_subdir_lib/libbsm --- >>>>> ranlib -D libbsm_p.a >>>>> ranlib: fatal: Failed to open 'libbsm_p.a' >>>>> *** [libbsm_p.a] Error code 70 >>>>> >>>>> and: >>>>> >>>>> --- kerberos5/lib__L --- >>>>> ranlib -D libgssapi_spnego_p.a >>>>> --- libgssapi_spnego.a --- >>>>> ranlib -D libgssapi_spnego.a >>>>> --- libgssapi_spnego_p.a --- >>>>> ranlib: fatal: Failed to open 'libgssapi_spnego_p.a' >>>>> *** [libgssapi_spnego_p.a] Error code 70 >>>>> >>>>> and so on. >>>>> >>>>> >>>>> It is not limited to powerpc64. For example, for aarch64 >>>>> there are: >>>>> >>>>> --- libpam_exec.a --- >>>>> building static pam_exec library >>>>> ar -crD libpam_exec.a `NM=3D'nm' NMFLAGS=3D'' lorder pam_exec.o |= tsort -q` >>>>> ranlib -D libpam_exec.a >>>>> ranlib: fatal: Failed to open 'libpam_exec.a' >>>>> *** [libpam_exec.a] Error code 70 >>>>> >>>>> and: >>>>> >>>>> --- all_subdir_lib/libusb --- >>>>> ranlib -D libusb.a >>>>> ranlib: fatal: Failed to open 'libusb.a' >>>>> *** [libusb.a] Error code 70 >>>>> >>>>> and: >>>>> >>>>> --- all_subdir_lib/libbsnmp --- >>>>> ranlib: fatal: Failed to open 'libbsnmp.a' >>>>> --- all_subdir_lib/ncurses --- >>>>> --- all_subdir_lib/ncurses/panelw --- >>>>> --- panel.pico --- >>>>> --- all_subdir_lib/libbsnmp --- >>>>> *** [libbsnmp.a] Error code 70 >>>>> >>>>> >>>>> Even amd64 gets such: >>>>> >>>>> --- libpcap.a --- >>>>> ranlib -D libpcap.a >>>>> ranlib: fatal: Failed to open 'libpcap.a' >>>>> *** [libpcap.a] Error code 70 >>>>> >>>>> and: >>>>> >>>>> >>>>> --- libkafs5.a --- >>>>> ranlib: fatal: Failed to open 'libkafs5.a' >>>>> --- libkafs5_p.a --- >>>>> ranlib: fatal: Failed to open 'libkafs5_p.a' >>>>> --- cddl/lib__L --- >>>>> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/lua/lbaseli= b.c:60:26: note: include the header or explicitly provide a dec= laration for 'toupper' >>>>> --- kerberos5/lib__L --- >>>>> *** [libkafs5_p.a] Error code 70 >>>>> >>>>> make[5]: stopped in /usr/src/kerberos5/lib/libkafs5 >>>>> --- libkafs5.a --- >>>>> *** [libkafs5.a] Error code 70 >>>>> >>>>> and: >>>>> >>>>> >>>>> --- lib__L --- >>>>> ranlib -D libclang_rt.asan_cxx-i386.a >>>>> ranlib: fatal: Failed to open 'libclang_rt.asan_cxx-i386.a' >>>>> *** [libclang_rt.asan_cxx-i386.a] Error code 70 >>>>> >>>>> >>>>> (Notice the variability in what .a the ranlib's fail for.) >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> I looked at this a few days ago and don't believe it's actually a bu= ild >>>> race. I think there is something wrong with the ar/ranlib on that sy= stem >>>> or something else. I've found no evidence of concurrent building of = the >>>> .a files in question. >>> >>> FWIW, I got the similar failure when I did last checks for the OFED >>> commit. For me, it was libgcc.a. >>> >> >> If it was -lgcc_s then it's a known rare build race due to >> tools/install.sh not handling -S. >=20 > It seems a more general problem, this one: >=20 > https://ci.freebsd.org/job/FreeBSD-head-aarch64-build/8190/console >=20 > calls for libcuse_p.a, while this one: >=20 > https://ci.freebsd.org/job/FreeBSD-head-mips-build/2919/console >=20 > calls for libfifolog.a >=20 Well why is ar -> ranlib so special? Nothing else is failing. What filesystem are these using for objdirs? What revision is the host kernel? --=20 Regards, Bryan Drewery --qlTVijLjr7Vess76ZBjTCf4WFmsuLr5Od-- --qOqODywPw7sr1YLQU9do3M2p18zqeWgUz 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 iQEcBAEBAgAGBQJbKDNUAAoJEDXXcbtuRpfPizUIALxtnZDaono3T4sjzUTN9qIM GqoVNd6mb+d61ntQ+UKp6hdgKni7tikPsqFiSf4aAC0NSj2FurbB4sgKKjdsCl8R WtzerM8WpPEy/ro2Ow5hxntGfW+F308W5dePXGS+ugkTqz3FMuJ0tGfNre/cEfHX f91iVrouAW45Bfg8IRIqdk2Py7aaDTRXUbcSYyiFb9jwQf0EWS5seR9SEu30Yjck MStso/CDuNBUpEzPfObww2lr7TaJFdg51KfshQ6cFkby6mzlylRMigsUlXcyR3Z7 Xzb7qvL3XPsBxgPYmFhemEqCIlX94lEvxBGtVzGrPT0k55BEB/DYoxVj5ym98N8= =O4Hw -----END PGP SIGNATURE----- --qOqODywPw7sr1YLQU9do3M2p18zqeWgUz-- From owner-freebsd-current@freebsd.org Mon Jun 18 23:08:34 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1EBCD10048B6; Mon, 18 Jun 2018 23:08:34 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 93A5F78E14; Mon, 18 Jun 2018 23:08:33 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 593A83A8D; Mon, 18 Jun 2018 23:08:33 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 7DB64A53D; Mon, 18 Jun 2018 23:08:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id afs3gkHcCQbM; Mon, 18 Jun 2018 23:08:26 +0000 (UTC) Subject: Re: A head buildworld race visible in the ci.freebsd.org build history DKIM-Filter: OpenDKIM Filter v2.10.3 mail.xzibition.com 2342DA538 To: Li-Wen Hsu , Mark Millard Cc: FreeBSD Current , FreeBSD Toolchain References: <74EAD684-0E0B-453A-B746-156777CF604A@yahoo.com> <1884103f-d1fb-aca6-2edd-062e11d05617@FreeBSD.org> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Autocrypt: addr=bdrewery@FreeBSD.org; prefer-encrypt=mutual; keydata= xsBNBFJphmsBCADiFgmS4bIzwZijrS31SjEMzg+n5zNellgM+HkShwehpqCiyhXdWrvH6dTZ a6u50pbUIX7doTR7W7PQHCjCTqtpwvcj0eulZva+iHFp+XrbgSFHn+VVXgkYP2MFySyZRFab D2qqzJBEJofhpv4HvY6uQI5K99pMqKr1Z/lHqsijYYu4RH2OfwB5PinId7xeldzWEonVoCr+ rfxzO/UrgA6v/3layGZcKNHFjmc3NqoN1DXtdaEHqtjIozzbndVkH6lkFvIpIrI6i5ox8pwp VxsxLCr/4Musd5CWgHiet5kSw2SzNeA8FbxdLYCpXNVu+uBACEbCUP+CSNy3NVfEUxsBABEB AAHNJEJyeWFuIERyZXdlcnkgPGJkcmV3ZXJ5QEZyZWVCU0Qub3JnPsLAgAQTAQoAKgIbAwUL CQgHAwUVCgkICwUWAwIBAAIeAQIXgAIZAQUCWujOIgUJCmB7NwAKCRA113G7bkaXz/xpB/9b /UWIPbieY1IeIuHF2pyYPE7Hytkh3HVsxMA0F5Ma2AYQsXZZeKNKWrF7RPyDyDwUklLHJkhm k3EfClBbHxf08kMIm1vWCJRtgxic9knY/bzYGiWMpHjg3cSd1XfrYH1autYqTZAjDwIkgOjU dR//Tbn4V36sY7y2jz+kdMVWvK53U32aZqiwBbCn4DPe1wSZcUs17mV/0uZdIoGdj74B1orN A/0py5vHYo6HcbBNoaR8pKRLf5VZNRsxqGIMhTucx4SJWcHpuRBWYyvJSFzwvxdK4ZD4Yqoc kFGPVtOXktVMai9exrLvP3G77fKMu8DI6j4QRU4wCesnHuIfRPFuzsBNBFJphmsBCACiVFPf kNfaFtUSuY0395ueo/rMyHPGPQ2iwvERFCpeFGSQSgagpenNHLpFQKTg/dl6FOoST5tqyxMq fyHGHDzzU51bvA/IfaGoNi/BIhTe/toZNMRvpcI3PLjiGcnJnuwCCbAVOAGdb+t5cZtpNdOI cKYmrYG3u9RiBpe6dTF+qLrD/8Bs1wjhduQ8fcNNgnkXu8xDH4ZxY0lIc3QgvYWp9vimlQe6 iKjUd2/DX28ETZcD5h6pYV331KMPTrEI0p0yvFijUZce8c1XHFyL1j9sBAha5qpszJl6Uq5i LolhKRcGfcdmtD72vHQjUYglUyudSJUVyo2gMYjdbiFKzJulABEBAAHCwGUEGAEKAA8CGwwF AlrozigFCQpgez0ACgkQNddxu25Gl8+m5Af/R3VEdxNMAcDIes9ADhQyofj20SPV3eCJ3HYR OebTSuNdOudGt4AAyA8Ks94u9hiIp5IGsc6RDsT9W7O2vgXhd6eV3eiY5Oif5xLIYrIDVu1Y 1GyRxRrPEn/QOqDN6uFZCPwK1aOapGcYCrO9lB0gMuTVfgHanU61rgC9tMX0OoAOyRd+V3/M 8lDNhjJdF/IpO3SdYzKfkwduy4qamw4Gphcx/RfYQvYLq/eDkP8d50PphWdboqWBwNRHayro W/07OGzfxM5fJ5mBsXPQcO2QcRjkyHf6xCM6Hi1qQL4OnXMNE/ZTX0lnOj1/pH93TlzSHZMP TaiiA/MBD3vGsXBmBg== Organization: FreeBSD Message-ID: Date: Mon, 18 Jun 2018 16:08:24 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uDsvE7PHdQU0ABYYxgVDc9bzdb55x1GeO" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 18 Jun 2018 23:08:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uDsvE7PHdQU0ABYYxgVDc9bzdb55x1GeO Content-Type: multipart/mixed; boundary="2k2GCiexwz0mFSRCZWPGmIkNNkl9s1ckj"; protected-headers="v1" From: Bryan Drewery To: Li-Wen Hsu , Mark Millard Cc: FreeBSD Current , FreeBSD Toolchain Message-ID: Subject: Re: A head buildworld race visible in the ci.freebsd.org build history References: <74EAD684-0E0B-453A-B746-156777CF604A@yahoo.com> <1884103f-d1fb-aca6-2edd-062e11d05617@FreeBSD.org> In-Reply-To: --2k2GCiexwz0mFSRCZWPGmIkNNkl9s1ckj Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/18/2018 3:27 PM, Li-Wen Hsu wrote: > ranlib -D libpcap.a > ranlib: fatal: Failed to open 'libpcap.a' Where is this error even coming from? It's not in the usr.bin/ar code and ranlib does not cause it. # ranlib -D uh ranlib: warning: uh: no such file --=20 Regards, Bryan Drewery --2k2GCiexwz0mFSRCZWPGmIkNNkl9s1ckj-- --uDsvE7PHdQU0ABYYxgVDc9bzdb55x1GeO 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 iQEcBAEBAgAGBQJbKDtoAAoJEDXXcbtuRpfPfzoIAJmx5YHw5Agv5dSLxscNovqI uze0FYo9cMS03OTGXVM89V6kSVmB9DIolKWKjE25tLAUqJWo8WWoGMJxVnxNEdb7 OGUnh+d7mPMMtfWm9SPQlrxzrNcx98NP4HfU/79PpajDmFxYnk+EyvpPxWvv3Fp1 /lFucYp3MSTWSO2M1F5ZCpEcarfLLaM3LFWVbrjappoBnDHxbV28IPRLFGRkhP/M LT3syTrdTbwOvSmskeRhnbeGVGguFwee6XdS3nNlX6VMHUSMKw+YoGxw96IFJKQC aVhH7wAJQ3nGjR/zFFI75CVJ7ta7G5/4GxHaz/Dos19Opg30uvxp8SIcyE3Txo0= =BrgJ -----END PGP SIGNATURE----- --uDsvE7PHdQU0ABYYxgVDc9bzdb55x1GeO-- From owner-freebsd-current@freebsd.org Mon Jun 18 23:29:16 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 57AD910057F6; Mon, 18 Jun 2018 23:29:16 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EA39479868; Mon, 18 Jun 2018 23:29:15 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id B63DA3D93; Mon, 18 Jun 2018 23:29:15 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id A1290A564; Mon, 18 Jun 2018 23:29:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id GZcIZP0abfkK; Mon, 18 Jun 2018 23:29:07 +0000 (UTC) To: Li-Wen Hsu , Mark Millard DKIM-Filter: OpenDKIM Filter v2.10.3 mail.xzibition.com BF589A55F Cc: FreeBSD Current , FreeBSD Toolchain References: <74EAD684-0E0B-453A-B746-156777CF604A@yahoo.com> <1884103f-d1fb-aca6-2edd-062e11d05617@FreeBSD.org> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Autocrypt: addr=bdrewery@FreeBSD.org; prefer-encrypt=mutual; keydata= xsBNBFJphmsBCADiFgmS4bIzwZijrS31SjEMzg+n5zNellgM+HkShwehpqCiyhXdWrvH6dTZ a6u50pbUIX7doTR7W7PQHCjCTqtpwvcj0eulZva+iHFp+XrbgSFHn+VVXgkYP2MFySyZRFab D2qqzJBEJofhpv4HvY6uQI5K99pMqKr1Z/lHqsijYYu4RH2OfwB5PinId7xeldzWEonVoCr+ rfxzO/UrgA6v/3layGZcKNHFjmc3NqoN1DXtdaEHqtjIozzbndVkH6lkFvIpIrI6i5ox8pwp VxsxLCr/4Musd5CWgHiet5kSw2SzNeA8FbxdLYCpXNVu+uBACEbCUP+CSNy3NVfEUxsBABEB AAHNJEJyeWFuIERyZXdlcnkgPGJkcmV3ZXJ5QEZyZWVCU0Qub3JnPsLAgAQTAQoAKgIbAwUL CQgHAwUVCgkICwUWAwIBAAIeAQIXgAIZAQUCWujOIgUJCmB7NwAKCRA113G7bkaXz/xpB/9b /UWIPbieY1IeIuHF2pyYPE7Hytkh3HVsxMA0F5Ma2AYQsXZZeKNKWrF7RPyDyDwUklLHJkhm k3EfClBbHxf08kMIm1vWCJRtgxic9knY/bzYGiWMpHjg3cSd1XfrYH1autYqTZAjDwIkgOjU dR//Tbn4V36sY7y2jz+kdMVWvK53U32aZqiwBbCn4DPe1wSZcUs17mV/0uZdIoGdj74B1orN A/0py5vHYo6HcbBNoaR8pKRLf5VZNRsxqGIMhTucx4SJWcHpuRBWYyvJSFzwvxdK4ZD4Yqoc kFGPVtOXktVMai9exrLvP3G77fKMu8DI6j4QRU4wCesnHuIfRPFuzsBNBFJphmsBCACiVFPf kNfaFtUSuY0395ueo/rMyHPGPQ2iwvERFCpeFGSQSgagpenNHLpFQKTg/dl6FOoST5tqyxMq fyHGHDzzU51bvA/IfaGoNi/BIhTe/toZNMRvpcI3PLjiGcnJnuwCCbAVOAGdb+t5cZtpNdOI cKYmrYG3u9RiBpe6dTF+qLrD/8Bs1wjhduQ8fcNNgnkXu8xDH4ZxY0lIc3QgvYWp9vimlQe6 iKjUd2/DX28ETZcD5h6pYV331KMPTrEI0p0yvFijUZce8c1XHFyL1j9sBAha5qpszJl6Uq5i LolhKRcGfcdmtD72vHQjUYglUyudSJUVyo2gMYjdbiFKzJulABEBAAHCwGUEGAEKAA8CGwwF AlrozigFCQpgez0ACgkQNddxu25Gl8+m5Af/R3VEdxNMAcDIes9ADhQyofj20SPV3eCJ3HYR OebTSuNdOudGt4AAyA8Ks94u9hiIp5IGsc6RDsT9W7O2vgXhd6eV3eiY5Oif5xLIYrIDVu1Y 1GyRxRrPEn/QOqDN6uFZCPwK1aOapGcYCrO9lB0gMuTVfgHanU61rgC9tMX0OoAOyRd+V3/M 8lDNhjJdF/IpO3SdYzKfkwduy4qamw4Gphcx/RfYQvYLq/eDkP8d50PphWdboqWBwNRHayro W/07OGzfxM5fJ5mBsXPQcO2QcRjkyHf6xCM6Hi1qQL4OnXMNE/ZTX0lnOj1/pH93TlzSHZMP TaiiA/MBD3vGsXBmBg== Organization: FreeBSD Subject: Re: A head buildworld race visible in the ci.freebsd.org build history Message-ID: <33a43aac-231f-6158-1de4-f5dbfaf195df@FreeBSD.org> Date: Mon, 18 Jun 2018 16:29:05 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i3QlIgdhlde0b31PmQhO90vQjY4MPnZCT" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 18 Jun 2018 23:29:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --i3QlIgdhlde0b31PmQhO90vQjY4MPnZCT Content-Type: multipart/mixed; boundary="DAW6nsCxBca1w2EzimZDNtVm0TBjJ6W4p"; protected-headers="v1" From: Bryan Drewery To: Li-Wen Hsu , Mark Millard Cc: FreeBSD Current , FreeBSD Toolchain Message-ID: <33a43aac-231f-6158-1de4-f5dbfaf195df@FreeBSD.org> Subject: Re: A head buildworld race visible in the ci.freebsd.org build history References: <74EAD684-0E0B-453A-B746-156777CF604A@yahoo.com> <1884103f-d1fb-aca6-2edd-062e11d05617@FreeBSD.org> In-Reply-To: --DAW6nsCxBca1w2EzimZDNtVm0TBjJ6W4p Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/18/2018 3:27 PM, Li-Wen Hsu wrote: > On Mon, Jun 18, 2018 at 5:04 PM Mark Millard via freebsd-toolchain > wrote: >> >> On 2018-Jun-18, at 12:42 PM, Bryan Drewery w= rote: >> >>> On 6/15/2018 10:55 PM, Mark Millard wrote: >>>> In watching ci.freebsd.org builds I've seen a notable >>>> number of one time failures, such as (example from >>>> powerpc64): >>>> >>>> --- all_subdir_lib/libufs --- >>>> ranlib -D libufs.a >>>> ranlib: fatal: Failed to open 'libufs.a' >>>> *** [libufs.a] Error code 70 >>>> >>>> where the next build works despite the change being >>>> irrelevant to whatever ranlib complained about. >>>> >>>> Other builds failed similarly: >>>> >>>> --- all_subdir_lib/libbsm --- >>>> ranlib -D libbsm_p.a >>>> ranlib: fatal: Failed to open 'libbsm_p.a' >>>> *** [libbsm_p.a] Error code 70 >>>> >>>> and: >>>> >>>> --- kerberos5/lib__L --- >>>> ranlib -D libgssapi_spnego_p.a >>>> --- libgssapi_spnego.a --- >>>> ranlib -D libgssapi_spnego.a >>>> --- libgssapi_spnego_p.a --- >>>> ranlib: fatal: Failed to open 'libgssapi_spnego_p.a' >>>> *** [libgssapi_spnego_p.a] Error code 70 >>>> >>>> and so on. >>>> >>>> >>>> It is not limited to powerpc64. For example, for aarch64 >>>> there are: >>>> >>>> --- libpam_exec.a --- >>>> building static pam_exec library >>>> ar -crD libpam_exec.a `NM=3D'nm' NMFLAGS=3D'' lorder pam_exec.o | = tsort -q` >>>> ranlib -D libpam_exec.a >>>> ranlib: fatal: Failed to open 'libpam_exec.a' >>>> *** [libpam_exec.a] Error code 70 >>>> >>>> and: >>>> >>>> --- all_subdir_lib/libusb --- >>>> ranlib -D libusb.a >>>> ranlib: fatal: Failed to open 'libusb.a' >>>> *** [libusb.a] Error code 70 >>>> >>>> and: >>>> >>>> --- all_subdir_lib/libbsnmp --- >>>> ranlib: fatal: Failed to open 'libbsnmp.a' >>>> --- all_subdir_lib/ncurses --- >>>> --- all_subdir_lib/ncurses/panelw --- >>>> --- panel.pico --- >>>> --- all_subdir_lib/libbsnmp --- >>>> *** [libbsnmp.a] Error code 70 >>>> >>>> >>>> Even amd64 gets such: >>>> >>>> --- libpcap.a --- >>>> ranlib -D libpcap.a >>>> ranlib: fatal: Failed to open 'libpcap.a' >>>> *** [libpcap.a] Error code 70 >>>> >>>> and: >>>> >>>> >>>> --- libkafs5.a --- >>>> ranlib: fatal: Failed to open 'libkafs5.a' >>>> --- libkafs5_p.a --- >>>> ranlib: fatal: Failed to open 'libkafs5_p.a' >>>> --- cddl/lib__L --- >>>> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/lua/lbaselib= =2Ec:60:26: note: include the header or explicitly provide a de= claration for 'toupper' >>>> --- kerberos5/lib__L --- >>>> *** [libkafs5_p.a] Error code 70 >>>> >>>> make[5]: stopped in /usr/src/kerberos5/lib/libkafs5 >>>> --- libkafs5.a --- >>>> *** [libkafs5.a] Error code 70 >>>> >>>> and: >>>> >>>> >>>> --- lib__L --- >>>> ranlib -D libclang_rt.asan_cxx-i386.a >>>> ranlib: fatal: Failed to open 'libclang_rt.asan_cxx-i386.a' >>>> *** [libclang_rt.asan_cxx-i386.a] Error code 70 >>>> >>>> >>>> (Notice the variability in what .a the ranlib's fail for.) >>>> >>>> >>>> >>>> >>>> >>> >>> >>> I looked at this a few days ago and don't believe it's actually a bui= ld >>> race. I think there is something wrong with the ar/ranlib on that sys= tem >>> or something else. I've found no evidence of concurrent building of t= he >>> .a files in question. >> >> >> Looking at a bunch of the failures, spanning multiple >> FreeBSD-head-*-build types of builds, I see only: >> >> NODE_LABELS bhyve_host butler1.nyi.freebsd.org jailer jailer_fast >> NODE_NAME butler1.nyi.freebsd.org >> >> for the failures that I looked at. >> >> So your "on that system" might well be correct. >=20 > Thanks for the insight, the build is done in a 11.1-R jail on a > -CURRENT host. butler1.nyi is running r333388 (as a canary) while > other builders are mostly running r328278. I upgraded few others and > it seems can reproduce the issue, and now I downgraded all the build > slaves to r328278 before we find the root cause. >=20 The error is coming from libarchive which had a change between those revisions: > -----------------------------------------------------------------------= - > r328332 | mm | 2018-01-24 06:24:17 -0800 (Wed, 24 Jan 2018) | 14 lines >=20 > MFV r328323,328324: > Sync libarchive with vendor. >=20 > Relevant vendor changes: > PR #893: delete dead ppmd7 alloc callbacks > PR #904: Fix archive freeing bug in bsdcat > PR #961: Fix ZIP format names > PR #962: Don't modify attributes for existing directories > when ARCHIVE_EXTRACT_NO_OVERWRITE is set > PR #964: Fix -Werror=3Dimplicit-fallthrough=3D for GCC 7 > PR #970: zip: Allow backslash as path separator >=20 > MFC after: 1 week >=20 > -----------------------------------------------------------------------= - Nothing obvious stands out in the change to me though from a brief look. --=20 Regards, Bryan Drewery --DAW6nsCxBca1w2EzimZDNtVm0TBjJ6W4p-- --i3QlIgdhlde0b31PmQhO90vQjY4MPnZCT 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 iQEcBAEBAgAGBQJbKEBBAAoJEDXXcbtuRpfPmD8H/i03v1lLcO6wmdDY0EJ9BZzz jhzqJukgt5kfgoj4N7yX/XsErGtwQqgbSDa5oQ/Hfbhwlsl+McpSiNyLgiKmz35Y u0LPuGQRAmcygyScGKKIlL8rZKdw77G7Ic4sIuXJcXtaJeQNm7iq0b7od0vCP9ZA U8XQgfrBNVgkvPIBdkQyKcIqAN+XCG5+0woUzKjQgZN5YtIw5qqRzOtCdx/qy/C/ S26ZR8mz9JTWG9BKqL2TUoo+++j0+Uv9+LDmqdbMi93A9LFKGSDzD8IEl9eOroXV pBy79ecl2lSKUadAG/BXtyT/34rub6mrTRUwFAPrWEw21ALWiw3kkQbGXocTFRw= =UMfb -----END PGP SIGNATURE----- --i3QlIgdhlde0b31PmQhO90vQjY4MPnZCT-- From owner-freebsd-current@freebsd.org Tue Jun 19 00:36:19 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E7AA100942D; Tue, 19 Jun 2018 00:36:19 +0000 (UTC) (envelope-from carpeddiem@gmail.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 C447F7BD1F; Tue, 19 Jun 2018 00:36:18 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x22e.google.com with SMTP id s26-v6so18522976ioj.4; Mon, 18 Jun 2018 17:36:18 -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=jNvlqyhBKU+ZkMgz7MEQ9Ubw0OxqQMQocyxjAZdBe/Y=; b=IOGJenIgo5Mj7bnStFInIjz2eOFyE2xX+pIPAoVbt4UZ3mu0bJQ0jRR35MzYJMUBRA NPK3BA2P85ZrRoWElcHOw20mk1OUzXVeMMF6avDe4I+uTY3+7oaCa18vnDp/EuCUQ8C1 7hs+5plmmJVu6qX16TiGKaovYfjXl7BrD6QFTfIOrB5b2pu0oL0sfggi/jmRRUk6wKkr ngLSbMrJLkXsQGFXsufmMhhuSvuvkbQsbnl095fmQUX1DnJBxAP3j3NlMIZAlj/oGpdt bQhqU/wPoDFbeGBBw5AwyxuenlVL0hZ2lnvY6bZ/boGRRPXxp+ubLi9XL5EdJ5wXh85O AlqQ== 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=jNvlqyhBKU+ZkMgz7MEQ9Ubw0OxqQMQocyxjAZdBe/Y=; b=pNhaqam6nbSyvNjH/3d9WqOY+KLMzwySSjwsFqhJU8ylFS9rqizWLEX5lFl1b21BFJ 8M7QUHwUw+l1X5jz7itFFlCeQsSVYi2iVdqZOjrtWDk8Z1mOVW/wxXgdqqS+bVqO6mws oIafQufrkXPmY7lSfM2UuT2WhFfW2+wZA6/AYVxK3n6jt/+LcRg4jpwcEusPzbKdNrHz YOBtxYwUiIEeoFv36/4FhSBYOELYGyAHNLjmv9irkHmF15jwYZWhZ4TlsnXCr0NGc4hr 9qQ7Ety5Mw5Qm7F3SiRnOZg8MLbp0mpBioTa7gpT5wJDirMOxVEGECrJ//CM1LDP/jAy nlBw== X-Gm-Message-State: APt69E3egvZMQlijTx3jdYdavcM+/Dk2SLVGjl7H87xuUnWeJht51LUI ItZIl44P+4zovwzBZKlXUOMEQ6E1Bcg2yLvVcQH1yVuo X-Google-Smtp-Source: ADUXVKLXHrQMgbWRVoD22ZY5aoSRKwZdDji0BTE9b/O7Crg/oS8VN+8svawcvw0FBAaTOrBHYdYuQB3GstPemKJ+rzw= X-Received: by 2002:a6b:2cd:: with SMTP id 196-v6mr11546846ioc.294.1529368577916; Mon, 18 Jun 2018 17:36:17 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 2002:a6b:87c4:0:0:0:0:0 with HTTP; Mon, 18 Jun 2018 17:35:57 -0700 (PDT) In-Reply-To: <33a43aac-231f-6158-1de4-f5dbfaf195df@FreeBSD.org> References: <74EAD684-0E0B-453A-B746-156777CF604A@yahoo.com> <1884103f-d1fb-aca6-2edd-062e11d05617@FreeBSD.org> <33a43aac-231f-6158-1de4-f5dbfaf195df@FreeBSD.org> From: Ed Maste Date: Mon, 18 Jun 2018 20:35:57 -0400 X-Google-Sender-Auth: c9IMJaSP5MMkbVOjcY-FIJMhu1I Message-ID: Subject: Re: A head buildworld race visible in the ci.freebsd.org build history To: Bryan Drewery Cc: Li-Wen Hsu , Mark Millard , FreeBSD Current , FreeBSD Toolchain Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 19 Jun 2018 00:36:19 -0000 On 18 June 2018 at 19:29, Bryan Drewery wrote: > > The error is coming from libarchive which had a change between those > revisions: > >> ------------------------------------------------------------------------ >> r328332 | mm | 2018-01-24 06:24:17 -0800 (Wed, 24 Jan 2018) | 14 lines Li-Wen reported that the build is done in a 11.1-rel jail though, so the libarchive (or any userland) change shouldn't be responsible. Can we update a canary builder to somewhere between r328278 and r333388? From owner-freebsd-current@freebsd.org Tue Jun 19 00:37:35 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F08D2100959A; Tue, 19 Jun 2018 00:37:34 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 95AFF7BFBB; Tue, 19 Jun 2018 00:37:34 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (unknown [76.212.85.177]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: truckman) by smtp.freebsd.org (Postfix) with ESMTPSA id EB81D17B16; Tue, 19 Jun 2018 00:37:33 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Date: Mon, 18 Jun 2018 17:37:32 -0700 (PDT) From: Don Lewis Subject: Re: review of nfsd rc.d script patch To: Rick Macklem cc: "rc@freebsd.org" , "freebsd-current@freebsd.org" In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 19 Jun 2018 00:37:35 -0000 On 15 Jun, Rick Macklem wrote: > Hi, > > For the pNFS service MDS machine, the nfsd can't be started until all nfs mounts > in /etc/fstab are done. > I think that adding "mountcritremote" to the "# REQUIRE:" line is sufficient to do this? > > I don't think delaying the startup of the nfsd daemon until after any NFS mounts > are done will do any harm, but if others think it would be a POLA violation, > I could make this dependent on the pNFS service being enabled. > Does anyone think this would cause a POLA violation? Sounds like that would break cross mounts. Back in the olden days before the automounter, I would set up workstation clusters with hosta exporting local filesystem /home/hosta, and hostb exporting /home/hostb. In addition, hosta would do a bg NFS mount of /home/hostb and hostb would do a bg NFS mount of /home/hosta. That way everybody would have a consistent view of everything. If a power failure took down everything, the first system up would export its local filesystem and even though it wouldn't be able to mount any remote filesystems, mount would background itself at the boot would complete. As the remaining machines came up, they would be able to mount the remote filesystems of the machine that came up earlier, and the early machines would mount the filesystems from the later machines as they became available. If nfsd is delayed until all the NFS filesystems are mounted, the above setup would deadlock. From owner-freebsd-current@freebsd.org Tue Jun 19 01:13:29 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D66AA100C0FB for ; Tue, 19 Jun 2018 01:13:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-15.consmr.mail.bf2.yahoo.com (sonic313-15.consmr.mail.bf2.yahoo.com [74.6.133.125]) (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 7BEC17E08E for ; Tue, 19 Jun 2018 01:13:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: IynvXs0VM1m3.VvHoy6U88U8XAjdmOQchCbQPKhC01ICleZihgGgFTpIvgwof2I yAMBfLlEa2w0ogPLmveXC0TNKwFzzdTGn1gkLilJSbNTYllW8MqVUZOcC0DiqgS1X8kbgFKR5Wus Y941yz0rOqrU..oQi280jctjy_hyHtHWf5JRgxsovLsY75LZ.lTsnZ_UUtpQVHJJaeHArohh9A8C k8kfC.ce6upgaHSJ5bQThVacHs0a._WzYFlZCZJYe.BexH_QncbIOW.tJPXMrIlr6B4o.JxCqaLe 2JrW0VMLjUdwmMVH6yxm_HEMQn4Z8txLw_cVCxJ.wX7EmhZ922zernuV1NHZPq4zX9_APFkHCUb7 eyOeU0U.HluulAc0rTI_XodQubeKKUDZnkLO0IqM6z5JVPAVFiWR3yCjxF3HUu1pj1UrqaSQdaYw DyqUJYKU0s0BiPOLa.F27tHw13h2OhBwUMHqgFkPP7EtU1Dv0cmIy3HAlU_nzjbLfzGkAwpPqL74 i5mHrZsnJ3brnErQ1QIXhAgWAbYp9N7R0U7iNTndt0DFAeEoEHPqp.4e_oZQP52xAZ11f1uK61oD WUdlsWtnh0dePBXzHYvQ_FSTMfQRWriUHFVTEjWAQjzXVgSZ_wyATlEuqXZaNsolMW5i_co10v06 lLZAu5Nv519zE9cT75FmpaUdqUacgu3MllDmppUMfejoU97SD86ZWfuMMFNq5jaXHoTKuk3KnX.1 i7fI.ZpYaFiyzX3aK3kAgAu6O4kOLN0IPoiA93NMxPqTKoK_eWXz6aU_ZWKMDZT.W2bMlcYuRsmC qXoggIAcH0NF1yhS3sSeALoKAMZOOKK9DpFsTA1h48AWJxm0.I9bTi47rblB6rRKiItl0qNqi4b5 2b2KTOxV1afJ_p8d3Y5AMMQsS99LfmvXkfKP673sYB9gH8KMvFcXOFVwMmzveR7GsrSTfx58bEuB 8yb.FzTY- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.bf2.yahoo.com with HTTP; Tue, 19 Jun 2018 01:13:22 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp425.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ac04fc78ca5986cea3b5b7125b0a177a; Tue, 19 Jun 2018 01:03:14 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: A head buildworld race visible in the ci.freebsd.org build history From: Mark Millard In-Reply-To: Date: Mon, 18 Jun 2018 18:03:12 -0700 Cc: Li-Wen Hsu , FreeBSD Current , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <07C8E943-BDED-4912-8856-0ECCED7014A3@yahoo.com> References: <74EAD684-0E0B-453A-B746-156777CF604A@yahoo.com> <1884103f-d1fb-aca6-2edd-062e11d05617@FreeBSD.org> To: Bryan Drewery X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 19 Jun 2018 01:13:29 -0000 On 2018-Jun-18, at 4:08 PM, Bryan Drewery = wrote: > On 6/18/2018 3:27 PM, Li-Wen Hsu wrote: >> ranlib -D libpcap.a >> ranlib: fatal: Failed to open 'libpcap.a' >=20 > Where is this error even coming from? It's not in the usr.bin/ar code > and ranlib does not cause it. >=20 > # ranlib -D uh > ranlib: warning: uh: no such file A more complete sequence is (with some other text mixed in, as in where I got the text from on ci.freebsd.org): --- libvgl.a --- building static vgl library ar -crD libvgl.a `NM=3D'nm' NMFLAGS=3D'' lorder main.o simple.o = bitmap.o text.o mouse.o keyboard.o | tsort -q`=20 --- all_subdir_lib/libsysdecode --- ranlib -D libsysdecode.a --- all_subdir_lib/libvgl --- ranlib -D libvgl.a ranlib: fatal: Failed to open 'libvgl.a' --- all_subdir_lib/libsysdecode --- ranlib: fatal: Failed to open 'libsysdecode.a' --- all_subdir_lib/libvgl --- *** [libvgl.a] Error code 70 So, in essence, ar -crD libvgl.a `NM=3D'nm' NMFLAGS=3D'' lorder main.o simple.o = bitmap.o text.o mouse.o keyboard.o | tsort -q`=20 ranlib -D libvgl.a ranlib: fatal: Failed to open 'libvgl.a' It is not obvious to me that the "Failed to open" means that there was "no such file". Might there be some other form of "Failed to open" for a file that does exist from the ar at least having created its output .a file? =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Tue Jun 19 01:46:52 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0BB6710107A9 for ; Tue, 19 Jun 2018 01:46:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-30.consmr.mail.ne1.yahoo.com (sonic301-30.consmr.mail.ne1.yahoo.com [66.163.184.199]) (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 996B781092 for ; Tue, 19 Jun 2018 01:46:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: gKFNcYwVM1klxFcaxXwwALbH7RB8T1u1brMBDm862JWLfh90s5K.jIBP1GcH0vG 52fby_Ku.NmmhTu36kjMFROxKnRvYBtoBAzj6hqbqBjzxE20Ha0HmG0zNpDAAU5r4Ycl9WRpnZX1 2G1FWZnukKPNjj2Z.2vG34u3nreqGZI6GcaimFBw1NgkbgPifMGYlO11T5OveEMEriz2iqudSBKw W5pllHplGxhcIxk53vXCwyKrP3EdtSK6lMP1KDSVbKu_.7sYuMeJbTZ9HOc__aXEET7uKCFE1b3X M9dAViv8x.ERpiujZmI5VK8IJ0wul3yl.RBosX_3IPCO6fxY3zPl74uEMyhSx4zFXy6xc5_QffCF sD.A0bYDMs..IX29GJdnKUSDhOImaW2rSVSEvFFM3haIfrb2_MZl0yrBSOfCOUC8Xa5OQpKu8Vmh b6aQVLlw22UZlCEPSg5y2joGCOsCcMwHzB5owR62wt6hlGkeQJMDnI6szoqdVtPJfMMKLTHeFFW4 vmYRGxQR4h2cqiJ_bb.hJxXfpLfAG86RfgRLtEpZ1H99kC89IFJTmnz.P7IO_gsEfXL9wVNxXTaV _D30tom2AvnmEo8VrtUxZ6c4sYwCnDXnYSjughiui8bpwEJcYHP_Zgh8z.17GIqgwe2zXlCBxF1t _r_Z2h3cFYKu5WbPTbEsBedVy2TeGcHrNtlnEfcM5VHnaVTo1giWAmX26YOLViHS_uEwAljOAvHE MscMyS8n0Owdf74aXL2Lywif.Oh_Ybv3aU1j_7vOGGgvnQ3QcJx9LRxl3kp._kV1CpvkBHSXVyAF QZZvFZR1oM_.dzxeQy2Pw5pLg7ENHrrrZ1tfgw24iwPzbolDLUNiJ8YeaGEwi89vprR1pfLZcbMW voLgTcmp.0RcmTAYj.O_RYCKOBRBYnF4ilDxj9gw5QMaeFCvE8jegjRHX3KsltDFhy.WWBIFAsV8 Il0av Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Tue, 19 Jun 2018 01:46:45 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp415.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 6bc6c85800e2e07bda0056c1b5fc2a50; Tue, 19 Jun 2018 01:46:43 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: A head buildworld race visible in the ci.freebsd.org build history From: Mark Millard In-Reply-To: <07C8E943-BDED-4912-8856-0ECCED7014A3@yahoo.com> Date: Mon, 18 Jun 2018 18:46:41 -0700 Cc: Li-Wen Hsu , FreeBSD Current , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <74EAD684-0E0B-453A-B746-156777CF604A@yahoo.com> <1884103f-d1fb-aca6-2edd-062e11d05617@FreeBSD.org> <07C8E943-BDED-4912-8856-0ECCED7014A3@yahoo.com> To: Bryan Drewery X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 19 Jun 2018 01:46:52 -0000 On 2018-Jun-18, at 6:03 PM, Mark Millard wrote: > On 2018-Jun-18, at 4:08 PM, Bryan Drewery = wrote: >=20 >> On 6/18/2018 3:27 PM, Li-Wen Hsu wrote: >>> ranlib -D libpcap.a >>> ranlib: fatal: Failed to open 'libpcap.a' >>=20 >> Where is this error even coming from? It's not in the usr.bin/ar code >> and ranlib does not cause it. >>=20 >> # ranlib -D uh >> ranlib: warning: uh: no such file >=20 > A more complete sequence is (with some > other text mixed in, as in where I got > the text from on ci.freebsd.org): >=20 > --- libvgl.a --- > building static vgl library > ar -crD libvgl.a `NM=3D'nm' NMFLAGS=3D'' lorder main.o simple.o = bitmap.o text.o mouse.o keyboard.o | tsort -q`=20 > --- all_subdir_lib/libsysdecode --- > ranlib -D libsysdecode.a > --- all_subdir_lib/libvgl --- > ranlib -D libvgl.a > ranlib: fatal: Failed to open 'libvgl.a' > --- all_subdir_lib/libsysdecode --- > ranlib: fatal: Failed to open 'libsysdecode.a' > --- all_subdir_lib/libvgl --- > *** [libvgl.a] Error code 70 >=20 > So, in essence, >=20 > ar -crD libvgl.a `NM=3D'nm' NMFLAGS=3D'' lorder main.o simple.o = bitmap.o text.o mouse.o keyboard.o | tsort -q`=20 > ranlib -D libvgl.a > ranlib: fatal: Failed to open 'libvgl.a' >=20 > It is not obvious to me that the "Failed to open" means > that there was "no such file". Might there be some other > form of "Failed to open" for a file that does exist from > the ar at least having created its output .a file? >=20 Also, if what varies is the head system version (for failing vs. working) and what is the same is running a 11.1R jail, then it would seem to be the underlying head system software in each that matters for the ar -> ranlib sequence behavior, but not 11.1R's ar or ranlib or 11.1R's libraries indirectly involved --nor in head's ar or ranlib (or their indirections). head's: unused. The only parts of head that could be involved are parts that the 11.1R jail does not avoid. This suggests more basic infrastructure in head to me. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Tue Jun 19 05:44:46 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DD0F61021A89 for ; Tue, 19 Jun 2018 05:44:45 +0000 (UTC) (envelope-from lists@eitanadler.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 6E4AA6C131 for ; Tue, 19 Jun 2018 05:44:45 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mailman.ysv.freebsd.org (Postfix) id 283FA1021A86; Tue, 19 Jun 2018 05:44:45 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 15DA51021A84 for ; Tue, 19 Jun 2018 05:44:45 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::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 945DE6C12E for ; Tue, 19 Jun 2018 05:44:44 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yw0-x232.google.com with SMTP id r19-v6so6468413ywc.10 for ; Mon, 18 Jun 2018 22:44:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/Gu8mj7iAvWYJXrPQpMy6WE4jBtcm6EQAcCR74dWm2s=; b=F+3kUyu/DZqiZbPWzYgc4aD/ZPEpMUIM1mdmQQm0p07zdmqdVlppbIadM0c02ViVZb fkA0CJgahHk3b3CLZa0CrUBN9E5RXckjrt3DTaV8Kyqae6QoI83lLIBy7mwmPWWVmW57 /cCQukhVRq5/N48xGS5fdiQFUOjteU2pC145s= 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=/Gu8mj7iAvWYJXrPQpMy6WE4jBtcm6EQAcCR74dWm2s=; b=j4aqcNGrctwglgZQQRrGofocXti9P5vQkkok6BaFKbGmD1zlQzMIKXw9OJsmVGSHxo gGCEEFIIS9pv+IfYE+XPQDF8BcQlfssTlj7iaruNr/Qd2ZLh9rFCdjqDm/Ix1Dj1CBJc 7QYjC7Y+6m+JXIc17yUIUM2OaJh8gJL0Zb1IsLh7AqUXeQ40BQBNaCNy/63bSQ9KVpZx xGACxmZOlAz5hV4nGm0WkkyRWRLbiA9NIjK7CHhaTegrOdUINQDb7/uvAzVqVE70Zrr4 F2HsBy/FmB7XiM4vXFfaHANuHnXy+G9yN3RFYi1nl3phiYjT5KyvR5b5qLe+ouOhnUrP wliA== X-Gm-Message-State: APt69E2aezFExpIMaLlK+TFfO/tHF2bSwLniwS5jKeddH5q3L7caNu/7 DA1gDMON9V+FdzUYw4Eoo3CZJdCNhiMRKtJdDt0FYQ== X-Google-Smtp-Source: ADUXVKKOMXYLTREOh+SBFA/+DBVleJHqabFYFrfch5h1YgSiVacooM/pwgNDGRp2ZRcMsFRr8D4Co6Ide5YLwWRVMRc= X-Received: by 2002:a0d:cf01:: with SMTP id r1-v6mr7164640ywd.162.1529387083966; Mon, 18 Jun 2018 22:44:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:ef50:0:0:0:0:0 with HTTP; Mon, 18 Jun 2018 22:44:13 -0700 (PDT) In-Reply-To: References: <20180613103535.GP2493@kib.kiev.ua> From: Eitan Adler Date: Mon, 18 Jun 2018 22:44:13 -0700 Message-ID: Subject: Re: Ryzen public erratas To: Konstantin Belousov Cc: "current@freebsd.org" , amd64@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 19 Jun 2018 05:44:46 -0000 On 13 June 2018 at 04:16, Eitan Adler wrote: > On 13 June 2018 at 03:35, Konstantin Belousov wrote: >> Today I noted that AMD published the public errata document for Ryzens, >> https://developer.amd.com/wp-content/resources/55449_1.12.pdf >> >> Some of the issues listed there looks quite relevant to the potential >> hangs that some people still experience with the machines. I wrote >> a script which should apply the recommended workarounds to the erratas >> that I find interesting. >> >> To run it, kldload cpuctl, then apply the latest firmware update to your >> CPU, then run the following shell script. Comments indicate the errata >> number for the workarounds. >> >> Please report the results. If the script helps, I will code the kernel >> change to apply the workarounds. >> >> #!/bin/sh >> >> # Enable workarounds for erratas listed in >> # https://developer.amd.com/wp-content/resources/55449_1.12.pdf >> >> # 1057, 1109 >> sysctl machdep.idle_mwait=0 >> sysctl machdep.idle=hlt > > > Is this needed if it was previously machdep.idle: acpi ? This might explain why I've never seen the lockup issues mentioned by other people. What would cause my machine to differ from others? -- Eitan Adler From owner-freebsd-current@freebsd.org Tue Jun 19 09:28:46 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 25DB2100A167 for ; Tue, 19 Jun 2018 09:28:46 +0000 (UTC) (envelope-from alexvpetrov@gmail.com) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 7CEC575910 for ; Tue, 19 Jun 2018 09:28:45 +0000 (UTC) (envelope-from alexvpetrov@gmail.com) Received: by mail-lf0-x230.google.com with SMTP id v84-v6so5894077lfa.1 for ; Tue, 19 Jun 2018 02:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:openpgp:autocrypt:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=hPicuvng9ky+Wn5dF2Y9egMgO7SCYwcpRFG2RByjyRI=; b=hI+PQ5MjO8o8O0L99tMFJ6jOcEnPrmCEeg1AXT38ojM3TF2x4yeWcdyQFf2BhXv2C8 Q8ZUgjHxDOJK19O+4UKeL5O6KGrLhv28bMTdbJ/dcsnv5+u9QCEEDB8LG2hnh7WP84Df QBDaZkuzZDUzVt/3lA+cvf06jtaTJM5qBC9aL9bv/bkVj+01T8fLO7zHFKkEhiE8VQj7 YPXOYc3uqlnxYjibncnpmtInr0UoCeuTyiV6+rict4Abemr14m/nwqlVvy6julKhL1xw u/TWbg6okvX86zH8Vsvx51PlHSaECzRacpZOYcPARvmtcGFosTUVetbz+oRZ/Su8vm2q XMAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:openpgp:autocrypt:message-id :date:user-agent:mime-version:content-language :content-transfer-encoding; bh=hPicuvng9ky+Wn5dF2Y9egMgO7SCYwcpRFG2RByjyRI=; b=Z45SYEKaSa76JX1yBCN4cu46ggmcss+ZiEoj+7QVbvoey9jCCTIOg0JXUpumH4LhD2 ZEAw8vnrWM0owEI8foE18dDg3kCUEy2XJ/avj3Wf2DRErcF42uAGFhhKY8/0reOMjKG/ IDMWyIyk0lMsT8kuzlDCOUZUOu+gplMFWZqVksLBC577vpgb7mwBfTbNUwkl1iFRJWtt t1FAMqnfH0TdGXBX1rV52uaBrP6een/OeVFqCXszJJj7dElephmb6QnkqVamyv5Hl5uA Kgkth7nI0OMn33RLSX0FvwTsuaKPdB9DNT1ThX6zNW9LU0thTcWdMkEHGhKzj3qZLzS4 fdHg== X-Gm-Message-State: APt69E1dIHiDkcAWrxzE7MzueQoP2gEtG43gMRAPr7jGy45lerIqmO3A JW7yAaHkHBWutq7GxXwmO7C/UQ== X-Google-Smtp-Source: ADUXVKJ2BXAB2tG0QANCJnzLkkJFu6tvbTu5V4PWEUtXB04rs8deF6YIKH8pd9woww6HSxzhsLEuuQ== X-Received: by 2002:a19:6d0a:: with SMTP id i10-v6mr9370201lfc.103.1529400523767; Tue, 19 Jun 2018 02:28:43 -0700 (PDT) Received: from alex.super (stone.g-service.ru. [84.22.141.217]) by smtp.googlemail.com with ESMTPSA id 66-v6sm3188994lfy.53.2018.06.19.02.28.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jun 2018 02:28:42 -0700 (PDT) To: FreeBSD Current From: "Alex V. Petrov" Subject: top -m io Segmentation fault(core dumped) on fresh r335360 Openpgp: preference=signencrypt Autocrypt: addr=alexvpetrov@gmail.com; prefer-encrypt=mutual; keydata= xsFNBFr3oA0BEADMSXiVd/IwYhJPMQ6LXbZ7jTA/RXuzrGYaR++UENx5QJ6/HJ/3myTeMnZE nNa0Zme+oKw/9s5x7rBTP6mL5ta7VSYpnPX932mAjT9J4nS7iW/wWNBqcXn7wDCog2TV8Ww3 13SUP2YaKoJKJLxddiZD6AJrkafB9EE/AycMQ8XxMao1lVS+/KAo0yciOsnSlIJCWhF00b3j xDlHLvehrDa4S3EB13bF6uE0XU5nFfMNHtBav2mwD9t01hNioCNTV1hXwmsS/L1n5PR5FyJJ yYtjeohrAUiGKGJU9lJJ6tROBhzV/k3OsOGPyajFOVsW0vUueYfgw+IAPYdOZIAONgNdxkvs tRLQxYPCBMN1FvQ7GlIhq7ob+mxuA1imXx3xzlYy5tu4QzB383qZtLqQnZpysjYooAbHl+eN vB2ldvH9TZxm3fxxNL6zgYAXE/pNgFoqg/ILmhDwvvHzApHqVCKU3g6yii0KPxD7susaUWcL JYgrmt2BIE0RuiQRGWyS0L277D/YGmVnPNHxPi58DBs2iexDm7jw7PhlmfOw44N9w+O09D2S gqmBHySAtsq9Z5LoM81F+LrOoVmpYczZWErS917Gua1X7K3wrXoqQC8qcSiHZpEcBl/Uohii QWzjQJot5LT7rvfFHpnSOXAKgN7enVM7KxTJAYK1U343GGdepQARAQABzTZBbGV4VlBldHJv diAoZmlyc3QgZ2xvYmFsIGtleSkgPGFsZXh2cGV0cm92QGdtYWlsLmNvbT7CwY4EEwEIADgW IQRvKPTT2TJuh37ANx313p8aVpVkcAUCWvegDQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIX gAAKCRD13p8aVpVkcLLeEADClYAElEInGGjtLfH4jdjvTDaQTsrwT5/1E5/h8yxI4yn7hCt1 Dh+iCSUNLdPO88nZV2jP8bMQXFBKSbC0nAJXd8O+8t9AfSWoUC6IMzncxKTK/jZuJTCToCUR XZ+47+uJaBp51rpw3pFX8UrFlYSF6Dz97dI2cGHfx3xAOnowKxyHfthxS8waKWgbMOceds78 BP2+Q0iLCpoC9rO4KDc+w+h8z21eHIE9VHadTHpnKVF82voPH8XWvznTOCpYrdBwUtIyD/DV XRb0xcFsOSkvmReYX7u4QuOPLSc86sEWh4hXTFLAOdfeTjrDTDmBcmFpltmW1j+5t4mI1dK8 gptREM8gMJVJw3jjcO6jADeXX9q5C8/lX0sEGz9uC4oU5nkOMyfzd9Anb+9bCs7pMxhqAKjA 8tqJPPkmJU8WzMCs+uudIiQ8W9qIETwUJWxizQ3kvlzLfWRz5n93Y9kzSmjw81aiIJK/HFY8 wsW5zNo6JBn57cMPx8nBC4E2zM09ffmqSpjDwXfvZF2IIR8L4VTiKi3ovwLglJP+Qbs5HXNn 6K40cPNqfnHzPLwXwd/co04B/VVr+cKZuE58kYGty9Xs9q/SEpObDnxnLxMNHUNJJuRgOiti TKDkteHuKm6NA8v05o3TDQ5HU9szEoE5uoi/3pQ1ktfA/K3LkDwbotXL+87BTQRa96ANARAA w5+/xcaCP6iwsi2CFQ4pAWksdmPBEHA2VPn1ym3C6opjbyWUp6sn25eTWppdhA9rUqbM/zV/ hAFRT67oZJKBYNRaMoDdO8BsVZsg/u76QF/GuhbUjIk0tFFdpddMXl0zKAJJMCfDRxURRWv7 NW6sY/EZ4Dal5s4xOT+UrWGag3qoaIRdzw5bJRP+o75L90cE8pd7+Pd9cVJOOtTAwx0E4bPq dPSa6CPDSvzd9D3mw37dPzXysyQkQTy0OM7255E2wjYz3RbJxB3utybPVN3XJBD5EyA8IYeS ic1/03UrkRNv4XrLnlg7xLv96ZeCrf/BDNQW23iVwbISUAk4TXL7xs2TGYOmowZ89mMEcbfW ChX3YLAuAeWzgpMcrDC00izOxG0spkkrHL7/i1iSu2MKhv5qMTVgchlSktdd+KTba5keleHv ULQ3feGUKf9eTkKgES6q4rKrae0tIwByTLhhDVbkXqR6v8zrpJSscrvJ3tMNgquJKy5ATIUB nvUE2hMkSwtnJ2vQ/Z0zGt6c5KxI57/hsb148tXp1v3gAq9d6i8c8ChxSR/kUlqAvzl2QGcn CFVN6nfOzyNfBPZ61abNzkzjzyhOK4Gq4gQvx4QXhDp3jEME7rPM0Tqf0venb1Dp7SIHwggV yJglGApwoUvD4kKNIC7KDr+s/UjbBp4ExFMAEQEAAcLBdgQYAQgAIBYhBG8o9NPZMm6HfsA3 HfXenxpWlWRwBQJa96ANAhsMAAoJEPXenxpWlWRwAaEQAKm0imG5Fm37JZi+5faXJv/ZLZGl r4TVg4u1kMktdTQRrTXa3Qs0i3wTtOZe1p3xCCzPx+97iYETHragDTdAFUO+v+Llin26L1Zl z4huyIqgGSuTuekQfn6eoMZbcF+wzah4j/mvXQVpJBF2qQi1YdHSapWDlweuiuk01y8C3eHv 3qfFB/OJwXhwj0HKhkGkB2dLXuLtIk4GCXh4/g22tWz/SB0gsSXU7WhJFb0CyxETGR9YKxM8 CNl5tVRLqsBC6yQLvcAJgJci73PfMiHKnjxrz//+0xQO1TPeruWsd8nLYvziT38CyX42Mbaj 01WpvB0qOeTGtwGFmyyrnE8fYpd3CE0uAl9BnHqafAabl9+09x3wf+lEkkO2bK59akZz3BPU 8Lz2BAgskyS81WZCthQYUrUozFEx/31x8JJ95EQFNW9t8HBa51r4QhedSNKxLbT3Sx8hH0iq Z8wYkGw0og9U1DqgFzxE2HSGZSDG3I1DrPDqhcM/6Y0V98wS+XreuS88DYYck37+L7bTGiyZ WYFNZk1ChcIBk8hgKn5nFOCWO2rX06RI9zorzSpEg6lB2STae1Up5oEj8QqfYmfO3cp2Qhvj F3c2/i8KpWkJQkAgNrv428FIlx9SiPu9gvNTTYuLIOdZLQvInTmKs2uCoB6JDAW75axDhBbR FvM3Vpv/ Message-ID: Date: Tue, 19 Jun 2018 16:28:41 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 19 Jun 2018 09:28:46 -0000 top -m io Segmentation fault(core dumped) FreeBSD alex.super 12.0-CURRENT FreeBSD 12.0-CURRENT #11 r335360: Tue Jun 19 14:53:20 +07 2018 alex@alex.super:/usr/obj/usr/src/amd64.amd64/sys/IOSCHED amd64 -- ----- Alex. From owner-freebsd-current@freebsd.org Tue Jun 19 09:50:39 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C0CF8100B8A3 for ; Tue, 19 Jun 2018 09:50:38 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 5465E76C7B for ; Tue, 19 Jun 2018 09:50:38 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 13920100B89D; Tue, 19 Jun 2018 09:50:38 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CABBA100B899; Tue, 19 Jun 2018 09:50:37 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::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 43B3476C72; Tue, 19 Jun 2018 09:50:37 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr0-x235.google.com with SMTP id k16-v6so19853487wro.0; Tue, 19 Jun 2018 02:50:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=0Wp5VQsuPD7xbwaRE3E/GHIynVmYv6qJosAEgIvbcDY=; b=ADMhe9e/7BDZHBiWI2My4cG8Vx3Ya/nMCyaSzmWlJgesDDHUFmImqpxo01RXg1VN5t cp//KruysAIzRi7iveb+9wv6s717YQ+oO9nL4XOX55lTv2YEfxcUm0IrMo8M3dDwqEVH 2PZ4YbswgxD7y2zZaYjE62isxiE7jFn/s3c1RLnrrXu8D4y4OV79qh8Xea7dAKJU0khp inzuBdbXnFC78bPwPUjZu3AsU3Lhbvp8HkSvbTHuvtWYMLfOuYy5Q1yoHpMfZkZdBQe1 1GSBYp/zD9A4QxImVkRtPeenuplGsJ38x4xv4rUbyReIheezE+LhkvDFh//qVyMdbQI/ Q9fA== 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:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=0Wp5VQsuPD7xbwaRE3E/GHIynVmYv6qJosAEgIvbcDY=; b=F0Svl5GFQLh6fV/FxUVuKwWApEFvjVCY+N+LHSmUN82txVqEXfh7X2XiQOrKsF+3Wl 2+1x0EZBn+6t4fLaKJzoPkwYfwJ+ji55Q4bcskW+UFrFRktfbwqfBvtzNLsKjhMuwZp+ qWUoaM4ptfQn2ZehfRUfG+BaU4BHkBdi7wt/V1fZTKn9ykuVhH8VepMp5KCFeoJcKIIL 8OMU5bvMCht/byrKdQyrTzyMuHsyzTDGsVVvclvx0tMNhWuSncrYPnDlQKrLM6nRc5Aa GtAnbLMy3KVEyQHHJSY8stwXNGcgvBUp+VJ9eRZHj9qaZY0sp+K47kYTF/rTMS9G0rMQ WeTQ== X-Gm-Message-State: APt69E3YCKVhlMfIae+2PDDjJqEi+OZY7l5VExTRpgJ2RBNmpKbNrFRl WK15y/9aksks4sf/aabuEnvmSw== X-Google-Smtp-Source: ADUXVKJubZ0H6mPZH4uzjeW7DGvNVedZfkJHoVgDeTlMu32MmCW2MViAS3EPT+s1riXxSjoSRfiu+w== X-Received: by 2002:a5d:4049:: with SMTP id w9-v6mr13829408wrp.96.1529401836319; Tue, 19 Jun 2018 02:50:36 -0700 (PDT) Received: from ernst.home (p5B02381D.dip0.t-ipconnect.de. [91.2.56.29]) by smtp.gmail.com with ESMTPSA id b80-v6sm11902855wmf.2.2018.06.19.02.50.34 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 19 Jun 2018 02:50:35 -0700 (PDT) Date: Tue, 19 Jun 2018 11:50:30 +0200 From: Gary Jennejohn To: Eitan Adler Cc: Konstantin Belousov , amd64@freebsd.org, "current@freebsd.org" Subject: Re: Ryzen public erratas Message-ID: <20180619115030.5491af33@ernst.home> In-Reply-To: References: <20180613103535.GP2493@kib.kiev.ua> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.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.26 Precedence: 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, 19 Jun 2018 09:50:39 -0000 On Mon, 18 Jun 2018 22:44:13 -0700 Eitan Adler wrote: > On 13 June 2018 at 04:16, Eitan Adler wrote: > > On 13 June 2018 at 03:35, Konstantin Belousov wrote: > >> Today I noted that AMD published the public errata document for Ryzens, > >> https://developer.amd.com/wp-content/resources/55449_1.12.pdf > >> > >> Some of the issues listed there looks quite relevant to the potential > >> hangs that some people still experience with the machines. I wrote > >> a script which should apply the recommended workarounds to the erratas > >> that I find interesting. > >> > >> To run it, kldload cpuctl, then apply the latest firmware update to your > >> CPU, then run the following shell script. Comments indicate the errata > >> number for the workarounds. > >> > >> Please report the results. If the script helps, I will code the kernel > >> change to apply the workarounds. > >> > >> #!/bin/sh > >> > >> # Enable workarounds for erratas listed in > >> # https://developer.amd.com/wp-content/resources/55449_1.12.pdf > >> > >> # 1057, 1109 > >> sysctl machdep.idle_mwait=0 > >> sysctl machdep.idle=hlt > > > > > > Is this needed if it was previously machdep.idle: acpi ? > > This might explain why I've never seen the lockup issues mentioned by > other people. What would cause my machine to differ from others? > I had sysctl machdep.idle_mwait=1 and machdep.idle=acpi before applying the shell script. I had multiple lockups every week, sometimes multiple lockups per day. With the idle settings from the script it still locks up, but not as often. I suspect I also need to update the CPU firmware, although I expect that the new BIOS version I installed last week would have done that already. -- Gary Jennejohn From owner-freebsd-current@freebsd.org Tue Jun 19 11:03:45 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4ECC41010B52; Tue, 19 Jun 2018 11:03:45 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660066.outbound.protection.outlook.com [40.107.66.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT TLS CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CB2377A094; Tue, 19 Jun 2018 11:03:44 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM (52.132.44.24) by YTOPR0101MB0956.CANPRD01.PROD.OUTLOOK.COM (52.132.44.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.17; Tue, 19 Jun 2018 11:03:43 +0000 Received: from YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM ([fe80::d0eb:3783:7c99:2802]) by YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM ([fe80::d0eb:3783:7c99:2802%3]) with mapi id 15.20.0863.016; Tue, 19 Jun 2018 11:03:43 +0000 From: Rick Macklem To: Don Lewis CC: "rc@freebsd.org" , "freebsd-current@freebsd.org" Subject: Re: review of nfsd rc.d script patch Thread-Topic: review of nfsd rc.d script patch Thread-Index: AQHUBOpJU2qX1eyBDUe5qiTFuEQ6AqRmwZYAgACsYVw= Date: Tue, 19 Jun 2018 11:03:43 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB0956; 7:BcegBTxTG1KlthW113f2BQrsVxxfQWvxiZjY+JxYMQnHK1ezWigWkuuk/Ko1fGnhc/TgtgX7wJCB2+hovvQ93z5x9ZkYowCBoTkOo89YTLuJhm2WRNR0N9MvrGMA+qTzrdvmBcLNxTEaQF4C0w2Utv/lktAhFSA6Q/tefOIcO3ZD36bYYdnBYK09ukIMsNqGyLB9zfa7y+zpPliGCBOeDqb5YR1A4+XOVjIwOcDyocZflKx6JHxZO6l7e9ZfUHt7 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: d8a406b1-7e83-4067-40ca-08d5d5d4525c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:YTOPR0101MB0956; x-ms-traffictypediagnostic: YTOPR0101MB0956: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231254)(944501410)(52105095)(10201501046)(3002001)(149027)(150027)(6041310)(20161123562045)(20161123558120)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:YTOPR0101MB0956; BCL:0; PCL:0; RULEID:; SRVR:YTOPR0101MB0956; x-forefront-prvs: 07083FF734 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(366004)(346002)(39380400002)(376002)(199004)(189003)(51444003)(478600001)(2900100001)(5660300001)(33656002)(14454004)(54906003)(81156014)(6916009)(76176011)(102836004)(186003)(486006)(81166006)(59450400001)(6506007)(68736007)(26005)(7696005)(86362001)(8936002)(476003)(8676002)(74316002)(25786009)(3280700002)(6436002)(4326008)(450100002)(446003)(2906002)(53936002)(11346002)(305945005)(3660700001)(9686003)(97736004)(99286004)(55016002)(786003)(106356001)(74482002)(6246003)(105586002)(5250100002)(316002)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB0956; H:YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-microsoft-antispam-message-info: FifB1xIcovfL721ZXXVkagdhRW9lzgbL60QaNp5I86CyknGycg293piQvI1yjFb8PFX00NXii4u/vxmE/O97xUTg9FwRfk8Gr/QvyFbea6Y6nsUruRwQkcyzN5aS0Jv1AkQj84AGO4eUycYwvEgK3OORldQmGmprKzrAsoF6VbdHm0mReibQ2VpnuYJEWVVpguqx8ja1EK1ZXktMT42a3+ggfcAz3SzwLc0hgmyygaUP+hxA6d/TX0npNcbQLcHmpkGvWR+vvHWthIueSEp/KlbIQCKDFYlQp3M7cdBf4j5GJ4Xy85vcLhnRxo4z3oDx 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-Network-Message-Id: d8a406b1-7e83-4067-40ca-08d5d5d4525c X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2018 11:03:43.3572 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB0956 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 19 Jun 2018 11:03:45 -0000 Don Lewis wrote: >On 15 Jun, Rick Macklem wrote: >> Hi, >> >> For the pNFS service MDS machine, the nfsd can't be started until all nf= s mounts >> in /etc/fstab are done. >> I think that adding "mountcritremote" to the "# REQUIRE:" line is suffic= ient to do this? >> >> I don't think delaying the startup of the nfsd daemon until after any NF= S mounts >> are done will do any harm, but if others think it would be a POLA violat= ion, >> I could make this dependent on the pNFS service being enabled. >> Does anyone think this would cause a POLA violation? > >Sounds like that would break cross mounts. Back in the olden days >before the automounter, I would set up workstation clusters with hosta >exporting local filesystem /home/hosta, and hostb exporting /home/hostb. >In addition, hosta would do a bg NFS mount of /home/hostb and hostb >would do a bg NFS mount of /home/hosta. That way everybody would have a >consistent view of everything. If a power failure took down everything, >the first system up would export its local filesystem and even though it >wouldn't be able to mount any remote filesystems, mount would background >itself at the boot would complete. As the remaining machines came up, >they would be able to mount the remote filesystems of the machine that >came up earlier, and the early machines would mount the filesystems from >the later machines as they became available. > >If nfsd is delayed until all the NFS filesystems are mounted, the above >setup would deadlock. I think you would have used the "bg" mount option on the NFS mounts to get the above to work? (That is what makes the mount go "background" if it can'= t contact the NFS server.) If so, this would still behave the same after this patch. The patch forces "mountcritremote" to complete before nfsd is run (to be ho= nest, since "m" comes before "n", I think that happens anyhow? This patch just tr= ies to ensure that). It does not force waiting for mount completion if "bg" is specified. (Put another way, "bg" can't be used for mounts of DSs for the pNFS server = setup.) rick ps: I recall a small company that only had a few SGI workstations and did a= setup like the above. However, they weren't very good at configuring it and= , as such, everyone would run around for a half hour after a power failure, tryi= ng to get the workstations back up;-) From owner-freebsd-current@freebsd.org Tue Jun 19 11:11:10 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F132B1011326 for ; Tue, 19 Jun 2018 11:11:09 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670049.outbound.protection.outlook.com [40.107.67.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT TLS CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 82E157A5C0; Tue, 19 Jun 2018 11:11:09 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM (52.132.44.24) by YTOPR0101MB0794.CANPRD01.PROD.OUTLOOK.COM (52.132.47.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.17; Tue, 19 Jun 2018 11:11:08 +0000 Received: from YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM ([fe80::d0eb:3783:7c99:2802]) by YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM ([fe80::d0eb:3783:7c99:2802%3]) with mapi id 15.20.0863.016; Tue, 19 Jun 2018 11:11:08 +0000 From: Rick Macklem To: Steve Wills , "freebsd-current@freebsd.org" CC: "andreas.nagy@frequentis.com" Subject: Re: ESXi NFSv4.1 client id is nasty Thread-Topic: ESXi NFSv4.1 client id is nasty Thread-Index: AQHUBjX1G4uSBXqIhUeci7+GbxFK06RmiCEAgAAFxoiAAAO4AIAA3Phc Date: Tue, 19 Jun 2018 11:11:08 +0000 Message-ID: References: , <8ceea008-f827-580b-8ca6-4a5fcb028e83@FreeBSD.org> In-Reply-To: <8ceea008-f827-580b-8ca6-4a5fcb028e83@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB0794; 7:NqNyJfk8jzRqhcvGDeLHsLul+xBTvUj862D9mlMHpOJ0aT2GXkssifebXcpCVjw4WbZPE4Ml8qtmLkDV/KCwPD3hR9Ldt1/fvDFBk/V3k3QUuozT7zXzfXugQ7C+a3ue+z/eHvKWjnefmfefdTbbE7sCo9P/lC7ltjP2DNULBo5mE86wdo/9uPYEtfMwQcAWwqqIS/9FZNphtfqKktg4NiQaIshgbTyHOa3E+QAAjzXCvaQ1cBrZBxR0L+2xswXJ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 050eb44b-a3e3-483c-296b-08d5d5d55bc5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:YTOPR0101MB0794; x-ms-traffictypediagnostic: YTOPR0101MB0794: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231254)(944501410)(52105095)(3002001)(10201501046)(149027)(150027)(6041310)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:YTOPR0101MB0794; BCL:0; PCL:0; RULEID:; SRVR:YTOPR0101MB0794; x-forefront-prvs: 07083FF734 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(346002)(39860400002)(39380400002)(396003)(189003)(199004)(102836004)(26005)(7696005)(476003)(186003)(76176011)(99286004)(105586002)(3280700002)(106356001)(3660700001)(2900100001)(478600001)(59450400001)(53546011)(6506007)(2906002)(5660300001)(2501003)(11346002)(486006)(86362001)(5250100002)(446003)(33656002)(74316002)(53936002)(316002)(55016002)(786003)(4326008)(74482002)(6436002)(97736004)(229853002)(9686003)(25786009)(81166006)(14454004)(8936002)(81156014)(68736007)(6246003)(93886005)(8676002)(110136005)(305945005)(12363001); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB0794; H:YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-microsoft-antispam-message-info: T4vGA4ieJHlfBxf9gsAgi/m9hhL/fn79xMxdkdJWV66pxqdcydfLJSjeMVNe1Emkf+SWPPS97LsAZ2k2VQjEwD0uO59NInMAvMgZcJzGWcrkbNo/au56fRM5oeso7N1aLOFX6X8dLTQBPdbE4E2pDQUcT989UIzx8D5ByAxPCY3cgjWyjmMI25EZ5p18KK6v70PI/J0TTfUDaLV8zxbRbaHH2MhMSHoUZRW52hJbWne1MEAa5AyGTFfeZJcmFBk3xDeFqU18Zg8/KmIj4ZDxRsk2d6/nq4wRo5wpKDKphHbj0npVffYqyQO4SmIFBG7UcT3uilwERaL/IzkOKccydw== 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-Network-Message-Id: 050eb44b-a3e3-483c-296b-08d5d5d55bc5 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2018 11:11:08.6722 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB0794 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 19 Jun 2018 11:11:10 -0000 Steve Wills wrote: On 06/18/18 17:42, Rick Macklem wrote: >> Steve Wills wrote: >>> Would it be possible or reasonable to use the client ID to log a messag= e >>> telling the admin to enable a sysctl to enable the hacks? >> Yes. However, this client implementation id is only seen by the server >> when the client makes a mount attempt. >> >> I suppose it could log the message and fail the mount, if the "hack" sys= ctl isn't >> set? > >I hadn't thought of failing the mount, just defaulting not enabling the >hacks unless the admin chooses to enable them. But at the same time >being proactive about telling the admin to enable them. > >I.E. keep the implementation RFC compliant since we wouldn't be changing >the behavior based on the implementation ID, only based upon the admin >setting the sysctl, which we told them to do based on the implementation I= D. Well, without one of the hacks (as head currently is) the mounts always fai= l, so ESXi mounts failing is a feature of the "unhacked" server. (The ReclaimComplete failure fails the mount.) >Just an idea, maybe Warner's suggestion is a better one. Yes, I think Warner has the right idea, although logging a message w.r.t. t= he ReclaimComplete failure (which fails these mounts) when the hacks are turne= d off sounds like a good one to me. >Steve rick From owner-freebsd-current@freebsd.org Tue Jun 19 14:16:18 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1EB97101C68F for ; Tue, 19 Jun 2018 14:16:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A2C9682CEB for ; Tue, 19 Jun 2018 14:16:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x233.google.com with SMTP id r24-v6so340739ioh.9 for ; Tue, 19 Jun 2018 07:16:17 -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=sM4Uwm1hRnuBXsAU0HJhsQ/8FONnRw2Fo5pTCtMqdLE=; b=IhXaUoj1rDt1KH6j7X6nlB3agsoOFid9LFqfVf3VAK32CAYTMizn9sCnRHbg5iGU9t vaHozs89qPcFuAuOiF/bV66td5Cb1+R2VrmiTv4OmrfUQSCCEOhKccjFfLCHx3jrU54I Nq8aSvhujOLKi5xauT9n0IjBAVRS2l9ou0uKGje8s3PWOfLAkjwBV4enPc9T/nRpzlo7 3H/NVwMoms6DFeEYEp89eoqfHquT1xZRF+Gh7q4MDEZtx+1imlIxD7Y353+Pmi4DoWnG k0F18NoGSzZc0ene5uDDqyztQdSAzuLZButZ1GAaF6SlwschImQIP+0IEjgZCDxQ1nRa K4gA== 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=sM4Uwm1hRnuBXsAU0HJhsQ/8FONnRw2Fo5pTCtMqdLE=; b=fFryu6+ZknCpGiLt1MHeQ0V9J7RFwuEo5auL86E0K1//cqV6QZN3lKP0K/i/Ak9Ymd 7weab3EDeA3P80sssdpZyCaAJ9OslBuHIAo6nRaIZZic4t0BqDnE7YTRNuMRoNrDOl5n 1nlTmlVwf6TxesfO+XGamAhyJRLEOd0YPDEizaNkjdJv5o5a7iqHDyj4wFpmEXTgGoW/ +mnSDgLyDIGbjoJzgl00bX/Vg9O9Y9SmI/KVpHM/bEyfb/HryXARAKaZ1Eh/AiYg5LDX g8mJkOg3DjA1rIywc2k5Sjj5Pz15uoaPiTZqP94wRWEVSchZRpghWtfJBUqBHNdSu7eC AzFQ== X-Gm-Message-State: APt69E1YCnxIJk5YyIUeJnZHjiHAXXHdD1fhDaboSTBzym4tlyMruqn9 mKu/0EkRaKtVgCwZjX2Y1TuiigWsjK7gECfyML08bQ== X-Google-Smtp-Source: ADUXVKIpiPuTKu1rImXq8Ncb64T8jZbvNirw9DEW1JnKiKh0KOR4tAGmysdxbi2S/LYqa2E9il+m5Db8OawaRXM/EUo= X-Received: by 2002:a6b:29c4:: with SMTP id p187-v6mr13338590iop.299.1529417772292; Tue, 19 Jun 2018 07:16:12 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:5945:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 07:16:11 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <8ceea008-f827-580b-8ca6-4a5fcb028e83@FreeBSD.org> From: Warner Losh Date: Tue, 19 Jun 2018 08:16:11 -0600 X-Google-Sender-Auth: ZzphlDE9jnPoE3D0qw48FbRga30 Message-ID: Subject: Re: ESXi NFSv4.1 client id is nasty To: Rick Macklem Cc: Steve Wills , "freebsd-current@freebsd.org" , "andreas.nagy@frequentis.com" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 19 Jun 2018 14:16:18 -0000 On Tue, Jun 19, 2018 at 5:11 AM, Rick Macklem wrote: > Steve Wills wrote: > On 06/18/18 17:42, Rick Macklem wrote: > >> Steve Wills wrote: > >>> Would it be possible or reasonable to use the client ID to log a > message > >>> telling the admin to enable a sysctl to enable the hacks? > >> Yes. However, this client implementation id is only seen by the server > >> when the client makes a mount attempt. > >> > >> I suppose it could log the message and fail the mount, if the "hack" > sysctl isn't > >> set? > > > >I hadn't thought of failing the mount, just defaulting not enabling the > >hacks unless the admin chooses to enable them. But at the same time > >being proactive about telling the admin to enable them. > > > >I.E. keep the implementation RFC compliant since we wouldn't be changing > >the behavior based on the implementation ID, only based upon the admin > >setting the sysctl, which we told them to do based on the implementation > ID. > Well, without one of the hacks (as head currently is) the mounts always > fail, > so ESXi mounts failing is a feature of the "unhacked" server. > (The ReclaimComplete failure fails the mount.) > > >Just an idea, maybe Warner's suggestion is a better one. > Yes, I think Warner has the right idea, although logging a message w.r.t. > the > ReclaimComplete failure (which fails these mounts) when the hacks are > turned > off sounds like a good one to me. > I think so too, rate limited, with an invitation to turn on the hack :) Warner From owner-freebsd-current@freebsd.org Tue Jun 19 15:03:14 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 58AE1101FC9F; Tue, 19 Jun 2018 15:03:14 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: from mail-wr0-f177.google.com (mail-wr0-f177.google.com [209.85.128.177]) (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 CD3D485794; Tue, 19 Jun 2018 15:03:13 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: by mail-wr0-f177.google.com with SMTP id e18-v6so3143wrs.5; Tue, 19 Jun 2018 08:03:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=k/th35f+caUUwBmaTWgPyYAHrZsJO/o3IlLbG/1Zs7s=; b=uFTdvZrYxfc267/IRK8efP7IXab/E4XZaU7gvK8mj8cxhGPRvtXuM8l7AOFVjJ8UcF R4igVYST5f60jzhdE+RW70FyKM33Fcj+7VseOOVTbJtodC9Mdk6w1P9uQpC0X1A8fepa vy5Fmey14FNXl/NcI+KhgXYtN08tjFfFOER55ZBhSFku5dn1gs7Cv2BMYMd1m63O/VUO UTbIFpeTt24KTk2T4U0TFdcOqAWCNevjVdgpHuTKGb8J3uYgxv6PAT80unvEv9LhQ2A1 knqlHJcJbJj5bqjPWmF7jFODcCsSyDIgxkJbbReBMqCuVqFZGu0cX8NZFgNSQqFhINnQ pqWw== X-Gm-Message-State: APt69E0SlZSiqYJbrX06Cnbozqrbb4S+ngE2IqVAU1cFyOLDhUkLKU+c N6S7+E9JeF1yKZVY3d6+W6r9TCS/g6ExZr/zi6FJKIC5 X-Google-Smtp-Source: ADUXVKLxMV/rJTXBkYVmY/KjaLDob8H+WS/tv140USzFKYIL2BiwHxLcN7ou90JjsxWyG+E/OTCamJ2QCQXJZfjE9UA= X-Received: by 2002:adf:f712:: with SMTP id r18-v6mr15528681wrp.85.1529420586517; Tue, 19 Jun 2018 08:03:06 -0700 (PDT) MIME-Version: 1.0 References: <74EAD684-0E0B-453A-B746-156777CF604A@yahoo.com> <1884103f-d1fb-aca6-2edd-062e11d05617@FreeBSD.org> <33a43aac-231f-6158-1de4-f5dbfaf195df@FreeBSD.org> In-Reply-To: From: Li-Wen Hsu Date: Tue, 19 Jun 2018 11:02:54 -0400 Message-ID: Subject: Re: A head buildworld race visible in the ci.freebsd.org build history To: Ed Maste Cc: Bryan Drewery , Mark Millard , FreeBSD Current , FreeBSD Toolchain Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 19 Jun 2018 15:03:14 -0000 On Mon, Jun 18, 2018 at 8:36 PM Ed Maste wrote: > Li-Wen reported that the build is done in a 11.1-rel jail though, so > the libarchive (or any userland) change shouldn't be responsible. > > Can we update a canary builder to somewhere between r328278 and r333388? butler1.nyi.freebsd.org is running r331373 now. -- Li-Wen Hsu https://lwhsu.org From owner-freebsd-current@freebsd.org Tue Jun 19 16:09:40 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4F6031023BC7 for ; Tue, 19 Jun 2018 16:09:40 +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 E02F66880B for ; Tue, 19 Jun 2018 16:09:39 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 089CB1E9F1 for ; Tue, 19 Jun 2018 16:09:33 +0000 (UTC) To: freebsd-current@freebsd.org References: <61aeea9a-bb8b-65d0-1ffb-f8fb7b2f121d@acm.org> From: Allan Jude Openpgp: preference=signencrypt Autocrypt: addr=allanjude@freebsd.org; prefer-encrypt=mutual; keydata= xsFNBFVwZcYBEADwrZDH0xe0ZVjc9ORCc6PcBLwS/RTXA6NkvpD6ea02pZ8lPOVgteuuugFc D34LdDbiWr+479vfrKBh+Y38GL0oZ0/13j10tIlDMHSa5BU0y6ACtnhupFvVlQ57+XaJAb/q 7qkfSiuxVwQ3FY3PL3cl1RrIP5eGHLA9hu4eVbu+FOX/q/XVKz49HaeIaxzo2Q54572VzIo6 C28McX9m65UL5fXMUGJDDLCItLmehZlHsQQ+uBxvODLFpVV2lUgDR/0rDa0B9zHZX8jY8qQ7 ZdCSy7CwClXI054CkXZCaBzgxYh/CotdI8ezmaw7NLs5vWNTxaDEFXaFMQtMVhvqQBpHkfOD 7rjjOmFw00nJL4FuPE5Yut0CPyx8vLjVmNJSt/Y8WxxmhutsqJYFgYfWl/vaWkrFLur/Zcmz IklwLw35HLsCZytCN5A3rGKdRbQjD6QPXOTJu0JPrJF6t2xFkWAT7oxnSV0ELhl2g+JfMMz2 Z1PDmS3NRnyEdqEm7NoRGXJJ7bgxDbN+9SXTyOletqGNXj/bSrBvhvZ0RQrzdHAPwQUfVSU2 qBhQEi2apSZstgVNMan0GUPqCdbE2zpysg+zT7Yhvf9EUQbzPL4LpdK1llT9fZbrdMzEXvEF oSvwJFdV3sqKmZc7b+E3PuxK6GTsKqaukd/3Cj8aLHG1T1im1QARAQABzSJBbGxhbiBKdWRl IDxhbGxhbmp1ZGVAZnJlZWJzZC5vcmc+wsF/BBMBAgApBQJVcGXGAhsjBQkSzAMABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AACgkQGZU1PhKYC34Muw/+JOKpSfhhysWFYiRXynGRDe07 Z6pVsn7DzrPUMRNZfHu8Uujmmy3p2nx9FelIY9yjd2UKHhug+whM54MiIFs90eCRVa4XEsPR 4FFAm0DAWrrb7qhZFcE/GhHdRWpZ341WAElWf6Puj2devtRjfYbikvj5+1V1QmDbju7cEw5D mEET44pTuD2VMRJpu2yZZzkM0i+wKFuPxlhqreufA1VNkZXI/rIfkYWK+nkXd9Efw3YdCyCQ zUgTUCb88ttSqcyhik/li1CDbXBpkzDCKI6I/8fAb7jjOC9LAtrZJrdgONywcVFoyK9ZN7EN AVA+xvYCmuYhR/3zHWH1g4hAm1v1+gIsufhajhfo8/wY1SetlzPaYkSkVQLqD8T6zZyhf+AN bC7ci44UsiKGAplB3phAXrtSPUEqM86kbnHg3fSx37kWKUiYNOnx4AC2VXvEiKsOBlpyt3dw WQbOtOYM+vkfbBwDtoGOOPYAKxc4LOIt9r+J8aD+gTooi9Eo5tvphATf9WkCpl9+aaGbSixB tUpvQMRnSMqTqq4Z7DeiG6VMRQIjsXDSLJEUqcfhnLFo0Ko/RiaHd5xyAQ4DhQ9QpkyQjjNf /3f/dYG7JAtoD30txaQ5V8uHrz210/77DRRX+HJjEj6xCxWUGvQgvEZf5XXyxeePvqZ+zQyT DX61bYw6w6bOwU0EVXBlxgEQAMy7YVnCCLN4oAOBVLZ5nUbVPvpUhsdA94/0/P+uqCIh28Cz ar56OCX0X19N/nAWecxL4H32zFbIRyDB2V/MEh4p9Qvyu/j4i1r3Ex5GhOT2hnit43Ng46z5 29Es4TijrHJP4/l/rB2VOqMKBS7Cq8zk1cWqaI9XZ59imxDNjtLLPPM+zQ1yE3OAMb475QwN UgWxTMw8rkA7CEaqeIn4sqpTSD5C7kT1Bh26+rbgJDZ77D6Uv1LaCZZOaW52okW3bFbdozV8 yM2u+xz2Qs8bHz67p+s+BlygryiOyYytpkiK6Iy4N7FTolyj5EIwCuqzfk0SaRHeOKX2ZRjC qatkgoD/t13PNT38V9tw3qZVOJDS0W6WM8VSg+F+bkM9LgJ8CmKV+Hj0k3pfGfYPOZJ/v18i +SmZmL/Uw2RghnwDWGAsPCKu4uZR777iw7n9Io6Vfxndw2dcS0e9klvFYoaGS6H2F13Asygr WBzFNGFQscN4mUW+ZYBzpTOcHkdT7w8WS55BmXYLna+dYer9/HaAuUrONjujukN4SPS1fMJ2 /CS/idAUKyyVVX5vozoNK2JVC1h1zUAVsdnmhEzNPsvBoqcVNfyqBFROEVLIPwq+lQMGNVjH ekLTKRWf59MEhUC2ztjSKkGmwdg73d6xSXMuq45EgIJV2wPvOgWQonoHH/kxABEBAAHCwWUE GAECAA8FAlVwZcYCGwwFCRLMAwAACgkQGZU1PhKYC34w5A//YViBtZyDV5O+SJT9FFO3lb9x Zdxf0trA3ooCt7gdBkdnBM6T5EmjgVZ3KYYyFfwXZVkteuCCycMF/zVw5eE9FL1+zz9gg663 nY9q2F77TZTKXVWOLlOV2bY+xaK94U4ytogOGhh9b4UnQ/Ct3+6aviCF78Go608BXbmF/GVT 7uhddemk7ItxM1gE5Hscx3saxGKlayaOsdPKeGTVJCDEtHDuOc7/+jGh5Zxpk/Hpi+DUt1ot 8e6hPYLIQa4uVx4f1xxxV858PQ7QysSLr9pTV7FAQ18JclCaMc7JWIa3homZQL/MNKOfST0S 2e+msuRwQo7AnnfFKBUtb02KwpA4GhWryhkjUh/kbVc1wmGxaU3DgXYQ5GV5+Zf4kk/wqr/7 KG0dkTz6NLCVLyDlmAzuFhf66DJ3zzz4yIo3pbDYi3HB/BwJXVSKB3Ko0oUo+6/qMrOIS02L s++QE/z7K12CCcs7WwOjfCYHK7VtE0Sr/PfybBdTbuDncOuAyAIeIKxdI2nmQHzl035hhvQX s4CSghsP319jAOQiIolCeSbTMD4QWMK8RL/Pe1FI1jC3Nw9s+jq8Dudtbcj2UwAP/STUEbJ9 5rznzuuhPjE0e++EU/RpWmcaIMK/z1zZDMN+ce2v1qzgV936ZhJ3iaVzyqbEE81gDxg3P+IM kiYh4ZtPB4Q= Subject: Re: Current @ r335314 not bootable with Geli and ZFS Message-ID: <3eac8c14-da21-5666-c060-d8a551b3ca49@freebsd.org> Date: Tue, 19 Jun 2018 12:09:32 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <61aeea9a-bb8b-65d0-1ffb-f8fb7b2f121d@acm.org> 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.26 Precedence: 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, 19 Jun 2018 16:09:40 -0000 On 2018-06-18 12:42, Thomas Laus wrote: > Something changed in /boot/gptzfsboot between r334610 and r335314. I > built current this morning and my system is un-bootable. I am using > redundant ZFS disks and only copied the updated /boot/gptzfsboot file to > my ada0 drive. I was able to boot the ada1 drive that still had the > gptzfsboot file from r334610. > > I had a similar issue a few months ago with the upgrades to the Geli + > ZFS booting process. These were resolved and operation has been fine > since the last 'hick-up' in the testing process. I might not be the > only person running the combination of Geli encryption and using a ZFS > filesystem, but it should not be that much uncommon setup that I am the > first to report the problem. > > Let me know far back I need to revert my sources to identify the commit > that broke gptzfsboot. My system goes into a continuous reboot loop > before presenting the password prompt. It is very early in the startup > process. > > Tom > We tested all of the changes with the setup in tools/boot/rootgen.sh, it will be interesting to figure out what went wrong with your setup, and add it as a test case to prevent this in the future. The recent changes are: r335245 (reading the size of the disk) r335254 (reading past the end of the disk) r335276 (enable the serial console sooner so the password prompt can be used over serial) There is also one outstanding fix: https://reviews.freebsd.org/D15847 -- Allan Jude From owner-freebsd-current@freebsd.org Tue Jun 19 18:23:08 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 700851006153 for ; Tue, 19 Jun 2018 18:23:08 +0000 (UTC) (envelope-from lausts@acm.org) Received: from cdptpa-cmomta03.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E0E326F537; Tue, 19 Jun 2018 18:23:07 +0000 (UTC) (envelope-from lausts@acm.org) Received: from mail.laus.org ([65.29.112.189]) by cmsmtp with ESMTP id VLKsfBVxEB3KIVLL4fb6TN; Tue, 19 Jun 2018 18:26:59 +0000 Received: from [192.168.1.100] (presario [192.168.1.100]) by mail.laus.org (8.15.2/8.15.2) with ESMTPS id w5JIMXc6059071 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 19 Jun 2018 14:22:33 -0400 (EDT) (envelope-from lausts@acm.org) X-Authentication-Warning: mail.laus.org: Host presario [192.168.1.100] claimed to be [192.168.1.100] Reply-To: lausts@acm.org Subject: Re: Current @ r335314 not bootable with Geli and ZFS To: Allan Jude , FreeBSD Current References: <61aeea9a-bb8b-65d0-1ffb-f8fb7b2f121d@acm.org> <3eac8c14-da21-5666-c060-d8a551b3ca49@freebsd.org> From: Thomas Laus Openpgp: preference=signencrypt Autocrypt: addr=lausts@acm.org; prefer-encrypt=mutual; keydata= xsDiBDx1NWwRBADARalI5I8kGeBYYYWnZB73T1fU4333yCuRokRvzlAZ5Zhb3hqsNdTEMheN FDjZSL8J5jeJtvSRinY2p09CxpAMoJR9zHLmHl+zEOY8fInbB+KiFtSfGf0blSEY9/+isQP9 xmUIQWUj0kwVtrns7m1HrYLiI07NVFzbHNKqQcbPuwCg0n/KKi+VJiUs5MqLKwGuPotGeZME AIluMetTQwfLyovundMwFYlSZ/Z8JjkMybqgKuiRrZnaBVVZ80NjAYZI73yAZPfQh9mvFxW9 ipc2tSALwDy/tYDpQRK0k+0EsDmwG/wM6OarkqSuFcYx+tP86+2+6Xitn6E/hriIWa/ZQVef /fx7dZzdwhXH6fd34v8o/BuqhawLBACs4MTMGbdSmyI56vCMXWY1yxRPmuygd4vUnXqYwlrM Ee/LjQdreg1zTAJnnW1K+PgOUW/jvS+uAbgxLa3i59/Z4Uu7nB6G1y+Y1cThojUsLnvoJlt1 4XE1U/vnOcvO3evo6knB1qjbAMsZGaVleiVKDq+7XE7swe4WtBJKbYJthc0cVGhvbWFzIExh dXMgPGxhdXN0c0BhY20ub3JnPsJ/BBMRAgA/AheAAh4BBgsJCAcDAgYVCAIJCgsEFgIDAQIZ ARYhBBloSoDtPqFEokqZd+v/gtRiCDbPBQJaRO3QBQkfyKbkAAoJEOv/gtRiCDbPi+UAnAm8 +zuC7S1JQEjx/OU4asYWvLdcAJ0V59C0iowNwnxyPHBnYBQpOoDScc7BTQRFspgcEAgAjXsi 9WqowAKZ7d2ix6t7fiYgu2QBGWq36NvN+cPBJIu0CnagL1v4W1UrRW/0cInLzgqlWrSU7SFg y1+rGBlusMHf8/faGeZD0XwMdYgTIYdjdK5VZ0GaRWUs0LbHAOJQkOFRHLMAEG8wrc3f1xrn uVJ4JPOA81kTmTXvYTyQNXJBySc0oNSgvSut8aBbNGBZhw9U2V3yXXnnMeWR8+DYrriYdOdR eK7S0LNN8TPY60PJx3KLN9vUY9Cb5Ly0NavF3wREPQqYlNfTMoG/GA/n8XB6SCoMj73oKCyw FLbckBUjFsl7wTeKKvU68V8kWG762fscXhOhRduETGrja09MbwADBQf/WiycmdfNtB41+vvT HQqz9tm3ZHAW2yE53CxfQpvlyS/KwnWgLjl/iV0SHRDede0NJ5yTEqPVhqq7WCdlqVsHPSpX FfvyOgbNmjPmOY/a1nW4UnWSqA7bgQvkthahhoLeHzkU8YKupW0m05RIBpqQER6HwBOksTq4 sWV/lUy1P0VT8GqqPLNklKe2BEu+KhuhLV6XwEG3VrHNoY6/R5CMGvBhZbtiUViCZktmxJAj Fq0VCcuj7+Oo52eq4BL2vMrzLX+2Ib1JSWid6t0N+grXxbr2mv7H2V2/4Vo0XI3IKxPX1mdG y9RBkbRUGyV9A8RlaS0QTnXvsxZTjOnmjxPX68JPBBgRAgAPAhsMBQJLQftKBQkHcJauAAoJ EOv/gtRiCDbPjFIAn3xxpJ7L5KEAO31jgTyxZX1iLIqYAJ9pXvy5sGrjA8HQlOy9BR0FM6IG JMJPBBgRAgAPAhsMBQJQ9ZV5BQkNJDDXAAoJEOv/gtRiCDbPHHkAn3yVaT4ZzTxbTzWFRPWF QceKmgYYAJ9Oowt+YhIp5mNPUOE6GT1oU9g5XMJmBBgRAgAmAhsMFiEEGWhKgO0+oUSiSpl3 6/+C1GIINs8FAlpE7dwFCRaLREAACgkQ6/+C1GIINs9JdgCfeHMtCRjzubbkAvAVg5wQo7gF moUAoL39iRV66xSZ0w/I00RnFU3jsmiz Message-ID: <749bde52-58ba-b8db-9528-a74b0304a61e@acm.org> Date: Tue, 19 Jun 2018 14:22:33 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <3eac8c14-da21-5666-c060-d8a551b3ca49@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfE53B9COuOjzcsEq6fv2hSP5fOv4rMCF3Wru5MxAQTJUg7pRVSOEDyryuODI067aAjLt/gRDLW79m9l6Cusp4p+vcQGZAm8OWlRxdEfmAVUCHilnR3dZ 7upbgJgzTL+P3l+sB1141aKo8lBqTpaG5LKCBFC4CVh/nLgTjcT7PBtbOfRVv33lwjP3l9FKeqyGXIn8F7vpzVWpIqjCreaC1KE= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 19 Jun 2018 18:23:08 -0000 On 06/19/18 12:09, Allan Jude wrote: > > We tested all of the changes with the setup in tools/boot/rootgen.sh, it > will be interesting to figure out what went wrong with your setup, and > add it as a test case to prevent this in the future. > > The recent changes are: > > r335245 (reading the size of the disk) > r335254 (reading past the end of the disk) > r335276 (enable the serial console sooner so the password prompt can be > used over serial) > > There is also one outstanding fix: https://reviews.freebsd.org/D15847 > I don't think that my issue is related to the fix described in the review. I am using ~256G SSD's. They are slightly different sizes but are both >200M. I will try backing out the commits starting with r335276 and work backward from there. I will review the changes made to gptzfsboot to get the date that it was last touched. When I replace only gptzfsboot with one made 2 weeks ago (r334610) everything boots OK and I get a password prompt for the geli password. If the gptzfs bootcode after r335314 is copied to the boot record, the computer goes into a continuous reboot loop and only a part of the password prompt is shown before the reboot. The filesize on the bad gptzfsboot file is 121922 bytes and the good one is 121634 bytes. The filesize on that file has not changed in a few months. I keep old versions of this file since imp fixed things for me a few months ago when he made changes for loader code migration from Forth that caused a similar issue. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From owner-freebsd-current@freebsd.org Tue Jun 19 18:51:24 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DE12C1007C28 for ; Tue, 19 Jun 2018 18:51:23 +0000 (UTC) (envelope-from lausts@acm.org) Received: from cdptpa-cmomta01.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 69E5C70988; Tue, 19 Jun 2018 18:51:23 +0000 (UTC) (envelope-from lausts@acm.org) Received: from mail.laus.org ([65.29.112.189]) by cmsmtp with ESMTP id VLa9ftWsusMBqVLaDfqNzS; Tue, 19 Jun 2018 18:42:27 +0000 Received: from [192.168.1.100] (presario [192.168.1.100]) by mail.laus.org (8.15.2/8.15.2) with ESMTPS id w5JIpEur059128 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 19 Jun 2018 14:51:15 -0400 (EDT) (envelope-from lausts@acm.org) X-Authentication-Warning: mail.laus.org: Host presario [192.168.1.100] claimed to be [192.168.1.100] Reply-To: lausts@acm.org Subject: Re: Current @ r335314 not bootable with Geli and ZFS From: Thomas Laus To: Allan Jude , FreeBSD Current References: <61aeea9a-bb8b-65d0-1ffb-f8fb7b2f121d@acm.org> <3eac8c14-da21-5666-c060-d8a551b3ca49@freebsd.org> <749bde52-58ba-b8db-9528-a74b0304a61e@acm.org> Openpgp: preference=signencrypt Autocrypt: addr=lausts@acm.org; prefer-encrypt=mutual; keydata= xsDiBDx1NWwRBADARalI5I8kGeBYYYWnZB73T1fU4333yCuRokRvzlAZ5Zhb3hqsNdTEMheN FDjZSL8J5jeJtvSRinY2p09CxpAMoJR9zHLmHl+zEOY8fInbB+KiFtSfGf0blSEY9/+isQP9 xmUIQWUj0kwVtrns7m1HrYLiI07NVFzbHNKqQcbPuwCg0n/KKi+VJiUs5MqLKwGuPotGeZME AIluMetTQwfLyovundMwFYlSZ/Z8JjkMybqgKuiRrZnaBVVZ80NjAYZI73yAZPfQh9mvFxW9 ipc2tSALwDy/tYDpQRK0k+0EsDmwG/wM6OarkqSuFcYx+tP86+2+6Xitn6E/hriIWa/ZQVef /fx7dZzdwhXH6fd34v8o/BuqhawLBACs4MTMGbdSmyI56vCMXWY1yxRPmuygd4vUnXqYwlrM Ee/LjQdreg1zTAJnnW1K+PgOUW/jvS+uAbgxLa3i59/Z4Uu7nB6G1y+Y1cThojUsLnvoJlt1 4XE1U/vnOcvO3evo6knB1qjbAMsZGaVleiVKDq+7XE7swe4WtBJKbYJthc0cVGhvbWFzIExh dXMgPGxhdXN0c0BhY20ub3JnPsJ/BBMRAgA/AheAAh4BBgsJCAcDAgYVCAIJCgsEFgIDAQIZ ARYhBBloSoDtPqFEokqZd+v/gtRiCDbPBQJaRO3QBQkfyKbkAAoJEOv/gtRiCDbPi+UAnAm8 +zuC7S1JQEjx/OU4asYWvLdcAJ0V59C0iowNwnxyPHBnYBQpOoDScc7BTQRFspgcEAgAjXsi 9WqowAKZ7d2ix6t7fiYgu2QBGWq36NvN+cPBJIu0CnagL1v4W1UrRW/0cInLzgqlWrSU7SFg y1+rGBlusMHf8/faGeZD0XwMdYgTIYdjdK5VZ0GaRWUs0LbHAOJQkOFRHLMAEG8wrc3f1xrn uVJ4JPOA81kTmTXvYTyQNXJBySc0oNSgvSut8aBbNGBZhw9U2V3yXXnnMeWR8+DYrriYdOdR eK7S0LNN8TPY60PJx3KLN9vUY9Cb5Ly0NavF3wREPQqYlNfTMoG/GA/n8XB6SCoMj73oKCyw FLbckBUjFsl7wTeKKvU68V8kWG762fscXhOhRduETGrja09MbwADBQf/WiycmdfNtB41+vvT HQqz9tm3ZHAW2yE53CxfQpvlyS/KwnWgLjl/iV0SHRDede0NJ5yTEqPVhqq7WCdlqVsHPSpX FfvyOgbNmjPmOY/a1nW4UnWSqA7bgQvkthahhoLeHzkU8YKupW0m05RIBpqQER6HwBOksTq4 sWV/lUy1P0VT8GqqPLNklKe2BEu+KhuhLV6XwEG3VrHNoY6/R5CMGvBhZbtiUViCZktmxJAj Fq0VCcuj7+Oo52eq4BL2vMrzLX+2Ib1JSWid6t0N+grXxbr2mv7H2V2/4Vo0XI3IKxPX1mdG y9RBkbRUGyV9A8RlaS0QTnXvsxZTjOnmjxPX68JPBBgRAgAPAhsMBQJLQftKBQkHcJauAAoJ EOv/gtRiCDbPjFIAn3xxpJ7L5KEAO31jgTyxZX1iLIqYAJ9pXvy5sGrjA8HQlOy9BR0FM6IG JMJPBBgRAgAPAhsMBQJQ9ZV5BQkNJDDXAAoJEOv/gtRiCDbPHHkAn3yVaT4ZzTxbTzWFRPWF QceKmgYYAJ9Oowt+YhIp5mNPUOE6GT1oU9g5XMJmBBgRAgAmAhsMFiEEGWhKgO0+oUSiSpl3 6/+C1GIINs8FAlpE7dwFCRaLREAACgkQ6/+C1GIINs9JdgCfeHMtCRjzubbkAvAVg5wQo7gF moUAoL39iRV66xSZ0w/I00RnFU3jsmiz Message-ID: <3c4d82aa-9020-0da1-2c88-6cfe30c9525c@acm.org> Date: Tue, 19 Jun 2018 14:51:14 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <749bde52-58ba-b8db-9528-a74b0304a61e@acm.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfGJLHdjiNGI1xPumOU+/XAqH+9VN6SCj5uIQzcHwT5VxZTogWSuJirioKFMgWdz3i2wBC15kfxuc1cNTtH3LClc4Y/Va8KD+kQPxk3M0Mjl5z4xcwBVr J6bPVRCfBAxxcCJiMkcqh1n7ltJPRO7HGxc= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 19 Jun 2018 18:51:24 -0000 On 06/19/18 14:22, Thomas Laus wrote: > On 06/19/18 12:09, Allan Jude wrote: >> >> We tested all of the changes with the setup in tools/boot/rootgen.sh, it >> will be interesting to figure out what went wrong with your setup, and >> add it as a test case to prevent this in the future. >> >> The recent changes are: >> >> r335245 (reading the size of the disk) >> r335254 (reading past the end of the disk) >> r335276 (enable the serial console sooner so the password prompt can be >> used over serial) >> Allan: It looks like the problem is with r335276. I reverted back to that revision and built stand, my boot problem was still there. I reverted further back to r335254 and everything worked fine. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From owner-freebsd-current@freebsd.org Tue Jun 19 21:14:31 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B75E5100F1D4 for ; Tue, 19 Jun 2018 21:14:31 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp002.me.com (st13p35im-asmtp002.me.com [17.164.199.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5241676587; Tue, 19 Jun 2018 21:14:31 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp002.me.com by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0PAL00000587RB00@st13p35im-asmtp002.me.com>; Tue, 19 Jun 2018 20:13:45 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=04042017; t=1529439225; bh=OYuFS13l0bN5IoocWN3RkkeE9e7kg96p5KP73PuwDYE=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=FGIpOKaLAYevFl3htl/R0kUa+qHCL0FnzqP8JjW4N5qVfoh4xXfK7cd2K9MU/9+K+ gDf5ykn+Cjn64oXQjzmy10o4pT8Rob4djpmKiOrNqkyCTDtEqcLivlK2TdBa58S8qm C6QTt+Xu5ZDvHQi3Sg7m406no8b1t+z1vHuodbPaZwsbu/FKhSvDMPtB/oNOW7YZn3 DRFqdX0RwlaN4LOcsy136jeKQvx2QoOBUGRaFrwOrEaBZarwF/HCZTKWQ5wPTeUPOr zk0Xzc0oAuxcevEOqF+/k1K9lRIwd3UtncZD6PypZm5j+o0RDVQA1JcLHcNjbmSxcx V7eRlivC7bfhQ== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0PAL004506UQIU30@st13p35im-asmtp002.me.com>; Tue, 19 Jun 2018 20:13:41 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-06-19_10:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=4 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1806190220 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: Current @ r335314 not bootable with Geli and ZFS From: Toomas Soome In-reply-to: <3c4d82aa-9020-0da1-2c88-6cfe30c9525c@acm.org> Date: Tue, 19 Jun 2018 23:13:38 +0300 Cc: Allan Jude , FreeBSD Current Content-transfer-encoding: quoted-printable Message-id: <575782A1-D50B-4CF7-A82C-DF879375208E@me.com> References: <61aeea9a-bb8b-65d0-1ffb-f8fb7b2f121d@acm.org> <3eac8c14-da21-5666-c060-d8a551b3ca49@freebsd.org> <749bde52-58ba-b8db-9528-a74b0304a61e@acm.org> <3c4d82aa-9020-0da1-2c88-6cfe30c9525c@acm.org> To: lausts@acm.org X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 19 Jun 2018 21:14:31 -0000 > On 19 Jun 2018, at 21:51, Thomas Laus wrote: >=20 > On 06/19/18 14:22, Thomas Laus wrote: >> On 06/19/18 12:09, Allan Jude wrote: >>>=20 >>> We tested all of the changes with the setup in = tools/boot/rootgen.sh, it >>> will be interesting to figure out what went wrong with your setup, = and >>> add it as a test case to prevent this in the future. >>>=20 >>> The recent changes are: >>>=20 >>> r335245 (reading the size of the disk) >>> r335254 (reading past the end of the disk) >>> r335276 (enable the serial console sooner so the password prompt can = be >>> used over serial) >>>=20 > Allan: >=20 > It looks like the problem is with r335276. I reverted back to that > revision and built stand, my boot problem was still there. I reverted > further back to r335254 and everything worked fine. >=20 ou, in illumos side there was an idea of having early boot printouts = mirrored to serial, but it got turned down because there is no way to = tell if any system has some bad side effects from it=E2=80=A6 (either = directly or indirectly by having some weird device connected to the = serial). rgds, toomas From owner-freebsd-current@freebsd.org Tue Jun 19 23:32:26 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DC7161015B13 for ; Tue, 19 Jun 2018 23:32:26 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E2927B03F for ; Tue, 19 Jun 2018 23:32:26 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yw0-x230.google.com with SMTP id j134-v6so528025ywg.4 for ; Tue, 19 Jun 2018 16:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5EiGuKRYHJYYYrzJsRfKYZ5lEUY4xhbngPFmYgZmzKI=; b=aOMVItbA6vsiVb0iAgmmHZPu5tM7WulF0CWTAJkH2yYtdY88BIK5w/k186lVGS3gq4 gEe7lnT7TTYJzXKg2RYLQaJg5uEssFM0kJUFmypCKLz3RVSgvXizrm/f1DajjNqwW5/G Y49m5x1hwgjoxlgSWZUfwOWM6i7bXMUmxk8bw= 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=5EiGuKRYHJYYYrzJsRfKYZ5lEUY4xhbngPFmYgZmzKI=; b=Gq3M/teAjTqO4j1+Zp/bmBi/vH34NDVF2ABvPyrGa5rUV6oYbY3fWECSPVSsJwHg6S V8aN5AOFZjUm2juL5ATlzGPE1NGQsadTjrabZvQpsqma+hzI8Wrj/OYWgzsicR5UodbW Al+wZMx3WYJd4TfkNRQkE9rczDV/YdRh/ktIvHnl/ekLXHRfEi9sVcTyzBXjYg1DNq8c 7iM/e/IZlh6Cg7pfVG/62w1EpZ/xfd4EgISdxYpBZ8kdpC8WDG3VOnCPdENVPeJkWvWH 4DSrYtBm+NKcClpIj7BslBLVZagJhBnwVd7AOBdLhIjv52XaevvajZyZ1EIiBD7TIfoM SgyA== X-Gm-Message-State: APt69E0VxVU2rnU2WGlCquKWk51Oet7bAsx/Xj1smM4wQjy624wkT5YB AyhRoR1dKTCexWWmja4NbHx/pOmXR0FXe9lMvb5lWA== X-Google-Smtp-Source: ADUXVKJBvEJ2o8HxxbpQWuH/oycGfOGo84xQeS3Gx7353wQXOdhfhggm8YRItD92OneajNHdxqTAaK3kRrTBkRZB0rs= X-Received: by 2002:a0d:cf01:: with SMTP id r1-v6mr8830210ywd.162.1529451145541; Tue, 19 Jun 2018 16:32:25 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:ef50:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 16:31:54 -0700 (PDT) In-Reply-To: References: From: Eitan Adler Date: Tue, 19 Jun 2018 16:31:54 -0700 Message-ID: Subject: Re: top -m io Segmentation fault(core dumped) on fresh r335360 To: "Alex V. Petrov" Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 19 Jun 2018 23:32:27 -0000 On 19 June 2018 at 02:28, Alex V. Petrov wrote: > top -m io > Segmentation fault(core dumped) > FreeBSD alex.super 12.0-CURRENT FreeBSD 12.0-CURRENT #11 r335360: Tue > Jun 19 14:53:20 +07 2018 > alex@alex.super:/usr/obj/usr/src/amd64.amd64/sys/IOSCHED amd64 r335390 should fix it. -- Eitan Adler From owner-freebsd-current@freebsd.org Wed Jun 20 01:03:41 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BD7A6101A810 for ; Wed, 20 Jun 2018 01:03:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-2.consmr.mail.bf2.yahoo.com (sonic302-2.consmr.mail.bf2.yahoo.com [74.6.135.41]) (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 48DC77F09F for ; Wed, 20 Jun 2018 01:03:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: oORApigVM1kkDIBG754RiLTPtMrMz2UWEK2Cac_52nQ0lM16OkefXbUwm1VBrA5 iI0nLw7TvQ3iLYbjT1Z8upHW_dcO6U5BDV77njioRNQ9fvAikUvOMmm0ijp6yovxXYeCTziGIM_r eC6r5S4Zo6RBbeN80.c.ggYymfL6oJvcWnvQrf05no4PqYm8_VSJwwoo8Pe7Ag1GAzj_Syc_iAT2 wFb3fC5baMAqbWykSfpwtOurQrjA0S0CoBJ_RMQ5Fs7AstNg4YNQ41YZyXdZhUKkVcArfde2O.YV P2_6kJAMi7szAE6Z15p3dErjgOqLmDUck7dtOl0arnP3ayXAR3gau_lMNXPxu0GslphQhBeI2pDk c2m6YADJKPSt_KDQ_hRGGmIljw7Eqqm65u.8qAbMa9uEAHyuJwoL3T8vCw1QBh.IDf4Wm73NPMel O4gX_jQMvqC.qKOqVeOVfgbQ7u5sp3svjDv9RedFFmCiXoaOcYCwMQD.4CbDzH7LrtrUlmgJd0aC Xu83MDeCAnTJpi85ipeChPD7JUTVO4raU3q1f_YxR6NZxVIiCnKTHFnRp5w3r_RnPvwFBRYmGWUL W5muCaj8lSieBNIaTVYw2Wc2MHaVVepQVIXo7VN5LeWhxZ5far4ooUWqGupnMQ7DUl.SnLW5w3Mo XjotT.3sOvm1bnmZI4U_XPcG9PqVTnQtGPHGR_BQ0W_rZFZScYPJNA6_aeMaAQcvLhZUHbPY340O SsICV5J8OuLyhbstT4up5l4iCLYVkiUPFHW.h8egW06AwS.VDIpOJImimT2SvFV8dGRdC6zMH_m8 Cj68SUxOsRmpj7pQwGPnaxdHdLloVGZS4aaGvhOW3D7me8q1MXVxWxkjJBlX7c_8eOE50bYMGnMv vhnQF8twly35mD2DSvicpGXFhenSHZ2WCOY3kxu3bsNaSlVgMxqI1a7VhIbR_s3iA04MjMqWZd7c 8_IdGqunncxEzVtn2xNqpHAM- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Wed, 20 Jun 2018 01:03:35 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp426.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 9edb9fd29086b9df5d909c6a76957b3c; Wed, 20 Jun 2018 01:03:35 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: ci.freebsd.org's FreeBSD-head-amd64-gcc broken by -r335338 and/or -r335339 (-r335389 still broken) Message-Id: Date: Tue, 19 Jun 2018 18:03:32 -0700 To: erj@FreeBSD.org, FreeBSD Current X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 20 Jun 2018 01:03:42 -0000 =46rom = https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6190/consoleText and https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6213/ as examples: --- ixl_pf_qmgr.o --- In file included from /workspace/src/sys/dev/ixl/ixl_pf_qmgr.h:36:0, from /workspace/src/sys/dev/ixl/ixl_pf_qmgr.c:36: /workspace/src/sys/dev/ixl/ixl_pf.h:339:6: error: redundant = redeclaration of 'ixl_set_queue_rx_itr' [-Werror=3Dredundant-decls] void ixl_set_queue_rx_itr(struct ixl_rx_queue *); ^~~~~~~~~~~~~~~~~~~~ In file included from /workspace/src/sys/dev/ixl/ixl_pf.h:39:0, from /workspace/src/sys/dev/ixl/ixl_pf_qmgr.h:36, from /workspace/src/sys/dev/ixl/ixl_pf_qmgr.c:36: /workspace/src/sys/dev/ixl/ixl.h:545:8: note: previous declaration of = 'ixl_set_queue_rx_itr' was here void ixl_set_queue_rx_itr(struct ixl_rx_queue *que); ^~~~~~~~~~~~~~~~~~~~ In file included from /workspace/src/sys/dev/ixl/ixl_pf_qmgr.h:36:0, from /workspace/src/sys/dev/ixl/ixl_pf_qmgr.c:36: /workspace/src/sys/dev/ixl/ixl_pf.h:404:5: error: redundant = redeclaration of 'ixl_max_aq_speed_to_value' [-Werror=3Dredundant-decls] u64 ixl_max_aq_speed_to_value(u8); ^~~~~~~~~~~~~~~~~~~~~~~~~ In file included from /workspace/src/sys/dev/ixl/ixl_pf.h:39:0, from /workspace/src/sys/dev/ixl/ixl_pf_qmgr.h:36, from /workspace/src/sys/dev/ixl/ixl_pf_qmgr.c:36: /workspace/src/sys/dev/ixl/ixl.h:549:6: note: previous declaration of = 'ixl_max_aq_speed_to_value' was here u64 ixl_max_aq_speed_to_value(u8); ^~~~~~~~~~~~~~~~~~~~~~~~~ and: --- all_subdir_ixl --- In file included from /workspace/src/sys/dev/ixl/ixl_pf_main.c:36:0: /workspace/src/sys/dev/ixl/ixl_pf.h:339:6: error: redundant = redeclaration of 'ixl_set_queue_rx_itr' [-Werror=3Dredundant-decls] void ixl_set_queue_rx_itr(struct ixl_rx_queue *); ^~~~~~~~~~~~~~~~~~~~ In file included from /workspace/src/sys/dev/ixl/ixl_pf.h:39:0, from /workspace/src/sys/dev/ixl/ixl_pf_main.c:36: /workspace/src/sys/dev/ixl/ixl.h:545:8: note: previous declaration of = 'ixl_set_queue_rx_itr' was here void ixl_set_queue_rx_itr(struct ixl_rx_queue *que); ^~~~~~~~~~~~~~~~~~~~ In file included from /workspace/src/sys/dev/ixl/ixl_pf_main.c:36:0: /workspace/src/sys/dev/ixl/ixl_pf.h:404:5: error: redundant = redeclaration of 'ixl_max_aq_speed_to_value' [-Werror=3Dredundant-decls] u64 ixl_max_aq_speed_to_value(u8); ^~~~~~~~~~~~~~~~~~~~~~~~~ In file included from /workspace/src/sys/dev/ixl/ixl_pf.h:39:0, from /workspace/src/sys/dev/ixl/ixl_pf_main.c:36: /workspace/src/sys/dev/ixl/ixl.h:549:6: note: previous declaration of = 'ixl_max_aq_speed_to_value' was here u64 ixl_max_aq_speed_to_value(u8); ^~~~~~~~~~~~~~~~~~~~~~~~~ In file included from /workspace/src/sys/dev/ixl/ixl_pf_main.c:39:0: /workspace/src/sys/dev/ixl/ixl_pf_iov.h:60:7: error: redundant = redeclaration of 'ixl_handle_vflr' [-Werror=3Dredundant-decls] void ixl_handle_vflr(void *arg, int pending); ^~~~~~~~~~~~~~~ In file included from /workspace/src/sys/dev/ixl/ixl_pf_main.c:36:0: /workspace/src/sys/dev/ixl/ixl_pf.h:405:6: note: previous declaration of = 'ixl_handle_vflr' was here void ixl_handle_vflr(void *, int); ^~~~~~~~~~~~~~~ =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Wed Jun 20 01:23:58 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A0ED3101BD94 for ; Wed, 20 Jun 2018 01:23:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-28.consmr.mail.bf2.yahoo.com (sonic317-28.consmr.mail.bf2.yahoo.com [74.6.129.83]) (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 161237FD8D for ; Wed, 20 Jun 2018 01:23:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: K7_fKh8VM1kbz.AQGykHi4tUAXO0Bn0aheuaUfIZNIx7QtKfG0KghdYPtR..ZwV q0Xy7A9D6RYANrVouV_ij3qtq0JgajmaWrQlCMoA3sEDQz_5wB1OjAWFMBcjT_KjImHoMsVPXsEh PBKtOyKE8gCQzPgQp0BrC7zp6WqBzlhtLYMdx.n6cNii5Do4b52Kmuffb16yf46dJfflA3fwhAcd G9F7OV1UDoo3PJPI8uFlOPTDP6kW3.vRJcNbeWPdddAsNyE8xeS2kTev8Fs73vBcEB8lWwL8Ei6G EDwFWP9klwRj3goatw3apbJI1wWU7jFbJxQZv32qomaxNaFM7fibj_26iSdMES0BS0MqDTCJK1PN 31mUM4nlXPzs9EoBiIoQaV_2I1jaEMLEdu.aVPeDAgFlTFSRyiWeHn3vIjjnLU1ULu_uLofwWlwr vFhecUqM9M9RsWhrX7PmiSry0cCJKU3yEDefje8bgp6amnkjRr_inulBRRLH4z6mnDrhYQZ7810Z LLOiqmD_LZ28GoyNudchKLH2asPMD3RhjrJvWfmpiqPU9kHI8u609zX2YLRAR1Q_VXuiCMNguAvB mOCeW5Hk5DeCrEOhhAo5PVtW7A9SpCW5vDuijdYbc5HNFggehrVCp9L5mSc6Xt.V0nuMXIBYUO4s hvxyeIYleFGaX.IQICdYcUFC0Vrgedkb9w_ayrVR49TrA7T_wt3fMR00LTmJRVs6rS6GqyJDVa1K V90c5UpRGsxIJKXLAyLiJCxiHhJJo2_EglEbXm04mYew2vm4u0unJMd2WvOfZo3MPJM6byaNTmgN R_NgjO3Jw27Fb_zcXNqywbTdSJ.awFf80BCu9G1D84vK9URuF3Ifpu4UB6iSo.qezX.FeMYSkZfh SYWmPoIFvwf2NfDNBzEhgqVdIaXYamsCyiTIsQrKZQUIf4UbjR9bOVxI9sccW51dG5Cwyo9Z1CZR aFdFfHfHCvYsmXsqEhfA6r1vbrpkyLw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Wed, 20 Jun 2018 01:23:57 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp421.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 6c74acc7f1eb6fedc538085a3cbe90dc; Wed, 20 Jun 2018 01:23:56 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: A head buildworld race visible in the ci.freebsd.org build history From: Mark Millard In-Reply-To: Date: Tue, 19 Jun 2018 18:23:53 -0700 Cc: Ed Maste , Bryan Drewery , FreeBSD Current , FreeBSD Toolchain Content-Transfer-Encoding: 7bit Message-Id: References: <74EAD684-0E0B-453A-B746-156777CF604A@yahoo.com> <1884103f-d1fb-aca6-2edd-062e11d05617@FreeBSD.org> <33a43aac-231f-6158-1de4-f5dbfaf195df@FreeBSD.org> To: Li-Wen Hsu X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 20 Jun 2018 01:23:59 -0000 On 2018-Jun-19, at 8:02 AM, Li-Wen Hsu wrote: > On Mon, Jun 18, 2018 at 8:36 PM Ed Maste wrote: >> Li-Wen reported that the build is done in a 11.1-rel jail though, so >> the libarchive (or any userland) change shouldn't be responsible. >> >> Can we update a canary builder to somewhere between r328278 and r333388? > > butler1.nyi.freebsd.org is running r331373 now. But there seems to be another of the ar -> ranlib failures after that on butler1.nyi.freebsd.org : https://ci.freebsd.org/job/FreeBSD-head-powerpc-build/6321/ shows: 22:12:05 --- _bootstrap-tools-lib/liby --- 22:12:05 ranlib -D liby.a 22:12:05 ranlib: fatal: Failed to open 'liby.a' 22:12:05 *** [liby.a] Error code 70 with: NODE_LABELS bhyve_host butler1.nyi.freebsd.org jailer jailer_fast NODE_NAME butler1.nyi.freebsd.org And in fact there is at least one more: https://ci.freebsd.org/job/FreeBSD-head-sparc64-build/8291/consoleText shows: --- all_subdir_lib/libipsec --- ranlib -D libipsec_p.a ranlib: fatal: Failed to open 'libipsec_p.a' *** [libipsec_p.a] Error code 70 === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Wed Jun 20 02:43:36 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 232BB101FA5D for ; Wed, 20 Jun 2018 02:43:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-9.consmr.mail.gq1.yahoo.com (sonic315-9.consmr.mail.gq1.yahoo.com [98.137.65.33]) (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 9DAE782187 for ; Wed, 20 Jun 2018 02:43:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 12hzJtkVM1mE2cX5P9lZUi0UPe2r4DWkMxldaEaDMk6_vI0oRSemsaqX9jBE.sh AUk4YEfe2.R9svW2D5imIF_JYwcjhGdh7L1Z.D5xNhiQ8nzcFgutYf8hLKd_gXiDnerSjVxlQ4jU Ydi6om6KX5o5qLMOAfV94Taf7rTp91Txm1ZpvoLvK12zjYMFtbouId1OWFL5zMAyBK.GYVagbKS3 1YQqR8.OmCkqYWLjEagGqMm3HeHFhmStmjjh70M0lGNcsAEYlK2g_TS76owD7SR0r7uX5jZBQu25 264eoE4k8MzUXMO.ZXpB5ifS96VyF6muKWZAKodCi7e6MqWl0R84cysM3O0glAXfUv4D4DuB6FxD BLJw.SuxBSvYs54jzZSsWhG2VbEwuulwEUZeIjBuFxcp2zx4dIdCzrnCmR3oj5mApPjpyoAI1Bhz 08VZuqX8Rn94R7KitgdZuyzGLccKGg08iRbZx9dYH4a6VozRRK.PVlZ7iMHQczMLPnRsYjL8xNP0 TAuRuqJpxCLzQ1uYdxyp1DHzlqkF_H5XA7NTiHSbp9wW7Wp83HdRwwkQOdHaoMYxi6ehDuAGPUgW DlWJyDzJpMEYMFAhHJZbt5c6lPaaqejXF0TvwOoP8eLaEmZH38MQiacH.8dc9r79D15CHUTt7wRE b6ywbVyaDLHaUHdi_YvtYY_J14qgcJ0ONxVHZ9Dhv_XyqXj_XPciV3ajBfjGAZwOe75DYOlX.Rip h0LjgzageH0D57U9z0tJEV8EqgGL7_hYrHfCdpdAxeCWKyMlKTa5lJ.i0JwBtdmFLipgclCVnabb vIU_GGdEv7qquVdd9rjfq99.xxO45OjvU6Gi.PTzv8kU7WbA9yevOY1EEL.aIJ79jSoEtBY6mEhk SmOhen3hNjxTVxo7tXYrrcj.HhKRbDhYfFFlYLPVsJxmYlD9vHXHFC8RRBlzWpfGKiVissnkxuM9 HPsLLC6ZG5xJYl0.T1ODXBg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Wed, 20 Jun 2018 02:43:27 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp429.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 1c2b50e7dab6a76cdde66ca49e9a00ac; Wed, 20 Jun 2018 02:33:19 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: svn commit: r335399: . . . head/sys/security/mac_veriexec/ . . . breaks ci.freebsg.org builds of FreeBSD-head-{armv6,ar,m7,i386,mips,powerpc,powerpcspe}-build Message-Id: <16300ECA-4991-40B9-94CB-9579B3F19245@yahoo.com> Date: Tue, 19 Jun 2018 19:33:17 -0700 To: stevek@FreeBSD.org, svn-src-head@freebsd.org, FreeBSD Current X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 20 Jun 2018 02:43:36 -0000 Stephen J. Kiernan stevek at FreeBSD.org=20 Wed Jun 20 00:41:33 UTC 2018 Author: stevek Date: Wed Jun 20 00:41:30 2018 New Revision: 335399 URL:=20 https://svnweb.freebsd.org/changeset/base/335399 Log: MAC/veriexec implements a verified execution environment using the MAC framework. . . . But the logs on ci.freebsd.prg show for -r335399 and later for FreeBSD-head-{armv6,ar,m7,i386,mips,powerpc,powerpcspe}-build messages like: --- all_subdir_mac_veriexec --- cc1: warnings being treated as errors /usr/src/sys/security/mac_veriexec/veriexec_fingerprint.c: In function = 'identify_error': /usr/src/sys/security/mac_veriexec/veriexec_fingerprint.c:115: warning: = format '%lu' expects type 'long unsigned int', but argument 5 has type = 'dev_t' [-Wformat] /usr/src/sys/security/mac_veriexec/veriexec_fingerprint.c:115: warning: = format '%lu' expects type 'long unsigned int', but argument 6 has type = 'ino_t' [-Wformat] . . . --- all_subdir_mac_veriexec --- *** [veriexec_fingerprint.o] Error code 1 And, as a result, those builds fail on ci.freebsd.org . Basically the 32-bit architectures fail and the 64-bit ones do not (for the same code). I've not checked the later *veriex* related check-ins: -r335400 -r335401 -r335402 for possible similar problems. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Wed Jun 20 04:14:39 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8269F1023CAC; Wed, 20 Jun 2018 04:14:39 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) (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 EDA7885D87; Wed, 20 Jun 2018 04:14:38 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: by mail-wm0-f49.google.com with SMTP id v131-v6so4121734wma.1; Tue, 19 Jun 2018 21:14:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OJJ0KVz8sCrUyhohgYEpE0Mz2vjm6ks4wbnv2BFF6Nc=; b=Cl1pIMGD7yry0aZ97afWRBtoWJynKOnB8XhzsZTctg+XFtutZAGIvzTS3n4xDgfCQi 1Jjbld0D417MCETTDNRZKf8iJRnXX5OZ1bpJEd6nkx/mrhHSALJ+hE2gKCS3vY3yq+fA bEyLSq9eaBpAyvWoU01WsulASTkEHDqooUzb3DOG1f2HoqqTQX0ChoKjTux/UP5/eYE1 RDzFMxUykhomHrhgVhcYgjn7LR7SP11AO8ZMC5W9tSqEmbwrO+/TCX8kz8mrgwDi9FD6 4rpFXMXW8dnEXc+oVJfrn28W4Wqv6UH0nWuZahau16xo0jwdmcJojKRiXl1ebuThaw/i YgGQ== X-Gm-Message-State: APt69E3d4IdyAcQ2KZVRN/PBuZi88gSjHzWfLFRPzoYTRerV0AEcM7Fn pVGOnJee47I3P1iVXu6CdZ0UEB4IxMrslOOMrvd79jg4 X-Google-Smtp-Source: ADUXVKJ72Pe+OVdvD4Iwgp4F0XK1kfAJVenMfFxXvWkXYPuce8mOGqvVt9fECEDBXClbJyyPfbvPQLsl6ZlhtI156AU= X-Received: by 2002:a1c:ea4a:: with SMTP id i71-v6mr264615wmh.158.1529468077620; Tue, 19 Jun 2018 21:14:37 -0700 (PDT) MIME-Version: 1.0 References: <74EAD684-0E0B-453A-B746-156777CF604A@yahoo.com> <1884103f-d1fb-aca6-2edd-062e11d05617@FreeBSD.org> <33a43aac-231f-6158-1de4-f5dbfaf195df@FreeBSD.org> In-Reply-To: From: Li-Wen Hsu Date: Wed, 20 Jun 2018 00:14:27 -0400 Message-ID: Subject: Re: A head buildworld race visible in the ci.freebsd.org build history To: Mark Millard Cc: Ed Maste , Bryan Drewery , FreeBSD Current , FreeBSD Toolchain Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 20 Jun 2018 04:14:39 -0000 On Tue, Jun 19, 2018 at 9:24 PM Mark Millard wrote: > > On 2018-Jun-19, at 8:02 AM, Li-Wen Hsu wrote: > > > On Mon, Jun 18, 2018 at 8:36 PM Ed Maste wrote: > >> Li-Wen reported that the build is done in a 11.1-rel jail though, so > >> the libarchive (or any userland) change shouldn't be responsible. > >> > >> Can we update a canary builder to somewhere between r328278 and r333388? > > > > butler1.nyi.freebsd.org is running r331373 now. > > > But there seems to be another of the ar -> ranlib failures > after that on butler1.nyi.freebsd.org : Yes I was trying to narrow down the cause, now it seems between r328278 and r330304. butler1.nyi.freebsd.org is back to run r328278. And I'll try to reproduce this in elsewhere. -- Li-Wen Hsu https://lwhsu.org From owner-freebsd-current@freebsd.org Wed Jun 20 05:54:35 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 69B6B10022FB for ; Wed, 20 Jun 2018 05:54:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-23.consmr.mail.gq1.yahoo.com (sonic312-23.consmr.mail.gq1.yahoo.com [98.137.69.204]) (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 C557869030 for ; Wed, 20 Jun 2018 05:54:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: o292yOIVM1kh9uw2IRf4amQ1o.knC8V_7KZoaldXvg1z8bLurJQg3DW1nE8ZFWi okh7TX7HwzCQjlvpiSyN0QstC4f8Tmm_yCORDgaqYfhbUiSCnzyN1Z89x8I7lz5JS1FgAPOLC.ab bUD2UYbihdaIQmw_NFaCUhkz7IKnewHLH0mIBybZRfZPwor1FgwU60ZL7q9FLlPS58D5lmF8apcl jQuO2egSZ2FozRdxF5Hacupm70uNmA3U9s1WOJ_DDu1i7m4VXbFyoCQEiWlfxIYyIoDYCE2o1iRv 0MtbVEDd2KLrFFfkfC9jl6DTrsojz_ezH1zqkQ4VdS4voV4gI5gLZbBOhha_jg5sy8RQvCmyN1wZ UYz9XFsBB_UIZNmkOJVKiGaiwwt4BS2ICwRLUSbiGn_vyl_KajWCX2B1qaXgyG7cvc.lEuJKciHF F8brUEikCh50GR4fddTD6UUUH51hByRm5_bI7JO5B8ziye4uyuLrgLznO0G7DVoZeuTnYbmERDyg HsaQRxAekT.ZAmRBq1NvXUXDf6L7CMAtR0BM5iaoOwZPIirpY8SstUZ4oRv.MXnBTv1RFCJ4DcJ7 Gchk3JDNvvhfYFmdsQ2CBjatiP8.8DKdEsE3Wf64_euJd1OjfgIHTxU7RDJwtG4RYKssWo8Bblyy 9B_LqzY3vyBCaCIEEtKevFJjqf.hbbENRU0cYt67Otu.bCc_B3n2FyHA.6dVyBuQdQbKKlOAcM7t ZrWfdvQSlNI48RxVUJ05jdgnGiYltMZHh4ukFbqn_tdsdhHw1oWsMugmtwIK020eM23XVgDHXqrt KlbqbZ6jPO0XPKKVOu1XuNGDpIUJ87dn8Uff1d7CJ0RVsXzVGMQd1YdM49ZWs0Y8S059PGPD5KXL x8gyCfu9Kb7.7zrmA8rRq_j9T5aPK5AKI_SZUZX.e1o_51ejK4qhNxRUlp7zayH_jod6Xlooob6R rWEWiQg95z6CXfbOqhRk7gzBhAbpM Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Wed, 20 Jun 2018 05:54:33 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp410.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 3d5b8cbcac32e3145860924296b1643b; Wed, 20 Jun 2018 05:44:23 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: A head buildworld race visible in the ci.freebsd.org build history From: Mark Millard In-Reply-To: Date: Tue, 19 Jun 2018 22:44:22 -0700 Cc: Ed Maste , Bryan Drewery , FreeBSD Current , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <916F804A-7A7E-43A7-8DBF-EE4973FDD32A@yahoo.com> References: <74EAD684-0E0B-453A-B746-156777CF604A@yahoo.com> <1884103f-d1fb-aca6-2edd-062e11d05617@FreeBSD.org> <33a43aac-231f-6158-1de4-f5dbfaf195df@FreeBSD.org> To: Li-Wen Hsu X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 20 Jun 2018 05:54:35 -0000 On 2018-Jun-19, at 9:14 PM, Li-Wen Hsu wrote: > On Tue, Jun 19, 2018 at 9:24 PM Mark Millard = wrote: >>=20 >> On 2018-Jun-19, at 8:02 AM, Li-Wen Hsu wrote: >>=20 >>> On Mon, Jun 18, 2018 at 8:36 PM Ed Maste = wrote: >>>> Li-Wen reported that the build is done in a 11.1-rel jail though, = so >>>> the libarchive (or any userland) change shouldn't be responsible. >>>>=20 >>>> Can we update a canary builder to somewhere between r328278 and = r333388? >>>=20 >>> butler1.nyi.freebsd.org is running r331373 now. >>=20 >>=20 >> But there seems to be another of the ar -> ranlib failures >> after that on butler1.nyi.freebsd.org : >=20 > Yes I was trying to narrow down the cause, now it seems between > r328278 and r330304. >=20 > butler1.nyi.freebsd.org is back to run r328278. And I'll try to > reproduce this in elsewhere. Okay. Then I'll quit looking to report which way butler1.nyi.freebsd.org is working (implicitly: search direction information). I will report if I see any new examples. (Seems unlikely.) Side note . . . It took me a while to find what to look to find the head version and jail version involved. For what I reported (powerpc): 22:12:03 uname: 22:12:03 FreeBSD FreeBSD-head-powerpc-build.jail.ci.FreeBSD.org = 11.1-RELEASE FreeBSD 12.0-CURRENT #0 r330304M: Sat Mar 3 02:23:02 UTC = 2018 peter@build-12.freebsd.org:/usr/obj/usr/src/sys/CLUSTER12 = amd64 Now I know. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Wed Jun 20 09:10:03 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1EE31100CCB3 for ; Wed, 20 Jun 2018 09:10:03 +0000 (UTC) (envelope-from pho@holm.cc) 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 A667771F8B for ; Wed, 20 Jun 2018 09:10:02 +0000 (UTC) (envelope-from pho@holm.cc) Received: by mailman.ysv.freebsd.org (Postfix) id 6298E100CCAD; Wed, 20 Jun 2018 09:10:02 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 507DB100CCAC for ; Wed, 20 Jun 2018 09:10:02 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) (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 0366371F88 for ; Wed, 20 Jun 2018 09:10:01 +0000 (UTC) (envelope-from pho@holm.cc) Received: from x2.osted.lan (87-58-223-204-dynamic.dk.customer.tdc.net [87.58.223.204]) by relay01.pair.com (Postfix) with ESMTP id 725C7D00BA1 for ; Wed, 20 Jun 2018 05:10:00 -0400 (EDT) Received: from x2.osted.lan (localhost [127.0.0.1]) by x2.osted.lan (8.15.2/8.15.2) with ESMTPS id w5K99vK0000169 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 20 Jun 2018 11:09:57 +0200 (CEST) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.15.2/8.15.2/Submit) id w5K99vC0000168 for current@freebsd.org; Wed, 20 Jun 2018 11:09:57 +0200 (CEST) (envelope-from pho) Date: Wed, 20 Jun 2018 11:09:57 +0200 From: Peter Holm To: current@freebsd.org Subject: Page fault in udp_usrreq.c:823 Message-ID: <20180620090957.GA130@x2.osted.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.0 (2018-05-17) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 20 Jun 2018 09:10:03 -0000 20180620 10:32:47 all (1/1): udp.sh Kernel page fault with the following non-sleepable locks held: shared rw udpinp (udpinp) r = 0 (0xfffff80bbc808d78) locked @ netinet/in_pcb.c:2398 stack backtrace: #0 0xffffffff80c00733 at witness_debugger+0x73 #1 0xffffffff80c01b11 at witness_warn+0x461 #2 0xffffffff81075763 at trap_pfault+0x53 #3 0xffffffff81074d7a at trap+0x2ba #4 0xffffffff8105076c at calltrap+0x8 #5 0xffffffff80dd21b0 at udp_ctlinput+0x50 #6 0xffffffff80d3081d at icmp_input+0x96d #7 0xffffffff80d316d7 at ip_input+0x3f7 #8 0xffffffff80cc0a92 at netisr_dispatch_src+0xa2 #9 0xffffffff80ca3ebe at ether_demux+0x16e #10 0xffffffff80ca5377 at ether_nh_input+0x427 #11 0xffffffff80cc0a92 at netisr_dispatch_src+0xa2 #12 0xffffffff80ca437f at ether_input+0x8f #13 0xffffffff80cbc500 at iflib_rxeof+0xc90 #14 0xffffffff80cb6b6f at _task_fn_rx+0x7f #15 0xffffffff80bdd209 at gtaskqueue_run_locked+0x139 #16 0xffffffff80bdcf88 at gtaskqueue_thread_loop+0x88 #17 0xffffffff80b54514 at fork_exit+0x84 Fatal trap 12: page fault while in kernel mode cpuid = 10; apic id = 0a fault virtual address = 0x8 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80dd2423 stack pointer = 0x0:0xfffffe00004a5500 frame pointer = 0x0:0xfffffe00004a55a0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (if_io_tqg_10) [ thread pid 0 tid 100069 ] Stopped at udp_common_ctlinput+0x263: cmpq $0,0x8(%rax) db> Details @ https://people.freebsd.org/~pho/stress/log/udp_usrreq.txt -- Peter From owner-freebsd-current@freebsd.org Wed Jun 20 14:47:08 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 54AA6101CD53; Wed, 20 Jun 2018 14:47:08 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D20E07D465; Wed, 20 Jun 2018 14:47:07 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x233.google.com with SMTP id d22-v6so3678536iof.13; Wed, 20 Jun 2018 07:47:07 -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=dTDi6hnOOwpJJAErsYDQ9rDRqUJUU958FuetSmEkenM=; b=J16GU4OrGG1b/F8vwcWOljnmYST40+XhrPAqRzjJvgrwr6GdMfsg8y88+aAjExCRcU piosbpBaAuoqC5xq679d7Y5ZVPJORYfd+zGiRIDBs0lduMo22CfsXdSASVygRzFWBoBO EnBXIcM89OP8MjqoDNaaAi1j3W2X99VzJ2O49L0eG/nQ68rEj1IsdLmi9oWQnNMNah/B VByiX6JdcJSgGckJ5/X3Kcf6UsfNqe7+WIK8HVlFjEYZ5Kz34XLZZIpqQRBur/s+p1x0 978RKUWrPtJ+YLmZ0wm4/jF4nkrMohp/Eh661IPqqSBpXe5EhFyQp9bxXQsGyfQZX3O1 Qpcg== 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=dTDi6hnOOwpJJAErsYDQ9rDRqUJUU958FuetSmEkenM=; b=MKwKQArAnJPGvtcVWYmki6UuKoU/h9X4KV2R+hYfRODujdN7y9OgO9LuDj5YpxkYKH fkd4mNBkGhF9Y3EXzvzg5pUHeeolKTef8H0luKPWjoRR0tm9VN0f1CvCOXWPLDQSYBc9 eeQm5T/fk7U83UiNnDbvKMCSohpbRipo8g13vSyY9DxEHenKJ2b7GDFLnkoxoE5Ae6G7 rLj3vBxwjPLZMVKF05i225dqSfBcBge9MVzWihl2DBRzTiUhgzTaLcV8BHRZPi4o9JyF NlBG/ZXDnqbwLicPAq3HyG+ns8YuhA1SDres/vf0d5sdXb7x4MH8iKmBeMtqGNyivN9S hmog== X-Gm-Message-State: APt69E1SfF+KP3N6+kd+4gxFmbryU9IeHFjpgSi4HmY+k+1g8xZKKnyG pYWLdZPdSKgwh8kUmNZNhVjkgMZV7/OOwkMU6/YoOomb X-Google-Smtp-Source: ADUXVKIhZ3IbCWYrSQJ/VrMRj55CO8AZmfPRr4mQaw1tYCPwG6g7KB/OjBMVxM3s3u3/l6karJhT3xPkwcA0s9rnKWc= X-Received: by 2002:a6b:2cd:: with SMTP id 196-v6mr16837806ioc.294.1529506026990; Wed, 20 Jun 2018 07:47:06 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 2002:a6b:87c4:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 07:46:46 -0700 (PDT) From: Ed Maste Date: Wed, 20 Jun 2018 10:46:46 -0400 X-Google-Sender-Auth: ezVuUXpBQkD2iedP8W9aZUmP9mQ Message-ID: Subject: Tool Chain Migration: objdump users, please test llvm-objdump To: FreeBSD Current , "freebsd-toolchain@FreeBSD.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 20 Jun 2018 14:47:08 -0000 Work is in progress to migrate fully to modern and permissively licensed components for the tool chain. This includes moving away from the three obsolete binutils components that are still in the base system (as, ld, objdump). objdump is a tool to report information about binary objects (such as headers, symbols, etc.), is not required as a build tool, and in any case many uses of objdump are better served by readelf. For FreeBSD 12 I intend to remove GNU objdump 2.17.50. PR 229046[1] is open to track tasks related to its removal, and users who need GNU objdump can install an up-to-date version from the ports tree or the binutils package. That said, llvm includes a somewhat equivalent llvm-objdump, and it is built by default in FreeBSD now. If llvm-objdump's command line option support and output format is "close enough" to GNU objdump for most users we may decide to install it as /usr/bin/objdump. Therefore, I would like to ask users of GNU objdump in FreeBSD to give llvm-objdump a try. Please let me know if it works for your uses, or describe deficiencies that you found. [1] https://bugs.freebsd.org/229046 From owner-freebsd-current@freebsd.org Wed Jun 20 15:50:31 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63001102067A; Wed, 20 Jun 2018 15:50:31 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0879380D0C; Wed, 20 Jun 2018 15:50:30 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id B6A4E5A9F12; Wed, 20 Jun 2018 15:50:22 +0000 (UTC) Date: Wed, 20 Jun 2018 15:50:22 +0000 From: Brooks Davis To: Ed Maste Cc: FreeBSD Current , "freebsd-toolchain@FreeBSD.org" Subject: Re: Tool Chain Migration: objdump users, please test llvm-objdump Message-ID: <20180620155022.GA92001@spindle.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 20 Jun 2018 15:50:31 -0000 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 20, 2018 at 10:46:46AM -0400, Ed Maste wrote: > Work is in progress to migrate fully to modern and permissively > licensed components for the tool chain. This includes moving away from > the three obsolete binutils components that are still in the base > system (as, ld, objdump). objdump is a tool to report information > about binary objects (such as headers, symbols, etc.), is not required > as a build tool, and in any case many uses of objdump are better > served by readelf. >=20 > For FreeBSD 12 I intend to remove GNU objdump 2.17.50. PR 229046[1] is > open to track tasks related to its removal, and users who need GNU > objdump can install an up-to-date version from the ports tree or the > binutils package. >=20 > That said, llvm includes a somewhat equivalent llvm-objdump, and it is > built by default in FreeBSD now. If llvm-objdump's command line option > support and output format is "close enough" to GNU objdump for most > users we may decide to install it as /usr/bin/objdump. Therefore, I > would like to ask users of GNU objdump in FreeBSD to give llvm-objdump > a try. Please let me know if it works for your uses, or describe > deficiencies that you found. I think we've changed our flag us in CheriBSD to accommodate llvm-objdump so at least a few months ago flag compatibility was poor. The output is different, but fine for my uses (producing human readable assembly output). -- Brooks --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJbKne9AAoJEKzQXbSebgfA7uAH/2xPXhLzGp20uqe/KwYrdjm5 zeol32twuy23tuwUsxS/cqFK0uR7ZafA3pC4aOLKWa72EbOnKE5IqCqn729yn59+ yb/leR0KOZ3IVbAGinM/yyQEYhQSkHCJYwA+zyTY8oIP1PmRBy0eVNAaMwIYk4eq b+5W/KgrdJkK4N2Z6le2I6gd1skAr4fZ/gbZUxPH/IyEfykNgu0aJa546WAxm38u 0RgNOv47X7Ln3nqGJMlbOP/ji4VzaCQZcfuyNJKh5nh1sc7+++3k6UWZCOoXyh/Y LZuy5mkQbSrB/uMmoKlyy2H4jiGGIr6yUTWlZCA+nkEnv2zb4y29XZ3nwzYTmAQ= =y0r2 -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- From owner-freebsd-current@freebsd.org Wed Jun 20 16:43:28 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D62B7102381E for ; Wed, 20 Jun 2018 16:43:28 +0000 (UTC) (envelope-from ricera10@gmail.com) Received: from mail-ot0-f171.google.com (mail-ot0-f171.google.com [74.125.82.171]) (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 6F0EC842F4 for ; Wed, 20 Jun 2018 16:43:28 +0000 (UTC) (envelope-from ricera10@gmail.com) Received: by mail-ot0-f171.google.com with SMTP id d19-v6so226934oti.8 for ; Wed, 20 Jun 2018 09:43:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5uyvESMHwShn/KCDmqKJ41Nd/bB4kSw6wRfPclkhPwg=; b=PgNsJEIpLJu1MIs6utbxcKIbDdtdaddd1+9th/yDaQdaMn7TJOkUxFcHNaf7X39gX4 DjmC83eWAI9sbDBQxm95rZZcIJfvk4y5xm0OkIBjpNuvjk76azza2J4StYXLuYE+4DxH 3AaXEO7xdovi2GJwyy0YQytKGRyAN1opFgSMhONd9V3mlLe72dRAk3KQbxHlZd97bRGI MepPp6oCjmvbF/SpqpF6GFHdWOtEzQIBGOuDs/yRWu3OOZ2CQzntJj+cyyOYHZJPtvbv 4Rv4LU/XvHnZkGJ1d46gcGu6OxIDZvr0hPcIyz8FZZF/YXjzv4u6QP+eOz7wopkQhNZ4 MGEg== X-Gm-Message-State: APt69E3OSGEjQ/8KB2yOq8XgT5mNnAVXiRNZEqiU8AuRjErGM68ABKJf BiuMwToYGj7YjUMx5c5CDWOaY//U X-Google-Smtp-Source: ADUXVKJnd1dxBR9oTXh5yofvLqjN+y3HbmL9l/5X4JHpQeTL7/wKLPvKci+PoeO0nz9swH7ctVnCXA== X-Received: by 2002:a9d:4e99:: with SMTP id v25-v6mr13810634otk.328.1529511111458; Wed, 20 Jun 2018 09:11:51 -0700 (PDT) Received: from mail-ot0-f180.google.com (mail-ot0-f180.google.com. [74.125.82.180]) by smtp.gmail.com with ESMTPSA id 200-v6sm2175280oib.49.2018.06.20.09.11.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jun 2018 09:11:50 -0700 (PDT) Received: by mail-ot0-f180.google.com with SMTP id 92-v6so111114otw.9 for ; Wed, 20 Jun 2018 09:11:50 -0700 (PDT) X-Received: by 2002:a9d:5305:: with SMTP id g5-v6mr3434371oth.213.1529511110813; Wed, 20 Jun 2018 09:11:50 -0700 (PDT) MIME-Version: 1.0 From: Eric Joyner Date: Wed, 20 Jun 2018 09:11:15 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: mount_smbfs stack overflow issue with long hostnames To: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 20 Jun 2018 16:43:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228354 Can someone look at fixing this for 12? Non-gracefully handling long names is a pretty bad bug. - Eric From owner-freebsd-current@freebsd.org Wed Jun 20 21:08:47 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1EE3B100C316; Wed, 20 Jun 2018 21:08:47 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B925774D7A; Wed, 20 Jun 2018 21:08:46 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 86F2019612; Wed, 20 Jun 2018 21:08:46 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id C0BB41D4B; Wed, 20 Jun 2018 21:08:45 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id lNY455BWnvcp; Wed, 20 Jun 2018 21:08:43 +0000 (UTC) To: FreeBSD Current DKIM-Filter: OpenDKIM Filter v2.10.3 mail.xzibition.com 219291D46 Cc: FreeBSD Toolchain From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Autocrypt: addr=bdrewery@FreeBSD.org; prefer-encrypt=mutual; keydata= xsBNBFJphmsBCADiFgmS4bIzwZijrS31SjEMzg+n5zNellgM+HkShwehpqCiyhXdWrvH6dTZ a6u50pbUIX7doTR7W7PQHCjCTqtpwvcj0eulZva+iHFp+XrbgSFHn+VVXgkYP2MFySyZRFab D2qqzJBEJofhpv4HvY6uQI5K99pMqKr1Z/lHqsijYYu4RH2OfwB5PinId7xeldzWEonVoCr+ rfxzO/UrgA6v/3layGZcKNHFjmc3NqoN1DXtdaEHqtjIozzbndVkH6lkFvIpIrI6i5ox8pwp VxsxLCr/4Musd5CWgHiet5kSw2SzNeA8FbxdLYCpXNVu+uBACEbCUP+CSNy3NVfEUxsBABEB AAHNJEJyeWFuIERyZXdlcnkgPGJkcmV3ZXJ5QEZyZWVCU0Qub3JnPsLAgAQTAQoAKgIbAwUL CQgHAwUVCgkICwUWAwIBAAIeAQIXgAIZAQUCWujOIgUJCmB7NwAKCRA113G7bkaXz/xpB/9b /UWIPbieY1IeIuHF2pyYPE7Hytkh3HVsxMA0F5Ma2AYQsXZZeKNKWrF7RPyDyDwUklLHJkhm k3EfClBbHxf08kMIm1vWCJRtgxic9knY/bzYGiWMpHjg3cSd1XfrYH1autYqTZAjDwIkgOjU dR//Tbn4V36sY7y2jz+kdMVWvK53U32aZqiwBbCn4DPe1wSZcUs17mV/0uZdIoGdj74B1orN A/0py5vHYo6HcbBNoaR8pKRLf5VZNRsxqGIMhTucx4SJWcHpuRBWYyvJSFzwvxdK4ZD4Yqoc kFGPVtOXktVMai9exrLvP3G77fKMu8DI6j4QRU4wCesnHuIfRPFuzsBNBFJphmsBCACiVFPf kNfaFtUSuY0395ueo/rMyHPGPQ2iwvERFCpeFGSQSgagpenNHLpFQKTg/dl6FOoST5tqyxMq fyHGHDzzU51bvA/IfaGoNi/BIhTe/toZNMRvpcI3PLjiGcnJnuwCCbAVOAGdb+t5cZtpNdOI cKYmrYG3u9RiBpe6dTF+qLrD/8Bs1wjhduQ8fcNNgnkXu8xDH4ZxY0lIc3QgvYWp9vimlQe6 iKjUd2/DX28ETZcD5h6pYV331KMPTrEI0p0yvFijUZce8c1XHFyL1j9sBAha5qpszJl6Uq5i LolhKRcGfcdmtD72vHQjUYglUyudSJUVyo2gMYjdbiFKzJulABEBAAHCwGUEGAEKAA8CGwwF AlrozigFCQpgez0ACgkQNddxu25Gl8+m5Af/R3VEdxNMAcDIes9ADhQyofj20SPV3eCJ3HYR OebTSuNdOudGt4AAyA8Ks94u9hiIp5IGsc6RDsT9W7O2vgXhd6eV3eiY5Oif5xLIYrIDVu1Y 1GyRxRrPEn/QOqDN6uFZCPwK1aOapGcYCrO9lB0gMuTVfgHanU61rgC9tMX0OoAOyRd+V3/M 8lDNhjJdF/IpO3SdYzKfkwduy4qamw4Gphcx/RfYQvYLq/eDkP8d50PphWdboqWBwNRHayro W/07OGzfxM5fJ5mBsXPQcO2QcRjkyHf6xCM6Hi1qQL4OnXMNE/ZTX0lnOj1/pH93TlzSHZMP TaiiA/MBD3vGsXBmBg== Organization: FreeBSD Subject: [CFT] tinderbox/universe building clang once Message-ID: <7dc2e7de-410e-bf24-2b3c-a91e4a97e4f2@FreeBSD.org> Date: Wed, 20 Jun 2018 14:08:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fn7CExqiCzxskqk2aB5Z1aaDownqZxUOg" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 20 Jun 2018 21:08:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fn7CExqiCzxskqk2aB5Z1aaDownqZxUOg Content-Type: multipart/mixed; boundary="UL11EkMzdgYPJWnEqdE1m54eNepYJ0M8t"; protected-headers="v1" From: Bryan Drewery To: FreeBSD Current Cc: FreeBSD Toolchain Message-ID: <7dc2e7de-410e-bf24-2b3c-a91e4a97e4f2@FreeBSD.org> Subject: [CFT] tinderbox/universe building clang once --UL11EkMzdgYPJWnEqdE1m54eNepYJ0M8t Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable https://people.freebsd.org/~bdrewery/patches/universe-one-clang.diff This will build clang once if any of the targets specified (or defaulted) require bootstrapping clang. It probably has some issues with LLD_BOOTSTRAP in some cases. It could be improved more in the future for reusing more of the tools built but I think this is good enough for now as it saves the majority of the time in the bootstrap phases on clang. This won't work for GCC unless it learns convenient -target support. Its needed --sysroot support was also broken until some recent work from John Baldwin but I'm not sure if that has been committed yet. Also FYI WITH_SYSTEM_LINKER support is now in to avoid building libclang for lld on archs that have LLD_BOOTSTRAP set. I'm putting this out for testing since tinderbox/universe take so long and I can't possibly test all workflows with it myself. --=20 Regards, Bryan Drewery --UL11EkMzdgYPJWnEqdE1m54eNepYJ0M8t-- --fn7CExqiCzxskqk2aB5Z1aaDownqZxUOg 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 iQEcBAEBAgAGBQJbKsJbAAoJEDXXcbtuRpfPwzYIANro40U71/wwbk2wKD0ua+xB ToH7z4gdfDlaRHdlUxacIkUlcNBXWPcx/z2Qw/6pl5G4qPA2OZ/YGAly6GqKTDbf DkRwWX/3SuJerbxJT++o+YocapkleYN/xqa/n5sSriqsmy5KCI9ltmQlcvPUqBVH nVwr5IviCldxtDv1TQumD6impVhfXbf6Ll/Io0XWix1auR8UJC/KrBfR27hhgdK4 i8PlIzF8IFz7xNLn92TZHuYVpeROBy+a+OKgQavyc5vbfbKR6Z7k1hKtqUCrEFIQ Om09xZOWqkyjgrIVB4jtUtf2cD/ZWgi2BbDKz1VzfU8RaLbpQyMYuYVoczEeyF0= =CDWz -----END PGP SIGNATURE----- --fn7CExqiCzxskqk2aB5Z1aaDownqZxUOg-- From owner-freebsd-current@freebsd.org Wed Jun 20 22:26:01 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 303A4100FC01 for ; Wed, 20 Jun 2018 22:26:01 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9DC4F7783B for ; Wed, 20 Jun 2018 22:26:00 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-wm0-x243.google.com with SMTP id r125-v6so2248193wmg.2 for ; Wed, 20 Jun 2018 15:26:00 -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=uKEjXyFedaly3u8DaZxZpvyWQdknKghAExr5rG9FHAw=; b=bVrJJwp+i014n5r96qF/QR7dG1mydBjoMmU7T/UBk0dYHOsnis3bWQ8VQYZCDLNpCr 6F1OTRoZeTnPrSEMNnqoicipBTN20AiJaHKgTbLNclCBz+Cv/OQIpytMOuwidlm5U8+L GyMIC9bl+nchtGU7BXS2v17NsvB3ZXCsPBsSSsgXlvAeA3V8l83fRwpjk3fSwIJQAVz+ 6AEM6Q4UyzjnZSgLRyutpy/8xL0Sg/GcIfo/2fhDNzFbGu7EdL4W+MDi7gQrpYJ1+Lex D2nwnLzPHlh4JifT7VCVPrlq9H8vKVHRTtoXRADkpEg7vxi0Zj/n/vtUMuczHlEjw+5m BekA== 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=uKEjXyFedaly3u8DaZxZpvyWQdknKghAExr5rG9FHAw=; b=tGxHjS1UFK9fnrQ62eZuoLFqa1iDHPwEr8z/ZFa8wCFgAZkyABbMcb2K9mEbaXWw78 WG2Teo3xZ+RN3+lKmeUFWDjBeTuxZJeqcvcj5p2v85hYzZW6X9v173g5GPMANfjzay8m CTzUtfvwYYy2gkpV/QSRaaZ542xWIDNVK+t2+vEGuWRp/5vmvjUxjk2upq5TwWnQHFpz GJVrcFe5oebKHh9xmGHQhy+kR5SDolADfkVoNFnEzmx5p7YE/aGz7QYbYfYv6bwm7Yt8 jR2/BxrIffDZ1tYY9LQJ5/UKopL1nD/nHsHBQgLtquO8Wc5/ZBaEnIJAl9+N9vEh9Fut doQA== X-Gm-Message-State: APt69E08V3XXsGSCqBlNkbv7z+WvjihNH16tPqlKscU5FoZuOyAZEVj1 ZZf/uS76JgfPEzjvgef1mKHbhA== X-Google-Smtp-Source: ADUXVKILIMSXQqiNUdw7Gs9g7N01jD7gf6qc5gch1ARbC+/w9NOR8QdeVK9Sb4pzglLMRPKuszXMfQ== X-Received: by 2002:a50:8f42:: with SMTP id 60-v6mr19470280edy.248.1529533559407; Wed, 20 Jun 2018 15:25:59 -0700 (PDT) Received: from mutt-hbsd (tor.matmen.me. [94.16.123.176]) by smtp.gmail.com with ESMTPSA id r10-v6sm1444237edo.77.2018.06.20.15.25.56 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 20 Jun 2018 15:25:58 -0700 (PDT) Date: Wed, 20 Jun 2018 18:25:27 -0400 From: Shawn Webb To: Ed Maste Cc: FreeBSD Current , "freebsd-toolchain@FreeBSD.org" Subject: Re: Tool Chain Migration: objdump users, please test llvm-objdump Message-ID: <20180620222527.vkd5fm3ksd5j6yux@mutt-hbsd> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nq7lbmr2sjwra7le" Content-Disposition: inline In-Reply-To: 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/20180323 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 20 Jun 2018 22:26:01 -0000 --nq7lbmr2sjwra7le Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 20, 2018 at 10:46:46AM -0400, Ed Maste wrote: > Work is in progress to migrate fully to modern and permissively > licensed components for the tool chain. This includes moving away from > the three obsolete binutils components that are still in the base > system (as, ld, objdump). objdump is a tool to report information > about binary objects (such as headers, symbols, etc.), is not required > as a build tool, and in any case many uses of objdump are better > served by readelf. >=20 > For FreeBSD 12 I intend to remove GNU objdump 2.17.50. PR 229046[1] is > open to track tasks related to its removal, and users who need GNU > objdump can install an up-to-date version from the ports tree or the > binutils package. >=20 > That said, llvm includes a somewhat equivalent llvm-objdump, and it is > built by default in FreeBSD now. If llvm-objdump's command line option > support and output format is "close enough" to GNU objdump for most > users we may decide to install it as /usr/bin/objdump. Therefore, I > would like to ask users of GNU objdump in FreeBSD to give llvm-objdump > a try. Please let me know if it works for your uses, or describe > deficiencies that you found. In preparation for Cross-DSO CFI support, HardenedBSD switched to llvm-ar, llvm-nm, and llvm-objdump on 12-CURRENT/arm64 with commit a3db6f9006499b55c2042faccd0ed6a6777b9d9f (22 Dec 2017). There are some issues with the ports tree, but I haven't quantified them, yet. All high-visibility applications (firefox, apache, nginx, openvpn, etc.) all work with a full llvm toolchain (again: llvm-ar, llvm-nm, and llvm-objdump). Some applications break during runtime and not build time. Certain pidgin plugins break, for example, at runtime due to a full llvm toolchain, but compile just fine. Would you like me to quantify the compilation breakages due to the full llvm toolchain switch? If so, I can do that after July 12th. Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal: +1 443-546-8752 Tor+XMPP+OTR: lattera@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --nq7lbmr2sjwra7le Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlsq1FIACgkQaoRlj1JF bu6JfA/9ExEew2VcI4fz2rc3F3/YIKkc9MuY5+w8UsNNaFK2ye2WjAhDP5lPcCzp PxqRkILYXk6uRnZvNXIAawpo2I5DXnNhVvsEK6f0oBCZe8/OTscKGWKueNbg5e4q 7my69lfJujCK6kxrS4vgfUMwqHg9DwhCCyI/mT7hkRVZXaxzbFRQad925jhyjCWH n9nzWOgHV0k7JMAH6S9F4jqLiYFQDGNvay6t5EGtMEv7u2aCdSthS0byCyTr1qd2 v3qQD+elYI8Wpo84bTVKyxBWXW8vI6hwzOftD5QNUwIiA8VpuYahIt7XoE8xhUEK Ua5DLQNrUL6q3kHkhoJjPES2dPBc9X2hPX+5cIMIIE6+Dsfjx2unYMee4zkyH+qb oeb7OyV37voF7DeDxPPn4sLT9P1zZHJ0CrC84iLit+zT2qX6Mo2z+S084vLMAPKI qkDf9d4vumwjs0WSy74G3mhro2KdEZno+CqFD+GTMYNf2LMA647jj9BLaMkuj/ce Y69/c/JO2q228PN2oqznZzPB88UX3s/t4i6whMUMZSL8eCrp23IE0AH/IBTPnJti TdSnk3eH/DAJWbFj9Gg5ptpIpVl2w2OFttA5i7+Drh3YaE6crcdGCMrx/iwtQtZ3 mS97wWhypYkguS564AHktJYDuFhNkSGvEygPIkJGa5jSZASOCyw= =28XV -----END PGP SIGNATURE----- --nq7lbmr2sjwra7le-- From owner-freebsd-current@freebsd.org Wed Jun 20 23:31:43 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 968F41012B2D; Wed, 20 Jun 2018 23:31:43 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 22D61797EA; Wed, 20 Jun 2018 23:31:43 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x236.google.com with SMTP id t5-v6so1309976ioa.8; Wed, 20 Jun 2018 16:31:43 -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=22Gz3KOK4Qd2MwplLS8E5n8TQgqwP9U9ip6VVgdeI7w=; b=PXJ4Is2tOFfANLrpn2X9v5s0OJvbFhqjbEBcWI7h8x6sVq25JyOekTg/0avFyNGvsY 5BMFBIS3oovcFqKsG1LT6cI1l5O4xpqjAdANgmjrKkB/RPO4Nbx3F0JlXuhV+5m56zso QYtaofP3hUk54Ahtiz2ifC4fLBT29FvK1z2MpauiMP8lFbIpcJrE5kFf6Q9qhc27gV6c Qv2+lgsnQ9vbVAZn1o1iyqgF6oCzMKWSMeLnxESIAOgK6e5mJawTYUFyVCckMgRM6+HV +T0k5/eoN2szJs24EMKLSpI/Wl2GoEPNAga3G0zVbl3TXmpm5vpIFT+EXgWE5QZLIPrc ENqA== 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=22Gz3KOK4Qd2MwplLS8E5n8TQgqwP9U9ip6VVgdeI7w=; b=CQMhgdIhrbKyE20vxr4AaYSsYUMTgPNLZUbiC0erG6P2mTvfJEs4HE/hREMnwg1Eg9 /X+NWwD+0EViZ9XKA/dtqvI8JprI7leEVTFTfc9sVK4dZjo8ABDV6KPs32WJkYl4rhOs Cx5lF2biwkOQMKiD91j1LErjf0uJZdeUYWid4kSrEuia4cd7CbJxa6m1o74280DiESYo Q2F/YE92dx6ODIN+onZ2biRngliX0rgLvYF8f40Ojm1hr/QFSe6AowJMOvtZ0xAxeOHB A4UDUmUIRWdR/ToEe/Qq5UzAuaFWa7P6bbdVbc5EwmjTFEzxFzjhL4PwFfSxPNy0IkRi UtYA== X-Gm-Message-State: APt69E0XRbhamRByrLViq7b3SGiFiWrlY//7vW2oGlN61i7rD+od8VD6 dfNsEK1jcNlntOjRl2bX6nW8mYEEtW6cOqRB4zQtzw== X-Google-Smtp-Source: ADUXVKKmbpdqTfiPl1TnptPJY0mVR2SDPhUYuE2yk0rJjicS3GdvO83xkpLs3BnZ8wCUhp5pwHOUVtfUXzC7e2nnnUQ= X-Received: by 2002:a6b:2cd:: with SMTP id 196-v6mr18280983ioc.294.1529537502390; Wed, 20 Jun 2018 16:31:42 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 2002:a6b:84e1:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 16:31:21 -0700 (PDT) In-Reply-To: <20180620222527.vkd5fm3ksd5j6yux@mutt-hbsd> References: <20180620222527.vkd5fm3ksd5j6yux@mutt-hbsd> From: Ed Maste Date: Wed, 20 Jun 2018 19:31:21 -0400 X-Google-Sender-Auth: jETrYq669ZpCvMJagZ6JymYAIm0 Message-ID: Subject: Re: Tool Chain Migration: objdump users, please test llvm-objdump To: Shawn Webb Cc: FreeBSD Current , "freebsd-toolchain@FreeBSD.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 20 Jun 2018 23:31:43 -0000 On 20 June 2018 at 18:25, Shawn Webb wrote: > > Would you like me to quantify the compilation breakages due to the > full llvm toolchain switch? If so, I can do that after July 12th. Thanks Shawn, right now I'm interested specifically in llvm-objdump, with the goal of sorting it out in advance of FreeBSD 12. I think it's a worthwhile endeavour to quantify the breakage from using all of the LLVM tools though, and if you're able to triage the issues and submit LLVM, FreeBSD, or upstream port issues as appropriate that would be much appreciated. (It's just not yet on the critical path for me.) From owner-freebsd-current@freebsd.org Wed Jun 20 23:41:22 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C6DDF10133FA for ; Wed, 20 Jun 2018 23:41:21 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 37E2879D50 for ; Wed, 20 Jun 2018 23:41:21 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-wm0-x236.google.com with SMTP id 69-v6so2449171wmf.3 for ; Wed, 20 Jun 2018 16:41:21 -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=2yZzOTVIGoQsCjkTWL7uLSmBn8ui0zidYHUxWhmN6qk=; b=GG2FPem0UeIj8iy9nmCasIok5ytmY51JrG3L9JGDHILEIlWCKzE+MwLUHWH+C5RH0n 4W26fb9/ci+hM4i1j+NUseXJWqQE5RJb0SMWXOAITQd/mMO5HD5HWyaObkAGILxirakG EIAhw8Qr9VG8ni6cfdvFoRiUW82oN++DBT0UgK5sr27jssONmYwo1LlFhv1cmJ0SuDpv dwk7f1kHvDVeIMo08iTZCXQUrAKRyLB8xw3m1ukeHFLAyb1GbpTFjZjp6ygKTB7HifCX cKUzlqFvhfWPtuuUV/IB4GVG1T2U2QVy2wMeM9XuPjJfDbpi5puLghqeE2hfMs9+zBwo a1cw== 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=2yZzOTVIGoQsCjkTWL7uLSmBn8ui0zidYHUxWhmN6qk=; b=PTwltbCAbQXWnlWVGuDqoaQEETePjuEjBxA4sEox3FZwTmg0oz4eShi4YZPxldGOS8 jlLQB9ue/D3PVdtbjVArFyLuOPThBa0wVNAK2o/SBbqMwd80KiSlJEXdLK8C/Ppv044E ntMLiq/kgMDVaemaPgtFGCOKVlPReJ2XfB1OXMWAvZRpy65B9+1gnYrusruYZlIGvHGs ARCjJlAoOT2Vna0l2Zvi/lWbVC9XWSVvAaZg2eXnsTJTNwIiHFgIcptXTyMWQXaBLITp pAIPMDeOMeyIsGO1WHa9Fa94iG5nKItCcpxjEa/P4eCum7Ni8XJsU/CIGyUXaiAMidlj yqdg== X-Gm-Message-State: APt69E0g+zLJbCiIpMEVHxZ11YJ4kRjDF1RReTaTleGdd0XhB3tcKo3B tayma7zXiI0L3XRXz7b80gKKFw== X-Google-Smtp-Source: ADUXVKK+T1R1JzE4JolU8hWTL6JSRh1RAuyOLgYN74JcSKPV2u2rgFzgm+R1dkfyFmXRl4BsV4fI7A== X-Received: by 2002:a50:f5d7:: with SMTP id x23-v6mr19354290edm.132.1529538079379; Wed, 20 Jun 2018 16:41:19 -0700 (PDT) Received: from mutt-hbsd (tor-exit-4.all.de. [212.21.66.6]) by smtp.gmail.com with ESMTPSA id d11-v6sm1555446edo.63.2018.06.20.16.41.16 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 20 Jun 2018 16:41:18 -0700 (PDT) Date: Wed, 20 Jun 2018 19:40:47 -0400 From: Shawn Webb To: Ed Maste Cc: FreeBSD Current , "freebsd-toolchain@FreeBSD.org" Subject: Re: Tool Chain Migration: objdump users, please test llvm-objdump Message-ID: <20180620234047.s5m267t3s3ys66wh@mutt-hbsd> References: <20180620222527.vkd5fm3ksd5j6yux@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zyoys46m3tkhag4e" Content-Disposition: inline In-Reply-To: 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/20180323 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 20 Jun 2018 23:41:22 -0000 --zyoys46m3tkhag4e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 20, 2018 at 07:31:21PM -0400, Ed Maste wrote: > On 20 June 2018 at 18:25, Shawn Webb wrote: > > > > Would you like me to quantify the compilation breakages due to the > > full llvm toolchain switch? If so, I can do that after July 12th. >=20 > Thanks Shawn, right now I'm interested specifically in llvm-objdump, > with the goal of sorting it out in advance of FreeBSD 12. >=20 > I think it's a worthwhile endeavour to quantify the breakage from > using all of the LLVM tools though, and if you're able to triage the > issues and submit LLVM, FreeBSD, or upstream port issues as > appropriate that would be much appreciated. (It's just not yet on the > critical path for me.) Sounds good. Can you ping me again after July 12th? Also, if Tor is available for you, the amd64 Poudriere web UI is accessible via a Tor v3 Onion Service: http://3jkjhrvkdbdkqisnwhdpe4afh2j2g3suhsfcewiemsyk5ecd6gadmxyd.onion:8081/= index.html Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal: +1 443-546-8752 Tor+XMPP+OTR: lattera@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --zyoys46m3tkhag4e Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlsq5foACgkQaoRlj1JF bu4XUBAAxa66VitVI6ms0mHy22WWeQEyOBoxORP9CraJGRMa4LF/zWE8TgHazjvT iKY7UGBKa6azEHbYOI6MvgoF/vXufh+/Gwiid5J0Lcp3dzbiLDEPxsygvczITzRp PApI8dJnQUsK8/9WmqpcbzrMC3y5B6xoPcomTjeSkpTDnC1zMw08kgZFshS+8Kt+ 5iAeOx7P0NjXJAB2eqD/qCCMlIx6OEnJmkOjgw3EPiwSexxUijF1vqiEcR5Px5XY y1GjfZow3eOrP8cfxr1d4ZveqQbZiLGdLyRZM9b4iJTVG4o0m+FRM/MVOnaZfjSV 4mLHZQ2b79CZtNX4D6n+MFY0q5FS1okd4BoNPolXAt5ZJA/hTGYLQ+b7NMJZs1x9 chRmWt8cEQh38J+oQHRUkOpE7Fftk00WT3kTFXWOia6cdPmZ779gLRt3EH/2/Ou/ zqHQP24sQb7/nSmj39YbJS3/95Jtee17QRF7/KwBMqOBNGXIHjioPxUhD+00I2PX L8OZTOJC1MCl2u85J/JBoLr9OtFYVm5gKov8gq09tp1M1mom73g0j71uTPkkxkR5 iuoatU2oVBEIVxBra7R5rlWe+GgFz9bhVbynTI08Bwfih+tYVpmVVH5QAnXevJD4 RJbtEJCVJ9zfzOXozcjM1H1UZfaLYAg5TXJ8O+jwkB6q6AyfSMc= =GPcL -----END PGP SIGNATURE----- --zyoys46m3tkhag4e-- From owner-freebsd-current@freebsd.org Thu Jun 21 00:07:38 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4EB7510149A9; Thu, 21 Jun 2018 00:07:38 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CCD637AC25; Thu, 21 Jun 2018 00:07:37 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 9D85F1B55D; Thu, 21 Jun 2018 00:07:37 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id A64BA1F46; Thu, 21 Jun 2018 00:07:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id XfPwaGm7Vynk; Thu, 21 Jun 2018 00:07:33 +0000 (UTC) Subject: Re: [CFT] tinderbox/universe building clang once DKIM-Filter: OpenDKIM Filter v2.10.3 mail.xzibition.com 435E41F41 From: Bryan Drewery To: FreeBSD Current Cc: FreeBSD Toolchain References: <7dc2e7de-410e-bf24-2b3c-a91e4a97e4f2@FreeBSD.org> Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Autocrypt: addr=bdrewery@FreeBSD.org; prefer-encrypt=mutual; keydata= xsBNBFJphmsBCADiFgmS4bIzwZijrS31SjEMzg+n5zNellgM+HkShwehpqCiyhXdWrvH6dTZ a6u50pbUIX7doTR7W7PQHCjCTqtpwvcj0eulZva+iHFp+XrbgSFHn+VVXgkYP2MFySyZRFab D2qqzJBEJofhpv4HvY6uQI5K99pMqKr1Z/lHqsijYYu4RH2OfwB5PinId7xeldzWEonVoCr+ rfxzO/UrgA6v/3layGZcKNHFjmc3NqoN1DXtdaEHqtjIozzbndVkH6lkFvIpIrI6i5ox8pwp VxsxLCr/4Musd5CWgHiet5kSw2SzNeA8FbxdLYCpXNVu+uBACEbCUP+CSNy3NVfEUxsBABEB AAHNJEJyeWFuIERyZXdlcnkgPGJkcmV3ZXJ5QEZyZWVCU0Qub3JnPsLAgAQTAQoAKgIbAwUL CQgHAwUVCgkICwUWAwIBAAIeAQIXgAIZAQUCWujOIgUJCmB7NwAKCRA113G7bkaXz/xpB/9b /UWIPbieY1IeIuHF2pyYPE7Hytkh3HVsxMA0F5Ma2AYQsXZZeKNKWrF7RPyDyDwUklLHJkhm k3EfClBbHxf08kMIm1vWCJRtgxic9knY/bzYGiWMpHjg3cSd1XfrYH1autYqTZAjDwIkgOjU dR//Tbn4V36sY7y2jz+kdMVWvK53U32aZqiwBbCn4DPe1wSZcUs17mV/0uZdIoGdj74B1orN A/0py5vHYo6HcbBNoaR8pKRLf5VZNRsxqGIMhTucx4SJWcHpuRBWYyvJSFzwvxdK4ZD4Yqoc kFGPVtOXktVMai9exrLvP3G77fKMu8DI6j4QRU4wCesnHuIfRPFuzsBNBFJphmsBCACiVFPf kNfaFtUSuY0395ueo/rMyHPGPQ2iwvERFCpeFGSQSgagpenNHLpFQKTg/dl6FOoST5tqyxMq fyHGHDzzU51bvA/IfaGoNi/BIhTe/toZNMRvpcI3PLjiGcnJnuwCCbAVOAGdb+t5cZtpNdOI cKYmrYG3u9RiBpe6dTF+qLrD/8Bs1wjhduQ8fcNNgnkXu8xDH4ZxY0lIc3QgvYWp9vimlQe6 iKjUd2/DX28ETZcD5h6pYV331KMPTrEI0p0yvFijUZce8c1XHFyL1j9sBAha5qpszJl6Uq5i LolhKRcGfcdmtD72vHQjUYglUyudSJUVyo2gMYjdbiFKzJulABEBAAHCwGUEGAEKAA8CGwwF AlrozigFCQpgez0ACgkQNddxu25Gl8+m5Af/R3VEdxNMAcDIes9ADhQyofj20SPV3eCJ3HYR OebTSuNdOudGt4AAyA8Ks94u9hiIp5IGsc6RDsT9W7O2vgXhd6eV3eiY5Oif5xLIYrIDVu1Y 1GyRxRrPEn/QOqDN6uFZCPwK1aOapGcYCrO9lB0gMuTVfgHanU61rgC9tMX0OoAOyRd+V3/M 8lDNhjJdF/IpO3SdYzKfkwduy4qamw4Gphcx/RfYQvYLq/eDkP8d50PphWdboqWBwNRHayro W/07OGzfxM5fJ5mBsXPQcO2QcRjkyHf6xCM6Hi1qQL4OnXMNE/ZTX0lnOj1/pH93TlzSHZMP TaiiA/MBD3vGsXBmBg== Organization: FreeBSD Message-ID: <77cab326-1cd9-4f25-4e8f-22f1038161b7@FreeBSD.org> Date: Wed, 20 Jun 2018 17:07:31 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <7dc2e7de-410e-bf24-2b3c-a91e4a97e4f2@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3vGfZViDBlyLXtOnkKeNrd68sZh0JTgNH" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 21 Jun 2018 00:07:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3vGfZViDBlyLXtOnkKeNrd68sZh0JTgNH Content-Type: multipart/mixed; boundary="0XBdC9G0rSJTDcaCDGKClfiiUKtAo4gOY"; protected-headers="v1" From: Bryan Drewery To: FreeBSD Current Cc: FreeBSD Toolchain Message-ID: <77cab326-1cd9-4f25-4e8f-22f1038161b7@FreeBSD.org> Subject: Re: [CFT] tinderbox/universe building clang once References: <7dc2e7de-410e-bf24-2b3c-a91e4a97e4f2@FreeBSD.org> In-Reply-To: <7dc2e7de-410e-bf24-2b3c-a91e4a97e4f2@FreeBSD.org> --0XBdC9G0rSJTDcaCDGKClfiiUKtAo4gOY Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/20/2018 2:08 PM, Bryan Drewery wrote: > https://people.freebsd.org/~bdrewery/patches/universe-one-clang.diff >=20 > This will build clang once if any of the targets specified (or > defaulted) require bootstrapping clang. >=20 The longterm plan does include making 'TARGET=3Darch1 make buildworld' an= d 'TARGET=3Darch2 make buildworld' both use the same compiler and various other build tools. For now this patch only addresses tinderbox/universe so we can have some progress. I had another implementation that covered the buildworld case but it was getting too complex and causing conflicts with other people's work. I'll improve this over time. > It probably has some issues with LLD_BOOTSTRAP in some cases. It could > be improved more in the future for reusing more of the tools built but = I > think this is good enough for now as it saves the majority of the time > in the bootstrap phases on clang. >=20 > This won't work for GCC unless it learns convenient -target support. > Its needed --sysroot support was also broken until some recent work fro= m > John Baldwin but I'm not sure if that has been committed yet. >=20 > Also FYI WITH_SYSTEM_LINKER support is now in to avoid building libclan= g > for lld on archs that have LLD_BOOTSTRAP set. >=20 > I'm putting this out for testing since tinderbox/universe take so long > and I can't possibly test all workflows with it myself. >=20 --=20 Regards, Bryan Drewery --0XBdC9G0rSJTDcaCDGKClfiiUKtAo4gOY-- --3vGfZViDBlyLXtOnkKeNrd68sZh0JTgNH 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 iQEcBAEBAgAGBQJbKuxDAAoJEDXXcbtuRpfPtDIIANgXKTqreWu6Fsfb0wDNvVoL ox3AOlHi3U3KO4p+PqbLJXm0rbftg4KClmsy86n8+bbz4G9wxGrHssNN/2Czko+d 2m1VmRqN6dp+A8jlU/N/5FMMSMh7XQt4aEmGV6l+25ZjPHbG9sUGnXqH+s8dhtNW cXAYNfn5nbwILjXRu4lrbCyWRncHgF1vGGsALHCE0Vcs8CUvNzpTDlXgR4s0TkyL UChJCKA7HpdrFc7n+NUWjTLIf250ZYbac98vFVLqlRqWxRgnsoKi+LkkRQOvTJYR 1vlkJAXj4jtJeJMQaez/eTgg5oWra6jvHWo2irXtjwrdhqFSp1v6ubPZadGsyJU= =Z8vq -----END PGP SIGNATURE----- --3vGfZViDBlyLXtOnkKeNrd68sZh0JTgNH-- From owner-freebsd-current@freebsd.org Thu Jun 21 03:37:24 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A5F8B10245FD; Thu, 21 Jun 2018 03:37:24 +0000 (UTC) (envelope-from arichardson.kde@gmail.com) Received: from mail-yw0-f179.google.com (mail-yw0-f179.google.com [209.85.161.179]) (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 460E584DAF; Thu, 21 Jun 2018 03:37:24 +0000 (UTC) (envelope-from arichardson.kde@gmail.com) Received: by mail-yw0-f179.google.com with SMTP id t198-v6so640571ywc.3; Wed, 20 Jun 2018 20:37:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4LUYW8vDYEdqRIQux+5ZhvpZPix7OEYYFWCORerQ+4I=; b=uJufNGZj7lnyWRvTFj80pr2N4K/Os30+8KdL67Skw/ZetBLVomwN1Y32ANVHtj5PS0 loJTX8oa2FCI4f8gKANxnEdLv5OEo5o7CSHmw9grXDBZ64x+SD5NRufYNL2O3iMavrj3 pJQlgtuPHWShEclFnWBMlEETD7VZmhfgdribDYTfYo1/HK6uSvPUvw6eZqld2lM4874Q 1m+d5ANG+eqN9waPhoo/Ev2KxmxmgNdE6Kf/JhTbc4/t6DxMWl6xrPsk+2ETYxRw4sYk o7txf9090kgWuPNTweeUToVJ/H5HIkO9aKoCUxgtxwG/8U7yJxsJkPquhHyO3gjEybF4 X2ng== X-Gm-Message-State: APt69E2cBI50HIUXtZDBmFX3KLlticJuY26p0B8h9QoyBTI71NK26tx9 jb8/TzUtGsJ/2zCp6Ly2YBVMpBLOlMrcyQ== X-Google-Smtp-Source: ADUXVKLFhNtO8zoxm+x5S3Jwimk88UDVF7nGYqXTlfnYnaZ6mBuE1IgOymn7enBjgvF30+Yv5GWC9Q== X-Received: by 2002:a81:6dc5:: with SMTP id i188-v6mr10890217ywc.385.1529530014025; Wed, 20 Jun 2018 14:26:54 -0700 (PDT) Received: from mail-yb0-f171.google.com (mail-yb0-f171.google.com. [209.85.213.171]) by smtp.gmail.com with ESMTPSA id f131-v6sm1220394ywh.18.2018.06.20.14.26.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jun 2018 14:26:53 -0700 (PDT) Received: by mail-yb0-f171.google.com with SMTP id x6-v6so392051ybl.12; Wed, 20 Jun 2018 14:26:53 -0700 (PDT) X-Received: by 2002:a25:a443:: with SMTP id f61-v6mr11875773ybi.38.1529530013081; Wed, 20 Jun 2018 14:26:53 -0700 (PDT) MIME-Version: 1.0 References: <20180620155022.GA92001@spindle.one-eyed-alien.net> In-Reply-To: <20180620155022.GA92001@spindle.one-eyed-alien.net> From: Alexander Richardson Date: Wed, 20 Jun 2018 22:26:41 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Tool Chain Migration: objdump users, please test llvm-objdump To: Brooks Davis Cc: Ed Maste , FreeBSD Current , "freebsd-toolchain@FreeBSD.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 21 Jun 2018 03:37:25 -0000 On Wed, 20 Jun 2018 at 16:50 Brooks Davis wrote: > On Wed, Jun 20, 2018 at 10:46:46AM -0400, Ed Maste wrote: > > Work is in progress to migrate fully to modern and permissively > > licensed components for the tool chain. This includes moving away from > > the three obsolete binutils components that are still in the base > > system (as, ld, objdump). objdump is a tool to report information > > about binary objects (such as headers, symbols, etc.), is not required > > as a build tool, and in any case many uses of objdump are better > > served by readelf. > > > > For FreeBSD 12 I intend to remove GNU objdump 2.17.50. PR 229046[1] is > > open to track tasks related to its removal, and users who need GNU > > objdump can install an up-to-date version from the ports tree or the > > binutils package. > > > > That said, llvm includes a somewhat equivalent llvm-objdump, and it is > > built by default in FreeBSD now. If llvm-objdump's command line option > > support and output format is "close enough" to GNU objdump for most > > users we may decide to install it as /usr/bin/objdump. Therefore, I > > would like to ask users of GNU objdump in FreeBSD to give llvm-objdump > > a try. Please let me know if it works for your uses, or describe > > deficiencies that you found. > > I think we've changed our flag us in CheriBSD to accommodate llvm-objdump > so at least a few months ago flag compatibility was poor. The output is > different, but fine for my uses (producing human readable assembly > output). > > When I made the change to use llvm-objdump in CheriBSD I had to change the objdump flags from -xrsSd to -r -s -p -S -d -h -l -t. This is because llvm-objdump doesn't support the -x option and doesn't accept joined single-character options. I've been meaning to submit a patch upstream for -x but haven't got around to it yet. Otherwise the only noticeable change was that creating a full dump of any binary is MUCH faster. Alex From owner-freebsd-current@freebsd.org Thu Jun 21 01:56:17 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5756C101C38A for ; Thu, 21 Jun 2018 01:56:17 +0000 (UTC) (envelope-from kiri@kx.openedu.org) Received: from kx.openedu.org (flets-sg1027.kamome.or.jp [202.216.24.27]) (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 9F92180094 for ; Thu, 21 Jun 2018 01:56:15 +0000 (UTC) (envelope-from kiri@kx.openedu.org) Received: from kx.openedu.org (kx.openedu.org [202.216.24.27]) by kx.openedu.org (8.14.5/8.14.5) with ESMTP id w5L1a5Nv074194; Thu, 21 Jun 2018 10:36:05 +0900 (JST) (envelope-from kiri@kx.openedu.org) Message-Id: <201806210136.w5L1a5Nv074194@kx.openedu.org> Date: Thu, 21 Jun 2018 10:36:05 +0900 From: KIRIYAMA Kazuhiko To: FreeBSD Current Cc: kiri@kx.openedu.org Subject: ZFS: I/O error - blocks larger than 16777216 are not supported User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.6 MULE XEmacs/21.4 (patch 22) (Instant Classic) (amd64--freebsd) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 21 Jun 2018 01:56:17 -0000 Hi all, I've been reported ZFS boot disable problem [1], and found that this issue occers form RAID configuration [2]. So I rebuit with RAID5 and re-installed 12.0-CURRENT (r333982). But failed to boot with: ZFS: i/o error - all block copies unavailable ZFS: can't read MOS of pool zroot gptzfsboot: failed to mount default pool zroot FreeBSD/x86 boot ZFS: I/O error - blocks larger than 16777216 are not supported ZFS: can't find dataset u Default: zroot/<0x0>: In this case, the reason is "blocks larger than 16777216 are not supported" and I guess this means datasets that have recordsize greater than 8GB is NOT supported by the FreeBSD boot loader(zpool-features(7)). Is that true ? My zpool featues are as follows: # kldload zfs # zpool import pool: zroot id: 13407092850382881815 state: ONLINE status: The pool was last accessed by another system. action: The pool can be imported using its name or numeric identifier and the '-f' flag. see: http://illumos.org/msg/ZFS-8000-EY config: zroot ONLINE mfid0p3 ONLINE # zpool import -fR /mnt zroot # zpool list NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT zroot 19.9T 129G 19.7T - 0% 0% 1.00x ONLINE /mnt # zpool get all zroot NAME PROPERTY VALUE SOURCE zroot size 19.9T - zroot capacity 0% - zroot altroot /mnt local zroot health ONLINE - zroot guid 13407092850382881815 default zroot version - default zroot bootfs zroot/ROOT/default local zroot delegation on default zroot autoreplace off default zroot cachefile none local zroot failmode wait default zroot listsnapshots off default zroot autoexpand off default zroot dedupditto 0 default zroot dedupratio 1.00x - zroot free 19.7T - zroot allocated 129G - zroot readonly off - zroot comment - default zroot expandsize - - zroot freeing 0 default zroot fragmentation 0% - zroot leaked 0 default zroot feature@async_destroy enabled local zroot feature@empty_bpobj active local zroot feature@lz4_compress active local zroot feature@multi_vdev_crash_dump enabled local zroot feature@spacemap_histogram active local zroot feature@enabled_txg active local zroot feature@hole_birth active local zroot feature@extensible_dataset enabled local zroot feature@embedded_data active local zroot feature@bookmarks enabled local zroot feature@filesystem_limits enabled local zroot feature@large_blocks enabled local zroot feature@sha512 enabled local zroot feature@skein enabled local zroot unsupported@com.delphix:device_removal inactive local zroot unsupported@com.delphix:obsolete_counts inactive local zroot unsupported@com.delphix:zpool_checkpoint inactive local # Regards [1] https://lists.freebsd.org/pipermail/freebsd-current/2018-March/068886.html [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=151910 --- KIRIYAMA Kazuhiko From owner-freebsd-current@freebsd.org Thu Jun 21 03:34:54 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 73C0B10243F7 for ; Thu, 21 Jun 2018 03:34:54 +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 12DE584CB7 for ; Thu, 21 Jun 2018 03:34:54 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 45E6D1DF9F for ; Thu, 21 Jun 2018 03:34:53 +0000 (UTC) Subject: Re: ZFS: I/O error - blocks larger than 16777216 are not supported To: freebsd-current@freebsd.org References: <201806210136.w5L1a5Nv074194@kx.openedu.org> From: Allan Jude Openpgp: preference=signencrypt Autocrypt: addr=allanjude@freebsd.org; prefer-encrypt=mutual; keydata= xsFNBFVwZcYBEADwrZDH0xe0ZVjc9ORCc6PcBLwS/RTXA6NkvpD6ea02pZ8lPOVgteuuugFc D34LdDbiWr+479vfrKBh+Y38GL0oZ0/13j10tIlDMHSa5BU0y6ACtnhupFvVlQ57+XaJAb/q 7qkfSiuxVwQ3FY3PL3cl1RrIP5eGHLA9hu4eVbu+FOX/q/XVKz49HaeIaxzo2Q54572VzIo6 C28McX9m65UL5fXMUGJDDLCItLmehZlHsQQ+uBxvODLFpVV2lUgDR/0rDa0B9zHZX8jY8qQ7 ZdCSy7CwClXI054CkXZCaBzgxYh/CotdI8ezmaw7NLs5vWNTxaDEFXaFMQtMVhvqQBpHkfOD 7rjjOmFw00nJL4FuPE5Yut0CPyx8vLjVmNJSt/Y8WxxmhutsqJYFgYfWl/vaWkrFLur/Zcmz IklwLw35HLsCZytCN5A3rGKdRbQjD6QPXOTJu0JPrJF6t2xFkWAT7oxnSV0ELhl2g+JfMMz2 Z1PDmS3NRnyEdqEm7NoRGXJJ7bgxDbN+9SXTyOletqGNXj/bSrBvhvZ0RQrzdHAPwQUfVSU2 qBhQEi2apSZstgVNMan0GUPqCdbE2zpysg+zT7Yhvf9EUQbzPL4LpdK1llT9fZbrdMzEXvEF oSvwJFdV3sqKmZc7b+E3PuxK6GTsKqaukd/3Cj8aLHG1T1im1QARAQABzSJBbGxhbiBKdWRl IDxhbGxhbmp1ZGVAZnJlZWJzZC5vcmc+wsF/BBMBAgApBQJVcGXGAhsjBQkSzAMABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AACgkQGZU1PhKYC34Muw/+JOKpSfhhysWFYiRXynGRDe07 Z6pVsn7DzrPUMRNZfHu8Uujmmy3p2nx9FelIY9yjd2UKHhug+whM54MiIFs90eCRVa4XEsPR 4FFAm0DAWrrb7qhZFcE/GhHdRWpZ341WAElWf6Puj2devtRjfYbikvj5+1V1QmDbju7cEw5D mEET44pTuD2VMRJpu2yZZzkM0i+wKFuPxlhqreufA1VNkZXI/rIfkYWK+nkXd9Efw3YdCyCQ zUgTUCb88ttSqcyhik/li1CDbXBpkzDCKI6I/8fAb7jjOC9LAtrZJrdgONywcVFoyK9ZN7EN AVA+xvYCmuYhR/3zHWH1g4hAm1v1+gIsufhajhfo8/wY1SetlzPaYkSkVQLqD8T6zZyhf+AN bC7ci44UsiKGAplB3phAXrtSPUEqM86kbnHg3fSx37kWKUiYNOnx4AC2VXvEiKsOBlpyt3dw WQbOtOYM+vkfbBwDtoGOOPYAKxc4LOIt9r+J8aD+gTooi9Eo5tvphATf9WkCpl9+aaGbSixB tUpvQMRnSMqTqq4Z7DeiG6VMRQIjsXDSLJEUqcfhnLFo0Ko/RiaHd5xyAQ4DhQ9QpkyQjjNf /3f/dYG7JAtoD30txaQ5V8uHrz210/77DRRX+HJjEj6xCxWUGvQgvEZf5XXyxeePvqZ+zQyT DX61bYw6w6bOwU0EVXBlxgEQAMy7YVnCCLN4oAOBVLZ5nUbVPvpUhsdA94/0/P+uqCIh28Cz ar56OCX0X19N/nAWecxL4H32zFbIRyDB2V/MEh4p9Qvyu/j4i1r3Ex5GhOT2hnit43Ng46z5 29Es4TijrHJP4/l/rB2VOqMKBS7Cq8zk1cWqaI9XZ59imxDNjtLLPPM+zQ1yE3OAMb475QwN UgWxTMw8rkA7CEaqeIn4sqpTSD5C7kT1Bh26+rbgJDZ77D6Uv1LaCZZOaW52okW3bFbdozV8 yM2u+xz2Qs8bHz67p+s+BlygryiOyYytpkiK6Iy4N7FTolyj5EIwCuqzfk0SaRHeOKX2ZRjC qatkgoD/t13PNT38V9tw3qZVOJDS0W6WM8VSg+F+bkM9LgJ8CmKV+Hj0k3pfGfYPOZJ/v18i +SmZmL/Uw2RghnwDWGAsPCKu4uZR777iw7n9Io6Vfxndw2dcS0e9klvFYoaGS6H2F13Asygr WBzFNGFQscN4mUW+ZYBzpTOcHkdT7w8WS55BmXYLna+dYer9/HaAuUrONjujukN4SPS1fMJ2 /CS/idAUKyyVVX5vozoNK2JVC1h1zUAVsdnmhEzNPsvBoqcVNfyqBFROEVLIPwq+lQMGNVjH ekLTKRWf59MEhUC2ztjSKkGmwdg73d6xSXMuq45EgIJV2wPvOgWQonoHH/kxABEBAAHCwWUE GAECAA8FAlVwZcYCGwwFCRLMAwAACgkQGZU1PhKYC34w5A//YViBtZyDV5O+SJT9FFO3lb9x Zdxf0trA3ooCt7gdBkdnBM6T5EmjgVZ3KYYyFfwXZVkteuCCycMF/zVw5eE9FL1+zz9gg663 nY9q2F77TZTKXVWOLlOV2bY+xaK94U4ytogOGhh9b4UnQ/Ct3+6aviCF78Go608BXbmF/GVT 7uhddemk7ItxM1gE5Hscx3saxGKlayaOsdPKeGTVJCDEtHDuOc7/+jGh5Zxpk/Hpi+DUt1ot 8e6hPYLIQa4uVx4f1xxxV858PQ7QysSLr9pTV7FAQ18JclCaMc7JWIa3homZQL/MNKOfST0S 2e+msuRwQo7AnnfFKBUtb02KwpA4GhWryhkjUh/kbVc1wmGxaU3DgXYQ5GV5+Zf4kk/wqr/7 KG0dkTz6NLCVLyDlmAzuFhf66DJ3zzz4yIo3pbDYi3HB/BwJXVSKB3Ko0oUo+6/qMrOIS02L s++QE/z7K12CCcs7WwOjfCYHK7VtE0Sr/PfybBdTbuDncOuAyAIeIKxdI2nmQHzl035hhvQX s4CSghsP319jAOQiIolCeSbTMD4QWMK8RL/Pe1FI1jC3Nw9s+jq8Dudtbcj2UwAP/STUEbJ9 5rznzuuhPjE0e++EU/RpWmcaIMK/z1zZDMN+ce2v1qzgV936ZhJ3iaVzyqbEE81gDxg3P+IM kiYh4ZtPB4Q= Message-ID: <21493592-4eb2-59c5-1b0d-e1d08217a96b@freebsd.org> Date: Wed, 20 Jun 2018 23:34:48 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <201806210136.w5L1a5Nv074194@kx.openedu.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2VVltOwtGC4x6DHiLhWFZrrP58R52dG9O" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 21 Jun 2018 03:34:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2VVltOwtGC4x6DHiLhWFZrrP58R52dG9O Content-Type: multipart/mixed; boundary="LfiZ2oxaAjDIYUCN76fSQWgObjaAaXzMN"; protected-headers="v1" From: Allan Jude To: freebsd-current@freebsd.org Message-ID: <21493592-4eb2-59c5-1b0d-e1d08217a96b@freebsd.org> Subject: Re: ZFS: I/O error - blocks larger than 16777216 are not supported References: <201806210136.w5L1a5Nv074194@kx.openedu.org> In-Reply-To: <201806210136.w5L1a5Nv074194@kx.openedu.org> --LfiZ2oxaAjDIYUCN76fSQWgObjaAaXzMN Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2018-06-20 21:36, KIRIYAMA Kazuhiko wrote: > Hi all, >=20 > I've been reported ZFS boot disable problem [1], and found > that this issue occers form RAID configuration [2]. So I > rebuit with RAID5 and re-installed 12.0-CURRENT > (r333982). But failed to boot with: >=20 > ZFS: i/o error - all block copies unavailable > ZFS: can't read MOS of pool zroot > gptzfsboot: failed to mount default pool zroot >=20 > FreeBSD/x86 boot > ZFS: I/O error - blocks larger than 16777216 are not supported > ZFS: can't find dataset u > Default: zroot/<0x0>: >=20 > In this case, the reason is "blocks larger than 16777216 are > not supported" and I guess this means datasets that have > recordsize greater than 8GB is NOT supported by the > FreeBSD boot loader(zpool-features(7)). Is that true ? >=20 > My zpool featues are as follows: >=20 > # kldload zfs > # zpool import=20 > pool: zroot > id: 13407092850382881815 > state: ONLINE > status: The pool was last accessed by another system. > action: The pool can be imported using its name or numeric identifier = and > the '-f' flag. > see: http://illumos.org/msg/ZFS-8000-EY > config: >=20 > zroot ONLINE > mfid0p3 ONLINE > # zpool import -fR /mnt zroot > # zpool list > NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTR= OOT > zroot 19.9T 129G 19.7T - 0% 0% 1.00x ONLINE /mnt= > # zpool get all zroot > NAME PROPERTY VALUE = SOURCE > zroot size 19.9T = - > zroot capacity 0% = - > zroot altroot /mnt = local > zroot health ONLINE = - > zroot guid 13407092850382881815 = default > zroot version - = default > zroot bootfs zroot/ROOT/default = local > zroot delegation on = default > zroot autoreplace off = default > zroot cachefile none = local > zroot failmode wait = default > zroot listsnapshots off = default > zroot autoexpand off = default > zroot dedupditto 0 = default > zroot dedupratio 1.00x = - > zroot free 19.7T = - > zroot allocated 129G = - > zroot readonly off = - > zroot comment - = default > zroot expandsize - = - > zroot freeing 0 = default > zroot fragmentation 0% = - > zroot leaked 0 = default > zroot feature@async_destroy enabled = local > zroot feature@empty_bpobj active = local > zroot feature@lz4_compress active = local > zroot feature@multi_vdev_crash_dump enabled = local > zroot feature@spacemap_histogram active = local > zroot feature@enabled_txg active = local > zroot feature@hole_birth active = local > zroot feature@extensible_dataset enabled = local > zroot feature@embedded_data active = local > zroot feature@bookmarks enabled = local > zroot feature@filesystem_limits enabled = local > zroot feature@large_blocks enabled = local > zroot feature@sha512 enabled = local > zroot feature@skein enabled = local > zroot unsupported@com.delphix:device_removal inactive = local > zroot unsupported@com.delphix:obsolete_counts inactive = local > zroot unsupported@com.delphix:zpool_checkpoint inactive = local > #=20 >=20 > Regards >=20 > [1] https://lists.freebsd.org/pipermail/freebsd-current/2018-March/0688= 86.html > [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D151910 >=20 > --- > KIRIYAMA Kazuhiko > _______________________________________________ > 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 I am guessing it means something is corrupt, as 16MB is the maximum size of a record in ZFS. Also, the 'large_blocks' feature is 'enabled', not 'active', so this suggest you do not have any records larger than 128kb on your pool. --=20 Allan Jude --LfiZ2oxaAjDIYUCN76fSQWgObjaAaXzMN-- --2VVltOwtGC4x6DHiLhWFZrrP58R52dG9O 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) iQIcBAEBAgAGBQJbKxzcAAoJEBmVNT4SmAt+f3AP/1hrEuTo63Qp9w88BYokaIdJ cd2WFdZUtMO/M6qo3CpReWpmHdNZ78Vt06d+t1XQ6VeNpbEsbxh71wxpHrvQ0s3c h9QSy0zdYGVOW2Nn47lKHhduhGujwX1+NhDzYbsKyN1aJgazgbMhWCc5itofjBYP yqZ8kzhZW0ulZPF5vLe/HfiE6U6oWMh/lGCP1bBAUpigYS4cmw8vSTDPqVqx7WTy lj7JO3/o0i5TmaAtIVGKQ9fRPh4SJh5/xoh1iR3mQ3G6OgY3NgfmR993L9tRiG/0 CY/rlkDX0yBDrJBB8ouF5ZJ35mZ21AQCnWVv7OoYJocwRepLdgqAPIObWk/pUDoq zAlNCzY0gE/i6WM7VCo6LkRVzr/BrhOK/PQwRHsgpHwjvmSKSiZfwBF1qBRQjBPF 1Ydu0TkHc5kFVtx1iBZ9zi0WBetLXi00Fgs0UTnIdU/BVkGsYhRuu5JjOpj4gNPb ZMkG0nIbRzjkJ9djQodagzAjDPIKuyudrxaj3pMGP9KL1Xup9dSPueDc4j/bH03P +1jekVz6kFFciOh1VmNXCctaO/nu5TQPDtEXeMkR79qmBu9BHPld0ln85e1gRueX 8mDgS5iJakn/XoBNgah18oTHIX5wG6jrNE26BrLegVgd2TnYLHOKZyhcSt5oyA+X Hd2PKuEJoe4Ax5FofaPB =9Ouo -----END PGP SIGNATURE----- --2VVltOwtGC4x6DHiLhWFZrrP58R52dG9O-- From owner-freebsd-current@freebsd.org Thu Jun 21 05:38:25 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0F8F110073A3 for ; Thu, 21 Jun 2018 05:38:25 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp002.me.com (st13p35im-asmtp002.me.com [17.164.199.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 92ADF8ACF0 for ; Thu, 21 Jun 2018 05:38:24 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp002.me.com by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0PAN00900RH8OO00@st13p35im-asmtp002.me.com> for freebsd-current@freebsd.org; Thu, 21 Jun 2018 05:38:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=04042017; t=1529559498; bh=5kx9KReP4loCNj9srSWKA38lH/JPSbcMNehSOwJVv/E=; h=From:Content-type:MIME-version:Subject:Date:To:Message-id; b=n2hrpFni/wr2esOHnJgxfQkq4lZVugJwB2tVeZGzcEl/MtGB4iXWaiPdtWqLgEEq0 vbYEPDlXr8Py/Sn6F7xIIuDwcJctpO3c30BXaPOwxRN8xL4BI/DOLh6zEpJ/b0IsCl vmh58TRh2+yBNpK8xnCQLv+KOk5GxfGYmrFBLpjHKMVZT3fENwpSbkvzi1TpleR5d/ 5Xqj0FKBYHBVVnhRpZUWy0TLOiLW0dHN8+GBTrNHesIB81eJpK18E11Uk3QMC5I23e /duymUpggpKNq+YRVkzfaLe92jvpIN42/J8ritlMpnXLAzzytF86oJGF/IBKEqiei9 beYR7Qoxy7MXQ== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0PAN00H0NRNPX820@st13p35im-asmtp002.me.com> for freebsd-current@freebsd.org; Thu, 21 Jun 2018 05:38:15 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-06-21_02:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=31 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1806210062 From: Toomas Soome Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable MIME-version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: ZFS: I/O error - blocks larger than 16777216 are not supported Date: Thu, 21 Jun 2018 08:38:12 +0300 References: <201806210136.w5L1a5Nv074194@kx.openedu.org> <21493592-4eb2-59c5-1b0d-e1d08217a96b@freebsd.org> To: FreeBSD Current In-reply-to: <21493592-4eb2-59c5-1b0d-e1d08217a96b@freebsd.org> Message-id: X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 21 Jun 2018 05:38:25 -0000 > On 21 Jun 2018, at 06:34, Allan Jude wrote: >=20 > On 2018-06-20 21:36, KIRIYAMA Kazuhiko wrote: >> Hi all, >>=20 >> I've been reported ZFS boot disable problem [1], and found >> that this issue occers form RAID configuration [2]. So I >> rebuit with RAID5 and re-installed 12.0-CURRENT >> (r333982). But failed to boot with: >>=20 >> ZFS: i/o error - all block copies unavailable >> ZFS: can't read MOS of pool zroot >> gptzfsboot: failed to mount default pool zroot >>=20 >> FreeBSD/x86 boot >> ZFS: I/O error - blocks larger than 16777216 are not supported >> ZFS: can't find dataset u >> Default: zroot/<0x0>: >>=20 >> In this case, the reason is "blocks larger than 16777216 are >> not supported" and I guess this means datasets that have >> recordsize greater than 8GB is NOT supported by the >> FreeBSD boot loader(zpool-features(7)). Is that true ? >>=20 >> My zpool featues are as follows: >>=20 >> # kldload zfs >> # zpool import=20 >> pool: zroot >> id: 13407092850382881815 >> state: ONLINE >> status: The pool was last accessed by another system. >> action: The pool can be imported using its name or numeric identifier = and >> the '-f' flag. >> see: http://illumos.org/msg/ZFS-8000-EY >> config: >>=20 >> zroot ONLINE >> mfid0p3 ONLINE >> # zpool import -fR /mnt zroot >> # zpool list >> NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH = ALTROOT >> zroot 19.9T 129G 19.7T - 0% 0% 1.00x ONLINE = /mnt >> # zpool get all zroot >> NAME PROPERTY VALUE = SOURCE >> zroot size 19.9T = - >> zroot capacity 0% = - >> zroot altroot /mnt = local >> zroot health ONLINE = - >> zroot guid 13407092850382881815 = default >> zroot version - = default >> zroot bootfs zroot/ROOT/default = local >> zroot delegation on = default >> zroot autoreplace off = default >> zroot cachefile none = local >> zroot failmode wait = default >> zroot listsnapshots off = default >> zroot autoexpand off = default >> zroot dedupditto 0 = default >> zroot dedupratio 1.00x = - >> zroot free 19.7T = - >> zroot allocated 129G = - >> zroot readonly off = - >> zroot comment - = default >> zroot expandsize - = - >> zroot freeing 0 = default >> zroot fragmentation 0% = - >> zroot leaked 0 = default >> zroot feature@async_destroy enabled = local >> zroot feature@empty_bpobj active = local >> zroot feature@lz4_compress active = local >> zroot feature@multi_vdev_crash_dump enabled = local >> zroot feature@spacemap_histogram active = local >> zroot feature@enabled_txg active = local >> zroot feature@hole_birth active = local >> zroot feature@extensible_dataset enabled = local >> zroot feature@embedded_data active = local >> zroot feature@bookmarks enabled = local >> zroot feature@filesystem_limits enabled = local >> zroot feature@large_blocks enabled = local >> zroot feature@sha512 enabled = local >> zroot feature@skein enabled = local >> zroot unsupported@com.delphix:device_removal inactive = local >> zroot unsupported@com.delphix:obsolete_counts inactive = local >> zroot unsupported@com.delphix:zpool_checkpoint inactive = local >> #=20 >>=20 >> Regards >>=20 >> [1] = https://lists.freebsd.org/pipermail/freebsd-current/2018-March/068886.html= >> [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D151910 >>=20 >> --- >> KIRIYAMA Kazuhiko >> _______________________________________________ >> 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" >>=20 >=20 > I am guessing it means something is corrupt, as 16MB is the maximum = size > of a record in ZFS. Also, the 'large_blocks' feature is 'enabled', not > 'active', so this suggest you do not have any records larger than = 128kb > on your pool. >=20 >=20 yes indeed, this value printed is 1 << 24 and is current, however, I = would start with reinstalling gptzfsboot on freebsd-boot partition.=20 rgds, toomas From owner-freebsd-current@freebsd.org Thu Jun 21 06:00:53 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 52465100A01A for ; Thu, 21 Jun 2018 06:00:53 +0000 (UTC) (envelope-from kiri@kx.openedu.org) Received: from kx.openedu.org (flets-sg1027.kamome.or.jp [202.216.24.27]) (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 A069A8BDC6; Thu, 21 Jun 2018 06:00:51 +0000 (UTC) (envelope-from kiri@kx.openedu.org) Received: from kx.openedu.org (kx.openedu.org [202.216.24.27]) by kx.openedu.org (8.14.5/8.14.5) with ESMTP id w5L60mYn079435; Thu, 21 Jun 2018 15:00:49 +0900 (JST) (envelope-from kiri@kx.openedu.org) Message-Id: <201806210600.w5L60mYn079435@kx.openedu.org> Date: Thu, 21 Jun 2018 15:00:48 +0900 From: KIRIYAMA Kazuhiko To: Allan Jude Cc: freebsd-current@freebsd.org Subject: Re: ZFS: I/O error - blocks larger than 16777216 are not supported In-Reply-To: <21493592-4eb2-59c5-1b0d-e1d08217a96b@freebsd.org> References: <201806210136.w5L1a5Nv074194@kx.openedu.org> <21493592-4eb2-59c5-1b0d-e1d08217a96b@freebsd.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.6 MULE XEmacs/21.4 (patch 22) (Instant Classic) (amd64--freebsd) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 21 Jun 2018 06:00:53 -0000 At Wed, 20 Jun 2018 23:34:48 -0400, Allan Jude wrote: > > On 2018-06-20 21:36, KIRIYAMA Kazuhiko wrote: > > Hi all, > > > > I've been reported ZFS boot disable problem [1], and found > > that this issue occers form RAID configuration [2]. So I > > rebuit with RAID5 and re-installed 12.0-CURRENT > > (r333982). But failed to boot with: > > > > ZFS: i/o error - all block copies unavailable > > ZFS: can't read MOS of pool zroot > > gptzfsboot: failed to mount default pool zroot > > > > FreeBSD/x86 boot > > ZFS: I/O error - blocks larger than 16777216 are not supported > > ZFS: can't find dataset u > > Default: zroot/<0x0>: > > > > In this case, the reason is "blocks larger than 16777216 are > > not supported" and I guess this means datasets that have > > recordsize greater than 8GB is NOT supported by the > > FreeBSD boot loader(zpool-features(7)). Is that true ? > > > > My zpool featues are as follows: > > > > # kldload zfs > > # zpool import > > pool: zroot > > id: 13407092850382881815 > > state: ONLINE > > status: The pool was last accessed by another system. > > action: The pool can be imported using its name or numeric identifier and > > the '-f' flag. > > see: http://illumos.org/msg/ZFS-8000-EY > > config: > > > > zroot ONLINE > > mfid0p3 ONLINE > > # zpool import -fR /mnt zroot > > # zpool list > > NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT > > zroot 19.9T 129G 19.7T - 0% 0% 1.00x ONLINE /mnt > > # zpool get all zroot > > NAME PROPERTY VALUE SOURCE > > zroot size 19.9T - > > zroot capacity 0% - > > zroot altroot /mnt local > > zroot health ONLINE - > > zroot guid 13407092850382881815 default > > zroot version - default > > zroot bootfs zroot/ROOT/default local > > zroot delegation on default > > zroot autoreplace off default > > zroot cachefile none local > > zroot failmode wait default > > zroot listsnapshots off default > > zroot autoexpand off default > > zroot dedupditto 0 default > > zroot dedupratio 1.00x - > > zroot free 19.7T - > > zroot allocated 129G - > > zroot readonly off - > > zroot comment - default > > zroot expandsize - - > > zroot freeing 0 default > > zroot fragmentation 0% - > > zroot leaked 0 default > > zroot feature@async_destroy enabled local > > zroot feature@empty_bpobj active local > > zroot feature@lz4_compress active local > > zroot feature@multi_vdev_crash_dump enabled local > > zroot feature@spacemap_histogram active local > > zroot feature@enabled_txg active local > > zroot feature@hole_birth active local > > zroot feature@extensible_dataset enabled local > > zroot feature@embedded_data active local > > zroot feature@bookmarks enabled local > > zroot feature@filesystem_limits enabled local > > zroot feature@large_blocks enabled local > > zroot feature@sha512 enabled local > > zroot feature@skein enabled local > > zroot unsupported@com.delphix:device_removal inactive local > > zroot unsupported@com.delphix:obsolete_counts inactive local > > zroot unsupported@com.delphix:zpool_checkpoint inactive local > > # > > > > Regards > > > > [1] https://lists.freebsd.org/pipermail/freebsd-current/2018-March/068886.html > > [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=151910 > > > > --- > > KIRIYAMA Kazuhiko > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > I am guessing it means something is corrupt, as 16MB is the maximum size > of a record in ZFS. Also, the 'large_blocks' feature is 'enabled', not > 'active', so this suggest you do not have any records larger than 128kb > on your pool. As I mentioned above, [2] says ZFS on RAID disks have any serious bugs except for mirror. Anyway I gave up to use ZFS on RAID{5,6}* until Bug 151910 [2] fixed. > > -- > Allan Jude > --- KIRIYAMA Kazuhiko From owner-freebsd-current@freebsd.org Thu Jun 21 07:48:45 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC9D0101283B for ; Thu, 21 Jun 2018 07:48:45 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp001.me.com (st13p35im-asmtp001.me.com [17.164.199.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 72DED7118A; Thu, 21 Jun 2018 07:48:45 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp001.me.com by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0PAN00D00XHJXR00@st13p35im-asmtp001.me.com>; Thu, 21 Jun 2018 07:48:32 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=04042017; t=1529567312; bh=tUoYShb7x9dmr81gnSBRhei3YJuF8kYMe6ucOl8+D/g=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=wwsfTrJMISsfEeaHQCnb+scoFtXljZMkZi45d+opaA62J4GRbm4GnEjLL5ZfQSLdL rvvsjfmhxAvitfoNRVAaYqTTRVkWvk9SjIPItWGUYIjx4eju3CfCSpjgvpm0tybw1d YfZfCHYDY9l0oOrrz3plXoIeUBD4bzG29+DmruazhHK/qFcLJTwdNwD5MFcXzd+0No 2SgsbCt0k83I/xH81VWmaKl+EGLlgm2eJ4rYxoxiTJdCV0zolbTYDXMqKgmZJglHZo E842V3oa6X9iaJ/BnKk4xRtUdW3N4jJGgR2z/nq49Us6FmVA4v2UG2iUf8/IA/5woA mc47GFbY6ljrQ== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0PAN00LRQXOSV130@st13p35im-asmtp001.me.com>; Thu, 21 Jun 2018 07:48:31 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-06-21_03:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=8 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1806210088 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: ZFS: I/O error - blocks larger than 16777216 are not supported From: Toomas Soome In-reply-to: <201806210600.w5L60mYn079435@kx.openedu.org> Date: Thu, 21 Jun 2018 10:48:28 +0300 Cc: Allan Jude , freebsd-current@freebsd.org Content-transfer-encoding: quoted-printable Message-id: <1CDD5AFE-F115-406C-AB92-9DC58B57E1D5@me.com> References: <201806210136.w5L1a5Nv074194@kx.openedu.org> <21493592-4eb2-59c5-1b0d-e1d08217a96b@freebsd.org> <201806210600.w5L60mYn079435@kx.openedu.org> To: KIRIYAMA Kazuhiko X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 21 Jun 2018 07:48:46 -0000 > On 21 Jun 2018, at 09:00, KIRIYAMA Kazuhiko = wrote: >=20 > At Wed, 20 Jun 2018 23:34:48 -0400, > Allan Jude wrote: >>=20 >> On 2018-06-20 21:36, KIRIYAMA Kazuhiko wrote: >>> Hi all, >>>=20 >>> I've been reported ZFS boot disable problem [1], and found >>> that this issue occers form RAID configuration [2]. So I >>> rebuit with RAID5 and re-installed 12.0-CURRENT >>> (r333982). But failed to boot with: >>>=20 >>> ZFS: i/o error - all block copies unavailable >>> ZFS: can't read MOS of pool zroot >>> gptzfsboot: failed to mount default pool zroot >>>=20 >>> FreeBSD/x86 boot >>> ZFS: I/O error - blocks larger than 16777216 are not supported >>> ZFS: can't find dataset u >>> Default: zroot/<0x0>: >>>=20 >>> In this case, the reason is "blocks larger than 16777216 are >>> not supported" and I guess this means datasets that have >>> recordsize greater than 8GB is NOT supported by the >>> FreeBSD boot loader(zpool-features(7)). Is that true ? >>>=20 >>> My zpool featues are as follows: >>>=20 >>> # kldload zfs >>> # zpool import=20 >>> pool: zroot >>> id: 13407092850382881815 >>> state: ONLINE >>> status: The pool was last accessed by another system. >>> action: The pool can be imported using its name or numeric = identifier and >>> the '-f' flag. >>> see: http://illumos.org/msg/ZFS-8000-EY >>> config: >>>=20 >>> zroot ONLINE >>> mfid0p3 ONLINE >>> # zpool import -fR /mnt zroot >>> # zpool list >>> NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH = ALTROOT >>> zroot 19.9T 129G 19.7T - 0% 0% 1.00x ONLINE = /mnt >>> # zpool get all zroot >>> NAME PROPERTY VALUE = SOURCE >>> zroot size 19.9T = - >>> zroot capacity 0% = - >>> zroot altroot /mnt = local >>> zroot health ONLINE = - >>> zroot guid = 13407092850382881815 default >>> zroot version - = default >>> zroot bootfs zroot/ROOT/default = local >>> zroot delegation on = default >>> zroot autoreplace off = default >>> zroot cachefile none = local >>> zroot failmode wait = default >>> zroot listsnapshots off = default >>> zroot autoexpand off = default >>> zroot dedupditto 0 = default >>> zroot dedupratio 1.00x = - >>> zroot free 19.7T = - >>> zroot allocated 129G = - >>> zroot readonly off = - >>> zroot comment - = default >>> zroot expandsize - = - >>> zroot freeing 0 = default >>> zroot fragmentation 0% = - >>> zroot leaked 0 = default >>> zroot feature@async_destroy enabled = local >>> zroot feature@empty_bpobj active = local >>> zroot feature@lz4_compress active = local >>> zroot feature@multi_vdev_crash_dump enabled = local >>> zroot feature@spacemap_histogram active = local >>> zroot feature@enabled_txg active = local >>> zroot feature@hole_birth active = local >>> zroot feature@extensible_dataset enabled = local >>> zroot feature@embedded_data active = local >>> zroot feature@bookmarks enabled = local >>> zroot feature@filesystem_limits enabled = local >>> zroot feature@large_blocks enabled = local >>> zroot feature@sha512 enabled = local >>> zroot feature@skein enabled = local >>> zroot unsupported@com.delphix:device_removal inactive = local >>> zroot unsupported@com.delphix:obsolete_counts inactive = local >>> zroot unsupported@com.delphix:zpool_checkpoint inactive = local >>> #=20 >>>=20 >>> Regards >>>=20 >>> [1] = https://lists.freebsd.org/pipermail/freebsd-current/2018-March/068886.html= >>> [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D151910 >>>=20 >>> --- >>> KIRIYAMA Kazuhiko >>> _______________________________________________ >>> 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" >>>=20 >>=20 >> I am guessing it means something is corrupt, as 16MB is the maximum = size >> of a record in ZFS. Also, the 'large_blocks' feature is 'enabled', = not >> 'active', so this suggest you do not have any records larger than = 128kb >> on your pool. >=20 > As I mentioned above, [2] says ZFS on RAID disks have any > serious bugs except for mirror. Anyway I gave up to use ZFS > on RAID{5,6}* until Bug 151910 [2] fixed. >=20 if you boot from usb stick (or cd), press esc at boot loader menu and = enter lsdev -v. what sector and disk sizes are reported? the issue [2] is mix of ancient freebsd (v 8.1 is mentioned there), and = RAID luns with 512B sector size and 15TB!!! total size - are you really = sure your BIOS can actually address 15TB lun (with 512B sector size)? = Note that the problem with large disks can hide itself till you have = pool filled up enough till the essential files will be stored above the = limit=E2=80=A6 meaning that you may have =E2=80=9Cperfectly working=E2=80=9D= setup till at some point in time, after next update, it is suddenly not = working any more. Note that for boot loader we have only INT13h for BIOS version, and it = really is limited. The UEFI version is using EFI_BLOCK_IO API, which = usually can handle large sectors and disk sizes better. rgds, toomas From owner-freebsd-current@freebsd.org Thu Jun 21 13:09:32 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1812F101E84A; Thu, 21 Jun 2018 13:09:32 +0000 (UTC) (envelope-from carpeddiem@gmail.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 7F03F7BDD2; Thu, 21 Jun 2018 13:09:31 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x22c.google.com with SMTP id g22-v6so2907186iob.7; Thu, 21 Jun 2018 06:09:31 -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=fjbDUE+ZuUXROmKQ5k7aqbl/b2PQg8L+CIw9odKTrMA=; b=pNmvWhicW0QiRwPXtyoxcbQ4cwEmms3FxW9++f0jhdV4mThz6fy1ZvEglJSfOUurdE I9aJc/qomD4Oy+IlwjrzhE9DkA+S9JI/N6Hfakyb3xzbPJ+61r4TVeVdupJIstAD5LU5 eQsCIkeMhDS2tpw6+Xyr55XnHQP3Xox8HFUEzVK2WfxIY+TLfjSQOd5qgMt2X54STbwH O50M/cySi4WcCm1VptMODEJ08+hs0RSu6KMnwv0SPJKhrUL5+ZcsP/DhUVNa5vwo+8Px allVxGxzdFOCiIJTOxkumj9g9zvTz0B2W3QCFIclODIMJwU/3qIwqza1zsG4zURdXBNG pqkw== 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=fjbDUE+ZuUXROmKQ5k7aqbl/b2PQg8L+CIw9odKTrMA=; b=hKNO9aEHj+23l8veB5afxcsANTDYOj+iea8OEgGE4Cnrn8Yy8cS3sRqTc7ukYtFsEf AS5fGDjGBNQwebI8WQHFgmMnAw2Z0SRRhLVjZDJMEhgk87geO2WKGIoumynYTllJvmlO S+adEy0o6k/UAuiQvaS0TipLq8y2sQTKiULaDTfhspzxGHh/9TXVOQnlJAvnUBD8DX72 ILUssPyBZMxeOo0QLxyIhqV0F82fBCy13dt7jgGvLgx19qqEaUy4RV6/IHdyLLx5W9FF R/WVp8eTjmsXQWY6m+ky1pss6K1Wg4NMFMqmAYac7PDgmkaAPSChyigGgE895a9GaDzb wh6w== X-Gm-Message-State: APt69E1CWZgqAiXQrwsRaZxYeSqk5vBHP/UGkIc47m7w1zyuUcvgh2fg zpbdpB1R+hyWVV1DZ4cllx927FdcRQ+7xDLCGk1GjQ== X-Google-Smtp-Source: ADUXVKJpTNUHccoRebWFAP04HV9WDJjvl3xbMQHr0iB5IHYacY/y9yjCG5JilbA0N0USa8jIzJg336pAUkj0+Tjp/to= X-Received: by 2002:a6b:2cd:: with SMTP id 196-v6mr20061157ioc.294.1529586570771; Thu, 21 Jun 2018 06:09:30 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 2002:a6b:c6c6:0:0:0:0:0 with HTTP; Thu, 21 Jun 2018 06:09:10 -0700 (PDT) In-Reply-To: References: <20180620155022.GA92001@spindle.one-eyed-alien.net> From: Ed Maste Date: Thu, 21 Jun 2018 09:09:10 -0400 X-Google-Sender-Auth: 1rslMByCC-3-HotJEtqHrucUbhs Message-ID: Subject: Re: Tool Chain Migration: objdump users, please test llvm-objdump To: Alexander Richardson Cc: Brooks Davis , FreeBSD Current , "freebsd-toolchain@FreeBSD.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 21 Jun 2018 13:09:32 -0000 On 20 June 2018 at 17:26, Alexander Richardson wrote: > > When I made the change to use llvm-objdump in CheriBSD I had to change the > objdump flags from -xrsSd to -r -s -p -S -d -h -l -t. Ah yes, I recall discussing this now. Per GNU objdump's man page, -x is equivalent to -a -f -h -p -r -t. llvm-objdump doesn't support these: -a archive headers -f file headers so we probably want to address those as well. We'll also need a man page. From owner-freebsd-current@freebsd.org Thu Jun 21 13:55:05 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F29DC101F91E; Thu, 21 Jun 2018 13:55:04 +0000 (UTC) (envelope-from carpeddiem@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 7D8987D6D1; Thu, 21 Jun 2018 13:55:04 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x230.google.com with SMTP id q4-v6so3072370iob.2; Thu, 21 Jun 2018 06:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=0tRgq1Yt6ScP8eiIfA0mBAfL+s8xNtise6VyWlsYSqI=; b=IC1oV3aRQQn/AoWmPbQRfyZxn8T7BXI6IlGPZlDiT0crzRXDdLI32oshkvTvpL4tz2 f2ohNGzou4nFDad4cNPbXOhBQxx0n3R4FSytct9DPbBbQQSPOsAGIjS5/IYHSj/iOgfq s+kn/uZCEfUuYLnU87J4imrQDM+WUBSPYMfWRkVC2mOjXHnXm9wOFs9ktV8BljoLThjq tmq3wR6rNBkXgmuzHpMr3R13MA7lTitLBO4DtivjvwLTRIsUWvlKQTZ5QfHOItzQpzN+ iaTn1oqbAp+zbFIgY9fuWrbHy9X6pVyZ9j52k3ycOnG/8IviPVLUpMIdq0Vs9KCHmYZk NQGw== 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=0tRgq1Yt6ScP8eiIfA0mBAfL+s8xNtise6VyWlsYSqI=; b=bGtmMoREg9t8MX/1HTdTQde17DwxN4yIZMOqdz7zAWqQ809NtF9XNas4hwxa1tYO/z vt/HaUJKddpK4x0R4YmmAEhrKzr97XsxhanmmkolZP2FmS7ZB6Tp+mAK2AroE7Yefmkp W2QKMPz310To9GWxdkSCNNBfhzLTn7Cg2sm+qXEgz7qZ4mmrA2u0onj3T/ggDGPXy0J4 bQ6XkzSZMrXT8rEW2V5aLhlEkc5AcUKMSmEr9NJ+TywVlXKKLHizmHyeN7YTxTYA8YHF mTtxk/SerJEmqUazKmQxbuPnuXL2C1rNBMjhz9wZarTw7KXEIC/AOCZcuWOeK1TL1g6J cTVg== X-Gm-Message-State: APt69E3U28O5bQ1kXZzZDmTglTDaj/txoHaydIC4kpLYOpFwUGXm7a+E Xyt1xlZ98IQdek87NEI0iHRhz1RIYD2OGJB0aBOBvOmw X-Google-Smtp-Source: ADUXVKJ2a2mHinMuZ06ZQPRUz3V/A3YGb9X08mRAuVaetadbQXeTflXxilwyInqROZ7c8c6uDWRGK3ViIAHOW+OMlPM= X-Received: by 2002:a6b:2cd:: with SMTP id 196-v6mr20210468ioc.294.1529589303656; Thu, 21 Jun 2018 06:55:03 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 2002:a6b:c6c6:0:0:0:0:0 with HTTP; Thu, 21 Jun 2018 06:54:43 -0700 (PDT) In-Reply-To: References: <20180620155022.GA92001@spindle.one-eyed-alien.net> From: Ed Maste Date: Thu, 21 Jun 2018 09:54:43 -0400 X-Google-Sender-Auth: HNGKc9S9fjSuMjuaKaJdNxq4sYQ Message-ID: Subject: Re: Tool Chain Migration: objdump users, please test llvm-objdump To: Alexander Richardson Cc: FreeBSD Current , "freebsd-toolchain@FreeBSD.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 21 Jun 2018 13:55:05 -0000 On 21 June 2018 at 09:09, Ed Maste wrote: > > We'll also need a man page. I took a quick look at this, and in doing so found that the output from "llvm-objdump --help" appears to be missing a large number of single-letter options, so one more thing to sort out. As it happens there are LLVM bugs open for a number of the llvm-objdump issues (even including some I submitted but forgot about): https://bugs.llvm.org/buglist.cgi?component=llvm-objdump&list_id=140941&product=tools&query_format=advanced&resolution=--- From owner-freebsd-current@freebsd.org Thu Jun 21 21:49:12 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C865100122F for ; Thu, 21 Jun 2018 21:49:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-14.consmr.mail.bf2.yahoo.com (sonic313-14.consmr.mail.bf2.yahoo.com [74.6.133.124]) (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 BCB3E70022 for ; Thu, 21 Jun 2018 21:49:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 0Sc6dLwVM1kf1tNzDu62T51Bq8AOHaCdPfPDmvct1ynk2zLjOQo8jeSFQj0fFxC 0.7tu.rav8zCMJ5I8uvtqCXXHGMgJCklsM6FN84mdIUn190YSYidugOgx8YyewMlI2iVR5W2tYaD mvgtqJsKJUqJ.cciZXPN2lbtOytMvxVEt2v3Am5kiETTVPmOMhG.ZSNu4nyuW7blu3U08beUFyYm VUKbBGBIMBupU7.hTjoKWanv_9nISTyEpMlgx.V2JE4OLHQXg46WRZ7arFPxLRBosj8kDQAtrUWS OL6ORmhXs0Qb50WIMQFpcTYzi1kIteLz1Mph79nB2kzp6nEQZfayruXFzcnNChhQ_uKeSnsEwETd DN4ln0EApvjsHNlaijVAmwIM58eNDX5bVRaxYLoMkPF38iEYQLIIT930Jrw2BFcKXF5GAsf7Y26W 6FJOIv_UVRjIIGiOaZOvqyxQv1B4VheOfk5tfP.EUdrL.w6j54GRupPKolg27KQrKV5Rel7KI6Py z8VFnO.9De0.UDRYoBFI0pX9.kIyrrmDyAzypdVCMV831iQFuPDUFDn9QfBAi8X2AcHFGz_6myku s7hdNEzDLR.nuhIHA8pUQB8xL04zoBwWBbFMn.C1ygydCDWQOAb2zvUDo.9jN.6oeinkSFRm0ZJI K6ljfBfLfo2zEn5LOGzs5LAorlhE74BOHx4beifZciTVBX3dZK0sODOew4UySTuyKlUyZLS0UH4d IHNq3EPrdMiWf7CoJl6KPdvCYACUy_GXaPJCoRO4XiRZFpKeMzJB_prVMiXFMZxjxi4ZtBq08FZY .WosUdWfC86UYql0LEUF0E_KwUPQSwxTQUmRQNxbj6CfFN9m20yyyWPtmynbpqivJxEGT.aryK9p DD5nDnlA.iMMsWJ3KTp4Tih_opllJyRssXMDSfTT3Go3ZV52c5jvTFWEw6qDc5wNLmBuRzV9KW1K Y886SjzyEocxL2vu1BOOZmCLy8vIhlIS7tA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.bf2.yahoo.com with HTTP; Thu, 21 Jun 2018 21:49:05 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp432.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID a340e1c5811d16f399b25b6993c3bed8; Thu, 21 Jun 2018 21:49:01 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: A head buildworld race visible in the ci.freebsd.org build history From: Mark Millard In-Reply-To: Date: Thu, 21 Jun 2018 14:48:59 -0700 Cc: Ed Maste , Bryan Drewery , FreeBSD Current , FreeBSD Toolchain Content-Transfer-Encoding: 7bit Message-Id: <29F7FD25-147A-4B87-AC96-23CB3B1C38C7@yahoo.com> References: <74EAD684-0E0B-453A-B746-156777CF604A@yahoo.com> <1884103f-d1fb-aca6-2edd-062e11d05617@FreeBSD.org> <33a43aac-231f-6158-1de4-f5dbfaf195df@FreeBSD.org> To: Li-Wen Hsu X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 21 Jun 2018 21:49:12 -0000 On 2018-Jun-19, at 9:14 PM, Li-Wen Hsu wrote: > On Tue, Jun 19, 2018 at 9:24 PM Mark Millard wrote: >> >> On 2018-Jun-19, at 8:02 AM, Li-Wen Hsu wrote: >> >>> On Mon, Jun 18, 2018 at 8:36 PM Ed Maste wrote: >>>> Li-Wen reported that the build is done in a 11.1-rel jail though, so >>>> the libarchive (or any userland) change shouldn't be responsible. >>>> >>>> Can we update a canary builder to somewhere between r328278 and r333388? >>> >>> butler1.nyi.freebsd.org is running r331373 now. >> >> >> But there seems to be another of the ar -> ranlib failures >> after that on butler1.nyi.freebsd.org : > > Yes I was trying to narrow down the cause, now it seems between > r328278 and r330304. > > butler1.nyi.freebsd.org is back to run r328278. And I'll try to > reproduce this in elsewhere. Has the range r328278 < PROBLEM_START <= r330304 been narrowed down some more? (I'm just curious were the problem started.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Fri Jun 22 01:15:05 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9EEFD1007AD7 for ; Fri, 22 Jun 2018 01:15:05 +0000 (UTC) (envelope-from cy.schubert@cschubert.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 2B81877738 for ; Fri, 22 Jun 2018 01:15:05 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: by mailman.ysv.freebsd.org (Postfix) id DFDCD1007AD6; Fri, 22 Jun 2018 01:15:04 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 917B11007AD3 for ; Fri, 22 Jun 2018 01:15:04 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0874F77737 for ; Fri, 22 Jun 2018 01:15:03 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id WAf8fjEqiSzNNWAf9fWcGf; Thu, 21 Jun 2018 19:14:56 -0600 X-Authority-Analysis: v=2.3 cv=KuxjJ1eN c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=7mUfYlMuFuIA:10 a=6I5d2MoRAAAA:8 a=mDV3o1hIAAAA:8 a=YxBL1-UpAAAA:8 a=VfJU935czivgIt8UOroA:9 a=K7qD8OWFJuu76a7U:21 a=DPIirCjv34uU4Loq:21 a=XqE05Yf1wqetR3ZW:21 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 a=_FVE-zBwftR9WsbkzFJk:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 7D9EA942; Thu, 21 Jun 2018 18:14:53 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id w5M1Ergv034855; Thu, 21 Jun 2018 18:14:53 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id w5M1EqeX034820; Thu, 21 Jun 2018 18:14:53 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201806220114.w5M1EqeX034820@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Peter Holm cc: current@freebsd.org Subject: Re: Page fault in udp_usrreq.c:823 In-Reply-To: Message from Peter Holm of "Wed, 20 Jun 2018 11:09:57 +0200." <20180620090957.GA130@x2.osted.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Jun 2018 18:14:52 -0700 X-CMAE-Envelope: MS4wfJMw8ltfLHzLXGeNoDJ352/Vpp8yd26tiAsDyxzDcXiqLf+tGXDI6yHPX+f/VaKF3kVRcCfYd3OOq49r2w/rwgPjUmbg6y21n41xzZMhIqhxkKblbS+I LI3w1F6IdaC0geK1A6qw37oHutgJUr/SR7LpY233ZzUg7AaXNfprm+gzo6XiLy+OZjjNBkYOP8hoOA== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 22 Jun 2018 01:15:06 -0000 In message <20180620090957.GA130@x2.osted.lan>, Peter Holm writes: > 20180620 10:32:47 all (1/1): udp.sh > Kernel page fault with the following non-sleepable locks held: > shared rw udpinp (udpinp) r = 0 (0xfffff80bbc808d78) locked @ netinet/in_pcb. > c:2398 > stack backtrace: > #0 0xffffffff80c00733 at witness_debugger+0x73 > #1 0xffffffff80c01b11 at witness_warn+0x461 > #2 0xffffffff81075763 at trap_pfault+0x53 > #3 0xffffffff81074d7a at trap+0x2ba > #4 0xffffffff8105076c at calltrap+0x8 > #5 0xffffffff80dd21b0 at udp_ctlinput+0x50 > #6 0xffffffff80d3081d at icmp_input+0x96d > #7 0xffffffff80d316d7 at ip_input+0x3f7 > #8 0xffffffff80cc0a92 at netisr_dispatch_src+0xa2 > #9 0xffffffff80ca3ebe at ether_demux+0x16e > #10 0xffffffff80ca5377 at ether_nh_input+0x427 > #11 0xffffffff80cc0a92 at netisr_dispatch_src+0xa2 > #12 0xffffffff80ca437f at ether_input+0x8f > #13 0xffffffff80cbc500 at iflib_rxeof+0xc90 > #14 0xffffffff80cb6b6f at _task_fn_rx+0x7f > #15 0xffffffff80bdd209 at gtaskqueue_run_locked+0x139 > #16 0xffffffff80bdcf88 at gtaskqueue_thread_loop+0x88 > #17 0xffffffff80b54514 at fork_exit+0x84 > > > Fatal trap 12: page fault while in kernel mode > cpuid = 10; apic id = 0a > fault virtual address = 0x8 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff80dd2423 > stack pointer = 0x0:0xfffffe00004a5500 > frame pointer = 0x0:0xfffffe00004a55a0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (if_io_tqg_10) > [ thread pid 0 tid 100069 ] > Stopped at udp_common_ctlinput+0x263: cmpq $0,0x8(%rax) > db> > > Details @ https://people.freebsd.org/~pho/stress/log/udp_usrreq.txt > > -- > Peter > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > This is surprisingly similar to my panic. Twice since June 19. slippy# kgdb /boot/kernel/kernel vmcore.3 GNU gdb (GDB) 8.1 [GDB v8.1 for FreeBSD] Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd12.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /boot/kernel/kernel...Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug...done. done. Unread portion of the kernel message buffer: Copyright (c) 1992-2018 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 #355 r335477M: Thu Jun 21 05:26:35 PDT 2018 root@slippy:/export/obj/opt/src/svn-current/amd64.amd64/sys/BREAK amd64 FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0) VT(vga): text 80x25 module_register: cannot register mmc/mmcsd from kernel; already loaded from mmcsd.ko Module mmc/mmcsd failed to register: 17 CPU: Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz (2294.83-MHz K8-class CPU) Origin="GenuineIntel" Id=0x206a7 Family=0x6 Model=0x2a Stepping=7 Features=0xbfebfbff Features2=0x1dbae3bf AMD Features=0x28100800 AMD Features2=0x1 XSAVE Features=0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 8080965632 (7706 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads random: unblocking device. ioapic0 irqs 0-23 on motherboard random: entropy device external interface module_register_init: MOD_LOAD (vesa, 0xffffffff8097b700, 0) error 19 kbd1 at kbdmux0 nexus0 vtvga0: on motherboard cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. atrtc0: registered as a time-of-day clock, resolution 1.000000s attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x2000-0x203f mem 0xf0000000-0xf03fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 vgapci0: Boot video device pci0: at device 22.0 (no driver attached) ehci0: mem 0xf060a000-0xf060a3ff irq 16 at device 26.0 on pci0 usbus0: EHCI version 1.0 usbus0 on ehci0 hdac0: mem 0xf0600000-0xf0603fff irq 22 at device 27.0 on pci0 pcib1: irq 16 at device 28.0 on pci0 pci1: on pcib1 pcib2: irq 17 at device 28.1 on pci0 pci2: on pcib2 iwn0: mem 0xf0500000-0xf0501fff irq 17 at device 0.0 on pci2 pcib3: irq 19 at device 28.3 on pci0 pci3: on pcib3 bge0: mem 0xf0400000-0xf040ffff,0xf0410000-0xf041ffff irq 19 at device 0.0 on pci3 bge0: CHIP ID 0x57785100; ASIC REV 0x57785; CHIP REV 0x577851; PCI-E miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow <6>bge0: Using defaults for TSO: 65518/35/2048 <6>bge0: Ethernet address: 20:6a:8a:72:03:17 pci3: at device 0.1 (no driver attached) ehci1: mem 0xf0609000-0xf06093ff irq 23 at device 29.0 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci1 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x2088-0x208f,0x2094-0x2097,0x2080-0x2087,0x2090-0x2093,0x2060-0x207f mem 0xf0608000-0xf06087ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich5: at channel 5 on ahci0 ahciem0: on ahci0 ichsmb0: port 0xefa0-0xefbf mem 0xf0604000-0xf06040ff irq 18 at device 31.3 on pci0 smbus0: on ichsmb0 smb0: on smbus0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_tz0: on acpi0 acpi_tz1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Synaptics Touchpad, device ID 0 acpi_acad0: on acpi0 battery0: on acpi0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff pnpid PNP0900 on isa0 ata0: at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata1: at port 0x170-0x177,0x376 irq 15 on isa0 acpi_perf0: on cpu0 coretemp0: on cpu0 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 10.000 msec IP Filter: v5.1.2 initialized. Default = pass all, Logging = enabled hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 20,33 and 27 on hdaa0 pcm1: at nid 24 on hdaa0 hdacc1: at cad 3 on hdac0 hdaa1: at nid 1 on hdacc1 pcm2: at nid 5 on hdaa1 usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ugen1.1: at usbus1 uhub0: on usbus1 ugen0.1: at usbus0 uhub1: on usbus0 ses0 at ahciem0 bus 0 scbus3 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA8-ACS SATA 3.x device ada0: Serial Number JR1000D33969RE ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 953869MB (1953525168 512 byte sectors) cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI device cd0: Serial Number SBB5103801 cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed Launching APs: 1 3 2 Trying to mount root from ufs:/dev/ufs/Sroot [rw]... Timecounter "TSC-low" frequency 1147416846 Hz quality 1000 <118>Setting hostuuid: 34f5ed40-8938-11da-b265-efe316da850d. <118>Setting hostid: 0x7f5a03b9. uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered ugen0.2: at usbus0 uhub2 on uhub1 uhub2: on usbus0 ugen1.2: at usbus1 uhub3 on uhub0 uhub3: on usbus1 uhub2: 6 ports with 6 removable, self powered uhub3: 6 ports with 6 removable, self powered ugen0.3: at usbus0 ukbd0 on uhub2 ukbd0: on usbus0 kbd2 at ukbd0 ums0 on uhub2 ums0: on usbus0 ums0: 16 buttons and [XYZT] coordinates ID=2 ugen1.3: at usbus1 uhub4 on uhub3 uhub4: on usbus1 uhub4: 4 ports with 4 removable, self powered ugen0.4: at usbus0 ugen1.4: at usbus1 uhub5 on uhub4 uhub5: on usbus1 uhub5: 4 ports with 4 removable, self powered ugen1.5: at usbus1 uhub6 on uhub5 uhub6: on usbus1 uhub6: 4 ports with 4 removable, self powered ugen1.6: at usbus1 ukbd1 on uhub6 ukbd1: on usbus1 kbd3 at ukbd1 ums1 on uhub6 ums1: on usbus1 ums1: 16 buttons and [XYZT] coordinates ID=2 ugen1.7: at usbus1 ukbd2 on uhub6 ukbd2: on usbus1 kbd4 at ukbd2 ugen1.8: at usbus1 umass0 on uhub5 umass0: on usbus1 umass0: SCSI over Bulk-Only; quirks = 0x408c umass0:6:0: Attached to scbus6 da0 at umass-sim0 bus 0 scbus6 target 0 lun 0 da0: Fixed Direct Access SCSI device da0: 40.000MB/s transfers da0: 76319MB (156301488 512 byte sectors) da0: quirks=0x2 <118>Starting file system checks: <118>/dev/ufs/Sroot: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/ufs/Sroot: clean, 413829 free (909 frags, 51615 blocks, 0.2% fragmentation) <118>/dev/ufs/Susr: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/ufs/Susr: clean, 459287 free (4847 frags, 56805 blocks, 0.6% fragmentation) <118>/dev/ufs/Svtmp: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/ufs/Svtmp: clean, 503642 free (50 frags, 62949 blocks, 0.0% fragmentation) <118>/dev/ufs/SCusr: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/ufs/Svar: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/ufs/SSusr: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/ufs/SCusr: clean, 469826 free (4578 frags, 58156 blocks, 0.6% fragmentation) <118>/dev/ufs/Svar: clean, 453726 free (574 frags, 56644 blocks, 0.1% fragmentation) <118>/dev/ufs/SCroot: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/ufs/SSusr: clean, 569245 free (3653 frags, 70699 blocks, 0.5% fragmentation) <118>/dev/ufs/SCroot: clean, 422625 free (617 frags, 52751 blocks, 0.1% fragmentation) <118>/dev/ufs/SCvar: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/ufs/SSvar: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/ufs/SCvar: clean, 400011 free (99 frags, 49989 blocks, 0.0% fragmentation) <118>/dev/ufs/SSvar: clean, 457058 free (138 frags, 57115 blocks, 0.0% fragmentation) <118>/dev/ufs/SSroot: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/ufs/SSroot: clean, 412995 free (219 frags, 51597 blocks, 0.0% fragmentation) <118>/dev/msdosfs/SHARED: FILESYSTEM CLEAN; SKIPPING CHECKS <118>/dev/zvol/tank/VMs/current/i386/disk0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/zvol/tank/VMs/current/i386/disk0s1a: clean, 254465 free (337 frags, 31766 blocks, 0.1% fragmentation) <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1a: clean, 335508 free (1348 frags, 41770 blocks, 0.1% fragmentation) <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1a: clean, 566833 free (2297 frags, 70567 blocks, 0.2% fragmentation) <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/zvol/tank/VMs/current/amd64/disk0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1a: clean, 510529 free (1185 frags, 63668 blocks, 0.1% fragmentation) <118>/dev/zvol/tank/VMs/current/amd64/disk0s1a: clean, 354656 free (336 frags, 44290 blocks, 0.1% fragmentation) <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1a: clean, 633994 free (2106 frags, 78986 blocks, 0.2% fragmentation) <118>/dev/zvol/tank/VMs/current/amd64/disk3p1: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/zvol/tank/VMs/current/amd64/disk3p1: clean, 2535564 free (564 frags, 316875 blocks, 0.0% fragmentation) <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1d: clean, 897924 free (188 frags, 112217 blocks, 0.0% fragmentation) <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1d: clean, 897896 free (152 frags, 112218 blocks, 0.0% fragmentation) <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1d: clean, 889422 free (214 frags, 111151 blocks, 0.0% fragmentation) <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1d: clean, 889419 free (219 frags, 111150 blocks, 0.0% fragmentation) <118>/dev/zvol/tank/VMs/current/amd64/disk0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/zvol/tank/VMs/current/amd64/disk0s1d: clean, 408410 free (90 frags, 51040 blocks, 0.0% fragmentation) <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1e: clean, 1230068 free (7300 frags, 152846 blocks, 0.5% fragmentation) <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1e: clean, 726361 free (6297 frags, 90008 blocks, 0.4% fragmentation) <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1e: clean, 1299097 free (6385 frags, 161589 blocks, 0.4% fragmentation) <118>/dev/zvol/tank/VMs/current/amd64/disk0s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/zvol/tank/VMs/current/amd64/disk0s1e: clean, 822303 free (1047 frags, 102657 blocks, 0.1% fragmentation) <118>/dev/zvol/tank/VMs/current/i386/disk0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/zvol/tank/VMs/current/i386/disk0s1d: clean, 399855 free (15 frags, 49980 blocks, 0.0% fragmentation) <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1e: clean, 937324 free (7524 frags, 116225 blocks, 0.5% fragmentation) <118>/dev/zvol/tank/VMs/current/i386/disk0s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/zvol/tank/VMs/current/i386/disk0s1e: clean, 1077125 free (845 frags, 134535 blocks, 0.1% fragmentation) <118>Mounting local filesystems:. <118>ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg /usr/local/krb5/lib /usr/local/kde4/lib /usr/local/lib/compat /usr/local/lib/compat/pkg /usr/local/lib/dovecot /usr/local/lib/e2fsprogs /usr/local/lib/ffmpeg0 /usr/local/lib/freeradiu s-3.0.15 /usr/local/lib/gcc48 /usr/local/lib/gcc5 /usr/local/lib/gcc6 /usr/local/lib/gcc7 /usr/local/lib/gcc8 /usr/local/lib/gcc9 /usr/local/lib/gegl-0.2 /usr/local/lib/graphviz /usr/local/lib/httrack /usr/local/lib/itcl3.4 /usr/local/lib/jitsi/lib/native /usr/local/lib/mysql /usr/local/lib/mysql/plugin /usr/local/lib/nss /usr/local/lib/opencollada /usr/local/lib/perl5/5.24/mach/CORE /usr/local/lib/perl5/5.26/mach/CORE /usr/local/lib/perl5/5.28/mach/CORE /usr/local/lib/pgtcl /usr/local/lib/pidgin /usr/local/lib/pth /usr/local/lib/qt4 /usr/local/lib/qt5 /usr/local/lib/samba4 /usr/local/lib/xrdp /usr/local/libexec/openldap /usr/local/llvm-devel/li b /usr/local/llvm40/lib /usr/local/llvm50/lib /usr/local/llvm60/lib /usr/local/share/chromium <118>32-bit compatibility ldconfig path: /usr/lib32 /alt/i386/root/usr/local/lib /usr/local/lib32/compat <118>Setting hostname: slippy. <118>Additional TCP/IP options: rfc1323 extensions=NO. <118>Setting up harvesting: [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ET HER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED <118>Feeding entropy: . <118>Loading IP Pools. <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already present in pool <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already present in pool <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already present in pool <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already present in pool <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already present in pool <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already present in pool <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already present in pool <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already present in pool <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already present in pool <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already present in pool <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already present in pool <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already present in pool <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already present in pool <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already present in pool <118>Enabling ipfilter. <118>32:1:ioctl(add/insert rule): rule already exists <118>Installing NAT rules. <118>0 entries flushed from NAT table <118>0 entries flushed from NAT list <6>wlan0: Ethernet address: 20:6a:8a:72:03:17 <118>Created wlan(4) interfaces: wlan0. <118>Created clone interfaces: lagg0. <6>lo0: link state changed to UP <6>bge0: link state changed to DOWN iwn0: iwn_read_firmware: ucode rev=0x12a80601 <118>Starting wpa_supplicant. <6>lagg0: link state changed to DOWN iwn0: iwn_read_firmware: ucode rev=0x12a80601 <118>Starting dhclient. <118>lagg0: no link ... <6>wlan0: link state changed to UP <6>lagg0: link state changed to UP <118> got link <6>bge0: link state changed to UP <118>Starting Network: lo0 bge0 wlan0 lagg0. <118>lo0: flags=8049 metric 0 mtu 16384 <118> options=680003 <118> inet 127.0.0.1 netmask 0xff000000 <118> inet6 ::1 prefixlen 128 <118> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 <118> nd6 options=21 <118> groups: lo <118>bge0: flags=8843 metric 0 mtu 1500 <118> options=80080 <118> ether 20:6a:8a:72:03:17 <118> nd6 options=29 <118> media: Ethernet autoselect (1000baseT ) <118> status: active <118>wlan0: flags=8843 metric 0 mtu 1500 <118> ether 20:6a:8a:72:03:17 <118> nd6 options=29 <118> media: IEEE 802.11 Wireless Ethernet MCS mode 11ng <118> status: associated <118> ssid Walden_Pond channel 1 (2412 MHz 11g ht/20) bssid 4c:60:de:31:3c:17 <118> regdomain FCC country US authmode WPA2/802.11i privacy ON <118> deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 120 scanvalid 16959 <118> protmode CTS ampdulimit 64k ampdudensity 8 -amsdutx amsdurx shortgi <118> -stbc -ldpc wme roaming MANUAL <118> groups: wlan <118>lagg0: flags=8843 metric 0 mtu 1500 <118> ether 20:6a:8a:72:03:17 <118> inet6 fe80::226a:8aff:fe72:317%lagg0 prefixlen 64 scopeid 0x4 <118> inet 0.0.0.0 netmask 0x0 broadcast 255.255.255.255 <118> nd6 options=23 <118> media: Ethernet autoselect <118> status: active <118> groups: lagg <118> laggproto failover lagghash l2,l3,l4 <118> laggport: bge0 flags=5 <118> laggport: wlan0 flags=0<> <118>filter sync'd <118>Starting devd. <118>Starting ums0 moused. <118>Autoloading module: uhid.ko uhid0 on uhub2 uhid0: on usbus0 uhid1 on uhub6 uhid1: on usbus1 <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or use 'onestart' instead of 'start'. <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or use 'onestart' instead of 'start'. <118>Cannot 'start' webcamd. Set webcamd_enable to YES in /etc/rc.conf or use 'onestart' instead of 'start'. uhid2 on uhub6 uhid2: on usbus1 device_attach: uhid2 attach returned 12 <118>Cannot 'start' webcamd. Set webcamd_enable to YES in /etc/rc.conf or use 'onestart' instead of 'start'. <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or use 'onestart' instead of 'start'. <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or use 'onestart' instead of 'start'. <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or use 'onestart' instead of 'start'. <118>Starting ums1 moused. <118>Autoloading module: uhid.ko <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or use 'onestart' instead of 'start'. <118>Autoloading module: uhid.ko <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or use 'onestart' instead of 'start'. <118>local: Not in a function <118>local: Not in a function <118>dhclient not running? (check /var/run/dhclient.bge0.pid). <118>Stopping dhclient. <118>Waiting for PIDS: 471. <118>Starting dhclient. <118>add host 127.0.0.1: gateway lo0 fib 0: route already in table <118>Additional inet routing options: ignore ICMP redirect=YES log ICMP redirect=YES. <118>add host ::1: gateway lo0 fib 0: route already in table <118>add net fe80::: gateway ::1 <118>add net ff02::: gateway ::1 <118>add net ::ffff:0.0.0.0: gateway ::1 <118>add net ::0.0.0.0: gateway ::1 <118>Starting rtsold. Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80806966 stack pointer = 0x28:0xfffffe00004667d0 frame pointer = 0x28:0xfffffe0000466840 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (swi1: netisr 0) trap number = 12 panic: page fault cpuid = 3 time = 1529587144 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0000466480 vpanic() at vpanic+0x1a3/frame 0xfffffe00004664e0 panic() at panic+0x43/frame 0xfffffe0000466540 trap_fatal() at trap_fatal+0x35f/frame 0xfffffe0000466590 trap_pfault() at trap_pfault+0x49/frame 0xfffffe00004665f0 trap() at trap+0x29e/frame 0xfffffe0000466700 calltrap() at calltrap+0x8/frame 0xfffffe0000466700 --- trap 0xc, rip = 0xffffffff80806966, rsp = 0xfffffe00004667d0, rbp = 0xfffffe0000466840 --- udp_append() at udp_append+0x26/frame 0xfffffe0000466840 udp_input() at udp_input+0x574/frame 0xfffffe0000466910 ip_input() at ip_input+0x145/frame 0xfffffe0000466970 swi_net() at swi_net+0x17b/frame 0xfffffe00004669e0 intr_event_execute_handlers() at intr_event_execute_handlers+0xe9/frame 0xfffffe0000466a20 ithread_loop() at ithread_loop+0xe7/frame 0xfffffe0000466a70 fork_exit() at fork_exit+0x83/frame 0xfffffe0000466ab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0000466ab0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- Uptime: 51s Dumping 697 out of 7975 MB:..3%..12%..21%..33%..42%..51%..62%..72%..81%. .92% __curthread () at ./machine/pcpu.h:231 231 __asm("movq %%gs:%1,%0" : "=r" (td) (kgdb) bt #0 __curthread () at ./machine/pcpu.h:231 #1 doadump (textdump=1) at /opt/src/svn-current/sys/kern/kern_shutdown. c:366 #2 0xffffffff8061b330 in kern_reboot (howto=260) at /opt/src/svn-current/sys/kern/kern_shutdown.c:446 #3 0xffffffff8061b7c3 in vpanic (fmt=, ap=0xfffffe0000466520) at /opt/src/svn-current/sys/kern/kern_shutdown.c:863 #4 0xffffffff8061b5b3 in panic (fmt=) at /opt/src/svn-current/sys/kern/kern_shutdown.c:790 #5 0xffffffff8095e76f in trap_fatal (frame=0xfffffe0000466710, eva=0) at /opt/src/svn-current/sys/amd64/amd64/trap.c:892 #6 0xffffffff8095e7c9 in trap_pfault (frame=0xfffffe0000466710, usermode=0) at /opt/src/svn-current/sys/amd64/amd64/trap.c:728 #7 0xffffffff8095ddee in trap (frame=0xfffffe0000466710) at /opt/src/svn-current/sys/amd64/amd64/trap.c:427 #8 #9 udp_append (inp=0xfffff80031d2ed58, ip=0xfffff800039333a0, n=0xfffff80003933300, off=20, udp_in=0xfffffe0000466850) at /opt/src/svn-current/sys/netinet/udp_usrreq.c:314 #10 0xffffffff80806464 in udp_input (mp=, offp=, proto=17) at /opt/src/svn-current/sys/netinet/udp_usrreq.c:722 #11 0xffffffff8075f645 in ip_input (m=0x0) at /opt/src/svn-current/sys/netinet/ip_input.c:825 #12 0xffffffff8073959b in netisr_process_workstream_proto ( ---Type to continue, or q to quit---q nwsp=,Quit (kgdb) frame 9 #9 udp_append (inp=0xfffff80031d2ed58, ip=0xfffff800039333a0, n=0xfffff80003933300, off=20, udp_in=0xfffffe0000466850) at /opt/src/svn-current/sys/netinet/udp_usrreq.c:314 314 if (up->u_tun_func != NULL) { (kgdb) l 309 310 /* 311 * Engage the tunneling protocol. 312 */ 313 up = intoudpcb(inp); 314 if (up->u_tun_func != NULL) { 315 in_pcbref(inp); 316 INP_RUNLOCK(inp); 317 (*up->u_tun_func)(n, off, inp, (struct sockaddr *)&udp_in[0], 318 up->u_tun_ctx); (kgdb) p up $1 = (struct udpcb *) 0x0 (kgdb) p *inp $2 = {inp_hash = {cle_next = 0x0, cle_prev = 0xfffff800023abf70}, inp_pcbgrouphash = {cle_next = 0x0, cle_prev = 0x0}, inp_lock = { lock_object = {lo_name = 0xffffffff80a02fc7 "udpinp", lo_flags = 90898432, lo_data = 0, lo_witness = 0x0}, rw_lock = 33}, inp_hpts = { tqe_next = 0x0, tqe_prev = 0x0}, inp_hpts_request = 0, inp_in_hpts = 0 '\000', inp_in_input = 0 '\000', inp_hpts_cpu = 0, inp_refcount = 1, inp_flags = 8405056, inp_flags2 = 16, inp_input_cpu = 0, inp_hpts_cpu_set = 0 '\000', inp_input_cpu_set = 0 '\000', inp_hpts_calls = 0 '\000', inp_input_calls = 0 '\000', inp_spare_bits2 = 0 '\000', inp_spare_byte = 0 '\000', inp_ppcb = 0x0, inp_socket = 0x0, inp_hptsslot = 0, inp_hpts_drop_reas = 0, inp_input = { tqe_next = 0x0, tqe_prev = 0x0}, inp_pcbinfo = 0xfffffe0048566738, inp_pcbgroup = 0x0, inp_pcbgroup_wild = {cle_next = 0x0, cle_prev = 0x0}, inp_cred = 0xfffff80031366600, inp_flow = 0, inp_vflag = 1 '\001', inp_ip_ttl = 64 '@', inp_ip_p = 0 '\000', inp_ip_minttl = 0 '\000', inp_flowid = 60, inp_snd_tag = 0x0, inp_flowtype = 63, inp_rss_listen_bucket = 0, inp_inc = {inc_flags = 0 '\000', inc_len = 0 '\000', inc_fibnum = 0, inc_ie = {ie_fport = 0, ie_lport = 28353, ie_dependfaddr = {id46_addr = {ia46_pad32 = {0, 0, 0}, ia46_addr4 = {s_addr = 0}}, id6_addr = {__u6_addr = { __u6_addr8 = '\000' , __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}}, ie_dependladdr = { id46_addr = {ia46_pad32 = {0, 0, 0}, ia46_addr4 = { ---Type to continue, or q to quit--- s_addr = 16777343}}, id6_addr = {__u6_addr = { __u6_addr8 = '\000' , "\177\000\000\001", __u6_addr16 = {0, 0, 0, 0, 0, 0, 127, 256}, __u6_addr32 = {0, 0, 0, 16777343}}}}, ie6_zoneid = 0}}, inp_label = 0x0, inp_sp = 0xfffff8000725dee0, {inp_ip_tos = 0 '\000', inp_options = 0x0, inp_moptions = 0x0}, {in6p_options = 0x0, in6p_outputopts = 0x0, in6p_moptions = 0x0, in6p_icmp6filt = 0x0, in6p_cksum = 0, in6p_hops = 0}, inp_portlist = {cle_next = 0x0, cle_prev = 0xfffff80002334d20}, inp_phd = 0xfffff80002334d00, inp_gencnt = 169, inp_lle = 0x0, inp_rt_cookie = 7, {inp_route = {ro_rt = 0x0, ro_lle = 0x0, ro_prepend = 0x0, ro_plen = 0, ro_flags = 256, ro_mtu = 0, spare = 0, ro_dst = {sa_len = 0 '\000', sa_family = 0 '\000', sa_data = '\000' }}, inp_route6 = {ro_rt = 0x0, ro_lle = 0x0, ro_prepend = 0x0, ro_plen = 0, ro_flags = 256, ro_mtu = 0, spare = 0, ro_dst = {sin6_len = 0 '\000', sin6_family = 0 '\000', sin6_port = 0, sin6_flowinfo = 0, sin6_addr = {__u6_addr = { __u6_addr8 = '\000' , __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}}}, inp_list = {cle_next = 0xfffff80031d4e000, cle_prev = 0xfffffe0048566828}, inp_epoch_ctx = {data = {0xffffffff80759b10 , 0xfffff80002334d08}}} (kgdb) up #10 0xffffffff80806464 in udp_input (mp=, offp=, proto=17) at /opt/src/svn-current/sys/netinet/udp_usrreq.c:722 722 if (udp_append(inp, ip, m, iphlen, udp_in) == 0) (kgdb) l 717 return (IPPROTO_DONE); 718 } 719 } 720 721 UDP_PROBE(receive, NULL, inp, ip, inp, uh); 722 if (udp_append(inp, ip, m, iphlen, udp_in) == 0) 723 INP_RUNLOCK(inp); 724 return (IPPROTO_DONE); 725 726 badunlocked: (kgdb) up #11 0xffffffff8075f645 in ip_input (m=0x0) at /opt/src/svn-current/sys/netinet/ip_input.c:825 825 (*inetsw[ip_protox[ip->ip_p]].pr_input)(&m, &hlen, ip->ip_p); (kgdb) l 820 /* 821 * Switch out to protocol's input routine. 822 */ 823 IPSTAT_INC(ips_delivered); 824 825 (*inetsw[ip_protox[ip->ip_p]].pr_input)(&m, &hlen, ip->ip_p); 826 return; 827 bad: 828 m_freem(m); 829 } (kgdb) In both cases rtsold was starting. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Fri Jun 22 01:17:01 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D82971007CC8 for ; Fri, 22 Jun 2018 01:17:00 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 3ADE37793B for ; Fri, 22 Jun 2018 01:17:00 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id F272A1007CC5; Fri, 22 Jun 2018 01:16:59 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 90B211007CC4 for ; Fri, 22 Jun 2018 01:16:59 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 2E0367793A for ; Fri, 22 Jun 2018 01:16:59 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by mail-io0-x231.google.com with SMTP id k16-v6so1953587ioa.8 for ; Thu, 21 Jun 2018 18:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0z2UKdouOmlykjnGPzR/cpp3qQis7ief4W6nftxYsD8=; b=k72MiBkNXGcpZ+UUhmE11TqjFXEWp/6pX+TJxOhXboZjOOUp4ql9x/JtyGiKsJIQQh JGpC76rS7ZSAGuMw4W5MdlToOq9j0ErD3pZk5JNuSxqSiV2nPaeBt8toaaBDNuGXFy/E 0AvhMIFJPq+9FfS++A0h8Pd36N+IM545n4yurPpL9kp5BUPSKJWyLSlggoXceec3XsHs ClgjE0HUHUvwyOGx8lD9FHgx/i8aCqnas4Cb24aOVwh7KR00iAt8B2B/1eKl7NAyV4ON m7j1HTH0eP0Va0C9nRTSifI4mlRRelUdDaigbrHCcbT+8ak4NeTg5gxYJCXEJHD8tq4x i1lA== 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=0z2UKdouOmlykjnGPzR/cpp3qQis7ief4W6nftxYsD8=; b=othczO5I2VNCUpMNaqk57F81dUPrzuDjACgt1TY3QOOnBOzH8EU+wja0Tgiqgerzsb RK1InGw1Yr1qaJZCLze38DO2suoeczexVZeLa99EF/G3qPCyBXDcbsOzKs9OUctgWNpr yNptp3+o92VN1bKwlGVFrKO65N81pPg/mnueoWuXMNEmjjUZ3tD973szWFC6RfFhzJ7y VXMel24Osd2f2DnvwptwI7y6+MT1r+WyWHpy4OoXSfaKicyxnGmrDqW/Rxn+PPklGZh+ o4eBYMt9yKxpLdrPpLlU1HLRbvYn0iI0ZANAvz7BkkVRUYpMuY7xrPe9iq0YisRl5SeF CX/g== X-Gm-Message-State: APt69E2dls5Xwjk7RU1y/eQVtNxuZZUvtC/igZhv+kMsrd6+yOL270Qi OQ60ccCIPi+6G1BIQYJDzM4nRBKbdmjCbyT4m1w= X-Google-Smtp-Source: ADUXVKJFQRwv7moVBYie+W93ZMdLmYVKZyfYzTsR0Wh7CfbGfdWiEm7RFGQ/HPuebpSC1noy3aWXi85QxIkIhQSJ3TE= X-Received: by 2002:a6b:d00c:: with SMTP id x12-v6mr11350040ioa.5.1529630218147; Thu, 21 Jun 2018 18:16:58 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:8cd:0:0:0:0:0 with HTTP; Thu, 21 Jun 2018 18:16:57 -0700 (PDT) In-Reply-To: <201806220114.w5M1EqeX034820@slippy.cwsent.com> References: <20180620090957.GA130@x2.osted.lan> <201806220114.w5M1EqeX034820@slippy.cwsent.com> From: Matthew Macy Date: Thu, 21 Jun 2018 18:16:57 -0700 Message-ID: Subject: Re: Page fault in udp_usrreq.c:823 To: Cy Schubert Cc: Peter Holm , current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Fri, 22 Jun 2018 01:35:44 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 22 Jun 2018 01:17:01 -0000 Try updating. It should be fixed. On Thu, Jun 21, 2018 at 6:14 PM, Cy Schubert wrote: > In message <20180620090957.GA130@x2.osted.lan>, Peter Holm writes: >> 20180620 10:32:47 all (1/1): udp.sh >> Kernel page fault with the following non-sleepable locks held: >> shared rw udpinp (udpinp) r = 0 (0xfffff80bbc808d78) locked @ netinet/in_pcb. >> c:2398 >> stack backtrace: >> #0 0xffffffff80c00733 at witness_debugger+0x73 >> #1 0xffffffff80c01b11 at witness_warn+0x461 >> #2 0xffffffff81075763 at trap_pfault+0x53 >> #3 0xffffffff81074d7a at trap+0x2ba >> #4 0xffffffff8105076c at calltrap+0x8 >> #5 0xffffffff80dd21b0 at udp_ctlinput+0x50 >> #6 0xffffffff80d3081d at icmp_input+0x96d >> #7 0xffffffff80d316d7 at ip_input+0x3f7 >> #8 0xffffffff80cc0a92 at netisr_dispatch_src+0xa2 >> #9 0xffffffff80ca3ebe at ether_demux+0x16e >> #10 0xffffffff80ca5377 at ether_nh_input+0x427 >> #11 0xffffffff80cc0a92 at netisr_dispatch_src+0xa2 >> #12 0xffffffff80ca437f at ether_input+0x8f >> #13 0xffffffff80cbc500 at iflib_rxeof+0xc90 >> #14 0xffffffff80cb6b6f at _task_fn_rx+0x7f >> #15 0xffffffff80bdd209 at gtaskqueue_run_locked+0x139 >> #16 0xffffffff80bdcf88 at gtaskqueue_thread_loop+0x88 >> #17 0xffffffff80b54514 at fork_exit+0x84 >> >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 10; apic id = 0a >> fault virtual address = 0x8 >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0xffffffff80dd2423 >> stack pointer = 0x0:0xfffffe00004a5500 >> frame pointer = 0x0:0xfffffe00004a55a0 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 0 (if_io_tqg_10) >> [ thread pid 0 tid 100069 ] >> Stopped at udp_common_ctlinput+0x263: cmpq $0,0x8(%rax) >> db> >> >> Details @ https://people.freebsd.org/~pho/stress/log/udp_usrreq.txt >> >> -- >> Peter >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > > This is surprisingly similar to my panic. Twice since June 19. > > slippy# kgdb /boot/kernel/kernel vmcore.3 > GNU gdb (GDB) 8.1 [GDB v8.1 for FreeBSD] > Copyright (C) 2018 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "x86_64-portbld-freebsd12.0". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > . > Find the GDB manual and other documentation resources online at: > . > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from /boot/kernel/kernel...Reading symbols from > /usr/lib/debug//boot/kernel/kernel.debug...done. > done. > > Unread portion of the kernel message buffer: > Copyright (c) 1992-2018 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 #355 r335477M: Thu Jun 21 05:26:35 PDT 2018 > root@slippy:/export/obj/opt/src/svn-current/amd64.amd64/sys/BREAK > amd64 > FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on > LLVM 6.0.0) > VT(vga): text 80x25 > module_register: cannot register mmc/mmcsd from kernel; already loaded > from mmcsd.ko > Module mmc/mmcsd failed to register: 17 > CPU: Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz (2294.83-MHz K8-class CPU) > Origin="GenuineIntel" Id=0x206a7 Family=0x6 Model=0x2a Stepping=7 > Features=0xbfebfbff GE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > Features2=0x1dbae3bf 3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,XSAVE,OSXSAVE,A > VX> > AMD Features=0x28100800 > AMD Features2=0x1 > XSAVE Features=0x1 > VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID > TSC: P-state invariant, performance statistics > real memory = 8589934592 (8192 MB) > avail memory = 8080965632 (7706 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads > random: unblocking device. > ioapic0 irqs 0-23 on motherboard > random: entropy device external interface > module_register_init: MOD_LOAD (vesa, 0xffffffff8097b700, 0) error 19 > kbd1 at kbdmux0 > nexus0 > vtvga0: on motherboard > cryptosoft0: on motherboard > acpi0: on motherboard > acpi0: Power Button (fixed) > cpu0: on acpi0 > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 950 > Event timer "HPET" frequency 14318180 Hz quality 550 > Event timer "HPET1" frequency 14318180 Hz quality 440 > Event timer "HPET2" frequency 14318180 Hz quality 440 > Event timer "HPET3" frequency 14318180 Hz quality 440 > Event timer "HPET4" frequency 14318180 Hz quality 440 > atrtc0: port 0x70-0x77 irq 8 on acpi0 > atrtc0: Warning: Couldn't map I/O. > atrtc0: registered as a time-of-day clock, resolution 1.000000s > attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > acpi_ec0: port 0x62,0x66 on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > vgapci0: port 0x2000-0x203f mem > 0xf0000000-0xf03fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 > vgapci0: Boot video device > pci0: at device 22.0 (no driver attached) > ehci0: mem > 0xf060a000-0xf060a3ff irq 16 at device 26.0 on pci0 > usbus0: EHCI version 1.0 > usbus0 on ehci0 > hdac0: mem 0xf0600000-0xf0603fff > irq 22 at device 27.0 on pci0 > pcib1: irq 16 at device 28.0 on pci0 > pci1: on pcib1 > pcib2: irq 17 at device 28.1 on pci0 > pci2: on pcib2 > iwn0: mem 0xf0500000-0xf0501fff irq 17 > at device 0.0 on pci2 > pcib3: irq 19 at device 28.3 on pci0 > pci3: on pcib3 > bge0: mem > 0xf0400000-0xf040ffff,0xf0410000-0xf041ffff irq 19 at device 0.0 on pci3 > bge0: CHIP ID 0x57785100; ASIC REV 0x57785; CHIP REV 0x577851; PCI-E > miibus0: on bge0 > brgphy0: PHY 1 on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > <6>bge0: Using defaults for TSO: 65518/35/2048 > <6>bge0: Ethernet address: 20:6a:8a:72:03:17 > pci3: at device 0.1 (no driver > attached) > ehci1: mem > 0xf0609000-0xf06093ff irq 23 at device 29.0 on pci0 > usbus1: EHCI version 1.0 > usbus1 on ehci1 > isab0: at device 31.0 on pci0 > isa0: on isab0 > ahci0: port > 0x2088-0x208f,0x2094-0x2097,0x2080-0x2087,0x2090-0x2093,0x2060-0x207f > mem 0xf0608000-0xf06087ff irq 19 at device 31.2 on pci0 > ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported > ahcich0: at channel 0 on ahci0 > ahcich1: at channel 1 on ahci0 > ahcich5: at channel 5 on ahci0 > ahciem0: on ahci0 > ichsmb0: port 0xefa0-0xefbf mem > 0xf0604000-0xf06040ff irq 18 at device 31.3 on pci0 > smbus0: on ichsmb0 > smb0: on smbus0 > acpi_lid0: on acpi0 > acpi_button0: on acpi0 > acpi_tz0: on acpi0 > acpi_tz1: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: model Synaptics Touchpad, device ID 0 > acpi_acad0: on acpi0 > battery0: on acpi0 > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff pnpid > PNP0900 on isa0 > ata0: at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 > ata1: at port 0x170-0x177,0x376 irq 15 on isa0 > acpi_perf0: on cpu0 > coretemp0: on cpu0 > ZFS filesystem version: 5 > ZFS storage pool version: features support (5000) > Timecounters tick every 10.000 msec > IP Filter: v5.1.2 initialized. Default = pass all, Logging = enabled > hdacc0: at cad 0 on hdac0 > hdaa0: at nid 1 on hdacc0 > pcm0: at nid 20,33 and 27 on hdaa0 > pcm1: at nid 24 on hdaa0 > hdacc1: at cad 3 on hdac0 > hdaa1: at nid 1 on hdacc1 > pcm2: at nid 5 on hdaa1 > usbus0: 480Mbps High Speed USB v2.0 > usbus1: 480Mbps High Speed USB v2.0 > ugen1.1: at usbus1 > uhub0: on usbus1 > ugen0.1: at usbus0 > uhub1: on usbus0 > ses0 at ahciem0 bus 0 scbus3 target 0 lun 0 > ses0: SEMB S-E-S 2.00 device > ses0: SEMB SES Device > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ATA8-ACS SATA 3.x device > ada0: Serial Number JR1000D33969RE > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 953869MB (1953525168 512 byte sectors) > cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 > cd0: Removable CD-ROM SCSI device > cd0: Serial Number SBB5103801 > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO > 8192bytes) > cd0: Attempt to query device size failed: NOT READY, Medium not present > - tray closed > Launching APs: 1 3 2 > Trying to mount root from ufs:/dev/ufs/Sroot [rw]... > Timecounter "TSC-low" frequency 1147416846 Hz quality 1000 > <118>Setting hostuuid: 34f5ed40-8938-11da-b265-efe316da850d. > <118>Setting hostid: 0x7f5a03b9. > uhub0: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > ugen0.2: at usbus0 > uhub2 on uhub1 > uhub2: > on usbus0 > ugen1.2: at usbus1 > uhub3 on uhub0 > uhub3: > on usbus1 > uhub2: 6 ports with 6 removable, self powered > uhub3: 6 ports with 6 removable, self powered > ugen0.3: at usbus0 > ukbd0 on uhub2 > ukbd0: on > usbus0 > kbd2 at ukbd0 > ums0 on uhub2 > ums0: on > usbus0 > ums0: 16 buttons and [XYZT] coordinates ID=2 > ugen1.3: at usbus1 > uhub4 on uhub3 > uhub4: on > usbus1 > uhub4: 4 ports with 4 removable, self powered > ugen0.4: at usbus0 > ugen1.4: at usbus1 > uhub5 on uhub4 > uhub5: on > usbus1 > uhub5: 4 ports with 4 removable, self powered > ugen1.5: at usbus1 > uhub6 on uhub5 > uhub6: on > usbus1 > uhub6: 4 ports with 4 removable, self powered > ugen1.6: at usbus1 > ukbd1 on uhub6 > ukbd1: on > usbus1 > kbd3 at ukbd1 > ums1 on uhub6 > ums1: on > usbus1 > ums1: 16 buttons and [XYZT] coordinates ID=2 > ugen1.7: at usbus1 > ukbd2 on uhub6 > ukbd2: on > usbus1 > kbd4 at ukbd2 > ugen1.8: at usbus1 > umass0 on uhub5 > umass0: on > usbus1 > umass0: SCSI over Bulk-Only; quirks = 0x408c > umass0:6:0: Attached to scbus6 > da0 at umass-sim0 bus 0 scbus6 target 0 lun 0 > da0: Fixed Direct Access SCSI device > da0: 40.000MB/s transfers > da0: 76319MB (156301488 512 byte sectors) > da0: quirks=0x2 > <118>Starting file system checks: > <118>/dev/ufs/Sroot: FILE SYSTEM CLEAN; SKIPPING CHECKS > <118>/dev/ufs/Sroot: clean, 413829 free (909 frags, 51615 blocks, 0.2% > fragmentation) > <118>/dev/ufs/Susr: FILE SYSTEM CLEAN; SKIPPING CHECKS > <118>/dev/ufs/Susr: clean, 459287 free (4847 frags, 56805 blocks, 0.6% > fragmentation) > <118>/dev/ufs/Svtmp: FILE SYSTEM CLEAN; SKIPPING CHECKS > <118>/dev/ufs/Svtmp: clean, 503642 free (50 frags, 62949 blocks, 0.0% > fragmentation) > <118>/dev/ufs/SCusr: FILE SYSTEM CLEAN; SKIPPING CHECKS > <118>/dev/ufs/Svar: FILE SYSTEM CLEAN; SKIPPING CHECKS > <118>/dev/ufs/SSusr: FILE SYSTEM CLEAN; SKIPPING CHECKS > <118>/dev/ufs/SCusr: clean, 469826 free (4578 frags, 58156 blocks, 0.6% > fragmentation) > <118>/dev/ufs/Svar: clean, 453726 free (574 frags, 56644 blocks, 0.1% > fragmentation) > <118>/dev/ufs/SCroot: FILE SYSTEM CLEAN; SKIPPING CHECKS > <118>/dev/ufs/SSusr: clean, 569245 free (3653 frags, 70699 blocks, 0.5% > fragmentation) > <118>/dev/ufs/SCroot: clean, 422625 free (617 frags, 52751 blocks, 0.1% > fragmentation) > <118>/dev/ufs/SCvar: FILE SYSTEM CLEAN; SKIPPING CHECKS > <118>/dev/ufs/SSvar: FILE SYSTEM CLEAN; SKIPPING CHECKS > <118>/dev/ufs/SCvar: clean, 400011 free (99 frags, 49989 blocks, 0.0% > fragmentation) > <118>/dev/ufs/SSvar: clean, 457058 free (138 frags, 57115 blocks, 0.0% > fragmentation) > <118>/dev/ufs/SSroot: FILE SYSTEM CLEAN; SKIPPING CHECKS > <118>/dev/ufs/SSroot: clean, 412995 free (219 frags, 51597 blocks, 0.0% > fragmentation) > <118>/dev/msdosfs/SHARED: FILESYSTEM CLEAN; SKIPPING CHECKS > <118>/dev/zvol/tank/VMs/current/i386/disk0s1a: FILE SYSTEM CLEAN; > SKIPPING CHECKS > <118>/dev/zvol/tank/VMs/current/i386/disk0s1a: clean, 254465 free (337 > frags, 31766 blocks, 0.1% fragmentation) > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1a: FILE SYSTEM CLEAN; > SKIPPING CHECKS > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1a: FILE SYSTEM CLEAN; > SKIPPING CHECKS > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1a: clean, 335508 free > (1348 frags, 41770 blocks, 0.1% fragmentation) > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1a: clean, 566833 free > (2297 frags, 70567 blocks, 0.2% fragmentation) > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1a: FILE SYSTEM CLEAN; > SKIPPING CHECKS > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1a: FILE SYSTEM CLEAN; > SKIPPING CHECKS > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1a: clean, 510529 free > (1185 frags, 63668 blocks, 0.1% fragmentation) > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1a: clean, 354656 free (336 > frags, 44290 blocks, 0.1% fragmentation) > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1a: FILE SYSTEM CLEAN; > SKIPPING CHECKS > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1a: clean, 633994 free > (2106 frags, 78986 blocks, 0.2% fragmentation) > <118>/dev/zvol/tank/VMs/current/amd64/disk3p1: FILE SYSTEM CLEAN; > SKIPPING CHECKS > <118>/dev/zvol/tank/VMs/current/amd64/disk3p1: clean, 2535564 free (564 > frags, 316875 blocks, 0.0% fragmentation) > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1d: FILE SYSTEM CLEAN; > SKIPPING CHECKS > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1d: clean, 897924 free > (188 frags, 112217 blocks, 0.0% fragmentation) > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1d: FILE SYSTEM CLEAN; > SKIPPING CHECKS > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1d: clean, 897896 free > (152 frags, 112218 blocks, 0.0% fragmentation) > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1d: FILE SYSTEM CLEAN; > SKIPPING CHECKS > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1d: FILE SYSTEM CLEAN; > SKIPPING CHECKS > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1d: clean, 889422 free (214 > frags, 111151 blocks, 0.0% fragmentation) > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1d: clean, 889419 free (219 > frags, 111150 blocks, 0.0% fragmentation) > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1d: FILE SYSTEM CLEAN; > SKIPPING CHECKS > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1d: clean, 408410 free (90 > frags, 51040 blocks, 0.0% fragmentation) > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1e: FILE SYSTEM CLEAN; > SKIPPING CHECKS > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1e: FILE SYSTEM CLEAN; > SKIPPING CHECKS > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1e: clean, 1230068 free > (7300 frags, 152846 blocks, 0.5% fragmentation) > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1e: clean, 726361 free > (6297 frags, 90008 blocks, 0.4% fragmentation) > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1e: FILE SYSTEM CLEAN; > SKIPPING CHECKS > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1e: clean, 1299097 free > (6385 frags, 161589 blocks, 0.4% fragmentation) > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1e: FILE SYSTEM CLEAN; > SKIPPING CHECKS > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1e: clean, 822303 free > (1047 frags, 102657 blocks, 0.1% fragmentation) > <118>/dev/zvol/tank/VMs/current/i386/disk0s1d: FILE SYSTEM CLEAN; > SKIPPING CHECKS > <118>/dev/zvol/tank/VMs/current/i386/disk0s1d: clean, 399855 free (15 > frags, 49980 blocks, 0.0% fragmentation) > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1e: FILE SYSTEM CLEAN; > SKIPPING CHECKS > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1e: clean, 937324 free > (7524 frags, 116225 blocks, 0.5% fragmentation) > <118>/dev/zvol/tank/VMs/current/i386/disk0s1e: FILE SYSTEM CLEAN; > SKIPPING CHECKS > <118>/dev/zvol/tank/VMs/current/i386/disk0s1e: clean, 1077125 free (845 > frags, 134535 blocks, 0.1% fragmentation) > <118>Mounting local filesystems:. > <118>ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib > /usr/local/lib/compat/pkg /usr/local/krb5/lib /usr/local/kde4/lib > /usr/local/lib/compat /usr/local/lib/compat/pkg /usr/local/lib/dovecot > /usr/local/lib/e2fsprogs /usr/local/lib/ffmpeg0 /usr/local/lib/freeradiu > s-3.0.15 /usr/local/lib/gcc48 /usr/local/lib/gcc5 /usr/local/lib/gcc6 > /usr/local/lib/gcc7 /usr/local/lib/gcc8 /usr/local/lib/gcc9 > /usr/local/lib/gegl-0.2 /usr/local/lib/graphviz /usr/local/lib/httrack > /usr/local/lib/itcl3.4 /usr/local/lib/jitsi/lib/native > /usr/local/lib/mysql /usr/local/lib/mysql/plugin /usr/local/lib/nss > /usr/local/lib/opencollada /usr/local/lib/perl5/5.24/mach/CORE > /usr/local/lib/perl5/5.26/mach/CORE /usr/local/lib/perl5/5.28/mach/CORE > /usr/local/lib/pgtcl /usr/local/lib/pidgin /usr/local/lib/pth > /usr/local/lib/qt4 /usr/local/lib/qt5 /usr/local/lib/samba4 > /usr/local/lib/xrdp /usr/local/libexec/openldap /usr/local/llvm-devel/li > b /usr/local/llvm40/lib /usr/local/llvm50/lib /usr/local/llvm60/lib > /usr/local/share/chromium > <118>32-bit compatibility ldconfig path: /usr/lib32 > /alt/i386/root/usr/local/lib /usr/local/lib32/compat > <118>Setting hostname: slippy. > <118>Additional TCP/IP options: rfc1323 extensions=NO. > <118>Setting up harvesting: [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ET > HER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED > <118>Feeding entropy: . > <118>Loading IP Pools. > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > present in pool > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > present in pool > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > present in pool > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > present in pool > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > present in pool > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > present in pool > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > present in pool > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > present in pool > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > present in pool > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > present in pool > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > present in pool > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > present in pool > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > present in pool > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > present in pool > <118>Enabling ipfilter. > <118>32:1:ioctl(add/insert rule): rule already exists > <118>Installing NAT rules. > <118>0 entries flushed from NAT table > <118>0 entries flushed from NAT list > <6>wlan0: Ethernet address: 20:6a:8a:72:03:17 > <118>Created wlan(4) interfaces: wlan0. > <118>Created clone interfaces: lagg0. > <6>lo0: link state changed to UP > <6>bge0: link state changed to DOWN > iwn0: iwn_read_firmware: ucode rev=0x12a80601 > <118>Starting wpa_supplicant. > <6>lagg0: link state changed to DOWN > iwn0: iwn_read_firmware: ucode rev=0x12a80601 > <118>Starting dhclient. > <118>lagg0: no link ... > <6>wlan0: link state changed to UP > <6>lagg0: link state changed to UP > <118> got link > <6>bge0: link state changed to UP > <118>Starting Network: lo0 bge0 wlan0 lagg0. > <118>lo0: flags=8049 metric 0 mtu 16384 > <118> options=680003 > <118> inet 127.0.0.1 netmask 0xff000000 > <118> inet6 ::1 prefixlen 128 > <118> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > <118> nd6 options=21 > <118> groups: lo > <118>bge0: flags=8843 metric 0 > mtu 1500 > <118> options=80080 > <118> ether 20:6a:8a:72:03:17 > <118> nd6 options=29 > <118> media: Ethernet autoselect (1000baseT ) > <118> status: active > <118>wlan0: flags=8843 metric 0 > mtu 1500 > <118> ether 20:6a:8a:72:03:17 > <118> nd6 options=29 > <118> media: IEEE 802.11 Wireless Ethernet MCS mode 11ng > <118> status: associated > <118> ssid Walden_Pond channel 1 (2412 MHz 11g ht/20) bssid > 4c:60:de:31:3c:17 > <118> regdomain FCC country US authmode WPA2/802.11i privacy ON > <118> deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 120 scanvalid > 16959 > <118> protmode CTS ampdulimit 64k ampdudensity 8 -amsdutx amsdurx > shortgi > <118> -stbc -ldpc wme roaming MANUAL > <118> groups: wlan > <118>lagg0: flags=8843 metric 0 > mtu 1500 > <118> ether 20:6a:8a:72:03:17 > <118> inet6 fe80::226a:8aff:fe72:317%lagg0 prefixlen 64 scopeid 0x4 > <118> inet 0.0.0.0 netmask 0x0 broadcast 255.255.255.255 > <118> nd6 options=23 > <118> media: Ethernet autoselect > <118> status: active > <118> groups: lagg > <118> laggproto failover lagghash l2,l3,l4 > <118> laggport: bge0 flags=5 > <118> laggport: wlan0 flags=0<> > <118>filter sync'd > <118>Starting devd. > <118>Starting ums0 moused. > <118>Autoloading module: uhid.ko > uhid0 on uhub2 > uhid0: on > usbus0 > uhid1 on uhub6 > uhid1: on > usbus1 > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > use 'onestart' instead of 'start'. > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > use 'onestart' instead of 'start'. > <118>Cannot 'start' webcamd. Set webcamd_enable to YES in /etc/rc.conf > or use 'onestart' instead of 'start'. > uhid2 on uhub6 > uhid2: on > usbus1 > device_attach: uhid2 attach returned 12 > <118>Cannot 'start' webcamd. Set webcamd_enable to YES in /etc/rc.conf > or use 'onestart' instead of 'start'. > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > use 'onestart' instead of 'start'. > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > use 'onestart' instead of 'start'. > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > use 'onestart' instead of 'start'. > <118>Starting ums1 moused. > <118>Autoloading module: uhid.ko > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > use 'onestart' instead of 'start'. > <118>Autoloading module: uhid.ko > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > use 'onestart' instead of 'start'. > <118>local: Not in a function > <118>local: Not in a function > <118>dhclient not running? (check /var/run/dhclient.bge0.pid). > <118>Stopping dhclient. > <118>Waiting for PIDS: 471. > <118>Starting dhclient. > <118>add host 127.0.0.1: gateway lo0 fib 0: route already in table > <118>Additional inet routing options: ignore ICMP redirect=YES log ICMP > redirect=YES. > <118>add host ::1: gateway lo0 fib 0: route already in table > <118>add net fe80::: gateway ::1 > <118>add net ff02::: gateway ::1 > <118>add net ::ffff:0.0.0.0: gateway ::1 > <118>add net ::0.0.0.0: gateway ::1 > <118>Starting rtsold. > > > Fatal trap 12: page fault while in kernel mode > cpuid = 3; apic id = 03 > fault virtual address = 0x0 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff80806966 > stack pointer = 0x28:0xfffffe00004667d0 > frame pointer = 0x28:0xfffffe0000466840 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 12 (swi1: netisr 0) > trap number = 12 > panic: page fault > cpuid = 3 > time = 1529587144 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe0000466480 > vpanic() at vpanic+0x1a3/frame 0xfffffe00004664e0 > panic() at panic+0x43/frame 0xfffffe0000466540 > trap_fatal() at trap_fatal+0x35f/frame 0xfffffe0000466590 > trap_pfault() at trap_pfault+0x49/frame 0xfffffe00004665f0 > trap() at trap+0x29e/frame 0xfffffe0000466700 > calltrap() at calltrap+0x8/frame 0xfffffe0000466700 > --- trap 0xc, rip = 0xffffffff80806966, rsp = 0xfffffe00004667d0, rbp = > 0xfffffe0000466840 --- > udp_append() at udp_append+0x26/frame 0xfffffe0000466840 > udp_input() at udp_input+0x574/frame 0xfffffe0000466910 > ip_input() at ip_input+0x145/frame 0xfffffe0000466970 > swi_net() at swi_net+0x17b/frame 0xfffffe00004669e0 > intr_event_execute_handlers() at intr_event_execute_handlers+0xe9/frame > 0xfffffe0000466a20 > ithread_loop() at ithread_loop+0xe7/frame 0xfffffe0000466a70 > fork_exit() at fork_exit+0x83/frame 0xfffffe0000466ab0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0000466ab0 > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > Uptime: 51s > Dumping 697 out of 7975 MB:..3%..12%..21%..33%..42%..51%..62%..72%..81%. > .92% > > __curthread () at ./machine/pcpu.h:231 > 231 __asm("movq %%gs:%1,%0" : "=r" (td) > (kgdb) bt > #0 __curthread () at ./machine/pcpu.h:231 > #1 doadump (textdump=1) at /opt/src/svn-current/sys/kern/kern_shutdown. > c:366 > #2 0xffffffff8061b330 in kern_reboot (howto=260) > at /opt/src/svn-current/sys/kern/kern_shutdown.c:446 > #3 0xffffffff8061b7c3 in vpanic (fmt=, > ap=0xfffffe0000466520) > at /opt/src/svn-current/sys/kern/kern_shutdown.c:863 > #4 0xffffffff8061b5b3 in panic (fmt=) > at /opt/src/svn-current/sys/kern/kern_shutdown.c:790 > #5 0xffffffff8095e76f in trap_fatal (frame=0xfffffe0000466710, eva=0) > at /opt/src/svn-current/sys/amd64/amd64/trap.c:892 > #6 0xffffffff8095e7c9 in trap_pfault (frame=0xfffffe0000466710, > usermode=0) > at /opt/src/svn-current/sys/amd64/amd64/trap.c:728 > #7 0xffffffff8095ddee in trap (frame=0xfffffe0000466710) > at /opt/src/svn-current/sys/amd64/amd64/trap.c:427 > #8 > #9 udp_append (inp=0xfffff80031d2ed58, ip=0xfffff800039333a0, > n=0xfffff80003933300, off=20, udp_in=0xfffffe0000466850) > at /opt/src/svn-current/sys/netinet/udp_usrreq.c:314 > #10 0xffffffff80806464 in udp_input (mp=, > offp=, > proto=17) at /opt/src/svn-current/sys/netinet/udp_usrreq.c:722 > #11 0xffffffff8075f645 in ip_input (m=0x0) > at /opt/src/svn-current/sys/netinet/ip_input.c:825 > #12 0xffffffff8073959b in netisr_process_workstream_proto ( > ---Type to continue, or q to quit---q > nwsp=,Quit > (kgdb) frame 9 > #9 udp_append (inp=0xfffff80031d2ed58, ip=0xfffff800039333a0, > n=0xfffff80003933300, off=20, udp_in=0xfffffe0000466850) > at /opt/src/svn-current/sys/netinet/udp_usrreq.c:314 > 314 if (up->u_tun_func != NULL) { > (kgdb) l > 309 > 310 /* > 311 * Engage the tunneling protocol. > 312 */ > 313 up = intoudpcb(inp); > 314 if (up->u_tun_func != NULL) { > 315 in_pcbref(inp); > 316 INP_RUNLOCK(inp); > 317 (*up->u_tun_func)(n, off, inp, (struct sockaddr *)&udp_in[0], > 318 up->u_tun_ctx); > (kgdb) p up > $1 = (struct udpcb *) 0x0 > (kgdb) p *inp > $2 = {inp_hash = {cle_next = 0x0, cle_prev = 0xfffff800023abf70}, > inp_pcbgrouphash = {cle_next = 0x0, cle_prev = 0x0}, inp_lock = { > lock_object = {lo_name = 0xffffffff80a02fc7 "udpinp", lo_flags = > 90898432, > lo_data = 0, lo_witness = 0x0}, rw_lock = 33}, inp_hpts = { > tqe_next = 0x0, tqe_prev = 0x0}, inp_hpts_request = 0, > inp_in_hpts = 0 '\000', inp_in_input = 0 '\000', inp_hpts_cpu = 0, > inp_refcount = 1, inp_flags = 8405056, inp_flags2 = 16, inp_input_cpu > = 0, > inp_hpts_cpu_set = 0 '\000', inp_input_cpu_set = 0 '\000', > inp_hpts_calls = 0 '\000', inp_input_calls = 0 '\000', > inp_spare_bits2 = 0 '\000', inp_spare_byte = 0 '\000', inp_ppcb = > 0x0, > inp_socket = 0x0, inp_hptsslot = 0, inp_hpts_drop_reas = 0, inp_input > = { > tqe_next = 0x0, tqe_prev = 0x0}, inp_pcbinfo = 0xfffffe0048566738, > inp_pcbgroup = 0x0, inp_pcbgroup_wild = {cle_next = 0x0, cle_prev = > 0x0}, > inp_cred = 0xfffff80031366600, inp_flow = 0, inp_vflag = 1 '\001', > inp_ip_ttl = 64 '@', inp_ip_p = 0 '\000', inp_ip_minttl = 0 '\000', > inp_flowid = 60, inp_snd_tag = 0x0, inp_flowtype = 63, > inp_rss_listen_bucket = 0, inp_inc = {inc_flags = 0 '\000', > inc_len = 0 '\000', inc_fibnum = 0, inc_ie = {ie_fport = 0, > ie_lport = 28353, ie_dependfaddr = {id46_addr = {ia46_pad32 = {0, > 0, 0}, > ia46_addr4 = {s_addr = 0}}, id6_addr = {__u6_addr = { > __u6_addr8 = '\000' , __u6_addr16 = {0, > 0, 0, 0, > 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}}, > ie_dependladdr = { > id46_addr = {ia46_pad32 = {0, 0, 0}, ia46_addr4 = { > ---Type to continue, or q to quit--- > s_addr = 16777343}}, id6_addr = {__u6_addr = { > __u6_addr8 = '\000' , "\177\000\000\001", > __u6_addr16 = {0, 0, 0, 0, 0, 0, 127, 256}, __u6_addr32 = > {0, 0, > 0, 16777343}}}}, ie6_zoneid = 0}}, inp_label = 0x0, > inp_sp = 0xfffff8000725dee0, {inp_ip_tos = 0 '\000', inp_options = > 0x0, > inp_moptions = 0x0}, {in6p_options = 0x0, in6p_outputopts = 0x0, > in6p_moptions = 0x0, in6p_icmp6filt = 0x0, in6p_cksum = 0, > in6p_hops = 0}, > inp_portlist = {cle_next = 0x0, cle_prev = 0xfffff80002334d20}, > inp_phd = 0xfffff80002334d00, inp_gencnt = 169, inp_lle = 0x0, > inp_rt_cookie = 7, {inp_route = {ro_rt = 0x0, ro_lle = 0x0, > ro_prepend = 0x0, ro_plen = 0, ro_flags = 256, ro_mtu = 0, spare > = 0, > ro_dst = {sa_len = 0 '\000', sa_family = 0 '\000', > sa_data = '\000' }}, inp_route6 = {ro_rt = > 0x0, > ro_lle = 0x0, ro_prepend = 0x0, ro_plen = 0, ro_flags = 256, > ro_mtu = 0, > spare = 0, ro_dst = {sin6_len = 0 '\000', sin6_family = 0 '\000', > sin6_port = 0, sin6_flowinfo = 0, sin6_addr = {__u6_addr = { > __u6_addr8 = '\000' , __u6_addr16 = {0, > 0, 0, 0, > 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id > = 0}}}, > inp_list = {cle_next = 0xfffff80031d4e000, cle_prev = > 0xfffffe0048566828}, > inp_epoch_ctx = {data = {0xffffffff80759b10 , > 0xfffff80002334d08}}} > (kgdb) up > #10 0xffffffff80806464 in udp_input (mp=, > offp=, > proto=17) at /opt/src/svn-current/sys/netinet/udp_usrreq.c:722 > 722 if (udp_append(inp, ip, m, iphlen, udp_in) == 0) > (kgdb) l > 717 return (IPPROTO_DONE); > 718 } > 719 } > 720 > 721 UDP_PROBE(receive, NULL, inp, ip, inp, uh); > 722 if (udp_append(inp, ip, m, iphlen, udp_in) == 0) > 723 INP_RUNLOCK(inp); > 724 return (IPPROTO_DONE); > 725 > 726 badunlocked: > (kgdb) up > #11 0xffffffff8075f645 in ip_input (m=0x0) > at /opt/src/svn-current/sys/netinet/ip_input.c:825 > 825 (*inetsw[ip_protox[ip->ip_p]].pr_input)(&m, &hlen, ip->ip_p); > (kgdb) l > 820 /* > 821 * Switch out to protocol's input routine. > 822 */ > 823 IPSTAT_INC(ips_delivered); > 824 > 825 (*inetsw[ip_protox[ip->ip_p]].pr_input)(&m, &hlen, ip->ip_p); > 826 return; > 827 bad: > 828 m_freem(m); > 829 } > (kgdb) > > > In both cases rtsold was starting. > > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > The need of the many outweighs the greed of the few. > > > _______________________________________________ > 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 Fri Jun 22 01:41:51 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AEA5310098C4 for ; Fri, 22 Jun 2018 01:41:51 +0000 (UTC) (envelope-from cy.schubert@cschubert.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 0D4C97855C for ; Fri, 22 Jun 2018 01:41:51 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: by mailman.ysv.freebsd.org (Postfix) id BCBBC10098C3; Fri, 22 Jun 2018 01:41:50 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7533710098C2 for ; Fri, 22 Jun 2018 01:41:50 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DD41F7855A for ; Fri, 22 Jun 2018 01:41:49 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id WB53fjQMqSzNNWB55fWfSb; Thu, 21 Jun 2018 19:41:43 -0600 X-Authority-Analysis: v=2.3 cv=KuxjJ1eN c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=7mUfYlMuFuIA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=xfDLHkLGAAAA:8 a=mDV3o1hIAAAA:8 a=7MkQZppbYTRF0_BNoYsA:9 a=sJY53Wz5yUy_6kM8:21 a=RfnrApy-ugBsw2io:21 a=XqE05Yf1wqetR3ZW:21 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=IfaqVvZgccqrtc8gcwf2:22 a=_FVE-zBwftR9WsbkzFJk:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id DCA7A95C; Thu, 21 Jun 2018 18:41:40 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id w5M1feXG081510; Thu, 21 Jun 2018 18:41:40 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id w5M1fdOb081507; Thu, 21 Jun 2018 18:41:40 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201806220141.w5M1fdOb081507@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Matthew Macy cc: Cy Schubert , Peter Holm , current@freebsd.org Subject: Re: Page fault in udp_usrreq.c:823 In-Reply-To: Message from Matthew Macy of "Thu, 21 Jun 2018 18:16:57 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Jun 2018 18:41:39 -0700 X-CMAE-Envelope: MS4wfD/mPAunWmCGNPo4qjuqyLM71KvaeJNnPTQ0FXxEKp4ayi0shQ+QAKJqQ0aqj/G+hwFAKz+PDvT45cIv+QIa3xR7rbTFe7p9ylqYnqQPxItWX+12wOUa lwUb6mNLW0xTIwOhl496izz+D+tSrUFJPvwvtfgKZYfpXtfSjms+8CTr1M49QeA8PQdmvX9qqEL13uqQzUiSXe1PcuonsG0i804RO23UhHt0mZEzSvYlf5L5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 22 Jun 2018 01:41:52 -0000 Like as of now? The last panic occurred this morning after a build last night. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. In message , Matthew Macy writes: > Try updating. It should be fixed. > > On Thu, Jun 21, 2018 at 6:14 PM, Cy Schubert wrot > e: > > In message <20180620090957.GA130@x2.osted.lan>, Peter Holm writes: > >> 20180620 10:32:47 all (1/1): udp.sh > >> Kernel page fault with the following non-sleepable locks held: > >> shared rw udpinp (udpinp) r = 0 (0xfffff80bbc808d78) locked @ netinet/in_p > cb. > >> c:2398 > >> stack backtrace: > >> #0 0xffffffff80c00733 at witness_debugger+0x73 > >> #1 0xffffffff80c01b11 at witness_warn+0x461 > >> #2 0xffffffff81075763 at trap_pfault+0x53 > >> #3 0xffffffff81074d7a at trap+0x2ba > >> #4 0xffffffff8105076c at calltrap+0x8 > >> #5 0xffffffff80dd21b0 at udp_ctlinput+0x50 > >> #6 0xffffffff80d3081d at icmp_input+0x96d > >> #7 0xffffffff80d316d7 at ip_input+0x3f7 > >> #8 0xffffffff80cc0a92 at netisr_dispatch_src+0xa2 > >> #9 0xffffffff80ca3ebe at ether_demux+0x16e > >> #10 0xffffffff80ca5377 at ether_nh_input+0x427 > >> #11 0xffffffff80cc0a92 at netisr_dispatch_src+0xa2 > >> #12 0xffffffff80ca437f at ether_input+0x8f > >> #13 0xffffffff80cbc500 at iflib_rxeof+0xc90 > >> #14 0xffffffff80cb6b6f at _task_fn_rx+0x7f > >> #15 0xffffffff80bdd209 at gtaskqueue_run_locked+0x139 > >> #16 0xffffffff80bdcf88 at gtaskqueue_thread_loop+0x88 > >> #17 0xffffffff80b54514 at fork_exit+0x84 > >> > >> > >> Fatal trap 12: page fault while in kernel mode > >> cpuid = 10; apic id = 0a > >> fault virtual address = 0x8 > >> fault code = supervisor read data, page not present > >> instruction pointer = 0x20:0xffffffff80dd2423 > >> stack pointer = 0x0:0xfffffe00004a5500 > >> frame pointer = 0x0:0xfffffe00004a55a0 > >> code segment = base 0x0, limit 0xfffff, type 0x1b > >> = DPL 0, pres 1, long 1, def32 0, gran 1 > >> processor eflags = interrupt enabled, resume, IOPL = 0 > >> current process = 0 (if_io_tqg_10) > >> [ thread pid 0 tid 100069 ] > >> Stopped at udp_common_ctlinput+0x263: cmpq $0,0x8(%rax) > >> db> > >> > >> Details @ https://people.freebsd.org/~pho/stress/log/udp_usrreq.txt > >> > >> -- > >> Peter > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > >> > > > > This is surprisingly similar to my panic. Twice since June 19. > > > > slippy# kgdb /boot/kernel/kernel vmcore.3 > > GNU gdb (GDB) 8.1 [GDB v8.1 for FreeBSD] > > Copyright (C) 2018 Free Software Foundation, Inc. > > License GPLv3+: GNU GPL version 3 or later > html> > > This is free software: you are free to change and redistribute it. > > There is NO WARRANTY, to the extent permitted by law. Type "show > > copying" > > and "show warranty" for details. > > This GDB was configured as "x86_64-portbld-freebsd12.0". > > Type "show configuration" for configuration details. > > For bug reporting instructions, please see: > > . > > Find the GDB manual and other documentation resources online at: > > . > > For help, type "help". > > Type "apropos word" to search for commands related to "word"... > > Reading symbols from /boot/kernel/kernel...Reading symbols from > > /usr/lib/debug//boot/kernel/kernel.debug...done. > > done. > > > > Unread portion of the kernel message buffer: > > Copyright (c) 1992-2018 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 #355 r335477M: Thu Jun 21 05:26:35 PDT 2018 > > root@slippy:/export/obj/opt/src/svn-current/amd64.amd64/sys/BREAK > > amd64 > > FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on > > LLVM 6.0.0) > > VT(vga): text 80x25 > > module_register: cannot register mmc/mmcsd from kernel; already loaded > > from mmcsd.ko > > Module mmc/mmcsd failed to register: 17 > > CPU: Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz (2294.83-MHz K8-class CPU) > > Origin="GenuineIntel" Id=0x206a7 Family=0x6 Model=0x2a Stepping=7 > > Features=0xbfebfbff > GE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > > Features2=0x1dbae3bf > 3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,XSAVE,OSXSAVE,A > > VX> > > AMD Features=0x28100800 > > AMD Features2=0x1 > > XSAVE Features=0x1 > > VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID > > TSC: P-state invariant, performance statistics > > real memory = 8589934592 (8192 MB) > > avail memory = 8080965632 (7706 MB) > > ACPI APIC Table: > > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > > FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads > > random: unblocking device. > > ioapic0 irqs 0-23 on motherboard > > random: entropy device external interface > > module_register_init: MOD_LOAD (vesa, 0xffffffff8097b700, 0) error 19 > > kbd1 at kbdmux0 > > nexus0 > > vtvga0: on motherboard > > cryptosoft0: on motherboard > > acpi0: on motherboard > > acpi0: Power Button (fixed) > > cpu0: on acpi0 > > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > > Timecounter "HPET" frequency 14318180 Hz quality 950 > > Event timer "HPET" frequency 14318180 Hz quality 550 > > Event timer "HPET1" frequency 14318180 Hz quality 440 > > Event timer "HPET2" frequency 14318180 Hz quality 440 > > Event timer "HPET3" frequency 14318180 Hz quality 440 > > Event timer "HPET4" frequency 14318180 Hz quality 440 > > atrtc0: port 0x70-0x77 irq 8 on acpi0 > > atrtc0: Warning: Couldn't map I/O. > > atrtc0: registered as a time-of-day clock, resolution 1.000000s > > attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > Event timer "i8254" frequency 1193182 Hz quality 100 > > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > > acpi_ec0: port 0x62,0x66 on acpi0 > > pcib0: port 0xcf8-0xcff on acpi0 > > pci0: on pcib0 > > vgapci0: port 0x2000-0x203f mem > > 0xf0000000-0xf03fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 > > vgapci0: Boot video device > > pci0: at device 22.0 (no driver attached) > > ehci0: mem > > 0xf060a000-0xf060a3ff irq 16 at device 26.0 on pci0 > > usbus0: EHCI version 1.0 > > usbus0 on ehci0 > > hdac0: mem 0xf0600000-0xf0603fff > > irq 22 at device 27.0 on pci0 > > pcib1: irq 16 at device 28.0 on pci0 > > pci1: on pcib1 > > pcib2: irq 17 at device 28.1 on pci0 > > pci2: on pcib2 > > iwn0: mem 0xf0500000-0xf0501fff irq 17 > > at device 0.0 on pci2 > > pcib3: irq 19 at device 28.3 on pci0 > > pci3: on pcib3 > > bge0: mem > > 0xf0400000-0xf040ffff,0xf0410000-0xf041ffff irq 19 at device 0.0 on pci3 > > bge0: CHIP ID 0x57785100; ASIC REV 0x57785; CHIP REV 0x577851; PCI-E > > miibus0: on bge0 > > brgphy0: PHY 1 on miibus0 > > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > > <6>bge0: Using defaults for TSO: 65518/35/2048 > > <6>bge0: Ethernet address: 20:6a:8a:72:03:17 > > pci3: at device 0.1 (no driver > > attached) > > ehci1: mem > > 0xf0609000-0xf06093ff irq 23 at device 29.0 on pci0 > > usbus1: EHCI version 1.0 > > usbus1 on ehci1 > > isab0: at device 31.0 on pci0 > > isa0: on isab0 > > ahci0: port > > 0x2088-0x208f,0x2094-0x2097,0x2080-0x2087,0x2090-0x2093,0x2060-0x207f > > mem 0xf0608000-0xf06087ff irq 19 at device 31.2 on pci0 > > ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported > > ahcich0: at channel 0 on ahci0 > > ahcich1: at channel 1 on ahci0 > > ahcich5: at channel 5 on ahci0 > > ahciem0: on ahci0 > > ichsmb0: port 0xefa0-0xefbf mem > > 0xf0604000-0xf06040ff irq 18 at device 31.3 on pci0 > > smbus0: on ichsmb0 > > smb0: on smbus0 > > acpi_lid0: on acpi0 > > acpi_button0: on acpi0 > > acpi_tz0: on acpi0 > > acpi_tz1: on acpi0 > > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > > atkbd0: irq 1 on atkbdc0 > > kbd0 at atkbd0 > > atkbd0: [GIANT-LOCKED] > > psm0: irq 12 on atkbdc0 > > psm0: [GIANT-LOCKED] > > psm0: model Synaptics Touchpad, device ID 0 > > acpi_acad0: on acpi0 > > battery0: on acpi0 > > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff pnpid > > PNP0900 on isa0 > > ata0: at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 > > ata1: at port 0x170-0x177,0x376 irq 15 on isa0 > > acpi_perf0: on cpu0 > > coretemp0: on cpu0 > > ZFS filesystem version: 5 > > ZFS storage pool version: features support (5000) > > Timecounters tick every 10.000 msec > > IP Filter: v5.1.2 initialized. Default = pass all, Logging = enabled > > hdacc0: at cad 0 on hdac0 > > hdaa0: at nid 1 on hdacc0 > > pcm0: at nid 20,33 and 27 on hdaa0 > > pcm1: at nid 24 on hdaa0 > > hdacc1: at cad 3 on hdac0 > > hdaa1: at nid 1 on hdacc1 > > pcm2: at nid 5 on hdaa1 > > usbus0: 480Mbps High Speed USB v2.0 > > usbus1: 480Mbps High Speed USB v2.0 > > ugen1.1: at usbus1 > > uhub0: on usbus1 > > ugen0.1: at usbus0 > > uhub1: on usbus0 > > ses0 at ahciem0 bus 0 scbus3 target 0 lun 0 > > ses0: SEMB S-E-S 2.00 device > > ses0: SEMB SES Device > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > > ada0: ATA8-ACS SATA 3.x device > > ada0: Serial Number JR1000D33969RE > > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > > ada0: Command Queueing enabled > > ada0: 953869MB (1953525168 512 byte sectors) > > cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 > > cd0: Removable CD-ROM SCSI device > > cd0: Serial Number SBB5103801 > > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO > > 8192bytes) > > cd0: Attempt to query device size failed: NOT READY, Medium not present > > - tray closed > > Launching APs: 1 3 2 > > Trying to mount root from ufs:/dev/ufs/Sroot [rw]... > > Timecounter "TSC-low" frequency 1147416846 Hz quality 1000 > > <118>Setting hostuuid: 34f5ed40-8938-11da-b265-efe316da850d. > > <118>Setting hostid: 0x7f5a03b9. > > uhub0: 2 ports with 2 removable, self powered > > uhub1: 2 ports with 2 removable, self powered > > ugen0.2: at usbus0 > > uhub2 on uhub1 > > uhub2: > > on usbus0 > > ugen1.2: at usbus1 > > uhub3 on uhub0 > > uhub3: > > on usbus1 > > uhub2: 6 ports with 6 removable, self powered > > uhub3: 6 ports with 6 removable, self powered > > ugen0.3: at usbus0 > > ukbd0 on uhub2 > > ukbd0: on > > usbus0 > > kbd2 at ukbd0 > > ums0 on uhub2 > > ums0: on > > usbus0 > > ums0: 16 buttons and [XYZT] coordinates ID=2 > > ugen1.3: at usbus1 > > uhub4 on uhub3 > > uhub4: on > > usbus1 > > uhub4: 4 ports with 4 removable, self powered > > ugen0.4: at usbus0 > > ugen1.4: at usbus1 > > uhub5 on uhub4 > > uhub5: on > > usbus1 > > uhub5: 4 ports with 4 removable, self powered > > ugen1.5: at usbus1 > > uhub6 on uhub5 > > uhub6: on > > usbus1 > > uhub6: 4 ports with 4 removable, self powered > > ugen1.6: at usbus1 > > ukbd1 on uhub6 > > ukbd1: on > > usbus1 > > kbd3 at ukbd1 > > ums1 on uhub6 > > ums1: on > > usbus1 > > ums1: 16 buttons and [XYZT] coordinates ID=2 > > ugen1.7: at usbus1 > > ukbd2 on uhub6 > > ukbd2: on > > usbus1 > > kbd4 at ukbd2 > > ugen1.8: at usbus1 > > umass0 on uhub5 > > umass0: on > > usbus1 > > umass0: SCSI over Bulk-Only; quirks = 0x408c > > umass0:6:0: Attached to scbus6 > > da0 at umass-sim0 bus 0 scbus6 target 0 lun 0 > > da0: Fixed Direct Access SCSI device > > da0: 40.000MB/s transfers > > da0: 76319MB (156301488 512 byte sectors) > > da0: quirks=0x2 > > <118>Starting file system checks: > > <118>/dev/ufs/Sroot: FILE SYSTEM CLEAN; SKIPPING CHECKS > > <118>/dev/ufs/Sroot: clean, 413829 free (909 frags, 51615 blocks, 0.2% > > fragmentation) > > <118>/dev/ufs/Susr: FILE SYSTEM CLEAN; SKIPPING CHECKS > > <118>/dev/ufs/Susr: clean, 459287 free (4847 frags, 56805 blocks, 0.6% > > fragmentation) > > <118>/dev/ufs/Svtmp: FILE SYSTEM CLEAN; SKIPPING CHECKS > > <118>/dev/ufs/Svtmp: clean, 503642 free (50 frags, 62949 blocks, 0.0% > > fragmentation) > > <118>/dev/ufs/SCusr: FILE SYSTEM CLEAN; SKIPPING CHECKS > > <118>/dev/ufs/Svar: FILE SYSTEM CLEAN; SKIPPING CHECKS > > <118>/dev/ufs/SSusr: FILE SYSTEM CLEAN; SKIPPING CHECKS > > <118>/dev/ufs/SCusr: clean, 469826 free (4578 frags, 58156 blocks, 0.6% > > fragmentation) > > <118>/dev/ufs/Svar: clean, 453726 free (574 frags, 56644 blocks, 0.1% > > fragmentation) > > <118>/dev/ufs/SCroot: FILE SYSTEM CLEAN; SKIPPING CHECKS > > <118>/dev/ufs/SSusr: clean, 569245 free (3653 frags, 70699 blocks, 0.5% > > fragmentation) > > <118>/dev/ufs/SCroot: clean, 422625 free (617 frags, 52751 blocks, 0.1% > > fragmentation) > > <118>/dev/ufs/SCvar: FILE SYSTEM CLEAN; SKIPPING CHECKS > > <118>/dev/ufs/SSvar: FILE SYSTEM CLEAN; SKIPPING CHECKS > > <118>/dev/ufs/SCvar: clean, 400011 free (99 frags, 49989 blocks, 0.0% > > fragmentation) > > <118>/dev/ufs/SSvar: clean, 457058 free (138 frags, 57115 blocks, 0.0% > > fragmentation) > > <118>/dev/ufs/SSroot: FILE SYSTEM CLEAN; SKIPPING CHECKS > > <118>/dev/ufs/SSroot: clean, 412995 free (219 frags, 51597 blocks, 0.0% > > fragmentation) > > <118>/dev/msdosfs/SHARED: FILESYSTEM CLEAN; SKIPPING CHECKS > > <118>/dev/zvol/tank/VMs/current/i386/disk0s1a: FILE SYSTEM CLEAN; > > SKIPPING CHECKS > > <118>/dev/zvol/tank/VMs/current/i386/disk0s1a: clean, 254465 free (337 > > frags, 31766 blocks, 0.1% fragmentation) > > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1a: FILE SYSTEM CLEAN; > > SKIPPING CHECKS > > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1a: FILE SYSTEM CLEAN; > > SKIPPING CHECKS > > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1a: clean, 335508 free > > (1348 frags, 41770 blocks, 0.1% fragmentation) > > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1a: clean, 566833 free > > (2297 frags, 70567 blocks, 0.2% fragmentation) > > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1a: FILE SYSTEM CLEAN; > > SKIPPING CHECKS > > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1a: FILE SYSTEM CLEAN; > > SKIPPING CHECKS > > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1a: clean, 510529 free > > (1185 frags, 63668 blocks, 0.1% fragmentation) > > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1a: clean, 354656 free (336 > > frags, 44290 blocks, 0.1% fragmentation) > > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1a: FILE SYSTEM CLEAN; > > SKIPPING CHECKS > > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1a: clean, 633994 free > > (2106 frags, 78986 blocks, 0.2% fragmentation) > > <118>/dev/zvol/tank/VMs/current/amd64/disk3p1: FILE SYSTEM CLEAN; > > SKIPPING CHECKS > > <118>/dev/zvol/tank/VMs/current/amd64/disk3p1: clean, 2535564 free (564 > > frags, 316875 blocks, 0.0% fragmentation) > > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1d: FILE SYSTEM CLEAN; > > SKIPPING CHECKS > > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1d: clean, 897924 free > > (188 frags, 112217 blocks, 0.0% fragmentation) > > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1d: FILE SYSTEM CLEAN; > > SKIPPING CHECKS > > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1d: clean, 897896 free > > (152 frags, 112218 blocks, 0.0% fragmentation) > > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1d: FILE SYSTEM CLEAN; > > SKIPPING CHECKS > > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1d: FILE SYSTEM CLEAN; > > SKIPPING CHECKS > > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1d: clean, 889422 free (214 > > frags, 111151 blocks, 0.0% fragmentation) > > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1d: clean, 889419 free (219 > > frags, 111150 blocks, 0.0% fragmentation) > > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1d: FILE SYSTEM CLEAN; > > SKIPPING CHECKS > > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1d: clean, 408410 free (90 > > frags, 51040 blocks, 0.0% fragmentation) > > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1e: FILE SYSTEM CLEAN; > > SKIPPING CHECKS > > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1e: FILE SYSTEM CLEAN; > > SKIPPING CHECKS > > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1e: clean, 1230068 free > > (7300 frags, 152846 blocks, 0.5% fragmentation) > > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1e: clean, 726361 free > > (6297 frags, 90008 blocks, 0.4% fragmentation) > > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1e: FILE SYSTEM CLEAN; > > SKIPPING CHECKS > > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1e: clean, 1299097 free > > (6385 frags, 161589 blocks, 0.4% fragmentation) > > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1e: FILE SYSTEM CLEAN; > > SKIPPING CHECKS > > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1e: clean, 822303 free > > (1047 frags, 102657 blocks, 0.1% fragmentation) > > <118>/dev/zvol/tank/VMs/current/i386/disk0s1d: FILE SYSTEM CLEAN; > > SKIPPING CHECKS > > <118>/dev/zvol/tank/VMs/current/i386/disk0s1d: clean, 399855 free (15 > > frags, 49980 blocks, 0.0% fragmentation) > > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1e: FILE SYSTEM CLEAN; > > SKIPPING CHECKS > > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1e: clean, 937324 free > > (7524 frags, 116225 blocks, 0.5% fragmentation) > > <118>/dev/zvol/tank/VMs/current/i386/disk0s1e: FILE SYSTEM CLEAN; > > SKIPPING CHECKS > > <118>/dev/zvol/tank/VMs/current/i386/disk0s1e: clean, 1077125 free (845 > > frags, 134535 blocks, 0.1% fragmentation) > > <118>Mounting local filesystems:. > > <118>ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib > > /usr/local/lib/compat/pkg /usr/local/krb5/lib /usr/local/kde4/lib > > /usr/local/lib/compat /usr/local/lib/compat/pkg /usr/local/lib/dovecot > > /usr/local/lib/e2fsprogs /usr/local/lib/ffmpeg0 /usr/local/lib/freeradiu > > s-3.0.15 /usr/local/lib/gcc48 /usr/local/lib/gcc5 /usr/local/lib/gcc6 > > /usr/local/lib/gcc7 /usr/local/lib/gcc8 /usr/local/lib/gcc9 > > /usr/local/lib/gegl-0.2 /usr/local/lib/graphviz /usr/local/lib/httrack > > /usr/local/lib/itcl3.4 /usr/local/lib/jitsi/lib/native > > /usr/local/lib/mysql /usr/local/lib/mysql/plugin /usr/local/lib/nss > > /usr/local/lib/opencollada /usr/local/lib/perl5/5.24/mach/CORE > > /usr/local/lib/perl5/5.26/mach/CORE /usr/local/lib/perl5/5.28/mach/CORE > > /usr/local/lib/pgtcl /usr/local/lib/pidgin /usr/local/lib/pth > > /usr/local/lib/qt4 /usr/local/lib/qt5 /usr/local/lib/samba4 > > /usr/local/lib/xrdp /usr/local/libexec/openldap /usr/local/llvm-devel/li > > b /usr/local/llvm40/lib /usr/local/llvm50/lib /usr/local/llvm60/lib > > /usr/local/share/chromium > > <118>32-bit compatibility ldconfig path: /usr/lib32 > > /alt/i386/root/usr/local/lib /usr/local/lib32/compat > > <118>Setting hostname: slippy. > > <118>Additional TCP/IP options: rfc1323 extensions=NO. > > <118>Setting up harvesting: [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ET > > HER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED > > <118>Feeding entropy: . > > <118>Loading IP Pools. > > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > > present in pool > > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > > present in pool > > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > > present in pool > > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > > present in pool > > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > > present in pool > > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > > present in pool > > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > > present in pool > > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > > present in pool > > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > > present in pool > > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > > present in pool > > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > > present in pool > > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > > present in pool > > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > > present in pool > > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > > present in pool > > <118>Enabling ipfilter. > > <118>32:1:ioctl(add/insert rule): rule already exists > > <118>Installing NAT rules. > > <118>0 entries flushed from NAT table > > <118>0 entries flushed from NAT list > > <6>wlan0: Ethernet address: 20:6a:8a:72:03:17 > > <118>Created wlan(4) interfaces: wlan0. > > <118>Created clone interfaces: lagg0. > > <6>lo0: link state changed to UP > > <6>bge0: link state changed to DOWN > > iwn0: iwn_read_firmware: ucode rev=0x12a80601 > > <118>Starting wpa_supplicant. > > <6>lagg0: link state changed to DOWN > > iwn0: iwn_read_firmware: ucode rev=0x12a80601 > > <118>Starting dhclient. > > <118>lagg0: no link ... > > <6>wlan0: link state changed to UP > > <6>lagg0: link state changed to UP > > <118> got link > > <6>bge0: link state changed to UP > > <118>Starting Network: lo0 bge0 wlan0 lagg0. > > <118>lo0: flags=8049 metric 0 mtu 16384 > > <118> options=680003 > > <118> inet 127.0.0.1 netmask 0xff000000 > > <118> inet6 ::1 prefixlen 128 > > <118> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > > <118> nd6 options=21 > > <118> groups: lo > > <118>bge0: flags=8843 metric 0 > > mtu 1500 > > <118> options=80080 > > <118> ether 20:6a:8a:72:03:17 > > <118> nd6 options=29 > > <118> media: Ethernet autoselect (1000baseT ) > > <118> status: active > > <118>wlan0: flags=8843 metric 0 > > mtu 1500 > > <118> ether 20:6a:8a:72:03:17 > > <118> nd6 options=29 > > <118> media: IEEE 802.11 Wireless Ethernet MCS mode 11ng > > <118> status: associated > > <118> ssid Walden_Pond channel 1 (2412 MHz 11g ht/20) bssid > > 4c:60:de:31:3c:17 > > <118> regdomain FCC country US authmode WPA2/802.11i privacy ON > > <118> deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 120 scanvalid > > 16959 > > <118> protmode CTS ampdulimit 64k ampdudensity 8 -amsdutx amsdurx > > shortgi > > <118> -stbc -ldpc wme roaming MANUAL > > <118> groups: wlan > > <118>lagg0: flags=8843 metric 0 > > mtu 1500 > > <118> ether 20:6a:8a:72:03:17 > > <118> inet6 fe80::226a:8aff:fe72:317%lagg0 prefixlen 64 scopeid 0x4 > > <118> inet 0.0.0.0 netmask 0x0 broadcast 255.255.255.255 > > <118> nd6 options=23 > > <118> media: Ethernet autoselect > > <118> status: active > > <118> groups: lagg > > <118> laggproto failover lagghash l2,l3,l4 > > <118> laggport: bge0 flags=5 > > <118> laggport: wlan0 flags=0<> > > <118>filter sync'd > > <118>Starting devd. > > <118>Starting ums0 moused. > > <118>Autoloading module: uhid.ko > > uhid0 on uhub2 > > uhid0: on > > usbus0 > > uhid1 on uhub6 > > uhid1: on > > usbus1 > > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > > use 'onestart' instead of 'start'. > > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > > use 'onestart' instead of 'start'. > > <118>Cannot 'start' webcamd. Set webcamd_enable to YES in /etc/rc.conf > > or use 'onestart' instead of 'start'. > > uhid2 on uhub6 > > uhid2: on > > usbus1 > > device_attach: uhid2 attach returned 12 > > <118>Cannot 'start' webcamd. Set webcamd_enable to YES in /etc/rc.conf > > or use 'onestart' instead of 'start'. > > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > > use 'onestart' instead of 'start'. > > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > > use 'onestart' instead of 'start'. > > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > > use 'onestart' instead of 'start'. > > <118>Starting ums1 moused. > > <118>Autoloading module: uhid.ko > > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > > use 'onestart' instead of 'start'. > > <118>Autoloading module: uhid.ko > > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > > use 'onestart' instead of 'start'. > > <118>local: Not in a function > > <118>local: Not in a function > > <118>dhclient not running? (check /var/run/dhclient.bge0.pid). > > <118>Stopping dhclient. > > <118>Waiting for PIDS: 471. > > <118>Starting dhclient. > > <118>add host 127.0.0.1: gateway lo0 fib 0: route already in table > > <118>Additional inet routing options: ignore ICMP redirect=YES log ICMP > > redirect=YES. > > <118>add host ::1: gateway lo0 fib 0: route already in table > > <118>add net fe80::: gateway ::1 > > <118>add net ff02::: gateway ::1 > > <118>add net ::ffff:0.0.0.0: gateway ::1 > > <118>add net ::0.0.0.0: gateway ::1 > > <118>Starting rtsold. > > > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 3; apic id = 03 > > fault virtual address = 0x0 > > fault code = supervisor read data, page not present > > instruction pointer = 0x20:0xffffffff80806966 > > stack pointer = 0x28:0xfffffe00004667d0 > > frame pointer = 0x28:0xfffffe0000466840 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 12 (swi1: netisr 0) > > trap number = 12 > > panic: page fault > > cpuid = 3 > > time = 1529587144 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xfffffe0000466480 > > vpanic() at vpanic+0x1a3/frame 0xfffffe00004664e0 > > panic() at panic+0x43/frame 0xfffffe0000466540 > > trap_fatal() at trap_fatal+0x35f/frame 0xfffffe0000466590 > > trap_pfault() at trap_pfault+0x49/frame 0xfffffe00004665f0 > > trap() at trap+0x29e/frame 0xfffffe0000466700 > > calltrap() at calltrap+0x8/frame 0xfffffe0000466700 > > --- trap 0xc, rip = 0xffffffff80806966, rsp = 0xfffffe00004667d0, rbp = > > 0xfffffe0000466840 --- > > udp_append() at udp_append+0x26/frame 0xfffffe0000466840 > > udp_input() at udp_input+0x574/frame 0xfffffe0000466910 > > ip_input() at ip_input+0x145/frame 0xfffffe0000466970 > > swi_net() at swi_net+0x17b/frame 0xfffffe00004669e0 > > intr_event_execute_handlers() at intr_event_execute_handlers+0xe9/frame > > 0xfffffe0000466a20 > > ithread_loop() at ithread_loop+0xe7/frame 0xfffffe0000466a70 > > fork_exit() at fork_exit+0x83/frame 0xfffffe0000466ab0 > > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0000466ab0 > > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > > Uptime: 51s > > Dumping 697 out of 7975 MB:..3%..12%..21%..33%..42%..51%..62%..72%..81%. > > .92% > > > > __curthread () at ./machine/pcpu.h:231 > > 231 __asm("movq %%gs:%1,%0" : "=r" (td) > > (kgdb) bt > > #0 __curthread () at ./machine/pcpu.h:231 > > #1 doadump (textdump=1) at /opt/src/svn-current/sys/kern/kern_shutdown. > > c:366 > > #2 0xffffffff8061b330 in kern_reboot (howto=260) > > at /opt/src/svn-current/sys/kern/kern_shutdown.c:446 > > #3 0xffffffff8061b7c3 in vpanic (fmt=, > > ap=0xfffffe0000466520) > > at /opt/src/svn-current/sys/kern/kern_shutdown.c:863 > > #4 0xffffffff8061b5b3 in panic (fmt=) > > at /opt/src/svn-current/sys/kern/kern_shutdown.c:790 > > #5 0xffffffff8095e76f in trap_fatal (frame=0xfffffe0000466710, eva=0) > > at /opt/src/svn-current/sys/amd64/amd64/trap.c:892 > > #6 0xffffffff8095e7c9 in trap_pfault (frame=0xfffffe0000466710, > > usermode=0) > > at /opt/src/svn-current/sys/amd64/amd64/trap.c:728 > > #7 0xffffffff8095ddee in trap (frame=0xfffffe0000466710) > > at /opt/src/svn-current/sys/amd64/amd64/trap.c:427 > > #8 > > #9 udp_append (inp=0xfffff80031d2ed58, ip=0xfffff800039333a0, > > n=0xfffff80003933300, off=20, udp_in=0xfffffe0000466850) > > at /opt/src/svn-current/sys/netinet/udp_usrreq.c:314 > > #10 0xffffffff80806464 in udp_input (mp=, > > offp=, > > proto=17) at /opt/src/svn-current/sys/netinet/udp_usrreq.c:722 > > #11 0xffffffff8075f645 in ip_input (m=0x0) > > at /opt/src/svn-current/sys/netinet/ip_input.c:825 > > #12 0xffffffff8073959b in netisr_process_workstream_proto ( > > ---Type to continue, or q to quit---q > > nwsp=,Quit > > (kgdb) frame 9 > > #9 udp_append (inp=0xfffff80031d2ed58, ip=0xfffff800039333a0, > > n=0xfffff80003933300, off=20, udp_in=0xfffffe0000466850) > > at /opt/src/svn-current/sys/netinet/udp_usrreq.c:314 > > 314 if (up->u_tun_func != NULL) { > > (kgdb) l > > 309 > > 310 /* > > 311 * Engage the tunneling protocol. > > 312 */ > > 313 up = intoudpcb(inp); > > 314 if (up->u_tun_func != NULL) { > > 315 in_pcbref(inp); > > 316 INP_RUNLOCK(inp); > > 317 (*up->u_tun_func)(n, off, inp, (struct sockaddr *)& > udp_in[0], > > 318 up->u_tun_ctx); > > (kgdb) p up > > $1 = (struct udpcb *) 0x0 > > (kgdb) p *inp > > $2 = {inp_hash = {cle_next = 0x0, cle_prev = 0xfffff800023abf70}, > > inp_pcbgrouphash = {cle_next = 0x0, cle_prev = 0x0}, inp_lock = { > > lock_object = {lo_name = 0xffffffff80a02fc7 "udpinp", lo_flags = > > 90898432, > > lo_data = 0, lo_witness = 0x0}, rw_lock = 33}, inp_hpts = { > > tqe_next = 0x0, tqe_prev = 0x0}, inp_hpts_request = 0, > > inp_in_hpts = 0 '\000', inp_in_input = 0 '\000', inp_hpts_cpu = 0, > > inp_refcount = 1, inp_flags = 8405056, inp_flags2 = 16, inp_input_cpu > > = 0, > > inp_hpts_cpu_set = 0 '\000', inp_input_cpu_set = 0 '\000', > > inp_hpts_calls = 0 '\000', inp_input_calls = 0 '\000', > > inp_spare_bits2 = 0 '\000', inp_spare_byte = 0 '\000', inp_ppcb = > > 0x0, > > inp_socket = 0x0, inp_hptsslot = 0, inp_hpts_drop_reas = 0, inp_input > > = { > > tqe_next = 0x0, tqe_prev = 0x0}, inp_pcbinfo = 0xfffffe0048566738, > > inp_pcbgroup = 0x0, inp_pcbgroup_wild = {cle_next = 0x0, cle_prev = > > 0x0}, > > inp_cred = 0xfffff80031366600, inp_flow = 0, inp_vflag = 1 '\001', > > inp_ip_ttl = 64 '@', inp_ip_p = 0 '\000', inp_ip_minttl = 0 '\000', > > inp_flowid = 60, inp_snd_tag = 0x0, inp_flowtype = 63, > > inp_rss_listen_bucket = 0, inp_inc = {inc_flags = 0 '\000', > > inc_len = 0 '\000', inc_fibnum = 0, inc_ie = {ie_fport = 0, > > ie_lport = 28353, ie_dependfaddr = {id46_addr = {ia46_pad32 = {0, > > 0, 0}, > > ia46_addr4 = {s_addr = 0}}, id6_addr = {__u6_addr = { > > __u6_addr8 = '\000' , __u6_addr16 = {0, > > 0, 0, 0, > > 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}}, > > ie_dependladdr = { > > id46_addr = {ia46_pad32 = {0, 0, 0}, ia46_addr4 = { > > ---Type to continue, or q to quit--- > > s_addr = 16777343}}, id6_addr = {__u6_addr = { > > __u6_addr8 = '\000' , "\177\000\000\001", > > __u6_addr16 = {0, 0, 0, 0, 0, 0, 127, 256}, __u6_addr32 = > > {0, 0, > > 0, 16777343}}}}, ie6_zoneid = 0}}, inp_label = 0x0, > > inp_sp = 0xfffff8000725dee0, {inp_ip_tos = 0 '\000', inp_options = > > 0x0, > > inp_moptions = 0x0}, {in6p_options = 0x0, in6p_outputopts = 0x0, > > in6p_moptions = 0x0, in6p_icmp6filt = 0x0, in6p_cksum = 0, > > in6p_hops = 0}, > > inp_portlist = {cle_next = 0x0, cle_prev = 0xfffff80002334d20}, > > inp_phd = 0xfffff80002334d00, inp_gencnt = 169, inp_lle = 0x0, > > inp_rt_cookie = 7, {inp_route = {ro_rt = 0x0, ro_lle = 0x0, > > ro_prepend = 0x0, ro_plen = 0, ro_flags = 256, ro_mtu = 0, spare > > = 0, > > ro_dst = {sa_len = 0 '\000', sa_family = 0 '\000', > > sa_data = '\000' }}, inp_route6 = {ro_rt = > > 0x0, > > ro_lle = 0x0, ro_prepend = 0x0, ro_plen = 0, ro_flags = 256, > > ro_mtu = 0, > > spare = 0, ro_dst = {sin6_len = 0 '\000', sin6_family = 0 '\000', > > sin6_port = 0, sin6_flowinfo = 0, sin6_addr = {__u6_addr = { > > __u6_addr8 = '\000' , __u6_addr16 = {0, > > 0, 0, 0, > > 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id > > = 0}}}, > > inp_list = {cle_next = 0xfffff80031d4e000, cle_prev = > > 0xfffffe0048566828}, > > inp_epoch_ctx = {data = {0xffffffff80759b10 , > > 0xfffff80002334d08}}} > > (kgdb) up > > #10 0xffffffff80806464 in udp_input (mp=, > > offp=, > > proto=17) at /opt/src/svn-current/sys/netinet/udp_usrreq.c:722 > > 722 if (udp_append(inp, ip, m, iphlen, udp_in) == 0) > > (kgdb) l > > 717 return (IPPROTO_DONE); > > 718 } > > 719 } > > 720 > > 721 UDP_PROBE(receive, NULL, inp, ip, inp, uh); > > 722 if (udp_append(inp, ip, m, iphlen, udp_in) == 0) > > 723 INP_RUNLOCK(inp); > > 724 return (IPPROTO_DONE); > > 725 > > 726 badunlocked: > > (kgdb) up > > #11 0xffffffff8075f645 in ip_input (m=0x0) > > at /opt/src/svn-current/sys/netinet/ip_input.c:825 > > 825 (*inetsw[ip_protox[ip->ip_p]].pr_input)(&m, &hlen, ip->ip_p > ); > > (kgdb) l > > 820 /* > > 821 * Switch out to protocol's input routine. > > 822 */ > > 823 IPSTAT_INC(ips_delivered); > > 824 > > 825 (*inetsw[ip_protox[ip->ip_p]].pr_input)(&m, &hlen, ip->ip_p > ); > > 826 return; > > 827 bad: > > 828 m_freem(m); > > 829 } > > (kgdb) > > > > > > In both cases rtsold was starting. > > > > > > > > -- > > Cheers, > > Cy Schubert > > FreeBSD UNIX: Web: http://www.FreeBSD.org > > > > The need of the many outweighs the greed of the few. > > > > > > _______________________________________________ > > 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 Fri Jun 22 01:42:44 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 572C31009A56 for ; Fri, 22 Jun 2018 01:42:44 +0000 (UTC) (envelope-from mmacy@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 C239178677 for ; Fri, 22 Jun 2018 01:42:43 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 858611009A53; Fri, 22 Jun 2018 01:42:43 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1EDB71009A51 for ; Fri, 22 Jun 2018 01:42:43 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B68A87866D for ; Fri, 22 Jun 2018 01:42:42 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-it0-f47.google.com (mail-it0-f47.google.com [209.85.214.47]) (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)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id 70DA7B803 for ; Fri, 22 Jun 2018 01:42:42 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-it0-f47.google.com with SMTP id u4-v6so806125itg.0 for ; Thu, 21 Jun 2018 18:42:42 -0700 (PDT) X-Gm-Message-State: APt69E1KVlcPh3zXP8UBL8H8ABqEIlg5GfdHt3UdQ75L6VOPwGjt3/Qh nOAD8rkGDlBCpwk1wcascHYZbepJ1fh/QOrYXAM= X-Google-Smtp-Source: ADUXVKLzwKjpHniE6T+C/QZhyg2EtWNnaGSKVch8zdmDahOH7V581AyghJJlffxr6YkWOcqOV2n1S0Dh5eUBkfqtjbE= X-Received: by 2002:a02:9525:: with SMTP id y34-v6mr22169493jah.38.1529631761662; Thu, 21 Jun 2018 18:42:41 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:8cd:0:0:0:0:0 with HTTP; Thu, 21 Jun 2018 18:42:41 -0700 (PDT) In-Reply-To: <201806220141.w5M1fdOb081507@slippy.cwsent.com> References: <201806220141.w5M1fdOb081507@slippy.cwsent.com> From: Matthew Macy Date: Thu, 21 Jun 2018 18:42:41 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Page fault in udp_usrreq.c:823 To: Cy Schubert Cc: Peter Holm , current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 22 Jun 2018 01:42:44 -0000 I made changes this morning / early afternoon. -M On Thu, Jun 21, 2018 at 6:41 PM, Cy Schubert wrote: > Like as of now? > > The last panic occurred this morning after a build last night. > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > The need of the many outweighs the greed of the few. > > > In message il.com> > , Matthew Macy writes: >> Try updating. It should be fixed. >> >> On Thu, Jun 21, 2018 at 6:14 PM, Cy Schubert wrot >> e: >> > In message <20180620090957.GA130@x2.osted.lan>, Peter Holm writes: >> >> 20180620 10:32:47 all (1/1): udp.sh >> >> Kernel page fault with the following non-sleepable locks held: >> >> shared rw udpinp (udpinp) r = 0 (0xfffff80bbc808d78) locked @ netinet/in_p >> cb. >> >> c:2398 >> >> stack backtrace: >> >> #0 0xffffffff80c00733 at witness_debugger+0x73 >> >> #1 0xffffffff80c01b11 at witness_warn+0x461 >> >> #2 0xffffffff81075763 at trap_pfault+0x53 >> >> #3 0xffffffff81074d7a at trap+0x2ba >> >> #4 0xffffffff8105076c at calltrap+0x8 >> >> #5 0xffffffff80dd21b0 at udp_ctlinput+0x50 >> >> #6 0xffffffff80d3081d at icmp_input+0x96d >> >> #7 0xffffffff80d316d7 at ip_input+0x3f7 >> >> #8 0xffffffff80cc0a92 at netisr_dispatch_src+0xa2 >> >> #9 0xffffffff80ca3ebe at ether_demux+0x16e >> >> #10 0xffffffff80ca5377 at ether_nh_input+0x427 >> >> #11 0xffffffff80cc0a92 at netisr_dispatch_src+0xa2 >> >> #12 0xffffffff80ca437f at ether_input+0x8f >> >> #13 0xffffffff80cbc500 at iflib_rxeof+0xc90 >> >> #14 0xffffffff80cb6b6f at _task_fn_rx+0x7f >> >> #15 0xffffffff80bdd209 at gtaskqueue_run_locked+0x139 >> >> #16 0xffffffff80bdcf88 at gtaskqueue_thread_loop+0x88 >> >> #17 0xffffffff80b54514 at fork_exit+0x84 >> >> >> >> >> >> Fatal trap 12: page fault while in kernel mode >> >> cpuid = 10; apic id = 0a >> >> fault virtual address = 0x8 >> >> fault code = supervisor read data, page not present >> >> instruction pointer = 0x20:0xffffffff80dd2423 >> >> stack pointer = 0x0:0xfffffe00004a5500 >> >> frame pointer = 0x0:0xfffffe00004a55a0 >> >> code segment = base 0x0, limit 0xfffff, type 0x1b >> >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> >> processor eflags = interrupt enabled, resume, IOPL = 0 >> >> current process = 0 (if_io_tqg_10) >> >> [ thread pid 0 tid 100069 ] >> >> Stopped at udp_common_ctlinput+0x263: cmpq $0,0x8(%rax) >> >> db> >> >> >> >> Details @ https://people.freebsd.org/~pho/stress/log/udp_usrreq.txt >> >> >> >> -- >> >> Peter >> >> _______________________________________________ >> >> freebsd-current@freebsd.org mailing list >> >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> >> >> > >> > This is surprisingly similar to my panic. Twice since June 19. >> > >> > slippy# kgdb /boot/kernel/kernel vmcore.3 >> > GNU gdb (GDB) 8.1 [GDB v8.1 for FreeBSD] >> > Copyright (C) 2018 Free Software Foundation, Inc. >> > License GPLv3+: GNU GPL version 3 or later > > html> >> > This is free software: you are free to change and redistribute it. >> > There is NO WARRANTY, to the extent permitted by law. Type "show >> > copying" >> > and "show warranty" for details. >> > This GDB was configured as "x86_64-portbld-freebsd12.0". >> > Type "show configuration" for configuration details. >> > For bug reporting instructions, please see: >> > . >> > Find the GDB manual and other documentation resources online at: >> > . >> > For help, type "help". >> > Type "apropos word" to search for commands related to "word"... >> > Reading symbols from /boot/kernel/kernel...Reading symbols from >> > /usr/lib/debug//boot/kernel/kernel.debug...done. >> > done. >> > >> > Unread portion of the kernel message buffer: >> > Copyright (c) 1992-2018 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 #355 r335477M: Thu Jun 21 05:26:35 PDT 2018 >> > root@slippy:/export/obj/opt/src/svn-current/amd64.amd64/sys/BREAK >> > amd64 >> > FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on >> > LLVM 6.0.0) >> > VT(vga): text 80x25 >> > module_register: cannot register mmc/mmcsd from kernel; already loaded >> > from mmcsd.ko >> > Module mmc/mmcsd failed to register: 17 >> > CPU: Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz (2294.83-MHz K8-class CPU) >> > Origin="GenuineIntel" Id=0x206a7 Family=0x6 Model=0x2a Stepping=7 >> > Features=0xbfebfbff> > GE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> >> > Features2=0x1dbae3bf> > 3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,XSAVE,OSXSAVE,A >> > VX> >> > AMD Features=0x28100800 >> > AMD Features2=0x1 >> > XSAVE Features=0x1 >> > VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID >> > TSC: P-state invariant, performance statistics >> > real memory = 8589934592 (8192 MB) >> > avail memory = 8080965632 (7706 MB) >> > ACPI APIC Table: >> > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >> > FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads >> > random: unblocking device. >> > ioapic0 irqs 0-23 on motherboard >> > random: entropy device external interface >> > module_register_init: MOD_LOAD (vesa, 0xffffffff8097b700, 0) error 19 >> > kbd1 at kbdmux0 >> > nexus0 >> > vtvga0: on motherboard >> > cryptosoft0: on motherboard >> > acpi0: on motherboard >> > acpi0: Power Button (fixed) >> > cpu0: on acpi0 >> > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 >> > Timecounter "HPET" frequency 14318180 Hz quality 950 >> > Event timer "HPET" frequency 14318180 Hz quality 550 >> > Event timer "HPET1" frequency 14318180 Hz quality 440 >> > Event timer "HPET2" frequency 14318180 Hz quality 440 >> > Event timer "HPET3" frequency 14318180 Hz quality 440 >> > Event timer "HPET4" frequency 14318180 Hz quality 440 >> > atrtc0: port 0x70-0x77 irq 8 on acpi0 >> > atrtc0: Warning: Couldn't map I/O. >> > atrtc0: registered as a time-of-day clock, resolution 1.000000s >> > attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 >> > Timecounter "i8254" frequency 1193182 Hz quality 0 >> > Event timer "i8254" frequency 1193182 Hz quality 100 >> > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 >> > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 >> > acpi_ec0: port 0x62,0x66 on acpi0 >> > pcib0: port 0xcf8-0xcff on acpi0 >> > pci0: on pcib0 >> > vgapci0: port 0x2000-0x203f mem >> > 0xf0000000-0xf03fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 >> > vgapci0: Boot video device >> > pci0: at device 22.0 (no driver attached) >> > ehci0: mem >> > 0xf060a000-0xf060a3ff irq 16 at device 26.0 on pci0 >> > usbus0: EHCI version 1.0 >> > usbus0 on ehci0 >> > hdac0: mem 0xf0600000-0xf0603fff >> > irq 22 at device 27.0 on pci0 >> > pcib1: irq 16 at device 28.0 on pci0 >> > pci1: on pcib1 >> > pcib2: irq 17 at device 28.1 on pci0 >> > pci2: on pcib2 >> > iwn0: mem 0xf0500000-0xf0501fff irq 17 >> > at device 0.0 on pci2 >> > pcib3: irq 19 at device 28.3 on pci0 >> > pci3: on pcib3 >> > bge0: mem >> > 0xf0400000-0xf040ffff,0xf0410000-0xf041ffff irq 19 at device 0.0 on pci3 >> > bge0: CHIP ID 0x57785100; ASIC REV 0x57785; CHIP REV 0x577851; PCI-E >> > miibus0: on bge0 >> > brgphy0: PHY 1 on miibus0 >> > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >> > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow >> > <6>bge0: Using defaults for TSO: 65518/35/2048 >> > <6>bge0: Ethernet address: 20:6a:8a:72:03:17 >> > pci3: at device 0.1 (no driver >> > attached) >> > ehci1: mem >> > 0xf0609000-0xf06093ff irq 23 at device 29.0 on pci0 >> > usbus1: EHCI version 1.0 >> > usbus1 on ehci1 >> > isab0: at device 31.0 on pci0 >> > isa0: on isab0 >> > ahci0: port >> > 0x2088-0x208f,0x2094-0x2097,0x2080-0x2087,0x2090-0x2093,0x2060-0x207f >> > mem 0xf0608000-0xf06087ff irq 19 at device 31.2 on pci0 >> > ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported >> > ahcich0: at channel 0 on ahci0 >> > ahcich1: at channel 1 on ahci0 >> > ahcich5: at channel 5 on ahci0 >> > ahciem0: on ahci0 >> > ichsmb0: port 0xefa0-0xefbf mem >> > 0xf0604000-0xf06040ff irq 18 at device 31.3 on pci0 >> > smbus0: on ichsmb0 >> > smb0: on smbus0 >> > acpi_lid0: on acpi0 >> > acpi_button0: on acpi0 >> > acpi_tz0: on acpi0 >> > acpi_tz1: on acpi0 >> > atkbdc0: port 0x60,0x64 irq 1 on acpi0 >> > atkbd0: irq 1 on atkbdc0 >> > kbd0 at atkbd0 >> > atkbd0: [GIANT-LOCKED] >> > psm0: irq 12 on atkbdc0 >> > psm0: [GIANT-LOCKED] >> > psm0: model Synaptics Touchpad, device ID 0 >> > acpi_acad0: on acpi0 >> > battery0: on acpi0 >> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff pnpid >> > PNP0900 on isa0 >> > ata0: at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 >> > ata1: at port 0x170-0x177,0x376 irq 15 on isa0 >> > acpi_perf0: on cpu0 >> > coretemp0: on cpu0 >> > ZFS filesystem version: 5 >> > ZFS storage pool version: features support (5000) >> > Timecounters tick every 10.000 msec >> > IP Filter: v5.1.2 initialized. Default = pass all, Logging = enabled >> > hdacc0: at cad 0 on hdac0 >> > hdaa0: at nid 1 on hdacc0 >> > pcm0: at nid 20,33 and 27 on hdaa0 >> > pcm1: at nid 24 on hdaa0 >> > hdacc1: at cad 3 on hdac0 >> > hdaa1: at nid 1 on hdacc1 >> > pcm2: at nid 5 on hdaa1 >> > usbus0: 480Mbps High Speed USB v2.0 >> > usbus1: 480Mbps High Speed USB v2.0 >> > ugen1.1: at usbus1 >> > uhub0: on usbus1 >> > ugen0.1: at usbus0 >> > uhub1: on usbus0 >> > ses0 at ahciem0 bus 0 scbus3 target 0 lun 0 >> > ses0: SEMB S-E-S 2.00 device >> > ses0: SEMB SES Device >> > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 >> > ada0: ATA8-ACS SATA 3.x device >> > ada0: Serial Number JR1000D33969RE >> > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) >> > ada0: Command Queueing enabled >> > ada0: 953869MB (1953525168 512 byte sectors) >> > cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 >> > cd0: Removable CD-ROM SCSI device >> > cd0: Serial Number SBB5103801 >> > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO >> > 8192bytes) >> > cd0: Attempt to query device size failed: NOT READY, Medium not present >> > - tray closed >> > Launching APs: 1 3 2 >> > Trying to mount root from ufs:/dev/ufs/Sroot [rw]... >> > Timecounter "TSC-low" frequency 1147416846 Hz quality 1000 >> > <118>Setting hostuuid: 34f5ed40-8938-11da-b265-efe316da850d. >> > <118>Setting hostid: 0x7f5a03b9. >> > uhub0: 2 ports with 2 removable, self powered >> > uhub1: 2 ports with 2 removable, self powered >> > ugen0.2: at usbus0 >> > uhub2 on uhub1 >> > uhub2: >> > on usbus0 >> > ugen1.2: at usbus1 >> > uhub3 on uhub0 >> > uhub3: >> > on usbus1 >> > uhub2: 6 ports with 6 removable, self powered >> > uhub3: 6 ports with 6 removable, self powered >> > ugen0.3: at usbus0 >> > ukbd0 on uhub2 >> > ukbd0: on >> > usbus0 >> > kbd2 at ukbd0 >> > ums0 on uhub2 >> > ums0: on >> > usbus0 >> > ums0: 16 buttons and [XYZT] coordinates ID=2 >> > ugen1.3: at usbus1 >> > uhub4 on uhub3 >> > uhub4: on >> > usbus1 >> > uhub4: 4 ports with 4 removable, self powered >> > ugen0.4: at usbus0 >> > ugen1.4: at usbus1 >> > uhub5 on uhub4 >> > uhub5: on >> > usbus1 >> > uhub5: 4 ports with 4 removable, self powered >> > ugen1.5: at usbus1 >> > uhub6 on uhub5 >> > uhub6: on >> > usbus1 >> > uhub6: 4 ports with 4 removable, self powered >> > ugen1.6: at usbus1 >> > ukbd1 on uhub6 >> > ukbd1: on >> > usbus1 >> > kbd3 at ukbd1 >> > ums1 on uhub6 >> > ums1: on >> > usbus1 >> > ums1: 16 buttons and [XYZT] coordinates ID=2 >> > ugen1.7: at usbus1 >> > ukbd2 on uhub6 >> > ukbd2: on >> > usbus1 >> > kbd4 at ukbd2 >> > ugen1.8: at usbus1 >> > umass0 on uhub5 >> > umass0: on >> > usbus1 >> > umass0: SCSI over Bulk-Only; quirks = 0x408c >> > umass0:6:0: Attached to scbus6 >> > da0 at umass-sim0 bus 0 scbus6 target 0 lun 0 >> > da0: Fixed Direct Access SCSI device >> > da0: 40.000MB/s transfers >> > da0: 76319MB (156301488 512 byte sectors) >> > da0: quirks=0x2 >> > <118>Starting file system checks: >> > <118>/dev/ufs/Sroot: FILE SYSTEM CLEAN; SKIPPING CHECKS >> > <118>/dev/ufs/Sroot: clean, 413829 free (909 frags, 51615 blocks, 0.2% >> > fragmentation) >> > <118>/dev/ufs/Susr: FILE SYSTEM CLEAN; SKIPPING CHECKS >> > <118>/dev/ufs/Susr: clean, 459287 free (4847 frags, 56805 blocks, 0.6% >> > fragmentation) >> > <118>/dev/ufs/Svtmp: FILE SYSTEM CLEAN; SKIPPING CHECKS >> > <118>/dev/ufs/Svtmp: clean, 503642 free (50 frags, 62949 blocks, 0.0% >> > fragmentation) >> > <118>/dev/ufs/SCusr: FILE SYSTEM CLEAN; SKIPPING CHECKS >> > <118>/dev/ufs/Svar: FILE SYSTEM CLEAN; SKIPPING CHECKS >> > <118>/dev/ufs/SSusr: FILE SYSTEM CLEAN; SKIPPING CHECKS >> > <118>/dev/ufs/SCusr: clean, 469826 free (4578 frags, 58156 blocks, 0.6% >> > fragmentation) >> > <118>/dev/ufs/Svar: clean, 453726 free (574 frags, 56644 blocks, 0.1% >> > fragmentation) >> > <118>/dev/ufs/SCroot: FILE SYSTEM CLEAN; SKIPPING CHECKS >> > <118>/dev/ufs/SSusr: clean, 569245 free (3653 frags, 70699 blocks, 0.5% >> > fragmentation) >> > <118>/dev/ufs/SCroot: clean, 422625 free (617 frags, 52751 blocks, 0.1% >> > fragmentation) >> > <118>/dev/ufs/SCvar: FILE SYSTEM CLEAN; SKIPPING CHECKS >> > <118>/dev/ufs/SSvar: FILE SYSTEM CLEAN; SKIPPING CHECKS >> > <118>/dev/ufs/SCvar: clean, 400011 free (99 frags, 49989 blocks, 0.0% >> > fragmentation) >> > <118>/dev/ufs/SSvar: clean, 457058 free (138 frags, 57115 blocks, 0.0% >> > fragmentation) >> > <118>/dev/ufs/SSroot: FILE SYSTEM CLEAN; SKIPPING CHECKS >> > <118>/dev/ufs/SSroot: clean, 412995 free (219 frags, 51597 blocks, 0.0% >> > fragmentation) >> > <118>/dev/msdosfs/SHARED: FILESYSTEM CLEAN; SKIPPING CHECKS >> > <118>/dev/zvol/tank/VMs/current/i386/disk0s1a: FILE SYSTEM CLEAN; >> > SKIPPING CHECKS >> > <118>/dev/zvol/tank/VMs/current/i386/disk0s1a: clean, 254465 free (337 >> > frags, 31766 blocks, 0.1% fragmentation) >> > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1a: FILE SYSTEM CLEAN; >> > SKIPPING CHECKS >> > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1a: FILE SYSTEM CLEAN; >> > SKIPPING CHECKS >> > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1a: clean, 335508 free >> > (1348 frags, 41770 blocks, 0.1% fragmentation) >> > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1a: clean, 566833 free >> > (2297 frags, 70567 blocks, 0.2% fragmentation) >> > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1a: FILE SYSTEM CLEAN; >> > SKIPPING CHECKS >> > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1a: FILE SYSTEM CLEAN; >> > SKIPPING CHECKS >> > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1a: clean, 510529 free >> > (1185 frags, 63668 blocks, 0.1% fragmentation) >> > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1a: clean, 354656 free (336 >> > frags, 44290 blocks, 0.1% fragmentation) >> > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1a: FILE SYSTEM CLEAN; >> > SKIPPING CHECKS >> > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1a: clean, 633994 free >> > (2106 frags, 78986 blocks, 0.2% fragmentation) >> > <118>/dev/zvol/tank/VMs/current/amd64/disk3p1: FILE SYSTEM CLEAN; >> > SKIPPING CHECKS >> > <118>/dev/zvol/tank/VMs/current/amd64/disk3p1: clean, 2535564 free (564 >> > frags, 316875 blocks, 0.0% fragmentation) >> > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1d: FILE SYSTEM CLEAN; >> > SKIPPING CHECKS >> > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1d: clean, 897924 free >> > (188 frags, 112217 blocks, 0.0% fragmentation) >> > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1d: FILE SYSTEM CLEAN; >> > SKIPPING CHECKS >> > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1d: clean, 897896 free >> > (152 frags, 112218 blocks, 0.0% fragmentation) >> > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1d: FILE SYSTEM CLEAN; >> > SKIPPING CHECKS >> > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1d: FILE SYSTEM CLEAN; >> > SKIPPING CHECKS >> > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1d: clean, 889422 free (214 >> > frags, 111151 blocks, 0.0% fragmentation) >> > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1d: clean, 889419 free (219 >> > frags, 111150 blocks, 0.0% fragmentation) >> > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1d: FILE SYSTEM CLEAN; >> > SKIPPING CHECKS >> > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1d: clean, 408410 free (90 >> > frags, 51040 blocks, 0.0% fragmentation) >> > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1e: FILE SYSTEM CLEAN; >> > SKIPPING CHECKS >> > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1e: FILE SYSTEM CLEAN; >> > SKIPPING CHECKS >> > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1e: clean, 1230068 free >> > (7300 frags, 152846 blocks, 0.5% fragmentation) >> > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1e: clean, 726361 free >> > (6297 frags, 90008 blocks, 0.4% fragmentation) >> > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1e: FILE SYSTEM CLEAN; >> > SKIPPING CHECKS >> > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1e: clean, 1299097 free >> > (6385 frags, 161589 blocks, 0.4% fragmentation) >> > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1e: FILE SYSTEM CLEAN; >> > SKIPPING CHECKS >> > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1e: clean, 822303 free >> > (1047 frags, 102657 blocks, 0.1% fragmentation) >> > <118>/dev/zvol/tank/VMs/current/i386/disk0s1d: FILE SYSTEM CLEAN; >> > SKIPPING CHECKS >> > <118>/dev/zvol/tank/VMs/current/i386/disk0s1d: clean, 399855 free (15 >> > frags, 49980 blocks, 0.0% fragmentation) >> > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1e: FILE SYSTEM CLEAN; >> > SKIPPING CHECKS >> > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1e: clean, 937324 free >> > (7524 frags, 116225 blocks, 0.5% fragmentation) >> > <118>/dev/zvol/tank/VMs/current/i386/disk0s1e: FILE SYSTEM CLEAN; >> > SKIPPING CHECKS >> > <118>/dev/zvol/tank/VMs/current/i386/disk0s1e: clean, 1077125 free (845 >> > frags, 134535 blocks, 0.1% fragmentation) >> > <118>Mounting local filesystems:. >> > <118>ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib >> > /usr/local/lib/compat/pkg /usr/local/krb5/lib /usr/local/kde4/lib >> > /usr/local/lib/compat /usr/local/lib/compat/pkg /usr/local/lib/dovecot >> > /usr/local/lib/e2fsprogs /usr/local/lib/ffmpeg0 /usr/local/lib/freeradiu >> > s-3.0.15 /usr/local/lib/gcc48 /usr/local/lib/gcc5 /usr/local/lib/gcc6 >> > /usr/local/lib/gcc7 /usr/local/lib/gcc8 /usr/local/lib/gcc9 >> > /usr/local/lib/gegl-0.2 /usr/local/lib/graphviz /usr/local/lib/httrack >> > /usr/local/lib/itcl3.4 /usr/local/lib/jitsi/lib/native >> > /usr/local/lib/mysql /usr/local/lib/mysql/plugin /usr/local/lib/nss >> > /usr/local/lib/opencollada /usr/local/lib/perl5/5.24/mach/CORE >> > /usr/local/lib/perl5/5.26/mach/CORE /usr/local/lib/perl5/5.28/mach/CORE >> > /usr/local/lib/pgtcl /usr/local/lib/pidgin /usr/local/lib/pth >> > /usr/local/lib/qt4 /usr/local/lib/qt5 /usr/local/lib/samba4 >> > /usr/local/lib/xrdp /usr/local/libexec/openldap /usr/local/llvm-devel/li >> > b /usr/local/llvm40/lib /usr/local/llvm50/lib /usr/local/llvm60/lib >> > /usr/local/share/chromium >> > <118>32-bit compatibility ldconfig path: /usr/lib32 >> > /alt/i386/root/usr/local/lib /usr/local/lib32/compat >> > <118>Setting hostname: slippy. >> > <118>Additional TCP/IP options: rfc1323 extensions=NO. >> > <118>Setting up harvesting: [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ET >> > HER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED >> > <118>Feeding entropy: . >> > <118>Loading IP Pools. >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already >> > present in pool >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already >> > present in pool >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already >> > present in pool >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already >> > present in pool >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already >> > present in pool >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already >> > present in pool >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already >> > present in pool >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already >> > present in pool >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already >> > present in pool >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already >> > present in pool >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already >> > present in pool >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already >> > present in pool >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already >> > present in pool >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already >> > present in pool >> > <118>Enabling ipfilter. >> > <118>32:1:ioctl(add/insert rule): rule already exists >> > <118>Installing NAT rules. >> > <118>0 entries flushed from NAT table >> > <118>0 entries flushed from NAT list >> > <6>wlan0: Ethernet address: 20:6a:8a:72:03:17 >> > <118>Created wlan(4) interfaces: wlan0. >> > <118>Created clone interfaces: lagg0. >> > <6>lo0: link state changed to UP >> > <6>bge0: link state changed to DOWN >> > iwn0: iwn_read_firmware: ucode rev=0x12a80601 >> > <118>Starting wpa_supplicant. >> > <6>lagg0: link state changed to DOWN >> > iwn0: iwn_read_firmware: ucode rev=0x12a80601 >> > <118>Starting dhclient. >> > <118>lagg0: no link ... >> > <6>wlan0: link state changed to UP >> > <6>lagg0: link state changed to UP >> > <118> got link >> > <6>bge0: link state changed to UP >> > <118>Starting Network: lo0 bge0 wlan0 lagg0. >> > <118>lo0: flags=8049 metric 0 mtu 16384 >> > <118> options=680003 >> > <118> inet 127.0.0.1 netmask 0xff000000 >> > <118> inet6 ::1 prefixlen 128 >> > <118> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 >> > <118> nd6 options=21 >> > <118> groups: lo >> > <118>bge0: flags=8843 metric 0 >> > mtu 1500 >> > <118> options=80080 >> > <118> ether 20:6a:8a:72:03:17 >> > <118> nd6 options=29 >> > <118> media: Ethernet autoselect (1000baseT ) >> > <118> status: active >> > <118>wlan0: flags=8843 metric 0 >> > mtu 1500 >> > <118> ether 20:6a:8a:72:03:17 >> > <118> nd6 options=29 >> > <118> media: IEEE 802.11 Wireless Ethernet MCS mode 11ng >> > <118> status: associated >> > <118> ssid Walden_Pond channel 1 (2412 MHz 11g ht/20) bssid >> > 4c:60:de:31:3c:17 >> > <118> regdomain FCC country US authmode WPA2/802.11i privacy ON >> > <118> deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 120 scanvalid >> > 16959 >> > <118> protmode CTS ampdulimit 64k ampdudensity 8 -amsdutx amsdurx >> > shortgi >> > <118> -stbc -ldpc wme roaming MANUAL >> > <118> groups: wlan >> > <118>lagg0: flags=8843 metric 0 >> > mtu 1500 >> > <118> ether 20:6a:8a:72:03:17 >> > <118> inet6 fe80::226a:8aff:fe72:317%lagg0 prefixlen 64 scopeid 0x4 >> > <118> inet 0.0.0.0 netmask 0x0 broadcast 255.255.255.255 >> > <118> nd6 options=23 >> > <118> media: Ethernet autoselect >> > <118> status: active >> > <118> groups: lagg >> > <118> laggproto failover lagghash l2,l3,l4 >> > <118> laggport: bge0 flags=5 >> > <118> laggport: wlan0 flags=0<> >> > <118>filter sync'd >> > <118>Starting devd. >> > <118>Starting ums0 moused. >> > <118>Autoloading module: uhid.ko >> > uhid0 on uhub2 >> > uhid0: on >> > usbus0 >> > uhid1 on uhub6 >> > uhid1: on >> > usbus1 >> > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or >> > use 'onestart' instead of 'start'. >> > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or >> > use 'onestart' instead of 'start'. >> > <118>Cannot 'start' webcamd. Set webcamd_enable to YES in /etc/rc.conf >> > or use 'onestart' instead of 'start'. >> > uhid2 on uhub6 >> > uhid2: on >> > usbus1 >> > device_attach: uhid2 attach returned 12 >> > <118>Cannot 'start' webcamd. Set webcamd_enable to YES in /etc/rc.conf >> > or use 'onestart' instead of 'start'. >> > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or >> > use 'onestart' instead of 'start'. >> > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or >> > use 'onestart' instead of 'start'. >> > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or >> > use 'onestart' instead of 'start'. >> > <118>Starting ums1 moused. >> > <118>Autoloading module: uhid.ko >> > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or >> > use 'onestart' instead of 'start'. >> > <118>Autoloading module: uhid.ko >> > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or >> > use 'onestart' instead of 'start'. >> > <118>local: Not in a function >> > <118>local: Not in a function >> > <118>dhclient not running? (check /var/run/dhclient.bge0.pid). >> > <118>Stopping dhclient. >> > <118>Waiting for PIDS: 471. >> > <118>Starting dhclient. >> > <118>add host 127.0.0.1: gateway lo0 fib 0: route already in table >> > <118>Additional inet routing options: ignore ICMP redirect=YES log ICMP >> > redirect=YES. >> > <118>add host ::1: gateway lo0 fib 0: route already in table >> > <118>add net fe80::: gateway ::1 >> > <118>add net ff02::: gateway ::1 >> > <118>add net ::ffff:0.0.0.0: gateway ::1 >> > <118>add net ::0.0.0.0: gateway ::1 >> > <118>Starting rtsold. >> > >> > >> > Fatal trap 12: page fault while in kernel mode >> > cpuid = 3; apic id = 03 >> > fault virtual address = 0x0 >> > fault code = supervisor read data, page not present >> > instruction pointer = 0x20:0xffffffff80806966 >> > stack pointer = 0x28:0xfffffe00004667d0 >> > frame pointer = 0x28:0xfffffe0000466840 >> > code segment = base 0x0, limit 0xfffff, type 0x1b >> > = DPL 0, pres 1, long 1, def32 0, gran 1 >> > processor eflags = interrupt enabled, resume, IOPL = 0 >> > current process = 12 (swi1: netisr 0) >> > trap number = 12 >> > panic: page fault >> > cpuid = 3 >> > time = 1529587144 >> > KDB: stack backtrace: >> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> > 0xfffffe0000466480 >> > vpanic() at vpanic+0x1a3/frame 0xfffffe00004664e0 >> > panic() at panic+0x43/frame 0xfffffe0000466540 >> > trap_fatal() at trap_fatal+0x35f/frame 0xfffffe0000466590 >> > trap_pfault() at trap_pfault+0x49/frame 0xfffffe00004665f0 >> > trap() at trap+0x29e/frame 0xfffffe0000466700 >> > calltrap() at calltrap+0x8/frame 0xfffffe0000466700 >> > --- trap 0xc, rip = 0xffffffff80806966, rsp = 0xfffffe00004667d0, rbp = >> > 0xfffffe0000466840 --- >> > udp_append() at udp_append+0x26/frame 0xfffffe0000466840 >> > udp_input() at udp_input+0x574/frame 0xfffffe0000466910 >> > ip_input() at ip_input+0x145/frame 0xfffffe0000466970 >> > swi_net() at swi_net+0x17b/frame 0xfffffe00004669e0 >> > intr_event_execute_handlers() at intr_event_execute_handlers+0xe9/frame >> > 0xfffffe0000466a20 >> > ithread_loop() at ithread_loop+0xe7/frame 0xfffffe0000466a70 >> > fork_exit() at fork_exit+0x83/frame 0xfffffe0000466ab0 >> > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0000466ab0 >> > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- >> > Uptime: 51s >> > Dumping 697 out of 7975 MB:..3%..12%..21%..33%..42%..51%..62%..72%..81%. >> > .92% >> > >> > __curthread () at ./machine/pcpu.h:231 >> > 231 __asm("movq %%gs:%1,%0" : "=r" (td) >> > (kgdb) bt >> > #0 __curthread () at ./machine/pcpu.h:231 >> > #1 doadump (textdump=1) at /opt/src/svn-current/sys/kern/kern_shutdown. >> > c:366 >> > #2 0xffffffff8061b330 in kern_reboot (howto=260) >> > at /opt/src/svn-current/sys/kern/kern_shutdown.c:446 >> > #3 0xffffffff8061b7c3 in vpanic (fmt=, >> > ap=0xfffffe0000466520) >> > at /opt/src/svn-current/sys/kern/kern_shutdown.c:863 >> > #4 0xffffffff8061b5b3 in panic (fmt=) >> > at /opt/src/svn-current/sys/kern/kern_shutdown.c:790 >> > #5 0xffffffff8095e76f in trap_fatal (frame=0xfffffe0000466710, eva=0) >> > at /opt/src/svn-current/sys/amd64/amd64/trap.c:892 >> > #6 0xffffffff8095e7c9 in trap_pfault (frame=0xfffffe0000466710, >> > usermode=0) >> > at /opt/src/svn-current/sys/amd64/amd64/trap.c:728 >> > #7 0xffffffff8095ddee in trap (frame=0xfffffe0000466710) >> > at /opt/src/svn-current/sys/amd64/amd64/trap.c:427 >> > #8 >> > #9 udp_append (inp=0xfffff80031d2ed58, ip=0xfffff800039333a0, >> > n=0xfffff80003933300, off=20, udp_in=0xfffffe0000466850) >> > at /opt/src/svn-current/sys/netinet/udp_usrreq.c:314 >> > #10 0xffffffff80806464 in udp_input (mp=, >> > offp=, >> > proto=17) at /opt/src/svn-current/sys/netinet/udp_usrreq.c:722 >> > #11 0xffffffff8075f645 in ip_input (m=0x0) >> > at /opt/src/svn-current/sys/netinet/ip_input.c:825 >> > #12 0xffffffff8073959b in netisr_process_workstream_proto ( >> > ---Type to continue, or q to quit---q >> > nwsp=,Quit >> > (kgdb) frame 9 >> > #9 udp_append (inp=0xfffff80031d2ed58, ip=0xfffff800039333a0, >> > n=0xfffff80003933300, off=20, udp_in=0xfffffe0000466850) >> > at /opt/src/svn-current/sys/netinet/udp_usrreq.c:314 >> > 314 if (up->u_tun_func != NULL) { >> > (kgdb) l >> > 309 >> > 310 /* >> > 311 * Engage the tunneling protocol. >> > 312 */ >> > 313 up = intoudpcb(inp); >> > 314 if (up->u_tun_func != NULL) { >> > 315 in_pcbref(inp); >> > 316 INP_RUNLOCK(inp); >> > 317 (*up->u_tun_func)(n, off, inp, (struct sockaddr *)& >> udp_in[0], >> > 318 up->u_tun_ctx); >> > (kgdb) p up >> > $1 = (struct udpcb *) 0x0 >> > (kgdb) p *inp >> > $2 = {inp_hash = {cle_next = 0x0, cle_prev = 0xfffff800023abf70}, >> > inp_pcbgrouphash = {cle_next = 0x0, cle_prev = 0x0}, inp_lock = { >> > lock_object = {lo_name = 0xffffffff80a02fc7 "udpinp", lo_flags = >> > 90898432, >> > lo_data = 0, lo_witness = 0x0}, rw_lock = 33}, inp_hpts = { >> > tqe_next = 0x0, tqe_prev = 0x0}, inp_hpts_request = 0, >> > inp_in_hpts = 0 '\000', inp_in_input = 0 '\000', inp_hpts_cpu = 0, >> > inp_refcount = 1, inp_flags = 8405056, inp_flags2 = 16, inp_input_cpu >> > = 0, >> > inp_hpts_cpu_set = 0 '\000', inp_input_cpu_set = 0 '\000', >> > inp_hpts_calls = 0 '\000', inp_input_calls = 0 '\000', >> > inp_spare_bits2 = 0 '\000', inp_spare_byte = 0 '\000', inp_ppcb = >> > 0x0, >> > inp_socket = 0x0, inp_hptsslot = 0, inp_hpts_drop_reas = 0, inp_input >> > = { >> > tqe_next = 0x0, tqe_prev = 0x0}, inp_pcbinfo = 0xfffffe0048566738, >> > inp_pcbgroup = 0x0, inp_pcbgroup_wild = {cle_next = 0x0, cle_prev = >> > 0x0}, >> > inp_cred = 0xfffff80031366600, inp_flow = 0, inp_vflag = 1 '\001', >> > inp_ip_ttl = 64 '@', inp_ip_p = 0 '\000', inp_ip_minttl = 0 '\000', >> > inp_flowid = 60, inp_snd_tag = 0x0, inp_flowtype = 63, >> > inp_rss_listen_bucket = 0, inp_inc = {inc_flags = 0 '\000', >> > inc_len = 0 '\000', inc_fibnum = 0, inc_ie = {ie_fport = 0, >> > ie_lport = 28353, ie_dependfaddr = {id46_addr = {ia46_pad32 = {0, >> > 0, 0}, >> > ia46_addr4 = {s_addr = 0}}, id6_addr = {__u6_addr = { >> > __u6_addr8 = '\000' , __u6_addr16 = {0, >> > 0, 0, 0, >> > 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}}, >> > ie_dependladdr = { >> > id46_addr = {ia46_pad32 = {0, 0, 0}, ia46_addr4 = { >> > ---Type to continue, or q to quit--- >> > s_addr = 16777343}}, id6_addr = {__u6_addr = { >> > __u6_addr8 = '\000' , "\177\000\000\001", >> > __u6_addr16 = {0, 0, 0, 0, 0, 0, 127, 256}, __u6_addr32 = >> > {0, 0, >> > 0, 16777343}}}}, ie6_zoneid = 0}}, inp_label = 0x0, >> > inp_sp = 0xfffff8000725dee0, {inp_ip_tos = 0 '\000', inp_options = >> > 0x0, >> > inp_moptions = 0x0}, {in6p_options = 0x0, in6p_outputopts = 0x0, >> > in6p_moptions = 0x0, in6p_icmp6filt = 0x0, in6p_cksum = 0, >> > in6p_hops = 0}, >> > inp_portlist = {cle_next = 0x0, cle_prev = 0xfffff80002334d20}, >> > inp_phd = 0xfffff80002334d00, inp_gencnt = 169, inp_lle = 0x0, >> > inp_rt_cookie = 7, {inp_route = {ro_rt = 0x0, ro_lle = 0x0, >> > ro_prepend = 0x0, ro_plen = 0, ro_flags = 256, ro_mtu = 0, spare >> > = 0, >> > ro_dst = {sa_len = 0 '\000', sa_family = 0 '\000', >> > sa_data = '\000' }}, inp_route6 = {ro_rt = >> > 0x0, >> > ro_lle = 0x0, ro_prepend = 0x0, ro_plen = 0, ro_flags = 256, >> > ro_mtu = 0, >> > spare = 0, ro_dst = {sin6_len = 0 '\000', sin6_family = 0 '\000', >> > sin6_port = 0, sin6_flowinfo = 0, sin6_addr = {__u6_addr = { >> > __u6_addr8 = '\000' , __u6_addr16 = {0, >> > 0, 0, 0, >> > 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id >> > = 0}}}, >> > inp_list = {cle_next = 0xfffff80031d4e000, cle_prev = >> > 0xfffffe0048566828}, >> > inp_epoch_ctx = {data = {0xffffffff80759b10 , >> > 0xfffff80002334d08}}} >> > (kgdb) up >> > #10 0xffffffff80806464 in udp_input (mp=, >> > offp=, >> > proto=17) at /opt/src/svn-current/sys/netinet/udp_usrreq.c:722 >> > 722 if (udp_append(inp, ip, m, iphlen, udp_in) == 0) >> > (kgdb) l >> > 717 return (IPPROTO_DONE); >> > 718 } >> > 719 } >> > 720 >> > 721 UDP_PROBE(receive, NULL, inp, ip, inp, uh); >> > 722 if (udp_append(inp, ip, m, iphlen, udp_in) == 0) >> > 723 INP_RUNLOCK(inp); >> > 724 return (IPPROTO_DONE); >> > 725 >> > 726 badunlocked: >> > (kgdb) up >> > #11 0xffffffff8075f645 in ip_input (m=0x0) >> > at /opt/src/svn-current/sys/netinet/ip_input.c:825 >> > 825 (*inetsw[ip_protox[ip->ip_p]].pr_input)(&m, &hlen, ip->ip_p >> ); >> > (kgdb) l >> > 820 /* >> > 821 * Switch out to protocol's input routine. >> > 822 */ >> > 823 IPSTAT_INC(ips_delivered); >> > 824 >> > 825 (*inetsw[ip_protox[ip->ip_p]].pr_input)(&m, &hlen, ip->ip_p >> ); >> > 826 return; >> > 827 bad: >> > 828 m_freem(m); >> > 829 } >> > (kgdb) >> > >> > >> > In both cases rtsold was starting. >> > >> > >> > >> > -- >> > Cheers, >> > Cy Schubert >> > FreeBSD UNIX: Web: http://www.FreeBSD.org >> > >> > The need of the many outweighs the greed of the few. >> > >> > >> > _______________________________________________ >> > 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 Fri Jun 22 01:50:15 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DA5691009D8C for ; Fri, 22 Jun 2018 01:50:14 +0000 (UTC) (envelope-from cy.schubert@cschubert.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 4068278D76 for ; Fri, 22 Jun 2018 01:50:14 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: by mailman.ysv.freebsd.org (Postfix) id EF88C1009D8B; Fri, 22 Jun 2018 01:50:13 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9A84D1009D8A for ; Fri, 22 Jun 2018 01:50:13 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DB24F78D74; Fri, 22 Jun 2018 01:50:12 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id WBDAfjTwJSzNNWBDBfWgPl; Thu, 21 Jun 2018 19:50:05 -0600 X-Authority-Analysis: v=2.3 cv=KuxjJ1eN c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=7mUfYlMuFuIA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=xfDLHkLGAAAA:8 a=mDV3o1hIAAAA:8 a=VvRnbvacaox2kBrXniAA:9 a=1-rgeKb0oY6L2VYR:21 a=Il5DP49W69wcmnYn:21 a=XqE05Yf1wqetR3ZW:21 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=IfaqVvZgccqrtc8gcwf2:22 a=_FVE-zBwftR9WsbkzFJk:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 9592396F; Thu, 21 Jun 2018 18:50:02 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id w5M1o1b4018521; Thu, 21 Jun 2018 18:50:01 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id w5M1o0WE018518; Thu, 21 Jun 2018 18:50:00 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201806220150.w5M1o0WE018518@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Matthew Macy cc: Cy Schubert , Peter Holm , current@freebsd.org Subject: Re: Page fault in udp_usrreq.c:823 In-Reply-To: Message from Matthew Macy of "Thu, 21 Jun 2018 18:42:41 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Jun 2018 18:50:00 -0700 X-CMAE-Envelope: MS4wfEb9E0s+PGtO0ckbyoJayeAvNm91AS5lrnQ9jHbxnjUpE6FbRSJket2ptWT0+P3sWxSWGwY2BRvS1Xf4HAjw4rSA0MfW0BWNO4gVOG1uQibQe1Pk2DA2 fXa7hpCUi5vxvv5etS5JnzmZCE6cBZNr/XCGejN7uEFsVHlVeU4hQRbbrIRmJfL/Fif4VMK9Ibua4BEGDmZOFWXLi4VzxRm/Buy9Z/aAhgVF4mD2GTBbl9WX X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 22 Jun 2018 01:50:15 -0000 I saw them go by on my phone, thinking they might fix it. Building now. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. In message , Matthew Macy writes: > I made changes this morning / early afternoon. > -M > > On Thu, Jun 21, 2018 at 6:41 PM, Cy Schubert wrot > e: > > Like as of now? > > > > The last panic occurred this morning after a build last night. > > > > > > -- > > Cheers, > > Cy Schubert > > FreeBSD UNIX: Web: http://www.FreeBSD.org > > > > The need of the many outweighs the greed of the few. > > > > > > In message > il.com> > > , Matthew Macy writes: > >> Try updating. It should be fixed. > >> > >> On Thu, Jun 21, 2018 at 6:14 PM, Cy Schubert w > rot > >> e: > >> > In message <20180620090957.GA130@x2.osted.lan>, Peter Holm writes: > >> >> 20180620 10:32:47 all (1/1): udp.sh > >> >> Kernel page fault with the following non-sleepable locks held: > >> >> shared rw udpinp (udpinp) r = 0 (0xfffff80bbc808d78) locked @ netinet/i > n_p > >> cb. > >> >> c:2398 > >> >> stack backtrace: > >> >> #0 0xffffffff80c00733 at witness_debugger+0x73 > >> >> #1 0xffffffff80c01b11 at witness_warn+0x461 > >> >> #2 0xffffffff81075763 at trap_pfault+0x53 > >> >> #3 0xffffffff81074d7a at trap+0x2ba > >> >> #4 0xffffffff8105076c at calltrap+0x8 > >> >> #5 0xffffffff80dd21b0 at udp_ctlinput+0x50 > >> >> #6 0xffffffff80d3081d at icmp_input+0x96d > >> >> #7 0xffffffff80d316d7 at ip_input+0x3f7 > >> >> #8 0xffffffff80cc0a92 at netisr_dispatch_src+0xa2 > >> >> #9 0xffffffff80ca3ebe at ether_demux+0x16e > >> >> #10 0xffffffff80ca5377 at ether_nh_input+0x427 > >> >> #11 0xffffffff80cc0a92 at netisr_dispatch_src+0xa2 > >> >> #12 0xffffffff80ca437f at ether_input+0x8f > >> >> #13 0xffffffff80cbc500 at iflib_rxeof+0xc90 > >> >> #14 0xffffffff80cb6b6f at _task_fn_rx+0x7f > >> >> #15 0xffffffff80bdd209 at gtaskqueue_run_locked+0x139 > >> >> #16 0xffffffff80bdcf88 at gtaskqueue_thread_loop+0x88 > >> >> #17 0xffffffff80b54514 at fork_exit+0x84 > >> >> > >> >> > >> >> Fatal trap 12: page fault while in kernel mode > >> >> cpuid = 10; apic id = 0a > >> >> fault virtual address = 0x8 > >> >> fault code = supervisor read data, page not present > >> >> instruction pointer = 0x20:0xffffffff80dd2423 > >> >> stack pointer = 0x0:0xfffffe00004a5500 > >> >> frame pointer = 0x0:0xfffffe00004a55a0 > >> >> code segment = base 0x0, limit 0xfffff, type 0x1b > >> >> = DPL 0, pres 1, long 1, def32 0, gran 1 > >> >> processor eflags = interrupt enabled, resume, IOPL = 0 > >> >> current process = 0 (if_io_tqg_10) > >> >> [ thread pid 0 tid 100069 ] > >> >> Stopped at udp_common_ctlinput+0x263: cmpq $0,0x8(%rax) > >> >> db> > >> >> > >> >> Details @ https://people.freebsd.org/~pho/stress/log/udp_usrreq.txt > >> >> > >> >> -- > >> >> Peter > >> >> _______________________________________________ > >> >> 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" > >> >> > >> > > >> > This is surprisingly similar to my panic. Twice since June 19. > >> > > >> > slippy# kgdb /boot/kernel/kernel vmcore.3 > >> > GNU gdb (GDB) 8.1 [GDB v8.1 for FreeBSD] > >> > Copyright (C) 2018 Free Software Foundation, Inc. > >> > License GPLv3+: GNU GPL version 3 or later >> > html> > >> > This is free software: you are free to change and redistribute it. > >> > There is NO WARRANTY, to the extent permitted by law. Type "show > >> > copying" > >> > and "show warranty" for details. > >> > This GDB was configured as "x86_64-portbld-freebsd12.0". > >> > Type "show configuration" for configuration details. > >> > For bug reporting instructions, please see: > >> > . > >> > Find the GDB manual and other documentation resources online at: > >> > . > >> > For help, type "help". > >> > Type "apropos word" to search for commands related to "word"... > >> > Reading symbols from /boot/kernel/kernel...Reading symbols from > >> > /usr/lib/debug//boot/kernel/kernel.debug...done. > >> > done. > >> > > >> > Unread portion of the kernel message buffer: > >> > Copyright (c) 1992-2018 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 #355 r335477M: Thu Jun 21 05:26:35 PDT 2018 > >> > root@slippy:/export/obj/opt/src/svn-current/amd64.amd64/sys/BREAK > >> > amd64 > >> > FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on > >> > LLVM 6.0.0) > >> > VT(vga): text 80x25 > >> > module_register: cannot register mmc/mmcsd from kernel; already loaded > >> > from mmcsd.ko > >> > Module mmc/mmcsd failed to register: 17 > >> > CPU: Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz (2294.83-MHz K8-class CPU) > >> > Origin="GenuineIntel" Id=0x206a7 Family=0x6 Model=0x2a Stepping=7 > >> > Features=0xbfebfbff >> > GE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > >> > Features2=0x1dbae3bf >> > 3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,XSAVE,OSXSAVE,A > >> > VX> > >> > AMD Features=0x28100800 > >> > AMD Features2=0x1 > >> > XSAVE Features=0x1 > >> > VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID > >> > TSC: P-state invariant, performance statistics > >> > real memory = 8589934592 (8192 MB) > >> > avail memory = 8080965632 (7706 MB) > >> > ACPI APIC Table: > >> > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > >> > FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads > >> > random: unblocking device. > >> > ioapic0 irqs 0-23 on motherboard > >> > random: entropy device external interface > >> > module_register_init: MOD_LOAD (vesa, 0xffffffff8097b700, 0) error 19 > >> > kbd1 at kbdmux0 > >> > nexus0 > >> > vtvga0: on motherboard > >> > cryptosoft0: on motherboard > >> > acpi0: on motherboard > >> > acpi0: Power Button (fixed) > >> > cpu0: on acpi0 > >> > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > >> > Timecounter "HPET" frequency 14318180 Hz quality 950 > >> > Event timer "HPET" frequency 14318180 Hz quality 550 > >> > Event timer "HPET1" frequency 14318180 Hz quality 440 > >> > Event timer "HPET2" frequency 14318180 Hz quality 440 > >> > Event timer "HPET3" frequency 14318180 Hz quality 440 > >> > Event timer "HPET4" frequency 14318180 Hz quality 440 > >> > atrtc0: port 0x70-0x77 irq 8 on acpi0 > >> > atrtc0: Warning: Couldn't map I/O. > >> > atrtc0: registered as a time-of-day clock, resolution 1.000000s > >> > attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 > >> > Timecounter "i8254" frequency 1193182 Hz quality 0 > >> > Event timer "i8254" frequency 1193182 Hz quality 100 > >> > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > >> > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > >> > acpi_ec0: port 0x62,0x66 on acpi0 > >> > pcib0: port 0xcf8-0xcff on acpi0 > >> > pci0: on pcib0 > >> > vgapci0: port 0x2000-0x203f mem > >> > 0xf0000000-0xf03fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 > >> > vgapci0: Boot video device > >> > pci0: at device 22.0 (no driver attached) > >> > ehci0: mem > >> > 0xf060a000-0xf060a3ff irq 16 at device 26.0 on pci0 > >> > usbus0: EHCI version 1.0 > >> > usbus0 on ehci0 > >> > hdac0: mem 0xf0600000-0xf0603fff > >> > irq 22 at device 27.0 on pci0 > >> > pcib1: irq 16 at device 28.0 on pci0 > >> > pci1: on pcib1 > >> > pcib2: irq 17 at device 28.1 on pci0 > >> > pci2: on pcib2 > >> > iwn0: mem 0xf0500000-0xf0501fff irq 17 > >> > at device 0.0 on pci2 > >> > pcib3: irq 19 at device 28.3 on pci0 > >> > pci3: on pcib3 > >> > bge0: mem > >> > 0xf0400000-0xf040ffff,0xf0410000-0xf041ffff irq 19 at device 0.0 on pci3 > >> > bge0: CHIP ID 0x57785100; ASIC REV 0x57785; CHIP REV 0x577851; PCI-E > >> > miibus0: on bge0 > >> > brgphy0: PHY 1 on miibus0 > >> > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > >> > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > >> > <6>bge0: Using defaults for TSO: 65518/35/2048 > >> > <6>bge0: Ethernet address: 20:6a:8a:72:03:17 > >> > pci3: at device 0.1 (no driver > >> > attached) > >> > ehci1: mem > >> > 0xf0609000-0xf06093ff irq 23 at device 29.0 on pci0 > >> > usbus1: EHCI version 1.0 > >> > usbus1 on ehci1 > >> > isab0: at device 31.0 on pci0 > >> > isa0: on isab0 > >> > ahci0: port > >> > 0x2088-0x208f,0x2094-0x2097,0x2080-0x2087,0x2090-0x2093,0x2060-0x207f > >> > mem 0xf0608000-0xf06087ff irq 19 at device 31.2 on pci0 > >> > ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported > >> > ahcich0: at channel 0 on ahci0 > >> > ahcich1: at channel 1 on ahci0 > >> > ahcich5: at channel 5 on ahci0 > >> > ahciem0: on ahci0 > >> > ichsmb0: port 0xefa0-0xefbf mem > >> > 0xf0604000-0xf06040ff irq 18 at device 31.3 on pci0 > >> > smbus0: on ichsmb0 > >> > smb0: on smbus0 > >> > acpi_lid0: on acpi0 > >> > acpi_button0: on acpi0 > >> > acpi_tz0: on acpi0 > >> > acpi_tz1: on acpi0 > >> > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > >> > atkbd0: irq 1 on atkbdc0 > >> > kbd0 at atkbd0 > >> > atkbd0: [GIANT-LOCKED] > >> > psm0: irq 12 on atkbdc0 > >> > psm0: [GIANT-LOCKED] > >> > psm0: model Synaptics Touchpad, device ID 0 > >> > acpi_acad0: on acpi0 > >> > battery0: on acpi0 > >> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff pnpid > >> > PNP0900 on isa0 > >> > ata0: at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 > >> > ata1: at port 0x170-0x177,0x376 irq 15 on isa0 > >> > acpi_perf0: on cpu0 > >> > coretemp0: on cpu0 > >> > ZFS filesystem version: 5 > >> > ZFS storage pool version: features support (5000) > >> > Timecounters tick every 10.000 msec > >> > IP Filter: v5.1.2 initialized. Default = pass all, Logging = enabled > >> > hdacc0: at cad 0 on hdac0 > >> > hdaa0: at nid 1 on hdacc0 > >> > pcm0: at nid 20,33 and 27 on hdaa0 > >> > pcm1: at nid 24 on hdaa0 > >> > hdacc1: at cad 3 on hdac0 > >> > hdaa1: at nid 1 on hdacc1 > >> > pcm2: at nid 5 on hdaa1 > >> > usbus0: 480Mbps High Speed USB v2.0 > >> > usbus1: 480Mbps High Speed USB v2.0 > >> > ugen1.1: at usbus1 > >> > uhub0: on usbus1 > >> > ugen0.1: at usbus0 > >> > uhub1: on usbus0 > >> > ses0 at ahciem0 bus 0 scbus3 target 0 lun 0 > >> > ses0: SEMB S-E-S 2.00 device > >> > ses0: SEMB SES Device > >> > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > >> > ada0: ATA8-ACS SATA 3.x device > >> > ada0: Serial Number JR1000D33969RE > >> > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > >> > ada0: Command Queueing enabled > >> > ada0: 953869MB (1953525168 512 byte sectors) > >> > cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 > >> > cd0: Removable CD-ROM SCSI device > >> > cd0: Serial Number SBB5103801 > >> > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO > >> > 8192bytes) > >> > cd0: Attempt to query device size failed: NOT READY, Medium not present > >> > - tray closed > >> > Launching APs: 1 3 2 > >> > Trying to mount root from ufs:/dev/ufs/Sroot [rw]... > >> > Timecounter "TSC-low" frequency 1147416846 Hz quality 1000 > >> > <118>Setting hostuuid: 34f5ed40-8938-11da-b265-efe316da850d. > >> > <118>Setting hostid: 0x7f5a03b9. > >> > uhub0: 2 ports with 2 removable, self powered > >> > uhub1: 2 ports with 2 removable, self powered > >> > ugen0.2: at usbus0 > >> > uhub2 on uhub1 > >> > uhub2: > >> > on usbus0 > >> > ugen1.2: at usbus1 > >> > uhub3 on uhub0 > >> > uhub3: > >> > on usbus1 > >> > uhub2: 6 ports with 6 removable, self powered > >> > uhub3: 6 ports with 6 removable, self powered > >> > ugen0.3: at usbus0 > >> > ukbd0 on uhub2 > >> > ukbd0: on > >> > usbus0 > >> > kbd2 at ukbd0 > >> > ums0 on uhub2 > >> > ums0: on > >> > usbus0 > >> > ums0: 16 buttons and [XYZT] coordinates ID=2 > >> > ugen1.3: at usbus1 > >> > uhub4 on uhub3 > >> > uhub4: on > >> > usbus1 > >> > uhub4: 4 ports with 4 removable, self powered > >> > ugen0.4: at usbus0 > >> > ugen1.4: at usbus1 > >> > uhub5 on uhub4 > >> > uhub5: on > >> > usbus1 > >> > uhub5: 4 ports with 4 removable, self powered > >> > ugen1.5: at usbus1 > >> > uhub6 on uhub5 > >> > uhub6: on > >> > usbus1 > >> > uhub6: 4 ports with 4 removable, self powered > >> > ugen1.6: at usbus1 > >> > ukbd1 on uhub6 > >> > ukbd1: on > >> > usbus1 > >> > kbd3 at ukbd1 > >> > ums1 on uhub6 > >> > ums1: on > >> > usbus1 > >> > ums1: 16 buttons and [XYZT] coordinates ID=2 > >> > ugen1.7: at usbus1 > >> > ukbd2 on uhub6 > >> > ukbd2: on > >> > usbus1 > >> > kbd4 at ukbd2 > >> > ugen1.8: at usbus1 > >> > umass0 on uhub5 > >> > umass0: on > >> > usbus1 > >> > umass0: SCSI over Bulk-Only; quirks = 0x408c > >> > umass0:6:0: Attached to scbus6 > >> > da0 at umass-sim0 bus 0 scbus6 target 0 lun 0 > >> > da0: Fixed Direct Access SCSI device > >> > da0: 40.000MB/s transfers > >> > da0: 76319MB (156301488 512 byte sectors) > >> > da0: quirks=0x2 > >> > <118>Starting file system checks: > >> > <118>/dev/ufs/Sroot: FILE SYSTEM CLEAN; SKIPPING CHECKS > >> > <118>/dev/ufs/Sroot: clean, 413829 free (909 frags, 51615 blocks, 0.2% > >> > fragmentation) > >> > <118>/dev/ufs/Susr: FILE SYSTEM CLEAN; SKIPPING CHECKS > >> > <118>/dev/ufs/Susr: clean, 459287 free (4847 frags, 56805 blocks, 0.6% > >> > fragmentation) > >> > <118>/dev/ufs/Svtmp: FILE SYSTEM CLEAN; SKIPPING CHECKS > >> > <118>/dev/ufs/Svtmp: clean, 503642 free (50 frags, 62949 blocks, 0.0% > >> > fragmentation) > >> > <118>/dev/ufs/SCusr: FILE SYSTEM CLEAN; SKIPPING CHECKS > >> > <118>/dev/ufs/Svar: FILE SYSTEM CLEAN; SKIPPING CHECKS > >> > <118>/dev/ufs/SSusr: FILE SYSTEM CLEAN; SKIPPING CHECKS > >> > <118>/dev/ufs/SCusr: clean, 469826 free (4578 frags, 58156 blocks, 0.6% > >> > fragmentation) > >> > <118>/dev/ufs/Svar: clean, 453726 free (574 frags, 56644 blocks, 0.1% > >> > fragmentation) > >> > <118>/dev/ufs/SCroot: FILE SYSTEM CLEAN; SKIPPING CHECKS > >> > <118>/dev/ufs/SSusr: clean, 569245 free (3653 frags, 70699 blocks, 0.5% > >> > fragmentation) > >> > <118>/dev/ufs/SCroot: clean, 422625 free (617 frags, 52751 blocks, 0.1% > >> > fragmentation) > >> > <118>/dev/ufs/SCvar: FILE SYSTEM CLEAN; SKIPPING CHECKS > >> > <118>/dev/ufs/SSvar: FILE SYSTEM CLEAN; SKIPPING CHECKS > >> > <118>/dev/ufs/SCvar: clean, 400011 free (99 frags, 49989 blocks, 0.0% > >> > fragmentation) > >> > <118>/dev/ufs/SSvar: clean, 457058 free (138 frags, 57115 blocks, 0.0% > >> > fragmentation) > >> > <118>/dev/ufs/SSroot: FILE SYSTEM CLEAN; SKIPPING CHECKS > >> > <118>/dev/ufs/SSroot: clean, 412995 free (219 frags, 51597 blocks, 0.0% > >> > fragmentation) > >> > <118>/dev/msdosfs/SHARED: FILESYSTEM CLEAN; SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/current/i386/disk0s1a: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/current/i386/disk0s1a: clean, 254465 free (337 > >> > frags, 31766 blocks, 0.1% fragmentation) > >> > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1a: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1a: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1a: clean, 335508 free > >> > (1348 frags, 41770 blocks, 0.1% fragmentation) > >> > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1a: clean, 566833 free > >> > (2297 frags, 70567 blocks, 0.2% fragmentation) > >> > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1a: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1a: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1a: clean, 510529 free > >> > (1185 frags, 63668 blocks, 0.1% fragmentation) > >> > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1a: clean, 354656 free (336 > >> > frags, 44290 blocks, 0.1% fragmentation) > >> > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1a: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1a: clean, 633994 free > >> > (2106 frags, 78986 blocks, 0.2% fragmentation) > >> > <118>/dev/zvol/tank/VMs/current/amd64/disk3p1: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/current/amd64/disk3p1: clean, 2535564 free (564 > >> > frags, 316875 blocks, 0.0% fragmentation) > >> > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1d: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1d: clean, 897924 free > >> > (188 frags, 112217 blocks, 0.0% fragmentation) > >> > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1d: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1d: clean, 897896 free > >> > (152 frags, 112218 blocks, 0.0% fragmentation) > >> > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1d: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1d: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1d: clean, 889422 free (214 > >> > frags, 111151 blocks, 0.0% fragmentation) > >> > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1d: clean, 889419 free (219 > >> > frags, 111150 blocks, 0.0% fragmentation) > >> > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1d: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1d: clean, 408410 free (90 > >> > frags, 51040 blocks, 0.0% fragmentation) > >> > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1e: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1e: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1e: clean, 1230068 free > >> > (7300 frags, 152846 blocks, 0.5% fragmentation) > >> > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1e: clean, 726361 free > >> > (6297 frags, 90008 blocks, 0.4% fragmentation) > >> > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1e: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1e: clean, 1299097 free > >> > (6385 frags, 161589 blocks, 0.4% fragmentation) > >> > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1e: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1e: clean, 822303 free > >> > (1047 frags, 102657 blocks, 0.1% fragmentation) > >> > <118>/dev/zvol/tank/VMs/current/i386/disk0s1d: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/current/i386/disk0s1d: clean, 399855 free (15 > >> > frags, 49980 blocks, 0.0% fragmentation) > >> > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1e: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1e: clean, 937324 free > >> > (7524 frags, 116225 blocks, 0.5% fragmentation) > >> > <118>/dev/zvol/tank/VMs/current/i386/disk0s1e: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/current/i386/disk0s1e: clean, 1077125 free (845 > >> > frags, 134535 blocks, 0.1% fragmentation) > >> > <118>Mounting local filesystems:. > >> > <118>ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib > >> > /usr/local/lib/compat/pkg /usr/local/krb5/lib /usr/local/kde4/lib > >> > /usr/local/lib/compat /usr/local/lib/compat/pkg /usr/local/lib/dovecot > >> > /usr/local/lib/e2fsprogs /usr/local/lib/ffmpeg0 /usr/local/lib/freeradiu > >> > s-3.0.15 /usr/local/lib/gcc48 /usr/local/lib/gcc5 /usr/local/lib/gcc6 > >> > /usr/local/lib/gcc7 /usr/local/lib/gcc8 /usr/local/lib/gcc9 > >> > /usr/local/lib/gegl-0.2 /usr/local/lib/graphviz /usr/local/lib/httrack > >> > /usr/local/lib/itcl3.4 /usr/local/lib/jitsi/lib/native > >> > /usr/local/lib/mysql /usr/local/lib/mysql/plugin /usr/local/lib/nss > >> > /usr/local/lib/opencollada /usr/local/lib/perl5/5.24/mach/CORE > >> > /usr/local/lib/perl5/5.26/mach/CORE /usr/local/lib/perl5/5.28/mach/CORE > >> > /usr/local/lib/pgtcl /usr/local/lib/pidgin /usr/local/lib/pth > >> > /usr/local/lib/qt4 /usr/local/lib/qt5 /usr/local/lib/samba4 > >> > /usr/local/lib/xrdp /usr/local/libexec/openldap /usr/local/llvm-devel/li > >> > b /usr/local/llvm40/lib /usr/local/llvm50/lib /usr/local/llvm60/lib > >> > /usr/local/share/chromium > >> > <118>32-bit compatibility ldconfig path: /usr/lib32 > >> > /alt/i386/root/usr/local/lib /usr/local/lib32/compat > >> > <118>Setting hostname: slippy. > >> > <118>Additional TCP/IP options: rfc1323 extensions=NO. > >> > <118>Setting up harvesting: [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ET > >> > HER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED > >> > <118>Feeding entropy: . > >> > <118>Loading IP Pools. > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > >> > present in pool > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > >> > present in pool > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > >> > present in pool > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > >> > present in pool > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > >> > present in pool > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > >> > present in pool > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > >> > present in pool > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > >> > present in pool > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > >> > present in pool > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > >> > present in pool > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > >> > present in pool > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > >> > present in pool > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > >> > present in pool > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > >> > present in pool > >> > <118>Enabling ipfilter. > >> > <118>32:1:ioctl(add/insert rule): rule already exists > >> > <118>Installing NAT rules. > >> > <118>0 entries flushed from NAT table > >> > <118>0 entries flushed from NAT list > >> > <6>wlan0: Ethernet address: 20:6a:8a:72:03:17 > >> > <118>Created wlan(4) interfaces: wlan0. > >> > <118>Created clone interfaces: lagg0. > >> > <6>lo0: link state changed to UP > >> > <6>bge0: link state changed to DOWN > >> > iwn0: iwn_read_firmware: ucode rev=0x12a80601 > >> > <118>Starting wpa_supplicant. > >> > <6>lagg0: link state changed to DOWN > >> > iwn0: iwn_read_firmware: ucode rev=0x12a80601 > >> > <118>Starting dhclient. > >> > <118>lagg0: no link ... > >> > <6>wlan0: link state changed to UP > >> > <6>lagg0: link state changed to UP > >> > <118> got link > >> > <6>bge0: link state changed to UP > >> > <118>Starting Network: lo0 bge0 wlan0 lagg0. > >> > <118>lo0: flags=8049 metric 0 mtu 16384 > >> > <118> options=680003 > >> > <118> inet 127.0.0.1 netmask 0xff000000 > >> > <118> inet6 ::1 prefixlen 128 > >> > <118> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > >> > <118> nd6 options=21 > >> > <118> groups: lo > >> > <118>bge0: flags=8843 metric 0 > >> > mtu 1500 > >> > <118> options=80080 > >> > <118> ether 20:6a:8a:72:03:17 > >> > <118> nd6 options=29 > >> > <118> media: Ethernet autoselect (1000baseT ) > >> > <118> status: active > >> > <118>wlan0: flags=8843 metric 0 > >> > mtu 1500 > >> > <118> ether 20:6a:8a:72:03:17 > >> > <118> nd6 options=29 > >> > <118> media: IEEE 802.11 Wireless Ethernet MCS mode 11ng > >> > <118> status: associated > >> > <118> ssid Walden_Pond channel 1 (2412 MHz 11g ht/20) bssid > >> > 4c:60:de:31:3c:17 > >> > <118> regdomain FCC country US authmode WPA2/802.11i privacy ON > >> > <118> deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 120 scanvalid > >> > 16959 > >> > <118> protmode CTS ampdulimit 64k ampdudensity 8 -amsdutx amsdurx > >> > shortgi > >> > <118> -stbc -ldpc wme roaming MANUAL > >> > <118> groups: wlan > >> > <118>lagg0: flags=8843 metric 0 > >> > mtu 1500 > >> > <118> ether 20:6a:8a:72:03:17 > >> > <118> inet6 fe80::226a:8aff:fe72:317%lagg0 prefixlen 64 scopeid 0x4 > >> > <118> inet 0.0.0.0 netmask 0x0 broadcast 255.255.255.255 > >> > <118> nd6 options=23 > >> > <118> media: Ethernet autoselect > >> > <118> status: active > >> > <118> groups: lagg > >> > <118> laggproto failover lagghash l2,l3,l4 > >> > <118> laggport: bge0 flags=5 > >> > <118> laggport: wlan0 flags=0<> > >> > <118>filter sync'd > >> > <118>Starting devd. > >> > <118>Starting ums0 moused. > >> > <118>Autoloading module: uhid.ko > >> > uhid0 on uhub2 > >> > uhid0: on > >> > usbus0 > >> > uhid1 on uhub6 > >> > uhid1: on > >> > usbus1 > >> > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > >> > use 'onestart' instead of 'start'. > >> > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > >> > use 'onestart' instead of 'start'. > >> > <118>Cannot 'start' webcamd. Set webcamd_enable to YES in /etc/rc.conf > >> > or use 'onestart' instead of 'start'. > >> > uhid2 on uhub6 > >> > uhid2: on > >> > usbus1 > >> > device_attach: uhid2 attach returned 12 > >> > <118>Cannot 'start' webcamd. Set webcamd_enable to YES in /etc/rc.conf > >> > or use 'onestart' instead of 'start'. > >> > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > >> > use 'onestart' instead of 'start'. > >> > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > >> > use 'onestart' instead of 'start'. > >> > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > >> > use 'onestart' instead of 'start'. > >> > <118>Starting ums1 moused. > >> > <118>Autoloading module: uhid.ko > >> > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > >> > use 'onestart' instead of 'start'. > >> > <118>Autoloading module: uhid.ko > >> > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > >> > use 'onestart' instead of 'start'. > >> > <118>local: Not in a function > >> > <118>local: Not in a function > >> > <118>dhclient not running? (check /var/run/dhclient.bge0.pid). > >> > <118>Stopping dhclient. > >> > <118>Waiting for PIDS: 471. > >> > <118>Starting dhclient. > >> > <118>add host 127.0.0.1: gateway lo0 fib 0: route already in table > >> > <118>Additional inet routing options: ignore ICMP redirect=YES log ICMP > >> > redirect=YES. > >> > <118>add host ::1: gateway lo0 fib 0: route already in table > >> > <118>add net fe80::: gateway ::1 > >> > <118>add net ff02::: gateway ::1 > >> > <118>add net ::ffff:0.0.0.0: gateway ::1 > >> > <118>add net ::0.0.0.0: gateway ::1 > >> > <118>Starting rtsold. > >> > > >> > > >> > Fatal trap 12: page fault while in kernel mode > >> > cpuid = 3; apic id = 03 > >> > fault virtual address = 0x0 > >> > fault code = supervisor read data, page not present > >> > instruction pointer = 0x20:0xffffffff80806966 > >> > stack pointer = 0x28:0xfffffe00004667d0 > >> > frame pointer = 0x28:0xfffffe0000466840 > >> > code segment = base 0x0, limit 0xfffff, type 0x1b > >> > = DPL 0, pres 1, long 1, def32 0, gran 1 > >> > processor eflags = interrupt enabled, resume, IOPL = 0 > >> > current process = 12 (swi1: netisr 0) > >> > trap number = 12 > >> > panic: page fault > >> > cpuid = 3 > >> > time = 1529587144 > >> > KDB: stack backtrace: > >> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > >> > 0xfffffe0000466480 > >> > vpanic() at vpanic+0x1a3/frame 0xfffffe00004664e0 > >> > panic() at panic+0x43/frame 0xfffffe0000466540 > >> > trap_fatal() at trap_fatal+0x35f/frame 0xfffffe0000466590 > >> > trap_pfault() at trap_pfault+0x49/frame 0xfffffe00004665f0 > >> > trap() at trap+0x29e/frame 0xfffffe0000466700 > >> > calltrap() at calltrap+0x8/frame 0xfffffe0000466700 > >> > --- trap 0xc, rip = 0xffffffff80806966, rsp = 0xfffffe00004667d0, rbp = > >> > 0xfffffe0000466840 --- > >> > udp_append() at udp_append+0x26/frame 0xfffffe0000466840 > >> > udp_input() at udp_input+0x574/frame 0xfffffe0000466910 > >> > ip_input() at ip_input+0x145/frame 0xfffffe0000466970 > >> > swi_net() at swi_net+0x17b/frame 0xfffffe00004669e0 > >> > intr_event_execute_handlers() at intr_event_execute_handlers+0xe9/frame > >> > 0xfffffe0000466a20 > >> > ithread_loop() at ithread_loop+0xe7/frame 0xfffffe0000466a70 > >> > fork_exit() at fork_exit+0x83/frame 0xfffffe0000466ab0 > >> > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0000466ab0 > >> > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > >> > Uptime: 51s > >> > Dumping 697 out of 7975 MB:..3%..12%..21%..33%..42%..51%..62%..72%..81%. > >> > .92% > >> > > >> > __curthread () at ./machine/pcpu.h:231 > >> > 231 __asm("movq %%gs:%1,%0" : "=r" (td) > >> > (kgdb) bt > >> > #0 __curthread () at ./machine/pcpu.h:231 > >> > #1 doadump (textdump=1) at /opt/src/svn-current/sys/kern/kern_shutdown. > >> > c:366 > >> > #2 0xffffffff8061b330 in kern_reboot (howto=260) > >> > at /opt/src/svn-current/sys/kern/kern_shutdown.c:446 > >> > #3 0xffffffff8061b7c3 in vpanic (fmt=, > >> > ap=0xfffffe0000466520) > >> > at /opt/src/svn-current/sys/kern/kern_shutdown.c:863 > >> > #4 0xffffffff8061b5b3 in panic (fmt=) > >> > at /opt/src/svn-current/sys/kern/kern_shutdown.c:790 > >> > #5 0xffffffff8095e76f in trap_fatal (frame=0xfffffe0000466710, eva=0) > >> > at /opt/src/svn-current/sys/amd64/amd64/trap.c:892 > >> > #6 0xffffffff8095e7c9 in trap_pfault (frame=0xfffffe0000466710, > >> > usermode=0) > >> > at /opt/src/svn-current/sys/amd64/amd64/trap.c:728 > >> > #7 0xffffffff8095ddee in trap (frame=0xfffffe0000466710) > >> > at /opt/src/svn-current/sys/amd64/amd64/trap.c:427 > >> > #8 > >> > #9 udp_append (inp=0xfffff80031d2ed58, ip=0xfffff800039333a0, > >> > n=0xfffff80003933300, off=20, udp_in=0xfffffe0000466850) > >> > at /opt/src/svn-current/sys/netinet/udp_usrreq.c:314 > >> > #10 0xffffffff80806464 in udp_input (mp=, > >> > offp=, > >> > proto=17) at /opt/src/svn-current/sys/netinet/udp_usrreq.c:722 > >> > #11 0xffffffff8075f645 in ip_input (m=0x0) > >> > at /opt/src/svn-current/sys/netinet/ip_input.c:825 > >> > #12 0xffffffff8073959b in netisr_process_workstream_proto ( > >> > ---Type to continue, or q to quit---q > >> > nwsp=,Quit > >> > (kgdb) frame 9 > >> > #9 udp_append (inp=0xfffff80031d2ed58, ip=0xfffff800039333a0, > >> > n=0xfffff80003933300, off=20, udp_in=0xfffffe0000466850) > >> > at /opt/src/svn-current/sys/netinet/udp_usrreq.c:314 > >> > 314 if (up->u_tun_func != NULL) { > >> > (kgdb) l > >> > 309 > >> > 310 /* > >> > 311 * Engage the tunneling protocol. > >> > 312 */ > >> > 313 up = intoudpcb(inp); > >> > 314 if (up->u_tun_func != NULL) { > >> > 315 in_pcbref(inp); > >> > 316 INP_RUNLOCK(inp); > >> > 317 (*up->u_tun_func)(n, off, inp, (struct sockaddr > *)& > >> udp_in[0], > >> > 318 up->u_tun_ctx); > >> > (kgdb) p up > >> > $1 = (struct udpcb *) 0x0 > >> > (kgdb) p *inp > >> > $2 = {inp_hash = {cle_next = 0x0, cle_prev = 0xfffff800023abf70}, > >> > inp_pcbgrouphash = {cle_next = 0x0, cle_prev = 0x0}, inp_lock = { > >> > lock_object = {lo_name = 0xffffffff80a02fc7 "udpinp", lo_flags = > >> > 90898432, > >> > lo_data = 0, lo_witness = 0x0}, rw_lock = 33}, inp_hpts = { > >> > tqe_next = 0x0, tqe_prev = 0x0}, inp_hpts_request = 0, > >> > inp_in_hpts = 0 '\000', inp_in_input = 0 '\000', inp_hpts_cpu = 0, > >> > inp_refcount = 1, inp_flags = 8405056, inp_flags2 = 16, inp_input_cpu > >> > = 0, > >> > inp_hpts_cpu_set = 0 '\000', inp_input_cpu_set = 0 '\000', > >> > inp_hpts_calls = 0 '\000', inp_input_calls = 0 '\000', > >> > inp_spare_bits2 = 0 '\000', inp_spare_byte = 0 '\000', inp_ppcb = > >> > 0x0, > >> > inp_socket = 0x0, inp_hptsslot = 0, inp_hpts_drop_reas = 0, inp_input > >> > = { > >> > tqe_next = 0x0, tqe_prev = 0x0}, inp_pcbinfo = 0xfffffe0048566738, > >> > inp_pcbgroup = 0x0, inp_pcbgroup_wild = {cle_next = 0x0, cle_prev = > >> > 0x0}, > >> > inp_cred = 0xfffff80031366600, inp_flow = 0, inp_vflag = 1 '\001', > >> > inp_ip_ttl = 64 '@', inp_ip_p = 0 '\000', inp_ip_minttl = 0 '\000', > >> > inp_flowid = 60, inp_snd_tag = 0x0, inp_flowtype = 63, > >> > inp_rss_listen_bucket = 0, inp_inc = {inc_flags = 0 '\000', > >> > inc_len = 0 '\000', inc_fibnum = 0, inc_ie = {ie_fport = 0, > >> > ie_lport = 28353, ie_dependfaddr = {id46_addr = {ia46_pad32 = {0, > >> > 0, 0}, > >> > ia46_addr4 = {s_addr = 0}}, id6_addr = {__u6_addr = { > >> > __u6_addr8 = '\000' , __u6_addr16 = {0, > >> > 0, 0, 0, > >> > 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}}, > >> > ie_dependladdr = { > >> > id46_addr = {ia46_pad32 = {0, 0, 0}, ia46_addr4 = { > >> > ---Type to continue, or q to quit--- > >> > s_addr = 16777343}}, id6_addr = {__u6_addr = { > >> > __u6_addr8 = '\000' , "\177\000\000\001", > >> > __u6_addr16 = {0, 0, 0, 0, 0, 0, 127, 256}, __u6_addr32 = > >> > {0, 0, > >> > 0, 16777343}}}}, ie6_zoneid = 0}}, inp_label = 0x0, > >> > inp_sp = 0xfffff8000725dee0, {inp_ip_tos = 0 '\000', inp_options = > >> > 0x0, > >> > inp_moptions = 0x0}, {in6p_options = 0x0, in6p_outputopts = 0x0, > >> > in6p_moptions = 0x0, in6p_icmp6filt = 0x0, in6p_cksum = 0, > >> > in6p_hops = 0}, > >> > inp_portlist = {cle_next = 0x0, cle_prev = 0xfffff80002334d20}, > >> > inp_phd = 0xfffff80002334d00, inp_gencnt = 169, inp_lle = 0x0, > >> > inp_rt_cookie = 7, {inp_route = {ro_rt = 0x0, ro_lle = 0x0, > >> > ro_prepend = 0x0, ro_plen = 0, ro_flags = 256, ro_mtu = 0, spare > >> > = 0, > >> > ro_dst = {sa_len = 0 '\000', sa_family = 0 '\000', > >> > sa_data = '\000' }}, inp_route6 = {ro_rt = > >> > 0x0, > >> > ro_lle = 0x0, ro_prepend = 0x0, ro_plen = 0, ro_flags = 256, > >> > ro_mtu = 0, > >> > spare = 0, ro_dst = {sin6_len = 0 '\000', sin6_family = 0 '\000', > >> > sin6_port = 0, sin6_flowinfo = 0, sin6_addr = {__u6_addr = { > >> > __u6_addr8 = '\000' , __u6_addr16 = {0, > >> > 0, 0, 0, > >> > 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id > >> > = 0}}}, > >> > inp_list = {cle_next = 0xfffff80031d4e000, cle_prev = > >> > 0xfffffe0048566828}, > >> > inp_epoch_ctx = {data = {0xffffffff80759b10 , > >> > 0xfffff80002334d08}}} > >> > (kgdb) up > >> > #10 0xffffffff80806464 in udp_input (mp=, > >> > offp=, > >> > proto=17) at /opt/src/svn-current/sys/netinet/udp_usrreq.c:722 > >> > 722 if (udp_append(inp, ip, m, iphlen, udp_in) == 0) > >> > (kgdb) l > >> > 717 return (IPPROTO_DONE); > >> > 718 } > >> > 719 } > >> > 720 > >> > 721 UDP_PROBE(receive, NULL, inp, ip, inp, uh); > >> > 722 if (udp_append(inp, ip, m, iphlen, udp_in) == 0) > >> > 723 INP_RUNLOCK(inp); > >> > 724 return (IPPROTO_DONE); > >> > 725 > >> > 726 badunlocked: > >> > (kgdb) up > >> > #11 0xffffffff8075f645 in ip_input (m=0x0) > >> > at /opt/src/svn-current/sys/netinet/ip_input.c:825 > >> > 825 (*inetsw[ip_protox[ip->ip_p]].pr_input)(&m, &hlen, ip->i > p_p > >> ); > >> > (kgdb) l > >> > 820 /* > >> > 821 * Switch out to protocol's input routine. > >> > 822 */ > >> > 823 IPSTAT_INC(ips_delivered); > >> > 824 > >> > 825 (*inetsw[ip_protox[ip->ip_p]].pr_input)(&m, &hlen, ip->i > p_p > >> ); > >> > 826 return; > >> > 827 bad: > >> > 828 m_freem(m); > >> > 829 } > >> > (kgdb) > >> > > >> > > >> > In both cases rtsold was starting. > >> > > >> > > >> > > >> > -- > >> > Cheers, > >> > Cy Schubert > >> > FreeBSD UNIX: Web: http://www.FreeBSD.org > >> > > >> > The need of the many outweighs the greed of the few. > >> > > >> > > >> > _______________________________________________ > >> > freebsd-current@freebsd.org mailing list > >> > https://lists.freebsd.org/mailman/listinfo/freebsd-current > >> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or > g" > > > > From owner-freebsd-current@freebsd.org Fri Jun 22 02:43:48 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B775D100B048 for ; Fri, 22 Jun 2018 02:43:48 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from vps-mail.nomadlogic.org (mail.nomadlogic.org [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 333DF7A529 for ; Fri, 22 Jun 2018 02:43:47 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [IPv6:2605:e000:1313:89:223:24ff:fea8:4fb5] (2605:e000:1313:89:223:24ff:fea8:4fb5 [IPv6:2605:e000:1313:89:223:24ff:fea8:4fb5]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 397fdcc1 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO for ; Thu, 21 Jun 2018 19:43:45 -0700 (PDT) To: FreeBSD-current From: Pete Wright Subject: buildkernel broken on if_ixl when EVDEV is enabled Message-ID: <3d9cffa3-8ee1-96e2-6edd-d3bf27fd88a5@nomadlogic.org> Date: Thu, 21 Jun 2018 19:43:44 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 22 Jun 2018 02:43:48 -0000 howdy - just ran into an issue with building a kernel that has EVDEV enabled causing this error: --- kernel.full --- linking kernel.full ld: error: undefined symbol: ixl_iw_pf_init >>> referenced by if_ixl.c:900 (/usr/home/pete/git/freebsd/sys/dev/ixl/if_ixl.c:900) >>>               if_ixl.o:(ixl_if_init) ld: error: undefined symbol: ixl_iw_pf_stop >>> referenced by if_ixl.c:920 (/usr/home/pete/git/freebsd/sys/dev/ixl/if_ixl.c:920) >>>               if_ixl.o:(ixl_if_stop) ld: error: undefined symbol: ixl_iw_pf_attach >>> referenced by if_ixl.c:669 (/usr/home/pete/git/freebsd/sys/dev/ixl/if_ixl.c:669) >>>               if_ixl.o:(ixl_if_attach_post) ld: error: undefined symbol: ixl_iw_pf_detach >>> referenced by if_ixl.c:711 (/usr/home/pete/git/freebsd/sys/dev/ixl/if_ixl.c:711) >>>               if_ixl.o:(ixl_if_detach) *** [kernel.full] Error code 1 building a standard GENERIC kernel works without issue.  my "EVDEV" kern conf has the following two lines added: options         EVDEV_SUPPORT           # D10265 from phabricator device          evdev Not sure if anyone else has seen this? -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Fri Jun 22 03:47:49 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B2D9100C6CB for ; Fri, 22 Jun 2018 03:47:49 +0000 (UTC) (envelope-from danilogondolfo@gmail.com) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 ABDAE7C4A3 for ; Fri, 22 Jun 2018 03:47:48 +0000 (UTC) (envelope-from danilogondolfo@gmail.com) Received: by mail-ua0-x22d.google.com with SMTP id k14-v6so3419232uao.12 for ; Thu, 21 Jun 2018 20:47:48 -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=PJVeqFmUgXwMoLxGv0d7J+wVnMLUxOtCP2Y5fm6Hd6g=; b=ICZZyq8CaOjsW3SP0aRldO6CurQHNSzuIE1xb4/+z/z9Vs7zbLLdDaPxl/iAAt2akd 0VEgA3erG7dnKC0Ba1naSwGLpNYQtmR3b0YN+fE9ejGAjzjbMj/QWPO36sJNGt3VHb1P U3vKehdd5SPyuFncBfKU9v5zzwsLJjrHWC1yrfJqCLNZKnm4eRqI7q2va9TiduAxNvyO nF/HBavnXsrw8rzWVTlpJau+cNxAcxMZvrDFrg1/SFYpJurLXlHiP8LafRkpAWtOCkp5 F4y/Dv/u1IkTAuxU6Y7+qz/4chcw+isGo2YUBd6yH5DjtRwHGnMQmKM0rxnBcXyjUNpn pH5w== 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=PJVeqFmUgXwMoLxGv0d7J+wVnMLUxOtCP2Y5fm6Hd6g=; b=Qz4KyIq+h8Wn4iQRMOMnpRVSrO3NyJgi9ReEgTD9shO59uriCr1IVMdenzzDwmOYFw oRVX7n3uDiIyDcyz5HtyJ6nBWIzdJ3HTVS8hpBK3/z9t5QgH6f9E2WU5BgdcPDBwzW8R m/lV5RGHN3DHyD6p6MbdjIHll8nh7uLnGjKURFDxEukZrgZ0Q7mSfmN6ViqeGv0VFhGS HyEh2x13kjxyFH6Ih1ybqeHktlkK3hCLQMSxJAmNnN2g6L4wCb/MGrY8cEAkS5wgQp3g cR5VAp11iIDLiSYATP3KFbTo71ZQ8639dT0daX+CGc74EJTV3rGLJzAjzkENPzliaftS 415A== X-Gm-Message-State: APt69E2fDjUyueN6Q2VglSE3VkfI5ZozPivTVWIvamr5La+C2sDtZWoc uANv/2LhNTFl/hgCs6eTNFjp5szQZVL487MqyCyjrw== X-Google-Smtp-Source: ADUXVKJHNwMGGInIMs6pTNrDLsETqHo3L6efZ1S8ptiJgSTk1+8J3RpmJke3acHPx4TKZShomiVJyQfXqVrFDOXFJ80= X-Received: by 2002:a9f:396b:: with SMTP id i43-v6mr18221311uag.63.1529639267910; Thu, 21 Jun 2018 20:47:47 -0700 (PDT) MIME-Version: 1.0 Sender: danilogondolfo@gmail.com Received: by 2002:a67:6143:0:0:0:0:0 with HTTP; Thu, 21 Jun 2018 20:47:27 -0700 (PDT) In-Reply-To: <3d9cffa3-8ee1-96e2-6edd-d3bf27fd88a5@nomadlogic.org> References: <3d9cffa3-8ee1-96e2-6edd-d3bf27fd88a5@nomadlogic.org> From: =?UTF-8?Q?Danilo_Eg=C3=AAa_Gondolfo?= Date: Fri, 22 Jun 2018 00:47:27 -0300 X-Google-Sender-Auth: kPCORCFrz9PuUI8cLtztgF0GGuQ Message-ID: Subject: Re: buildkernel broken on if_ixl when EVDEV is enabled To: Pete Wright Cc: FreeBSD-current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 22 Jun 2018 03:47:49 -0000 Hi, check if you have 'options IXL_IW' in your kernel conf. It's removed from GENERIC. I had the same problem here with my customized conf. On Thu, Jun 21, 2018 at 11:43 PM, Pete Wright wrote: > howdy - just ran into an issue with building a kernel that has EVDEV > enabled causing this error: > > --- kernel.full --- > linking kernel.full > ld: error: undefined symbol: ixl_iw_pf_init > >>> referenced by if_ixl.c:900 (/usr/home/pete/git/freebsd/sy > s/dev/ixl/if_ixl.c:900) > >>> if_ixl.o:(ixl_if_init) > > ld: error: undefined symbol: ixl_iw_pf_stop > >>> referenced by if_ixl.c:920 (/usr/home/pete/git/freebsd/sy > s/dev/ixl/if_ixl.c:920) > >>> if_ixl.o:(ixl_if_stop) > > ld: error: undefined symbol: ixl_iw_pf_attach > >>> referenced by if_ixl.c:669 (/usr/home/pete/git/freebsd/sy > s/dev/ixl/if_ixl.c:669) > >>> if_ixl.o:(ixl_if_attach_post) > > ld: error: undefined symbol: ixl_iw_pf_detach > >>> referenced by if_ixl.c:711 (/usr/home/pete/git/freebsd/sy > s/dev/ixl/if_ixl.c:711) > >>> if_ixl.o:(ixl_if_detach) > *** [kernel.full] Error code 1 > > > building a standard GENERIC kernel works without issue. my "EVDEV" kern > conf has the following two lines added: > > options EVDEV_SUPPORT # D10265 from phabricator > device evdev > > Not sure if anyone else has seen this? > > -pete > > -- > Pete Wright > pete@nomadlogic.org > @nomadlogicLA > > _______________________________________________ > 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 Fri Jun 22 05:28:01 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 80754100EB4D for ; Fri, 22 Jun 2018 05:28:01 +0000 (UTC) (envelope-from pho@holm.cc) 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 EB17C7F110 for ; Fri, 22 Jun 2018 05:28:00 +0000 (UTC) (envelope-from pho@holm.cc) Received: by mailman.ysv.freebsd.org (Postfix) id A7002100EB4C; Fri, 22 Jun 2018 05:28:00 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4ABD9100EB4B for ; Fri, 22 Jun 2018 05:28:00 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) (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 F267A7F109; Fri, 22 Jun 2018 05:27:59 +0000 (UTC) (envelope-from pho@holm.cc) Received: from x2.osted.lan (87-58-223-204-dynamic.dk.customer.tdc.net [87.58.223.204]) by relay01.pair.com (Postfix) with ESMTP id A2A8FD00B93; Fri, 22 Jun 2018 01:27:58 -0400 (EDT) Received: from x2.osted.lan (localhost [127.0.0.1]) by x2.osted.lan (8.15.2/8.15.2) with ESMTPS id w5M5Ruq8049235 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 22 Jun 2018 07:27:56 +0200 (CEST) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.15.2/8.15.2/Submit) id w5M5RtRY049234; Fri, 22 Jun 2018 07:27:55 +0200 (CEST) (envelope-from pho) Date: Fri, 22 Jun 2018 07:27:55 +0200 From: Peter Holm To: Matthew Macy Cc: Cy Schubert , current@freebsd.org Subject: Re: Page fault in udp_usrreq.c:823 Message-ID: <20180622052755.GA49166@x2.osted.lan> References: <201806220141.w5M1fdOb081507@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 22 Jun 2018 05:28:01 -0000 On Thu, Jun 21, 2018 at 06:42:41PM -0700, Matthew Macy wrote: > I made changes this morning / early afternoon. > -M > With r335501 I no longer see any of the issues I reported. Thank you for the fix! - Peter > On Thu, Jun 21, 2018 at 6:41 PM, Cy Schubert wrote: > > Like as of now? > > > > The last panic occurred this morning after a build last night. > > > > > > -- > > Cheers, > > Cy Schubert > > FreeBSD UNIX: Web: http://www.FreeBSD.org > > > > The need of the many outweighs the greed of the few. > > > > > > In message > il.com> > > , Matthew Macy writes: > >> Try updating. It should be fixed. > >> > >> On Thu, Jun 21, 2018 at 6:14 PM, Cy Schubert wrot > >> e: > >> > In message <20180620090957.GA130@x2.osted.lan>, Peter Holm writes: > >> >> 20180620 10:32:47 all (1/1): udp.sh > >> >> Kernel page fault with the following non-sleepable locks held: > >> >> shared rw udpinp (udpinp) r = 0 (0xfffff80bbc808d78) locked @ netinet/in_p > >> cb. > >> >> c:2398 > >> >> stack backtrace: > >> >> #0 0xffffffff80c00733 at witness_debugger+0x73 > >> >> #1 0xffffffff80c01b11 at witness_warn+0x461 > >> >> #2 0xffffffff81075763 at trap_pfault+0x53 > >> >> #3 0xffffffff81074d7a at trap+0x2ba > >> >> #4 0xffffffff8105076c at calltrap+0x8 > >> >> #5 0xffffffff80dd21b0 at udp_ctlinput+0x50 > >> >> #6 0xffffffff80d3081d at icmp_input+0x96d > >> >> #7 0xffffffff80d316d7 at ip_input+0x3f7 > >> >> #8 0xffffffff80cc0a92 at netisr_dispatch_src+0xa2 > >> >> #9 0xffffffff80ca3ebe at ether_demux+0x16e > >> >> #10 0xffffffff80ca5377 at ether_nh_input+0x427 > >> >> #11 0xffffffff80cc0a92 at netisr_dispatch_src+0xa2 > >> >> #12 0xffffffff80ca437f at ether_input+0x8f > >> >> #13 0xffffffff80cbc500 at iflib_rxeof+0xc90 > >> >> #14 0xffffffff80cb6b6f at _task_fn_rx+0x7f > >> >> #15 0xffffffff80bdd209 at gtaskqueue_run_locked+0x139 > >> >> #16 0xffffffff80bdcf88 at gtaskqueue_thread_loop+0x88 > >> >> #17 0xffffffff80b54514 at fork_exit+0x84 > >> >> > >> >> > >> >> Fatal trap 12: page fault while in kernel mode > >> >> cpuid = 10; apic id = 0a > >> >> fault virtual address = 0x8 > >> >> fault code = supervisor read data, page not present > >> >> instruction pointer = 0x20:0xffffffff80dd2423 > >> >> stack pointer = 0x0:0xfffffe00004a5500 > >> >> frame pointer = 0x0:0xfffffe00004a55a0 > >> >> code segment = base 0x0, limit 0xfffff, type 0x1b > >> >> = DPL 0, pres 1, long 1, def32 0, gran 1 > >> >> processor eflags = interrupt enabled, resume, IOPL = 0 > >> >> current process = 0 (if_io_tqg_10) > >> >> [ thread pid 0 tid 100069 ] > >> >> Stopped at udp_common_ctlinput+0x263: cmpq $0,0x8(%rax) > >> >> db> > >> >> > >> >> Details @ https://people.freebsd.org/~pho/stress/log/udp_usrreq.txt > >> >> > >> >> -- > >> >> Peter > >> >> _______________________________________________ > >> >> freebsd-current@freebsd.org mailing list > >> >> https://lists.freebsd.org/mailman/listinfo/freebsd-current > >> >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > >> >> > >> > > >> > This is surprisingly similar to my panic. Twice since June 19. > >> > > >> > slippy# kgdb /boot/kernel/kernel vmcore.3 > >> > GNU gdb (GDB) 8.1 [GDB v8.1 for FreeBSD] > >> > Copyright (C) 2018 Free Software Foundation, Inc. > >> > License GPLv3+: GNU GPL version 3 or later >> > html> > >> > This is free software: you are free to change and redistribute it. > >> > There is NO WARRANTY, to the extent permitted by law. Type "show > >> > copying" > >> > and "show warranty" for details. > >> > This GDB was configured as "x86_64-portbld-freebsd12.0". > >> > Type "show configuration" for configuration details. > >> > For bug reporting instructions, please see: > >> > . > >> > Find the GDB manual and other documentation resources online at: > >> > . > >> > For help, type "help". > >> > Type "apropos word" to search for commands related to "word"... > >> > Reading symbols from /boot/kernel/kernel...Reading symbols from > >> > /usr/lib/debug//boot/kernel/kernel.debug...done. > >> > done. > >> > > >> > Unread portion of the kernel message buffer: > >> > Copyright (c) 1992-2018 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 #355 r335477M: Thu Jun 21 05:26:35 PDT 2018 > >> > root@slippy:/export/obj/opt/src/svn-current/amd64.amd64/sys/BREAK > >> > amd64 > >> > FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on > >> > LLVM 6.0.0) > >> > VT(vga): text 80x25 > >> > module_register: cannot register mmc/mmcsd from kernel; already loaded > >> > from mmcsd.ko > >> > Module mmc/mmcsd failed to register: 17 > >> > CPU: Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz (2294.83-MHz K8-class CPU) > >> > Origin="GenuineIntel" Id=0x206a7 Family=0x6 Model=0x2a Stepping=7 > >> > Features=0xbfebfbff >> > GE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > >> > Features2=0x1dbae3bf >> > 3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,XSAVE,OSXSAVE,A > >> > VX> > >> > AMD Features=0x28100800 > >> > AMD Features2=0x1 > >> > XSAVE Features=0x1 > >> > VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID > >> > TSC: P-state invariant, performance statistics > >> > real memory = 8589934592 (8192 MB) > >> > avail memory = 8080965632 (7706 MB) > >> > ACPI APIC Table: > >> > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > >> > FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads > >> > random: unblocking device. > >> > ioapic0 irqs 0-23 on motherboard > >> > random: entropy device external interface > >> > module_register_init: MOD_LOAD (vesa, 0xffffffff8097b700, 0) error 19 > >> > kbd1 at kbdmux0 > >> > nexus0 > >> > vtvga0: on motherboard > >> > cryptosoft0: on motherboard > >> > acpi0: on motherboard > >> > acpi0: Power Button (fixed) > >> > cpu0: on acpi0 > >> > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > >> > Timecounter "HPET" frequency 14318180 Hz quality 950 > >> > Event timer "HPET" frequency 14318180 Hz quality 550 > >> > Event timer "HPET1" frequency 14318180 Hz quality 440 > >> > Event timer "HPET2" frequency 14318180 Hz quality 440 > >> > Event timer "HPET3" frequency 14318180 Hz quality 440 > >> > Event timer "HPET4" frequency 14318180 Hz quality 440 > >> > atrtc0: port 0x70-0x77 irq 8 on acpi0 > >> > atrtc0: Warning: Couldn't map I/O. > >> > atrtc0: registered as a time-of-day clock, resolution 1.000000s > >> > attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 > >> > Timecounter "i8254" frequency 1193182 Hz quality 0 > >> > Event timer "i8254" frequency 1193182 Hz quality 100 > >> > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > >> > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > >> > acpi_ec0: port 0x62,0x66 on acpi0 > >> > pcib0: port 0xcf8-0xcff on acpi0 > >> > pci0: on pcib0 > >> > vgapci0: port 0x2000-0x203f mem > >> > 0xf0000000-0xf03fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 > >> > vgapci0: Boot video device > >> > pci0: at device 22.0 (no driver attached) > >> > ehci0: mem > >> > 0xf060a000-0xf060a3ff irq 16 at device 26.0 on pci0 > >> > usbus0: EHCI version 1.0 > >> > usbus0 on ehci0 > >> > hdac0: mem 0xf0600000-0xf0603fff > >> > irq 22 at device 27.0 on pci0 > >> > pcib1: irq 16 at device 28.0 on pci0 > >> > pci1: on pcib1 > >> > pcib2: irq 17 at device 28.1 on pci0 > >> > pci2: on pcib2 > >> > iwn0: mem 0xf0500000-0xf0501fff irq 17 > >> > at device 0.0 on pci2 > >> > pcib3: irq 19 at device 28.3 on pci0 > >> > pci3: on pcib3 > >> > bge0: mem > >> > 0xf0400000-0xf040ffff,0xf0410000-0xf041ffff irq 19 at device 0.0 on pci3 > >> > bge0: CHIP ID 0x57785100; ASIC REV 0x57785; CHIP REV 0x577851; PCI-E > >> > miibus0: on bge0 > >> > brgphy0: PHY 1 on miibus0 > >> > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > >> > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > >> > <6>bge0: Using defaults for TSO: 65518/35/2048 > >> > <6>bge0: Ethernet address: 20:6a:8a:72:03:17 > >> > pci3: at device 0.1 (no driver > >> > attached) > >> > ehci1: mem > >> > 0xf0609000-0xf06093ff irq 23 at device 29.0 on pci0 > >> > usbus1: EHCI version 1.0 > >> > usbus1 on ehci1 > >> > isab0: at device 31.0 on pci0 > >> > isa0: on isab0 > >> > ahci0: port > >> > 0x2088-0x208f,0x2094-0x2097,0x2080-0x2087,0x2090-0x2093,0x2060-0x207f > >> > mem 0xf0608000-0xf06087ff irq 19 at device 31.2 on pci0 > >> > ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported > >> > ahcich0: at channel 0 on ahci0 > >> > ahcich1: at channel 1 on ahci0 > >> > ahcich5: at channel 5 on ahci0 > >> > ahciem0: on ahci0 > >> > ichsmb0: port 0xefa0-0xefbf mem > >> > 0xf0604000-0xf06040ff irq 18 at device 31.3 on pci0 > >> > smbus0: on ichsmb0 > >> > smb0: on smbus0 > >> > acpi_lid0: on acpi0 > >> > acpi_button0: on acpi0 > >> > acpi_tz0: on acpi0 > >> > acpi_tz1: on acpi0 > >> > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > >> > atkbd0: irq 1 on atkbdc0 > >> > kbd0 at atkbd0 > >> > atkbd0: [GIANT-LOCKED] > >> > psm0: irq 12 on atkbdc0 > >> > psm0: [GIANT-LOCKED] > >> > psm0: model Synaptics Touchpad, device ID 0 > >> > acpi_acad0: on acpi0 > >> > battery0: on acpi0 > >> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff pnpid > >> > PNP0900 on isa0 > >> > ata0: at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 > >> > ata1: at port 0x170-0x177,0x376 irq 15 on isa0 > >> > acpi_perf0: on cpu0 > >> > coretemp0: on cpu0 > >> > ZFS filesystem version: 5 > >> > ZFS storage pool version: features support (5000) > >> > Timecounters tick every 10.000 msec > >> > IP Filter: v5.1.2 initialized. Default = pass all, Logging = enabled > >> > hdacc0: at cad 0 on hdac0 > >> > hdaa0: at nid 1 on hdacc0 > >> > pcm0: at nid 20,33 and 27 on hdaa0 > >> > pcm1: at nid 24 on hdaa0 > >> > hdacc1: at cad 3 on hdac0 > >> > hdaa1: at nid 1 on hdacc1 > >> > pcm2: at nid 5 on hdaa1 > >> > usbus0: 480Mbps High Speed USB v2.0 > >> > usbus1: 480Mbps High Speed USB v2.0 > >> > ugen1.1: at usbus1 > >> > uhub0: on usbus1 > >> > ugen0.1: at usbus0 > >> > uhub1: on usbus0 > >> > ses0 at ahciem0 bus 0 scbus3 target 0 lun 0 > >> > ses0: SEMB S-E-S 2.00 device > >> > ses0: SEMB SES Device > >> > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > >> > ada0: ATA8-ACS SATA 3.x device > >> > ada0: Serial Number JR1000D33969RE > >> > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > >> > ada0: Command Queueing enabled > >> > ada0: 953869MB (1953525168 512 byte sectors) > >> > cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 > >> > cd0: Removable CD-ROM SCSI device > >> > cd0: Serial Number SBB5103801 > >> > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO > >> > 8192bytes) > >> > cd0: Attempt to query device size failed: NOT READY, Medium not present > >> > - tray closed > >> > Launching APs: 1 3 2 > >> > Trying to mount root from ufs:/dev/ufs/Sroot [rw]... > >> > Timecounter "TSC-low" frequency 1147416846 Hz quality 1000 > >> > <118>Setting hostuuid: 34f5ed40-8938-11da-b265-efe316da850d. > >> > <118>Setting hostid: 0x7f5a03b9. > >> > uhub0: 2 ports with 2 removable, self powered > >> > uhub1: 2 ports with 2 removable, self powered > >> > ugen0.2: at usbus0 > >> > uhub2 on uhub1 > >> > uhub2: > >> > on usbus0 > >> > ugen1.2: at usbus1 > >> > uhub3 on uhub0 > >> > uhub3: > >> > on usbus1 > >> > uhub2: 6 ports with 6 removable, self powered > >> > uhub3: 6 ports with 6 removable, self powered > >> > ugen0.3: at usbus0 > >> > ukbd0 on uhub2 > >> > ukbd0: on > >> > usbus0 > >> > kbd2 at ukbd0 > >> > ums0 on uhub2 > >> > ums0: on > >> > usbus0 > >> > ums0: 16 buttons and [XYZT] coordinates ID=2 > >> > ugen1.3: at usbus1 > >> > uhub4 on uhub3 > >> > uhub4: on > >> > usbus1 > >> > uhub4: 4 ports with 4 removable, self powered > >> > ugen0.4: at usbus0 > >> > ugen1.4: at usbus1 > >> > uhub5 on uhub4 > >> > uhub5: on > >> > usbus1 > >> > uhub5: 4 ports with 4 removable, self powered > >> > ugen1.5: at usbus1 > >> > uhub6 on uhub5 > >> > uhub6: on > >> > usbus1 > >> > uhub6: 4 ports with 4 removable, self powered > >> > ugen1.6: at usbus1 > >> > ukbd1 on uhub6 > >> > ukbd1: on > >> > usbus1 > >> > kbd3 at ukbd1 > >> > ums1 on uhub6 > >> > ums1: on > >> > usbus1 > >> > ums1: 16 buttons and [XYZT] coordinates ID=2 > >> > ugen1.7: at usbus1 > >> > ukbd2 on uhub6 > >> > ukbd2: on > >> > usbus1 > >> > kbd4 at ukbd2 > >> > ugen1.8: at usbus1 > >> > umass0 on uhub5 > >> > umass0: on > >> > usbus1 > >> > umass0: SCSI over Bulk-Only; quirks = 0x408c > >> > umass0:6:0: Attached to scbus6 > >> > da0 at umass-sim0 bus 0 scbus6 target 0 lun 0 > >> > da0: Fixed Direct Access SCSI device > >> > da0: 40.000MB/s transfers > >> > da0: 76319MB (156301488 512 byte sectors) > >> > da0: quirks=0x2 > >> > <118>Starting file system checks: > >> > <118>/dev/ufs/Sroot: FILE SYSTEM CLEAN; SKIPPING CHECKS > >> > <118>/dev/ufs/Sroot: clean, 413829 free (909 frags, 51615 blocks, 0.2% > >> > fragmentation) > >> > <118>/dev/ufs/Susr: FILE SYSTEM CLEAN; SKIPPING CHECKS > >> > <118>/dev/ufs/Susr: clean, 459287 free (4847 frags, 56805 blocks, 0.6% > >> > fragmentation) > >> > <118>/dev/ufs/Svtmp: FILE SYSTEM CLEAN; SKIPPING CHECKS > >> > <118>/dev/ufs/Svtmp: clean, 503642 free (50 frags, 62949 blocks, 0.0% > >> > fragmentation) > >> > <118>/dev/ufs/SCusr: FILE SYSTEM CLEAN; SKIPPING CHECKS > >> > <118>/dev/ufs/Svar: FILE SYSTEM CLEAN; SKIPPING CHECKS > >> > <118>/dev/ufs/SSusr: FILE SYSTEM CLEAN; SKIPPING CHECKS > >> > <118>/dev/ufs/SCusr: clean, 469826 free (4578 frags, 58156 blocks, 0.6% > >> > fragmentation) > >> > <118>/dev/ufs/Svar: clean, 453726 free (574 frags, 56644 blocks, 0.1% > >> > fragmentation) > >> > <118>/dev/ufs/SCroot: FILE SYSTEM CLEAN; SKIPPING CHECKS > >> > <118>/dev/ufs/SSusr: clean, 569245 free (3653 frags, 70699 blocks, 0.5% > >> > fragmentation) > >> > <118>/dev/ufs/SCroot: clean, 422625 free (617 frags, 52751 blocks, 0.1% > >> > fragmentation) > >> > <118>/dev/ufs/SCvar: FILE SYSTEM CLEAN; SKIPPING CHECKS > >> > <118>/dev/ufs/SSvar: FILE SYSTEM CLEAN; SKIPPING CHECKS > >> > <118>/dev/ufs/SCvar: clean, 400011 free (99 frags, 49989 blocks, 0.0% > >> > fragmentation) > >> > <118>/dev/ufs/SSvar: clean, 457058 free (138 frags, 57115 blocks, 0.0% > >> > fragmentation) > >> > <118>/dev/ufs/SSroot: FILE SYSTEM CLEAN; SKIPPING CHECKS > >> > <118>/dev/ufs/SSroot: clean, 412995 free (219 frags, 51597 blocks, 0.0% > >> > fragmentation) > >> > <118>/dev/msdosfs/SHARED: FILESYSTEM CLEAN; SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/current/i386/disk0s1a: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/current/i386/disk0s1a: clean, 254465 free (337 > >> > frags, 31766 blocks, 0.1% fragmentation) > >> > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1a: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1a: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1a: clean, 335508 free > >> > (1348 frags, 41770 blocks, 0.1% fragmentation) > >> > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1a: clean, 566833 free > >> > (2297 frags, 70567 blocks, 0.2% fragmentation) > >> > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1a: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1a: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1a: clean, 510529 free > >> > (1185 frags, 63668 blocks, 0.1% fragmentation) > >> > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1a: clean, 354656 free (336 > >> > frags, 44290 blocks, 0.1% fragmentation) > >> > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1a: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1a: clean, 633994 free > >> > (2106 frags, 78986 blocks, 0.2% fragmentation) > >> > <118>/dev/zvol/tank/VMs/current/amd64/disk3p1: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/current/amd64/disk3p1: clean, 2535564 free (564 > >> > frags, 316875 blocks, 0.0% fragmentation) > >> > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1d: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1d: clean, 897924 free > >> > (188 frags, 112217 blocks, 0.0% fragmentation) > >> > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1d: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1d: clean, 897896 free > >> > (152 frags, 112218 blocks, 0.0% fragmentation) > >> > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1d: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1d: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1d: clean, 889422 free (214 > >> > frags, 111151 blocks, 0.0% fragmentation) > >> > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1d: clean, 889419 free (219 > >> > frags, 111150 blocks, 0.0% fragmentation) > >> > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1d: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1d: clean, 408410 free (90 > >> > frags, 51040 blocks, 0.0% fragmentation) > >> > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1e: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1e: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1e: clean, 1230068 free > >> > (7300 frags, 152846 blocks, 0.5% fragmentation) > >> > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1e: clean, 726361 free > >> > (6297 frags, 90008 blocks, 0.4% fragmentation) > >> > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1e: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1e: clean, 1299097 free > >> > (6385 frags, 161589 blocks, 0.4% fragmentation) > >> > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1e: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1e: clean, 822303 free > >> > (1047 frags, 102657 blocks, 0.1% fragmentation) > >> > <118>/dev/zvol/tank/VMs/current/i386/disk0s1d: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/current/i386/disk0s1d: clean, 399855 free (15 > >> > frags, 49980 blocks, 0.0% fragmentation) > >> > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1e: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1e: clean, 937324 free > >> > (7524 frags, 116225 blocks, 0.5% fragmentation) > >> > <118>/dev/zvol/tank/VMs/current/i386/disk0s1e: FILE SYSTEM CLEAN; > >> > SKIPPING CHECKS > >> > <118>/dev/zvol/tank/VMs/current/i386/disk0s1e: clean, 1077125 free (845 > >> > frags, 134535 blocks, 0.1% fragmentation) > >> > <118>Mounting local filesystems:. > >> > <118>ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib > >> > /usr/local/lib/compat/pkg /usr/local/krb5/lib /usr/local/kde4/lib > >> > /usr/local/lib/compat /usr/local/lib/compat/pkg /usr/local/lib/dovecot > >> > /usr/local/lib/e2fsprogs /usr/local/lib/ffmpeg0 /usr/local/lib/freeradiu > >> > s-3.0.15 /usr/local/lib/gcc48 /usr/local/lib/gcc5 /usr/local/lib/gcc6 > >> > /usr/local/lib/gcc7 /usr/local/lib/gcc8 /usr/local/lib/gcc9 > >> > /usr/local/lib/gegl-0.2 /usr/local/lib/graphviz /usr/local/lib/httrack > >> > /usr/local/lib/itcl3.4 /usr/local/lib/jitsi/lib/native > >> > /usr/local/lib/mysql /usr/local/lib/mysql/plugin /usr/local/lib/nss > >> > /usr/local/lib/opencollada /usr/local/lib/perl5/5.24/mach/CORE > >> > /usr/local/lib/perl5/5.26/mach/CORE /usr/local/lib/perl5/5.28/mach/CORE > >> > /usr/local/lib/pgtcl /usr/local/lib/pidgin /usr/local/lib/pth > >> > /usr/local/lib/qt4 /usr/local/lib/qt5 /usr/local/lib/samba4 > >> > /usr/local/lib/xrdp /usr/local/libexec/openldap /usr/local/llvm-devel/li > >> > b /usr/local/llvm40/lib /usr/local/llvm50/lib /usr/local/llvm60/lib > >> > /usr/local/share/chromium > >> > <118>32-bit compatibility ldconfig path: /usr/lib32 > >> > /alt/i386/root/usr/local/lib /usr/local/lib32/compat > >> > <118>Setting hostname: slippy. > >> > <118>Additional TCP/IP options: rfc1323 extensions=NO. > >> > <118>Setting up harvesting: [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ET > >> > HER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED > >> > <118>Feeding entropy: . > >> > <118>Loading IP Pools. > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > >> > present in pool > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > >> > present in pool > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > >> > present in pool > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > >> > present in pool > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > >> > present in pool > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > >> > present in pool > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > >> > present in pool > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > >> > present in pool > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > >> > present in pool > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > >> > present in pool > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > >> > present in pool > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > >> > present in pool > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > >> > present in pool > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > >> > present in pool > >> > <118>Enabling ipfilter. > >> > <118>32:1:ioctl(add/insert rule): rule already exists > >> > <118>Installing NAT rules. > >> > <118>0 entries flushed from NAT table > >> > <118>0 entries flushed from NAT list > >> > <6>wlan0: Ethernet address: 20:6a:8a:72:03:17 > >> > <118>Created wlan(4) interfaces: wlan0. > >> > <118>Created clone interfaces: lagg0. > >> > <6>lo0: link state changed to UP > >> > <6>bge0: link state changed to DOWN > >> > iwn0: iwn_read_firmware: ucode rev=0x12a80601 > >> > <118>Starting wpa_supplicant. > >> > <6>lagg0: link state changed to DOWN > >> > iwn0: iwn_read_firmware: ucode rev=0x12a80601 > >> > <118>Starting dhclient. > >> > <118>lagg0: no link ... > >> > <6>wlan0: link state changed to UP > >> > <6>lagg0: link state changed to UP > >> > <118> got link > >> > <6>bge0: link state changed to UP > >> > <118>Starting Network: lo0 bge0 wlan0 lagg0. > >> > <118>lo0: flags=8049 metric 0 mtu 16384 > >> > <118> options=680003 > >> > <118> inet 127.0.0.1 netmask 0xff000000 > >> > <118> inet6 ::1 prefixlen 128 > >> > <118> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > >> > <118> nd6 options=21 > >> > <118> groups: lo > >> > <118>bge0: flags=8843 metric 0 > >> > mtu 1500 > >> > <118> options=80080 > >> > <118> ether 20:6a:8a:72:03:17 > >> > <118> nd6 options=29 > >> > <118> media: Ethernet autoselect (1000baseT ) > >> > <118> status: active > >> > <118>wlan0: flags=8843 metric 0 > >> > mtu 1500 > >> > <118> ether 20:6a:8a:72:03:17 > >> > <118> nd6 options=29 > >> > <118> media: IEEE 802.11 Wireless Ethernet MCS mode 11ng > >> > <118> status: associated > >> > <118> ssid Walden_Pond channel 1 (2412 MHz 11g ht/20) bssid > >> > 4c:60:de:31:3c:17 > >> > <118> regdomain FCC country US authmode WPA2/802.11i privacy ON > >> > <118> deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 120 scanvalid > >> > 16959 > >> > <118> protmode CTS ampdulimit 64k ampdudensity 8 -amsdutx amsdurx > >> > shortgi > >> > <118> -stbc -ldpc wme roaming MANUAL > >> > <118> groups: wlan > >> > <118>lagg0: flags=8843 metric 0 > >> > mtu 1500 > >> > <118> ether 20:6a:8a:72:03:17 > >> > <118> inet6 fe80::226a:8aff:fe72:317%lagg0 prefixlen 64 scopeid 0x4 > >> > <118> inet 0.0.0.0 netmask 0x0 broadcast 255.255.255.255 > >> > <118> nd6 options=23 > >> > <118> media: Ethernet autoselect > >> > <118> status: active > >> > <118> groups: lagg > >> > <118> laggproto failover lagghash l2,l3,l4 > >> > <118> laggport: bge0 flags=5 > >> > <118> laggport: wlan0 flags=0<> > >> > <118>filter sync'd > >> > <118>Starting devd. > >> > <118>Starting ums0 moused. > >> > <118>Autoloading module: uhid.ko > >> > uhid0 on uhub2 > >> > uhid0: on > >> > usbus0 > >> > uhid1 on uhub6 > >> > uhid1: on > >> > usbus1 > >> > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > >> > use 'onestart' instead of 'start'. > >> > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > >> > use 'onestart' instead of 'start'. > >> > <118>Cannot 'start' webcamd. Set webcamd_enable to YES in /etc/rc.conf > >> > or use 'onestart' instead of 'start'. > >> > uhid2 on uhub6 > >> > uhid2: on > >> > usbus1 > >> > device_attach: uhid2 attach returned 12 > >> > <118>Cannot 'start' webcamd. Set webcamd_enable to YES in /etc/rc.conf > >> > or use 'onestart' instead of 'start'. > >> > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > >> > use 'onestart' instead of 'start'. > >> > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > >> > use 'onestart' instead of 'start'. > >> > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > >> > use 'onestart' instead of 'start'. > >> > <118>Starting ums1 moused. > >> > <118>Autoloading module: uhid.ko > >> > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > >> > use 'onestart' instead of 'start'. > >> > <118>Autoloading module: uhid.ko > >> > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > >> > use 'onestart' instead of 'start'. > >> > <118>local: Not in a function > >> > <118>local: Not in a function > >> > <118>dhclient not running? (check /var/run/dhclient.bge0.pid). > >> > <118>Stopping dhclient. > >> > <118>Waiting for PIDS: 471. > >> > <118>Starting dhclient. > >> > <118>add host 127.0.0.1: gateway lo0 fib 0: route already in table > >> > <118>Additional inet routing options: ignore ICMP redirect=YES log ICMP > >> > redirect=YES. > >> > <118>add host ::1: gateway lo0 fib 0: route already in table > >> > <118>add net fe80::: gateway ::1 > >> > <118>add net ff02::: gateway ::1 > >> > <118>add net ::ffff:0.0.0.0: gateway ::1 > >> > <118>add net ::0.0.0.0: gateway ::1 > >> > <118>Starting rtsold. > >> > > >> > > >> > Fatal trap 12: page fault while in kernel mode > >> > cpuid = 3; apic id = 03 > >> > fault virtual address = 0x0 > >> > fault code = supervisor read data, page not present > >> > instruction pointer = 0x20:0xffffffff80806966 > >> > stack pointer = 0x28:0xfffffe00004667d0 > >> > frame pointer = 0x28:0xfffffe0000466840 > >> > code segment = base 0x0, limit 0xfffff, type 0x1b > >> > = DPL 0, pres 1, long 1, def32 0, gran 1 > >> > processor eflags = interrupt enabled, resume, IOPL = 0 > >> > current process = 12 (swi1: netisr 0) > >> > trap number = 12 > >> > panic: page fault > >> > cpuid = 3 > >> > time = 1529587144 > >> > KDB: stack backtrace: > >> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > >> > 0xfffffe0000466480 > >> > vpanic() at vpanic+0x1a3/frame 0xfffffe00004664e0 > >> > panic() at panic+0x43/frame 0xfffffe0000466540 > >> > trap_fatal() at trap_fatal+0x35f/frame 0xfffffe0000466590 > >> > trap_pfault() at trap_pfault+0x49/frame 0xfffffe00004665f0 > >> > trap() at trap+0x29e/frame 0xfffffe0000466700 > >> > calltrap() at calltrap+0x8/frame 0xfffffe0000466700 > >> > --- trap 0xc, rip = 0xffffffff80806966, rsp = 0xfffffe00004667d0, rbp = > >> > 0xfffffe0000466840 --- > >> > udp_append() at udp_append+0x26/frame 0xfffffe0000466840 > >> > udp_input() at udp_input+0x574/frame 0xfffffe0000466910 > >> > ip_input() at ip_input+0x145/frame 0xfffffe0000466970 > >> > swi_net() at swi_net+0x17b/frame 0xfffffe00004669e0 > >> > intr_event_execute_handlers() at intr_event_execute_handlers+0xe9/frame > >> > 0xfffffe0000466a20 > >> > ithread_loop() at ithread_loop+0xe7/frame 0xfffffe0000466a70 > >> > fork_exit() at fork_exit+0x83/frame 0xfffffe0000466ab0 > >> > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0000466ab0 > >> > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > >> > Uptime: 51s > >> > Dumping 697 out of 7975 MB:..3%..12%..21%..33%..42%..51%..62%..72%..81%. > >> > .92% > >> > > >> > __curthread () at ./machine/pcpu.h:231 > >> > 231 __asm("movq %%gs:%1,%0" : "=r" (td) > >> > (kgdb) bt > >> > #0 __curthread () at ./machine/pcpu.h:231 > >> > #1 doadump (textdump=1) at /opt/src/svn-current/sys/kern/kern_shutdown. > >> > c:366 > >> > #2 0xffffffff8061b330 in kern_reboot (howto=260) > >> > at /opt/src/svn-current/sys/kern/kern_shutdown.c:446 > >> > #3 0xffffffff8061b7c3 in vpanic (fmt=, > >> > ap=0xfffffe0000466520) > >> > at /opt/src/svn-current/sys/kern/kern_shutdown.c:863 > >> > #4 0xffffffff8061b5b3 in panic (fmt=) > >> > at /opt/src/svn-current/sys/kern/kern_shutdown.c:790 > >> > #5 0xffffffff8095e76f in trap_fatal (frame=0xfffffe0000466710, eva=0) > >> > at /opt/src/svn-current/sys/amd64/amd64/trap.c:892 > >> > #6 0xffffffff8095e7c9 in trap_pfault (frame=0xfffffe0000466710, > >> > usermode=0) > >> > at /opt/src/svn-current/sys/amd64/amd64/trap.c:728 > >> > #7 0xffffffff8095ddee in trap (frame=0xfffffe0000466710) > >> > at /opt/src/svn-current/sys/amd64/amd64/trap.c:427 > >> > #8 > >> > #9 udp_append (inp=0xfffff80031d2ed58, ip=0xfffff800039333a0, > >> > n=0xfffff80003933300, off=20, udp_in=0xfffffe0000466850) > >> > at /opt/src/svn-current/sys/netinet/udp_usrreq.c:314 > >> > #10 0xffffffff80806464 in udp_input (mp=, > >> > offp=, > >> > proto=17) at /opt/src/svn-current/sys/netinet/udp_usrreq.c:722 > >> > #11 0xffffffff8075f645 in ip_input (m=0x0) > >> > at /opt/src/svn-current/sys/netinet/ip_input.c:825 > >> > #12 0xffffffff8073959b in netisr_process_workstream_proto ( > >> > ---Type to continue, or q to quit---q > >> > nwsp=,Quit > >> > (kgdb) frame 9 > >> > #9 udp_append (inp=0xfffff80031d2ed58, ip=0xfffff800039333a0, > >> > n=0xfffff80003933300, off=20, udp_in=0xfffffe0000466850) > >> > at /opt/src/svn-current/sys/netinet/udp_usrreq.c:314 > >> > 314 if (up->u_tun_func != NULL) { > >> > (kgdb) l > >> > 309 > >> > 310 /* > >> > 311 * Engage the tunneling protocol. > >> > 312 */ > >> > 313 up = intoudpcb(inp); > >> > 314 if (up->u_tun_func != NULL) { > >> > 315 in_pcbref(inp); > >> > 316 INP_RUNLOCK(inp); > >> > 317 (*up->u_tun_func)(n, off, inp, (struct sockaddr *)& > >> udp_in[0], > >> > 318 up->u_tun_ctx); > >> > (kgdb) p up > >> > $1 = (struct udpcb *) 0x0 > >> > (kgdb) p *inp > >> > $2 = {inp_hash = {cle_next = 0x0, cle_prev = 0xfffff800023abf70}, > >> > inp_pcbgrouphash = {cle_next = 0x0, cle_prev = 0x0}, inp_lock = { > >> > lock_object = {lo_name = 0xffffffff80a02fc7 "udpinp", lo_flags = > >> > 90898432, > >> > lo_data = 0, lo_witness = 0x0}, rw_lock = 33}, inp_hpts = { > >> > tqe_next = 0x0, tqe_prev = 0x0}, inp_hpts_request = 0, > >> > inp_in_hpts = 0 '\000', inp_in_input = 0 '\000', inp_hpts_cpu = 0, > >> > inp_refcount = 1, inp_flags = 8405056, inp_flags2 = 16, inp_input_cpu > >> > = 0, > >> > inp_hpts_cpu_set = 0 '\000', inp_input_cpu_set = 0 '\000', > >> > inp_hpts_calls = 0 '\000', inp_input_calls = 0 '\000', > >> > inp_spare_bits2 = 0 '\000', inp_spare_byte = 0 '\000', inp_ppcb = > >> > 0x0, > >> > inp_socket = 0x0, inp_hptsslot = 0, inp_hpts_drop_reas = 0, inp_input > >> > = { > >> > tqe_next = 0x0, tqe_prev = 0x0}, inp_pcbinfo = 0xfffffe0048566738, > >> > inp_pcbgroup = 0x0, inp_pcbgroup_wild = {cle_next = 0x0, cle_prev = > >> > 0x0}, > >> > inp_cred = 0xfffff80031366600, inp_flow = 0, inp_vflag = 1 '\001', > >> > inp_ip_ttl = 64 '@', inp_ip_p = 0 '\000', inp_ip_minttl = 0 '\000', > >> > inp_flowid = 60, inp_snd_tag = 0x0, inp_flowtype = 63, > >> > inp_rss_listen_bucket = 0, inp_inc = {inc_flags = 0 '\000', > >> > inc_len = 0 '\000', inc_fibnum = 0, inc_ie = {ie_fport = 0, > >> > ie_lport = 28353, ie_dependfaddr = {id46_addr = {ia46_pad32 = {0, > >> > 0, 0}, > >> > ia46_addr4 = {s_addr = 0}}, id6_addr = {__u6_addr = { > >> > __u6_addr8 = '\000' , __u6_addr16 = {0, > >> > 0, 0, 0, > >> > 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}}, > >> > ie_dependladdr = { > >> > id46_addr = {ia46_pad32 = {0, 0, 0}, ia46_addr4 = { > >> > ---Type to continue, or q to quit--- > >> > s_addr = 16777343}}, id6_addr = {__u6_addr = { > >> > __u6_addr8 = '\000' , "\177\000\000\001", > >> > __u6_addr16 = {0, 0, 0, 0, 0, 0, 127, 256}, __u6_addr32 = > >> > {0, 0, > >> > 0, 16777343}}}}, ie6_zoneid = 0}}, inp_label = 0x0, > >> > inp_sp = 0xfffff8000725dee0, {inp_ip_tos = 0 '\000', inp_options = > >> > 0x0, > >> > inp_moptions = 0x0}, {in6p_options = 0x0, in6p_outputopts = 0x0, > >> > in6p_moptions = 0x0, in6p_icmp6filt = 0x0, in6p_cksum = 0, > >> > in6p_hops = 0}, > >> > inp_portlist = {cle_next = 0x0, cle_prev = 0xfffff80002334d20}, > >> > inp_phd = 0xfffff80002334d00, inp_gencnt = 169, inp_lle = 0x0, > >> > inp_rt_cookie = 7, {inp_route = {ro_rt = 0x0, ro_lle = 0x0, > >> > ro_prepend = 0x0, ro_plen = 0, ro_flags = 256, ro_mtu = 0, spare > >> > = 0, > >> > ro_dst = {sa_len = 0 '\000', sa_family = 0 '\000', > >> > sa_data = '\000' }}, inp_route6 = {ro_rt = > >> > 0x0, > >> > ro_lle = 0x0, ro_prepend = 0x0, ro_plen = 0, ro_flags = 256, > >> > ro_mtu = 0, > >> > spare = 0, ro_dst = {sin6_len = 0 '\000', sin6_family = 0 '\000', > >> > sin6_port = 0, sin6_flowinfo = 0, sin6_addr = {__u6_addr = { > >> > __u6_addr8 = '\000' , __u6_addr16 = {0, > >> > 0, 0, 0, > >> > 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id > >> > = 0}}}, > >> > inp_list = {cle_next = 0xfffff80031d4e000, cle_prev = > >> > 0xfffffe0048566828}, > >> > inp_epoch_ctx = {data = {0xffffffff80759b10 , > >> > 0xfffff80002334d08}}} > >> > (kgdb) up > >> > #10 0xffffffff80806464 in udp_input (mp=, > >> > offp=, > >> > proto=17) at /opt/src/svn-current/sys/netinet/udp_usrreq.c:722 > >> > 722 if (udp_append(inp, ip, m, iphlen, udp_in) == 0) > >> > (kgdb) l > >> > 717 return (IPPROTO_DONE); > >> > 718 } > >> > 719 } > >> > 720 > >> > 721 UDP_PROBE(receive, NULL, inp, ip, inp, uh); > >> > 722 if (udp_append(inp, ip, m, iphlen, udp_in) == 0) > >> > 723 INP_RUNLOCK(inp); > >> > 724 return (IPPROTO_DONE); > >> > 725 > >> > 726 badunlocked: > >> > (kgdb) up > >> > #11 0xffffffff8075f645 in ip_input (m=0x0) > >> > at /opt/src/svn-current/sys/netinet/ip_input.c:825 > >> > 825 (*inetsw[ip_protox[ip->ip_p]].pr_input)(&m, &hlen, ip->ip_p > >> ); > >> > (kgdb) l > >> > 820 /* > >> > 821 * Switch out to protocol's input routine. > >> > 822 */ > >> > 823 IPSTAT_INC(ips_delivered); > >> > 824 > >> > 825 (*inetsw[ip_protox[ip->ip_p]].pr_input)(&m, &hlen, ip->ip_p > >> ); > >> > 826 return; > >> > 827 bad: > >> > 828 m_freem(m); > >> > 829 } > >> > (kgdb) > >> > > >> > > >> > In both cases rtsold was starting. > >> > > >> > > >> > > >> > -- > >> > Cheers, > >> > Cy Schubert > >> > FreeBSD UNIX: Web: http://www.FreeBSD.org > >> > > >> > The need of the many outweighs the greed of the few. > >> > > >> > > >> > _______________________________________________ > >> > 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 Fri Jun 22 05:47:51 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E972A100F293 for ; Fri, 22 Jun 2018 05:47:50 +0000 (UTC) (envelope-from cy.schubert@cschubert.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 5362B7F9ED for ; Fri, 22 Jun 2018 05:47:50 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: by mailman.ysv.freebsd.org (Postfix) id 174FA100F292; Fri, 22 Jun 2018 05:47:50 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C2506100F291 for ; Fri, 22 Jun 2018 05:47:49 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 317527F9EB; Fri, 22 Jun 2018 05:47:48 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id WEv4fJCU2uYopWEv5fIOgH; Thu, 21 Jun 2018 23:47:41 -0600 X-Authority-Analysis: v=2.3 cv=GopsBH9C c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=7mUfYlMuFuIA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=xfDLHkLGAAAA:8 a=mDV3o1hIAAAA:8 a=NsZnd3Fs1-FfdE6APjYA:9 a=MkdGdE1-0cOgw9_Y:21 a=boXdrTfspIcja-cv:21 a=_HIXqGOnmPtoUM1Y:21 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=IfaqVvZgccqrtc8gcwf2:22 a=_FVE-zBwftR9WsbkzFJk:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 593CD191; Thu, 21 Jun 2018 22:47:38 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id w5M5lcQx002890; Thu, 21 Jun 2018 22:47:38 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id w5M5lcU1002887; Thu, 21 Jun 2018 22:47:38 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201806220547.w5M5lcU1002887@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Peter Holm cc: Matthew Macy , Cy Schubert , current@freebsd.org Subject: Re: Page fault in udp_usrreq.c:823 In-Reply-To: Message from Peter Holm of "Fri, 22 Jun 2018 07:27:55 +0200." <20180622052755.GA49166@x2.osted.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Jun 2018 22:47:38 -0700 X-CMAE-Envelope: MS4wfNWN+ZV/SMxtwvjtstdhXvIWjgLOD01u0BW4LDfvDJTmeGVP7z7hazJSTPk8iV1KNvdFiIFl+fDPS+KA7vxbUmEFxXG4SZdLLQPJgxhD1W6Y4SuYE9HQ OYDlfi9ydDWq0V0Iak7aF5zP8mUKCDu+PWVV5l2tiD9atzOL95LzQ2qYexsyDEne8rOVV3zqtqeaN6CAX93Pwpr46xzZShOhTh/vaxglzsDmP1Dtn82hGu24 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 22 Jun 2018 05:47:51 -0000 In message <20180622052755.GA49166@x2.osted.lan>, Peter Holm writes: > On Thu, Jun 21, 2018 at 06:42:41PM -0700, Matthew Macy wrote: > > I made changes this morning / early afternoon. > > -M > > > > With r335501 I no longer see any of the issues I reported. Thank > you for the fix! > > - Peter I didn't see any panic after installkernel either. However I only experienced two panics over a two day period, once early on the 19th and one early today, both times while rtsold was starting. This is on a laptop that was (and is) frequently booted over the last two days. I'll report if there are any issues. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. > > > On Thu, Jun 21, 2018 at 6:41 PM, Cy Schubert wr > ote: > > > Like as of now? > > > > > > The last panic occurred this morning after a build last night. > > > > > > > > > -- > > > Cheers, > > > Cy Schubert > > > FreeBSD UNIX: Web: http://www.FreeBSD.org > > > > > > The need of the many outweighs the greed of the few. > > > > > > > > > In message > > il.com> > > > , Matthew Macy writes: > > >> Try updating. It should be fixed. > > >> > > >> On Thu, Jun 21, 2018 at 6:14 PM, Cy Schubert > wrot > > >> e: > > >> > In message <20180620090957.GA130@x2.osted.lan>, Peter Holm writes: > > >> >> 20180620 10:32:47 all (1/1): udp.sh > > >> >> Kernel page fault with the following non-sleepable locks held: > > >> >> shared rw udpinp (udpinp) r = 0 (0xfffff80bbc808d78) locked @ netinet > /in_p > > >> cb. > > >> >> c:2398 > > >> >> stack backtrace: > > >> >> #0 0xffffffff80c00733 at witness_debugger+0x73 > > >> >> #1 0xffffffff80c01b11 at witness_warn+0x461 > > >> >> #2 0xffffffff81075763 at trap_pfault+0x53 > > >> >> #3 0xffffffff81074d7a at trap+0x2ba > > >> >> #4 0xffffffff8105076c at calltrap+0x8 > > >> >> #5 0xffffffff80dd21b0 at udp_ctlinput+0x50 > > >> >> #6 0xffffffff80d3081d at icmp_input+0x96d > > >> >> #7 0xffffffff80d316d7 at ip_input+0x3f7 > > >> >> #8 0xffffffff80cc0a92 at netisr_dispatch_src+0xa2 > > >> >> #9 0xffffffff80ca3ebe at ether_demux+0x16e > > >> >> #10 0xffffffff80ca5377 at ether_nh_input+0x427 > > >> >> #11 0xffffffff80cc0a92 at netisr_dispatch_src+0xa2 > > >> >> #12 0xffffffff80ca437f at ether_input+0x8f > > >> >> #13 0xffffffff80cbc500 at iflib_rxeof+0xc90 > > >> >> #14 0xffffffff80cb6b6f at _task_fn_rx+0x7f > > >> >> #15 0xffffffff80bdd209 at gtaskqueue_run_locked+0x139 > > >> >> #16 0xffffffff80bdcf88 at gtaskqueue_thread_loop+0x88 > > >> >> #17 0xffffffff80b54514 at fork_exit+0x84 > > >> >> > > >> >> > > >> >> Fatal trap 12: page fault while in kernel mode > > >> >> cpuid = 10; apic id = 0a > > >> >> fault virtual address = 0x8 > > >> >> fault code = supervisor read data, page not present > > >> >> instruction pointer = 0x20:0xffffffff80dd2423 > > >> >> stack pointer = 0x0:0xfffffe00004a5500 > > >> >> frame pointer = 0x0:0xfffffe00004a55a0 > > >> >> code segment = base 0x0, limit 0xfffff, type 0x1b > > >> >> = DPL 0, pres 1, long 1, def32 0, gran 1 > > >> >> processor eflags = interrupt enabled, resume, IOPL = 0 > > >> >> current process = 0 (if_io_tqg_10) > > >> >> [ thread pid 0 tid 100069 ] > > >> >> Stopped at udp_common_ctlinput+0x263: cmpq $0,0x8(%rax) > > >> >> db> > > >> >> > > >> >> Details @ https://people.freebsd.org/~pho/stress/log/udp_usrreq.txt > > >> >> > > >> >> -- > > >> >> Peter > > >> >> _______________________________________________ > > >> >> freebsd-current@freebsd.org mailing list > > >> >> https://lists.freebsd.org/mailman/listinfo/freebsd-current > > >> >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd > .org" > > >> >> > > >> > > > >> > This is surprisingly similar to my panic. Twice since June 19. > > >> > > > >> > slippy# kgdb /boot/kernel/kernel vmcore.3 > > >> > GNU gdb (GDB) 8.1 [GDB v8.1 for FreeBSD] > > >> > Copyright (C) 2018 Free Software Foundation, Inc. > > >> > License GPLv3+: GNU GPL version 3 or later l. > > >> > html> > > >> > This is free software: you are free to change and redistribute it. > > >> > There is NO WARRANTY, to the extent permitted by law. Type "show > > >> > copying" > > >> > and "show warranty" for details. > > >> > This GDB was configured as "x86_64-portbld-freebsd12.0". > > >> > Type "show configuration" for configuration details. > > >> > For bug reporting instructions, please see: > > >> > . > > >> > Find the GDB manual and other documentation resources online at: > > >> > . > > >> > For help, type "help". > > >> > Type "apropos word" to search for commands related to "word"... > > >> > Reading symbols from /boot/kernel/kernel...Reading symbols from > > >> > /usr/lib/debug//boot/kernel/kernel.debug...done. > > >> > done. > > >> > > > >> > Unread portion of the kernel message buffer: > > >> > Copyright (c) 1992-2018 The FreeBSD Project. > > >> > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 19 > 94 > > >> > The Regents of the University of California. All rights reserv > ed. > > >> > FreeBSD is a registered trademark of The FreeBSD Foundation. > > >> > FreeBSD 12.0-CURRENT #355 r335477M: Thu Jun 21 05:26:35 PDT 2018 > > >> > root@slippy:/export/obj/opt/src/svn-current/amd64.amd64/sys/BREAK > > >> > amd64 > > >> > FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on > > >> > LLVM 6.0.0) > > >> > VT(vga): text 80x25 > > >> > module_register: cannot register mmc/mmcsd from kernel; already loaded > > >> > from mmcsd.ko > > >> > Module mmc/mmcsd failed to register: 17 > > >> > CPU: Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz (2294.83-MHz K8-class CP > U) > > >> > Origin="GenuineIntel" Id=0x206a7 Family=0x6 Model=0x2a Stepping= > 7 > > >> > Features=0xbfebfbff ,P > > >> > GE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE > > > > >> > Features2=0x1dbae3bf SE > > >> > 3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,XSAVE,OSXSAVE > ,A > > >> > VX> > > >> > AMD Features=0x28100800 > > >> > AMD Features2=0x1 > > >> > XSAVE Features=0x1 > > >> > VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID > > >> > TSC: P-state invariant, performance statistics > > >> > real memory = 8589934592 (8192 MB) > > >> > avail memory = 8080965632 (7706 MB) > > >> > ACPI APIC Table: > > >> > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > > >> > FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads > > >> > random: unblocking device. > > >> > ioapic0 irqs 0-23 on motherboard > > >> > random: entropy device external interface > > >> > module_register_init: MOD_LOAD (vesa, 0xffffffff8097b700, 0) error 19 > > >> > kbd1 at kbdmux0 > > >> > nexus0 > > >> > vtvga0: on motherboard > > >> > cryptosoft0: on motherboard > > >> > acpi0: on motherboard > > >> > acpi0: Power Button (fixed) > > >> > cpu0: on acpi0 > > >> > hpet0: iomem 0xfed00000-0xfed003ff on acp > i0 > > >> > Timecounter "HPET" frequency 14318180 Hz quality 950 > > >> > Event timer "HPET" frequency 14318180 Hz quality 550 > > >> > Event timer "HPET1" frequency 14318180 Hz quality 440 > > >> > Event timer "HPET2" frequency 14318180 Hz quality 440 > > >> > Event timer "HPET3" frequency 14318180 Hz quality 440 > > >> > Event timer "HPET4" frequency 14318180 Hz quality 440 > > >> > atrtc0: port 0x70-0x77 irq 8 on acpi0 > > >> > atrtc0: Warning: Couldn't map I/O. > > >> > atrtc0: registered as a time-of-day clock, resolution 1.000000s > > >> > attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 > > >> > Timecounter "i8254" frequency 1193182 Hz quality 0 > > >> > Event timer "i8254" frequency 1193182 Hz quality 100 > > >> > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > > >> > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > > >> > acpi_ec0: port 0x62,0x66 on acpi0 > > >> > pcib0: port 0xcf8-0xcff on acpi0 > > >> > pci0: on pcib0 > > >> > vgapci0: port 0x2000-0x203f mem > > >> > 0xf0000000-0xf03fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pc > i0 > > >> > vgapci0: Boot video device > > >> > pci0: at device 22.0 (no driver attached) > > >> > ehci0: mem > > >> > 0xf060a000-0xf060a3ff irq 16 at device 26.0 on pci0 > > >> > usbus0: EHCI version 1.0 > > >> > usbus0 on ehci0 > > >> > hdac0: mem 0xf0600000-0xf0603fff > > >> > irq 22 at device 27.0 on pci0 > > >> > pcib1: irq 16 at device 28.0 on pci0 > > >> > pci1: on pcib1 > > >> > pcib2: irq 17 at device 28.1 on pci0 > > >> > pci2: on pcib2 > > >> > iwn0: mem 0xf0500000-0xf0501fff irq 1 > 7 > > >> > at device 0.0 on pci2 > > >> > pcib3: irq 19 at device 28.3 on pci0 > > >> > pci3: on pcib3 > > >> > bge0: mem > > >> > 0xf0400000-0xf040ffff,0xf0410000-0xf041ffff irq 19 at device 0.0 on pc > i3 > > >> > bge0: CHIP ID 0x57785100; ASIC REV 0x57785; CHIP REV 0x577851; PCI-E > > >> > miibus0: on bge0 > > >> > brgphy0: PHY 1 on miibus0 > > >> > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > > >> > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > > >> > <6>bge0: Using defaults for TSO: 65518/35/2048 > > >> > <6>bge0: Ethernet address: 20:6a:8a:72:03:17 > > >> > pci3: at device 0.1 (no driver > > >> > attached) > > >> > ehci1: mem > > >> > 0xf0609000-0xf06093ff irq 23 at device 29.0 on pci0 > > >> > usbus1: EHCI version 1.0 > > >> > usbus1 on ehci1 > > >> > isab0: at device 31.0 on pci0 > > >> > isa0: on isab0 > > >> > ahci0: port > > >> > 0x2088-0x208f,0x2094-0x2097,0x2080-0x2087,0x2090-0x2093,0x2060-0x207f > > >> > mem 0xf0608000-0xf06087ff irq 19 at device 31.2 on pci0 > > >> > ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported > > >> > ahcich0: at channel 0 on ahci0 > > >> > ahcich1: at channel 1 on ahci0 > > >> > ahcich5: at channel 5 on ahci0 > > >> > ahciem0: on ahci0 > > >> > ichsmb0: port 0xefa0-0xefbf mem > > >> > 0xf0604000-0xf06040ff irq 18 at device 31.3 on pci0 > > >> > smbus0: on ichsmb0 > > >> > smb0: on smbus0 > > >> > acpi_lid0: on acpi0 > > >> > acpi_button0: on acpi0 > > >> > acpi_tz0: on acpi0 > > >> > acpi_tz1: on acpi0 > > >> > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > > >> > atkbd0: irq 1 on atkbdc0 > > >> > kbd0 at atkbd0 > > >> > atkbd0: [GIANT-LOCKED] > > >> > psm0: irq 12 on atkbdc0 > > >> > psm0: [GIANT-LOCKED] > > >> > psm0: model Synaptics Touchpad, device ID 0 > > >> > acpi_acad0: on acpi0 > > >> > battery0: on acpi0 > > >> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff pnpi > d > > >> > PNP0900 on isa0 > > >> > ata0: at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 > > >> > ata1: at port 0x170-0x177,0x376 irq 15 on isa0 > > >> > acpi_perf0: on cpu0 > > >> > coretemp0: on cpu0 > > >> > ZFS filesystem version: 5 > > >> > ZFS storage pool version: features support (5000) > > >> > Timecounters tick every 10.000 msec > > >> > IP Filter: v5.1.2 initialized. Default = pass all, Logging = enabled > > >> > hdacc0: at cad 0 on hdac0 > > >> > hdaa0: at nid 1 on hdacc0 > > >> > pcm0: at nid 20,33 and 27 on hdaa > 0 > > >> > pcm1: at nid 24 on hdaa0 > > >> > hdacc1: at cad 3 on hdac0 > > >> > hdaa1: at nid 1 on hdacc1 > > >> > pcm2: at nid 5 on hdaa1 > > >> > usbus0: 480Mbps High Speed USB v2.0 > > >> > usbus1: 480Mbps High Speed USB v2.0 > > >> > ugen1.1: at usbus1 > > >> > uhub0: on usbu > s1 > > >> > ugen0.1: at usbus0 > > >> > uhub1: on usbu > s0 > > >> > ses0 at ahciem0 bus 0 scbus3 target 0 lun 0 > > >> > ses0: SEMB S-E-S 2.00 device > > >> > ses0: SEMB SES Device > > >> > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > > >> > ada0: ATA8-ACS SATA 3.x device > > >> > ada0: Serial Number JR1000D33969RE > > >> > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > > >> > ada0: Command Queueing enabled > > >> > ada0: 953869MB (1953525168 512 byte sectors) > > >> > cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 > > >> > cd0: Removable CD-ROM SCSI device > > >> > cd0: Serial Number SBB5103801 > > >> > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO > > >> > 8192bytes) > > >> > cd0: Attempt to query device size failed: NOT READY, Medium not presen > t > > >> > - tray closed > > >> > Launching APs: 1 3 2 > > >> > Trying to mount root from ufs:/dev/ufs/Sroot [rw]... > > >> > Timecounter "TSC-low" frequency 1147416846 Hz quality 1000 > > >> > <118>Setting hostuuid: 34f5ed40-8938-11da-b265-efe316da850d. > > >> > <118>Setting hostid: 0x7f5a03b9. > > >> > uhub0: 2 ports with 2 removable, self powered > > >> > uhub1: 2 ports with 2 removable, self powered > > >> > ugen0.2: at usbus0 > > >> > uhub2 on uhub1 > > >> > uhub2: > > > >> > on usbus0 > > >> > ugen1.2: at usbus1 > > >> > uhub3 on uhub0 > > >> > uhub3: > > > >> > on usbus1 > > >> > uhub2: 6 ports with 6 removable, self powered > > >> > uhub3: 6 ports with 6 removable, self powered > > >> > ugen0.3: at usbus0 > > >> > ukbd0 on uhub2 > > >> > ukbd0: on > > >> > usbus0 > > >> > kbd2 at ukbd0 > > >> > ums0 on uhub2 > > >> > ums0: on > > >> > usbus0 > > >> > ums0: 16 buttons and [XYZT] coordinates ID=2 > > >> > ugen1.3: at usbus1 > > >> > uhub4 on uhub3 > > >> > uhub4: o > n > > >> > usbus1 > > >> > uhub4: 4 ports with 4 removable, self powered > > >> > ugen0.4: at usbus0 > > >> > ugen1.4: at usbus1 > > >> > uhub5 on uhub4 > > >> > uhub5: o > n > > >> > usbus1 > > >> > uhub5: 4 ports with 4 removable, self powered > > >> > ugen1.5: at usbus1 > > >> > uhub6 on uhub5 > > >> > uhub6: on > > >> > usbus1 > > >> > uhub6: 4 ports with 4 removable, self powered > > >> > ugen1.6: at usbus1 > > >> > ukbd1 on uhub6 > > >> > ukbd1: on > > >> > usbus1 > > >> > kbd3 at ukbd1 > > >> > ums1 on uhub6 > > >> > ums1: on > > >> > usbus1 > > >> > ums1: 16 buttons and [XYZT] coordinates ID=2 > > >> > ugen1.7: at usbus1 > > >> > ukbd2 on uhub6 > > >> > ukbd2: on > > >> > usbus1 > > >> > kbd4 at ukbd2 > > >> > ugen1.8: at usbus1 > > >> > umass0 on uhub5 > > >> > umass0: o > n > > >> > usbus1 > > >> > umass0: SCSI over Bulk-Only; quirks = 0x408c > > >> > umass0:6:0: Attached to scbus6 > > >> > da0 at umass-sim0 bus 0 scbus6 target 0 lun 0 > > >> > da0: Fixed Direct Access SCSI device > > >> > da0: 40.000MB/s transfers > > >> > da0: 76319MB (156301488 512 byte sectors) > > >> > da0: quirks=0x2 > > >> > <118>Starting file system checks: > > >> > <118>/dev/ufs/Sroot: FILE SYSTEM CLEAN; SKIPPING CHECKS > > >> > <118>/dev/ufs/Sroot: clean, 413829 free (909 frags, 51615 blocks, 0.2% > > >> > fragmentation) > > >> > <118>/dev/ufs/Susr: FILE SYSTEM CLEAN; SKIPPING CHECKS > > >> > <118>/dev/ufs/Susr: clean, 459287 free (4847 frags, 56805 blocks, 0.6% > > >> > fragmentation) > > >> > <118>/dev/ufs/Svtmp: FILE SYSTEM CLEAN; SKIPPING CHECKS > > >> > <118>/dev/ufs/Svtmp: clean, 503642 free (50 frags, 62949 blocks, 0.0% > > >> > fragmentation) > > >> > <118>/dev/ufs/SCusr: FILE SYSTEM CLEAN; SKIPPING CHECKS > > >> > <118>/dev/ufs/Svar: FILE SYSTEM CLEAN; SKIPPING CHECKS > > >> > <118>/dev/ufs/SSusr: FILE SYSTEM CLEAN; SKIPPING CHECKS > > >> > <118>/dev/ufs/SCusr: clean, 469826 free (4578 frags, 58156 blocks, 0.6 > % > > >> > fragmentation) > > >> > <118>/dev/ufs/Svar: clean, 453726 free (574 frags, 56644 blocks, 0.1% > > >> > fragmentation) > > >> > <118>/dev/ufs/SCroot: FILE SYSTEM CLEAN; SKIPPING CHECKS > > >> > <118>/dev/ufs/SSusr: clean, 569245 free (3653 frags, 70699 blocks, 0.5 > % > > >> > fragmentation) > > >> > <118>/dev/ufs/SCroot: clean, 422625 free (617 frags, 52751 blocks, 0.1 > % > > >> > fragmentation) > > >> > <118>/dev/ufs/SCvar: FILE SYSTEM CLEAN; SKIPPING CHECKS > > >> > <118>/dev/ufs/SSvar: FILE SYSTEM CLEAN; SKIPPING CHECKS > > >> > <118>/dev/ufs/SCvar: clean, 400011 free (99 frags, 49989 blocks, 0.0% > > >> > fragmentation) > > >> > <118>/dev/ufs/SSvar: clean, 457058 free (138 frags, 57115 blocks, 0.0% > > >> > fragmentation) > > >> > <118>/dev/ufs/SSroot: FILE SYSTEM CLEAN; SKIPPING CHECKS > > >> > <118>/dev/ufs/SSroot: clean, 412995 free (219 frags, 51597 blocks, 0.0 > % > > >> > fragmentation) > > >> > <118>/dev/msdosfs/SHARED: FILESYSTEM CLEAN; SKIPPING CHECKS > > >> > <118>/dev/zvol/tank/VMs/current/i386/disk0s1a: FILE SYSTEM CLEAN; > > >> > SKIPPING CHECKS > > >> > <118>/dev/zvol/tank/VMs/current/i386/disk0s1a: clean, 254465 free (337 > > >> > frags, 31766 blocks, 0.1% fragmentation) > > >> > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1a: FILE SYSTEM CLEAN; > > >> > SKIPPING CHECKS > > >> > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1a: FILE SYSTEM CLEAN; > > >> > SKIPPING CHECKS > > >> > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1a: clean, 335508 free > > >> > (1348 frags, 41770 blocks, 0.1% fragmentation) > > >> > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1a: clean, 566833 free > > >> > (2297 frags, 70567 blocks, 0.2% fragmentation) > > >> > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1a: FILE SYSTEM CLEAN; > > >> > SKIPPING CHECKS > > >> > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1a: FILE SYSTEM CLEAN; > > >> > SKIPPING CHECKS > > >> > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1a: clean, 510529 free > > >> > (1185 frags, 63668 blocks, 0.1% fragmentation) > > >> > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1a: clean, 354656 free (33 > 6 > > >> > frags, 44290 blocks, 0.1% fragmentation) > > >> > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1a: FILE SYSTEM CLEAN; > > >> > SKIPPING CHECKS > > >> > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1a: clean, 633994 free > > >> > (2106 frags, 78986 blocks, 0.2% fragmentation) > > >> > <118>/dev/zvol/tank/VMs/current/amd64/disk3p1: FILE SYSTEM CLEAN; > > >> > SKIPPING CHECKS > > >> > <118>/dev/zvol/tank/VMs/current/amd64/disk3p1: clean, 2535564 free (56 > 4 > > >> > frags, 316875 blocks, 0.0% fragmentation) > > >> > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1d: FILE SYSTEM CLEAN; > > >> > SKIPPING CHECKS > > >> > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1d: clean, 897924 free > > >> > (188 frags, 112217 blocks, 0.0% fragmentation) > > >> > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1d: FILE SYSTEM CLEAN; > > >> > SKIPPING CHECKS > > >> > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1d: clean, 897896 free > > >> > (152 frags, 112218 blocks, 0.0% fragmentation) > > >> > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1d: FILE SYSTEM CLEAN; > > >> > SKIPPING CHECKS > > >> > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1d: FILE SYSTEM CLEAN; > > >> > SKIPPING CHECKS > > >> > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1d: clean, 889422 free (21 > 4 > > >> > frags, 111151 blocks, 0.0% fragmentation) > > >> > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1d: clean, 889419 free (21 > 9 > > >> > frags, 111150 blocks, 0.0% fragmentation) > > >> > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1d: FILE SYSTEM CLEAN; > > >> > SKIPPING CHECKS > > >> > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1d: clean, 408410 free (90 > > >> > frags, 51040 blocks, 0.0% fragmentation) > > >> > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1e: FILE SYSTEM CLEAN; > > >> > SKIPPING CHECKS > > >> > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1e: FILE SYSTEM CLEAN; > > >> > SKIPPING CHECKS > > >> > <118>/dev/zvol/tank/VMs/stable10/amd64/disk0s1e: clean, 1230068 free > > >> > (7300 frags, 152846 blocks, 0.5% fragmentation) > > >> > <118>/dev/zvol/tank/VMs/stable11/amd64/disk0s1e: clean, 726361 free > > >> > (6297 frags, 90008 blocks, 0.4% fragmentation) > > >> > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1e: FILE SYSTEM CLEAN; > > >> > SKIPPING CHECKS > > >> > <118>/dev/zvol/tank/VMs/stable10/i386/disk0s1e: clean, 1299097 free > > >> > (6385 frags, 161589 blocks, 0.4% fragmentation) > > >> > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1e: FILE SYSTEM CLEAN; > > >> > SKIPPING CHECKS > > >> > <118>/dev/zvol/tank/VMs/current/amd64/disk0s1e: clean, 822303 free > > >> > (1047 frags, 102657 blocks, 0.1% fragmentation) > > >> > <118>/dev/zvol/tank/VMs/current/i386/disk0s1d: FILE SYSTEM CLEAN; > > >> > SKIPPING CHECKS > > >> > <118>/dev/zvol/tank/VMs/current/i386/disk0s1d: clean, 399855 free (15 > > >> > frags, 49980 blocks, 0.0% fragmentation) > > >> > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1e: FILE SYSTEM CLEAN; > > >> > SKIPPING CHECKS > > >> > <118>/dev/zvol/tank/VMs/stable11/i386/disk0s1e: clean, 937324 free > > >> > (7524 frags, 116225 blocks, 0.5% fragmentation) > > >> > <118>/dev/zvol/tank/VMs/current/i386/disk0s1e: FILE SYSTEM CLEAN; > > >> > SKIPPING CHECKS > > >> > <118>/dev/zvol/tank/VMs/current/i386/disk0s1e: clean, 1077125 free (84 > 5 > > >> > frags, 134535 blocks, 0.1% fragmentation) > > >> > <118>Mounting local filesystems:. > > >> > <118>ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib > > >> > /usr/local/lib/compat/pkg /usr/local/krb5/lib /usr/local/kde4/lib > > >> > /usr/local/lib/compat /usr/local/lib/compat/pkg /usr/local/lib/dovecot > > >> > /usr/local/lib/e2fsprogs /usr/local/lib/ffmpeg0 /usr/local/lib/freerad > iu > > >> > s-3.0.15 /usr/local/lib/gcc48 /usr/local/lib/gcc5 /usr/local/lib/gcc6 > > >> > /usr/local/lib/gcc7 /usr/local/lib/gcc8 /usr/local/lib/gcc9 > > >> > /usr/local/lib/gegl-0.2 /usr/local/lib/graphviz /usr/local/lib/httrack > > >> > /usr/local/lib/itcl3.4 /usr/local/lib/jitsi/lib/native > > >> > /usr/local/lib/mysql /usr/local/lib/mysql/plugin /usr/local/lib/nss > > >> > /usr/local/lib/opencollada /usr/local/lib/perl5/5.24/mach/CORE > > >> > /usr/local/lib/perl5/5.26/mach/CORE /usr/local/lib/perl5/5.28/mach/COR > E > > >> > /usr/local/lib/pgtcl /usr/local/lib/pidgin /usr/local/lib/pth > > >> > /usr/local/lib/qt4 /usr/local/lib/qt5 /usr/local/lib/samba4 > > >> > /usr/local/lib/xrdp /usr/local/libexec/openldap /usr/local/llvm-devel/ > li > > >> > b /usr/local/llvm40/lib /usr/local/llvm50/lib /usr/local/llvm60/lib > > >> > /usr/local/share/chromium > > >> > <118>32-bit compatibility ldconfig path: /usr/lib32 > > >> > /alt/i386/root/usr/local/lib /usr/local/lib32/compat > > >> > <118>Setting hostname: slippy. > > >> > <118>Additional TCP/IP options: rfc1323 extensions=NO. > > >> > <118>Setting up harvesting: [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ > ET > > >> > HER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED > > >> > <118>Feeding entropy: . > > >> > <118>Loading IP Pools. > > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > > >> > present in pool > > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > > >> > present in pool > > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > > >> > present in pool > > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > > >> > present in pool > > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > > >> > present in pool > > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > > >> > present in pool > > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > > >> > present in pool > > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > > >> > present in pool > > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > > >> > present in pool > > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > > >> > present in pool > > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > > >> > present in pool > > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > > >> > present in pool > > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > > >> > present in pool > > >> > <118>70018:add pool node(252.0.0.1/255.255.255.255: node entry already > > >> > present in pool > > >> > <118>Enabling ipfilter. > > >> > <118>32:1:ioctl(add/insert rule): rule already exists > > >> > <118>Installing NAT rules. > > >> > <118>0 entries flushed from NAT table > > >> > <118>0 entries flushed from NAT list > > >> > <6>wlan0: Ethernet address: 20:6a:8a:72:03:17 > > >> > <118>Created wlan(4) interfaces: wlan0. > > >> > <118>Created clone interfaces: lagg0. > > >> > <6>lo0: link state changed to UP > > >> > <6>bge0: link state changed to DOWN > > >> > iwn0: iwn_read_firmware: ucode rev=0x12a80601 > > >> > <118>Starting wpa_supplicant. > > >> > <6>lagg0: link state changed to DOWN > > >> > iwn0: iwn_read_firmware: ucode rev=0x12a80601 > > >> > <118>Starting dhclient. > > >> > <118>lagg0: no link ... > > >> > <6>wlan0: link state changed to UP > > >> > <6>lagg0: link state changed to UP > > >> > <118> got link > > >> > <6>bge0: link state changed to UP > > >> > <118>Starting Network: lo0 bge0 wlan0 lagg0. > > >> > <118>lo0: flags=8049 metric 0 mtu 16384 > > >> > <118> options=680003 > > > >> > <118> inet 127.0.0.1 netmask 0xff000000 > > >> > <118> inet6 ::1 prefixlen 128 > > >> > <118> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > > >> > <118> nd6 options=21 > > >> > <118> groups: lo > > >> > <118>bge0: flags=8843 metric 0 > > >> > mtu 1500 > > >> > <118> options=80080 > > >> > <118> ether 20:6a:8a:72:03:17 > > >> > <118> nd6 options=29 > > >> > <118> media: Ethernet autoselect (1000baseT ) > > >> > <118> status: active > > >> > <118>wlan0: flags=8843 metric > 0 > > >> > mtu 1500 > > >> > <118> ether 20:6a:8a:72:03:17 > > >> > <118> nd6 options=29 > > >> > <118> media: IEEE 802.11 Wireless Ethernet MCS mode 11ng > > >> > <118> status: associated > > >> > <118> ssid Walden_Pond channel 1 (2412 MHz 11g ht/20) bssid > > >> > 4c:60:de:31:3c:17 > > >> > <118> regdomain FCC country US authmode WPA2/802.11i privacy ON > > >> > <118> deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 120 scanvali > d > > >> > 16959 > > >> > <118> protmode CTS ampdulimit 64k ampdudensity 8 -amsdutx amsdurx > > >> > shortgi > > >> > <118> -stbc -ldpc wme roaming MANUAL > > >> > <118> groups: wlan > > >> > <118>lagg0: flags=8843 metric > 0 > > >> > mtu 1500 > > >> > <118> ether 20:6a:8a:72:03:17 > > >> > <118> inet6 fe80::226a:8aff:fe72:317%lagg0 prefixlen 64 scopeid 0x4 > > >> > <118> inet 0.0.0.0 netmask 0x0 broadcast 255.255.255.255 > > >> > <118> nd6 options=23 > > >> > <118> media: Ethernet autoselect > > >> > <118> status: active > > >> > <118> groups: lagg > > >> > <118> laggproto failover lagghash l2,l3,l4 > > >> > <118> laggport: bge0 flags=5 > > >> > <118> laggport: wlan0 flags=0<> > > >> > <118>filter sync'd > > >> > <118>Starting devd. > > >> > <118>Starting ums0 moused. > > >> > <118>Autoloading module: uhid.ko > > >> > uhid0 on uhub2 > > >> > uhid0: on > > >> > usbus0 > > >> > uhid1 on uhub6 > > >> > uhid1: on > > >> > usbus1 > > >> > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > > >> > use 'onestart' instead of 'start'. > > >> > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > > >> > use 'onestart' instead of 'start'. > > >> > <118>Cannot 'start' webcamd. Set webcamd_enable to YES in /etc/rc.conf > > >> > or use 'onestart' instead of 'start'. > > >> > uhid2 on uhub6 > > >> > uhid2: on > > >> > usbus1 > > >> > device_attach: uhid2 attach returned 12 > > >> > <118>Cannot 'start' webcamd. Set webcamd_enable to YES in /etc/rc.conf > > >> > or use 'onestart' instead of 'start'. > > >> > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > > >> > use 'onestart' instead of 'start'. > > >> > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > > >> > use 'onestart' instead of 'start'. > > >> > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > > >> > use 'onestart' instead of 'start'. > > >> > <118>Starting ums1 moused. > > >> > <118>Autoloading module: uhid.ko > > >> > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > > >> > use 'onestart' instead of 'start'. > > >> > <118>Autoloading module: uhid.ko > > >> > <118>Cannot 'start' uhidd. Set uhidd_enable to YES in /etc/rc.conf or > > >> > use 'onestart' instead of 'start'. > > >> > <118>local: Not in a function > > >> > <118>local: Not in a function > > >> > <118>dhclient not running? (check /var/run/dhclient.bge0.pid). > > >> > <118>Stopping dhclient. > > >> > <118>Waiting for PIDS: 471. > > >> > <118>Starting dhclient. > > >> > <118>add host 127.0.0.1: gateway lo0 fib 0: route already in table > > >> > <118>Additional inet routing options: ignore ICMP redirect=YES log ICM > P > > >> > redirect=YES. > > >> > <118>add host ::1: gateway lo0 fib 0: route already in table > > >> > <118>add net fe80::: gateway ::1 > > >> > <118>add net ff02::: gateway ::1 > > >> > <118>add net ::ffff:0.0.0.0: gateway ::1 > > >> > <118>add net ::0.0.0.0: gateway ::1 > > >> > <118>Starting rtsold. > > >> > > > >> > > > >> > Fatal trap 12: page fault while in kernel mode > > >> > cpuid = 3; apic id = 03 > > >> > fault virtual address = 0x0 > > >> > fault code = supervisor read data, page not present > > >> > instruction pointer = 0x20:0xffffffff80806966 > > >> > stack pointer = 0x28:0xfffffe00004667d0 > > >> > frame pointer = 0x28:0xfffffe0000466840 > > >> > code segment = base 0x0, limit 0xfffff, type 0x1b > > >> > = DPL 0, pres 1, long 1, def32 0, gran 1 > > >> > processor eflags = interrupt enabled, resume, IOPL = 0 > > >> > current process = 12 (swi1: netisr 0) > > >> > trap number = 12 > > >> > panic: page fault > > >> > cpuid = 3 > > >> > time = 1529587144 > > >> > KDB: stack backtrace: > > >> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > >> > 0xfffffe0000466480 > > >> > vpanic() at vpanic+0x1a3/frame 0xfffffe00004664e0 > > >> > panic() at panic+0x43/frame 0xfffffe0000466540 > > >> > trap_fatal() at trap_fatal+0x35f/frame 0xfffffe0000466590 > > >> > trap_pfault() at trap_pfault+0x49/frame 0xfffffe00004665f0 > > >> > trap() at trap+0x29e/frame 0xfffffe0000466700 > > >> > calltrap() at calltrap+0x8/frame 0xfffffe0000466700 > > >> > --- trap 0xc, rip = 0xffffffff80806966, rsp = 0xfffffe00004667d0, rbp > = > > >> > 0xfffffe0000466840 --- > > >> > udp_append() at udp_append+0x26/frame 0xfffffe0000466840 > > >> > udp_input() at udp_input+0x574/frame 0xfffffe0000466910 > > >> > ip_input() at ip_input+0x145/frame 0xfffffe0000466970 > > >> > swi_net() at swi_net+0x17b/frame 0xfffffe00004669e0 > > >> > intr_event_execute_handlers() at intr_event_execute_handlers+0xe9/fram > e > > >> > 0xfffffe0000466a20 > > >> > ithread_loop() at ithread_loop+0xe7/frame 0xfffffe0000466a70 > > >> > fork_exit() at fork_exit+0x83/frame 0xfffffe0000466ab0 > > >> > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0000466ab0 > > >> > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > > >> > Uptime: 51s > > >> > Dumping 697 out of 7975 MB:..3%..12%..21%..33%..42%..51%..62%..72%..81 > %. > > >> > .92% > > >> > > > >> > __curthread () at ./machine/pcpu.h:231 > > >> > 231 __asm("movq %%gs:%1,%0" : "=r" (td) > > >> > (kgdb) bt > > >> > #0 __curthread () at ./machine/pcpu.h:231 > > >> > #1 doadump (textdump=1) at /opt/src/svn-current/sys/kern/kern_shutdow > n. > > >> > c:366 > > >> > #2 0xffffffff8061b330 in kern_reboot (howto=260) > > >> > at /opt/src/svn-current/sys/kern/kern_shutdown.c:446 > > >> > #3 0xffffffff8061b7c3 in vpanic (fmt=, > > >> > ap=0xfffffe0000466520) > > >> > at /opt/src/svn-current/sys/kern/kern_shutdown.c:863 > > >> > #4 0xffffffff8061b5b3 in panic (fmt=) > > >> > at /opt/src/svn-current/sys/kern/kern_shutdown.c:790 > > >> > #5 0xffffffff8095e76f in trap_fatal (frame=0xfffffe0000466710, eva=0) > > >> > at /opt/src/svn-current/sys/amd64/amd64/trap.c:892 > > >> > #6 0xffffffff8095e7c9 in trap_pfault (frame=0xfffffe0000466710, > > >> > usermode=0) > > >> > at /opt/src/svn-current/sys/amd64/amd64/trap.c:728 > > >> > #7 0xffffffff8095ddee in trap (frame=0xfffffe0000466710) > > >> > at /opt/src/svn-current/sys/amd64/amd64/trap.c:427 > > >> > #8 > > >> > #9 udp_append (inp=0xfffff80031d2ed58, ip=0xfffff800039333a0, > > >> > n=0xfffff80003933300, off=20, udp_in=0xfffffe0000466850) > > >> > at /opt/src/svn-current/sys/netinet/udp_usrreq.c:314 > > >> > #10 0xffffffff80806464 in udp_input (mp=, > > >> > offp=, > > >> > proto=17) at /opt/src/svn-current/sys/netinet/udp_usrreq.c:722 > > >> > #11 0xffffffff8075f645 in ip_input (m=0x0) > > >> > at /opt/src/svn-current/sys/netinet/ip_input.c:825 > > >> > #12 0xffffffff8073959b in netisr_process_workstream_proto ( > > >> > ---Type to continue, or q to quit---q > > >> > nwsp=,Quit > > >> > (kgdb) frame 9 > > >> > #9 udp_append (inp=0xfffff80031d2ed58, ip=0xfffff800039333a0, > > >> > n=0xfffff80003933300, off=20, udp_in=0xfffffe0000466850) > > >> > at /opt/src/svn-current/sys/netinet/udp_usrreq.c:314 > > >> > 314 if (up->u_tun_func != NULL) { > > >> > (kgdb) l > > >> > 309 > > >> > 310 /* > > >> > 311 * Engage the tunneling protocol. > > >> > 312 */ > > >> > 313 up = intoudpcb(inp); > > >> > 314 if (up->u_tun_func != NULL) { > > >> > 315 in_pcbref(inp); > > >> > 316 INP_RUNLOCK(inp); > > >> > 317 (*up->u_tun_func)(n, off, inp, (struct sockadd > r *)& > > >> udp_in[0], > > >> > 318 up->u_tun_ctx); > > >> > (kgdb) p up > > >> > $1 = (struct udpcb *) 0x0 > > >> > (kgdb) p *inp > > >> > $2 = {inp_hash = {cle_next = 0x0, cle_prev = 0xfffff800023abf70}, > > >> > inp_pcbgrouphash = {cle_next = 0x0, cle_prev = 0x0}, inp_lock = { > > >> > lock_object = {lo_name = 0xffffffff80a02fc7 "udpinp", lo_flags = > > >> > 90898432, > > >> > lo_data = 0, lo_witness = 0x0}, rw_lock = 33}, inp_hpts = { > > >> > tqe_next = 0x0, tqe_prev = 0x0}, inp_hpts_request = 0, > > >> > inp_in_hpts = 0 '\000', inp_in_input = 0 '\000', inp_hpts_cpu = 0, > > >> > inp_refcount = 1, inp_flags = 8405056, inp_flags2 = 16, inp_input_cp > u > > >> > = 0, > > >> > inp_hpts_cpu_set = 0 '\000', inp_input_cpu_set = 0 '\000', > > >> > inp_hpts_calls = 0 '\000', inp_input_calls = 0 '\000', > > >> > inp_spare_bits2 = 0 '\000', inp_spare_byte = 0 '\000', inp_ppcb = > > >> > 0x0, > > >> > inp_socket = 0x0, inp_hptsslot = 0, inp_hpts_drop_reas = 0, inp_inpu > t > > >> > = { > > >> > tqe_next = 0x0, tqe_prev = 0x0}, inp_pcbinfo = 0xfffffe0048566738, > > >> > inp_pcbgroup = 0x0, inp_pcbgroup_wild = {cle_next = 0x0, cle_prev = > > >> > 0x0}, > > >> > inp_cred = 0xfffff80031366600, inp_flow = 0, inp_vflag = 1 '\001', > > >> > inp_ip_ttl = 64 '@', inp_ip_p = 0 '\000', inp_ip_minttl = 0 '\000', > > >> > inp_flowid = 60, inp_snd_tag = 0x0, inp_flowtype = 63, > > >> > inp_rss_listen_bucket = 0, inp_inc = {inc_flags = 0 '\000', > > >> > inc_len = 0 '\000', inc_fibnum = 0, inc_ie = {ie_fport = 0, > > >> > ie_lport = 28353, ie_dependfaddr = {id46_addr = {ia46_pad32 = {0 > , > > >> > 0, 0}, > > >> > ia46_addr4 = {s_addr = 0}}, id6_addr = {__u6_addr = { > > >> > __u6_addr8 = '\000' , __u6_addr16 = {0, > > >> > 0, 0, 0, > > >> > 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}}, > > >> > ie_dependladdr = { > > >> > id46_addr = {ia46_pad32 = {0, 0, 0}, ia46_addr4 = { > > >> > ---Type to continue, or q to quit--- > > >> > s_addr = 16777343}}, id6_addr = {__u6_addr = { > > >> > __u6_addr8 = '\000' , "\177\000\000\001" > , > > >> > __u6_addr16 = {0, 0, 0, 0, 0, 0, 127, 256}, __u6_addr32 = > > >> > {0, 0, > > >> > 0, 16777343}}}}, ie6_zoneid = 0}}, inp_label = 0x0, > > >> > inp_sp = 0xfffff8000725dee0, {inp_ip_tos = 0 '\000', inp_options = > > >> > 0x0, > > >> > inp_moptions = 0x0}, {in6p_options = 0x0, in6p_outputopts = 0x0, > > >> > in6p_moptions = 0x0, in6p_icmp6filt = 0x0, in6p_cksum = 0, > > >> > in6p_hops = 0}, > > >> > inp_portlist = {cle_next = 0x0, cle_prev = 0xfffff80002334d20}, > > >> > inp_phd = 0xfffff80002334d00, inp_gencnt = 169, inp_lle = 0x0, > > >> > inp_rt_cookie = 7, {inp_route = {ro_rt = 0x0, ro_lle = 0x0, > > >> > ro_prepend = 0x0, ro_plen = 0, ro_flags = 256, ro_mtu = 0, spare > > >> > = 0, > > >> > ro_dst = {sa_len = 0 '\000', sa_family = 0 '\000', > > >> > sa_data = '\000' }}, inp_route6 = {ro_rt = > > >> > 0x0, > > >> > ro_lle = 0x0, ro_prepend = 0x0, ro_plen = 0, ro_flags = 256, > > >> > ro_mtu = 0, > > >> > spare = 0, ro_dst = {sin6_len = 0 '\000', sin6_family = 0 '\000' > , > > >> > sin6_port = 0, sin6_flowinfo = 0, sin6_addr = {__u6_addr = { > > >> > __u6_addr8 = '\000' , __u6_addr16 = {0, > > >> > 0, 0, 0, > > >> > 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id > > >> > = 0}}}, > > >> > inp_list = {cle_next = 0xfffff80031d4e000, cle_prev = > > >> > 0xfffffe0048566828}, > > >> > inp_epoch_ctx = {data = {0xffffffff80759b10 , > > >> > 0xfffff80002334d08}}} > > >> > (kgdb) up > > >> > #10 0xffffffff80806464 in udp_input (mp=, > > >> > offp=, > > >> > proto=17) at /opt/src/svn-current/sys/netinet/udp_usrreq.c:722 > > >> > 722 if (udp_append(inp, ip, m, iphlen, udp_in) == 0) > > >> > (kgdb) l > > >> > 717 return (IPPROTO_DONE); > > >> > 718 } > > >> > 719 } > > >> > 720 > > >> > 721 UDP_PROBE(receive, NULL, inp, ip, inp, uh); > > >> > 722 if (udp_append(inp, ip, m, iphlen, udp_in) == 0) > > >> > 723 INP_RUNLOCK(inp); > > >> > 724 return (IPPROTO_DONE); > > >> > 725 > > >> > 726 badunlocked: > > >> > (kgdb) up > > >> > #11 0xffffffff8075f645 in ip_input (m=0x0) > > >> > at /opt/src/svn-current/sys/netinet/ip_input.c:825 > > >> > 825 (*inetsw[ip_protox[ip->ip_p]].pr_input)(&m, &hlen, ip- > >ip_p > > >> ); > > >> > (kgdb) l > > >> > 820 /* > > >> > 821 * Switch out to protocol's input routine. > > >> > 822 */ > > >> > 823 IPSTAT_INC(ips_delivered); > > >> > 824 > > >> > 825 (*inetsw[ip_protox[ip->ip_p]].pr_input)(&m, &hlen, ip- > >ip_p > > >> ); > > >> > 826 return; > > >> > 827 bad: > > >> > 828 m_freem(m); > > >> > 829 } > > >> > (kgdb) > > >> > > > >> > > > >> > In both cases rtsold was starting. > > >> > > > >> > > > >> > > > >> > -- > > >> > Cheers, > > >> > Cy Schubert > > >> > FreeBSD UNIX: Web: http://www.FreeBSD.org > > >> > > > >> > The need of the many outweighs the greed of the few. > > >> > > > >> > > > >> > _______________________________________________ > > >> > 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 Fri Jun 22 14:18:08 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B69A3101D0F7 for ; Fri, 22 Jun 2018 14:18:08 +0000 (UTC) (envelope-from lev@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 43A9471F37 for ; Fri, 22 Jun 2018 14:18:08 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 07412101D0F6; Fri, 22 Jun 2018 14:18:08 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8CC0101D0F3 for ; Fri, 22 Jun 2018 14:18:07 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6745371F36 for ; Fri, 22 Jun 2018 14:18:07 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.23.186] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 6357AA5C for ; Fri, 22 Jun 2018 17:18:06 +0300 (MSK) To: current@freebsd.org Reply-To: lev@FreeBSD.org From: Lev Serebryakov Subject: clang on 12-CURRENT traps on its internal assertion when build kernel under nanobsd.sh control Openpgp: preference=signencrypt Autocrypt: addr=lev@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFKbGksBEADeguVs+XyJc3mL3iiOBqDd16wSk97YTJYOi4VsHsINzJr09oFvNDiaDBIi fLn2p8XcJvehcsF2GSgrfXfw+uK4O1jyNIKJmiYA0EtE+ZbRtvDrrE0w6Q8+SDeKA21SWh3Y vSQ0DJUontbgW55ER2CbEiIUTIn34uQ0kmESAaw/v5p/9ue8yPTmURvv130FqPFz8VPzltqL NxyGt54TxPfKAzAHEIwxlEZ63JOwzloKh1UDBExcsf9nJO08/TAVgR5UZ5njFBPzaaquhRoP qPJLEQQDqxPIlvMNtHKf7iIebE4BHeqgCdJA0BoiR6gpa0wlsZtdrTPK3n4wYSphLvGbhfOZ YW/hbcu7HYS/FImkVxB3iY17kcC1UTnx4ZaYeASPBGOOPbXky1lLfmDGWIFT//70yx+G17qD OZzF1SvJJhGvh6ilFYaWMX7T+nIp6Mcafc4D7AakXM+XdubNXOMlCJhzPcZ0skgAEnYV587w V7em5fDVwQccwvtfezzqKeJAU5TGiywBHSR5Svzk2FwRNf6M//hWkpq0SRR63iOhkHGOAEBi 69GfEIwH2/w24rLxP0E+Hqq8n+EWNkPatw1Mhcl5PKkdvGCjJUaGNMkpBffjyYo254JXRscR eEnwdIkJt4ErDvjb2/UrOFq31wWMOiLzJeVchAgvTHBMRfP9aQARAQABzShMZXYgU2VyZWJy eWFrb3YgPGxldkBzZXJlYnJ5YWtvdi5zcGIucnU+wsGCBBMBCAAsAhsDBwsJCAcDAgEGFQgC CQoLBBYCAwECHgECF4ACGQEFAlKbP8wFCQlmJwEACgkQ6rA8WL/cR4/6VBAAjRMyyX3PBFx/ HxyiIZ698EfwlWUua8Ft4crtrdK52m0qNkbBB9BH8xQgBHG32A1CwyzQnzxHgZuoOWMjh+Qq WJv7dmpM/q/c1GCJHhlPgewXrciTwpAamZILN071u+1GCPWwGRPzfQ/U+k63KJWx9ozf4doM WTTom6Cqcssi4J1u5kkt52a5ZRhsCK9pEVGilk36XTP9BakGrnMSIxF/NK4xeZVX2q+Nuqvf RchyofKXVgLEDLwb1cd/baLtBpDzy0PTN2Zl2lX4kOA6jwTKsqRya9A1Vui1KXwPh2XViTQ1 7Y3l5qg/M+sR73DohezP6bO6huOnLhty17jAqHPNlD6RonDo+j8uIlEg4iMSTN3MhzkBAu0Q pe3ucQ0o1767JiXN3fsNvRzSFhLVNDqPLce4uKlMogsbreXWvdgHGTN1ybOHGbybZnP77yHz uNBacbmG3vL/OLXMqwLdL2JXoiec4DmXjjCdhTBl5xLV9Hz/6VWKqElteg8QFVvHB3tHWzJ4 /rpiVEixytCIII6DS33BXZ0h2EOkK/6AYA2SJxy1vgOH4SZBtDBHoezmHV2nFnq5O0c7AuAB 7WPWgQG0sEwHQPZmg/baRGitRJnaxf/Gvf1DeD1x1VrcoVke2vwBcgDM3kugP8L9hsqic2D3 dI+gP76haeuvNNZr3y9L9zvOwU0EUpsaSwEQALRr3B+OjY/cnJPstz5CVsVWyEZtJtrNviZr tBgbkhlkPm98sEWR4+gbpyeufdYJengDjeGzMDKcLB7h5fICS/j6A8XdlJ40TlbPfNgb6OHa ebaIYKTJpXKR9sD7ZyGivYMofm0em40wGUX7BIkdkomaWj+wUiS0CdXU0FWDj9wv73+Eim+X zZyXeFgIPv97v+pET7DfwKkADOfrkW9s4OfvGVjd+wm35wc8EngQEz0qdPBxx74X7vZFAxlA SXu8gDBJGYt2Bkc3QwULnfeXrZJWgqNPR5o44gGu96yaiOFaN/C6CJtev5ZEX+0ZxbvsHHB7 Z5AtsRURKpZ4w5HFHGhzHtDtoAKgeZ/gbhTVXPHvNQR818eN+Nl5BV8BRF/8yhR6VlJb8GYw h8oKDeVGVYC34+raHZQAM9WoBnN7jlt4T9zzPwtmw5mIahGFgvw1KDr7OItN2ZgtZ20UYC5m Go602nmHq0aPbU6SwGi1xohrliNsKaaciYiMaVIGRQq8iGr9Fe2HlvaA3BpB275i/gCVlUdG y5XLAv+yQMUvn5Z7XVsMroxDk/O+ae1ElyBvKiKyfWGJXTg5XUukkkyQmfWPxWUGoNA1P/P4 GMHSu7/Rqe/7m4uPu/RyTTqsSjjKJdP9kBwEzvqPtXsVoZuShtrptRQJDYflhgE4qmKSMKen ABEBAAHCwWUEGAECAA8FAlKbGksCGwwFCRLMAwAACgkQ6rA8WL/cR48RkA//SNzeW3CI8KHx rA0aeHW6Nb5ieoqVRBGLyjBM06RX6vHB9v4dJL6Z+yV2jGN2s+XZX2HILbuTOwcTxGkI3xTT e0cDXVaF5K8R/liigUjtwuC2v/sWgoWyUmK1Cy9CPYdcXmFq6nESfkUe8DYiGOUULdHq5w63 F53yOZ72iXRBQBZgkhPtRFu4lPYIzOsMag9DIJ9CthR1r0ziqU/keb94Qt3l+aXK7CwGdY7X T4zUIMHNYsuAuyX+NJIXfsN68TT6m7QmlUwxPs13nxmoVQzm4ruV+hlQKh1MtbsjWRkNgPxF IPiqoAEhy8QoddlSvRTwL5Z7zFQiwMdiXU7toL8pfzj/zJR1jELXKMipijrt5MLrV8XX3OPN yZZvh95VIl8mv+iAqwSZUufd2EJnvj5TObB0eH+a+34NWf/XqA3fPjE6KHzmdnw9PZjPEjlx JCPECSs+6gse1+GaEfKYuXzB/ENe2ctlcfx5iQJXFc+/+zG/uU/JX/pXJHA12CUfB5g7lH6X BZIHvRo3VTCDjXgbF5xxDAe5V4exf8d4oSNjQIFLYxxN7zkvH89EN6RPfRgsWN7bYArCwfS9 MOgs9pFeCOewR6qieK150aoqNENGfKFXJup+5VVl6I0mU+j0rgVDZDht2/QgP/Tb4lGBe+ai pOGaK/GYNR+Ad6bUmokKsx4= Organization: FreeBSD Message-ID: <740aad56-4fed-d3a0-7f18-8c7c11d7ff07@FreeBSD.org> Date: Fri, 22 Jun 2018 17:18:00 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Cm5Q5rasgXzG06LYH0xI8qi1ZQ0iQKt6a" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 22 Jun 2018 14:18:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Cm5Q5rasgXzG06LYH0xI8qi1ZQ0iQKt6a Content-Type: multipart/mixed; boundary="ACt3tAe7BusZYdnzjeaFgX3IosWyrSAGQ"; protected-headers="v1" From: Lev Serebryakov Reply-To: lev@FreeBSD.org To: current@freebsd.org Message-ID: <740aad56-4fed-d3a0-7f18-8c7c11d7ff07@FreeBSD.org> Subject: clang on 12-CURRENT traps on its internal assertion when build kernel under nanobsd.sh control --ACt3tAe7BusZYdnzjeaFgX3IosWyrSAGQ Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable I tripped over very strange, but repeateable (in my conditions) bug in clang on 12-CURRENT. This message will be rather long, as I need to describe all details. I have VBox-based (Windows 10 is host) virtual machine with very fresh 12-CURRENT FreeBSD guest (r335478 now). I'm using this VM to build NanoBSD "firmware" for my router and I'm updating this VM via "buildworld buildkernel" ~weekly. This VM has 4 core CPU, 8GiB of "physical" RAM and 16GiB of swap. I *never* have problem when I make "make -j4 buidlworld buildkernel" to update VM itself. It works rock-solid. But when I try to build NanoBSD image from SAME SOURCES (exactly the same!) with SAME compiler (I'm using system compiler as cross-compiler to decrease time of build) clang fails every second time. Other problem is, that "nanobsd.sh" with "make -j1", but it is NOT out-of-memory, as swap isn't used at all! Message is always the same, and file is the same (asterisks are by me, to highlight assert): /usr/bin/cc -target x86_64-unknown-freebsd12.0 --sysroot=3D/usr/obj/nanobsd/data/src/amd64.amd64/tmp -B/usr/obj/nanobsd/data/src/amd64.amd64/tmp/usr/bin -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/data/src/sys/netgraph/bluetooth/include -I/data/src/sys/netgraph/bluetooth/drivers/ubtbcmfw -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/nanobsd/data/src/amd64.amd64/sys/D2500CC/opt_global.h -I. -I/data/src/sys -I/data/src/sys/contrib/ck/include -fno-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/obj/nanobsd/data/src/amd64.amd64/sys/D2500CC -MD -MF.depend.ubtbcmfw.o -MTubtbcmfw.o -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-address-of-packed-member -mno-aes -mno-avx -std=3Diso9899:1999 -c /data/src/sys/netgraph/bluetooth/drivers/ubtbcmfw/ubtbcmfw.c -o ubtbcmfw.= o ***** Assertion failed: ((!RequiresNullTerminator || BufEnd[0] =3D=3D 0) && "Buffer is not null terminated!"), function init, file /data/src/contrib/llvm/lib/Support/MemoryBuffer.cpp, line 48. ***** cc: error: unable to execute command: Abort trap (core dumped) cc: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0) Target: x86_64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin cc: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. --=20 // Lev Serebryakov --ACt3tAe7BusZYdnzjeaFgX3IosWyrSAGQ-- --Cm5Q5rasgXzG06LYH0xI8qi1ZQ0iQKt6a Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE+W0coLX0MYtnSzMK6rA8WL/cR48FAlstBRhfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEY5 NkQxQ0EwQjVGNDMxOEI2NzRCMzMwQUVBQjAzQzU4QkZEQzQ3OEYACgkQ6rA8WL/c R4+utw/+Isih98hiC3Jfx5PWwXlgGXefTFBa5g8yaWZeQzV5XlPegKuQkY//wdDU fMkQoOl/SNL1BE/jNKQyfHpHTsvNeMVzog02Lo+3xk668h7dAxqdUNl1EDb7G7Uu sJiaGaBBqJ5dekhq5b3xHP/SsgOEHHt9hU8T3gJKUq7YN14c0ewHenTRehuNnwoH r7Es+zB6LgBIjdGc6dwhpZWtwACuu+ZtB8gpvNxBl277B61xZHm+jzChG+3yd/xj wcFhuaeaazjgML/gxY31eoSaZ3v8lYu18Ii2E2wI1ZTy+CDPIp0EwvXlu2kuV7sH fwVBs5Rr3cgILyds4cpNrKIxSQ7GEGi7PEQkUXp5C5o7P7wsc8jBMx42r+Rrc6Kx 5xS2nkquQJdYZ7r1He6+TAD61p6uH69yijLHzPLWAkp/N8sCqyMnAKIKl8deTdk1 jpSmeauBr7TCkov1VmjF5JA5lllqwznlXoBAXPt6ZQjv+X7bqK1JsBzgRjxl9lnt E65NTYdiORm4EF9V35c50plj+AC7PTDHLuZmbc1PTZ4K8kGqVFIUx9U5lIpbwuO0 2BJN9B45bLRUb8nkR2TlGmJ9sVlLloASKUC/QnPUHz+4ZxDEb0+4SXj7Z/g4qD8v lsMKt1LnuNTnKCgc/Yatpz566uyIgGoq1fQ5E2+HpKFE31ctUEU= =g1wJ -----END PGP SIGNATURE----- --Cm5Q5rasgXzG06LYH0xI8qi1ZQ0iQKt6a-- From owner-freebsd-current@freebsd.org Fri Jun 22 17:25:05 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3A3D01021B15 for ; Fri, 22 Jun 2018 17:25:05 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from vps-mail.nomadlogic.org (mail.nomadlogic.org [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 9334078373; Fri, 22 Jun 2018 17:25:04 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.106] (cpe-75-82-194-8.socal.res.rr.com [75.82.194.8]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 0cf53872 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO; Fri, 22 Jun 2018 10:25:01 -0700 (PDT) Subject: Re: buildkernel broken on if_ixl when EVDEV is enabled To: =?UTF-8?Q?Danilo_Eg=c3=aaa_Gondolfo?= Cc: FreeBSD-current References: <3d9cffa3-8ee1-96e2-6edd-d3bf27fd88a5@nomadlogic.org> From: Pete Wright Message-ID: <7d7ed739-a8eb-1bd4-339b-d12464ff6629@nomadlogic.org> Date: Fri, 22 Jun 2018 10:25:00 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 22 Jun 2018 17:25:05 -0000 On 06/21/2018 20:47, Danilo Egêa Gondolfo wrote: > Hi, > > check if you have 'options IXL_IW' in your kernel conf. It's removed > from GENERIC. I had the same problem here with my customized conf. ah - that was totally it i think.  i was lazy and just copied GENERIC to GENERIC-EVDEV so it got of sync.  i've now re-created my EVDEV config to just include GENERIC. thanks for the heads up! -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Fri Jun 22 17:38:38 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C38510220E1 for ; Fri, 22 Jun 2018 17:38:38 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::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 B1DB478929 for ; Fri, 22 Jun 2018 17:38:37 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: by mail-pf0-x235.google.com with SMTP id y5-v6so3542886pfn.4 for ; Fri, 22 Jun 2018 10:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=zWVBcT6dWtx/Tv+rAMqTCnREz2jZtuFLfqexg7OILRA=; b=cnEKItXSxqhTDGayDFYNU/KyCHFIN6NRsyq51MLYoAcMnt0g+kIy5Hvvgr/k4RBp2Q oP7q9Wa8UnNL2gf6s4s/G+ERSb3dW+K4gy8SsU/nV1jGXollaEo/NUqpLX6RtOzlubmF 4Dy0wPquCgiNY0vCpcbvjwOopeP8swa4KMnYvq/P+q6wfsA3etRd1XtB0pDnu/1JCKlL FVFeKexZiuIPsqRpyakD3Dx4DCHTlBmx4fq/V8Rtp5l5ZqSrrSJ1/g1lrFLkT9BXl018 ZDhfEPc44jAdilNxwqEBp+eg0vQZDjLD5Uu26OqMxPozOu5bRxJGejOuZDvQoqemAx02 Op0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:openpgp :autocrypt:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=zWVBcT6dWtx/Tv+rAMqTCnREz2jZtuFLfqexg7OILRA=; b=UHW2emDjPBAM1zOFcpvnyeh3lWivk+A9Kkf6heIoEt12hS9zG+tUVKbWETjAEj1aoL uzACqvtLbCXSOtigE1ESoJjEE9CUn9BU1C4Fm4evrGup11f0wSMZdzU3fVnskeINuTtS z7fXagywcFWtBiPP2DLG9wKR67jKnlKEAf6e1x5NgwzF3OrVouZaW7G39zFjvZ0R1Q7h WnN8Ng/PtQtBWNiOuQQVqNGd+QT4byhmVw2Sb12aH3WNg3ILhq1QgzoLv6EsNg+dc8qa q/uodpqMADGiv5uS9oInocXypfMVc0WF0TiA7C8HIev9DL+GMp8wlIjE4FDgr/xiau3l 8w2A== X-Gm-Message-State: APt69E3Rjw5v33Xlcy/OKPhbucy5dUCUQNFwCWnorDjYvH84Sgf6FquQ 0UiUqbbEOTy1l3EIBnvOuLam6w== X-Google-Smtp-Source: ADUXVKLvcvomblQ7/kzDtAWWtV8dQXO36qjQj8Xg4HPjyBhEpyyla7jqCfNPDpDHJ1wN6CEl3YBo1Q== X-Received: by 2002:a63:ba43:: with SMTP id l3-v6mr2165307pgu.295.1529689116586; Fri, 22 Jun 2018 10:38:36 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [12.32.117.8]) by smtp.googlemail.com with ESMTPSA id y10-v6sm10815825pgr.44.2018.06.22.10.38.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jun 2018 10:38:35 -0700 (PDT) Sender: Navdeep Parhar Subject: Re: buildkernel broken on if_ixl when EVDEV is enabled To: freebsd-current@freebsd.org References: <3d9cffa3-8ee1-96e2-6edd-d3bf27fd88a5@nomadlogic.org> <7d7ed739-a8eb-1bd4-339b-d12464ff6629@nomadlogic.org> From: Navdeep Parhar Openpgp: preference=signencrypt Autocrypt: addr=np@FreeBSD.org; prefer-encrypt=mutual; keydata= xsDiBEosaGcRBACOXnXquGEW53BjpMt2jViod/TUf1xgjMekcbDxqOODPeX7eYfrwJ8G6BCN OpGjBmWDu/JcNj4Z+gmTilJ6WLZQ7ecFZfEeO91pt6ys0cyWh0xfO+/mT83D7W81S/kqrJBk QbBIdV6LumevdErHo272r8RcMELC4Ru87eRtX3hmEwCgnnGNJMpQFUfYTt5XE7nY0yQoeV8D /0OcWmJbEZWxX9O7AuliCe3zd2Dw0B4LB9SZ2Dis7+gpVd3xVgYnt5wRE9kM+ThgrMA/wqr8 07qmEG6bcfUsfwwGN9YUtNF3xAN07cXTs026sCIFNZK816PrThBzCgkwR7pDpkMzGWIBr8Wi XXy0eB+JlQ6UV4PEiXuZ5ulzP0b1A/9CZm3wJfrNC0r1gMyrfVedg4zwKU997bmPLGcYs+rW XDTI9CvMseOUYn4CoDZQCp/9zxuHK+VU7Y/w0c/hVE5ERACSn4SjN2unEDstK9njZBMHEPVk Ae/YvSG5cmc97SHlVE+eu/bbLKcvFb6rRLPOaVFQJMJA2VJEGWtYhvP7Zc0fTmF2ZGVlcCBQ YXJoYXIgPG5wQEZyZWVCU0Qub3JnPsJgBBMRAgAgBQJKLGhnAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQyrIrk6yriBL0MQCfUJOiS2PbJFDeiav1ylcXXwfpggAAoJRoS7GDENGy M4BzjJ4b0ptZqTLRzsFNBEosaGcQCACFCWs47SL4DQA6bNDlVJu4w8wLf8uVOyatuGmdXX8Y /OTVQJgA3vS+ODNVJCxhKVlvhcn7bhBdGdWKS9K+lr8+eEvr4hf2bQpesoHC+uFgKyILkCBN L8raixbhysyq0pfZWWDJMyn+G42BG1yJJi+bykygdpYnbIVA8dYHmBibI8mkPKOHSohjXT1S RfGGn+l1w54OO4NlJhCXMkjTA/Z9Bt4XeaiR85uJi0UUfV8FGZHhgSvT+/P1xIvz+nytuehS P/QLXl13CtAG/nKVkAcZnsT/3NrJ4Z2r45k+c50Wrf210scAaBogrrV5eIHfNGgOANApN8+8 vj+aXO4pXRuXAAMFB/44ea8rd+P5N3OMrfuM8i91Qe1bJ+BIoroKPOr8jvCry0h3QpdfLKUN IgaqbS3JZeBJ8HHnWSGCF+o6H5gzRe1hvylPEclLPDCuPe7T746h9Mzejf2hNDJvOg+BuweD ZW4KhovVbdS+syJEvpGF4bO8qgHT2CKgruXSHbFetdQWbkM0rfMmTuo0GcR2BEVrPb/SPFv6 4ZZyAZzmnGO4vT1bzClnTzJixrDpH74M3vSEYegMB4KdbLYBi8Jx4QUKgVEhJHjJubKWX4et yU/uuehOC3xYrmr1UXvsom3U8r36Dvdo77Yr3dgDVXa7bolNx0TIhdWxZI+R4z9E75QY+/wg wkkEGBECAAkFAkosaGcCGwwACgkQyrIrk6yriBI+JQCfUxgyqGtzZvLh5Al7gsTmRc11PLwA niD3NfWGRcO2+9uxSSQqRH1ywC4n Message-ID: <120e0a18-9048-2875-6b4d-ad81af91137a@FreeBSD.org> Date: Fri, 22 Jun 2018 10:38:34 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <7d7ed739-a8eb-1bd4-339b-d12464ff6629@nomadlogic.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 22 Jun 2018 17:38:38 -0000 On 06/22/18 10:25, Pete Wright wrote: >=20 >=20 > On 06/21/2018 20:47, Danilo Eg=C3=AAa Gondolfo wrote: >> Hi, >> >> check if you have 'options IXL_IW' in your kernel conf. It's removed >> from GENERIC. I had the same problem here with my customized conf. >=20 > ah - that was totally it i think.=C2=A0 i was lazy and just copied GENE= RIC to > GENERIC-EVDEV so it got of sync.=C2=A0 i've now re-created my EVDEV con= fig to > just include GENERIC. You can avoid your kernconf going out of sync by including GENERIC in it and then adding just your customizations. include GENERIC ident GENERIC-EVDEV options EVDEV_SUPPORT device evdev Regards, Navdeep From owner-freebsd-current@freebsd.org Fri Jun 22 17:41:17 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2ACC0102231D for ; Fri, 22 Jun 2018 17:41:17 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9DC2678F07 for ; Fri, 22 Jun 2018 17:41:16 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: by mail-pf0-x22b.google.com with SMTP id b74-v6so3544981pfl.5 for ; Fri, 22 Jun 2018 10:41:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:from:to:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=L4BLEBHMpT/3OClFC5oo8WvHqjiNivORU0OOH/0MaAM=; b=XO7Atm8sLO0zy5NfNyxwgCYkRfOyyTlkoON6XjRMU8Ku0WUYrqnPSeLTgz/ZUfEFIp 3XEf8RAcf7o13EprZ694k9cpxcYkEmrBTcRDi0kdY/gOInWUuMfy3ArTy+BZTIjHh1D4 CWz1CFeEdd4FsSUlbDqcmqhhrrU2WZcCeg4SpepIyWCd7fcQyGLxmzVB5J5K8H97rgNq vk1mvBO06t09M6x0GWHtHEauMJQ+UuVDJux076nxbsEQLohq7t2d8V0wZWEPPZDt7Wyg zg+SsNfuRiKvnjLz1QUgp+zIZ7p8WFek3JKiW51e8qvzXZ/c8/Hs7Pua/AYcI2RzhuHN wcSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:from:to:references:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=L4BLEBHMpT/3OClFC5oo8WvHqjiNivORU0OOH/0MaAM=; b=tf4PeJyk6jm76uMa0qFTSwFekLG2JcGdI6vXJJTR49tud4kx1usvaH8xQT4hSinxoN AzEoWHe4BYGRO94BqcvEsq774YLgMgk2r2l/BmejFTVF1BcYkkZQGveg4FpsGGqnsYSX 9I9RZVWX0lZHi+dOIUY8FO4/n6/0j08V7CE1hbp7vhCbYIW2Zma2S8/T/UQYTUC9S9K1 nSDjCCAVylLlv8PqjBNcKaoiIwXyGtjd+cMGH+tQCeUo7PiiKWd3lNFjPgX7XTb/DIz2 qsK+gcCYueYobvAb5vr13zf1CZGu2IOzg1Aq9gPDDEiVwlZrdeQzI6X8wnsK8Hy4tWjV U5lg== X-Gm-Message-State: APt69E1xDEAuoFB7kbZwCnAZMuP1Z47u7ZM5tcB86VARHz8qFA+tCvoD 1vq8dcsXC8AmSVmWN3XYc3rtZg== X-Google-Smtp-Source: ADUXVKJwaqToTMm/Vi7+5+Lc+XgCreAUqH/i3/BpmRAtOM7IlaBF+F+dHpLNuKlBweXr1t0jYIfEYg== X-Received: by 2002:a65:4a4d:: with SMTP id a13-v6mr2229181pgu.161.1529689275545; Fri, 22 Jun 2018 10:41:15 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [12.32.117.8]) by smtp.googlemail.com with ESMTPSA id i7-v6sm30314902pfa.34.2018.06.22.10.41.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jun 2018 10:41:14 -0700 (PDT) Sender: Navdeep Parhar Subject: Re: buildkernel broken on if_ixl when EVDEV is enabled From: Navdeep Parhar To: freebsd-current@freebsd.org References: <3d9cffa3-8ee1-96e2-6edd-d3bf27fd88a5@nomadlogic.org> <7d7ed739-a8eb-1bd4-339b-d12464ff6629@nomadlogic.org> <120e0a18-9048-2875-6b4d-ad81af91137a@FreeBSD.org> Message-ID: <235fd5c6-1218-d6d4-a92e-d4b3022b51e4@FreeBSD.org> Date: Fri, 22 Jun 2018 10:41:14 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <120e0a18-9048-2875-6b4d-ad81af91137a@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 22 Jun 2018 17:41:17 -0000 On 06/22/18 10:38, Navdeep Parhar wrote: > On 06/22/18 10:25, Pete Wright wrote: >> >> >> On 06/21/2018 20:47, Danilo Eg=C3=AAa Gondolfo wrote: >>> Hi, >>> >>> check if you have 'options IXL_IW' in your kernel conf. It's removed >>> from GENERIC. I had the same problem here with my customized conf. >> >> ah - that was totally it i think.=C2=A0 i was lazy and just copied GEN= ERIC to >> GENERIC-EVDEV so it got of sync.=C2=A0 i've now re-created my EVDEV co= nfig to >> just include GENERIC. >=20 > You can avoid your kernconf going out of sync by including GENERIC in i= t > and then adding just your customizations. oops I missed the last sentence in your email. From owner-freebsd-current@freebsd.org Fri Jun 22 17:41:34 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4EAD0102234A for ; Fri, 22 Jun 2018 17:41:34 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from vps-mail.nomadlogic.org (mail.nomadlogic.org [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 C5F4378F45 for ; Fri, 22 Jun 2018 17:41:33 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.106] (cpe-75-82-194-8.socal.res.rr.com [75.82.194.8]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 5b849fde TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO for ; Fri, 22 Jun 2018 10:41:31 -0700 (PDT) Subject: Re: buildkernel broken on if_ixl when EVDEV is enabled To: freebsd-current@freebsd.org References: <3d9cffa3-8ee1-96e2-6edd-d3bf27fd88a5@nomadlogic.org> <7d7ed739-a8eb-1bd4-339b-d12464ff6629@nomadlogic.org> <120e0a18-9048-2875-6b4d-ad81af91137a@FreeBSD.org> From: Pete Wright Message-ID: <885a33a4-d9ca-6633-bd05-d04c129d7826@nomadlogic.org> Date: Fri, 22 Jun 2018 10:41:30 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <120e0a18-9048-2875-6b4d-ad81af91137a@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 22 Jun 2018 17:41:34 -0000 On 06/22/2018 10:38, Navdeep Parhar wrote: > On 06/22/18 10:25, Pete Wright wrote: >> >> On 06/21/2018 20:47, Danilo Egêa Gondolfo wrote: >>> Hi, >>> >>> check if you have 'options IXL_IW' in your kernel conf. It's removed >>> from GENERIC. I had the same problem here with my customized conf. >> ah - that was totally it i think.  i was lazy and just copied GENERIC to >> GENERIC-EVDEV so it got of sync.  i've now re-created my EVDEV config to >> just include GENERIC. > You can avoid your kernconf going out of sync by including GENERIC in it > and then adding just your customizations. > > include GENERIC > ident GENERIC-EVDEV > options EVDEV_SUPPORT > device evdev yep, that's exactly what i did - don't think my hasty response phrased things too well :) -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Fri Jun 22 23:13:23 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3630E1002FA3 for ; Fri, 22 Jun 2018 23:13:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-22.consmr.mail.ne1.yahoo.com (sonic304-22.consmr.mail.ne1.yahoo.com [66.163.191.148]) (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 BE44887402 for ; Fri, 22 Jun 2018 23:13:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: voQDtl8VM1n5YiGC6F8uMN7MdaMTgNf99zNlzt3UOgJsYf76w1ba.3dLVJM5lA3 3aok97ZPQajoh5DOj203W3MdrN21LgsS3FI.rgdacDLB3EDcgGsjt4hOo8VygVYrCh3dHGbHtJEN bORrSYIj3f7tObyJENyG90kdHog7bsj6Tr9lNcvPu3yHtQXudkfT1pIGqm.GgQgdWcM9aS2QoRfh YKUpt7HZIXri48ESSIbE61aWVAl5Px6Z73gBdM6PblJ_XhOXFKfkYDxdx6TQjk_kbYoCJtoFbbAg b2lVfTCNlSRdWUHKc0e9CBKR8Q33pLYH7AxnJapafaFVb1UHGeviygh0J3zQh_5gyWrpWls4rBOQ tsOt0MpEQLmv0TG1woLIbbYhYx87cw7myY56Gy_lm.ovmH0cDr4NNCRmD93_K3MaTj5JBWm0BL9I Y6LVXqRblVYWKlKIvVvjTUIy7y45PckErX4tKKLxxhJ0eHECTuFddZxna2i3lpk9CihNrae40CZC UQgUfhvpgHd2Ud.JocffBcQMvswVW6h15EVhaC1hblfk1xoz.wkFOFNyeIiHv9AGk8ElJeEDllBM Jb6jgui56Z7JOapDHj.kdJTDEFjCaX9p3HazYTyacSs_5oKFkzTwbkof1W5k0yvLeELDgFB3Wofs w3wtaCGR.iGKzE8G7oNMMqS3F4I6Yzn0xCvh0iSyxfk4aGEbbLxloKm8rq0irmB_1T63M7X1Y.6z Bmq1O3eKhpTRfzKePQDIC9JLDev.ntKTg4TW57aXes2P.AeRV2I5m6zVWBkZ5xDxliR8kaq1Ys7O lcYWKIkTuVOl7fpRrc22hsLsAuW6Zp4sdDhg0YJENNB.ALRK4yK_QxLFF.rg4iLsYR_yBqNsbFxX vODohP_t7rrQ7SN4t0BfnCnnmqHn8MdnIdPSCsOAfXiWlkv.xETr3l.YiUB5hPrZ4LPgGta.3r13 L7o5TLWTwaTmrg4H3azZetg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.ne1.yahoo.com with HTTP; Fri, 22 Jun 2018 23:13:16 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp412.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID d716662e11868ceb9f087c09ce6510d5; Fri, 22 Jun 2018 23:03:08 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: head -r335568 breaks the ci.freebsd.org builds of the various FreeBSD-head-*-build Message-Id: <203EC229-F866-4B75-9E97-7104D819CC7D@yahoo.com> Date: Fri, 22 Jun 2018 16:03:06 -0700 To: rmacklem@FreeBSD.org, FreeBSD Current X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 22 Jun 2018 23:13:23 -0000 from the likes of: https://ci.freebsd.org/job/FreeBSD-head-sparc64-build/8346/consoleText --- nfs_commonkrpc.o --- /usr/src/sys/fs/nfs/nfs_commonkrpc.c: In function 'newnfs_request': /usr/src/sys/fs/nfs/nfs_commonkrpc.c:813: error: 'ND_HASSLOTID' = undeclared (first use in this function) /usr/src/sys/fs/nfs/nfs_commonkrpc.c:813: error: (Each undeclared = identifier is reported only once /usr/src/sys/fs/nfs/nfs_commonkrpc.c:813: error: for each function it = appears in.) *** [nfs_commonkrpc.o] Error code 1 (a gcc 4.2.1 context). Similarly for clang-based: --- all_subdir_nfscommon --- /usr/src/sys/fs/nfs/nfs_commonkrpc.c:814:20: error: use of undeclared = identifier 'ND_HASSLOTID' (ND_NFSV41 | ND_HASSLOTID) && nmp !=3D NULL && =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Sat Jun 23 00:52:58 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C203C1006374 for ; Sat, 23 Jun 2018 00:52:58 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670040.outbound.protection.outlook.com [40.107.67.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT TLS CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 345A68B688; Sat, 23 Jun 2018 00:52:57 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM (52.132.44.24) by YTOPR0101MB2169.CANPRD01.PROD.OUTLOOK.COM (52.132.46.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.884.21; Sat, 23 Jun 2018 00:52:56 +0000 Received: from YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM ([fe80::d0eb:3783:7c99:2802]) by YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM ([fe80::d0eb:3783:7c99:2802%3]) with mapi id 15.20.0863.016; Sat, 23 Jun 2018 00:52:56 +0000 From: Rick Macklem To: Mark Millard , "rmacklem@FreeBSD.org" , FreeBSD Current Subject: Re: head -r335568 breaks the ci.freebsd.org builds of the various FreeBSD-head-*-build Thread-Topic: head -r335568 breaks the ci.freebsd.org builds of the various FreeBSD-head-*-build Thread-Index: AQHUCn6mrhit+0EDGEGl2NdY9WRY86RtAzGw Date: Sat, 23 Jun 2018 00:52:56 +0000 Message-ID: References: <203EC229-F866-4B75-9E97-7104D819CC7D@yahoo.com> In-Reply-To: <203EC229-F866-4B75-9E97-7104D819CC7D@yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB2169; 7:NS3rCnggwYyAFDqXsMx3GygDY6y5YzTIeeRhhY97KR6gIqZR9kqt8LtNu3BxgtrzQo5EDmn1R0mi46wDSp2Qsz8Ok2GM19E8DlBawqnpQKaIHk1ikRNU5PUw9TsmD+VjIIhn3SYs1xHNoX9qOtSz9DUq2y09y7qPr+pcExjY6qFx29Seevog7ipgXUdmn98YxeFskHOrMi6hIUJrrBmVxV5hAPwwoUJD2a+NFQ51NpqShUUmVfi/k3lUntF+fqhM x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: c11dd06e-6c8e-4961-3d45-08d5d8a3a8db x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:YTOPR0101MB2169; x-ms-traffictypediagnostic: YTOPR0101MB2169: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211171220733660); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231254)(944501410)(52105095)(10201501046)(3002001)(149027)(150027)(6041310)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:YTOPR0101MB2169; BCL:0; PCL:0; RULEID:; SRVR:YTOPR0101MB2169; x-forefront-prvs: 07126E493C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(39380400002)(396003)(346002)(366004)(376002)(199004)(189003)(8936002)(74316002)(2906002)(478600001)(14454004)(229853002)(5660300001)(3660700001)(81156014)(33656002)(81166006)(305945005)(3280700002)(446003)(6506007)(6246003)(59450400001)(68736007)(8676002)(476003)(76176011)(11346002)(110136005)(97736004)(99286004)(25786009)(105586002)(486006)(102836004)(7696005)(186003)(5250100002)(26005)(6306002)(53936002)(106356001)(316002)(2900100001)(2501003)(9686003)(39060400002)(86362001)(6436002)(55016002)(786003)(74482002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB2169; H:YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-microsoft-antispam-message-info: PKRMJzcYHa53AH5tkDqD/Q861g5UXd77FK0tWpjeG7G9J9X+FIr6dOsx4meKESFXQ/eWykT+ILRecj9gcXasoHvAkcvp36/XF+YPHHi8uCOM33/FNk2rJitDHqUVaOI4BD5Ztf3XvA4JZvBQcfryI9edxEc1wR2m0A5Gp8sqNjicPAdQII1Jzz8JTRDsZTsC80EzfoQ3iZ5BX2CO8weohZwaVc0SSQpKwMqze1oinFw9qX2EqeILQ3rQmj6siSr0YQOXsaTLs0JP3UwmocgrQxcDCWizijP5rP8X3+fKmfxHDfpkI2mIA2MvQ53Ue8mnQPX8OVPYLoOrC1BY0pCXa6CJ+6EdggtvuJ/VcRu9xh8= 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-Network-Message-Id: c11dd06e-6c8e-4961-3d45-08d5d8a3a8db X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2018 00:52:56.6064 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB2169 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 23 Jun 2018 00:52:59 -0000 Mark Millard wrote: >from the likes of: > >https://ci.freebsd.org/job/FreeBSD-head-sparc64-build/8346/consoleText > >--- nfs_commonkrpc.o --- >/usr/src/sys/fs/nfs/nfs_commonkrpc.c: In function 'newnfs_request': >/usr/src/sys/fs/nfs/nfs_commonkrpc.c:813: error: 'ND_HASSLOTID' undeclared= (first >use in this function) >/usr/src/sys/fs/nfs/nfs_commonkrpc.c:813: error: (Each undeclared identifi= er is >reported only once >/usr/src/sys/fs/nfs/nfs_commonkrpc.c:813: error: for each function it appe= ars in.) >*** [nfs_commonkrpc.o] Error code 1 As you might have guessed, I missed part of the commit. Should be fixed by r335571. Pointy hat goes on me. Thanks for reporting it, rick From owner-freebsd-current@freebsd.org Sat Jun 23 02:13:34 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1F05100AA09 for ; Sat, 23 Jun 2018 02:13:33 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 610368E026 for ; Sat, 23 Jun 2018 02:13:33 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by mail-ua0-x232.google.com with SMTP id 59-v6so5441652uas.5 for ; Fri, 22 Jun 2018 19:13:33 -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=gxPERqGYarE6g0s5F6Ue8O+x5hwN1qRFO1NwyKrE8x0=; b=Fmm57+EWZWjQIO4EQ+6jqEgpmpAgTYoafXoUUlV9RdFV5w8RPngg76vbC862dJUFxJ 7m8B0UMNhYtP+eBWU9nzDAZ2tDrnUdRVPXq0xhiIjPGIkMYULan5P0oGwKIP3XMNBNhY PFGD8dkTHB4BpQ4AFrhx8y8LGBMJosw56bLJC8rWmirB8upf4MBwF0EzB8rawm5MR+q3 D5zdaD53F37YtJv+0pZAtcJiBeB8yq6MQRDGJbW4xkWvZK4YeaCPRyDdQ9TI2Q+IG4Sq PuBnNbEigCfiCiHLoMJek0hwx9z8zBGNd6wxFN3TsO/mKnIksrfqhJYVxS22KjkUSjDZ Ai+g== 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=gxPERqGYarE6g0s5F6Ue8O+x5hwN1qRFO1NwyKrE8x0=; b=AKMy21u2BSISgeMHqNlYX+0MuQeyQiQro23YRUg85kuQgEiDgXWlt3XaCSw+cq0J71 NUvS0tp22KD/XHPYxSPOu4bfNaQLpb90lxWx+GWgVQYVAilIWY6ESjOzudFsZC4NbMXq 3B5onOe/oYiv9/YYWbeZOAQB3XEaRmMUpuZrJxopoMWghJwV5rU9t5szO8ilroqrQDxU RaBx0jhR1brLOhWcGED1BLfqSXea7ef7u10ZEHGSUUfIv55WHm/Jrlc4uPcEN7Q70sK3 22j0eGAkYuj4BretO2tM2km8OCIV4DnUbZZtjzj0gpXat/PVMRtW6/Z1swNceH0+BYyp osWA== X-Gm-Message-State: APt69E3SMdnIlGooaYy3Jo6w5shN/AyiYDyhQd38XhlGb3t9vWJLyQVw Oz0PyL/9PN66ocBYEVq6WgOLNa19b5zYJcw+1vLB7jQy X-Google-Smtp-Source: ADUXVKJ6lJx1/tcHs/KwlSepAGXsqSPr+iFw0uE80xI6YNfA2lnMZGtVmsYqx9QqRCy2W1cNR+PfLz+pf3n6+7kzUlc= X-Received: by 2002:ab0:5c2e:: with SMTP id q46-v6mr2581153uaf.5.1529720012482; Fri, 22 Jun 2018 19:13:32 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:9:0:0:0:0:0 with HTTP; Fri, 22 Jun 2018 19:13:31 -0700 (PDT) From: Ben Woods Date: Sat, 23 Jun 2018 10:13:31 +0800 Message-ID: Subject: Boot freezing after kernel load - root on zfs To: FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 23 Jun 2018 02:13:34 -0000 Hi everyone, After shutting down to connect a new IP KVM switch (VGA and USB), my FreeNAS mini hardware is no longer booting FreeBSD with root in zfs (no encryption) - it is getting stuck after the kernel finishes loading and it tries to mount root and start_init. It just stops printing any more output to the screen, but I know the keyboard is working as ctrl+alt+delete works. I wonder if this could be due to hard drives names being re-ordered (e.g. what was ada0 is now ada1). I have 2 SATA3 SSDs in a zfs mirror for root (showing as ada4 and ada5 during boot), and 4 SATA3 HDDs in a raidz2 with geli for further storage (showing as ada0-3, but these are only mounted during rc init - after the point the boot process is getting stuck). I have no USB storage, although the IP KVM may present a virtual disk for loading media remotely. I am running 12-CURRENT, but know the recent upgrade is not the issue because I can=E2=80=99t load from the previous boot environment either. Is anyone able to recommend a fix or a way to troubleshoot further? Please see below a link with screenshots at the end of the boot where it gets stuck. https://imgur.com/gallery/vhn7ScC Thanks in advance for any help! Regards, Ben -- From: Benjamin Woods woodsb02@gmail.com From owner-freebsd-current@freebsd.org Sat Jun 23 04:08:14 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E8EBF10108E5 for ; Sat, 23 Jun 2018 04:08:13 +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 8EEC87293A for ; Sat, 23 Jun 2018 04:08:13 +0000 (UTC) (envelope-from allanjude@FreeBSD.org) Received: from [10.1.1.112] (senat1-01.HML3.ScaleEngine.net [209.51.186.5]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 944F21C21C; Sat, 23 Jun 2018 04:08:07 +0000 (UTC) Date: Sat, 23 Jun 2018 00:08:03 -0400 User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: Boot freezing after kernel load - root on zfs To: freebsd-current@freebsd.org, Ben Woods , FreeBSD Current From: Allan Jude Message-ID: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 23 Jun 2018 04:08:14 -0000 On June 22, 2018 10:13:31 PM EDT, Ben Woods wrote: >Hi everyone, > >After shutting down to connect a new IP KVM switch (VGA and USB), my >FreeNAS mini hardware is no longer booting FreeBSD with root in zfs (no >encryption) - it is getting stuck after the kernel finishes loading and >it >tries to mount root and start_init=2E It just stops printing any more >output >to the screen, but I know the keyboard is working as ctrl+alt+delete >works=2E > >I wonder if this could be due to hard drives names being re-ordered >(e=2Eg=2E >what was ada0 is now ada1)=2E I have 2 SATA3 SSDs in a zfs mirror for >root >(showing as ada4 and ada5 during boot), and 4 SATA3 HDDs in a raidz2 >with >geli for further storage (showing as ada0-3, but these are only mounted >during rc init - after the point the boot process is getting stuck)=2E I >have >no USB storage, although the IP KVM may present a virtual disk for >loading >media remotely=2E > >I am running 12-CURRENT, but know the recent upgrade is not the issue >because I can=E2=80=99t load from the previous boot environment either=2E > >Is anyone able to recommend a fix or a way to troubleshoot further? >Please >see below a link with screenshots at the end of the boot where it gets >stuck=2E > >https://imgur=2Ecom/gallery/vhn7ScC > >Thanks in advance for any help! > >Regards, >Ben > >-- >From: Benjamin Woods >woodsb02@gmail=2Ecom >_______________________________________________ >freebsd-current@freebsd=2Eorg mailing list >https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to >"freebsd-current-unsubscribe@freebsd=2Eorg" If you just press shift a bunch of times, does it print the Mount root pro= mpt? --=20 Allan Jude From owner-freebsd-current@freebsd.org Sat Jun 23 04:23:01 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E98AE10113C0 for ; Sat, 23 Jun 2018 04:23:00 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 80C95736CE; Sat, 23 Jun 2018 04:23:00 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by mail-vk0-x233.google.com with SMTP id b77-v6so5054479vkb.5; Fri, 22 Jun 2018 21:23:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o6Oz+it0rM6DRm1PXckgEaaDfcs5ySE/Y6Y8+8TdQvI=; b=MqYPwZTEq7g8ATLrGB5w4CvVB2XQcktLNEd931jH9SNHDO+coT2uSMYplgaGuNNX5i JZvuEl1/7hZ3M3oNvCWPh35+xJ8CckrMbuyBsL+XsUXM8GCyWOuum1ev5CNwCuoL7qpP nx79fQ+YW1w97vmsGZFK5rP24x4yXcQ3e5+QsrLhCub9YRljpOEboVwqLqsdh9tw+BOM j2v+zVIZE3puRZGoIE/zqQOfGW0/hkFsSNoMMbZy40/KF0o3VPusv74yXyhwIDI7ivVd 5dY6mapG5eQnkH3eRQzPD0xfcPseBnjQC9O+XdKDOqnka411o8b0KFrN7Y3FjveLy6k4 esWA== 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=o6Oz+it0rM6DRm1PXckgEaaDfcs5ySE/Y6Y8+8TdQvI=; b=aaWMBguw1sweXz7pKtSG5LE4mfb++Qp8dNR04SXdUwT+a62FMUcyL5pMzjrnVLsMD/ BaVorO8+10SKz2CuQiuabB34eygy+h960NfOoWLthniQkxhxHjz0uVTw6L7vzVnoeAHi Y3LdDN4HwpmIZUId5K5SwJOWrK0+hNRjHCRS41gUIG/4FmQYkAZYyvh3vNA0K85n9UHp omRp9KO8LtGqxknrtxbTmqrdnNzG8yRIdDHy2oPxhfEd4tUyxAzwSNbTuHtFc6tFBLUX uub+dhU89/vcLwGKRpMy6ULksM1Uq+ayCMllmLnR1Hin7bM/EYZ4h/s4kuX/GHMy15mH rAIg== X-Gm-Message-State: APt69E1ssOFvFMaK+2jQ+9XJOS2sfeMJvm6F7XSmsuT8pinciWRHBVhs zqyDxW6ST61Pcckp9zKpRXZAJPgU6OcCewXWhHUxU6kJ X-Google-Smtp-Source: ADUXVKIspzT1i/TpqaybVmyg1S+VifIX6UP5iR6MpkwbCT4qijGYVN5S692AYp2XQ73mFMTcxaSU6No5VAsiYYYykn0= X-Received: by 2002:a1f:4b86:: with SMTP id y128-v6mr2419087vka.146.1529727779830; Fri, 22 Jun 2018 21:22:59 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:9:0:0:0:0:0 with HTTP; Fri, 22 Jun 2018 21:22:59 -0700 (PDT) In-Reply-To: References: From: Ben Woods Date: Sat, 23 Jun 2018 12:22:59 +0800 Message-ID: Subject: Re: Boot freezing after kernel load - root on zfs To: Allan Jude Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 23 Jun 2018 04:23:01 -0000 On 23 June 2018 at 12:08, Allan Jude wrote: > If you just press shift a bunch of times, does it print the Mount root > prompt? > -- > Allan Jude > No, unfortunately not. But please keep any troubleshooting suggestions coming! I have tried booting with the KVM monitor and USB disconnected, with the same result. It is also worth noting I can successfully boot from a USB stick running the latest 12-current snapshot FreeBSD-12.0-CURRENT-amd64-20180618-r335317-memstick.img. From there I can import both of my zpools (zroot and zstore), and then export them again before rebooting - still can't boot from disk. -- From: Benjamin Woods woodsb02@gmail.com From owner-freebsd-current@freebsd.org Sat Jun 23 04:32:20 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD55C1011B62 for ; Sat, 23 Jun 2018 04:32:20 +0000 (UTC) (envelope-from mqudsi@neosmart.net) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6B22673CCA for ; Sat, 23 Jun 2018 04:32:20 +0000 (UTC) (envelope-from mqudsi@neosmart.net) Received: by mail-ot0-x231.google.com with SMTP id c15-v6so9715590otl.3 for ; Fri, 22 Jun 2018 21:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neosmart.net; s=google; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=9U71QhbDyz8kuLrwlYGJMU8gcdhfNJ0UsL2FLqXhBuQ=; b=AXDGCE99hHjaxtL8MycQkV3CjeXKhjC01Dp5f9HOp2JRr09R6VMebh/ICrxJ2m/hkD Et/I1w462BxSba+6WBp7lu+cjSZJ50kLWL08YZir6SbpIqgeveA2hwgC81VTV/LAFR64 A/aSN7iN+ZJDonQRd6Gu/xywX689hqUzBaqlA= 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 :content-transfer-encoding; bh=9U71QhbDyz8kuLrwlYGJMU8gcdhfNJ0UsL2FLqXhBuQ=; b=dxMGDxUNYV2W8qDx4eg98vXMrkmn47Rbjzabx/ONmR+3J4TCUuOYQcSBXNPAVWd5NA gBHuuLwz+4GRlBt93CccFcQaHENaYyfATB2Q+XS1OFgkjm0qQNKqUI5AS1rhzHhjd9Np U6RV6ICI410HqgyVCwaxKPxQ5w1VU/6Mavx3oqlBRp6lRi0qJ8GxMRtD9nAgG3lTxf9/ AnYCuBIgsmxN7V4GxEjvG1psiE8IfZlzILfZ3aM1waCVz+LNIL0YlCiY6La4Ch7tJokL UO/7B3WRZ+UbGzHFlYfVV7romxrjHMNgVOOcVJhXI/xX5MiHtgTT5Kr4eFmXewyq0PSa MWUQ== X-Gm-Message-State: APt69E2KZ+93T9CjoenvPXe/mnhNtEL6q6hviPDelt7Jrb6grQGa0rgV zqfaX3icSYGG0df7pR+UQGMVOL6uSa4i6Uc87TJmOniQ X-Google-Smtp-Source: ADUXVKLEhdPWsesFsM6Bppg6g0amOCGcDqYMAS1Ok/cnDzHnCf9W2kPJgpBrF3MLLY7yQYQ/mhZJNeCTsWoXa3BzL0c= X-Received: by 2002:a9d:2fda:: with SMTP id b26-v6mr2428033otd.177.1529728339194; Fri, 22 Jun 2018 21:32:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:e8f:0:0:0:0:0 with HTTP; Fri, 22 Jun 2018 21:31:58 -0700 (PDT) From: Mahmoud Al-Qudsi Date: Fri, 22 Jun 2018 23:31:58 -0500 Message-ID: Subject: Lack of /dev/vtvga0? To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 23 Jun 2018 04:32:21 -0000 Hello list, As I've mentioned in a previous message, I've been working on trying to get= a proper graphics subsystem/desktop up and running under 12-CURRENT without a= ny X components; something that was once possible a long time ago by using lib= vgl probably via SDL1.2 =E2=80=94 an option that's been deprecated in SDL2 and = isn't viable in all cases since libvgl doesn't support newcons/vt. I understand the limitations of the basic VGA driver (lack of hardware acceleration, current hard-coded 640x480x16 resolution) but I'm not clear o= n why the vt_vga driver does not make a framebuffer device available (vtvga0 = is initialized, but there is no corresponding /dev/vtvga0). Isn't it possible = to use vt_vga in pixel mode and directly write to the kernel console framebuff= er? Any insight would be appreciated! Mahmoud Al-Qudsi NeoSmart Technologies From owner-freebsd-current@freebsd.org Sat Jun 23 04:37:35 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A0CA91011F0C for ; Sat, 23 Jun 2018 04:37:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::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 345B373FFE for ; Sat, 23 Jun 2018 04:37:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x241.google.com with SMTP id d185-v6so7907789ioe.0 for ; Fri, 22 Jun 2018 21:37:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XjmnKEAvA+KVV8JVsCYm9Hqhhn53ebeIbCG9GN1X+kY=; b=nkYa+gyLwgGudSKPfVyr8AFbxmaWELoFEZkqeJRJhr6UFVTqoaTYz7ukQgbXP+0vs4 azxo9OZoRi6W33/iH9u8lPsmG+j+tcv6CibHJQq6Y/risqQBk9K+tiE+D9e3Xp5ejRh9 2Np4DZ9x1DdYFMeJ4e/4OeQszJiLBDp/ZAO2PjClJvZHUn5OurhH3FfJdpRjreYva/AP +lVpTxexirjkHwXDi08whUG0kmZNO1Ay5FWcECWmH4dznKx+FSKl/21TLyp6apgFGKrh jUU4eoGGcmv2gJBA3ZOP5PRuNgtUiR4P4idCGRZ3DrOLM0PRjauXPmfcqCvulYKEizam il3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XjmnKEAvA+KVV8JVsCYm9Hqhhn53ebeIbCG9GN1X+kY=; b=aGW9Zqe1xiTib0aFtprTjVGtVwMFeD2LiKL8aMcpSsJ8rne2eZHRVNC5nnJTJ0bfnY juzEHsN7Lqs0+OCMOA7t5Qs8Ho5J3abVjIe52fUKmDZIuofs+mX4qXq+GNZAezSVMOUZ IF6uks/78tqA/WNm8ffIKhJ9RE0ypoVwr53bLrJMBGis3kV1yPbf9M4wfWPL0XCoj5VZ U3/Ev6MWpmb08XD7Wr31qM2EVFwOz4gE4eN5Rv2Vibb6bJfNDv3Ze+KuP4BhbvTDiWmn zgE3Bx371udmSvSXmJ4TK7SIPCrQVIjXXZNyaC/75abVyovTcWJ64OvFXhphk+EEjURz OzGQ== X-Gm-Message-State: APt69E0BsFZqLOYDqOAdRLI7rBB28ghFbcRUWpCfHaBYyW/QQ10Yb22f 52bfh6TcFYHvg2amWwCHcR/K3yqXcayUv34Rxl5Kxg== X-Google-Smtp-Source: AAOMgpflmaqlDTvoeESvE59UqoqwCDTa0DgJtUju0cZpM/mYqLmm1h+HMsWO489IzbHWnYGeqJyZE2lejFCWCHPPdSw= X-Received: by 2002:a6b:d40c:: with SMTP id l12-v6mr3573526iog.37.1529728654441; Fri, 22 Jun 2018 21:37:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Fri, 22 Jun 2018 22:37:23 -0600 Message-ID: Subject: Re: Boot freezing after kernel load - root on zfs To: Ben Woods Cc: Allan Jude , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 23 Jun 2018 04:37:35 -0000 There were some issues with legacy geely booting recently. What version? UEFI or legacy BIOS booting? Warner On Fri, Jun 22, 2018, 10:26 PM Ben Woods wrote: > On 23 June 2018 at 12:08, Allan Jude wrote: > > > If you just press shift a bunch of times, does it print the Mount root > > prompt? > > -- > > Allan Jude > > > > > No, unfortunately not. But please keep any troubleshooting suggestions > coming! > > I have tried booting with the KVM monitor and USB disconnected, with the > same result. > > It is also worth noting I can successfully boot from a USB stick running > the latest 12-current snapshot > FreeBSD-12.0-CURRENT-amd64-20180618-r335317-memstick.img. From there I can > import both of my zpools (zroot and zstore), and then export them again > before rebooting - still can't boot from disk. > > -- > From: Benjamin Woods > woodsb02@gmail.com > _______________________________________________ > 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 Jun 23 05:11:41 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7619B1012F8B for ; Sat, 23 Jun 2018 05:11:41 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BDFBA74E76 for ; Sat, 23 Jun 2018 05:11:40 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id w5N5BV1m021867; Fri, 22 Jun 2018 22:11:37 -0700 (PDT) (envelope-from bsd-lists@BSDforge.com) X-Mailer: UDNSMS MIME-Version: 1.0 Cc: In-Reply-To: From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: "Mahmoud Al-Qudsi" Subject: Re: Lack of /dev/vtvga0? Date: Fri, 22 Jun 2018 22:11:37 -0700 Message-Id: <1ded7c55df9a77fd690959b375435b12@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 23 Jun 2018 05:11:41 -0000 On Fri, 22 Jun 2018 23:31:58 -0500 "Mahmoud Al-Qudsi" = said > Hello list, >=20 > As I've mentioned in a previous message, I've been working on trying to g= et > a > proper graphics subsystem/desktop up and running under 12-CURRENT without > any > X components; something that was once possible a long time ago by using > libvgl > probably via SDL1=2E2 =E2=80=94 an option that's been deprecated in SDL2 an= d isn't > viable in all cases since libvgl doesn't support newcons/vt=2E I'm not clear if you're already possibly referring to this=2E But have you tried sc(4) ( SysCons )=2E If you haven't tried already; adding the following to your loader=2Econf(5) should give it to you: kern=2Evty=3Dsc You can also include it in your custom kernel by adding this to your KERNCONF device sc options SC_PIXEL_MODE # adds support for the raster text mode Hope this helps=2E --Chris >=20 > I understand the limitations of the basic VGA driver (lack of hardware > acceleration, current hard-coded 640x480x16 resolution) but I'm not clear= on > why the vt_vga driver does not make a framebuffer device available (vtvga= 0 > is > initialized, but there is no corresponding /dev/vtvga0)=2E Isn't it possibl= e > to > use vt_vga in pixel mode and directly write to the kernel console > framebuffer? >=20 > Any insight would be appreciated! >=20 > Mahmoud Al-Qudsi > NeoSmart Technologies > _______________________________________________ > freebsd-current@freebsd=2Eorg mailing list > https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd=2Eorg= " From owner-freebsd-current@freebsd.org Sat Jun 23 13:41:00 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 836E010219F4 for ; Sat, 23 Jun 2018 13:41:00 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 12FD782C24 for ; Sat, 23 Jun 2018 13:41:00 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id C5DFD10219F3; Sat, 23 Jun 2018 13:40:59 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9DEB210219F2 for ; Sat, 23 Jun 2018 13:40:59 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0EC4382C21 for ; Sat, 23 Jun 2018 13:40:59 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm0-x243.google.com with SMTP id 69-v6so5425543wmf.3 for ; Sat, 23 Jun 2018 06:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:reply-to:mime-version :content-transfer-encoding; bh=Kh93RH4FYl6QwelP9LH4Ivt1erBK4Q7BDZ65H+HHckE=; b=NAkZm0ejw9f4GaXYVUVqUK97k6WfbWbWMHZemL5pm58mhU6vOiKdzFRwCWLYD+xNWx xTtrPro3VvNr3berwyQ4iw5nXt/wUj0OZtRwjBlZguN2TqZY84l0IhOoAK2kOH5cX8G1 ca2M2ZVmb/r9px8xibl5sdDZVVLfQnbZlLZ1WJxFucgYfJZxR7dDhSRTLViMVtu7a0th a/O2UFHZANfZZWbMp+0HOVQfJkvndtr4EpJHS6FtiuV8nz8S5SvS/wNO/hMuuB362Woy tEReBI/S5Be3diWLRIbCpShIq6S188t614fJH8XFT8G/4P6KMDgyCFuJ/aE2YzoKDtUh 6ZHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:reply-to :mime-version:content-transfer-encoding; bh=Kh93RH4FYl6QwelP9LH4Ivt1erBK4Q7BDZ65H+HHckE=; b=iTNFr8jzotWvJfPFFwJVMQnR23lBM8pgaj/qDFET2k272As4PnEjXbBW2v98hS5vNR lriVjtsOuw3vrDY3J8iDu7k0e9LkHPJFy9Dz/KouTxmwUg81rmtVanC7B2CCJIP8dq+j aogfbE7HXBYdAN7lY28mCDRTX628x50yDrkls/+cbYp1duiL7g6L3ilEs5enlTNEn0Fw 1cUHLYgdBRhaMK5edhjW8q+9GvRVFCzezRA53uZQ5Np3QqG6GfqdqbAndCrYmgwiRMbo EtRrwjQoqnAls6r2u2ngoETHOFcqfhVpYg/GzW42MZPsCyElXW4m8RRzIzNpqkOm3eHf GufA== X-Gm-Message-State: APt69E1AzLpdvOAaV/v3W1DJ0OdTmK8xDuLUn6oOAjwSdyJWTAU+E6oT aCWbqvspUsF7waxRwOUDFJxMeg== X-Google-Smtp-Source: ADUXVKLZMgU9Te+5t+sUFaLgeTjdf6s8etV0cYPg0UIQpFxBYZuLuXy39+YLqmV89NnRQ68ovdaa9w== X-Received: by 2002:a1c:c44c:: with SMTP id u73-v6mr4162408wmf.99.1529761257874; Sat, 23 Jun 2018 06:40:57 -0700 (PDT) Received: from ernst.home (p5B02381D.dip0.t-ipconnect.de. [91.2.56.29]) by smtp.gmail.com with ESMTPSA id h18-v6sm12900134wrq.36.2018.06.23.06.40.56 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 23 Jun 2018 06:40:56 -0700 (PDT) Date: Sat, 23 Jun 2018 15:40:48 +0200 From: Gary Jennejohn To: current@freebsd.org Subject: error building clang in HEAD Message-ID: <20180623154048.1b228df0@ernst.home> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.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.26 Precedence: 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, 23 Jun 2018 13:41:00 -0000 There is a strange error building clang with this use case: cd /usr/src make -j10 makeworld which produces this error output: ===> lib/clang/libclang (all) error: unable to rename temporary 'Sema/SemaTemplate-12ad7e30.o.tmp' to output file 'Sema/SemaTemplate.o': 'No such file or directory' 1 error generated. --- Sema/SemaTemplate.o --- *** [Sema/SemaTemplate.o] Error code 1 make[6]: stopped in /usr/src/lib/clang/libclang .ERROR_TARGET='Sema/SemaTemplate.o' .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/lib/clang/libclang/Sema_SemaTemplate.o.meta' .MAKE.LEVEL='6' MAKEFILE='' .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes' _ERROR_CMD='c++ -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -DNO_MALLOC_EXTRAS -I/usr/obj/usr/src/amd64.amd64/lib/clang/libclang -I/usr/obj/usr/src/amd64.amd64/lib/clang/libllvm -I/usr/src/contrib/llvm/tools/clang/lib/Basic -I/usr/src/contrib/llvm/tools/clang/lib/Driver -I/usr/src/contrib/llvm/tools/clang/include -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_STATIC_ANALYZER -I/usr/src/lib/clang/include -I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\" -DDEFAULT_SYSROOT=\"\" -DLLVM_TARGET_ENABLE_X86 -DLLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser -DLLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter -DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler -DLLVM_NATIVE_TARGET=LLVMInitializeX86Target -DLLVM_NATIVE_TARGETINFO=LLVMInitializeX86Tar getInfo -DLLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC -ffunction-sections -fdata-sections -Qunused-arguments -DNO_MALLOC_EXTRAS -std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions -c /usr/src/contrib/llvm/tools/clang/lib/Sema/SemaTemplate.cpp -o Sema/SemaTemplate.o;' .CURDIR='/usr/src/lib/clang/libclang' .MAKE='make' .OBJDIR='/usr/obj/usr/src/amd64.amd64/lib/clang/libclang' .TARGETS='all' DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp' LD_LIBRARY_PATH='' MACHINE='amd64' MACHINE_ARCH='amd64' MAKEOBJDIRPREFIX='' MAKESYSPATH='/usr/src/share/mk' MAKE_VERSION='20180512' PATH='/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP='/usr/src' OBJTOP='/usr/obj/usr/src/amd64.amd64' .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk /etc/src-env.conf /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk /etc/make.conf /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /etc/src.conf /usr/src/lib/clang/libclang/Makefile /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.mk /usr/src/lib/clang/clang.pre.mk /usr/src/lib/clang/llvm.pre.mk /usr/src/lib/clang/clang.build.mk /usr/src/lib/clang/llvm.build.mk /usr/src/share/mk/bsd.lib.mk /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk /usr/src/lib/clang/libclang/../Makefile.inc /usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk /usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk /usr/src /share/mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk /usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.sys.mk' .PATH='. /usr/src/lib/clang/libclang /usr/src/contrib/llvm/tools/clang/lib' 1 error However, if I do this cd /usr/src/lib/clang/libclang make -j10 depend all it succeeds. I have META_MODE enabled. It also succeeds with a simple make buildworld, but that's extremely slow. Note that this started happening after rm -rf /usr/obj/usr. -- Gary Jennejohn From owner-freebsd-current@freebsd.org Sat Jun 23 14:40:36 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 549F41023142 for ; Sat, 23 Jun 2018 14:40:36 +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 E055F84590 for ; Sat, 23 Jun 2018 14:40:35 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id F06211C8A3; Sat, 23 Jun 2018 14:40:34 +0000 (UTC) Subject: Re: Boot freezing after kernel load - root on zfs To: Warner Losh , Ben Woods Cc: FreeBSD Current References: From: Allan Jude Openpgp: preference=signencrypt Autocrypt: addr=allanjude@freebsd.org; prefer-encrypt=mutual; keydata= xsFNBFVwZcYBEADwrZDH0xe0ZVjc9ORCc6PcBLwS/RTXA6NkvpD6ea02pZ8lPOVgteuuugFc D34LdDbiWr+479vfrKBh+Y38GL0oZ0/13j10tIlDMHSa5BU0y6ACtnhupFvVlQ57+XaJAb/q 7qkfSiuxVwQ3FY3PL3cl1RrIP5eGHLA9hu4eVbu+FOX/q/XVKz49HaeIaxzo2Q54572VzIo6 C28McX9m65UL5fXMUGJDDLCItLmehZlHsQQ+uBxvODLFpVV2lUgDR/0rDa0B9zHZX8jY8qQ7 ZdCSy7CwClXI054CkXZCaBzgxYh/CotdI8ezmaw7NLs5vWNTxaDEFXaFMQtMVhvqQBpHkfOD 7rjjOmFw00nJL4FuPE5Yut0CPyx8vLjVmNJSt/Y8WxxmhutsqJYFgYfWl/vaWkrFLur/Zcmz IklwLw35HLsCZytCN5A3rGKdRbQjD6QPXOTJu0JPrJF6t2xFkWAT7oxnSV0ELhl2g+JfMMz2 Z1PDmS3NRnyEdqEm7NoRGXJJ7bgxDbN+9SXTyOletqGNXj/bSrBvhvZ0RQrzdHAPwQUfVSU2 qBhQEi2apSZstgVNMan0GUPqCdbE2zpysg+zT7Yhvf9EUQbzPL4LpdK1llT9fZbrdMzEXvEF oSvwJFdV3sqKmZc7b+E3PuxK6GTsKqaukd/3Cj8aLHG1T1im1QARAQABzSJBbGxhbiBKdWRl IDxhbGxhbmp1ZGVAZnJlZWJzZC5vcmc+wsF/BBMBAgApBQJVcGXGAhsjBQkSzAMABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AACgkQGZU1PhKYC34Muw/+JOKpSfhhysWFYiRXynGRDe07 Z6pVsn7DzrPUMRNZfHu8Uujmmy3p2nx9FelIY9yjd2UKHhug+whM54MiIFs90eCRVa4XEsPR 4FFAm0DAWrrb7qhZFcE/GhHdRWpZ341WAElWf6Puj2devtRjfYbikvj5+1V1QmDbju7cEw5D mEET44pTuD2VMRJpu2yZZzkM0i+wKFuPxlhqreufA1VNkZXI/rIfkYWK+nkXd9Efw3YdCyCQ zUgTUCb88ttSqcyhik/li1CDbXBpkzDCKI6I/8fAb7jjOC9LAtrZJrdgONywcVFoyK9ZN7EN AVA+xvYCmuYhR/3zHWH1g4hAm1v1+gIsufhajhfo8/wY1SetlzPaYkSkVQLqD8T6zZyhf+AN bC7ci44UsiKGAplB3phAXrtSPUEqM86kbnHg3fSx37kWKUiYNOnx4AC2VXvEiKsOBlpyt3dw WQbOtOYM+vkfbBwDtoGOOPYAKxc4LOIt9r+J8aD+gTooi9Eo5tvphATf9WkCpl9+aaGbSixB tUpvQMRnSMqTqq4Z7DeiG6VMRQIjsXDSLJEUqcfhnLFo0Ko/RiaHd5xyAQ4DhQ9QpkyQjjNf /3f/dYG7JAtoD30txaQ5V8uHrz210/77DRRX+HJjEj6xCxWUGvQgvEZf5XXyxeePvqZ+zQyT DX61bYw6w6bOwU0EVXBlxgEQAMy7YVnCCLN4oAOBVLZ5nUbVPvpUhsdA94/0/P+uqCIh28Cz ar56OCX0X19N/nAWecxL4H32zFbIRyDB2V/MEh4p9Qvyu/j4i1r3Ex5GhOT2hnit43Ng46z5 29Es4TijrHJP4/l/rB2VOqMKBS7Cq8zk1cWqaI9XZ59imxDNjtLLPPM+zQ1yE3OAMb475QwN UgWxTMw8rkA7CEaqeIn4sqpTSD5C7kT1Bh26+rbgJDZ77D6Uv1LaCZZOaW52okW3bFbdozV8 yM2u+xz2Qs8bHz67p+s+BlygryiOyYytpkiK6Iy4N7FTolyj5EIwCuqzfk0SaRHeOKX2ZRjC qatkgoD/t13PNT38V9tw3qZVOJDS0W6WM8VSg+F+bkM9LgJ8CmKV+Hj0k3pfGfYPOZJ/v18i +SmZmL/Uw2RghnwDWGAsPCKu4uZR777iw7n9Io6Vfxndw2dcS0e9klvFYoaGS6H2F13Asygr WBzFNGFQscN4mUW+ZYBzpTOcHkdT7w8WS55BmXYLna+dYer9/HaAuUrONjujukN4SPS1fMJ2 /CS/idAUKyyVVX5vozoNK2JVC1h1zUAVsdnmhEzNPsvBoqcVNfyqBFROEVLIPwq+lQMGNVjH ekLTKRWf59MEhUC2ztjSKkGmwdg73d6xSXMuq45EgIJV2wPvOgWQonoHH/kxABEBAAHCwWUE GAECAA8FAlVwZcYCGwwFCRLMAwAACgkQGZU1PhKYC34w5A//YViBtZyDV5O+SJT9FFO3lb9x Zdxf0trA3ooCt7gdBkdnBM6T5EmjgVZ3KYYyFfwXZVkteuCCycMF/zVw5eE9FL1+zz9gg663 nY9q2F77TZTKXVWOLlOV2bY+xaK94U4ytogOGhh9b4UnQ/Ct3+6aviCF78Go608BXbmF/GVT 7uhddemk7ItxM1gE5Hscx3saxGKlayaOsdPKeGTVJCDEtHDuOc7/+jGh5Zxpk/Hpi+DUt1ot 8e6hPYLIQa4uVx4f1xxxV858PQ7QysSLr9pTV7FAQ18JclCaMc7JWIa3homZQL/MNKOfST0S 2e+msuRwQo7AnnfFKBUtb02KwpA4GhWryhkjUh/kbVc1wmGxaU3DgXYQ5GV5+Zf4kk/wqr/7 KG0dkTz6NLCVLyDlmAzuFhf66DJ3zzz4yIo3pbDYi3HB/BwJXVSKB3Ko0oUo+6/qMrOIS02L s++QE/z7K12CCcs7WwOjfCYHK7VtE0Sr/PfybBdTbuDncOuAyAIeIKxdI2nmQHzl035hhvQX s4CSghsP319jAOQiIolCeSbTMD4QWMK8RL/Pe1FI1jC3Nw9s+jq8Dudtbcj2UwAP/STUEbJ9 5rznzuuhPjE0e++EU/RpWmcaIMK/z1zZDMN+ce2v1qzgV936ZhJ3iaVzyqbEE81gDxg3P+IM kiYh4ZtPB4Q= Message-ID: <85e188ff-a9db-3120-2709-1030640250e7@freebsd.org> Date: Sat, 23 Jun 2018 10:40:31 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8REuya94aHnRijhUfzytTq7J3EppSvmj2" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 23 Jun 2018 14:40:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8REuya94aHnRijhUfzytTq7J3EppSvmj2 Content-Type: multipart/mixed; boundary="cSTLEP830b4Ttq94c8UZcxYhg0p2Mpj4Z"; protected-headers="v1" From: Allan Jude To: Warner Losh , Ben Woods Cc: FreeBSD Current Message-ID: <85e188ff-a9db-3120-2709-1030640250e7@freebsd.org> Subject: Re: Boot freezing after kernel load - root on zfs References: In-Reply-To: --cSTLEP830b4Ttq94c8UZcxYhg0p2Mpj4Z Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2018-06-23 00:37, Warner Losh wrote: > There were some issues with legacy geely booting recently. What version= ? > UEFI or legacy BIOS booting? >=20 > Warner=C2=A0 >=20 > On Fri, Jun 22, 2018, 10:26 PM Ben Woods > wrote: >=20 > On 23 June 2018 at 12:08, Allan Jude > wrote: >=20 > > If you just press shift a bunch of times, does it print the Mount= root > > prompt? > > -- > > Allan Jude > > >=20 >=20 > No, unfortunately not. But please keep any troubleshooting suggesti= ons > coming! >=20 > I have tried booting with the KVM monitor and USB disconnected, wit= h the > same result. >=20 > It is also worth noting I can successfully boot from a USB stick ru= nning > the latest 12-current snapshot > FreeBSD-12.0-CURRENT-amd64-20180618-r335317-memstick.img. From ther= e > I can > import both of my zpools (zroot and zstore), and then export them a= gain > before rebooting - still can't boot from disk. >=20 > -- > From: Benjamin Woods > woodsb02@gmail.com > _______________________________________________ > 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 > " >=20 Warner: it is not that in this case, the screenshots show it getting just past mountroot, so it is well into the kernel when it is stopping. --=20 Allan Jude --cSTLEP830b4Ttq94c8UZcxYhg0p2Mpj4Z-- --8REuya94aHnRijhUfzytTq7J3EppSvmj2 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) iQIcBAEBAgAGBQJbLlviAAoJEBmVNT4SmAt+d/4QANzLaW0dlf3IYQYctyqhr00A TpQM7yodB3oXvWSzpau1Nb4P8wH/wdEtIbdSEYx9/Gm5UGvEmaRoiEG4tBMudBvM qajOMaXiHCA35SkpOHjYqFnwleeheopItIXHJpGPJvRLQdJbN8IvFYF3b5gfXq2z t/ES2fEcGo8fR4Ir+uxpuraFans5mAPR8lNjfxCYqYgFsehIRnlykN/5J0lmA6NL 5A0ZHiPrx8symhdwQLPH41Iz3eBh38RMyXxKvPalBqcxhEL2Osdw59rrReIUarht fTPgs9sDe6oyLKNymWgz0K7LkwaQhCvv1pIJ0RAtoSDOC3rDteP0t1tZtLOom/rw p6ldzv+Ke4fhDXCrLEOtL01wix57dkSSCrvjPgTjT3FtbCvE1Wj6mOG0ViSUNbxO DbxTLgOBuUU/auOm/OAA+kyUrY4HOplNcpnD2KooSY6+1mFRSn+3Mgsy4G+g7YzT QnUZNNQpR0ZPwZVqrJ7VwJkdRVAdTxwuQEqbO2XPoIENY2yB8ZpZKCs4h12yezKg DZ9rOIZayDbtJA8cFYqMHIejowz2pv2oEZxYUAivB9kdWSvE1FvCGD8SeNGlB6uf rvcNyY/IIhkMGZmuU3jBp6+OxCLiCAr7lkE+LdmGKMcPCsvjVfZdAfBlHDICNk5h OkFTiIlbwMxEzG3PCV8H =Q6uI -----END PGP SIGNATURE----- --8REuya94aHnRijhUfzytTq7J3EppSvmj2-- From owner-freebsd-current@freebsd.org Sat Jun 23 14:56:10 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B1CF41023D94 for ; Sat, 23 Jun 2018 14:56:10 +0000 (UTC) (envelope-from jmaloney@ixsystems.com) Received: from mail-yw0-x241.google.com (mail-yw0-x241.google.com [IPv6:2607:f8b0:4002:c05::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 4DFB785265 for ; Sat, 23 Jun 2018 14:56:10 +0000 (UTC) (envelope-from jmaloney@ixsystems.com) Received: by mail-yw0-x241.google.com with SMTP id s201-v6so3379175ywg.8 for ; Sat, 23 Jun 2018 07:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ixsystems-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cCRHJNvg4XUANQdSuBd6On6fuQnBj4mqDKcQ2BhMyRo=; b=XGJ2Dr+ZjjoBhkkx/DJtmqMYnlAv8mN2IM0EPszKb6liDGQynbi5kJ99tfX9A+i/g6 DTzESou+CmA8774/BXO/GwffqCq+g0nHzUlJM3mnXGUOkr4fc8qEO+e8NSao4/nmFiRY OKVfUKqOB5ejMX2juzCbg/WXVn8ULppDOsK1CMiMmDMLrPXuzGQpckLxWIubGkAO1WbN KlJLnv4TsUuMD5ALn9tNoPInOcTdvwsbKHTiIFDLoqvGe/V6LUYDINje66dYS8KRYPNi f2TKabtms+i2MwGwyqoxRx+Mj/LEQSqaZYFuvrTj24FMPR7aQRs+FuEM6WHf32Yq2sXS 2xpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cCRHJNvg4XUANQdSuBd6On6fuQnBj4mqDKcQ2BhMyRo=; b=f4SQlV86H9GCAHo4fqdBBtqLY8K5gBB/j12v0ehrUveUBZg8gOaMnjb+SJe/6DS6UW pZItThOLBBaLj1SL6JrbUD7uvnTv90qe/fyqhWjneUWgAD+GUtxIW3VTBJQgFGSuQfyZ 7nDIRGRcRxJHkBIuJ0LqJ+X+HTTjYvzjJUncMvD8aItGL36slRSOGdh+/B+/7aXsR4vZ Va3CCLxBJC13dLOcOzPh/+x0wNjq+wMBXS6N5SpxXFE7ASOzZyVu360FZc95KIMKbYF1 Q6wENf885LjnsGJZo7PpTEJX0Leg/IPd3QoEmw6oEM9L489XjKyFcorEDpvozPnVJHTo JfsA== X-Gm-Message-State: APt69E3MlxANpPFcYcZsLcKwOjR1mnouDQcuAf+qVmvywu001DjCt4kg 2PIxmOded5j+pRgTcjym0KJGkw== X-Google-Smtp-Source: ADUXVKLzvVR5POFuqKPScPmNsdRK3o1gvGE/fkgFGgGVlG8qDFL5Yc3LOkSvuhVfWiWCoWgKhY42/w== X-Received: by 2002:a81:3c0d:: with SMTP id j13-v6mr2718672ywa.16.1529765769668; Sat, 23 Jun 2018 07:56:09 -0700 (PDT) Received: from [10.0.1.12] (24-151-223-32.dhcp.jcsn.tn.charter.com. [24.151.223.32]) by smtp.gmail.com with ESMTPSA id w192-v6sm1332940ywd.8.2018.06.23.07.56.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Jun 2018 07:56:09 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: Boot freezing after kernel load - root on zfs From: Joe Maloney X-Mailer: iPhone Mail (15F79) In-Reply-To: <85e188ff-a9db-3120-2709-1030640250e7@freebsd.org> Date: Sat, 23 Jun 2018 10:56:07 -0400 Cc: Warner Losh , Ben Woods , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <3BCF59A2-308D-4A45-97EA-C25397F50C24@ixsystems.com> References: <85e188ff-a9db-3120-2709-1030640250e7@freebsd.org> To: Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 23 Jun 2018 14:56:10 -0000 Ben, do you by chance have multicons enabled with comconsole, vidconsole? This l= ooks exactly like a race we encountered where the remaining output was actua= lly being redirected to serial on some systems when multicons was being used= . It appeared to be a lockup when it wasn=E2=80=99t because keyboard input w= ould also break. > On Jun 23, 2018, at 10:40 AM, Allan Jude wrote: >=20 >> On 2018-06-23 00:37, Warner Losh wrote: >> There were some issues with legacy geely booting recently. What version? >> UEFI or legacy BIOS booting? >>=20 >> Warner=20 >>=20 >> On Fri, Jun 22, 2018, 10:26 PM Ben Woods > > wrote: >>=20 >> On 23 June 2018 at 12:08, Allan Jude > > wrote: >>=20 >>> If you just press shift a bunch of times, does it print the Mount root >>> prompt? >>> -- >>> Allan Jude >>>=20 >>=20 >>=20 >> No, unfortunately not. But please keep any troubleshooting suggestions= >> coming! >>=20 >> I have tried booting with the KVM monitor and USB disconnected, with t= he >> same result. >>=20 >> It is also worth noting I can successfully boot from a USB stick runni= ng >> the latest 12-current snapshot >> FreeBSD-12.0-CURRENT-amd64-20180618-r335317-memstick.img. =46rom there= >> I can >> import both of my zpools (zroot and zstore), and then export them agai= n >> before rebooting - still can't boot from disk. >>=20 >> -- >> From: Benjamin Woods >> woodsb02@gmail.com >> _______________________________________________ >> 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 >> " >>=20 >=20 > Warner: it is not that in this case, the screenshots show it getting > just past mountroot, so it is well into the kernel when it is stopping. >=20 > --=20 > Allan Jude >=20 From owner-freebsd-current@freebsd.org Sat Jun 23 15:05:22 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 87B8F10242EB for ; Sat, 23 Jun 2018 15:05:22 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 213C585C36 for ; Sat, 23 Jun 2018 15:05:22 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id D939010242E9; Sat, 23 Jun 2018 15:05:21 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C67B310242E8 for ; Sat, 23 Jun 2018 15:05:21 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 77D4385C34; Sat, 23 Jun 2018 15:05:21 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.home.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 0CD3419AF4; Sat, 23 Jun 2018 15:05:20 +0000 (UTC) (envelope-from dim@FreeBSD.org) From: Dimitry Andric Message-Id: <196E84B3-B58F-4296-B6EA-84D0DE3230EF@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_C6226EC1-74CD-43E7-8E92-1E3CC610924A"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: error building clang in HEAD Date: Sat, 23 Jun 2018 17:05:16 +0200 In-Reply-To: <20180623154048.1b228df0@ernst.home> Cc: current@freebsd.org To: gljennjohn@gmail.com References: <20180623154048.1b228df0@ernst.home> X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 23 Jun 2018 15:05:22 -0000 --Apple-Mail=_C6226EC1-74CD-43E7-8E92-1E3CC610924A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 23 Jun 2018, at 15:40, Gary Jennejohn wrote: >=20 > There is a strange error building clang with this use case: >=20 > cd /usr/src > make -j10 makeworld What's the "makeworld" target? I've not heard of this. > which produces this error output: >=20 > =3D=3D=3D> lib/clang/libclang (all) > error: unable to rename temporary 'Sema/SemaTemplate-12ad7e30.o.tmp' = to output file 'Sema/SemaTemplate.o': 'No such file or directory' > 1 error generated. > --- Sema/SemaTemplate.o --- > *** [Sema/SemaTemplate.o] Error code 1 This typically happens if "make obj" was not run before the rest of the make targets. Normally, the order is: make obj, then make depend, then make (a.k.a. make all). Is there a directory /usr/obj/usr/src/lib/libclang/Sema ? > Note that this started happening after rm -rf /usr/obj/usr. Indeed, that caused the subdirectories under the obj directories to have disappeared. For some reason, in your situation, "make obj" is not run correctly. -Dimitry --Apple-Mail=_C6226EC1-74CD-43E7-8E92-1E3CC610924A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWy5hrAAKCRCwXqMKLiCW o5lsAJkBHIsO4k+ioZGa8FyVkQwzdCpSjQCgnXzIzHKj37RavLWhYl1LzvJfnNg= =2GWu -----END PGP SIGNATURE----- --Apple-Mail=_C6226EC1-74CD-43E7-8E92-1E3CC610924A-- From owner-freebsd-current@freebsd.org Sat Jun 23 15:19:49 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 931C41024923 for ; Sat, 23 Jun 2018 15:19:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.83]) (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 03EEE86576 for ; Sat, 23 Jun 2018 15:19:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: g5QO2qIVM1lXsAXUnmek.k8CCPqqaHe2xs5lg6ca2ix6yMytj1z3xSaO1DOsPvE t7Nk68jAYR1.gTFfhDphyq_qs93VuQtwFDKHvdhc8ONqktJcqI_FM2FuaQK54pRJu9sqE3otl1uU 6e1VDS7_VLR4WTeRvcxoJsDebD_e9lmBpSQNeItdLRGh.XLZbOIvI5c9DNLsK7OB7P_4oouevrUm .qpB7DHSPswigUtMlKPo_y5k.c1YUMg_l8y0o4in7XvESHIrx3te94bsaGsWpQww5a5b7Sy9aGYH xNEYM2F4FvIlwHWkLN9N1OuD.hPWoqUpTDXkPQOLdm8n0iThZab6Vkoi9VDO2M79H0fkVi753U1C .fZqbASV7tJKL7JLfLHAxQlgEh5TaX0f9hF9iR4jbrbcFUnZSpd9t2sZ4DyIeb8gGwKxi5sHh_5l jp96t4Xud1RwG0xRK5ozA0DFOrr6Rvdt35pfjWt3Blt3izbaW5q_BSlgqOaNV1.uS5jsG1Plo.p1 iTVuAlaFSoL4P5NDWwLQ5uEYxYjK0IDFsdCc2D8bkMjNHcUd._gcueH1zJ7E1YymTC4XenNh.gGo 2cQ6fYexs6VvjzlNF0iLlGU9nfwWGwwAQQJwqDVg41w3p9EWhhyd3GiKqo9eng_rIz1G96W5Sscb pAhxnA3GBikqgtNOUUaD57F2.OZq0SCIHqjXKP4C5xglVYsm5cFeKRAxvKp0F9BdhJdfkqEPLvYC IkgCDsC5O8FE6SXK5IKkuq99hSqz_5mVjvukLvBpIYZwhBQDwnWYcpxi7WpXzogVYC6VaknaVI_C Yc_4Ke67p8F0arR9dku0xCbx4XetMl7.Mu_vI1P72dul1HdSJbMEEpp_ALYPJkvOxnbWY8ZADdT8 IobVpIY8O3pVkYF8uwJ61ZMOrQCceKwv5S9x8aXRhuIlfrIqs8bI1GfnvcWSxXxtPz_gmwfUHZWh 4YMlpeCiOyh4KIsNrseM7e1b_IpXFLao- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sat, 23 Jun 2018 15:19:41 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp425.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 78469cd6d64744578320729e6c9a7477; Sat, 23 Jun 2018 15:19:39 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: error building clang in HEAD Message-Id: <31AA10B7-B1EC-4D10-932F-9BA03FF922C7@yahoo.com> Date: Sat, 23 Jun 2018 08:19:35 -0700 To: gljennjohn@gmail.com, FreeBSD Current X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 23 Jun 2018 15:19:49 -0000 Gary Jennejohn gljennjohn at gmail.com wrote on Sat Jun 23 13:41:00 UTC 2018 : > cd /usr/src > make -j10 makeworld >=20 > which produces this error output: >=20 > =3D=3D=3D> lib/clang/libclang (all) > error: unable to rename temporary 'Sema/SemaTemplate-12ad7e30.o.tmp' = to output file 'Sema/SemaTemplate.o': 'No such file or directory' > 1 error generated. > --- Sema/SemaTemplate.o --- > *** [Sema/SemaTemplate.o] Error code 1 What version of head ( -r?????? )? Is this an AMD Ryzen, AMD Ryzen Threadripper, or AMD Epyc context? If not, what is the alternative in use? Other details could be relevant as well. There was a time when there were various reports of such for Ryzen variants but the failure would not be on the same file each time and some builds would work. (I've seen such myself but likely will not have access to a Ryzen context again and it will likely be months for access to a Ryzen Threadripper. So I'm just suggesting additional information to report.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Sat Jun 23 17:10:29 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BA73910279EB for ; Sat, 23 Jun 2018 17:10:29 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 477CE8ABE4; Sat, 23 Jun 2018 17:10:29 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by mail-ua0-x229.google.com with SMTP id a5-v6so6192585uao.8; Sat, 23 Jun 2018 10:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=99q8mz+1Gb+qRJG8y4usGdfrjQPgQdwFDUpxqAl6ix8=; b=ACUw/XbbcUzwincVzYHmyVrh51rXHUAu7MIWkLQOWRtvNEg69tRJpYDv+chdl1ohJB pr2gk1u7jcN/H83jeAIXTqg8LIN7NIKSssF/y6KoczqCC0duECH7fbFX4cEgvMGOqjbX 0Or8SsHjbcwucZ7OS+jzA9q7aOfUatDiGtDDUaHLIChpu1vqK7ttYRoRbd+ylmpstTqj bjSemuvWjI4iDgpklUHs9GvigK1ZMSwNfIMFBOtZ29CSs42Vk2DKygsgOuXGFXITIrO9 d0DNSvGUxluctpKGkWJzE1LuiaUWVhbwBtyiZGDcdbY6WtiheiU8tSbPPxlyFeEr6ptL 3MpA== 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=99q8mz+1Gb+qRJG8y4usGdfrjQPgQdwFDUpxqAl6ix8=; b=mLqG08r5djYHr6Gti0q9RNnMOeIAxQWdVhAB397OuKbVs4PF3nVFchhjHu+Ayw9OTj yGmXbm2dVFQfVPZQYzEQSdtHEa3MT9U0CjS1qpvJoIkc8ldmOWxYlXdAdrDXZMaaylgj BZyEqzGCpqzs235iHGTYBZ5+FojzKACjmS++NzXLEMZbz8ywQ2fspcvsjR7Hpht/TJhu T7chi6wiQfCqHKBhSm0jQK0AtNbKgVBLQGWyC7DEDB+ee83DFlLq7359+On0PosgaDUx sHgMmsrSLWpoJLhwjr/CfEdp/1Mpa+H7JBEyDd3qV8Ug3wcArUopyb6p0vXYpCbdxrdG C3UA== X-Gm-Message-State: APt69E19rZbLhFmpBOaJymr7u83moW9wAl99DrSo6eCK4Lumd1lnCkmR 6vGUlS7RoyN7hoJOBmTiVEF6sY0qf5RxgHgAbP2/JfVR X-Google-Smtp-Source: ADUXVKL3DMZPfWVrWgv3zNHTACVvAk/vHp1JnRKaVzXrAGFaoQS+3xjRXB6Lzvyhrny7a20Kg/5GY4cz35Kxvy0OT0k= X-Received: by 2002:a9f:31eb:: with SMTP id w40-v6mr3979770uad.13.1529773828445; Sat, 23 Jun 2018 10:10:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:9:0:0:0:0:0 with HTTP; Sat, 23 Jun 2018 10:10:27 -0700 (PDT) In-Reply-To: References: From: Ben Woods Date: Sun, 24 Jun 2018 01:10:27 +0800 Message-ID: Subject: Re: Boot freezing after kernel load - root on zfs To: Warner Losh Cc: Allan Jude , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 23 Jun 2018 17:10:30 -0000 On 23 June 2018 at 12:37, Warner Losh wrote: > There were some issues with legacy geely booting recently. What version? > UEFI or legacy BIOS booting? > > Warner > Hi Warner, This was occurring with both my old and new beadm boot environments - r330554 and r334554. I am booting with legacy BIOS. Regards, Ben -- From: Benjamin Woods woodsb02@gmail.com From owner-freebsd-current@freebsd.org Sat Jun 23 17:13:31 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4F0AF1027C52 for ; Sat, 23 Jun 2018 17:13:31 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 CA5898B084; Sat, 23 Jun 2018 17:13:30 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by mail-ua0-x22f.google.com with SMTP id l11-v6so6192775uak.7; Sat, 23 Jun 2018 10:13:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4SCnDiFFY5SYSYTKk6Bs3SCFwwu6uQOhrw+vX1Nrzdw=; b=llrn06qsPTWB5c7yTOBHvpvpZNQC834FCOsEbgdZRVeldZSHl3ZvPRsizkrNUVVgJn G1uz1ipp4qKvlRHgzlqBDLwbCQFfIzsKbyzEMtvqzvslhVDMkVJJ5aV6OT82Qs5OKMoo Y8F+NaT89oftPd5LrJdKpjoQMsBWGghlioUgKgc7mpQYBExyszMDlMURkLtLmgnpHFub lwhaydDbTYmZWdeHT+zL9qGfd7BpU2Dd4GLzXlzOhbkUl7+NCv9+wOmXvDAu08zzHFos Sx/5eTOvQZXjDZtTsFdGy1rqbNuYCv/WVYq75cqqitvHiAevpTqTi4xnFJLb2/TrqbZx z+5g== 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=4SCnDiFFY5SYSYTKk6Bs3SCFwwu6uQOhrw+vX1Nrzdw=; b=XOTW/dA8MLu71OVKO3Mu2oI+dlCyWoXXjR9nHBsd+m5dOlDlnMh18itzoUaOalvRrY DYp8WN/h4d/GBBXKkNGXem9LACqhD8JsCvYiF6MBTG+l0FaLFr/mSIfRCKAfrNifNHg+ PpiHIbzFBoSAa5j2z0p62TnN9yMGfgPRCOz40UI7zbdShqhPxIYHuIsX60G0cW0tbvU+ r+C0de2W5cI4yWxxPo4jXW6b0Aos1aK+yE58EIR5ggmdIExG5B1olFILHqCHRRdPJS6C gEvmu93FRMy6HqP5Wx12kXJhAcSYp/4sJZmxIn+lizbNLbAr8E0HjXnJCSnUrCQiCzCN E/mw== X-Gm-Message-State: APt69E1WI1lyqoDewLl8QSdkupDSCndLjQBvPDNM1GdChZXFbuBCuIAr U8XCblO91mY5drBhvOZgePtB72EDO9UJIBd8/gFhb63c X-Google-Smtp-Source: ADUXVKL0B7F6MkJm0CSLtYPckGPfohHjnz/8lyNIa+ViSgb2g0Hn/SmLBnNvikd6mX6amY34nzYr0AVE5rdYu3YRCZo= X-Received: by 2002:ab0:1a23:: with SMTP id a35-v6mr3970102uai.47.1529774010333; Sat, 23 Jun 2018 10:13:30 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:9:0:0:0:0:0 with HTTP; Sat, 23 Jun 2018 10:13:29 -0700 (PDT) In-Reply-To: <3BCF59A2-308D-4A45-97EA-C25397F50C24@ixsystems.com> References: <85e188ff-a9db-3120-2709-1030640250e7@freebsd.org> <3BCF59A2-308D-4A45-97EA-C25397F50C24@ixsystems.com> From: Ben Woods Date: Sun, 24 Jun 2018 01:13:29 +0800 Message-ID: Subject: Re: Boot freezing after kernel load - root on zfs To: Joe Maloney Cc: Allan Jude , Warner Losh , FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 23 Jun 2018 17:13:31 -0000 On 23 June 2018 at 22:56, Joe Maloney wrote: > Ben, > do you by chance have multicons enabled with comconsole, vidconsole? Thi= s > looks exactly like a race we encountered where the remaining output was > actually being redirected to serial on some systems when multicons was > being used. It appeared to be a lockup when it wasn=E2=80=99t because ke= yboard > input would also break. > Hi Joe, Indeed, you are right - I have now fixed the problem! Thanks very much for your help! I was previously using a serial console to boot the machine, whereas now I have an IP KVM. The lines I commented out in my /boot/loader.conf to fix this were: boot_multicons=3D"YES" boot_serial=3D"YES" comconsole_speed=3D"115200" console=3D"comconsole,vidconsole" I would have thought that the boot should still complete regardless of whether the serial console is connected or not? Regards, Ben -- From: Benjamin Woods woodsb02@gmail.com From owner-freebsd-current@freebsd.org Sat Jun 23 19:18:29 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9ED3F10032CC for ; Sat, 23 Jun 2018 19:18:29 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 488AA8F3A4; Sat, 23 Jun 2018 19:18:29 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-it0-f50.google.com (mail-it0-f50.google.com [209.85.214.50]) (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)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id 0E0D11B436; Sat, 23 Jun 2018 19:18:29 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-it0-f50.google.com with SMTP id a195-v6so7196099itd.3; Sat, 23 Jun 2018 12:18:29 -0700 (PDT) X-Gm-Message-State: APt69E1jFIh9o6h9aTezB7y4AU8/Umhx23kbU5Fpv2n8RUIGFwjsieFg sL+M0Qsbf8xhC7SnWmIpueca6dkbPrkT7yxl5QA= X-Google-Smtp-Source: ADUXVKJsQUypYzLG1ivK5UzJdbDWosqG4qNZrwRixDZeUw0edJO2kHTwRHI9khZm/1L5ir9mTgY6lctMJEpIeL73+Zo= X-Received: by 2002:a02:2710:: with SMTP id g16-v6mr5213970jaa.98.1529781508502; Sat, 23 Jun 2018 12:18:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:8cd:0:0:0:0:0 with HTTP; Sat, 23 Jun 2018 12:18:28 -0700 (PDT) From: Matthew Macy Date: Sat, 23 Jun 2018 12:18:28 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: atomic_testandclear_, atomic_testandset_ To: freebsd-current , marius@freebsd.org, John Baldwin , Adrian Chadd Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 23 Jun 2018 19:18:29 -0000 The functions in the subject are both documented in atomic(9) and are implemented by every arch except sparc64 and MIPS. I have some code in review that uses them that I intend to commit once the various design issues are addressed. Please implement them so that those targets can remain part of universe. Thanks in advance. -M From owner-freebsd-current@freebsd.org Sat Jun 23 20:38:21 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7BF7010055E1 for ; Sat, 23 Jun 2018 20:38:21 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 26F3291E06; Sat, 23 Jun 2018 20:38:21 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-it0-f42.google.com (mail-it0-f42.google.com [209.85.214.42]) (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)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id E1AAF1BC6C; Sat, 23 Jun 2018 20:38:20 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-it0-f42.google.com with SMTP id m194-v6so7339422itg.2; Sat, 23 Jun 2018 13:38:20 -0700 (PDT) X-Gm-Message-State: APt69E2GU3bs+tjKj0Oww8ovWZ/YQXBZQiQdVse9yfUpCo+JWhsbMZ4E SBW3u7Okb2lVxpsoxpTAIhXDhun21PSWiE8HDeQ= X-Google-Smtp-Source: ADUXVKIA+hWSBoQd77qF3tNTSTaITC/ZJrcpohn1xlxp5aPq5i5vaga+TSYDbxgQsktUGBTrx2rMP9CeYD15OxJEfbw= X-Received: by 2002:a24:8ac1:: with SMTP id v184-v6mr2711140itd.7.1529786300463; Sat, 23 Jun 2018 13:38:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Matthew Macy Date: Sat, 23 Jun 2018 13:38:07 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: atomic_testandclear_, atomic_testandset_ To: Adrian Chadd , John Baldwin , "br@freebsd.org" , freebsd-current , marius@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 23 Jun 2018 20:38:21 -0000 It turns out ck already has equivalent primitives. Pardon the noise. -M On Sat, Jun 23, 2018 at 12:18 Matthew Macy wrote: > The functions in the subject are both documented in atomic(9) and are > implemented by every arch except sparc64 and MIPS. I have some code in > review that uses them that I intend to commit once the various design > issues are addressed. Please implement them so that those targets can > remain part of universe. > > Thanks in advance. > -M > From owner-freebsd-current@freebsd.org Sat Jun 23 21:03:05 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B010F1005ECA for ; Sat, 23 Jun 2018 21:03:05 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660054.outbound.protection.outlook.com [40.107.66.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT TLS CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 27E929287B; Sat, 23 Jun 2018 21:03:04 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR0101MB0959.CANPRD01.PROD.OUTLOOK.COM (52.132.34.15) by YTXPR0101MB0766.CANPRD01.PROD.OUTLOOK.COM (52.132.33.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.17; Sat, 23 Jun 2018 21:03:02 +0000 Received: from YTXPR0101MB0959.CANPRD01.PROD.OUTLOOK.COM ([fe80::2cbc:a2ff:df24:74ff]) by YTXPR0101MB0959.CANPRD01.PROD.OUTLOOK.COM ([fe80::2cbc:a2ff:df24:74ff%3]) with mapi id 15.20.0884.010; Sat, 23 Jun 2018 21:03:02 +0000 From: Rick Macklem To: "freebsd-current@freebsd.org" CC: "kib@FreeBSD.org" , Alexander Motin Subject: nfsd kernel threads won't die via SIGKILL Thread-Topic: nfsd kernel threads won't die via SIGKILL Thread-Index: AQHUCzMbOoi8yQKY7UygDXm1hs0B0A== Date: Sat, 23 Jun 2018 21:03:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTXPR0101MB0766; 7:HD8uF5d+AnLGkKs3LCwMKhOynb0xmt/kwwy7p8td1uQD1IhaKH/U32RLsDuNuJ19l6ib9pFPzFAbRwYn+CgtSCwv1F2uVy1ygj4jkHTCyPRQsy7VifXK2NRxJ9qlvzQu6x9FbgQySZIJBtFv2E36psve2LJAB91xtYhreKuKFtH8RRPrOIQxPQYF3N5AgwLUJghrAz96GrYclUlMSTF075KQWRJsdNfxqnSVRhD1/ASIpk8mgpWl2pQlh48NgHXx x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: f098fb2e-be29-4106-6ac3-08d5d94cb561 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:YTXPR0101MB0766; x-ms-traffictypediagnostic: YTXPR0101MB0766: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231254)(944501410)(52105095)(3002001)(93006095)(93001095)(149027)(150027)(6041310)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:YTXPR0101MB0766; BCL:0; PCL:0; RULEID:; SRVR:YTXPR0101MB0766; x-forefront-prvs: 07126E493C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(39860400002)(376002)(346002)(396003)(366004)(189003)(199004)(478600001)(2351001)(106356001)(105586002)(33656002)(74482002)(68736007)(5640700003)(54906003)(450100002)(55016002)(6436002)(99286004)(316002)(25786009)(9686003)(305945005)(786003)(5250100002)(486006)(2501003)(476003)(74316002)(4326008)(7696005)(59450400001)(186003)(97736004)(102836004)(6506007)(26005)(2900100001)(14454004)(3660700001)(3280700002)(6916009)(2906002)(53936002)(8936002)(8676002)(81156014)(5660300001)(86362001)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR0101MB0766; H:YTXPR0101MB0959.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-microsoft-antispam-message-info: df+t87GK+aSGkvcnc4y69WN4xUfbALVH3ZA6NI3RzMVf89vU7KbL3ZPM+C9A7ths2G3H9w0Is/n+idn9URgH/2EsOyS4vrYzMdFCr5SIK9HOUxUl6gkLtomRhzrEt87EyTVYKWM9UmNir90m59Ft4hqFgaMgnGiN3xDiXmTKW0AeIAwQNHAeG15UbJP6UoEDrjTkLsdo8ZwJO8xvPvKUPVHfN62vyzJYU5jX9muCwbsd3iAz6/hkMF9JAvLPkP7XiPHtJ60fpotjSS844uphnZws4+3Oi3JybTZBRlXVC5hyweg2sS8l3+KahqnsD5p/2o5OdxfQp8Vjn8UubV0Uj/K85u16/izPg/D8kDE+64Y= 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-Network-Message-Id: f098fb2e-be29-4106-6ac3-08d5d94cb561 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2018 21:03:02.6225 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR0101MB0766 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: 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, 23 Jun 2018 21:03:05 -0000 During testing of the pNFS server I have been frequently killing/restarting= the nfsd. Once in a while, the "slave" nfsd process doesn't terminate and a "ps axHl"= shows: 0 48889 1 0 20 0 5884 812 svcexit D - 0:00.01 nfsd: ser= ver=20 0 48889 1 0 40 0 5884 812 rpcsvc I - 0:00.00 nfsd: ser= ver=20 ... more of the same 0 48889 1 0 40 0 5884 812 rpcsvc I - 0:00.00 nfsd: ser= ver=20 0 48889 1 0 -8 0 5884 812 rpcsvc I - 1:51.78 nfsd: ser= ver=20 0 48889 1 0 -8 0 5884 812 rpcsvc I - 2:27.75 nfsd: ser= ver=20 You can see that the top thread (the one that was created with the process)= is stuck in "D" on "svcexit". The rest of the threads are still servicing NFS RPCs. If you still have an = NFS mount on the server, the mount continues to work and the CPU time for the last two t= hreads slowly climbs, due to NFS RPC activity. A SIGKILL was posted for the proces= s and these threads (created by kthread_add) are here, but the cv_wait_sig/cv_timedwait_sig never seems to return EINTR for these other th= reads. if (ismaster || (!ismaster && 1207 grp->sg_threadcount > grp->sg_minthreads)= ) 1208 error =3D cv_timedwait_sig(&st->st_co= nd, 1209 &grp->sg_lock, 5 * hz); 1210 else 1211 error =3D cv_wait_sig(&st->st_cond, 1212 &grp->sg_lock); The top thread (referred to in svc.c as "ismaster" did return from here wit= h EINTR and has now done an msleep() here, waiting for the other threads to termina= te. /* Waiting for threads to stop. */ 1387 for (g =3D 0; g < pool->sp_groupcount; g++) { 1388 grp =3D &pool->sp_groups[g]; 1389 mtx_lock(&grp->sg_lock); 1390 while (grp->sg_threadcount > 0) 1391 msleep(grp, &grp->sg_lock, 0, "svcexit", 0); 1392 mtx_unlock(&grp->sg_lock); 1393 } Although I can't be sure if this patch has fixed the problem because it hap= pens intermittently, I have not seen the problem since applying this patch: --- rpc/svc.c.sav 2018-06-21 22:52:11.623955000 -0400 +++ rpc/svc.c 2018-06-22 09:01:40.271803000 -0400 @@ -1388,7 +1388,7 @@ svc_run(SVCPOOL *pool) grp =3D &pool->sp_groups[g]; mtx_lock(&grp->sg_lock); while (grp->sg_threadcount > 0) - msleep(grp, &grp->sg_lock, 0, "svcexit", 0); + msleep(grp, &grp->sg_lock, 0, "svcexit", 1); mtx_unlock(&grp->sg_lock); } } As you can see, all it does is add a timeout to the msleep().=20 I am not familiar with the signal delivery code in sleepqeue, so it probabl= y isn't correct, but my theory is alonge the lines of... Since the msleep() doesn't have PCATCH, it does not set TDF_SINTR and if that happens before the other threads return EINTR from cv_wait_sig(= ), they no longer do so? And I thought that waking up from the msleep() via timeouts would maybe all= ow the other threads to return EINTR from cv_wait_sig()? Does this make sense? rick ps: I'll post if I see the problem again with the patch applied. pss: This is a single core i386 system, just in case that might affect this= .