From owner-freebsd-stable@freebsd.org Sun Oct 30 11:52:10 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9626EC146FE for ; Sun, 30 Oct 2016 11:52:10 +0000 (UTC) (envelope-from gothmog@confusticate.com) Received: from mail.confusticate.com (bree.confusticate.com [68.225.85.26]) by mx1.freebsd.org (Postfix) with ESMTP id 609CE1710 for ; Sun, 30 Oct 2016 11:52:09 +0000 (UTC) (envelope-from gothmog@confusticate.com) Received: from [IPv6:2600:380:1924:3c2a:c56b:7afc:155e:2832] (unknown [IPv6:2600:380:1924:3c2a:c56b:7afc:155e:2832]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.confusticate.com (Postfix) with ESMTPSA id 3056A315AD for ; Sun, 30 Oct 2016 07:52:02 -0400 (EDT) From: Jeremy Beker Content-Type: multipart/signed; boundary=Apple-Mail-2B53EFC2-3302-4FCB-A6F6-4CDFECE20F4D; protocol="application/pkcs7-signature"; micalg=sha1 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: FreeBSD 11.0 and LSI SAS3081E losing all devices Message-Id: X-Universally-Unique-Identifier: 68E0B9FD-D393-4FB7-8C90-92AC25CD3624 Date: Sun, 30 Oct 2016 07:52:00 -0400 To: freebsd-stable@freebsd.org X-Mailer: iPhone Mail (14B72c) X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,MIME_QP_LONG_LINE, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on bree.confusticate.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2016 11:52:10 -0000 --Apple-Mail-2B53EFC2-3302-4FCB-A6F6-4CDFECE20F4D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Good Morning! Since upgrading my home server from 10.3 to 11.0-RELEASE-p1 about a week ago= , I have twice had a serious problem where my LSI adapter is having errors a= nd dropping all the drives out of my ZFS pool. Hardware: - LSI SAS3081E-R PCI-E card with the IT firmware loaded=20 - 6x2TB WD Black drives - 1 SSD - Supermicro X10SLL-F MB (not sure that is relevant)=20 This system has been running with this exact hardware for about a year with n= o problems under the 10.X versions of FreeBSD. Last weekend, I upgraded the s= ystem to 11.0-RELEASE-p1. Since then, twice, all of the drives have been mar= ked as unavailable to ZFS after generating a stream of errors. The problems start with a number of errors like this: Oct 26 03:28:29 rivendell kernel: mpt0: request 0xfffffe0000f73058:57643 tim= ed out for ccb 0xfffff803456ea000 (req->ccb 0xfffff803456ea000)=20 Oct 26 03:28:29 rivendell kernel: mpt0: attempting to abort req 0xfffffe0000= f73058:57643 function 0=20 Oct 26 03:28:29 rivendell kernel: mpt0: completing timedout/aborted req 0xff= fffe0000f73058:57643=20 Oct 26 03:28:29 rivendell kernel: (da0:mpt0:0:10:0): READ(10). CDB: 28 00 04= c4 91 c0 00 00 08 00=20 Oct 26 03:28:29 rivendell kernel: (da0:mpt0:0:10:0): CAM status: CCB request= terminated by the host=20 Oct 26 03:28:29 rivendell kernel: (da0:mpt0:0:10:0): mpt0: Retrying command=20= Oct 26 03:28:29 rivendell kernel: abort of req 0xfffffe0000f73058:0 complete= d=20 Oct 26 03:28:49 rivendell kernel: mpt0: request 0xfffffe0000f6c3b0:57658 tim= ed out for ccb 0xfffff803456ea000 (req->ccb 0xfffff803456ea000)=20 Oct 26 03:28:49 rivendell kernel: mpt0: attempting to abort req 0xfffffe0000= f6c3b0:57658 function 0=20 Oct 26 03:28:49 rivendell kernel: mpt0: completing timedout/aborted req 0xff= fffe0000f6c3b0:57658=20 Oct 26 03:28:49 rivendell kernel: (da0:mpt0:0:10:0): READ(10). CDB: 28 00 04= c4 91 c0 00 00 08 00=20 Oct 26 03:28:49 rivendell kernel: (da0:mpt0:0:10:0): CAM status: CCB request= terminated by the host=20 Oct 26 03:28:49 rivendell kernel: (da0:mpt0:0:10:0): Retrying command=20 Oct 26 03:28:49 rivendell kernel: mpt0: abort of req 0xfffffe0000f6c3b0:0 co= mpleted=20 Oct 26 03:28:51 rivendell kernel: (da0:mpt0:0:10:0): READ(10). CDB: 28 00 04= c4 91 c0 00 00 08 00=20 Oct 26 03:28:51 rivendell kernel: (da0:mpt0:0:10:0): CAM status: SCSI Status= Error=20 Oct 26 03:28:51 rivendell kernel: (da0:mpt0:0:10:0): SCSI status: Check Cond= ition=20 Oct 26 03:28:51 rivendell kernel: (da0:mpt0:0:10:0): SCSI sense: UNIT ATTENT= ION asc:29,0 (Power on, reset, or bus device reset occurred)=20 Oct 26 03:28:51 rivendell kernel: (da0:mpt0:0:10:0): Retrying command (per s= ense data)=20 Also these: Oct 26 03:29:55 rivendell kernel: (da1:mpt0:0:14:0): SYNCHRONIZE CACHE(10). C= DB: 35 00 00 00 00 00 00 00 00 00 Oct 26 03:29:55 rivendell kernel: (da1:mpt0:0:14:0): CAM status: SCSI Status= Error Oct 26 03:29:55 rivendell kernel: (da1:mpt0:0:14:0): SCSI status: Check Cond= ition Oct 26 03:29:55 rivendell kernel: (da1:mpt0:0:14:0): SCSI sense: UNIT ATTENT= ION asc:29,0 (Power on, reset, or bus device reset occurred) Oct 26 03:29:55 rivendell kernel: (da1:mpt0:0:14:0): Error 6, Retries exhaus= ted Oct 26 03:29:55 rivendell kernel: (da1:mpt0:0:14:0): Invalidating pack After a bunch of rounds of the errors above, I get this: Oct 26 03:35:17 rivendell kernel: mpt0: request 0xfffffe0000f73350:62027 tim= ed out for ccb 0xfffff800160ce000 (req->ccb 0xfffff800160ce000) Oct 26 03:35:17 rivendell kernel: mpt0: attempting to abort req 0xfffffe0000= f73350:62027 function 0 Oct 26 03:35:18 rivendell kernel: mpt0: mpt_wait_req(1) timed out Oct 26 03:35:18 rivendell kernel: mpt0: mpt_recover_commands: abort timed-ou= t. Resetting controller Oct 26 03:35:18 rivendell kernel: mpt0: mpt_cam_event: 0x0 Oct 26 03:35:18 rivendell kernel: mpt0: mpt_cam_event: 0x0 Oct 26 03:35:18 rivendell kernel: mpt0: completing timedout/aborted req 0xff= fffe0000f73350:62027 After which all the drives seem to disappear and the system detaches all of t= hem: Oct 26 03:35:33 rivendell kernel: da1 at mpt0 bus 0 scbus0 target 14 lun 0 Oct 26 03:35:33 rivendell kernel: da1: s/n WD-WM= AY01559141 detached Oct 26 03:35:33 rivendell kernel: da2 at mpt0 bus 0 scbus0 target 15 lun 0 Oct 26 03:35:33 rivendell kernel: da2: s/n WD-WM= AY01603430 detached Oct 26 03:35:33 rivendell kernel: da5 at mpt0 bus 0 scbus0 target 18 lun 0 Oct 26 03:35:33 rivendell kernel: da5: s/n WD-WM= AY01159727 detached Oct 26 03:35:33 rivendell kernel: da6 at mpt0 bus 0 scbus0 target 19 lun 0 Oct 26 03:35:33 rivendell kernel: da6: s/n WD-WM= AY02971691 detached Oct 26 03:35:33 rivendell kernel: da4 at mpt0 bus 0 scbus0 target 17 lun 0 Oct 26 03:35:33 rivendell kernel: da4: s/n WD-WM= AY01470856 detached Oct 26 03:35:33 rivendell kernel: da3 at mpt0 bus 0 scbus0 target 16 lun 0 Oct 26 03:35:33 rivendell kernel: da3: s/n WD-WM= AY01602648 detached At this point I have had to reboot the server and then all the drives magica= lly reappear. Any help would be greatly appreciated. -Jeremy --=20 Jeremy Beker - @gothmog=20 http://www.confusticate.com Condensing fact from the vapor of nuance. --Apple-Mail-2B53EFC2-3302-4FCB-A6F6-4CDFECE20F4D Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFDDCCBQgw ggPwoAMCAQICED7waKcRDjPZchDYp4xW7X0wDQYJKoZIhvcNAQELBQAwdTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTAeFw0xNjAzMjcx MjA0MjVaFw0xNzAzMjcxMjA0MjVaMEwxITAfBgNVBAMMGGdvdGhtb2dAY29uZnVzdGljYXRlLmNv bTEnMCUGCSqGSIb3DQEJARYYZ290aG1vZ0Bjb25mdXN0aWNhdGUuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA3RoESoAhdajTxi3KVNa8fnM9blHxqbylwHh9bDQ3A+w5xguZlOxg pLAJSczpLVGRilU/e6UlRzgXCaRhEFIv6rb5czqxqq+Aktvus9uY99Q+vCU/LbnutPeF/X0Hr01E ff+Ts+wVBVjnj1vuvW1x/lSzTGKCVsuYhvOb5ULXTTp/OLpRJhprpZXJCmJ+6LQftykLBR/fhyL9 jIEPAxa7JV64VkYk/qANeX29j36y1W8+J5CV2egwrrXpOnIOsY15K00eHIoNcRiXJnR0LfDST8eT dUVQWjBA5gzbTGs96hlS2EQ3Dz3jSZc2CsdM5k8rgzkdBXwzpvz6kbWNE8Q5ywIDAQABo4IBuzCC AbcwDgYDVR0PAQH/BAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRME AjAAMB0GA1UdDgQWBBRaB+bmgn7KdjjHK5ZnNUVBAuycKzAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3 G0YrySi1J0htaDBvBggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0 c3NsLmNvbTA5BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNs aWVudDEuY3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1j bGllbnQxLmNybDAjBgNVHREEHDAagRhnb3RobW9nQGNvbmZ1c3RpY2F0ZS5jb20wIwYDVR0SBBww GoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAq BggrBgEFBQcCARYeaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUA A4IBAQACW4t9PdRYwzKMfSdGBlBhkcd+OAF8lHT3Jh/FYgRVrkkPvEh7SIPa7wPKuzwf9hFjhxPE zyG264lW1WNyMbD3Hl4Djwu8tXPNjW1nxXO3iRIA9acqpvivp8SCIWoO5AigAm8G6KEIQS3rYPV+ q28YEziMoRGvb+seEBQCYANxRtEVTaQfYA3iOezKiYmftC+EXT/J3AqerQD7v9+kyloZ62OhHgof yAvXeVY7sK8BmG1h9LDPQgxDVwW1JRQJmw6WHVu2twj3W+DTTmEjZM9F8XqNvScaZvPhSx7ZIkvU bNo7rK5O+05825BkqJwgrwuhXS7utuBA3Gr6UYz9fdxQMYIDTjCCA0oCAQEwgYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQPvBo pxEOM9lyENinjFbtfTAJBgUrDgMCGgUAoIIBmTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNjEwMzAxMTUyMDBaMCMGCSqGSIb3DQEJBDEWBBSH6mGTBhkIJiCjdV4B R0iw7DsviTCBmgYJKwYBBAGCNxAEMYGMMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEG A1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0ECED7waKcRDjPZchDYp4xW7X0wgZwGCyqG SIb3DQEJEAILMYGMoIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkw JwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRD b20gQ2xhc3MgMSBDbGllbnQgQ0ECED7waKcRDjPZchDYp4xW7X0wDQYJKoZIhvcNAQEBBQAEggEA QLiXvIFR/yC9YcHSVYv/D7u30LomvtnQ6f3NrFzbsFF2nrUKMtAl+pxQ+YShol+sPHQ2hfdRt8fZ qE/bddHO8hCgziBTkFTMPqQm4EZGN2bDtKGeOHTJlP3/af0b0nzYHHGaznIVJHE9eWQvoX12153V ljsBw8DO7N0VvlgaAJwd4uSsEwc+eSJbdaqzRrZta6iPgq+znz+4e2ulzr7al+uRUcbVIeuotMJQ 8yfxdbwdL37Uyb+jEwh+Ld+O/jjJv7GmkhFuV2FTtOjyU2y/j/3zkibXYzghWcge64yBcUOFsgbr 21Hk+tRYkmDILO8qj6r2tEQUicX+9RzkXNcK0AAAAAAAAA== --Apple-Mail-2B53EFC2-3302-4FCB-A6F6-4CDFECE20F4D-- From owner-freebsd-stable@freebsd.org Sun Oct 30 16:32:47 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC4DAC2624A for ; Sun, 30 Oct 2016 16:32:47 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E5D0A1532; Sun, 30 Oct 2016 16:32:46 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id u9UGWhcd035758; Sun, 30 Oct 2016 17:32:44 +0100 (CET) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 9F863DA7; Sun, 30 Oct 2016 17:32:43 +0100 (CET) Message-ID: <581620AB.3050203@omnilan.de> Date: Sun, 30 Oct 2016 17:32:43 +0100 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org CC: Alexander Motin Subject: bhyve(8) passthru affects ahci-hd with device backend [Was: Re: Unexpected ahci-hd bytes when running in bhyve(8)] References: <58124200.5080306@omnilan.de> <5814C101.90805@omnilan.de> <5814DDDC.60104@omnilan.de> In-Reply-To: <5814DDDC.60104@omnilan.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Sun, 30 Oct 2016 17:32:44 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2016 16:32:47 -0000 Bez=C3=BCglich Harry Schmalzbauer's Nachricht vom 29.10.2016 19:35 (loca= ltime): > Bez=C3=BCglich Harry Schmalzbauer's Nachricht vom 29.10.2016 17:32 (lo= caltime): > > =E2=80=A6 >> Like mentioned, while reading the first 448 bytes on the host, I get >> identical results from /usr/local/guest.img and /dev/ada4, but when >> attaching /dev/ada4 to ahci-hd (-s 7,ahci-hd,/dev/ada4) and inspecting= >> inside vmm, all I see is 0x0, while ahci-hd attached >> /usr/local/guest.img shows the same pmbr as on the host!? >> >> Do I have to exclude /dev/ada4 on the host from geom? As soon as bhyve= >> opens /dev/ada4, all partitions vanish from the host =E2=80=93 probabl= y ada4 >> itself gets blocked somehow? =E2=80=A6 > Just another symptom I can only describe, not debug: > Opening /dev/adaX on the host works by 'hd /dev/ada4 | less', > but not inside the guest, where it just leads to endless IO when trying= > the same on the ahci-hd attached /dev/ada4 The described defects only happen when passthru is used with bhyve(8)!!! If I simply don't attach the passthru-device (keeping memory wired), everything works the way it's supposed to do. Opening the guest-ada1-device with hexdump works, geom tastes GPT and the first 448 bytes show exactly the pMBR like on the host. As soon as I start the guest with the passthru device (doesn't matter which slot, tested with a 82574L), the ahci-hd can't be read nymore, just returning 0x0 when dumped. Shall I file a bug report? Anybody aware of that or any idea where to start fixing? To summarize: FreeBSD-11-RELEASE hosting a bhyve(8) guest with a physical device as storage backend (regardless if accessed through virtio-blk or ahci-hd) corrupts guest-disk access if there's also a passthrough device attached.= If you use a file-backed ahci-hd (or virtio-blk) device, the problem doesn't show up, regardelss if there's passthru involved or not. Thanks, -Harry From owner-freebsd-stable@freebsd.org Sun Oct 30 18:21:02 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C741FC270FF for ; Sun, 30 Oct 2016 18:21:02 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id B249310EA for ; Sun, 30 Oct 2016 18:21:02 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id B1AD0C270FD; Sun, 30 Oct 2016 18:21:02 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B15CCC270FC for ; Sun, 30 Oct 2016 18:21:02 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6A25A10E9 for ; Sun, 30 Oct 2016 18:21:01 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id u9UIL0cg005116 for ; Sun, 30 Oct 2016 18:21:00 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id u9UIKxQQ005115 for stable@freebsd.org; Sun, 30 Oct 2016 11:20:59 -0700 (PDT) (envelope-from david) Date: Sun, 30 Oct 2016 11:20:59 -0700 From: David Wolfskill To: stable@freebsd.org Subject: (Circumvented) insta-panic from "pkg upgrade" stable/11 @r308090 Message-ID: <20161030182059.GC1203@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2JFBq9zoW8cOFH7v" Content-Disposition: inline User-Agent: Mutt/1.7.1 (2016-10-04) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2016 18:21:02 -0000 --2JFBq9zoW8cOFH7v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Summary: I've worked around this -- at least, for now -- but a process I've been using every Sunday since July 2015 on a pair of machines suddenly failed this morning (on just one of the machines). For background, (if you're interested): * * * So... this morning, the update from: FreeBSD albert.catwhisker.org 11.0-STABLE FreeBSD 11.0-STABLE #95 r307797M= /307819:1100505: Sun Oct 23 03:52:44 PDT 2016 root@freebeast.catwhisker= =2Eorg:/common/S1/obj/usr/src/sys/ALBERT amd64 to: FreeBSD albert.catwhisker.org 11.0-STABLE FreeBSD 11.0-STABLE #102 r308090= M/308101:1100506: Sun Oct 30 04:09:05 PDT 2016 root@freebeast.catwhiske= r.org:/common/S1/obj/usr/src/sys/ALBERT amd64 Just Worked -- as usual. I rebooted both "production" machines, logged in, fired up tmux on each, rotated my typescript files, then fired up script and ran the csh command alias I use on both machines to update the installed ports (from the locally-built packages that reside on my build machine; the production machines access them via NFS). For one of the machines ("bats"), things Just Worked (again). For the other ("albert"), I lost contact. Eventually (after I actually got up and went to the room where the machines are), I found that it had rebooted. Further experimentation showed that in the command sequence: mount -u -w / && \ mount -u -w /usr && \ ( cd /etc/mail && make stop-mta ) && \ service dovecot stop && \ service apache24 stop && \ pkg upgrade it got through "service apache24 stop" OK, but when I issued "pkg upgrade" -- the screen blanked, and the machine started rebooting. On reboot, the /var file system (UFS2+soft updates) showed the typescript files from before the above efforts -- not even the "rotation" (mentioned above) was reflected. (The typescript files in question reside in /var/tmp on the machine.) Oh: and the initial "fsck -p" for /var indicated that fsck needed to be re-run (so when I booted to single-user mode, I did just that). There was no hint in the logs of why the reboot (panic?) occurred. One point that may be at issue is that for bats (where things still worked), I manually mount the package repository from the build machine to bats:/mnt, while for albert (where things failed), I have depended on autofs to handle the mounting as needed (since I need albert to run autofs anyway, and bats does not). E.g.: bats(11.0-S)[1] cat /usr/local/etc/pkg/repos/custom.conf=20 custom: { # url: file:///net/freebeast/tank/poudriere/poudriere/data/packages= /11amd64-ports-home url: file:///mnt enabled: yes, } bats(11.0-S)[2]=20 vs.: albert(11.0-S)[10] cat /usr/local/etc/pkg/repos/custom.conf=20 custom: { url: file:///net/freebeast/tank/poudriere/poudriere/data/packages/1= 1amd64-ports-home enabled: yes, } albert(11.0-S)[11]=20 In the process of finally(!) getting albert's "pkg upgrade" working, I did 2 things differently: * I did not run under tmux. I can't imagine that this contributed, but I cite it for completeness. * Prior to invoking "pkg upgrade", I issued "ls /net/freebeast/tank/poudriere/poudriere/data/packages/11amd64-ports-h= ome" (and got a sane result), so the mount was satisfied prior to "pkg upgrade" being run. I note, too, that one of the times I logged in to albert, the login seemed to "hang" for a while. When I hit ^T (several times), it was apparent that the process was trying to use autofs to mount my home directory (from the FreeNAS box, "grundoon")... and that effort timed out -- I ended up with the whine about inability to find my home directory. And then when I logged out & back in again, /net/grundoon/mnt/tank/homedirs showed up 3 times in the output of "df". So perhaps there's something involving autofs and timing... though that doesn't seem like much to go on. Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who would murder in the name of God or prophet are blasphemous coward= s. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --2JFBq9zoW8cOFH7v Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJYFjoLXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XpU8IALzqVsKL/AS6xorrdJXkAnOg bYkfojiz+0Qs/5klBdaOlX3PZJ5nXhq6s40dZuZxIJlCOuhoCfxPJytWudIWiC1z WjEGRi15CW6wk+d3G7+jISf9BlQoWMj2/8cK8Q220o9BJoo7qQby2LiqHIt/xCLC 6RyBQrR9LGkTXYg02NVwqw9xYgTuXLmGrM6lZXRx9+Rei+Va2AMBueOvfXwZ/9b9 25VETGXYEWEj7fH6eDObKs7SpCw1Toc7lC21uWhRRhSCoru85Xm09vV50oOLdq8l fFBmfMrjqxWs+XcQz4dZP3wNTv9G7rlNRGj43n1n41j827Gy8gmql3DbVfZGEw8= =wGhZ -----END PGP SIGNATURE----- --2JFBq9zoW8cOFH7v-- From owner-freebsd-stable@freebsd.org Mon Oct 31 08:40:57 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5F88C2831F for ; Mon, 31 Oct 2016 08:40:57 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 7F129181C for ; Mon, 31 Oct 2016 08:40:56 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id E893C28416; Mon, 31 Oct 2016 09:40:47 +0100 (CET) Received: from illbsd.quip.test (ip-86-49-16-209.net.upcbroadband.cz [86.49.16.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id EA48228411; Mon, 31 Oct 2016 09:40:46 +0100 (CET) Subject: Re: Dying jail To: Peter , freebsd-stable@FreeBSD.ORG References: <581064BB.1030500@rdtc.ru> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <5817038E.3010300@quip.cz> Date: Mon, 31 Oct 2016 09:40:46 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 08:40:57 -0000 Peter wrote on 2016/10/28 14:28: > Eugene Grosbein wrote: >> Hi! >> >> Recently I've upgraded one of my server running 9.3-STABLE with jail >> containing 4.11-STABLE system. >> The host was source-upgraded upto 10.3-STABLE first and next to >> 11.0-STABLE >> and jail configuration migrated to /etc/jail.conf. The jail kept intact. >> >> "service jail start" started the jail successfully >> but "service jail restart" fails due to jail being stuck in "dying" >> state for long time: >> "jls" shows no running jails and "jls -d" shows the dying jail. > > Same issue here. During upgrade to 10 I wrote a proper jail.conf, > and, as this is now a much more transparent handling, I also began to > start+stop my jails individually w/o reboot. > I found the same issue: often jails do not want to fully terminate, but > stay in the "dying" state - sometimes for a minute or so, but sometimes > very long (indefinite). > > It seems this is not related to remaining processes or open files (there > are none) but to network connections/sockets which are still present. > Probably these connections can be displayed with netstat, and probably > netstat -x shows some decreasing counters associated with them - I have > not yet found the opportunity to figure out what they exactly mean, but > anyway it seems like there may be long times involved (hours? forever?), > unless one finds the proper connection and terminates both ends. > > There seems to be no other way to deliberately "kill" such connections > and thereby terminate the jail, so the proposal to let it have a new > number might be the only feasible approach. (I dont like it, I got used > to the numbers of my jails.) I am no sure where but I think it was discussed in jail@ mailing list that keeping the same JID is not recommended. Or recycling freed JID. It was few years ago when I talked about this with BZ. Miroslav Lachman From owner-freebsd-stable@freebsd.org Mon Oct 31 08:49:45 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63297C2873C for ; Mon, 31 Oct 2016 08:49:45 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003: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 2A3321C48 for ; Mon, 31 Oct 2016 08:49:45 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: by mail-oi0-x229.google.com with SMTP id v84so56479702oie.3 for ; Mon, 31 Oct 2016 01:49:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=qiYugK8oVNICRByEKNmNv/2OZDLb/6iTwRilaM3cZjA=; b=YHJgfE9ZMySSSdNaBToufe1gUBFx91i+aKzslugqtQkn1GNPAw5DRaVDCnCYs/YT/R +QVakYFgFw+4ztb53VhEV1Fa4y2viT+jIFH3GS9wGIKM2PgyILTetSK2L8dR+PpkdI5T xYaZ0pAKZTTYREv/IIR58xxXn/ZeKa3Hr779ooJ7zQBo/XYEe595Mfq6bQMN3EnTTWhk /YXCF09HQaR1mblNDoceR74EzCtLEA+q3oFeQply+ypRy9rmKC5+Bq0ohww35wGPcySF spJN9BQNhI42PgHvriCz3FWQpL1vyeAduZXy65sc3svDJkkydMysRgaC4WG14NVDGauC hYxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=qiYugK8oVNICRByEKNmNv/2OZDLb/6iTwRilaM3cZjA=; b=brz6Qj+LKKICjn+fGB0hVWiI521SXMnGRAmrqXHIDaN9IYtOfoIFkhj2ETGW+7mYk9 Ch+ks0VyUoeFmNMuSaZEtcPr1PuBFGLrX4oYMIFEw+IhsHpp2B4DXmMhLMS4NhndoJjd XJ5UcCuhXdJJMXiAvimQPaCeutYPwFcxUzVKWfx5fzvijA66XAtXSzFoRiUHXds0E2jY MS8Ve23W+gszdFyco1koWgbRrPzehu1+6z/nFiLU8+h4SLrMmeiKagtZvpwQ2UYAjvNp MpdWjHzFi+KtczT8YMxPwqlyNUE6DdXCqv2m+UC7NwHsY74TfWzdM0e+UlCu77Qn6Aj9 Hicg== X-Gm-Message-State: ABUngvenHLHr/i/om4Z3WZ2wxwgy6w/P6jcEuwGbFpzkQdD+A198qNXY+JPFSkWjxPK159YnLK51EOCIDcgK1A== X-Received: by 10.36.211.207 with SMTP id n198mr7734817itg.28.1477903784313; Mon, 31 Oct 2016 01:49:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.127.88 with HTTP; Mon, 31 Oct 2016 01:49:43 -0700 (PDT) From: Aryeh Friedman Date: Mon, 31 Oct 2016 04:49:43 -0400 Message-ID: Subject: NFS Client can't reconnect (RPC timeout) after reboot To: FreeBSD Stable List Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 08:49:45 -0000 I get a RPC time out when I attempt to reboot a 11-STABLE (1st uname) NFS client attempting to connect to a 11-STABLE NFS server (2nd uname): (Note: NIS continues to work w/ "server" being the NIS server also note rebooting the server clears it but restarting rpcbind/nfsd/mountd does not) FreeBSD lilith 11.0-STABLE FreeBSD 11.0-STABLE #7 r308121: Mon Oct 31 02:58:37 EDT 2016 root@lilith:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD server 11.0-STABLE FreeBSD 11.0-STABLE #0 r308000: Thu Oct 27 09:47:19 EDT 2016 aryeh@server2:/data/usr.obj/data/usr.src/sys/GENERIC amd64 Server /etc/rc.conf: hostname="server" ifconfig_vtnet0="inet 10.0.10.254 netmask 255.255.255.0" defaultrouter="10.0.10.1" sshd_enable="YES" # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable dumpdev="AUTO" named_enable="YES" rpcbind_enable="YES" nfs_server_enable="YES" mountd_flags="-r" nisdomainname="office" nis_server_enable="YES" nis_yppasswdd_enable="YES" lockd_enable="YES" statd_enable="YES" Server /etc/exports: /usr/local/com -maproot=root -network 10.0.10/24 /data/home /data/usr.src /data/ports -maproot=root -network 10.0.10/24 Client /etc/rc.conf: hostname="lilith" ifconfig_re0="inet 10.0.10.20 netmask 255.255.255.0" defaultrouter="10.0.10.1" sshd_enable="YES" # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable dumpdev="AUTO" nisdomainname="office" nis_client_enable="YES" tomcat7_enable="YES" cupsd_enable="YES" autofs_enable="YES" lockd_enable="YES" statd_enable="YES" -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org From owner-freebsd-stable@freebsd.org Mon Oct 31 09:09:47 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 829E8C27277 for ; Mon, 31 Oct 2016 09:09:47 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 547701928 for ; Mon, 31 Oct 2016 09:09:47 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: by mail-yw0-x235.google.com with SMTP id w3so129057689ywg.1 for ; Mon, 31 Oct 2016 02:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=xfyGad9xJcP+i+T5YJxiLFmd+fSulP8nsunBtC4amCU=; b=z+3dT5EOGZc8YTSGQTb9t2HOV/CJ//Jo9LkAkXlm4uDUI8yszThjQvEluSzVrf2ApL Wcw8Z8WODwE20Ptfv/UvreKH23PkDxi3sms2T1yHjF2W0lEDt03W9z4EzAEK7B0P93cV KDDxSf4rn7VP8LsZ2VN1NFCxmjz2OSgOIvgAkqBrD48Dzj/wAwd7CTM7zv0fl8B3fpr0 dcSbvaNveccD85My6+oR2g62JjMEpEEQjL39JizZcwjD6Z1Mzcgip4fTrJNgWU8xVzos ZeUKHYj9RAbGPZ6sjCM/Ds43afSsg2gCZiBmX1FLnBbyedHEOLMEz/K2L/K1jHR/3q8G I13Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xfyGad9xJcP+i+T5YJxiLFmd+fSulP8nsunBtC4amCU=; b=MTgMwCOd7WL9V12jMyI4Ea4mCEuqq3fIkHxNTuRH2qCFpFpzXhuBxLKGOESOsOrSax 7nQUKsrHgjAJdKu8agVRynUm1hNE0m8+UKsSOxfiHdq4f1f77knyaxbYmeZm73yfVtJO EKXjKxIfvozd2sec9fnbPa/KcrJ3WNge/noJ5ndn9LSHl0CB7UgnmL4EhLMiyPrftroY +ppMHwOUcCAuufRcHjfYQcuS+xB6GvZOdC02DQ+41vqljgGD2l2iOGswdObClBlNPMXP pdg7TdaJ/8qp4ge8KhIihMLNF+Q5H9OZ8vTDy8Susn9RGPxMA1mP7dyU7ODFpfY+YtWx u7XQ== X-Gm-Message-State: ABUngvcpdH1zO/umKG0405i1vQiuocjm2YRUIsr0gIKGu6mM04Jec0ahoyFDmNtFlyBWjvhEAYUoXrTMjptJPw== X-Received: by 10.36.27.68 with SMTP id 65mr6970657its.21.1477904986376; Mon, 31 Oct 2016 02:09:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.127.88 with HTTP; Mon, 31 Oct 2016 02:09:46 -0700 (PDT) From: Aryeh Friedman Date: Mon, 31 Oct 2016 05:09:46 -0400 Message-ID: Subject: USB keyboard (wired) caps-lock takes for ever on 11-STABLE To: FreeBSD Stable List Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 09:09:47 -0000 After I did a wipe/reinstall going from 10.3 to 11 the same machine/keyboard has gone from instantly registering the pressing of caps-lock to causing a 2-3 second pause in keyboard i/o when pressing it (on or off). -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org From owner-freebsd-stable@freebsd.org Mon Oct 31 15:53:22 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2A73AC2810E for ; Mon, 31 Oct 2016 15:53:22 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8C9C61A46 for ; Mon, 31 Oct 2016 15:53:21 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id u9VFrHdD061978 for ; Tue, 1 Nov 2016 02:53:17 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 1 Nov 2016 02:53:17 +1100 (EST) From: Ian Smith To: freebsd-stable@freebsd.org Subject: 1MB swap partition on 11.0 memstick Message-ID: <20161101025012.Q41537@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 15:53:22 -0000 Tried in -questions but no takers .. root@x200:~ # mdconfig -lv md0 vnode 700M /home/smithi/FreeBSD-11.0-RELEASE-amd64-memstick.img root@x200:~ # gpart show -p md0 => 3 1433741 md0 GPT (700M) 3 1600 md0p1 efi (800k) 1603 125 md0p2 freebsd-boot (62k) 1728 1429968 md0p3 freebsd-ufs (698M) 1431696 2048 md0p4 freebsd-swap (1.0M) What is the 1.0M swap partition for? Is it needed by bsdinstall? I have an MBR-scheme sliced memstick using boot0 with that md0p3 dd'd to da0s2a which boots fine, but have only run it as 'Live CD' and have not run the installer, but am wondering if a) that swap partition is really needed and if so, b) what can usefully be done with 1MB of swap .. cheers, Ian From owner-freebsd-stable@freebsd.org Mon Oct 31 17:21:15 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2835C288A3 for ; Mon, 31 Oct 2016 17:21:15 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 230DB1FAD for ; Mon, 31 Oct 2016 17:21:12 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by mail-wm0-x234.google.com with SMTP id n67so241816033wme.1; Mon, 31 Oct 2016 10:21:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=eaVyc169ogcHJfEc1gVsyIhjbVZFQmNkkT7MBp9jHaI=; b=i6RMmesK36YuI2piUbRDWHuhz14i6pMBPp7BjEMtK2KnDDipKt04o7Cfw3YM0yJeRZ QyV6kif/+nu/5HTVYpMDL97BYUXuQ3HYj09DaDLKj5Mf3JB3vQuXWT545k+MXBkTzkyM cJnmYlvCZ36UAp7WCnbpo3ktefTzv6TRZpvRdgNyVDtirY3PWi3a3lFctCBB4w/KMPna yRPhEAClSkbl++SMSAfSKButKkxE0ywJzJ2NU4E8ynGurhLFKRLf8yDb0gL9IkG2pf61 1U9MIW1Gug5tfutBZjlO5XTPOL0VJD4VJDpqWOxaUVe8R5vLbpByXYj/CPpecjSUP4fR fB/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=eaVyc169ogcHJfEc1gVsyIhjbVZFQmNkkT7MBp9jHaI=; b=aQOX8FpTvfAox8dZNOUYAEv1m1dL9qQSI4OUBE2Zy9a5MSHj7l+ZwivUslINQ2WKRG 9+R9PShlEGkc1svVhsjJOy0+bTCdVYYBu5zrdG38xsOxdWNuwS8cLzjF+NpzRGRU6rBl FVVcBUj0MqLpqI7hD/f9jtEibNXPj0wz6lsPJsLBhLQllJuYDR9/hNbLOCn1OPeGfOMz k/xpiu5YU3ikm/VAHWoWyiCoh2WYKrzGFyYFX58QwnFCID3ra7GnYfXBG92H9aUUWc0C /28jNfx1zx585i2dsFRzjLasT+BaD3NEK3e01jFgj9ya/XW+RXkR8dh5sU0dMbmBCA2w cXPQ== X-Gm-Message-State: ABUngvfdzquUhdegY70nwZ6AJXovDVrqFjYzXsnd18T2QVld6nJdBOxivXUb1AMBu38sbA== X-Received: by 10.194.115.135 with SMTP id jo7mr23251290wjb.21.1477934470639; Mon, 31 Oct 2016 10:21:10 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id af4sm31029088wjc.17.2016.10.31.10.21.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Oct 2016 10:21:09 -0700 (PDT) Sender: Baptiste Daroussin Date: Mon, 31 Oct 2016 18:21:06 +0100 From: Baptiste Daroussin To: Eugene Grosbein Cc: FreeBSD Stable , jails@FreeBSD.org Subject: Re: Dying jail Message-ID: <20161031172106.tzzazowea6uspyzl@ivaldir.etoilebsd.net> References: <581064BB.1030500@rdtc.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="o64p67o46vbr2lx5" Content-Disposition: inline In-Reply-To: <581064BB.1030500@rdtc.ru> User-Agent: NeoMutt/20161014 (1.7.1) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 17:21:15 -0000 --o64p67o46vbr2lx5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 26, 2016 at 03:09:31PM +0700, Eugene Grosbein wrote: > Hi! >=20 > Recently I've upgraded one of my server running 9.3-STABLE with jail cont= aining 4.11-STABLE system. > The host was source-upgraded upto 10.3-STABLE first and next to 11.0-STAB= LE > and jail configuration migrated to /etc/jail.conf. The jail kept intact. >=20 > "service jail start" started the jail successfully > but "service jail restart" fails due to jail being stuck in "dying" state= for long time: > "jls" shows no running jails and "jls -d" shows the dying jail. >=20 > How do I know why is it stuck and how to forcebly kill it without reboot = of the host? >=20 I have the same problem on a FreeBSD 11.0 I have no specific jail.conf for exec.start is directly calls service cassandra onestart and stop calls the stop of the very same service. jail -f /myconf -r nameofthejail I can see the jail staying in dying mode for multiple minutes even after sockstat -j has been showing no TCP is left at all. No processes are left in the jail I'm mostly clueless on how to debug that and know that the dying jail is wa= iting on. It is painful as it prevents from exporting the zfs pool the jail was sitti= ng on. Any one has ideas? Best regards, Bapt --o64p67o46vbr2lx5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYF31/AAoJEGOJi9zxtz5anpgP/iFPUF6kwjuk6T7phlDlu6Ve 6ORw4zPj38c+hk0o4iOwJOP0GnDd8exK+vcfICMV5HYcUDfuU01p91qcdB9FU4UF vXtZDHoOXrZ+BcmfH2AkVehmZkNzMt65mnQAP8XsAMUigdFUKcx05Nvyl81Y4/3l WtqgJtwLrml4e9+q26n5KYl58IoKHtxo0w3pCB1BwdPNcE1j6Ek4/cR1f8iOHd4I GeCVood13qzRZ3o1t9KY+hBxBXFSCT2eoSOdB7r/RgqkepmD0cP0sL9uMC++eH+z NBUmtVcCSHwlwz03U7/tWIz0M8uDQqXOHP0iX+vxFscZQxM/y3+7EYywqTf6i1TC lr4ph43APaE/czuJhZBXLm5Rqmhn2M0HN/2lJyCnHdyzdvfUwZKWTPMRbmzlvuAY vOyLqcAeJIK0rZN0pocxU5ZOrKHuN1x6VWlA9prfGTatCf7lABKNkKsBc8BsuYyO nP/BDnRsv/rQM5N+4Re2KfLMHjbgP3RLbkFlFtQfxQpoHVkWaKjhVgv0Ab/dV7k8 CeaZ0q23xx3V6EFtHA8RztJ1I61HFuhCMUmeE15RwLQ4/8KjzA2A7uRDxbsZTFYz I7xCSRgDjM+y0Qlt2ZotTNlvxOHdH1oWY0/MiPn+eIpVynMneTseFiMuJv61EUao NENFoRk8CA/y8VFonHZk =Kzdj -----END PGP SIGNATURE----- --o64p67o46vbr2lx5-- From owner-freebsd-stable@freebsd.org Tue Nov 1 05:56:40 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7A55C2A158 for ; Tue, 1 Nov 2016 05:56:40 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4393A1FB3; Tue, 1 Nov 2016 05:56:36 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221]) by hz.grosbein.net (8.14.9/8.14.9) with ESMTP id uA15uRt6048841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Nov 2016 06:56:27 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: bapt@FreeBSD.org Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id uA15uN7n013626 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 1 Nov 2016 12:56:23 +0700 (KRAT) (envelope-from eugen@grosbein.net) Subject: Re: Dying jail To: Baptiste Daroussin References: <581064BB.1030500@rdtc.ru> <20161031172106.tzzazowea6uspyzl@ivaldir.etoilebsd.net> Cc: FreeBSD Stable , jails@FreeBSD.org From: Eugene Grosbein Message-ID: <58182E82.1090303@grosbein.net> Date: Tue, 1 Nov 2016 12:56:18 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20161031172106.tzzazowea6uspyzl@ivaldir.etoilebsd.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM autolearn=no version=3.3.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hz.grosbein.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 05:56:40 -0000 01.11.2016 0:21, Baptiste Daroussin wrote: > I can see the jail staying in dying mode for multiple minutes > even after sockstat -j has been showing no TCP is left at all. > > No processes are left in the jail Same here, but not for multuple minutes but multiple days: my dying jail without a process cannot die 6 days already. It was restarted with another JID 6 days ago and its new instance runs just fine but old still dying. This is definitely a regression since 9.3-STABLE that ran "service jail restart" just fine even using fixed JID. From owner-freebsd-stable@freebsd.org Tue Nov 1 17:44:49 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AAAEDC29A83 for ; Tue, 1 Nov 2016 17:44:49 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CCAE11D8 for ; Tue, 1 Nov 2016 17:44:49 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id uA1Hil1U068094 for ; Tue, 1 Nov 2016 18:44:47 +0100 (CET) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 70367250; Tue, 1 Nov 2016 18:44:47 +0100 (CET) Message-ID: <5818D48E.8070205@omnilan.de> Date: Tue, 01 Nov 2016 18:44:46 +0100 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: pax(1) needs to learn POSIX-pax format (by libarchive(3)?) Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Tue, 01 Nov 2016 18:44:47 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 17:44:49 -0000 Dear hackers, I'm frequently missing pax(1) ability to handle the pax (the POSIX pax) format. Backing up real-world file names and lengths doesn't work with ustar format - which pax(1) uses and also tar(1) by default. I'd prefer using pax(1) because of it's cli usage – personal taste… But in practice, I'm forced to use tar(1), overriding tar's default format with the "--format pax" (or --posix) option, for almost any archive/backup job (where zfs send isn't feasible). Since tar(1) does support the POSIX pax format, it's not a big issue, but weird using tar for pax and pax for tar ;-) I'd love pax(1) beeing libarchive(3)ed. Has anyone ever thought about? Unfortunately I'm lacking skills and time :-( Thanks, -harry From owner-freebsd-stable@freebsd.org Tue Nov 1 20:51:57 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 537DFC2AD35 for ; Tue, 1 Nov 2016 20:51:57 +0000 (UTC) (envelope-from jason.harmening@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 EEADD15C7 for ; Tue, 1 Nov 2016 20:51:56 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: by mail-pf0-x22b.google.com with SMTP id 189so47405740pfz.3 for ; Tue, 01 Nov 2016 13:51:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version; bh=fgt9gwKI4lRGZ59iknJK/ZCung5Q7EsInscS+5Eb2Z0=; b=eky6sd8drPCFQLVfx4fAiS3Tiel/IY6hNK5MG7sTg9u41wTV0kDmODA1EoF+OSbQ2X RTn6Ba2RQQVukOC7Gz8cvqFiIiMLT5F0uadqW/k9eCOXYJvWeqtbNYj1cTUaQ5namcri rabbeJQnD5WiqbFCKxKmBFR8viJ5mFE8GzDddO5BLltZATas+3WDQiYYIT7g1ltA1+7g iNOjjUnbKUs7egz2E5tbG0fDRFb5YGLR32kaNtF/VBpkoLe8HVcLHxFgsDitCTwFTYMv nXejMw3lR/4Omc5rV+eylyKpmkh4lsWY2PZIyDjudFLHpKIqgC7ZvYLeS6dnm2A3dtjS rCFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=fgt9gwKI4lRGZ59iknJK/ZCung5Q7EsInscS+5Eb2Z0=; b=lu5DonhHE55dbba+noZ5mFjrAPIfEqQyV20VNzOIjn1+2QzgjWCzEtE0CVcJeLGpS9 SiyIV4jjZysRPYtqNcjUonZxYxvZDFGSWHafNOWFESJDLGOgPFwMuz6bioZcBBF72mO5 g34Nl5bSiDR+KsLvjoO4pI3QsrAU64a/XTdoUX1/BgVTdGkwXlUX2VWSxvquFZTVvRh2 +w57yUzXy5CEE4j213YxMoJ/Pk85r6v7ettZMEI+FXlknTcrOrKbiyWxrliudJlYLspR rS3XBbq7f5rrmJiggkP4yU8NjLtuwML4ebp8ZwZ+O2oD8eBSsBO3RoGPbTyuHJx5JoO0 nJJw== X-Gm-Message-State: ABUngvf9W4Q608nbrB3lHzkT0wyWYsXBeuCPlgnnZSU5rKQRLvY7BsxgZH4toq3shcODsQ== X-Received: by 10.99.98.2 with SMTP id w2mr51979951pgb.59.1478033516045; Tue, 01 Nov 2016 13:51:56 -0700 (PDT) Received: from corona.austin.rr.com (c-67-188-30-11.hsd1.ca.comcast.net. [67.188.30.11]) by smtp.googlemail.com with ESMTPSA id w15sm44123693pfi.55.2016.11.01.13.51.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Nov 2016 13:51:54 -0700 (PDT) To: freebsd-stable@freebsd.org From: Jason Harmening Subject: huge nanosleep variance on 11-stable Message-ID: Date: Tue, 1 Nov 2016 13:58:53 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="A38r7Uo4OBWvgQ5M9aqooXw4kV9U9CR9I" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 20:51:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --A38r7Uo4OBWvgQ5M9aqooXw4kV9U9CR9I Content-Type: multipart/mixed; boundary="LsAW7xxhbRV5jXDkQ8W8EX2K92PL5wtT6"; protected-headers="v1" From: Jason Harmening To: freebsd-stable@freebsd.org Message-ID: Subject: huge nanosleep variance on 11-stable --LsAW7xxhbRV5jXDkQ8W8EX2K92PL5wtT6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi everyone, I recently upgraded my main amd64 server from 10.3-stable (r302011) to 11.0-stable (r308099). It went smoothly except for one big issue: certain applications (but not the system as a whole) respond very sluggishly, and video playback of any kind is extremely choppy. The system is under very light load, and I see no evidence of abnormal interrupt latency or interrupt load. More interestingly, if I place the system under full load (~0.0% idle) the problem *disappears* and playback/responsiveness are smooth and quick. Running ktrace on some of the affected apps points me at the problem: huge variance in the amount of time spent in the nanosleep system call. A sleep of, say, 5ms might take anywhere from 5ms to ~500ms from entry to return of the syscall. OTOH, anything CPU-bound or that waits on condvars or I/O interrupts seems to work fine, so this doesn't seem to be an issue with overall system latency. I can repro this with a simple program that just does a 3ms usleep in a tight loop (i.e. roughly the amount of time a video player would sleep between frames @ 30fps). At light load ktrace will show the huge nanosleep variance; under heavy load every nanosleep will complete in almost exactly 3ms. FWIW, I don't see this on -current, although right now all my -current images are VMs on different HW so that might not mean anything. I'm not aware of any recent timer- or scheduler- specific changes, so I'm wondering if perhaps the recent IPI or taskqueue changes might be somehow to blame. I'm not especially familiar w/ the relevant parts of the kernel, so any guidance on where I should focus my debugging efforts would be much appreciated. Thanks, Jason --LsAW7xxhbRV5jXDkQ8W8EX2K92PL5wtT6-- --A38r7Uo4OBWvgQ5M9aqooXw4kV9U9CR9I Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJYGQIOXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRENkY3MTQyREU0MTU4MTgyRkZDNUU2ODVC QjlGOEJGOTkyODQxRDFCAAoJELufi/mShB0bmzQH/jmKuVxn4Ug1TvlyWv38ThsS j0xDqygjghN5FT1HtOm8VXr+y67rXrPbfwcJrpBsaizUl3MHhGp9xaYdkcrH34Nt XfL1EtRjSMghf2pmAP1uiiOS4XWuQ9M2r4R0Kd0k9raftKfkn/DfDf/IQQ94i/ah FCzL/Bd9f2KaDzADc8sO0iZpSHIyCBB9uXKFXvWka3ahXaXg0drzBLnv1FJHl2N/ TYueOUlr0wYe6kygo7n4JJ2vA4uZP7lM9Z881j7zIlcGAkap9hcYqWYyflamCikY px4JfNtzXUgarhEIHevYrBnN31ulQSkIzqyPG5kV9B702R1J/mxuwvej3Kp8a4k= =E/vK -----END PGP SIGNATURE----- --A38r7Uo4OBWvgQ5M9aqooXw4kV9U9CR9I-- From owner-freebsd-stable@freebsd.org Tue Nov 1 21:22:16 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 88E3AC2A8AF for ; Tue, 1 Nov 2016 21:22:16 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 F3FD51D05 for ; Tue, 1 Nov 2016 21:22:15 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: by mail-pf0-x230.google.com with SMTP id i88so7728993pfk.2 for ; Tue, 01 Nov 2016 14:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=mfls6sD3IUyKlPAkGE+i+kcxnIzjmKf62+sPEKoKjGQ=; b=gqhE9yGtkl7QPfxBXbfY66aQSIRYaQpb7FZX9phOzlwm2pD+OU6j5sstVTBDQYRjyS PDIIuShL/kBo7MbvPz7I0Kro1Cfrw507S2voTY84wFOjYIN8DtbxqMrNhzuhz59FvaCi ENlFmjM8h9SRu+h0QqunaPbAnlX+gCMhWaHTg+JzMPP/CNsR7ipdW77xG0Lvl1qyOaew +7t9UOgfUjL+S2bNo0KRT4OC/krIeviLVPV9SrmcieqNJzot5bOwnZBN3wSmT2Bz8tAZ kDIM9Zb6K7lu5PYIMZ4+rQ2bmVOLizj5xzz5ZVeksTGXZVuPGVvlZ9v/IFKoWMTNjZL5 1R+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=mfls6sD3IUyKlPAkGE+i+kcxnIzjmKf62+sPEKoKjGQ=; b=WnHEL+yGI05sZZCWGpfX2P/4jSILw/vj94ao0Za0JxuncSJ3zYnNIyk8iHBsnSjMCs a7UnWLsSXlzlERyPsevjdxGxhQZ4TlpskEq/PsoNjlQMxubW30qyXh+JWofpvy2ENOTt DExG5VTalbexK0rS64eclTf2IY9aEQ9g2cK2hffH9zODt+S+B7O+xVcV0Y1zYaahiw3+ gwHoAvq/SkX/B/QCzfFFF5VTv8TAVLKtM7bhKQbRzIPesLViHux0WpD5reS+bH4+z+4w DLHHgCdbFvnWlvW3OBsczY4BkMnDk0qg7DtQxRkEPANu6mUUMVdr+c4kcNt420aVYinB Ha4g== X-Gm-Message-State: ABUngve8uH90gWyHGKEgya24uIEJGcoKH1WIN5atCPkTYtNWBUP7Funx+L8bjJf9Ukl5Tw== X-Received: by 10.98.160.29 with SMTP id r29mr95029pfe.103.1478035335082; Tue, 01 Nov 2016 14:22:15 -0700 (PDT) Received: from corona.austin.rr.com (c-67-188-30-11.hsd1.ca.comcast.net. [67.188.30.11]) by smtp.googlemail.com with ESMTPSA id xk6sm44337566pab.26.2016.11.01.14.22.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Nov 2016 14:22:14 -0700 (PDT) Subject: Re: huge nanosleep variance on 11-stable To: freebsd-stable@freebsd.org References: From: Jason Harmening Message-ID: <6167392c-c37a-6e39-aa22-ca45435d6088@gmail.com> Date: Tue, 1 Nov 2016 14:29:13 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HDJ66P9oeeKbWwFf87EVABbhlNgJwSWjQ" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 21:22:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HDJ66P9oeeKbWwFf87EVABbhlNgJwSWjQ Content-Type: multipart/mixed; boundary="CwVNp2n6VHORNLW5VDPT3ugoQViEouw1S"; protected-headers="v1" From: Jason Harmening To: freebsd-stable@freebsd.org Message-ID: <6167392c-c37a-6e39-aa22-ca45435d6088@gmail.com> Subject: Re: huge nanosleep variance on 11-stable References: In-Reply-To: --CwVNp2n6VHORNLW5VDPT3ugoQViEouw1S Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable repro code is at http://pastebin.com/B68N4AFY if anyone's interested. On 11/01/16 13:58, Jason Harmening wrote: > Hi everyone, >=20 > I recently upgraded my main amd64 server from 10.3-stable (r302011) to > 11.0-stable (r308099). It went smoothly except for one big issue: > certain applications (but not the system as a whole) respond very > sluggishly, and video playback of any kind is extremely choppy. >=20 > The system is under very light load, and I see no evidence of abnormal > interrupt latency or interrupt load. More interestingly, if I place th= e > system under full load (~0.0% idle) the problem *disappears* and > playback/responsiveness are smooth and quick. >=20 > Running ktrace on some of the affected apps points me at the problem: > huge variance in the amount of time spent in the nanosleep system call.= > A sleep of, say, 5ms might take anywhere from 5ms to ~500ms from entry > to return of the syscall. OTOH, anything CPU-bound or that waits on > condvars or I/O interrupts seems to work fine, so this doesn't seem to > be an issue with overall system latency. >=20 > I can repro this with a simple program that just does a 3ms usleep in a= > tight loop (i.e. roughly the amount of time a video player would sleep > between frames @ 30fps). At light load ktrace will show the huge > nanosleep variance; under heavy load every nanosleep will complete in > almost exactly 3ms. >=20 > FWIW, I don't see this on -current, although right now all my -current > images are VMs on different HW so that might not mean anything. I'm no= t > aware of any recent timer- or scheduler- specific changes, so I'm > wondering if perhaps the recent IPI or taskqueue changes might be > somehow to blame. >=20 > I'm not especially familiar w/ the relevant parts of the kernel, so any= > guidance on where I should focus my debugging efforts would be much > appreciated. >=20 > Thanks, > Jason >=20 --CwVNp2n6VHORNLW5VDPT3ugoQViEouw1S-- --HDJ66P9oeeKbWwFf87EVABbhlNgJwSWjQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJYGQkpXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRENkY3MTQyREU0MTU4MTgyRkZDNUU2ODVC QjlGOEJGOTkyODQxRDFCAAoJELufi/mShB0bC1sH/3wywXoqkh+fmPZZL8D3TZlc L5jH7AOdQyy7AB+KDhEeJqxalA/yGulquLC9gqaDLDheKjEJf7SCCzgsZ/s9lzh0 cC705ux+kUkGOhHAtOG+r0OVMmw1PMPJrlkg67OC9qUVKs2sG45BVinl5fB0CJWG J7VfkI3471mnozkLUrwpox/R5g2mjPOI/f8XzXLxyiYz9Fuc+jFNREoqdCPv5aco VhHY7Pg2Wif11A77LrG+C/5l5EjUcATgBlKhhj1FLe47UPlUucy25k9Fk71zqrKJ SEx6aiSUX8xY7VjNi5mjv7YlYUTRJIxaFUGEMqRUYwFvmihdOOUpGCiDMQOis0M= =Y9p7 -----END PGP SIGNATURE----- --HDJ66P9oeeKbWwFf87EVABbhlNgJwSWjQ-- From owner-freebsd-stable@freebsd.org Tue Nov 1 21:29:18 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E1BDCC2AB3A for ; Tue, 1 Nov 2016 21:29:18 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::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 553111C85 for ; Tue, 1 Nov 2016 21:29:18 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: by mail-pf0-x233.google.com with SMTP id i88so7814915pfk.2 for ; Tue, 01 Nov 2016 14:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=JIb1m1Y56ATF8VNY/9+w+JlgHW5kapr2ZzSLFL8jaAs=; b=WdZQvDZCYw8rmbAtqI9dCAoLp2rTLzVu5GiWra8jCOVa9R/CKkV1FgB6+iaGJnaSa7 oVbh4GqrF6OH7jOdB8eiZmREaOFlKU7XDbFsBFMjytNPfZlhVglobrx2JN7LRRnyNxde yQUrp3VhS1DaZxWwF7N/kVGI4CpCIISq1J861io/UBnzkTzmmMALtotdOkJ7kCdvjimd OvUeFdxWnURYr3RXNG49nKzn3tARKnZTXuvu2HAql1YE/55B4QVyKlsXq99Uk1CzER2x udmsYwQ2MSUpqfyNfagJ+7lpNehprhwN+fQa4jFOyP26yNXC4ITHzlTS9EMql+sEEabI e1AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=JIb1m1Y56ATF8VNY/9+w+JlgHW5kapr2ZzSLFL8jaAs=; b=QhUMiM0hYTtofH/QhpMgsXDyqDdy8AO5OF4rrb9DuXumDNpKoak04TloVgeIUTCgF+ 0T7+t0SzgbYVKkofo/K/JTWptkWnznRWeL/ioUIwBE4/FWuaYJzx6yiaIsWQd8RmHP0z 4c/fJb4JRIfklL6tJA2ZG7NK9DOPe7Q5Jvm3Qell6HW4RkdO5VcQKHcMmp98E7wFCaFH vmcJ4GT0FHLvMOmO+JJ+Jis+dVkIY/9AxXlQFdx/zaAFQTt7rqhZXI96lR24WaIR6nRI GQr9BxAcwtdEj0kNxcEoaWJWpJER2oSCI1dXQtTJkrZw3W2V3cPuBMug0EXkgJ6ZhiZr 4NIw== X-Gm-Message-State: ABUngveRsFJovbpRFnf/kJg1WNQlUi4uSfkF2Eb2NjrIGH6IoPW0f6j8TohVYLgxPZB31g== X-Received: by 10.99.117.71 with SMTP id f7mr146795pgn.61.1478035757412; Tue, 01 Nov 2016 14:29:17 -0700 (PDT) Received: from corona.austin.rr.com (c-67-188-30-11.hsd1.ca.comcast.net. [67.188.30.11]) by smtp.googlemail.com with ESMTPSA id k67sm20922415pfj.47.2016.11.01.14.29.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Nov 2016 14:29:16 -0700 (PDT) Subject: Re: huge nanosleep variance on 11-stable To: freebsd-stable@freebsd.org References: <6167392c-c37a-6e39-aa22-ca45435d6088@gmail.com> From: Jason Harmening Message-ID: <1c3f4599-8aef-471a-3a39-49d913f1a4e5@gmail.com> Date: Tue, 1 Nov 2016 14:36:16 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <6167392c-c37a-6e39-aa22-ca45435d6088@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FeuPRo8Cg75vjqIn3oKdVcFOPkLFb2xpo" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 21:29:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FeuPRo8Cg75vjqIn3oKdVcFOPkLFb2xpo Content-Type: multipart/mixed; boundary="mwOsF42V3L8V2Klv3dae7EWcGXsbMLrLM"; protected-headers="v1" From: Jason Harmening To: freebsd-stable@freebsd.org Message-ID: <1c3f4599-8aef-471a-3a39-49d913f1a4e5@gmail.com> Subject: Re: huge nanosleep variance on 11-stable References: <6167392c-c37a-6e39-aa22-ca45435d6088@gmail.com> In-Reply-To: <6167392c-c37a-6e39-aa22-ca45435d6088@gmail.com> --mwOsF42V3L8V2Klv3dae7EWcGXsbMLrLM Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sorry, that should be ~*30ms* to get 30fps, though the variance is still up to 500ms for me either way. On 11/01/16 14:29, Jason Harmening wrote: > repro code is at http://pastebin.com/B68N4AFY if anyone's interested. >=20 > On 11/01/16 13:58, Jason Harmening wrote: >> Hi everyone, >> >> I recently upgraded my main amd64 server from 10.3-stable (r302011) to= >> 11.0-stable (r308099). It went smoothly except for one big issue: >> certain applications (but not the system as a whole) respond very >> sluggishly, and video playback of any kind is extremely choppy. >> >> The system is under very light load, and I see no evidence of abnormal= >> interrupt latency or interrupt load. More interestingly, if I place t= he >> system under full load (~0.0% idle) the problem *disappears* and >> playback/responsiveness are smooth and quick. >> >> Running ktrace on some of the affected apps points me at the problem: >> huge variance in the amount of time spent in the nanosleep system call= =2E >> A sleep of, say, 5ms might take anywhere from 5ms to ~500ms from entry= >> to return of the syscall. OTOH, anything CPU-bound or that waits on >> condvars or I/O interrupts seems to work fine, so this doesn't seem to= >> be an issue with overall system latency. >> >> I can repro this with a simple program that just does a 3ms usleep in = a >> tight loop (i.e. roughly the amount of time a video player would sleep= >> between frames @ 30fps). At light load ktrace will show the huge >> nanosleep variance; under heavy load every nanosleep will complete in >> almost exactly 3ms. >> >> FWIW, I don't see this on -current, although right now all my -current= >> images are VMs on different HW so that might not mean anything. I'm n= ot >> aware of any recent timer- or scheduler- specific changes, so I'm >> wondering if perhaps the recent IPI or taskqueue changes might be >> somehow to blame. >> >> I'm not especially familiar w/ the relevant parts of the kernel, so an= y >> guidance on where I should focus my debugging efforts would be much >> appreciated. >> >> Thanks, >> Jason >> >=20 --mwOsF42V3L8V2Klv3dae7EWcGXsbMLrLM-- --FeuPRo8Cg75vjqIn3oKdVcFOPkLFb2xpo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJYGQrQXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRENkY3MTQyREU0MTU4MTgyRkZDNUU2ODVC QjlGOEJGOTkyODQxRDFCAAoJELufi/mShB0bIVIIAJWGV1HTR4Q3MjmSKYRmpOd9 VwdriZdNHlP+R6SvjPdxhG2JsAvQsOUvg7UZEu7Or08/JM/SMQOuFL+pXGwHcqE2 e0tl5IDMQHr6JrLweyBiI+td8FuPxqHMDFWm1rsUg6YUkWCEfNYu30vp0Lpuvy6v wn80K0vdBqiLRW60gZsA9KVwt/4TK7VCdgDY/6IajrGLzsxhPcvdGTZA+6QkGf5r WIJfHzXwSm+h4a2hHzpRRSRh2RjalDmgF1yUtuxTmV/NOsuI8SpcT+11zos2jlN6 XmtLcDtgboY8h9rAVQMBibyzsCatQ5fmv443B/TEcgG5DSGfKGjMVXyW4Fqrcew= =z3t/ -----END PGP SIGNATURE----- --FeuPRo8Cg75vjqIn3oKdVcFOPkLFb2xpo-- From owner-freebsd-stable@freebsd.org Tue Nov 1 23:09:10 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75BBCC2A365 for ; Tue, 1 Nov 2016 23:09:10 +0000 (UTC) (envelope-from eddyraz.fl@gmail.com) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::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 09E491351 for ; Tue, 1 Nov 2016 23:09:10 +0000 (UTC) (envelope-from eddyraz.fl@gmail.com) Received: by mail-it0-x243.google.com with SMTP id f129so179661itc.2 for ; Tue, 01 Nov 2016 16:09:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=yVRfpmlUB2/uRn6Gt7KLChG0bgSnVrvYNeA1WfXUsXI=; b=Mpop4Dr2XqVpKGWWT0uHYKY5pANrVZo9Cprf4sXzlJ5EqYeUfdrvs5A3408Wj1xfMM 9NVW83vNq7o1t/U9qITkfsQhqrWrzxqwpeXwlDmrtUAABWSN0vDPmZyFkafkL0WTLRF/ t5aEXnjaOVsEuuzGDRkddcIu16cQRDtRCqn80Bw5nHlhnBUFLzmRiyo+CdRbDFR2mZZZ JM3ewFeDKV+TViBIkOR+S6kwN+BPoDfSOL3e8RSIl7AYdAa1R21hsmNi6GBBOlgqncpt DAlgILcrnkwqpQRYeqfLlbFJ8hNIJ5P9fGD4dZ66KLG4liDsVn7hJd5HHn1DTQMcBqNE 8Jpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=yVRfpmlUB2/uRn6Gt7KLChG0bgSnVrvYNeA1WfXUsXI=; b=OaVph4iIx7ZGM5Q21RUwklGxRo8cz+wjqYa8miDWxAmDsW39TXesHmTcTVahxwJv9u WYq83h9Z3p4hqhmu/xfCIpbMnSS61zTHi949q2Hyepa1kLFMYIg7X7UTk8IRKa/rb2UA 0uLKS3lgQBBP5dYpIjcRF6broq7WHCKbl5jrulPXPvE2gQ33vkf4jVUGoQqUbhvSF89S azfj/JBziO5OdRr1lDqPln66RZpDr67I6ABRb/4KPxmIXO7Pq9jbG02znzjJ5Y09M5nI qOHiToZCx5ktP3b2W79a9lQp+Tkb3jNdonno8qZyIMzSXy4tlOr7Q2WXStQ6I5Mou6si jbKA== X-Gm-Message-State: ABUngve32fV+OKPS3ieIddKeBAi3OBEbhu5n/oZop+z8O2yY1Pb9jZ7+S75ep5DY9DevBw== X-Received: by 10.107.31.78 with SMTP id f75mr1129235iof.141.1478041749104; Tue, 01 Nov 2016 16:09:09 -0700 (PDT) Received: from [172.19.164.177] ([200.55.166.34]) by smtp.gmail.com with ESMTPSA id p196sm440760iod.16.2016.11.01.16.09.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Nov 2016 16:09:08 -0700 (PDT) To: freebsd-stable@freebsd.org From: eddyraz Subject: Problems with jail inside ZFS dataset Message-ID: <425a02f7-035a-8c26-8ed2-7f32be6d3373@gmail.com> Date: Tue, 1 Nov 2016 19:05:21 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 23:09:10 -0000 Good Afternoon., I have A VPS with FreeBSD in a dedicated server with OVH Hosting. Last week I installed FreeBSD 11, Ran buildworld after that Crea\ ted a VM within a jail in /local/jails/ ZFS dataset While trying to start the VM gave an error that said it could not mount nullfs. I added this in /boot/loader.conf nullfs_mount=1 later the error changed to: Starting jails: cannot start jail "haproxy": mount: .: Operation not supported by device jail: haproxy: /sbin/mount -t fdescfs . /local/jails/haproxy/dev/fd: failed Following this post in Internet https://lists.freebsd.org/pipermail/freebsd-stable/2014-August/079700.html I ran the patch that they advised to. and I found in http://pastebin.com/5t9zEzkV but while aplying the patch with patch /sys/fs/fdescfs/fdesc_vfsops.c sys_fs_fdescfs_fdesc_vfsop gives this error. ****************************************************************************************************** Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/sys/fs/fdescfs/fdesc_vfsops.c b/sys/fs/fdescfs/fdesc_vfsops.c |index cb5e3c0..7193809 100644 |--- a/sys/fs/fdescfs/fdesc_vfsops.c |+++ b/sys/fs/fdescfs/fdesc_vfsops.c -------------------------- Patching file /sys/fs/fdescfs/fdesc_vfsops.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] y Hunk #1 succeeded at 51 (offset 1 line). Hunk #2 failed at 79. No such line 241 in input file, ignoring Hunk #3 succeeded at 229 (offset -8 lines). 1 out of 3 hunks failed--saving rejects to /sys/fs/fdescfs/fdesc_vfsops.c.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/sys/kern/kern_jail.c b/sys/kern/kern_jail.c |index 2846eca..791723d 100644 |--- a/sys/kern/kern_jail.c |+++ b/sys/kern/kern_jail.c -------------------------- File to patch: /sys/kern/kern_jail.c Patching file /sys/kern/kern_jail.c using Plan A... Hunk #1 failed at 207. Hunk #2 failed at 224. Hunk #3 failed at 4247. Hunk #4 failed at 4403. 4 out of 4 hunks failed--saving rejects to /sys/kern/kern_jail.c.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was: |diff --git a/sys/sys/jail.h b/sys/sys/jail.h |index a82a499..a01d665 100644 |--- a/sys/sys/jail.h |+++ b/sys/sys/jail.h -------------------------- File to patch: /sys/sys/jail.h Patching file /sys/sys/jail.h using Plan A... Hunk #1 failed at 228. 1 out of 1 hunks failed--saving rejects to /sys/sys/jail.h.rej done # ************************************************************************************************* I asked in serverfault.com but they make me notice that this was a patch for 10.x and I was applying it to 11. but afterthat no further advance, Ple\ ase could anyone help me on this. Thanks in advance. From owner-freebsd-stable@freebsd.org Wed Nov 2 01:55:55 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63F86C2A8C6 for ; Wed, 2 Nov 2016 01:55:55 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-qt0-x242.google.com (mail-qt0-x242.google.com [IPv6:2607:f8b0:400d:c0d::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DF7F41B88 for ; Wed, 2 Nov 2016 01:55:54 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-qt0-x242.google.com with SMTP id n34so63408qtb.3 for ; Tue, 01 Nov 2016 18:55:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=rafNk1afZQXNFMQ4DLr2eg/LIBWjV6ulZxSGY7kHu9M=; b=UGTGVHXdZzyK6itvg7jp+TlZhfCK+cQQm3n3AnXoHaQ47iafNMje15Jhs5lBpHBCuY JJjLxg/Hs33+zIOCCnDsqDdvVQCgpF4kjy3I1tK7v0Lc0sn+fPuaL2dU5uLptMILqECP EDu2MKW/jqCIsYAIadnboClBQCkuTN2kBGdGbi6FVAEwrq0mU+Mp9GIXFWmWddnQLzQ/ 4HB672QeMCvZven2e2/5VQ/nfj7Sa60sgSDQ3XOadGvweaEohSX1y87Pn0avZD/lOuev +9r43P4wMg/S+O7v5bftkqin+UCUW9BUwNpY2L2CCy/L4bQNOzkLXl+nHgC2yE+Euble irRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=rafNk1afZQXNFMQ4DLr2eg/LIBWjV6ulZxSGY7kHu9M=; b=mDSrwclLRXYryq8iQL1j35co3jyoZxzxCGztBgGnkvYKaYJ5DTmYjkq+X8OpSAf9uH owVnjeS1buTEypRFzVD2Fxg34PPwTo0/LTwbqMBIei7b6Ax3r3T3i71Z5ozF1OGa37iQ Asg+JSyr/U0rPxrGME2oe7aJQpYRHGQix28/LKZCfGFNUq/mIgPD3hiFwlPIsZ+VPD8f U5jXKYj28FbIJEUgfV8KCU8a9dZ6SPGz6Cf3B5bO2aDUXvqSMy1mDKMK13qKno4Jpg7e bW4pJ5ZJa3JkKWvnFU/89n9fBesc4fR+e736DgMeRW1HZeFKVp6cqMCPyxUnqABwIjSX meag== X-Gm-Message-State: ABUngvcvoc1stWnFskXCldFg/VG8vn7xnqTMW3w6lz+Kn+tatdor2OlG4ROnit2/djwe/EMVKr+Ccg8lmHmRPg== X-Received: by 10.200.56.228 with SMTP id g33mr998901qtc.140.1478051754059; Tue, 01 Nov 2016 18:55:54 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.12.168.154 with HTTP; Tue, 1 Nov 2016 18:55:51 -0700 (PDT) In-Reply-To: <425a02f7-035a-8c26-8ed2-7f32be6d3373@gmail.com> References: <425a02f7-035a-8c26-8ed2-7f32be6d3373@gmail.com> From: Alan Somers Date: Tue, 1 Nov 2016 19:55:51 -0600 X-Google-Sender-Auth: OmFh9zcZlzQ9LEowdWF9MiYY3aU Message-ID: Subject: Re: Problems with jail inside ZFS dataset To: eddyraz Cc: FreeBSD Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 01:55:55 -0000 On Tue, Nov 1, 2016 at 5:05 PM, eddyraz wrote: > > > Good Afternoon., I have A VPS with FreeBSD in a dedicated server with OVH > Hosting. Last week I installed FreeBSD 11, Ran buildworld after that Crea\ > ted a VM within a jail in /local/jails/ ZFS dataset > > While trying to start the VM gave an error that said it could not mount > nullfs. > > I added this in /boot/loader.conf > > nullfs_mount=1 > > later the error changed to: > > Starting jails: cannot start jail "haproxy": > mount: .: Operation not supported by device > jail: haproxy: /sbin/mount -t fdescfs . /local/jails/haproxy/dev/fd: failed > > Following this post in Internet > > https://lists.freebsd.org/pipermail/freebsd-stable/2014-August/079700.html > > I ran the patch that they advised to. and I found in > > http://pastebin.com/5t9zEzkV > > > but while aplying the patch with > > patch /sys/fs/fdescfs/fdesc_vfsops.c sys_fs_fdescfs_fdesc_vfsop > > gives this error. > > ****************************************************************************************************** > Hmm... Looks like a unified diff to me... > The text leading up to this was: > > -------------------------- > |diff --git a/sys/fs/fdescfs/fdesc_vfsops.c b/sys/fs/fdescfs/fdesc_vfsops.c > |index cb5e3c0..7193809 100644 > |--- a/sys/fs/fdescfs/fdesc_vfsops.c > |+++ b/sys/fs/fdescfs/fdesc_vfsops.c > -------------------------- > Patching file /sys/fs/fdescfs/fdesc_vfsops.c using Plan A... > Reversed (or previously applied) patch detected! Assume -R? [y] y > Hunk #1 succeeded at 51 (offset 1 line). > Hunk #2 failed at 79. > No such line 241 in input file, ignoring > Hunk #3 succeeded at 229 (offset -8 lines). > 1 out of 3 hunks failed--saving rejects to > /sys/fs/fdescfs/fdesc_vfsops.c.rej > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |diff --git a/sys/kern/kern_jail.c b/sys/kern/kern_jail.c > |index 2846eca..791723d 100644 > |--- a/sys/kern/kern_jail.c > |+++ b/sys/kern/kern_jail.c > -------------------------- > File to patch: /sys/kern/kern_jail.c > Patching file /sys/kern/kern_jail.c using Plan A... > Hunk #1 failed at 207. > Hunk #2 failed at 224. > Hunk #3 failed at 4247. > Hunk #4 failed at 4403. > 4 out of 4 hunks failed--saving rejects to /sys/kern/kern_jail.c.rej > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > > |diff --git a/sys/sys/jail.h b/sys/sys/jail.h > |index a82a499..a01d665 100644 > |--- a/sys/sys/jail.h > |+++ b/sys/sys/jail.h > > -------------------------- > File to patch: /sys/sys/jail.h > Patching file /sys/sys/jail.h using Plan A... > Hunk #1 failed at 228. > 1 out of 1 hunks failed--saving rejects to /sys/sys/jail.h.rej > done > # > > ************************************************************************************************* > > I asked in serverfault.com but they make me notice that this was a patch for > 10.x and I was applying it to 11. but afterthat no further advance, Ple\ > ase could anyone help me on this. Thanks in advance. ZFS appears to be unrelated to your problem. It sounds like you're trying to mount fdescfs from within a jail. That's not allowed by default. Is your VPS itself a jail? If so, you'll have to ask your hosting provider to set allow.mount.fdescfs=1 in your jail config. Or are you trying to use nested jails? If so, set that same parameter in the config for your outer jail. -Alan From owner-freebsd-stable@freebsd.org Wed Nov 2 03:45:03 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7250EC28615 for ; Wed, 2 Nov 2016 03:45:03 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c: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 03DC61669 for ; Wed, 2 Nov 2016 03:45:02 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-vk0-x230.google.com with SMTP id w194so2901626vkw.2 for ; Tue, 01 Nov 2016 20:45:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=SXT3x8IW9rg27s8t1T8mhKUZg5qkc5o162NYkcFU/G0=; b=eX5wCDKHhOlLzY4KYq2EKEy3aUU1s/kSY27wD921WXgMIBYtQXxyCWtUPM9bZJ1Bgx 74fQULBnuNpjU1AW8Jn8wXZL+fw7spMtB0PJFoypH9CIbpXYOAxpHNvSrodNE65N1eVO GX/zb97rrVwJlXOiM2mt1oAT2fa8mRSDrscmeDSBRFZKapY2poPUdds77FadzpnOM6RS Opc/P6fnAx2/MvvFJb6BDZOvuWoESXOgSe0X6qiAMiRJ+hZLlqUJSwG9x/RJX3Cu3dhN YcGHxCzt9bO/dxLa4elKHBOVu3jrbOw+ClMM42bqhiH33IwJzI+DMO1EAsx7FZi5lzAE LM3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=SXT3x8IW9rg27s8t1T8mhKUZg5qkc5o162NYkcFU/G0=; b=DgsvosDj/S6+r7mFMB+J/28I2QU7yv2Thc2luNZVlfNvClv7aPXTnANzhzY3Sa5I23 FLxSKS5ad5jdqEI05frt2Jg0RqWRHhPnF3qbfSc+p8cnyWWsUJeRKPx8Ks91S90Red+z Norc0kXZJwPIr0Xz7PTMRiNHs9rT/oo+wvlQ9PYg9+xwJBMarY5UiymjSPMg68VGpyER h0xWWdcY/1RFrVj8TY4AN0U7G2NG0TlQJotOibNDv5zpluZ5WqmD++BSBuvMgr0ywHAA L8DpgRPBDOOYqMrhkV0tH/jwoC+0/5C3zzhp5+oIwSN/vFVPSsa5hbFLopJdTIhVEaYD X8sQ== X-Gm-Message-State: ABUngvfygnJdFXsgJAGdhMy93el2TThgMaPJx6T56JVTwvRkHAKcyMeo1XFYkIIbDJbVkMZsU0OlsR9qSCkkuw== X-Received: by 10.31.188.67 with SMTP id m64mr1079017vkf.155.1478058301601; Tue, 01 Nov 2016 20:45:01 -0700 (PDT) MIME-Version: 1.0 Sender: kob6558@gmail.com Received: by 10.103.119.79 with HTTP; Tue, 1 Nov 2016 20:45:01 -0700 (PDT) In-Reply-To: <1c3f4599-8aef-471a-3a39-49d913f1a4e5@gmail.com> References: <6167392c-c37a-6e39-aa22-ca45435d6088@gmail.com> <1c3f4599-8aef-471a-3a39-49d913f1a4e5@gmail.com> From: Kevin Oberman Date: Tue, 1 Nov 2016 20:45:01 -0700 X-Google-Sender-Auth: smdJT4aH9ha3gDzKXgHDFYY82Kw Message-ID: Subject: Re: huge nanosleep variance on 11-stable To: Jason Harmening Cc: FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 03:45:03 -0000 On Tue, Nov 1, 2016 at 2:36 PM, Jason Harmening wrote: > Sorry, that should be ~*30ms* to get 30fps, though the variance is still > up to 500ms for me either way. > > On 11/01/16 14:29, Jason Harmening wrote: > > repro code is at http://pastebin.com/B68N4AFY if anyone's interested. > > > > On 11/01/16 13:58, Jason Harmening wrote: > >> Hi everyone, > >> > >> I recently upgraded my main amd64 server from 10.3-stable (r302011) to > >> 11.0-stable (r308099). It went smoothly except for one big issue: > >> certain applications (but not the system as a whole) respond very > >> sluggishly, and video playback of any kind is extremely choppy. > >> > >> The system is under very light load, and I see no evidence of abnormal > >> interrupt latency or interrupt load. More interestingly, if I place the > >> system under full load (~0.0% idle) the problem *disappears* and > >> playback/responsiveness are smooth and quick. > >> > >> Running ktrace on some of the affected apps points me at the problem: > >> huge variance in the amount of time spent in the nanosleep system call. > >> A sleep of, say, 5ms might take anywhere from 5ms to ~500ms from entry > >> to return of the syscall. OTOH, anything CPU-bound or that waits on > >> condvars or I/O interrupts seems to work fine, so this doesn't seem to > >> be an issue with overall system latency. > >> > >> I can repro this with a simple program that just does a 3ms usleep in a > >> tight loop (i.e. roughly the amount of time a video player would sleep > >> between frames @ 30fps). At light load ktrace will show the huge > >> nanosleep variance; under heavy load every nanosleep will complete in > >> almost exactly 3ms. > >> > >> FWIW, I don't see this on -current, although right now all my -current > >> images are VMs on different HW so that might not mean anything. I'm not > >> aware of any recent timer- or scheduler- specific changes, so I'm > >> wondering if perhaps the recent IPI or taskqueue changes might be > >> somehow to blame. > >> > >> I'm not especially familiar w/ the relevant parts of the kernel, so any > >> guidance on where I should focus my debugging efforts would be much > >> appreciated. > >> > >> Thanks, > >> Jason > This is likely off track, but this is a behavior I have noticed since moving to 11, though it might have started in 10.3-STABLE before moving to head before 11 went to beta. I can't explain any way nanosleep could be involved, but I saw annoying lock-ups similar to yours. I also no longer see them. I eliminated the annoyance by change scheduler from ULE to 4BSD. That was it, but I have not seen the issue since. I'd be very interested in whether the scheduler is somehow impacting timing functions or it's s different issue. I've felt that there was something off in ULE for some time, but it was not until these annoying hiccups convinced me to try going back to 4BSD. Tip o' the hat to Doug B. for his suggestions that ULE may have issues that impacted interactivity. From owner-freebsd-stable@freebsd.org Wed Nov 2 05:09:44 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97E5AC2A85B for ; Wed, 2 Nov 2016 05:09:44 +0000 (UTC) (envelope-from jason.harmening@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 30AE11203 for ; Wed, 2 Nov 2016 05:09:44 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: by mail-pf0-x235.google.com with SMTP id n85so4688725pfi.1 for ; Tue, 01 Nov 2016 22:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=KcKIniNi53XtHAD26B+gWNwvLs/YkylhfwU+cVDbewc=; b=vSPUzlelkPMyLTK6bcvJXXKiMOY9n/11+z7PACdy01I0bTxxXudajWSJhCafIAiFni l31yfk7aa8dHl1LnUvImdsBW26g18ofDBHSEA9OrxVCh+8T8rUfy4PsYYDSRX46c28iQ 373i761Di5fyM5rcvUyebx56gesa5q6k+Xc6i9Nj4wSXlSd6Q/hbmWzA7LqmxDu67FG8 oN3/ciClgL8q5E8GB69khJFOcLxkLMsizHwF/z0DLA2aaeZ5r35IZVwCNwPRt+n7Je3c 9h7g6eCPjdlZOGyrETtblBdogMy4+AESdVrfx3BEF7M+4qkk88CciOzrql6ulKr3V15M qjgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=KcKIniNi53XtHAD26B+gWNwvLs/YkylhfwU+cVDbewc=; b=SQlU6P3RcRUglz/K9YhRV2hUvc0ivgcJM+j+Z10wwDU3pIG3BGGHRex5QY0EP+vqea tFzxjSyDje7a7yjFm5YF4K0qA9qcTgFAT74mp5JN6EivCbDr2VvMMxuFSAJAdpj+3E/z mqY1aAg97e3vvWH3GgvTG+dhS8AMsKJAsml+aFQMd11E11tsTA73YzwgOFkmZKQ1NSP8 th15HVrpmZ4kmR3bxyyqzdWzINBiQ89tGMnkKrve/4ywh92lq8Ayru5D01P7iTgn8Y+J 23N9c5Ac4uNxbtLwYsQaZAzfZVMHZR9Vj8CcEchZ7yxPPR5CjKzdbmvASOGlvBjcpC7r pX7w== X-Gm-Message-State: ABUngvfGvgMrYesVWR0hFWPIiGWgXOCSMyopDhM3K0cGSqATx8SCKdfYOAjyO6uepA2oYA== X-Received: by 10.98.144.83 with SMTP id a80mr3425853pfe.156.1478063383183; Tue, 01 Nov 2016 22:09:43 -0700 (PDT) Received: from corona.austin.rr.com (c-67-188-30-11.hsd1.ca.comcast.net. [67.188.30.11]) by smtp.googlemail.com with ESMTPSA id l7sm685709pfg.35.2016.11.01.22.09.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Nov 2016 22:09:42 -0700 (PDT) Subject: Re: huge nanosleep variance on 11-stable To: Kevin Oberman References: <6167392c-c37a-6e39-aa22-ca45435d6088@gmail.com> <1c3f4599-8aef-471a-3a39-49d913f1a4e5@gmail.com> Cc: FreeBSD-STABLE Mailing List From: Jason Harmening Message-ID: Date: Tue, 1 Nov 2016 22:16:39 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="17l0HvA18Gx7iIfq8LvJv7LJbKkkiT9Ah" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 05:09:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --17l0HvA18Gx7iIfq8LvJv7LJbKkkiT9Ah Content-Type: multipart/mixed; boundary="8HTTFfHFskPSnrQDLV8uDFxOEbWF1knW6"; protected-headers="v1" From: Jason Harmening To: Kevin Oberman Cc: FreeBSD-STABLE Mailing List Message-ID: Subject: Re: huge nanosleep variance on 11-stable References: <6167392c-c37a-6e39-aa22-ca45435d6088@gmail.com> <1c3f4599-8aef-471a-3a39-49d913f1a4e5@gmail.com> In-Reply-To: --8HTTFfHFskPSnrQDLV8uDFxOEbWF1knW6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/01/16 20:45, Kevin Oberman wrote: > On Tue, Nov 1, 2016 at 2:36 PM, Jason Harmening > > wrote: >=20 > Sorry, that should be ~*30ms* to get 30fps, though the variance is = still > up to 500ms for me either way. >=20 > On 11/01/16 14:29, Jason Harmening wrote: > > repro code is at http://pastebin.com/B68N4AFY if anyone's interes= ted. > > > > On 11/01/16 13:58, Jason Harmening wrote: > >> Hi everyone, > >> > >> I recently upgraded my main amd64 server from 10.3-stable > (r302011) to > >> 11.0-stable (r308099). It went smoothly except for one big issu= e: > >> certain applications (but not the system as a whole) respond ver= y > >> sluggishly, and video playback of any kind is extremely choppy. > >> > >> The system is under very light load, and I see no evidence of > abnormal > >> interrupt latency or interrupt load. More interestingly, if I > place the > >> system under full load (~0.0% idle) the problem *disappears* and= > >> playback/responsiveness are smooth and quick. > >> > >> Running ktrace on some of the affected apps points me at the pro= blem: > >> huge variance in the amount of time spent in the nanosleep syste= m > call. > >> A sleep of, say, 5ms might take anywhere from 5ms to ~500ms from= > entry > >> to return of the syscall. OTOH, anything CPU-bound or that wait= s on > >> condvars or I/O interrupts seems to work fine, so this doesn't > seem to > >> be an issue with overall system latency. > >> > >> I can repro this with a simple program that just does a 3ms > usleep in a > >> tight loop (i.e. roughly the amount of time a video player would= > sleep > >> between frames @ 30fps). At light load ktrace will show the hug= e > >> nanosleep variance; under heavy load every nanosleep will comple= te in > >> almost exactly 3ms. > >> > >> FWIW, I don't see this on -current, although right now all my > -current > >> images are VMs on different HW so that might not mean anything. = > I'm not > >> aware of any recent timer- or scheduler- specific changes, so I'= m > >> wondering if perhaps the recent IPI or taskqueue changes might b= e > >> somehow to blame. > >> > >> I'm not especially familiar w/ the relevant parts of the kernel,= > so any > >> guidance on where I should focus my debugging efforts would be m= uch > >> appreciated. > >> > >> Thanks, > >> Jason >=20 > =20 > This is likely off track, but this is a behavior I have noticed since > moving to 11, though it might have started in 10.3-STABLE before moving= > to head before 11 went to beta. I can't explain any way nanosleep could= > be involved, but I saw annoying lock-ups similar to yours. I also no > longer see them. >=20 > I eliminated the annoyance by change scheduler from ULE to 4BSD. That > was it, but I have not seen the issue since. I'd be very interested in > whether the scheduler is somehow impacting timing functions or it's s > different issue. I've felt that there was something off in ULE for some= > time, but it was not until these annoying hiccups convinced me to try > going back to 4BSD. >=20 > Tip o' the hat to Doug B. for his suggestions that ULE may have issues > that impacted interactivity. I figured it out: r282678 (which was never MFCed to 10-stable) added support for the MWAIT instruction on the idle path for Intel CPUs that claim to support it. While my CPU (2009-era Xeon 5500) advertises support for it in its feature mask and ACPI C-state entries, the cores don't seem to respond very quickly to interrupts while idling in MWAIT. Disabling mwait in acpi_cpu.c and falling back to the old "sti; hlt" mechanism for C1 completely fixes the responsiveness issues. So if your CPU is of a similar vintage, it may not be ULE's fault. --8HTTFfHFskPSnrQDLV8uDFxOEbWF1knW6-- --17l0HvA18Gx7iIfq8LvJv7LJbKkkiT9Ah Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJYGXa6XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRENkY3MTQyREU0MTU4MTgyRkZDNUU2ODVC QjlGOEJGOTkyODQxRDFCAAoJELufi/mShB0bwGwH/RVFzEp0ThkwNTW6nJc5j/0u QWOLclW56iZ3CJMMAdIG6Dk0P8V4fg9KxuSL276PFxxcGq1sNg3HeTh69cAUWK3N i3jjSa2JUgh4VAViKAEOTr1iWcNgqFpNl+05NP9ZWJY/v60n4AmMApNXH6KT8C5f WQnPymA3csxxUBtmHGZnDyUDrlpWNRfk2b6M2E9Zc975hJTpBxyxhI+IrmoyiB/4 2yQ0ha0SqzT2dN9f7XgFVvpuRJTGaaWWLhMYGib69U7EhVudkYNn33/dftI6eDYt ZRxLJgvfJr6Z3s3o9+xKv5ExGrMqOFF1DkCznm0klcCSkPiH1VVTfZCRkko8tI4= =xnUb -----END PGP SIGNATURE----- --17l0HvA18Gx7iIfq8LvJv7LJbKkkiT9Ah-- From owner-freebsd-stable@freebsd.org Wed Nov 2 05:49:59 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 54CC1C2A52B for ; Wed, 2 Nov 2016 05:49:59 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c: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 399361FD4 for ; Wed, 2 Nov 2016 05:49:58 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-vk0-x232.google.com with SMTP id x186so4485859vkd.1 for ; Tue, 01 Nov 2016 22:49:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=fY470maeajdR6V+8I3hXg/4Nfv2tngMSpas7nSaGPEM=; b=lKh9OL4nlsDg5EKf5BT/7j2Oz0cNRY4t0d/wWcoCBfBXe7veGTlgCk2e1WNgKCBxs8 oyup/r+rcPP7NjT/QUeg3KTs9obp8pL5DGAg9SYEjcaQV1tYYb3usfgEPvv6rHyS7avO Iur4D1/qUfA47MuobFEXb/HDae7YgJ9bN7TMVgVkRKJWqGI3asBH7r8lxvjBgnvruEDw jW8gfGoUa+D9kUbtJpWUBDtbu9qXsyL6Tl/B330PVYbD/VpZ65K3cS1zmm67vRbSgdXZ eLT7hngaguz/heeu7rc7s2Oc0Bt+ZPj2UmTCftIEH1edtff0uDi506K9SIs2ASao3LXb a0ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=fY470maeajdR6V+8I3hXg/4Nfv2tngMSpas7nSaGPEM=; b=b6SNuSLqSiWLGaHVsmmWUFCh0RGRkW5Kv0RSuzvJw+I534dU51d0JJuqZMWt14BmHP lfCUaazBTC1j4Ijz6K9nP06Jc0ZNlkZ2nJE/QCYSwcco+9CRINUib1ciqxZkgHWL5mPc KYu3ccJoOAn3qLoOpQgim9RvnBzI+zLcbEGc4gTAVqFf6GOMjapZZ0KKwTPzMmoAKVRf UpL0FT202mAf6riZHQfe4LyjygV8Vq7/jKGk8eCsJRWlXhEacqaZ3DDV7kzDyLb3h1Yn mUSkPfduQHx3EOhSPZhfLjobNnmQK3Cc9gyJipylgJTeN1dnc7IRCG/Z8VEiii9jjjQD 2n+w== X-Gm-Message-State: ABUngvdMo7FN+fwvfY6nafTDBq+Rh4gdRrkgKjdmk9HRa2d1oUKMOfB2Nw6LSCnIb60greL2HyiPMYGnJiwx3g== X-Received: by 10.31.60.85 with SMTP id j82mr1356388vka.42.1478065797046; Tue, 01 Nov 2016 22:49:57 -0700 (PDT) MIME-Version: 1.0 Sender: kob6558@gmail.com Received: by 10.103.119.79 with HTTP; Tue, 1 Nov 2016 22:49:56 -0700 (PDT) In-Reply-To: References: <6167392c-c37a-6e39-aa22-ca45435d6088@gmail.com> <1c3f4599-8aef-471a-3a39-49d913f1a4e5@gmail.com> From: Kevin Oberman Date: Tue, 1 Nov 2016 22:49:56 -0700 X-Google-Sender-Auth: NNcovKsrJ8WoFdVCX1Wz93OUpEY Message-ID: Subject: Re: huge nanosleep variance on 11-stable To: Jason Harmening Cc: FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 05:49:59 -0000 On Tue, Nov 1, 2016 at 10:16 PM, Jason Harmening wrote: > > > On 11/01/16 20:45, Kevin Oberman wrote: > > On Tue, Nov 1, 2016 at 2:36 PM, Jason Harmening > > > wrote: > > > > Sorry, that should be ~*30ms* to get 30fps, though the variance is > still > > up to 500ms for me either way. > > > > On 11/01/16 14:29, Jason Harmening wrote: > > > repro code is at http://pastebin.com/B68N4AFY if anyone's > interested. > > > > > > On 11/01/16 13:58, Jason Harmening wrote: > > >> Hi everyone, > > >> > > >> I recently upgraded my main amd64 server from 10.3-stable > > (r302011) to > > >> 11.0-stable (r308099). It went smoothly except for one big issue: > > >> certain applications (but not the system as a whole) respond very > > >> sluggishly, and video playback of any kind is extremely choppy. > > >> > > >> The system is under very light load, and I see no evidence of > > abnormal > > >> interrupt latency or interrupt load. More interestingly, if I > > place the > > >> system under full load (~0.0% idle) the problem *disappears* and > > >> playback/responsiveness are smooth and quick. > > >> > > >> Running ktrace on some of the affected apps points me at the > problem: > > >> huge variance in the amount of time spent in the nanosleep system > > call. > > >> A sleep of, say, 5ms might take anywhere from 5ms to ~500ms from > > entry > > >> to return of the syscall. OTOH, anything CPU-bound or that waits > on > > >> condvars or I/O interrupts seems to work fine, so this doesn't > > seem to > > >> be an issue with overall system latency. > > >> > > >> I can repro this with a simple program that just does a 3ms > > usleep in a > > >> tight loop (i.e. roughly the amount of time a video player would > > sleep > > >> between frames @ 30fps). At light load ktrace will show the huge > > >> nanosleep variance; under heavy load every nanosleep will > complete in > > >> almost exactly 3ms. > > >> > > >> FWIW, I don't see this on -current, although right now all my > > -current > > >> images are VMs on different HW so that might not mean anything. > > I'm not > > >> aware of any recent timer- or scheduler- specific changes, so I'm > > >> wondering if perhaps the recent IPI or taskqueue changes might be > > >> somehow to blame. > > >> > > >> I'm not especially familiar w/ the relevant parts of the kernel, > > so any > > >> guidance on where I should focus my debugging efforts would be > much > > >> appreciated. > > >> > > >> Thanks, > > >> Jason > > > > > > This is likely off track, but this is a behavior I have noticed since > > moving to 11, though it might have started in 10.3-STABLE before moving > > to head before 11 went to beta. I can't explain any way nanosleep could > > be involved, but I saw annoying lock-ups similar to yours. I also no > > longer see them. > > > > I eliminated the annoyance by change scheduler from ULE to 4BSD. That > > was it, but I have not seen the issue since. I'd be very interested in > > whether the scheduler is somehow impacting timing functions or it's s > > different issue. I've felt that there was something off in ULE for some > > time, but it was not until these annoying hiccups convinced me to try > > going back to 4BSD. > > > > Tip o' the hat to Doug B. for his suggestions that ULE may have issues > > that impacted interactivity. > > I figured it out: r282678 (which was never MFCed to 10-stable) added > support for the MWAIT instruction on the idle path for Intel CPUs that > claim to support it. > > While my CPU (2009-era Xeon 5500) advertises support for it in its > feature mask and ACPI C-state entries, the cores don't seem to respond > very quickly to interrupts while idling in MWAIT. Disabling mwait in > acpi_cpu.c and falling back to the old "sti; hlt" mechanism for C1 > completely fixes the responsiveness issues. > > So if your CPU is of a similar vintage, it may not be ULE's fault. > > You are almost certainly correct. My system is circa 2011; i5-2520M, Sandy Bridge. While it might have the same issue, I'd be surprised. It's possible, but probably completely different from what you are seeing. Reports of the problem I was seeing definitely pre-date 11, but 11 made things much worse, so it could be a combination of things. And I can't see how ULE could have anything to do with this issue. Congratulations on some really good sleuthing to find this. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 From owner-freebsd-stable@freebsd.org Wed Nov 2 06:06:06 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D87C3C2A9DF for ; Wed, 2 Nov 2016 06:06:06 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 75BD21442 for ; Wed, 2 Nov 2016 06:06:06 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: by mail-pf0-x230.google.com with SMTP id i88so5605386pfk.2 for ; Tue, 01 Nov 2016 23:06:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=/W2a5PPp9i92PTkCCJ1Or35to43IkUhRv8IiArfmu/A=; b=FtX+1hUna9MSQ4K9fv1trUPCznvba/XHKtOialwRT1ub3VVv8g4IvprgF2Rmsbh9zc zFJY08L+/teVRMI/F5ckQ1tRCAQ2GESONFztTSphH2lZOdQ4GwWIHoseXrKMdY20y3lk 0RYKB/a4UyoxrFUGy35DL1wPJojuTgmwNo0hmFQcG9oWaw0weMUXCEFUl2SyRFBgPTcp H9cK61aWBBu2/q7alRQqHQDHNdQ8BERm1jIyzFaBa/+WG7uydEDMCQznmd/b2nv1Zblu DrpN9BBb36LZLmvC9gjNRhamHwMInmw+ZYZ47ewSK7sTSmrFvFu9AM3DSAh94tb59ToL oKnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=/W2a5PPp9i92PTkCCJ1Or35to43IkUhRv8IiArfmu/A=; b=fSc1Bl9Wq5Tx+MFQmTBneDcikUQ2MhhhXTXIFe+w6CPonTln2Q5NU2mYxLAAJlshN3 hEFcD8w6k7cf03Y2eOw2xB5ZlnERzxy8etMRn0Uzqpq58VIuLcG9XTu9PzivtxdKDRdW si2bdS/TABzO4vObm3+GmntmPaV1ehe38etokpYw943q0OMVdbXXB3ndT7vLvlmRCqto 2gnWMEW5nFPS7WhwHwH0WHW3LjIJBtRHZ3x3ljh2eW3J/wMlaSDgydfj5ir1xqcYFgJR V0fwwfNUbCp7dtWGhMUYuBoYQVBf1IKZCr/NJ7CW1NvzsVnSZeXU08EGLF6Wu6Fief/I U4lQ== X-Gm-Message-State: ABUngver6SvUuZTVHtmplH9Lj5N778/62l7wLoF+P1WTCglW4hPvQrKOnhCUK1Wb8fK/NQ== X-Received: by 10.99.65.133 with SMTP id o127mr3017557pga.73.1478066765929; Tue, 01 Nov 2016 23:06:05 -0700 (PDT) Received: from corona.austin.rr.com (c-67-188-30-11.hsd1.ca.comcast.net. [67.188.30.11]) by smtp.googlemail.com with ESMTPSA id 21sm1116234pfs.88.2016.11.01.23.06.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Nov 2016 23:06:04 -0700 (PDT) Subject: Re: huge nanosleep variance on 11-stable To: Kevin Oberman References: <6167392c-c37a-6e39-aa22-ca45435d6088@gmail.com> <1c3f4599-8aef-471a-3a39-49d913f1a4e5@gmail.com> Cc: FreeBSD-STABLE Mailing List From: Jason Harmening Message-ID: <3788515b-d271-ea9f-81b9-860111f7e7d4@gmail.com> Date: Tue, 1 Nov 2016 23:13:05 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IpLW9Sv2BaXgt9dpDtmHLHCBwHOrCMbg3" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 06:06:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IpLW9Sv2BaXgt9dpDtmHLHCBwHOrCMbg3 Content-Type: multipart/mixed; boundary="nsjwe146cwW3gEQWPVm1UJoa6sXL5Ki1W"; protected-headers="v1" From: Jason Harmening To: Kevin Oberman Cc: FreeBSD-STABLE Mailing List Message-ID: <3788515b-d271-ea9f-81b9-860111f7e7d4@gmail.com> Subject: Re: huge nanosleep variance on 11-stable References: <6167392c-c37a-6e39-aa22-ca45435d6088@gmail.com> <1c3f4599-8aef-471a-3a39-49d913f1a4e5@gmail.com> In-Reply-To: --nsjwe146cwW3gEQWPVm1UJoa6sXL5Ki1W Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/01/16 22:49, Kevin Oberman wrote: > On Tue, Nov 1, 2016 at 10:16 PM, Jason Harmening > > wrote: >=20 >=20 >=20 > On 11/01/16 20:45, Kevin Oberman wrote: > > On Tue, Nov 1, 2016 at 2:36 PM, Jason Harmening > > > >> wrote: > > > > Sorry, that should be ~*30ms* to get 30fps, though the > variance is still > > up to 500ms for me either way. > > > > On 11/01/16 14:29, Jason Harmening wrote: > > > repro code is at http://pastebin.com/B68N4AFY if anyone's > interested. > > > > > > On 11/01/16 13:58, Jason Harmening wrote: > > >> Hi everyone, > > >> > > >> I recently upgraded my main amd64 server from 10.3-stable > > (r302011) to > > >> 11.0-stable (r308099). It went smoothly except for one bi= g > issue: > > >> certain applications (but not the system as a whole) > respond very > > >> sluggishly, and video playback of any kind is extremely ch= oppy. > > >> > > >> The system is under very light load, and I see no evidence= of > > abnormal > > >> interrupt latency or interrupt load. More interestingly, = if I > > place the > > >> system under full load (~0.0% idle) the problem > *disappears* and > > >> playback/responsiveness are smooth and quick. > > >> > > >> Running ktrace on some of the affected apps points me at > the problem: > > >> huge variance in the amount of time spent in the nanosleep= > system > > call. > > >> A sleep of, say, 5ms might take anywhere from 5ms to ~500m= s > from > > entry > > >> to return of the syscall. OTOH, anything CPU-bound or tha= t > waits on > > >> condvars or I/O interrupts seems to work fine, so this doe= sn't > > seem to > > >> be an issue with overall system latency. > > >> > > >> I can repro this with a simple program that just does a 3m= s > > usleep in a > > >> tight loop (i.e. roughly the amount of time a video player= > would > > sleep > > >> between frames @ 30fps). At light load ktrace will show > the huge > > >> nanosleep variance; under heavy load every nanosleep will > complete in > > >> almost exactly 3ms. > > >> > > >> FWIW, I don't see this on -current, although right now all= my > > -current > > >> images are VMs on different HW so that might not mean anyt= hing. > > I'm not > > >> aware of any recent timer- or scheduler- specific changes,= > so I'm > > >> wondering if perhaps the recent IPI or taskqueue changes > might be > > >> somehow to blame. > > >> > > >> I'm not especially familiar w/ the relevant parts of the > kernel, > > so any > > >> guidance on where I should focus my debugging efforts woul= d > be much > > >> appreciated. > > >> > > >> Thanks, > > >> Jason > > > > > > This is likely off track, but this is a behavior I have noticed s= ince > > moving to 11, though it might have started in 10.3-STABLE before > moving > > to head before 11 went to beta. I can't explain any way nanosleep= > could > > be involved, but I saw annoying lock-ups similar to yours. I also= no > > longer see them. > > > > I eliminated the annoyance by change scheduler from ULE to 4BSD. = That > > was it, but I have not seen the issue since. I'd be very interest= ed in > > whether the scheduler is somehow impacting timing functions or it= 's s > > different issue. I've felt that there was something off in ULE fo= r > some > > time, but it was not until these annoying hiccups convinced me to= try > > going back to 4BSD. > > > > Tip o' the hat to Doug B. for his suggestions that ULE may have i= ssues > > that impacted interactivity. >=20 > I figured it out: r282678 (which was never MFCed to 10-stable) adde= d > support for the MWAIT instruction on the idle path for Intel CPUs t= hat > claim to support it. >=20 > While my CPU (2009-era Xeon 5500) advertises support for it in its > feature mask and ACPI C-state entries, the cores don't seem to resp= ond > very quickly to interrupts while idling in MWAIT. Disabling mwait = in > acpi_cpu.c and falling back to the old "sti; hlt" mechanism for C1 > completely fixes the responsiveness issues. >=20 > So if your CPU is of a similar vintage, it may not be ULE's fault. >=20 >=20 > You are almost certainly correct. My system is circa 2011; i5-2520M, > Sandy Bridge. While it might have the same issue, I'd be surprised. It'= s > possible, but probably completely different from what you are seeing. > Reports of the problem I was seeing definitely pre-date 11, but 11 made= > things much worse, so it could be a combination of things. And I can't > see how ULE could have anything to do with this issue. >=20 > Congratulations on some really good sleuthing to find this. It might be worth a shot just to see if this has any impact on the issue you were seeing with ULE. I agree that it doesn't seem likely the choice of scheduler would have an impact on an issue like this. But it's possible that 4BSD might schedule threads across cores such that a given core is less likely to be idle on delivery of a timer interrupt for a given workload. --nsjwe146cwW3gEQWPVm1UJoa6sXL5Ki1W-- --IpLW9Sv2BaXgt9dpDtmHLHCBwHOrCMbg3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJYGYPxXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRENkY3MTQyREU0MTU4MTgyRkZDNUU2ODVC QjlGOEJGOTkyODQxRDFCAAoJELufi/mShB0bF1gIAOcbjNQQkPoU6I8inqAD/4eH /yRyzAZJh90aSk/0Hl2UlTfJTkZ8E8gHoG5teTVPKYn72lePymLdDDWw28zre5Rf PNEbMLT6iCj72TZdV3MWzDVRe62MCKBnDF3ggmil0At+kWoCtKno1onIuR4xvfJk hYA8DCfS0ZIlUTvT2thgBgPAb5II8M5Whrs6eZAW8FRkf5Rm7TdtcRI5Cox08a1N PFqlOBBNKZnYs3M0Q89rrHGa0i9dCB8Ir+xTOkgDvLU7xZitPeNVomGKu04raype T0mm6d+0EIWvMMpTfr2VgkOiwOS71dlOAxg8MTEKULwk7UQWlapC2CnsgZy+AZo= =2aYg -----END PGP SIGNATURE----- --IpLW9Sv2BaXgt9dpDtmHLHCBwHOrCMbg3-- From owner-freebsd-stable@freebsd.org Wed Nov 2 07:55:20 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4C21C2AC2D for ; Wed, 2 Nov 2016 07:55:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1DACB1832 for ; Wed, 2 Nov 2016 07:55:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id uA27t9QF002896 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 2 Nov 2016 09:55:10 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uA27t9QF002896 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uA27t9ap002894; Wed, 2 Nov 2016 09:55:09 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 2 Nov 2016 09:55:09 +0200 From: Konstantin Belousov To: Jason Harmening Cc: freebsd-stable@freebsd.org Subject: Re: huge nanosleep variance on 11-stable Message-ID: <20161102075509.GF54029@kib.kiev.ua> References: <6167392c-c37a-6e39-aa22-ca45435d6088@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6167392c-c37a-6e39-aa22-ca45435d6088@gmail.com> User-Agent: Mutt/1.7.1 (2016-10-04) 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-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 07:55:20 -0000 On Tue, Nov 01, 2016 at 02:29:13PM -0700, Jason Harmening wrote: > repro code is at http://pastebin.com/B68N4AFY if anyone's interested. > > On 11/01/16 13:58, Jason Harmening wrote: > > Hi everyone, > > > > I recently upgraded my main amd64 server from 10.3-stable (r302011) to > > 11.0-stable (r308099). It went smoothly except for one big issue: > > certain applications (but not the system as a whole) respond very > > sluggishly, and video playback of any kind is extremely choppy. > > > > The system is under very light load, and I see no evidence of abnormal > > interrupt latency or interrupt load. More interestingly, if I place the > > system under full load (~0.0% idle) the problem *disappears* and > > playback/responsiveness are smooth and quick. > > > > Running ktrace on some of the affected apps points me at the problem: > > huge variance in the amount of time spent in the nanosleep system call. > > A sleep of, say, 5ms might take anywhere from 5ms to ~500ms from entry > > to return of the syscall. OTOH, anything CPU-bound or that waits on > > condvars or I/O interrupts seems to work fine, so this doesn't seem to > > be an issue with overall system latency. > > > > I can repro this with a simple program that just does a 3ms usleep in a > > tight loop (i.e. roughly the amount of time a video player would sleep > > between frames @ 30fps). At light load ktrace will show the huge > > nanosleep variance; under heavy load every nanosleep will complete in > > almost exactly 3ms. > > > > FWIW, I don't see this on -current, although right now all my -current > > images are VMs on different HW so that might not mean anything. I'm not > > aware of any recent timer- or scheduler- specific changes, so I'm > > wondering if perhaps the recent IPI or taskqueue changes might be > > somehow to blame. > > > > I'm not especially familiar w/ the relevant parts of the kernel, so any > > guidance on where I should focus my debugging efforts would be much > > appreciated. > > I am confident, with very high degree of certainity, that the issue is a CPU bug in interaction between deep sleep states (C6) and LAPIC timer. Check what hardware is used for the eventtimers, sysctl kern.eventtimer.timer It should report LAPIC, and you should get rid of jitter with setting the sysctl to HPET. Also please show the first 50 lines of the verbose boot dmesg. I know that the Nehalem cores are affected, I do not know was the bug fixed for Westmere or not. I asked Intel contact about the problem, but got no response. It is not unreasonable, given that the CPUs are beyond their support time. I intended to automatically bump HPET quality on Nehalem and might be Westmere, but I was not able to check Westmere, and waited for more information, so this was forgotten. BTW, using the latest CPU microcode did not helped. After I discovered this, I specifically looked at my Sandy and Haswell test systems, but they do not exhibit such problem. In the Intel document 320836-036US 'Intel(R) CoreTM i7-900 Desktop Processor Extreme Edition Series and Intel(R) CoreTM i7-900 Desktop Processor Series Specification Update', there are two erratas which might be relevant and show the LAPIC bugs: AAJ47 (but default is to not use periodic mode), and AAJ121. The 121 might be the real cause, but Intel does not provide enough details to understand. And of course, the suggested workaround is not feasible. Googling for 'Windows LAPIC Nehalem' shows very interesting results, in particular, https://support.microsoft.com/en-us/kb/2000977 (which I think is the bug you see) and https://hardware.slashdot.org/story/09/11/28/1723257/microsoft-advice-against-nehalem-xeons-snuffed-out for amusement. From owner-freebsd-stable@freebsd.org Wed Nov 2 10:14:07 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85BE7C2AF1E for ; Wed, 2 Nov 2016 10:14:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-57.reflexion.net [208.70.210.57]) (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 9D0C61E85 for ; Wed, 2 Nov 2016 10:14:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5205 invoked from network); 2 Nov 2016 10:14:56 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 2 Nov 2016 10:14:56 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.10.0) with SMTP; Wed, 02 Nov 2016 06:14:07 -0400 (EDT) Received: (qmail 5967 invoked from network); 2 Nov 2016 10:14:07 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 Nov 2016 10:14:07 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id CC02EEC8ADF; Wed, 2 Nov 2016 03:13:57 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: stable/11 -r308135 Build for RPI2 failed for: . . ./bcm2835_ft5406.c:65:10: fatal error: 'mbox_if.h' file not found Message-Id: Date: Wed, 2 Nov 2016 03:13:57 -0700 To: FreeBSD Toolchain , FreeBSD-STABLE Mailing List , freebsd-arm X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 10:14:07 -0000 Lack of dependency? Race? (I've not isolated why this happened yet but I = was using -j 5 for buildworld buildkernel .) This was a cross-build attempt from an amd64 context: # uname -apKU FreeBSD FreeBSDx64 11.0-STABLE FreeBSD 11.0-STABLE #1 r308135M: Tue Nov = 1 23:48:47 PDT 2016 = root@FreeBSDx64:/usr/obj/amd64_clang/amd64.amd64/usr/src/sys/GENERIC-NODBG= amd64 amd64 1100506 1100506 # svnlite info /usr/src/ | grep "Re[lv]" Relative URL: ^/stable/11 Revision: 308135 Last Changed Rev: 308135 # find /usr/src/sys/ -name "*files*" -exec grep mbox_if {} \; -print | = more dev/mbox/mbox_if.m standard /usr/src/sys/arm/broadcom/bcm2835/files.bcm283x dev/mbox/mbox_if.m optional ti_mbox /usr/src/sys/arm/ti/files.ti # find /usr/obj/rpi2_clang/arm.armv6/ -name mbox_if.h -print | more = = = =20 # (So no mbox_if.h file is present in the build tree.) # head = ~/sys_typescripts/typescript_make_rpi2_nodebug_clang_bootstrap-amd64-host-= 2016-11-02:00:59:43 Script started on Wed Nov 2 00:59:43 2016 Command: env __MAKE_CONF=3D/root/src.configs/make.conf = SRC_ENV_CONF=3D/root/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host = WITH_META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/rpi2_clang make -j 5 = buildworld buildkernel . . . --- all_subdir_rpi_ft5406 --- --- bcm2835_ft5406.o --- = /usr/src/sys/modules/rpi_ft5406/../../arm/broadcom/bcm2835//bcm2835_ft5406= .c:65:10: fatal error: 'mbox_if.h' file not found #include "mbox_if.h" ^ 1 error generated. *** [bcm2835_ft5406.o] Error code 1 make[4]: stopped in /usr/src/sys/modules/rpi_ft5406 .ERROR_TARGET=3D'bcm2835_ft5406.o' = .ERROR_META_FILE=3D'/usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG/m= odules/usr/src/sys/modules/rpi_ft5406/bcm2835_ft5406.o.meta' .MAKE.LEVEL=3D'4' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose' .CURDIR=3D'/usr/src/sys/modules/rpi_ft5406' .MAKE=3D'make' = .OBJDIR=3D'/usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG/modules/us= r/src/sys/modules/rpi_ft5406' .TARGETS=3D'all' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'arm' MACHINE_ARCH=3D'armv6' = MAKEOBJDIRPREFIX=3D'/usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG/m= odules' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20160606' = PATH=3D'/usr/obj/rpi2_clang/arm.armv6/usr/src/tmp/legacy/usr/sbin:/usr/obj= /rpi2_clang/arm.armv6/usr/src/tmp/legacy/usr/bin:/usr/obj/rpi2_clang/arm.a= rmv6/usr/src/tmp/legacy/bin:/usr/obj/rpi2_clang/arm.armv6/usr/src/tmp/usr/= sbin:/usr/obj/rpi2_clang/arm.armv6/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbi= n:/usr/bin' SRCTOP=3D'/usr/src' = OBJTOP=3D'/usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG/modules/usr= /src' .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host = /usr/src/share/mk/bsd.mkopt.mk /root/src.configs/make.conf = /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk = /etc/src.conf /usr/src/sys/modules/rpi_ft5406/Makefile = /usr/src/share/mk/bsd.kmod.mk /usr/src/sys/conf/kmod.mk = /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk = /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk = /usr/src/share/mk/src.init.mk = /usr/src/sys/modules/rpi_ft5406/../Makefile.inc = /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk = /usr/src/sys/conf/kern.opts.mk /usr/src/sys/conf/config.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/sys/conf/kern.mk' .PATH=3D'. /usr/src/sys/modules/rpi_ft5406 = /usr/src/sys/modules/rpi_ft5406/../../arm/broadcom/bcm2835/ = /usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG' 1 error . . . # less = /usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG/modules/usr/src/sys/m= odules/rpi_ft5406/bcm2835_ft5406.o.meta # Meta data file = /usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG/modules/usr/src/sys/m= odules/rpi_ft5406/bcm2835_ft5406.o.meta CMD cc -mcpu=3Dcortex-a7 -O -pipe -Werror -D_KERNEL -DKLD_MODULE = -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include = /usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG/opt_global.h -I. = -I/usr/src/sys -fno-common -g -funwind-tables = -I/usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG -march=3Darmv7a = -ffreestanding -fwrapv -gdwarf-2 -Wall -Wredundant-decls = -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign = -D__printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs = -fdiagnostics-show-option -Wno-unknown-pragmas = -Wno-error-tautological-compare -Wno-error-empty-body = -Wno-error-parentheses-equality -Wno-error-unused-function = -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-movt = -mfpu=3Dnone -std=3Diso9899:1999 -c = /usr/src/sys/modules/rpi_ft5406/../../arm/broadcom/bcm2835//bcm2835_ft5406= .c -o bcm2835_ft5406.o CMD ctfconvert -L VERSION -g bcm2835_ft5406.o CWD = /usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG/modules/usr/src/sys/m= odules/rpi_ft5406 TARGET bcm2835_ft5406.o -- command output -- = /usr/src/sys/modules/rpi_ft5406/../../arm/broadcom/bcm2835//bcm2835_ft5406= .c:65:10: fatal error: 'mbox_if.h' file not found #include "mbox_if.h" ^ 1 error generated. *** Error code 1 -- filemon acquired metadata -- # filemon version 5 # Target pid 65803 # Start 1478076388.181546 V 5 E 65827 /bin/sh R 65827 /etc/libmap.conf R 65827 /var/run/ld-elf.so.hints R 65827 /lib/libedit.so.7 R 65827 /lib/libc.so.7 R 65827 /lib/libncursesw.so.8 F 65827 65834 E 65834 /usr/obj/rpi2_clang/arm.armv6/usr/src/tmp/usr/bin/cc F 65834 65836 E 65836 /usr/obj/rpi2_clang/arm.armv6/usr/src/tmp/usr/bin/cc R 65836 = /usr/src/sys/modules/rpi_ft5406/../../arm/broadcom/bcm2835//bcm2835_ft5406= .c R 65836 bcm2835_ft5406.o-bd1d6a1e W 65836 bcm2835_ft5406.o-bd1d6a1e R 65836 = /usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG/opt_global.h R 65836 /usr/src/sys/sys/cdefs.h R 65836 /usr/src/sys/sys/param.h R 65836 /usr/src/sys/sys/_null.h R 65836 /usr/src/sys/sys/types.h R 65836 ./machine/endian.h R 65836 /usr/src/sys/sys/_types.h R 65836 ./machine/_types.h R 65836 /usr/src/sys/sys/_pthreadtypes.h R 65836 /usr/src/sys/sys/_stdint.h R 65836 /usr/src/sys/sys/select.h R 65836 /usr/src/sys/sys/_sigset.h R 65836 /usr/src/sys/sys/_timeval.h R 65836 /usr/src/sys/sys/timespec.h R 65836 /usr/src/sys/sys/_timespec.h R 65836 /usr/src/sys/sys/syslimits.h R 65836 /usr/src/sys/sys/errno.h R 65836 /usr/src/sys/sys/time.h R 65836 /usr/src/sys/sys/priority.h R 65836 ./machine/param.h R 65836 ./machine/_align.h R 65836 /usr/src/sys/sys/systm.h R 65836 ./machine/atomic.h R 65836 ./machine/armreg.h R 65836 ./machine/cpuconf.h R 65836 ./machine/atomic-v6.h R 65836 ./machine/cpufunc.h R 65836 /usr/src/sys/sys/callout.h R 65836 /usr/src/sys/sys/_callout.h R 65836 /usr/src/sys/sys/queue.h R 65836 /usr/src/sys/sys/stdint.h R 65836 ./machine/_stdint.h R 65836 /usr/src/sys/sys/libkern.h R 65836 /usr/src/sys/sys/bus.h R 65836 ./machine/_limits.h R 65836 ./machine/_bus.h R 65836 /usr/src/sys/sys/_bus_dma.h R 65836 /usr/src/sys/sys/ioccom.h R 65836 /usr/src/sys/sys/eventhandler.h R 65836 /usr/src/sys/sys/lock.h R 65836 /usr/src/sys/sys/_lock.h R 65836 /usr/src/sys/sys/ktr_class.h R 65836 /usr/src/sys/sys/ktr.h R 65836 /usr/src/sys/sys/_cpuset.h R 65836 /usr/src/sys/sys/_bitset.h R 65836 /usr/src/sys/sys/mutex.h R 65836 /usr/src/sys/sys/_mutex.h R 65836 /usr/src/sys/sys/pcpu.h R 65836 /usr/src/sys/sys/_sx.h R 65836 /usr/src/sys/sys/_rmlock.h R 65836 /usr/src/sys/sys/vmmeter.h R 65836 /usr/src/sys/sys/resource.h R 65836 ./machine/pcpu.h R 65836 /usr/src/sys/sys/lock_profile.h R 65836 /usr/src/sys/sys/lockstat.h R 65836 /usr/src/sys/sys/sdt.h R 65836 /usr/src/sys/sys/linker_set.h R 65836 /usr/src/sys/sys/kobj.h R 65836 ./device_if.h R 65836 ./bus_if.h R 65836 /usr/src/sys/sys/cpu.h R 65836 /usr/src/sys/sys/kernel.h R 65836 /usr/src/sys/sys/malloc.h R 65836 /usr/src/sys/sys/module.h R 65836 /usr/src/sys/sys/condvar.h R 65836 /usr/src/sys/sys/sysctl.h R 65836 /usr/src/sys/sys/selinfo.h R 65836 /usr/src/sys/sys/event.h R 65836 /usr/src/sys/sys/poll.h R 65836 /usr/src/sys/sys/uio.h R 65836 /usr/src/sys/sys/_iovec.h R 65836 /usr/src/sys/sys/conf.h R 65836 /usr/src/sys/vm/vm.h R 65836 ./machine/vm.h R 65836 /usr/src/sys/vm/pmap.h R 65836 ./machine/pmap.h R 65836 ./machine/pmap-v6.h R 65836 /usr/src/sys/dev/fdt/fdt_common.h R 65836 /usr/src/sys/sys/slicer.h R 65836 /usr/src/sys/contrib/libfdt/libfdt_env.h R 65836 /usr/src/sys/dev/ofw/ofw_bus.h R 65836 /usr/src/sys/dev/ofw/openfirm.h R 65836 ./machine/ofw_machdep.h R 65836 /usr/src/sys/sys/rman.h R 65836 ./machine/resource.h R 65836 ./ofw_bus_if.h R 65836 /usr/src/sys/dev/ofw/ofw_bus_subr.h R 65836 /usr/src/sys/dev/evdev/input.h R 65836 /usr/src/sys/dev/evdev/input-event-codes.h R 65836 /usr/src/sys/dev/evdev/evdev.h R 65836 /usr/src/sys/sys/kbio.h R 65836 /usr/src/sys/dev/kbd/kbdreg.h R 65836 ./machine/bus.h R 65836 ./machine/bus_dma.h R 65836 /usr/src/sys/sys/bus_dma.h R 65836 ./machine/cpu.h R 65836 ./machine/frame.h R 65836 /usr/src/sys/sys/signal.h R 65836 ./machine/signal.h R 65836 /usr/src/sys/sys/ucontext.h R 65836 ./machine/ucontext.h R 65836 /usr/src/sys/sys/_ucontext.h R 65836 ./machine/cpu-v6.h R 65836 ./machine/cpuinfo.h R 65836 ./machine/sysreg.h R 65836 ./machine/intr.h R 65836 /usr/src/sys/sys/intr.h R 65836 /usr/src/sys/arm/broadcom/bcm2835/bcm2835_mbox.h R 65836 /usr/src/sys/arm/broadcom/bcm2835/bcm2835_mbox_prop.h R 65836 /usr/src/sys/arm/broadcom/bcm2835/bcm2835_vcbus.h D 65836 bcm2835_ft5406.o-bd1d6a1e X 65836 1 0 X 65834 1 0 X 65827 1 0 # Stop 1478076388.449702 # Bye bye # grep mbox_if = ~/sys_typescripts/typescript_make_rpi2_nodebug_clang_bootstrap-amd64-host-= 2016-11-02:00:59:43 | more cd /usr/src/sys/modules; = MAKEOBJDIRPREFIX=3D/usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG/mo= dules KMODDIR=3D/boot/kernel MACHINE_CPUARCH=3Darm MACHINE=3Darm = MACHINE_ARCH=3Darmv6 MODULES_EXTRA=3D"dtb/rpi rpi_ft5406" = WITHOUT_MODULES=3D"" DEBUG_FLAGS=3D"-g" = __MPATH=3D"/usr/src/sys/pc98/pc98/canbus_if.m /usr/src/sys/isa/isa_if.m = /usr/src/sys/xen/xenbus/xenbusb_if.m /usr/src/sys/xen/xenbus/xenbus_if.m = /usr/src/sys/xen/xenmem/xenmem_if.m /usr/src/sys/net/ifdi_if.m = /usr/src/sys/geom/raid/g_raid_tr_if.m = /usr/src/sys/geom/raid/g_raid_md_if.m /usr/src/sys/geom/part/g_part_if.m = /usr/src/sys/dev/usb/controller/generic_usb_if.m = /usr/src/sys/dev/usb/usb_if.m = /usr/src/sys/dev/virtio/mmio/virtio_mmio_if.m = /usr/src/sys/dev/virtio/virtio_bus_if.m = /usr/src/sys/dev/virtio/virtio_if.m /usr/src/sys/dev/spibus/spibus_if.m = /usr/src/sys/dev/pccard/card_if.m /usr/src/sys/dev/pccard/power_if.m = /usr/src/sys/dev/sdhci/sdhci_if.m /usr/src/sys/dev/sound/midi/mpu_if.m = /usr/src/sys/dev/sound/midi/mpufoi_if.m = /usr/src/sys/dev/sound/midi/synth_if.m = /usr/src/sys/dev/sound/pci/hda/hdac_if.m = /usr/src/sys/dev/sound/pcm/feeder_if.m = /usr/src/sys/dev/sound/pcm/channel_if.m = /usr/src/sys/dev/sound/pcm/mixer_if.m = /usr/src/sys/dev/sound/pcm/ac97_if.m /usr/src/sys/dev/scc/scc_if.m = /usr/src/sys/dev/hyperv/vmbus/vmbus_if.m = /usr/src/sys/dev/bhnd/cores/chipc/bhnd_chipc_if.m = /usr/src/sys/dev/bhnd/bhndb/bhndb_if.m = /usr/src/sys/dev/bhnd/bhndb/bhndb_bus_if.m = /usr/src/sys/dev/bhnd/bhnd_bus_if.m = /usr/src/sys/dev/bhnd/nvram/bhnd_nvram_if.m = /usr/src/sys/dev/eisa/eisa_if.m /usr/src/sys/dev/adb/adb_hb_if.m = /usr/src/sys/dev/adb/adb_if.m /usr/src/sys/dev/mbox/mbox_if.m = /usr/src/sys/dev/altera/pio/pio_if.m = /usr/src/sys/dev/iscsi/icl_conn_if.m /usr/src/sys/dev/agp/agp_if.m = /usr/src/sys/dev/mmc/mmcbus_if.m /usr/src/sys/dev/mmc/mmcbr_if.m = /usr/src/sys/dev/ata/ata_if.m /usr/src/sys/dev/pci/pci_if.m = /usr/src/sys/dev/pci/pcib_if.m /usr/src/sys/dev/pci/pci_iov_if.m = /usr/src/sys/dev/cxgbe/t4_if.m /usr/src/sys/dev/gpio/gpiobus_if.m = /usr/src/sys/dev/gpio/gpio_if.m /usr/src/sys/dev/ow/owll_if.m = /usr/src/sys/dev/ow/own_if.m /usr/src/sys/dev/fdt/fdt_clock_if.m = /usr/src/sys/dev/fdt/fdt_pinctrl_if.m /usr/src/sys/dev/acpica/acpi_if.m = /usr/src/sys/dev/fb/fb_if.m /usr/src/sys/dev/vnic/lmac_if.m = /usr/src/sys/dev/mdio/mdio_if.m /usr/src/sys/dev/dwc/if_dwc_if.m = /usr/src/sys/dev/mii/miibus_if.m /usr/src/sys/dev/smbus/smbus_if.m = /usr/src/sys/dev/iicbus/iicbus_if.m /usr/src/sys/dev/iicbus/iicbb_if.m = /usr/src/sys/dev/ofw/ofw_bus_if.m /usr/src/sys/dev/ofw/ofw_if.m = /usr/src/sys/dev/ntb/ntb_if.m = /usr/src/sys/dev/acpi_support/acpi_wmi_if.m = /usr/src/sys/dev/extres/clk/clknode_if.m = /usr/src/sys/dev/extres/clk/clkdev_if.m = /usr/src/sys/dev/extres/regulator/regdev_if.m = /usr/src/sys/dev/extres/regulator/regnode_if.m = /usr/src/sys/dev/extres/hwreset/hwreset_if.m = /usr/src/sys/dev/extres/phy/phy_if.m = /usr/src/sys/dev/etherswitch/etherswitch_if.m = /usr/src/sys/dev/mvs/mvs_if.m /usr/src/sys/dev/ppbus/ppbus_if.m = /usr/src/sys/dev/uart/uart_if.m /usr/src/sys/dev/nand/nand_if.m = /usr/src/sys/dev/nand/nandbus_if.m /usr/src/sys/dev/nand/nfc_if.m = /usr/src/sys/arm/arm/platform_if.m /usr/src/sys/arm/arm/hdmi_if.m = /usr/src/sys/arm/ti/ti_gpio_if.m = /usr/src/sys/arm/allwinner/sunxi_dma_if.m = /usr/src/sys/arm/nvidia/tegra_soctherm_if.m = /usr/src/sys/sparc64/pci/ofw_pci_if.m /usr/src/sys/mips/beri/fdt_ic_if.m = /usr/src/sys/mips/mediatek/fdt_reset_if.m = /usr/src/sys/libkern/iconv_converter_if.m = /usr/src/sys/powerpc/aim/moea64_if.m = /usr/src/sys/powerpc/powerpc/pic_if.m = /usr/src/sys/powerpc/powerpc/platform_if.m = /usr/src/sys/powerpc/powerpc/mmu_if.m = /usr/src/sys/powerpc/powerpc/iommu_if.m = /usr/src/sys/opencrypto/cryptodev_if.m /usr/src/sys/kern/msi_if.m = /usr/src/sys/kern/pic_if.m /usr/src/sys/kern/device_if.m = /usr/src/sys/kern/clock_if.m /usr/src/sys/kern/bus_if.m = /usr/src/sys/kern/cpufreq_if.m /usr/src/sys/kern/linker_if.m = /usr/src/sys/kern/serdev_if.m /usr/src/sys/kgssapi/kgss_if.m" = KERNBUILDDIR=3D"/usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG" = SYSDIR=3D"/usr/src/sys" CONF_CFLAGS=3D"-march=3Darmv7a" WITH_CTF=3D"1" = make obj cd /usr/src/sys/modules; = MAKEOBJDIRPREFIX=3D/usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG/mo= dules KMODDIR=3D/boot/kernel MACHINE_CPUARCH=3Darm MACHINE=3Darm = MACHINE_ARCH=3Darmv6 MODULES_EXTRA=3D"dtb/rpi rpi_ft5406" = WITHOUT_MODULES=3D"" DEBUG_FLAGS=3D"-g" = __MPATH=3D"/usr/src/sys/pc98/pc98/canbus_if.m /usr/src/sys/isa/isa_if.m = /usr/src/sys/xen/xenbus/xenbusb_if.m /usr/src/sys/xen/xenbus/xenbus_if.m = /usr/src/sys/xen/xenmem/xenmem_if.m /usr/src/sys/net/ifdi_if.m = /usr/src/sys/geom/raid/g_raid_tr_if.m = /usr/src/sys/geom/raid/g_raid_md_if.m /usr/src/sys/geom/part/g_part_if.m = /usr/src/sys/dev/usb/controller/generic_usb_if.m = /usr/src/sys/dev/usb/usb_if.m = /usr/src/sys/dev/virtio/mmio/virtio_mmio_if.m = /usr/src/sys/dev/virtio/virtio_bus_if.m = /usr/src/sys/dev/virtio/virtio_if.m /usr/src/sys/dev/spibus/spibus_if.m = /usr/src/sys/dev/pccard/card_if.m /usr/src/sys/dev/pccard/power_if.m = /usr/src/sys/dev/sdhci/sdhci_if.m /usr/src/sys/dev/sound/midi/mpu_if.m = /usr/src/sys/dev/sound/midi/mpufoi_if.m = /usr/src/sys/dev/sound/midi/synth_if.m = /usr/src/sys/dev/sound/pci/hda/hdac_if.m = /usr/src/sys/dev/sound/pcm/feeder_if.m = /usr/src/sys/dev/sound/pcm/channel_if.m = /usr/src/sys/dev/sound/pcm/mixer_if.m = /usr/src/sys/dev/sound/pcm/ac97_if.m /usr/src/sys/dev/scc/scc_if.m = /usr/src/sys/dev/hyperv/vmbus/vmbus_if.m = /usr/src/sys/dev/bhnd/cores/chipc/bhnd_chipc_if.m = /usr/src/sys/dev/bhnd/bhndb/bhndb_if.m = /usr/src/sys/dev/bhnd/bhndb/bhndb_bus_if.m = /usr/src/sys/dev/bhnd/bhnd_bus_if.m = /usr/src/sys/dev/bhnd/nvram/bhnd_nvram_if.m = /usr/src/sys/dev/eisa/eisa_if.m /usr/src/sys/dev/adb/adb_hb_if.m = /usr/src/sys/dev/adb/adb_if.m /usr/src/sys/dev/mbox/mbox_if.m = /usr/src/sys/dev/altera/pio/pio_if.m = /usr/src/sys/dev/iscsi/icl_conn_if.m /usr/src/sys/dev/agp/agp_if.m = /usr/src/sys/dev/mmc/mmcbus_if.m /usr/src/sys/dev/mmc/mmcbr_if.m = /usr/src/sys/dev/ata/ata_if.m /usr/src/sys/dev/pci/pci_if.m = /usr/src/sys/dev/pci/pcib_if.m /usr/src/sys/dev/pci/pci_iov_if.m = /usr/src/sys/dev/cxgbe/t4_if.m /usr/src/sys/dev/gpio/gpiobus_if.m = /usr/src/sys/dev/gpio/gpio_if.m /usr/src/sys/dev/ow/owll_if.m = /usr/src/sys/dev/ow/own_if.m /usr/src/sys/dev/fdt/fdt_clock_if.m = /usr/src/sys/dev/fdt/fdt_pinctrl_if.m /usr/src/sys/dev/acpica/acpi_if.m = /usr/src/sys/dev/fb/fb_if.m /usr/src/sys/dev/vnic/lmac_if.m = /usr/src/sys/dev/mdio/mdio_if.m /usr/src/sys/dev/dwc/if_dwc_if.m = /usr/src/sys/dev/mii/miibus_if.m /usr/src/sys/dev/smbus/smbus_if.m = /usr/src/sys/dev/iicbus/iicbus_if.m /usr/src/sys/dev/iicbus/iicbb_if.m = /usr/src/sys/dev/ofw/ofw_bus_if.m /usr/src/sys/dev/ofw/ofw_if.m = /usr/src/sys/dev/ntb/ntb_if.m = /usr/src/sys/dev/acpi_support/acpi_wmi_if.m = /usr/src/sys/dev/extres/clk/clknode_if.m = /usr/src/sys/dev/extres/clk/clkdev_if.m = /usr/src/sys/dev/extres/regulator/regdev_if.m = /usr/src/sys/dev/extres/regulator/regnode_if.m = /usr/src/sys/dev/extres/hwreset/hwreset_if.m = /usr/src/sys/dev/extres/phy/phy_if.m = /usr/src/sys/dev/etherswitch/etherswitch_if.m = /usr/src/sys/dev/mvs/mvs_if.m /usr/src/sys/dev/ppbus/ppbus_if.m = /usr/src/sys/dev/uart/uart_if.m /usr/src/sys/dev/nand/nand_if.m = /usr/src/sys/dev/nand/nandbus_if.m /usr/src/sys/dev/nand/nfc_if.m = /usr/src/sys/arm/arm/platform_if.m /usr/src/sys/arm/arm/hdmi_if.m = /usr/src/sys/arm/ti/ti_gpio_if.m = /usr/src/sys/arm/allwinner/sunxi_dma_if.m = /usr/src/sys/arm/nvidia/tegra_soctherm_if.m = /usr/src/sys/sparc64/pci/ofw_pci_if.m /usr/src/sys/mips/beri/fdt_ic_if.m = /usr/src/sys/mips/mediatek/fdt_reset_if.m = /usr/src/sys/libkern/iconv_converter_if.m = /usr/src/sys/powerpc/aim/moea64_if.m = /usr/src/sys/powerpc/powerpc/pic_if.m = /usr/src/sys/powerpc/powerpc/platform_if.m = /usr/src/sys/powerpc/powerpc/mmu_if.m = /usr/src/sys/powerpc/powerpc/iommu_if.m = /usr/src/sys/opencrypto/cryptodev_if.m /usr/src/sys/kern/msi_if.m = /usr/src/sys/kern/pic_if.m /usr/src/sys/kern/device_if.m = /usr/src/sys/kern/clock_if.m /usr/src/sys/kern/bus_if.m = /usr/src/sys/kern/cpufreq_if.m /usr/src/sys/kern/linker_if.m = /usr/src/sys/kern/serdev_if.m /usr/src/sys/kgssapi/kgss_if.m" = KERNBUILDDIR=3D"/usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG" = SYSDIR=3D"/usr/src/sys" CONF_CFLAGS=3D"-march=3Darmv7a" WITH_CTF=3D"1" = make all Building /usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG/mbox_if.c = /usr/src/sys/modules/rpi_ft5406/../../arm/broadcom/bcm2835//bcm2835_ft5406= .c:65:10: fatal error: 'mbox_if.h' file not found #include "mbox_if.h" # more /usr/src/sys/arm/conf/RPI2-NODBG=20 # # RPI2 -- Custom configuration for the Raspberry Pi 2 # include "RPI2" ident RPI2-NODBG makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols options ALT_BREAK_TO_DEBUGGER options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger #options VERBOSE_SYSINIT # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE #options KTR #options KTR_MASK=3DKTR_TRAP ##options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # Disable any extra checking for. . . nooptions DEADLKRES # Enable the deadlock resolver nooptions INVARIANTS # Enable calls of extra sanity = checking nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect = deadlocks and cycles nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed nooptions DIAGNOSTIC nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones # more = ~/sys_build_scripts.amd64-host/make_rpi2_nodebug_clang_bootstrap-amd64-hos= t.sh=20 kldload -n filemon && \ script = ~/sys_typescripts/typescript_make_rpi2_nodebug_clang_bootstrap-amd64-host-= $(date +%Y-%m-%d:%H:%M:%S) \ env __MAKE_CONF=3D"/root/src.configs/make.conf" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host= " \ WITH_META_MODE=3Dyes \ MAKEOBJDIRPREFIX=3D"/usr/obj/rpi2_clang" \ make $* # more ~/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host=20 TO_TYPE=3Darmv6 # KERNCONF=3DRPI2-NODBG TARGET=3Darm .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # #CPUTYPE=3Dsoft WITH_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D WITHOUT_LIBSOFT=3D # WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_DEBUG_FILES=3D # XCFLAGS+=3D -mcpu=3Dcortex-a7 XCXXFLAGS+=3D -mcpu=3Dcortex-a7 # There is no XCPPFLAGS but XCPP gets XCFLAGS content. # =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Wed Nov 2 14:23:33 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2BC5FC2A3F4 for ; Wed, 2 Nov 2016 14:23:33 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [IPv6:2001:418:3fd::f7]) (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 A45B116EB for ; Wed, 2 Nov 2016 14:23:32 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [10.100.0.31] (haymarket.m5p.com [10.100.0.31]) by mailhost.m5p.com (8.15.2/8.15.2) with ESMTP id uA2ENOCL012016; Wed, 2 Nov 2016 10:23:29 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Subject: Re: huge nanosleep variance on 11-stable To: freebsd-stable@freebsd.org References: <6167392c-c37a-6e39-aa22-ca45435d6088@gmail.com> <1c3f4599-8aef-471a-3a39-49d913f1a4e5@gmail.com> From: George Mitchell Cc: rkoberman@gmail.com, jason.harmening@gmail.com Message-ID: Date: Wed, 2 Nov 2016 10:23:24 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (mailhost.m5p.com [10.100.0.247]); Wed, 02 Nov 2016 10:23:30 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 14:23:33 -0000 On 11/01/16 23:45, Kevin Oberman wrote: > On Tue, Nov 1, 2016 at 2:36 PM, Jason Harmening > wrote: > >> Sorry, that should be ~*30ms* to get 30fps, though the variance is still >> up to 500ms for me either way. >> >> On 11/01/16 14:29, Jason Harmening wrote: >>> repro code is at http://pastebin.com/B68N4AFY if anyone's interested. >>> >>> On 11/01/16 13:58, Jason Harmening wrote: >>>> Hi everyone, >>>> >>>> I recently upgraded my main amd64 server from 10.3-stable (r302011) to >>>> 11.0-stable (r308099). It went smoothly except for one big issue: >>>> certain applications (but not the system as a whole) respond very >>>> sluggishly, and video playback of any kind is extremely choppy. >>>> >>>> [...] > I eliminated the annoyance by change scheduler from ULE to 4BSD. That was > it, but I have not seen the issue since. I'd be very interested in whether > the scheduler is somehow impacting timing functions or it's s different > issue. I've felt that there was something off in ULE for some time, but it > was not until these annoying hiccups convinced me to try going back to > 4BSD. > > Tip o' the hat to Doug B. for his suggestions that ULE may have issues that > impacted interactivity. > [...] Not to beat a dead horse, but I've been a non-fan of SCHED_ULE since it was first introduced, and I don't like it even today. I run the distributed.net client on my machines, but even without that, ULE screws interactive behavior. With distributed.net running and ULE, a make buildworld/make buildkernel takes 10 2/3 hours on 10.3-RELEASE on a 6-CPU machine versus 2 1/2 hours on the same machine with 4BSD and distributed.net running. I'm told that SCHED_ULE is the greatest thing since sliced bread for some compute load or other (details are scarce), but I (fortunately) don't often have to run heavy server type loads; and for everyday use (even without distributed.net running), SCHED_4BSD is my choice by far. It's too bad I can't run freebsd_update with it, though. I promise to shut up about this now. -- George From owner-freebsd-stable@freebsd.org Wed Nov 2 16:11:21 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E666C2BC1F for ; Wed, 2 Nov 2016 16:11:21 +0000 (UTC) (envelope-from jason.harmening@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 304B11B00 for ; Wed, 2 Nov 2016 16:11:21 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: by mail-pf0-x235.google.com with SMTP id 189so14335381pfz.3 for ; Wed, 02 Nov 2016 09:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=e/6e1Yf1aq/iYtfEq0ID98V84FbhFDHOHv3Wa8hdnZw=; b=xHBT/Aif1NBNubA48sjV9pKWYYp17+bn1nI83HIEp1wxj6iqXcPbSioJAaLz5JKE90 xmrq8twGi2kvPSJtslCgWs/H6W5+2iJ5LDulPa9nY9RdtzUcHA5WplKPrtjFNttNKlw1 q5X0foumX87D6W/suWz2XhzxwXFprR0e1I31sDuNCwKw6h2StQHiIwR6lB7Gu4OI84w2 6Z+i+5qfoXv8gBj6UPoaIQhzGyvKErCKOePlnvOcQ8gQlWA7z03vQFaJ9fn7GaA1KeXM eS+L3aCunpHGQEOAOnIW1QhU61XAcRO6IaZTTHwJofRbODba5Rxphp7/8A8I0xL3sx5H X2ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=e/6e1Yf1aq/iYtfEq0ID98V84FbhFDHOHv3Wa8hdnZw=; b=khySFun/FWqCVAThMo6gCDYCCkglKRRBYMfhMBBX+tZa6sm9NNpLWPpp060Sk++rDp 0kz4HO4bvPzxlgS/VJymZicEiqb8TIh8Q/MolK0qZFOOm9DURH8YRBt7cFeYq7tnGKlX DnEgSjEwQT/2hM/VdQu1auborBiuJFi9GTqET00CTzDV+Lkl/8MWDi75e60+fg0p/1g3 mpxUH1KDgiNvZ1XJUTFncFGOuqJnNqj5DA2ywLEb9qlU261gWJ+J8P0BbWMAYDkEQzrH +EZWzb0OGRud+A9NrXoZwWnI+3mEmhGWmcRRHiHHlhV3Ffl82rl8rRBsveUNYOqAJR92 LKWA== X-Gm-Message-State: ABUngvfug86yAWJomYNVTTE8TCgY1iaI9NCbVvynzYyTjdxDHrHjr0anUI2dJO+bkpzdOQ== X-Received: by 10.99.9.129 with SMTP id 123mr6769059pgj.84.1478103080504; Wed, 02 Nov 2016 09:11:20 -0700 (PDT) Received: from corona.austin.rr.com (c-67-188-30-11.hsd1.ca.comcast.net. [67.188.30.11]) by smtp.googlemail.com with ESMTPSA id p14sm5861505par.25.2016.11.02.09.11.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Nov 2016 09:11:19 -0700 (PDT) Subject: Re: huge nanosleep variance on 11-stable To: Konstantin Belousov References: <6167392c-c37a-6e39-aa22-ca45435d6088@gmail.com> <20161102075509.GF54029@kib.kiev.ua> Cc: freebsd-stable@freebsd.org From: Jason Harmening Message-ID: <3620f62e-0f4c-2d62-dcf8-e2fdff459250@gmail.com> Date: Wed, 2 Nov 2016 09:18:15 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161102075509.GF54029@kib.kiev.ua> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="E2nnDG53p2ht9ac2Fldin6Avh8wNJekfL" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 16:11:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --E2nnDG53p2ht9ac2Fldin6Avh8wNJekfL Content-Type: multipart/mixed; boundary="2ni9r6VQ6UvSBsCuSqjvgPAVDq1SP7gs6"; protected-headers="v1" From: Jason Harmening To: Konstantin Belousov Cc: freebsd-stable@freebsd.org Message-ID: <3620f62e-0f4c-2d62-dcf8-e2fdff459250@gmail.com> Subject: Re: huge nanosleep variance on 11-stable References: <6167392c-c37a-6e39-aa22-ca45435d6088@gmail.com> <20161102075509.GF54029@kib.kiev.ua> In-Reply-To: <20161102075509.GF54029@kib.kiev.ua> --2ni9r6VQ6UvSBsCuSqjvgPAVDq1SP7gs6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11/02/16 00:55, Konstantin Belousov wrote: > On Tue, Nov 01, 2016 at 02:29:13PM -0700, Jason Harmening wrote: >> repro code is at http://pastebin.com/B68N4AFY if anyone's interested. >> >> On 11/01/16 13:58, Jason Harmening wrote: >>> Hi everyone, >>> >>> I recently upgraded my main amd64 server from 10.3-stable (r302011) t= o >>> 11.0-stable (r308099). It went smoothly except for one big issue: >>> certain applications (but not the system as a whole) respond very >>> sluggishly, and video playback of any kind is extremely choppy. >>> >>> The system is under very light load, and I see no evidence of abnorma= l >>> interrupt latency or interrupt load. More interestingly, if I place = the >>> system under full load (~0.0% idle) the problem *disappears* and >>> playback/responsiveness are smooth and quick. >>> >>> Running ktrace on some of the affected apps points me at the problem:= >>> huge variance in the amount of time spent in the nanosleep system cal= l. >>> A sleep of, say, 5ms might take anywhere from 5ms to ~500ms from entr= y >>> to return of the syscall. OTOH, anything CPU-bound or that waits on >>> condvars or I/O interrupts seems to work fine, so this doesn't seem t= o >>> be an issue with overall system latency. >>> >>> I can repro this with a simple program that just does a 3ms usleep in= a >>> tight loop (i.e. roughly the amount of time a video player would slee= p >>> between frames @ 30fps). At light load ktrace will show the huge >>> nanosleep variance; under heavy load every nanosleep will complete in= >>> almost exactly 3ms. >>> >>> FWIW, I don't see this on -current, although right now all my -curren= t >>> images are VMs on different HW so that might not mean anything. I'm = not >>> aware of any recent timer- or scheduler- specific changes, so I'm >>> wondering if perhaps the recent IPI or taskqueue changes might be >>> somehow to blame. >>> >>> I'm not especially familiar w/ the relevant parts of the kernel, so a= ny >>> guidance on where I should focus my debugging efforts would be much >>> appreciated. >>> >=20 > I am confident, with very high degree of certainity, that the issue is = a > CPU bug in interaction between deep sleep states (C6) and LAPIC timer. > Check what hardware is used for the eventtimers, > sysctl kern.eventtimer.timer > It should report LAPIC, and you should get rid of jitter with setting > the sysctl to HPET. Also please show the first 50 lines of the verbose= > boot dmesg. >=20 > I know that the Nehalem cores are affected, I do not know was the bug > fixed for Westmere or not. I asked Intel contact about the problem, > but got no response. It is not unreasonable, given that the CPUs are > beyond their support time. I intended to automatically bump HPET quali= ty > on Nehalem and might be Westmere, but I was not able to check Westmere,= > and waited for more information, so this was forgotten. > BTW, using the latest CPU microcode did not helped. >=20 > After I discovered this, I specifically looked at my Sandy and Haswell > test systems, but they do not exhibit such problem. >=20 > In the Intel document 320836-036US 'Intel(R) CoreTM i7-900 Desktop > Processor Extreme Edition Series and Intel(R) CoreTM i7-900 Desktop > Processor Series Specification Update', there are two erratas which > might be relevant and show the LAPIC bugs: AAJ47 (but default is to > not use periodic mode), and AAJ121. The 121 might be the real cause, > but Intel does not provide enough details to understand. And of > course, the suggested workaround is not feasible. >=20 > Googling for 'Windows LAPIC Nehalem' shows very interesting results, > in particular, > https://support.microsoft.com/en-us/kb/2000977 (which I think is the bu= g > you see) and > https://hardware.slashdot.org/story/09/11/28/1723257/microsoft-advice-a= gainst-nehalem-xeons-snuffed-out > for amusement. >=20 I think you are probably right. Hacking out the Intel-specific additions to C-state parsing in acpi_cpu_cx_cst() from r282678 (thus going back to sti;hlt instead of monitor+mwait at C1) fixed the problem for me. But r282678 also had the effect of enabling C2 and C3 on my system, because ACPI only presents MWAIT entries for those states and not p_lvlx. I will try switching to HPET when I have more time to test; may be a few days. --2ni9r6VQ6UvSBsCuSqjvgPAVDq1SP7gs6-- --E2nnDG53p2ht9ac2Fldin6Avh8wNJekfL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJYGhHIXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRENkY3MTQyREU0MTU4MTgyRkZDNUU2ODVC QjlGOEJGOTkyODQxRDFCAAoJELufi/mShB0borAH/1ZK64fGpBw6Y4QiMG1Vs/3q 7AecQZzWuf9VK9Z5V8iZYLgxud6fS2ZZZdiFGoPladfpg/I7CN3NXh5YfOjuWHfr RLwAOyWGpAaxzCcA09o8h+3x5sAq1NM6v6xi1WtKo8mHFVKanymJDiAjRIqdyD7A pQpvyfADFhFw2148t/kwhtJgsMDCfrW9lR+aCsfYJ/qrZrc+yMtvJq76mUNcQEZf Qms+t5FDBF4LJP62r72wHplUm1jckMtAOs9grVGhflHVXWbCKdr3e2I1Gh23MkOR vIduGdhpNIqesIRsPhCS2sWZ6kiDVUJ92gvZfONjdonY5D087YxahTGUiX6itw8= =aB6/ -----END PGP SIGNATURE----- --E2nnDG53p2ht9ac2Fldin6Avh8wNJekfL-- From owner-freebsd-stable@freebsd.org Wed Nov 2 16:28:19 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6AD19C2B8B6 for ; Wed, 2 Nov 2016 16:28:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D62111B83 for ; Wed, 2 Nov 2016 16:28:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id uA2GS8oC094823 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 2 Nov 2016 18:28:08 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uA2GS8oC094823 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uA2GS8bQ094822; Wed, 2 Nov 2016 18:28:08 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 2 Nov 2016 18:28:08 +0200 From: Konstantin Belousov To: Jason Harmening Cc: freebsd-stable@freebsd.org Subject: Re: huge nanosleep variance on 11-stable Message-ID: <20161102162808.GI54029@kib.kiev.ua> References: <6167392c-c37a-6e39-aa22-ca45435d6088@gmail.com> <20161102075509.GF54029@kib.kiev.ua> <3620f62e-0f4c-2d62-dcf8-e2fdff459250@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3620f62e-0f4c-2d62-dcf8-e2fdff459250@gmail.com> User-Agent: Mutt/1.7.1 (2016-10-04) 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-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 16:28:19 -0000 On Wed, Nov 02, 2016 at 09:18:15AM -0700, Jason Harmening wrote: > I think you are probably right. Hacking out the Intel-specific > additions to C-state parsing in acpi_cpu_cx_cst() from r282678 (thus > going back to sti;hlt instead of monitor+mwait at C1) fixed the problem > for me. But r282678 also had the effect of enabling C2 and C3 on my > system, because ACPI only presents MWAIT entries for those states and > not p_lvlx. You can do the same with "debug.acpi.disabled=mwait" loader tunable without hacking the code. And set sysctl hw.acpi.cpu.cx_lowest to C1 to enforce use of hlt instruction even when mwait states were requested. From owner-freebsd-stable@freebsd.org Wed Nov 2 19:25:53 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 13C73C2CB63 for ; Wed, 2 Nov 2016 19:25:53 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-56.reflexion.net [208.70.210.56]) (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 B47D915E4 for ; Wed, 2 Nov 2016 19:25:52 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15237 invoked from network); 2 Nov 2016 19:26:48 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 2 Nov 2016 19:26:48 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.10.0) with SMTP; Wed, 02 Nov 2016 15:25:59 -0400 (EDT) Received: (qmail 15429 invoked from network); 2 Nov 2016 19:25:59 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 Nov 2016 19:25:59 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 616F6EC9208; Wed, 2 Nov 2016 12:16:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: stable/11 -r308135 Build for RPI2 failed for: . . ./bcm2835_ft5406.c:65:10: fatal error: 'mbox_if.h' file not found From: Mark Millard In-Reply-To: Date: Wed, 2 Nov 2016 12:16:41 -0700 Cc: Bryan Drewery Content-Transfer-Encoding: quoted-printable Message-Id: <8400BD9A-E08C-4578-8409-274B1BC30C98@dsl-only.net> References: To: FreeBSD Toolchain , FreeBSD-STABLE Mailing List , freebsd-arm X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 19:25:53 -0000 Quick top post reporting that a build-order-race for -j use seems = likely: the clean-then-build sequence > Command: env __MAKE_CONF=3D/root/src.configs/make.conf = SRC_ENV_CONF=3D/root/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host = WITH_META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/rpi2_clang make = cleanworld >=20 > Command: env __MAKE_CONF=3D/root/src.configs/make.conf = SRC_ENV_CONF=3D/root/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host = WITH_META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/rpi2_clang make -j 5 = buildworld buildkernel that used -j 5 for buildworld buildkernel got the problem again. But = following that failure by doing just buildkernel without the -j 5: > Command: env __MAKE_CONF=3D/root/src.configs/make.conf = SRC_ENV_CONF=3D/root/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host = WITH_META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/rpi2_clang make = buildkernel completed the rest of the build just fine, creating the = previously-missing file before trying to use it. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Nov-2, at 3:13 AM, Mark Millard wrote: > Lack of dependency? Race? (I've not isolated why this happened yet but = I was using -j 5 for buildworld buildkernel .) >=20 > This was a cross-build attempt from an amd64 context: >=20 > # uname -apKU > FreeBSD FreeBSDx64 11.0-STABLE FreeBSD 11.0-STABLE #1 r308135M: Tue = Nov 1 23:48:47 PDT 2016 = root@FreeBSDx64:/usr/obj/amd64_clang/amd64.amd64/usr/src/sys/GENERIC-NODBG= amd64 amd64 1100506 1100506 >=20 > # svnlite info /usr/src/ | grep "Re[lv]" > Relative URL: ^/stable/11 > Revision: 308135 > Last Changed Rev: 308135 >=20 > # find /usr/src/sys/ -name "*files*" -exec grep mbox_if {} \; -print | = more > dev/mbox/mbox_if.m standard > /usr/src/sys/arm/broadcom/bcm2835/files.bcm283x > dev/mbox/mbox_if.m optional = ti_mbox > /usr/src/sys/arm/ti/files.ti >=20 > # find /usr/obj/rpi2_clang/arm.armv6/ -name mbox_if.h -print | more = = = =20 > # >=20 > (So no mbox_if.h file is present in the build tree.) >=20 > # head = ~/sys_typescripts/typescript_make_rpi2_nodebug_clang_bootstrap-amd64-host-= 2016-11-02:00:59:43 > Script started on Wed Nov 2 00:59:43 2016 > Command: env __MAKE_CONF=3D/root/src.configs/make.conf = SRC_ENV_CONF=3D/root/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host = WITH_META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/rpi2_clang make -j 5 = buildworld buildkernel > . . . > --- all_subdir_rpi_ft5406 --- > --- bcm2835_ft5406.o --- > = /usr/src/sys/modules/rpi_ft5406/../../arm/broadcom/bcm2835//bcm2835_ft5406= .c:65:10: fatal error: 'mbox_if.h' file not found > #include "mbox_if.h" > ^ > 1 error generated. > *** [bcm2835_ft5406.o] Error code 1 >=20 > make[4]: stopped in /usr/src/sys/modules/rpi_ft5406 > .ERROR_TARGET=3D'bcm2835_ft5406.o' > = .ERROR_META_FILE=3D'/usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG/m= odules/usr/src/sys/modules/rpi_ft5406/bcm2835_ft5406.o.meta' > .MAKE.LEVEL=3D'4' > MAKEFILE=3D'' > .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes= verbose' > .CURDIR=3D'/usr/src/sys/modules/rpi_ft5406' > .MAKE=3D'make' > = .OBJDIR=3D'/usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG/modules/us= r/src/sys/modules/rpi_ft5406' > .TARGETS=3D'all' > DESTDIR=3D'' > LD_LIBRARY_PATH=3D'' > MACHINE=3D'arm' > MACHINE_ARCH=3D'armv6' > = MAKEOBJDIRPREFIX=3D'/usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG/m= odules' > MAKESYSPATH=3D'/usr/src/share/mk' > MAKE_VERSION=3D'20160606' > = PATH=3D'/usr/obj/rpi2_clang/arm.armv6/usr/src/tmp/legacy/usr/sbin:/usr/obj= /rpi2_clang/arm.armv6/usr/src/tmp/legacy/usr/bin:/usr/obj/rpi2_clang/arm.a= rmv6/usr/src/tmp/legacy/bin:/usr/obj/rpi2_clang/arm.armv6/usr/src/tmp/usr/= sbin:/usr/obj/rpi2_clang/arm.armv6/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbi= n:/usr/bin' > SRCTOP=3D'/usr/src' > = OBJTOP=3D'/usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG/modules/usr= /src' > .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host = /usr/src/share/mk/bsd.mkopt.mk /root/src.configs/make.conf = /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk = /etc/src.conf /usr/src/sys/modules/rpi_ft5406/Makefile = /usr/src/share/mk/bsd.kmod.mk /usr/src/sys/conf/kmod.mk = /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk = /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk = /usr/src/share/mk/src.init.mk = /usr/src/sys/modules/rpi_ft5406/../Makefile.inc = /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk = /usr/src/sys/conf/kern.opts.mk /usr/src/sys/conf/config.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/sys/conf/kern.mk' > .PATH=3D'. /usr/src/sys/modules/rpi_ft5406 = /usr/src/sys/modules/rpi_ft5406/../../arm/broadcom/bcm2835/ = /usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG' > 1 error > . . . >=20 > # less = /usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG/modules/usr/src/sys/m= odules/rpi_ft5406/bcm2835_ft5406.o.meta > # Meta data file = /usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG/modules/usr/src/sys/m= odules/rpi_ft5406/bcm2835_ft5406.o.meta > CMD cc -mcpu=3Dcortex-a7 -O -pipe -Werror -D_KERNEL -DKLD_MODULE = -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include = /usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG/opt_global.h -I. = -I/usr/src/sys -fno-common -g -funwind-tables = -I/usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG -march=3Darmv7a = -ffreestanding -fwrapv -gdwarf-2 -Wall -Wredundant-decls = -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign = -D__printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs = -fdiagnostics-show-option -Wno-unknown-pragmas = -Wno-error-tautological-compare -Wno-error-empty-body = -Wno-error-parentheses-equality -Wno-error-unused-function = -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-movt = -mfpu=3Dnone -std=3Diso9899:1999 -c = /usr/src/sys/modules/rpi_ft5406/../../arm/broadcom/bcm2835//bcm2835_ft5406= .c -o bcm2835_ft5406.o > CMD ctfconvert -L VERSION -g bcm2835_ft5406.o > CWD = /usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG/modules/usr/src/sys/m= odules/rpi_ft5406 > TARGET bcm2835_ft5406.o > -- command output -- > = /usr/src/sys/modules/rpi_ft5406/../../arm/broadcom/bcm2835//bcm2835_ft5406= .c:65:10: fatal error: 'mbox_if.h' file not found > #include "mbox_if.h" > ^ > 1 error generated. > *** Error code 1 >=20 > -- filemon acquired metadata -- > # filemon version 5 > # Target pid 65803 > # Start 1478076388.181546 > V 5 > E 65827 /bin/sh > R 65827 /etc/libmap.conf > R 65827 /var/run/ld-elf.so.hints > R 65827 /lib/libedit.so.7 > R 65827 /lib/libc.so.7 > R 65827 /lib/libncursesw.so.8 > F 65827 65834 > E 65834 /usr/obj/rpi2_clang/arm.armv6/usr/src/tmp/usr/bin/cc > F 65834 65836 > E 65836 /usr/obj/rpi2_clang/arm.armv6/usr/src/tmp/usr/bin/cc > R 65836 = /usr/src/sys/modules/rpi_ft5406/../../arm/broadcom/bcm2835//bcm2835_ft5406= .c > R 65836 bcm2835_ft5406.o-bd1d6a1e > W 65836 bcm2835_ft5406.o-bd1d6a1e > R 65836 = /usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG/opt_global.h > R 65836 /usr/src/sys/sys/cdefs.h > R 65836 /usr/src/sys/sys/param.h > R 65836 /usr/src/sys/sys/_null.h > R 65836 /usr/src/sys/sys/types.h > R 65836 ./machine/endian.h > R 65836 /usr/src/sys/sys/_types.h > R 65836 ./machine/_types.h > R 65836 /usr/src/sys/sys/_pthreadtypes.h > R 65836 /usr/src/sys/sys/_stdint.h > R 65836 /usr/src/sys/sys/select.h > R 65836 /usr/src/sys/sys/_sigset.h > R 65836 /usr/src/sys/sys/_timeval.h > R 65836 /usr/src/sys/sys/timespec.h > R 65836 /usr/src/sys/sys/_timespec.h > R 65836 /usr/src/sys/sys/syslimits.h > R 65836 /usr/src/sys/sys/errno.h > R 65836 /usr/src/sys/sys/time.h > R 65836 /usr/src/sys/sys/priority.h > R 65836 ./machine/param.h > R 65836 ./machine/_align.h > R 65836 /usr/src/sys/sys/systm.h > R 65836 ./machine/atomic.h > R 65836 ./machine/armreg.h > R 65836 ./machine/cpuconf.h > R 65836 ./machine/atomic-v6.h > R 65836 ./machine/cpufunc.h > R 65836 /usr/src/sys/sys/callout.h > R 65836 /usr/src/sys/sys/_callout.h > R 65836 /usr/src/sys/sys/queue.h > R 65836 /usr/src/sys/sys/stdint.h > R 65836 ./machine/_stdint.h > R 65836 /usr/src/sys/sys/libkern.h > R 65836 /usr/src/sys/sys/bus.h > R 65836 ./machine/_limits.h > R 65836 ./machine/_bus.h > R 65836 /usr/src/sys/sys/_bus_dma.h > R 65836 /usr/src/sys/sys/ioccom.h > R 65836 /usr/src/sys/sys/eventhandler.h > R 65836 /usr/src/sys/sys/lock.h > R 65836 /usr/src/sys/sys/_lock.h > R 65836 /usr/src/sys/sys/ktr_class.h > R 65836 /usr/src/sys/sys/ktr.h > R 65836 /usr/src/sys/sys/_cpuset.h > R 65836 /usr/src/sys/sys/_bitset.h > R 65836 /usr/src/sys/sys/mutex.h > R 65836 /usr/src/sys/sys/_mutex.h > R 65836 /usr/src/sys/sys/pcpu.h > R 65836 /usr/src/sys/sys/_sx.h > R 65836 /usr/src/sys/sys/_rmlock.h > R 65836 /usr/src/sys/sys/vmmeter.h > R 65836 /usr/src/sys/sys/resource.h > R 65836 ./machine/pcpu.h > R 65836 /usr/src/sys/sys/lock_profile.h > R 65836 /usr/src/sys/sys/lockstat.h > R 65836 /usr/src/sys/sys/sdt.h > R 65836 /usr/src/sys/sys/linker_set.h > R 65836 /usr/src/sys/sys/kobj.h > R 65836 ./device_if.h > R 65836 ./bus_if.h > R 65836 /usr/src/sys/sys/cpu.h > R 65836 /usr/src/sys/sys/kernel.h > R 65836 /usr/src/sys/sys/malloc.h > R 65836 /usr/src/sys/sys/module.h > R 65836 /usr/src/sys/sys/condvar.h > R 65836 /usr/src/sys/sys/sysctl.h > R 65836 /usr/src/sys/sys/selinfo.h > R 65836 /usr/src/sys/sys/event.h > R 65836 /usr/src/sys/sys/poll.h > R 65836 /usr/src/sys/sys/uio.h > R 65836 /usr/src/sys/sys/_iovec.h > R 65836 /usr/src/sys/sys/conf.h > R 65836 /usr/src/sys/vm/vm.h > R 65836 ./machine/vm.h > R 65836 /usr/src/sys/vm/pmap.h > R 65836 ./machine/pmap.h > R 65836 ./machine/pmap-v6.h > R 65836 /usr/src/sys/dev/fdt/fdt_common.h > R 65836 /usr/src/sys/sys/slicer.h > R 65836 /usr/src/sys/contrib/libfdt/libfdt_env.h > R 65836 /usr/src/sys/dev/ofw/ofw_bus.h > R 65836 /usr/src/sys/dev/ofw/openfirm.h > R 65836 ./machine/ofw_machdep.h > R 65836 /usr/src/sys/sys/rman.h > R 65836 ./machine/resource.h > R 65836 ./ofw_bus_if.h > R 65836 /usr/src/sys/dev/ofw/ofw_bus_subr.h > R 65836 /usr/src/sys/dev/evdev/input.h > R 65836 /usr/src/sys/dev/evdev/input-event-codes.h > R 65836 /usr/src/sys/dev/evdev/evdev.h > R 65836 /usr/src/sys/sys/kbio.h > R 65836 /usr/src/sys/dev/kbd/kbdreg.h > R 65836 ./machine/bus.h > R 65836 ./machine/bus_dma.h > R 65836 /usr/src/sys/sys/bus_dma.h > R 65836 ./machine/cpu.h > R 65836 ./machine/frame.h > R 65836 /usr/src/sys/sys/signal.h > R 65836 ./machine/signal.h > R 65836 /usr/src/sys/sys/ucontext.h > R 65836 ./machine/ucontext.h > R 65836 /usr/src/sys/sys/_ucontext.h > R 65836 ./machine/cpu-v6.h > R 65836 ./machine/cpuinfo.h > R 65836 ./machine/sysreg.h > R 65836 ./machine/intr.h > R 65836 /usr/src/sys/sys/intr.h > R 65836 /usr/src/sys/arm/broadcom/bcm2835/bcm2835_mbox.h > R 65836 /usr/src/sys/arm/broadcom/bcm2835/bcm2835_mbox_prop.h > R 65836 /usr/src/sys/arm/broadcom/bcm2835/bcm2835_vcbus.h > D 65836 bcm2835_ft5406.o-bd1d6a1e > X 65836 1 0 > X 65834 1 0 > X 65827 1 0 > # Stop 1478076388.449702 > # Bye bye >=20 >=20 > # grep mbox_if = ~/sys_typescripts/typescript_make_rpi2_nodebug_clang_bootstrap-amd64-host-= 2016-11-02:00:59:43 | more > cd /usr/src/sys/modules; = MAKEOBJDIRPREFIX=3D/usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG/mo= dules KMODDIR=3D/boot/kernel MACHINE_CPUARCH=3Darm MACHINE=3Darm = MACHINE_ARCH=3Darmv6 MODULES_EXTRA=3D"dtb/rpi rpi_ft5406" = WITHOUT_MODULES=3D"" DEBUG_FLAGS=3D"-g" = __MPATH=3D"/usr/src/sys/pc98/pc98/canbus_if.m /usr/src/sys/isa/isa_if.m = /usr/src/sys/xen/xenbus/xenbusb_if.m /usr/src/sys/xen/xenbus/xenbus_if.m = /usr/src/sys/xen/xenmem/xenmem_if.m /usr/src/sys/net/ifdi_if.m = /usr/src/sys/geom/raid/g_raid_tr_if.m = /usr/src/sys/geom/raid/g_raid_md_if.m /usr/src/sys/geom/part/g_part_if.m = /usr/src/sys/dev/usb/controller/generic_usb_if.m = /usr/src/sys/dev/usb/usb_if.m = /usr/src/sys/dev/virtio/mmio/virtio_mmio_if.m = /usr/src/sys/dev/virtio/virtio_bus_if.m = /usr/src/sys/dev/virtio/virtio_if.m /usr/src/sys/dev/spibus/spibus_if.m = /usr/src/sys/dev/pccard/card_if.m /usr/src/sys/dev/pccard/power_if.m = /usr/src/sys/dev/sdhci/sdhci_if.m /usr/src/sys/dev/sound/midi/mpu_if.m = /usr/src/sys/dev/sound/midi/mpufoi_if.m = /usr/src/sys/dev/sound/midi/synth_if.m = /usr/src/sys/dev/sound/pci/hda/hdac_if.m = /usr/src/sys/dev/sound/pcm/feeder_if.m = /usr/src/sys/dev/sound/pcm/channel_if.m = /usr/src/sys/dev/sound/pcm/mixer_if.m = /usr/src/sys/dev/sound/pcm/ac97_if.m /usr/src/sys/dev/scc/scc_if.m = /usr/src/sys/dev/hyperv/vmbus/vmbus_if.m = /usr/src/sys/dev/bhnd/cores/chipc/bhnd_chipc_if.m = /usr/src/sys/dev/bhnd/bhndb/bhndb_if.m = /usr/src/sys/dev/bhnd/bhndb/bhndb_bus_if.m = /usr/src/sys/dev/bhnd/bhnd_bus_if.m = /usr/src/sys/dev/bhnd/nvram/bhnd_nvram_if.m = /usr/src/sys/dev/eisa/eisa_if.m /usr/src/sys/dev/adb/adb_hb_if.m = /usr/src/sys/dev/adb/adb_if.m /usr/src/sys/dev/mbox/mbox_if.m = /usr/src/sys/dev/altera/pio/pio_if.m = /usr/src/sys/dev/iscsi/icl_conn_if.m /usr/src/sys/dev/agp/agp_if.m = /usr/src/sys/dev/mmc/mmcbus_if.m /usr/src/sys/dev/mmc/mmcbr_if.m = /usr/src/sys/dev/ata/ata_if.m /usr/src/sys/dev/pci/pci_if.m = /usr/src/sys/dev/pci/pcib_if.m /usr/src/sys/dev/pci/pci_iov_if.m = /usr/src/sys/dev/cxgbe/t4_if.m /usr/src/sys/dev/gpio/gpiobus_if.m = /usr/src/sys/dev/gpio/gpio_if.m /usr/src/sys/dev/ow/owll_if.m = /usr/src/sys/dev/ow/own_if.m /usr/src/sys/dev/fdt/fdt_clock_if.m = /usr/src/sys/dev/fdt/fdt_pinctrl_if.m /usr/src/sys/dev/acpica/acpi_if.m = /usr/src/sys/dev/fb/fb_if.m /usr/src/sys/dev/vnic/lmac_if.m = /usr/src/sys/dev/mdio/mdio_if.m /usr/src/sys/dev/dwc/if_dwc_if.m = /usr/src/sys/dev/mii/miibus_if.m /usr/src/sys/dev/smbus/smbus_if.m = /usr/src/sys/dev/iicbus/iicbus_if.m /usr/src/sys/dev/iicbus/iicbb_if.m = /usr/src/sys/dev/ofw/ofw_bus_if.m /usr/src/sys/dev/ofw/ofw_if.m = /usr/src/sys/dev/ntb/ntb_if.m = /usr/src/sys/dev/acpi_support/acpi_wmi_if.m = /usr/src/sys/dev/extres/clk/clknode_if.m = /usr/src/sys/dev/extres/clk/clkdev_if.m = /usr/src/sys/dev/extres/regulator/regdev_if.m = /usr/src/sys/dev/extres/regulator/regnode_if.m = /usr/src/sys/dev/extres/hwreset/hwreset_if.m = /usr/src/sys/dev/extres/phy/phy_if.m = /usr/src/sys/dev/etherswitch/etherswitch_if.m = /usr/src/sys/dev/mvs/mvs_if.m /usr/src/sys/dev/ppbus/ppbus_if.m = /usr/src/sys/dev/uart/uart_if.m /usr/src/sys/dev/nand/nand_if.m = /usr/src/sys/dev/nand/nandbus_if.m /usr/src/sys/dev/nand/nfc_if.m = /usr/src/sys/arm/arm/platform_if.m /usr/src/sys/arm/arm/hdmi_if.m = /usr/src/sys/arm/ti/ti_gpio_if.m = /usr/src/sys/arm/allwinner/sunxi_dma_if.m = /usr/src/sys/arm/nvidia/tegra_soctherm_if.m = /usr/src/sys/sparc64/pci/ofw_pci_if.m /usr/src/sys/mips/beri/fdt_ic_if.m = /usr/src/sys/mips/mediatek/fdt_reset_if.m = /usr/src/sys/libkern/iconv_converter_if.m = /usr/src/sys/powerpc/aim/moea64_if.m = /usr/src/sys/powerpc/powerpc/pic_if.m = /usr/src/sys/powerpc/powerpc/platform_if.m = /usr/src/sys/powerpc/powerpc/mmu_if.m = /usr/src/sys/powerpc/powerpc/iommu_if.m = /usr/src/sys/opencrypto/cryptodev_if.m /usr/src/sys/kern/msi_if.m = /usr/src/sys/kern/pic_if.m /usr/src/sys/kern/device_if.m = /usr/src/sys/kern/clock_if.m /usr/src/sys/kern/bus_if.m = /usr/src/sys/kern/cpufreq_if.m /usr/src/sys/kern/linker_if.m = /usr/src/sys/kern/serdev_if.m /usr/src/sys/kgssapi/kgss_if.m" = KERNBUILDDIR=3D"/usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG" = SYSDIR=3D"/usr/src/sys" CONF_CFLAGS=3D"-march=3Darmv7a" WITH_CTF=3D"1" = make obj > cd /usr/src/sys/modules; = MAKEOBJDIRPREFIX=3D/usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG/mo= dules KMODDIR=3D/boot/kernel MACHINE_CPUARCH=3Darm MACHINE=3Darm = MACHINE_ARCH=3Darmv6 MODULES_EXTRA=3D"dtb/rpi rpi_ft5406" = WITHOUT_MODULES=3D"" DEBUG_FLAGS=3D"-g" = __MPATH=3D"/usr/src/sys/pc98/pc98/canbus_if.m /usr/src/sys/isa/isa_if.m = /usr/src/sys/xen/xenbus/xenbusb_if.m /usr/src/sys/xen/xenbus/xenbus_if.m = /usr/src/sys/xen/xenmem/xenmem_if.m /usr/src/sys/net/ifdi_if.m = /usr/src/sys/geom/raid/g_raid_tr_if.m = /usr/src/sys/geom/raid/g_raid_md_if.m /usr/src/sys/geom/part/g_part_if.m = /usr/src/sys/dev/usb/controller/generic_usb_if.m = /usr/src/sys/dev/usb/usb_if.m = /usr/src/sys/dev/virtio/mmio/virtio_mmio_if.m = /usr/src/sys/dev/virtio/virtio_bus_if.m = /usr/src/sys/dev/virtio/virtio_if.m /usr/src/sys/dev/spibus/spibus_if.m = /usr/src/sys/dev/pccard/card_if.m /usr/src/sys/dev/pccard/power_if.m = /usr/src/sys/dev/sdhci/sdhci_if.m /usr/src/sys/dev/sound/midi/mpu_if.m = /usr/src/sys/dev/sound/midi/mpufoi_if.m = /usr/src/sys/dev/sound/midi/synth_if.m = /usr/src/sys/dev/sound/pci/hda/hdac_if.m = /usr/src/sys/dev/sound/pcm/feeder_if.m = /usr/src/sys/dev/sound/pcm/channel_if.m = /usr/src/sys/dev/sound/pcm/mixer_if.m = /usr/src/sys/dev/sound/pcm/ac97_if.m /usr/src/sys/dev/scc/scc_if.m = /usr/src/sys/dev/hyperv/vmbus/vmbus_if.m = /usr/src/sys/dev/bhnd/cores/chipc/bhnd_chipc_if.m = /usr/src/sys/dev/bhnd/bhndb/bhndb_if.m = /usr/src/sys/dev/bhnd/bhndb/bhndb_bus_if.m = /usr/src/sys/dev/bhnd/bhnd_bus_if.m = /usr/src/sys/dev/bhnd/nvram/bhnd_nvram_if.m = /usr/src/sys/dev/eisa/eisa_if.m /usr/src/sys/dev/adb/adb_hb_if.m = /usr/src/sys/dev/adb/adb_if.m /usr/src/sys/dev/mbox/mbox_if.m = /usr/src/sys/dev/altera/pio/pio_if.m = /usr/src/sys/dev/iscsi/icl_conn_if.m /usr/src/sys/dev/agp/agp_if.m = /usr/src/sys/dev/mmc/mmcbus_if.m /usr/src/sys/dev/mmc/mmcbr_if.m = /usr/src/sys/dev/ata/ata_if.m /usr/src/sys/dev/pci/pci_if.m = /usr/src/sys/dev/pci/pcib_if.m /usr/src/sys/dev/pci/pci_iov_if.m = /usr/src/sys/dev/cxgbe/t4_if.m /usr/src/sys/dev/gpio/gpiobus_if.m = /usr/src/sys/dev/gpio/gpio_if.m /usr/src/sys/dev/ow/owll_if.m = /usr/src/sys/dev/ow/own_if.m /usr/src/sys/dev/fdt/fdt_clock_if.m = /usr/src/sys/dev/fdt/fdt_pinctrl_if.m /usr/src/sys/dev/acpica/acpi_if.m = /usr/src/sys/dev/fb/fb_if.m /usr/src/sys/dev/vnic/lmac_if.m = /usr/src/sys/dev/mdio/mdio_if.m /usr/src/sys/dev/dwc/if_dwc_if.m = /usr/src/sys/dev/mii/miibus_if.m /usr/src/sys/dev/smbus/smbus_if.m = /usr/src/sys/dev/iicbus/iicbus_if.m /usr/src/sys/dev/iicbus/iicbb_if.m = /usr/src/sys/dev/ofw/ofw_bus_if.m /usr/src/sys/dev/ofw/ofw_if.m = /usr/src/sys/dev/ntb/ntb_if.m = /usr/src/sys/dev/acpi_support/acpi_wmi_if.m = /usr/src/sys/dev/extres/clk/clknode_if.m = /usr/src/sys/dev/extres/clk/clkdev_if.m = /usr/src/sys/dev/extres/regulator/regdev_if.m = /usr/src/sys/dev/extres/regulator/regnode_if.m = /usr/src/sys/dev/extres/hwreset/hwreset_if.m = /usr/src/sys/dev/extres/phy/phy_if.m = /usr/src/sys/dev/etherswitch/etherswitch_if.m = /usr/src/sys/dev/mvs/mvs_if.m /usr/src/sys/dev/ppbus/ppbus_if.m = /usr/src/sys/dev/uart/uart_if.m /usr/src/sys/dev/nand/nand_if.m = /usr/src/sys/dev/nand/nandbus_if.m /usr/src/sys/dev/nand/nfc_if.m = /usr/src/sys/arm/arm/platform_if.m /usr/src/sys/arm/arm/hdmi_if.m = /usr/src/sys/arm/ti/ti_gpio_if.m = /usr/src/sys/arm/allwinner/sunxi_dma_if.m = /usr/src/sys/arm/nvidia/tegra_soctherm_if.m = /usr/src/sys/sparc64/pci/ofw_pci_if.m /usr/src/sys/mips/beri/fdt_ic_if.m = /usr/src/sys/mips/mediatek/fdt_reset_if.m = /usr/src/sys/libkern/iconv_converter_if.m = /usr/src/sys/powerpc/aim/moea64_if.m = /usr/src/sys/powerpc/powerpc/pic_if.m = /usr/src/sys/powerpc/powerpc/platform_if.m = /usr/src/sys/powerpc/powerpc/mmu_if.m = /usr/src/sys/powerpc/powerpc/iommu_if.m = /usr/src/sys/opencrypto/cryptodev_if.m /usr/src/sys/kern/msi_if.m = /usr/src/sys/kern/pic_if.m /usr/src/sys/kern/device_if.m = /usr/src/sys/kern/clock_if.m /usr/src/sys/kern/bus_if.m = /usr/src/sys/kern/cpufreq_if.m /usr/src/sys/kern/linker_if.m = /usr/src/sys/kern/serdev_if.m /usr/src/sys/kgssapi/kgss_if.m" = KERNBUILDDIR=3D"/usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG" = SYSDIR=3D"/usr/src/sys" CONF_CFLAGS=3D"-march=3Darmv7a" WITH_CTF=3D"1" = make all > Building = /usr/obj/rpi2_clang/arm.armv6/usr/src/sys/RPI2-NODBG/mbox_if.c > = /usr/src/sys/modules/rpi_ft5406/../../arm/broadcom/bcm2835//bcm2835_ft5406= .c:65:10: fatal error: 'mbox_if.h' file not found > #include "mbox_if.h" >=20 >=20 >=20 > # more /usr/src/sys/arm/conf/RPI2-NODBG=20 > # > # RPI2 -- Custom configuration for the Raspberry Pi 2 > # >=20 > include "RPI2" >=20 > ident RPI2-NODBG >=20 > makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols >=20 > options ALT_BREAK_TO_DEBUGGER >=20 > options KDB # Enable kernel debugger = support >=20 > # For minimum debugger support (stable branch) use: > options KDB_TRACE # Print a stack trace for a = panic > options DDB # Enable the kernel debugger > #options VERBOSE_SYSINIT # Enable verbose sysinit = messages > #options BOOTVERBOSE=3D1 > #options BOOTHOWTO=3DRB_VERBOSE > #options KTR > #options KTR_MASK=3DKTR_TRAP > ##options KTR_CPUMASK=3D0xF > #options KTR_VERBOSE >=20 > # Disable any extra checking for. . . > nooptions DEADLKRES # Enable the deadlock resolver > nooptions INVARIANTS # Enable calls of extra sanity = checking > nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS > nooptions WITNESS # Enable checks to detect = deadlocks and cycles > nooptions WITNESS_SKIPSPIN # Don't run witness on = spinlocks for speed > nooptions DIAGNOSTIC > nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones >=20 >=20 > # more = ~/sys_build_scripts.amd64-host/make_rpi2_nodebug_clang_bootstrap-amd64-hos= t.sh=20 > kldload -n filemon && \ > script = ~/sys_typescripts/typescript_make_rpi2_nodebug_clang_bootstrap-amd64-host-= $(date +%Y-%m-%d:%H:%M:%S) \ > env __MAKE_CONF=3D"/root/src.configs/make.conf" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host= " \ > WITH_META_MODE=3Dyes \ > MAKEOBJDIRPREFIX=3D"/usr/obj/rpi2_clang" \ > make $* >=20 >=20 > # more ~/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host=20 > TO_TYPE=3Darmv6 > # > KERNCONF=3DRPI2-NODBG > TARGET=3Darm > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3D${TO_TYPE} > .export TARGET_ARCH > .endif > # > WITH_CROSS_COMPILER=3D > WITHOUT_SYSTEM_COMPILER=3D > # > #CPUTYPE=3Dsoft > WITH_LIBCPLUSPLUS=3D > WITH_BINUTILS_BOOTSTRAP=3D > WITH_CLANG_BOOTSTRAP=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_CLANG_EXTRAS=3D > WITH_LLDB=3D > # > WITH_BOOT=3D > WITHOUT_LIB32=3D > WITHOUT_LIBSOFT=3D > # > WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D > WITHOUT_GCC_BOOTSTRAP=3D > WITHOUT_GCC=3D > WITHOUT_GCC_IS_CC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > #WERROR=3D > MALLOC_PRODUCTION=3D > # > WITH_DEBUG_FILES=3D > # > XCFLAGS+=3D -mcpu=3Dcortex-a7 > XCXXFLAGS+=3D -mcpu=3Dcortex-a7 > # There is no XCPPFLAGS but XCPP gets XCFLAGS content. > # >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Thu Nov 3 04:09:46 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 896C9C2CE23 for ; Thu, 3 Nov 2016 04:09:46 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E6C8D1D8E for ; Thu, 3 Nov 2016 04:09:44 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id uA349WZl087611; Thu, 3 Nov 2016 15:09:33 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 3 Nov 2016 15:09:32 +1100 (EST) From: Ian Smith To: Konstantin Belousov cc: Jason Harmening , freebsd-stable@freebsd.org Subject: Re: huge nanosleep variance on 11-stable In-Reply-To: <20161102162808.GI54029@kib.kiev.ua> Message-ID: <20161103150114.M41537@sola.nimnet.asn.au> References: <6167392c-c37a-6e39-aa22-ca45435d6088@gmail.com> <20161102075509.GF54029@kib.kiev.ua> <3620f62e-0f4c-2d62-dcf8-e2fdff459250@gmail.com> <20161102162808.GI54029@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 04:09:46 -0000 On Wed, 2 Nov 2016 18:28:08 +0200, Konstantin Belousov wrote: > On Wed, Nov 02, 2016 at 09:18:15AM -0700, Jason Harmening wrote: > > I think you are probably right. Hacking out the Intel-specific > > additions to C-state parsing in acpi_cpu_cx_cst() from r282678 (thus > > going back to sti;hlt instead of monitor+mwait at C1) fixed the problem > > for me. But r282678 also had the effect of enabling C2 and C3 on my > > system, because ACPI only presents MWAIT entries for those states and > > not p_lvlx. > You can do the same with "debug.acpi.disabled=mwait" loader tunable > without hacking the code. And set sysctl hw.acpi.cpu.cx_lowest to C1 to > enforce use of hlt instruction even when mwait states were requested. But hw.acpi.cpu.cx_lowest=C1 disables C2 & C3 etc, and Jason wanted those - but without using mwait - if I've read him right? cheers, Ian From owner-freebsd-stable@freebsd.org Thu Nov 3 13:49:04 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 103DAC2D0EE for ; Thu, 3 Nov 2016 13:49:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-55.reflexion.net [208.70.210.55]) (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 9C9901606 for ; Thu, 3 Nov 2016 13:49:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24345 invoked from network); 3 Nov 2016 13:48:49 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 3 Nov 2016 13:48:49 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.10.0) with SMTP; Thu, 03 Nov 2016 09:49:09 -0400 (EDT) Received: (qmail 25676 invoked from network); 3 Nov 2016 13:49:09 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 3 Nov 2016 13:49:09 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 45CA8EC9021; Thu, 3 Nov 2016 06:49:00 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: BPi-M3 (A83T based) under stable/11 -r308135: powerd? (cpufreq?) Message-Id: <196AC4A5-CAD1-4BD8-8DED-4435F3F9C0C4@dsl-only.net> Date: Thu, 3 Nov 2016 06:48:59 -0700 To: freebsd-arm , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 13:49:04 -0000 https://wiki.freebsd.org/FreeBSD/arm/Allwinner reports "yes" for = "cpufreq / DVFS" for A83T (and A64 and H3). But under stable/11 -r308135 powerd on a BPI-M3 (A83T) reports: powerd: no cpufreq(4) support -- aborting: No such file or directory sysctl -a does not seem to have the items for the subject area. It leaves me wondering if trying -j 5 buildworld buildkernel all the way = through would be safe on the BPI-M3 (heat sink and fan in use). I use = such long running sustained activity for a stability test, among other = things. > # uname -apKU > FreeBSD bpim3 11.0-STABLE FreeBSD 11.0-STABLE #1 r308135M: Tue Nov 1 = 22:07:22 PDT 2016 = markmi@FreeBSDx64:/usr/obj/bpim3_clang/arm.armv6/usr/src/sys/BPIM3-NODBG = arm armv6 1100506 1100506 As far as BPIM3-NODBG goes for my context: include "ALLWINNER" ident BPIM3-NODBG makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols options ALT_BREAK_TO_DEBUGGER options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger # Extra stuff: #options VERBOSE_SYSINIT # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE #options KTR #options KTR_MASK=3DKTR_TRAP ##options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # Disable any extra checking for. . . nooptions DEADLKRES # Enable the deadlock resolver nooptions INVARIANTS # Enable calls of extra sanity = checking nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect = deadlocks and cycles nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed nooptions DIAGNOSTIC nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Thu Nov 3 14:09:08 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFCD5C2D6EE for ; Thu, 3 Nov 2016 14:09:08 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [IPv6:2001:418:3fd::f7]) (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 71C9A1DEF for ; Thu, 3 Nov 2016 14:09:08 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [10.100.0.31] (haymarket.m5p.com [10.100.0.31]) by mailhost.m5p.com (8.15.2/8.15.2) with ESMTP id uA3E91SB001753 for ; Thu, 3 Nov 2016 10:09:06 -0400 (EDT) (envelope-from george+freebsd@m5p.com) To: FreeBSD Stable Mailing List From: George Mitchell Subject: ath0 associated, wlan0 not associated Message-ID: <3e831eea-2035-b658-3bae-784f2aa60eca@m5p.com> Date: Thu, 3 Nov 2016 10:09:01 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (mailhost.m5p.com [10.100.0.247]); Thu, 03 Nov 2016 10:09:06 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 14:09:08 -0000 Originally posted to freebsd-wireless; no solution yet so I thought I'd try here. After booting up, my ath0 interface says it is associated, but my wlan0 says it is not: FreeBSD 10.3-RELEASE-p11 wpa_supplicant v2.0 Copyright (c) 2003-2012, Jouni Malinen and contributors ath0@pci0:2:0:0: class=0x028000 card=0x064211ad chip=0x0036168c rev=0x01 hdr=0x00 vendor = 'Qualcomm Atheros' device = 'QCA9565 / AR9565 Wireless Network Adapter' class = network grep wlan /etc/rc.conf: create_args_wlan0="country US" ifconfig_wlan0="WPA DHCP" wlans_ath0="wlan0" And the result is: ifconfig wlan0: wlan0: flags=8c43 metric 0 mtu 1500 ether d0:53:49:91:6f:a1 inet6 fe80::d253:49ff:fe91:6fa1%wlan0 prefixlen 64 scopeid 0x4 inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 nd6 options=23 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid "" channel 2 (2417 MHz 11g ht/40+) regdomain FCC country US indoor ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF txpower 30 bmiss 7 scanvalid 60 protmode CTS ampdulimit 8k ampdudensity 8 shortgi wme burst roaming MANUAL ifconfig ath0: ath0: flags=8843 metric 0 mtu 2290 ether d0:53:49:91:6f:a1 nd6 options=21 media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng status: associated grep wpa /var/log/messages: ov 1 09:16:54 haymarket wpa_supplicant[389]: wlan0: Trying to associate with xx:xx:xx:xx:xx:xx (SSID='yyyyyyyyyy' freq=2417 MHz) Nov 1 09:16:54 haymarket wpa_supplicant[389]: wlan0: Associated with 60:e3:27:7b:e8:42 Nov 1 09:16:54 haymarket wpa_supplicant[389]: wlan0: WPA: Key negotiation completed with xx:xx:xx:xx:xx:xx [PTK=CCMP GTK=TKIP] Nov 1 09:16:54 haymarket wpa_supplicant[389]: wlan0: CTRL-EVENT-CONNECTED - Connection to xx:xx:xx:xx:xx:xx completed [id=1 id_str=] Nov 1 09:16:55 haymarket wpa_supplicant[389]: wlan0: WPA: Key negotiation completed with xx:xx:xx:xx:xx:xx [PTK=CCMP GTK=TKIP] Nov 1 09:16:56 haymarket wpa_supplicant[389]: wlan0: WPA: Key negotiation completed with xx:xx:xx:xx:xx:xx [PTK=CCMP GTK=TKIP] Nov 1 09:16:57 haymarket wpa_supplicant[389]: wlan0: WPA: Key negotiation completed with xx:xx:xx:xx:xx:xx [PTK=CCMP GTK=TKIP] Nov 1 09:16:57 haymarket wpa_supplicant[389]: wlan0: CTRL-EVENT-DISCONNECTED bssid=xx:xx:xx:xx:xx:xx reason=0 Nov 1 09:16:59 haymarket wpa_supplicant[389]: wlan0: Trying to associate with xx:xx:xx:xx:xx:xx (SSID='yyyyyyyyyy' freq=2417 MHz) Nov 1 09:17:09 haymarket wpa_supplicant[389]: wlan0: Authentication with xx:xx:xx:xx:xx:xx timed out. Nov 1 09:17:09 haymarket wpa_supplicant[389]: wlan0: CTRL-EVENT-DISCONNECTED bssid=xx:xx:xx:xx:xx:xx2 reason=3 locally_generated=1 Nov 1 09:18:13 haymarket wpa_supplicant[389]: wlan0: Trying to associate with xx:xx:xx:xx:xx:xx (SSID='yyyyyyyyyy' freq=2417 MHz etc. So how does ath0 get associated but not wlan0? -- George From owner-freebsd-stable@freebsd.org Thu Nov 3 15:33:39 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D0CC5C2D78B for ; Thu, 3 Nov 2016 15:33:39 +0000 (UTC) (envelope-from bennett@sdf.org) Received: from sdf.lonestar.org (ol.sdf.org [192.94.73.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ol.sdf.org", Issuer "ol.sdf.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9977213B6 for ; Thu, 3 Nov 2016 15:33:39 +0000 (UTC) (envelope-from bennett@sdf.org) Received: from sdf.org (norge.freeshell.org [192.94.73.17]) by sdf.lonestar.org (8.15.2/8.14.5) with ESMTPS id uA3FXIbI022098 (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits) verified NO); Thu, 3 Nov 2016 15:33:19 GMT Received: (from bennett@localhost) by sdf.org (8.15.2/8.12.8/Submit) id uA3FXIma020158; Thu, 3 Nov 2016 10:33:18 -0500 (CDT) From: Scott Bennett Message-Id: <201611031533.uA3FXIma020158@sdf.org> Date: Thu, 03 Nov 2016 10:33:18 -0500 To: freebsd-stable@freebsd.org, george+freebsd@m5p.com Subject: Re: huge nanosleep variance on 11-stable User-Agent: Heirloom mailx 12.5 6/20/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 15:33:40 -0000 On Wed, 2 Nov 2016 10:23:24 -0400 George Mitchell wrote: >On 11/01/16 23:45, Kevin Oberman wrote: >> On Tue, Nov 1, 2016 at 2:36 PM, Jason Harmening >> wrote: >> >>> Sorry, that should be ~*30ms* to get 30fps, though the variance is still >>> up to 500ms for me either way. >>> >>> On 11/01/16 14:29, Jason Harmening wrote: >>>> repro code is at http://pastebin.com/B68N4AFY if anyone's interested. >>>> >>>> On 11/01/16 13:58, Jason Harmening wrote: >>>>> Hi everyone, >>>>> >>>>> I recently upgraded my main amd64 server from 10.3-stable (r302011) to >>>>> 11.0-stable (r308099). It went smoothly except for one big issue: >>>>> certain applications (but not the system as a whole) respond very >>>>> sluggishly, and video playback of any kind is extremely choppy. >>>>> >>>>> [...] >> I eliminated the annoyance by change scheduler from ULE to 4BSD. That was >> it, but I have not seen the issue since. I'd be very interested in whether >> the scheduler is somehow impacting timing functions or it's s different >> issue. I've felt that there was something off in ULE for some time, but it >> was not until these annoying hiccups convinced me to try going back to >> 4BSD. >> >> Tip o' the hat to Doug B. for his suggestions that ULE may have issues that >> impacted interactivity. >> [...] > >Not to beat a dead horse, but I've been a non-fan of SCHED_ULE since >it was first introduced, and I don't like it even today. I run the >distributed.net client on my machines, but even without that, ULE >screws interactive behavior. With distributed.net running and ULE, >a make buildworld/make buildkernel takes 10 2/3 hours on 10.3-RELEASE >on a 6-CPU machine versus 2 1/2 hours on the same machine with 4BSD >and distributed.net running. I'm told that SCHED_ULE is the greatest >thing since sliced bread for some compute load or other (details are >scarce), but I (fortunately) don't often have to run heavy server >type loads; and for everyday use (even without distributed.net >running), SCHED_4BSD is my choice by far. It's too bad I can't run >freebsd_update with it, though. > I gave up on ULE during 8-STABLE. I had tried tinkering with kern.sched.preempt_thresh as recommended, as well as some more extreme values, but I couldn't see any improvement. Some values may have made performance even worse. The last straw for me, however, was when I discovered that ULE happily scheduled *idle* priority processes at times when both CPU threads on a P4 Prescott were tied up by 100% CPU-bound (mprime) threads at normal priority niced to 20. Idle priority tasks should *only* run when no higher priority tasks are available to run for all CPU threads. The 4BSD scheduler handles this situation properly. Now I'm running 10.3-STABLE on a QX9650, and I haven't tested ULE on it to see whether it's still as flawed. If and when I get a machine with a multi-cored, hyperthreaded CPU or perhaps a board with multiple CPU chips, then I may worry about the multi-level affinity stuff that ULE was supposedly designed for enough to bother testing it. But for now, I can't see any advantage in it for my current machine. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * ********************************************************************** From owner-freebsd-stable@freebsd.org Thu Nov 3 22:48:09 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E028FC2D9A0 for ; Thu, 3 Nov 2016 22:48:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 A5611127A for ; Thu, 3 Nov 2016 22:48:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-oi0-x22d.google.com with SMTP id x4so115747338oix.2 for ; Thu, 03 Nov 2016 15:48:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0tMeen4KMlAFhaA6BzpDb54ZC00DM3sIc4qCr1FSaAY=; b=sxu6/mRmJMbmnEYPmPVAeWkY3/U3TLHX5g4V+525BEvCPsu9hB/oRzmlpNGXc1xOw9 9qJgVGkBKbYLPJ1EdOipJyyNMkUDw3dxsOGQtVevHXzcSU4xgPE3bSPUv3NBTC0vPZRp /BLsUxeINIbXIJl+gzVOtdPit8CFV0VtdF/kmD5kZH8wm7H+VZEoeJiXTRXduqra6Xzp cne4QlNjWEOBX84UZB1BaDSVV3pdS7v6Q+UfcWKokultVuk+aMcDa2ISDoKziI/nvJKu sWm2ImI6u7EYypefXtjCZeZhho4KIziIuuE3+2zNTr7fi+SloimN1cWIabV+Z4LF8Udt jMHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0tMeen4KMlAFhaA6BzpDb54ZC00DM3sIc4qCr1FSaAY=; b=Dhq8ud1PM7yzWP7Zyi2Z2JL9B5EAaa6DBKzqNC2CLj7xneAtd6xBIkZRiBgvzpQ5v2 kEeg9ckHfuQ1GMqYZFk+DN0/T0a33ywYAknGkDqdSTEXLF5kTpgQcd+hJK5cyT9SflH5 lpHhxEWquBzEgdDRtw9DQj9J2cnGFiSc0mNupWSpXW1KqkUkoPmqIJbgjO13ZSSs9rzQ VxC6nnTosm7xp56rhc0VlQenDr52VcdQi7f+gwKg1FWQUpnZsqsVdjYNgcX92W9s9O85 7WgiVRj0FJxCC1CONWsQv2RKyAuuDEHdgQeWkWy5eY50LAJyMNTGXCH6bV6X/t822vAE vLxg== X-Gm-Message-State: ABUngveybl+2VUvwzN5ZUi3TCz0+TO96bU0/m+V8eE7y+5z9452HMPvkCSSMnHZVquaBPQWAiU6FeeQlztEocA== X-Received: by 10.107.174.229 with SMTP id n98mr10502081ioo.177.1478213288517; Thu, 03 Nov 2016 15:48:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.39.134 with HTTP; Thu, 3 Nov 2016 15:48:07 -0700 (PDT) In-Reply-To: <3e831eea-2035-b658-3bae-784f2aa60eca@m5p.com> References: <3e831eea-2035-b658-3bae-784f2aa60eca@m5p.com> From: Adrian Chadd Date: Thu, 3 Nov 2016 15:48:07 -0700 Message-ID: Subject: Re: ath0 associated, wlan0 not associated To: George Mitchell Cc: FreeBSD Stable Mailing List Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 22:48:10 -0000 hi, can you please try freebsd-11.0 ? I fixed a whole bunch of bugs in the AR9380 HAL and it may have improved that device. Thanks! -a On 3 November 2016 at 07:09, George Mitchell wrote: > Originally posted to freebsd-wireless; no solution yet so I thought > I'd try here. After booting up, my ath0 interface says it is > associated, but my wlan0 says it is not: > > > FreeBSD 10.3-RELEASE-p11 > wpa_supplicant v2.0 > Copyright (c) 2003-2012, Jouni Malinen and contributors > > ath0@pci0:2:0:0: class=0x028000 card=0x064211ad chip=0x0036168c rev=0x01 > hdr=0x00 > vendor = 'Qualcomm Atheros' > device = 'QCA9565 / AR9565 Wireless Network Adapter' > class = network > > grep wlan /etc/rc.conf: > create_args_wlan0="country US" > ifconfig_wlan0="WPA DHCP" > wlans_ath0="wlan0" > > And the result is: > > ifconfig wlan0: > wlan0: flags=8c43 metric > 0 mtu 1500 > ether d0:53:49:91:6f:a1 > inet6 fe80::d253:49ff:fe91:6fa1%wlan0 prefixlen 64 scopeid 0x4 > inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 > nd6 options=23 > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) > status: no carrier > ssid "" channel 2 (2417 MHz 11g ht/40+) > regdomain FCC country US indoor ecm authmode WPA2/802.11i privacy ON > deftxkey UNDEF txpower 30 bmiss 7 scanvalid 60 protmode CTS > ampdulimit 8k ampdudensity 8 shortgi wme burst roaming MANUAL > > ifconfig ath0: > ath0: flags=8843 metric 0 mtu 2290 > ether d0:53:49:91:6f:a1 > nd6 options=21 > media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng > status: associated > > grep wpa /var/log/messages: > ov 1 09:16:54 haymarket wpa_supplicant[389]: wlan0: Trying to associate > with xx:xx:xx:xx:xx:xx (SSID='yyyyyyyyyy' freq=2417 MHz) > Nov 1 09:16:54 haymarket wpa_supplicant[389]: wlan0: Associated with > 60:e3:27:7b:e8:42 > Nov 1 09:16:54 haymarket wpa_supplicant[389]: wlan0: WPA: Key > negotiation completed with xx:xx:xx:xx:xx:xx [PTK=CCMP GTK=TKIP] > Nov 1 09:16:54 haymarket wpa_supplicant[389]: wlan0: > CTRL-EVENT-CONNECTED - Connection to xx:xx:xx:xx:xx:xx completed [id=1 > id_str=] > Nov 1 09:16:55 haymarket wpa_supplicant[389]: wlan0: WPA: Key > negotiation completed with xx:xx:xx:xx:xx:xx [PTK=CCMP GTK=TKIP] > Nov 1 09:16:56 haymarket wpa_supplicant[389]: wlan0: WPA: Key > negotiation completed with xx:xx:xx:xx:xx:xx [PTK=CCMP GTK=TKIP] > Nov 1 09:16:57 haymarket wpa_supplicant[389]: wlan0: WPA: Key > negotiation completed with xx:xx:xx:xx:xx:xx [PTK=CCMP GTK=TKIP] > Nov 1 09:16:57 haymarket wpa_supplicant[389]: wlan0: > CTRL-EVENT-DISCONNECTED bssid=xx:xx:xx:xx:xx:xx reason=0 > Nov 1 09:16:59 haymarket wpa_supplicant[389]: wlan0: Trying to > associate with xx:xx:xx:xx:xx:xx (SSID='yyyyyyyyyy' freq=2417 MHz) > Nov 1 09:17:09 haymarket wpa_supplicant[389]: wlan0: Authentication > with xx:xx:xx:xx:xx:xx timed out. > Nov 1 09:17:09 haymarket wpa_supplicant[389]: wlan0: > CTRL-EVENT-DISCONNECTED bssid=xx:xx:xx:xx:xx:xx2 reason=3 > locally_generated=1 > Nov 1 09:18:13 haymarket wpa_supplicant[389]: wlan0: Trying to > associate with xx:xx:xx:xx:xx:xx (SSID='yyyyyyyyyy' freq=2417 MHz > > etc. > > So how does ath0 get associated but not wlan0? -- George > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Thu Nov 3 22:56:00 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 58449C2DDEC; Thu, 3 Nov 2016 22:56:00 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from connect.ultra-secure.de (connect.ultra-secure.de [88.198.71.201]) by mx1.freebsd.org (Postfix) with ESMTP id 720E71BB5; Thu, 3 Nov 2016 22:55:59 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: (Haraka outbound); Thu, 03 Nov 2016 23:57:22 +0100 Authentication-Results: connect.ultra-secure.de; iprev=pass; auth=pass (plain); spf=none smtp.mailfrom=ultra-secure.de Received-SPF: None (connect.ultra-secure.de: domain of ultra-secure.de does not designate 217.71.83.52 as permitted sender) receiver=connect.ultra-secure.de; identity=mailfrom; client-ip=217.71.83.52; helo=[192.168.1.200]; envelope-from= Received: from [192.168.1.200] (217-071-083-052.ip-tech.ch [217.71.83.52]) by connect.ultra-secure.de (Haraka/2.6.2-toaster) with ESMTPSA id 1DED0C7C-3780-4DD2-B1DF-EBCDAFC0F998.1 envelope-from (authenticated bits=0); Thu, 03 Nov 2016 23:57:20 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: zfs receive leads to a stuck server From: Rainer Duffner In-Reply-To: <4707908B-4868-4AA6-ADD6-D24121EFAE38@ultra-secure.de> Date: Thu, 3 Nov 2016 23:54:46 +0100 Cc: freebsd-stable Content-Transfer-Encoding: quoted-printable Message-Id: <60B441B0-F5C8-417D-95CF-23ED52E252F0@ultra-secure.de> References: <4707908B-4868-4AA6-ADD6-D24121EFAE38@ultra-secure.de> To: FreeBSD Filesystems X-Mailer: Apple Mail (2.3124) X-Haraka-GeoIP: EU, CH, 451km X-Haraka-ASN: 24951 X-Haraka-GeoIP-Received: X-Haraka-ASN: 24951 217.71.80.0/20 X-Haraka-ASN-CYMRU: asn=24951 net=217.71.80.0/20 country=CH assignor=ripencc date=2003-08-07 X-Haraka-FCrDNS: 217-071-083-052.ip-tech.ch X-Haraka-p0f: os="Mac OS X " link_type="DSL" distance=12 total_conn=14 shared_ip=Y X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on spamassassin X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Haraka-Karma: score: 6, good: 1476, bad: 1, connections: 1791, history: 1475, asn_score: 955, asn_connections: 1050, asn_good: 957, asn_bad: 2, pass:asn, relaying X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 22:56:00 -0000 > Am 01.10.2016 um 18:02 schrieb Rainer Duffner = : >=20 > Hi, >=20 > I posted this before, but I didn=E2=80=99t really get an answer and = I=E2=80=99m still looking for ways to debug this. >=20 > I have to servers (HP DL 380 Gen8, 192 GB RAM, 6C CPU). > I=E2=80=99ve outfitted them with HP=E2=80=99s H22x cards (really OEMed = 9207-8x, three altogether) that I recently cross-flashed to LSI=E2=80=99s = latest firmware. And it turns out, using anything branded by HP is just asking for ulcers = and headaches. We replaced said HBAs with LSI^WAvago^WBroadcom HBAs - and everything = started working as it should. There are still hangs at 03:00 and 04:00 (when the snapshots that got = deleted on the master get deleted on the slave) - but that's not really = a problem because they are much shorter than before and nobody is using = the system at that time. So, while the H22x-cards are =E2=80=9Eclose enough to a LSI2308-based = card so that the driver actually thinks it=E2=80=99s a 2308 - they are = in fact not. Also, with the original LSI cards, you can use LSI=E2=80=99s FreeBSD = flash utility and have a far better life overall. From owner-freebsd-stable@freebsd.org Thu Nov 3 23:04:23 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0BAC1C2E2A5 for ; Thu, 3 Nov 2016 23:04:23 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [IPv6:2001:418:3fd::f7]) (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 B151311E9 for ; Thu, 3 Nov 2016 23:04:22 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [10.100.0.31] (haymarket.m5p.com [10.100.0.31]) by mailhost.m5p.com (8.15.2/8.15.2) with ESMTP id uA3N4Aad007633; Thu, 3 Nov 2016 19:04:16 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Subject: Re: ath0 associated, wlan0 not associated To: Adrian Chadd References: <3e831eea-2035-b658-3bae-784f2aa60eca@m5p.com> Cc: FreeBSD Stable Mailing List From: George Mitchell Message-ID: Date: Thu, 3 Nov 2016 19:04:10 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.0 required=10.0 tests=ALL_TRUSTED, RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on scollay.m5p.com X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (mailhost.m5p.com [10.100.0.247]); Thu, 03 Nov 2016 19:04:21 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 23:04:23 -0000 Thanks for the suggestion. I won't be able to try it until after a business trip next week. Any patches available that apply to 10.3? -- George On 11/03/16 18:48, Adrian Chadd wrote: > hi, > > can you please try freebsd-11.0 ? I fixed a whole bunch of bugs in the > AR9380 HAL and it may have improved that device. > > Thanks! > > > -a > > > On 3 November 2016 at 07:09, George Mitchell wrote: >> Originally posted to freebsd-wireless; no solution yet so I thought >> I'd try here. After booting up, my ath0 interface says it is >> associated, but my wlan0 says it is not: >> >> >> FreeBSD 10.3-RELEASE-p11 >> wpa_supplicant v2.0 >> Copyright (c) 2003-2012, Jouni Malinen and contributors >> >> ath0@pci0:2:0:0: class=0x028000 card=0x064211ad chip=0x0036168c rev=0x01 >> hdr=0x00 >> vendor = 'Qualcomm Atheros' >> device = 'QCA9565 / AR9565 Wireless Network Adapter' >> class = network >> >> grep wlan /etc/rc.conf: >> create_args_wlan0="country US" >> ifconfig_wlan0="WPA DHCP" >> wlans_ath0="wlan0" >> >> And the result is: >> >> ifconfig wlan0: >> wlan0: flags=8c43 metric >> 0 mtu 1500 >> ether d0:53:49:91:6f:a1 >> inet6 fe80::d253:49ff:fe91:6fa1%wlan0 prefixlen 64 scopeid 0x4 >> inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 >> nd6 options=23 >> media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) >> status: no carrier >> ssid "" channel 2 (2417 MHz 11g ht/40+) >> regdomain FCC country US indoor ecm authmode WPA2/802.11i privacy ON >> deftxkey UNDEF txpower 30 bmiss 7 scanvalid 60 protmode CTS >> ampdulimit 8k ampdudensity 8 shortgi wme burst roaming MANUAL >> >> ifconfig ath0: >> ath0: flags=8843 metric 0 mtu 2290 >> ether d0:53:49:91:6f:a1 >> nd6 options=21 >> media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng >> status: associated >> >> grep wpa /var/log/messages: >> ov 1 09:16:54 haymarket wpa_supplicant[389]: wlan0: Trying to associate >> with xx:xx:xx:xx:xx:xx (SSID='yyyyyyyyyy' freq=2417 MHz) >> Nov 1 09:16:54 haymarket wpa_supplicant[389]: wlan0: Associated with >> 60:e3:27:7b:e8:42 >> Nov 1 09:16:54 haymarket wpa_supplicant[389]: wlan0: WPA: Key >> negotiation completed with xx:xx:xx:xx:xx:xx [PTK=CCMP GTK=TKIP] >> Nov 1 09:16:54 haymarket wpa_supplicant[389]: wlan0: >> CTRL-EVENT-CONNECTED - Connection to xx:xx:xx:xx:xx:xx completed [id=1 >> id_str=] >> Nov 1 09:16:55 haymarket wpa_supplicant[389]: wlan0: WPA: Key >> negotiation completed with xx:xx:xx:xx:xx:xx [PTK=CCMP GTK=TKIP] >> Nov 1 09:16:56 haymarket wpa_supplicant[389]: wlan0: WPA: Key >> negotiation completed with xx:xx:xx:xx:xx:xx [PTK=CCMP GTK=TKIP] >> Nov 1 09:16:57 haymarket wpa_supplicant[389]: wlan0: WPA: Key >> negotiation completed with xx:xx:xx:xx:xx:xx [PTK=CCMP GTK=TKIP] >> Nov 1 09:16:57 haymarket wpa_supplicant[389]: wlan0: >> CTRL-EVENT-DISCONNECTED bssid=xx:xx:xx:xx:xx:xx reason=0 >> Nov 1 09:16:59 haymarket wpa_supplicant[389]: wlan0: Trying to >> associate with xx:xx:xx:xx:xx:xx (SSID='yyyyyyyyyy' freq=2417 MHz) >> Nov 1 09:17:09 haymarket wpa_supplicant[389]: wlan0: Authentication >> with xx:xx:xx:xx:xx:xx timed out. >> Nov 1 09:17:09 haymarket wpa_supplicant[389]: wlan0: >> CTRL-EVENT-DISCONNECTED bssid=xx:xx:xx:xx:xx:xx2 reason=3 >> locally_generated=1 >> Nov 1 09:18:13 haymarket wpa_supplicant[389]: wlan0: Trying to >> associate with xx:xx:xx:xx:xx:xx (SSID='yyyyyyyyyy' freq=2417 MHz >> >> etc. >> >> So how does ath0 get associated but not wlan0? -- George >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@freebsd.org Fri Nov 4 00:28:59 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E842CC2E118 for ; Fri, 4 Nov 2016 00:28:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-55.reflexion.net [208.70.210.55]) (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 979D51306 for ; Fri, 4 Nov 2016 00:28:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17713 invoked from network); 4 Nov 2016 00:29:09 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 4 Nov 2016 00:29:09 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.10.0) with SMTP; Thu, 03 Nov 2016 20:29:01 -0400 (EDT) Received: (qmail 9693 invoked from network); 4 Nov 2016 00:29:01 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 4 Nov 2016 00:29:01 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id B8D82EC9177; Thu, 3 Nov 2016 17:28:51 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Use of env SRC_ENV_CONF=. . . for buildworld does not override/avoid use of /etc/src.conf : Intentional? Message-Id: <12E108A2-21FE-4756-B099-334ADD020891@dsl-only.net> Date: Thu, 3 Nov 2016 17:28:51 -0700 Cc: FreeBSD-STABLE Mailing List , FreeBSD Current To: Bryan Drewery , FreeBSD Toolchain X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 00:29:00 -0000 I just had a case of "odd" command text in a buildworld that was based = on (in part) env SRC_ENV_CONF=3D. . . env __MAKE_CONF=3D. . . does not get the kind of behavior reported below = for /etc/src.conf . Overall this means that even with an explicit env SRC_ENV_CONF=3D. . . = one must separately prevent /etc/src.conf from contributing if the = SRC_ENV_CONF file is intended to cover everything. Looking in the log from a failure that resulted shows that = .MAKE.MAKEFILES shows both the SRC_ENV_CONF expansion and also a = /etc/src.conf as well (formatted to make the /etc/src.conf and such = stand out: separate lines wiht whitespace before and after and with just = one path on the line for such file paths): > Script started on Thu Nov 3 16:37:26 2016 > Command: env __MAKE_CONF=3D/root/src.configs/make.conf = SRC_ENV_CONF=3D/root/src.configs/src.conf.powerpc64-xtoolchain.amd64-host = WITH_META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/powerpc64vtsc_xtoolchain = make -j 5 buildworld buildkernel . . . > .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk > /root/src.configs/src.conf.powerpc64-xtoolchain.amd64-host > /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk > /root/src.configs/make.conf > /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk > /etc/src.conf > /usr/src/include/rpcsvc/Makefile /usr/src/share/mk/bsd.prog.mk = /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk = /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk = /usr/src/share/mk/src.init > .mk /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.libnames.mk = /usr/src/share/mk/src.libnames.mk /usr/src/share/mk/src.opts.mk = /usr/src/share/mk/bsd.nls.mk /usr/src/share/mk/bsd.confs.mk = /usr/src/share > /mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk = /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.man.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=3D'. /usr/src/include/rpcsvc' Note: > # grep src.conf = /root/src.configs/src.conf.powerpc64-xtoolchain.amd64-host > # The context I was under was: > # uname -apKU > FreeBSD FreeBSDx64 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r308247M: Thu = Nov 3 04:05:55 PDT 2016 = markmi@FreeBSDx64:/usr/obj/amd64_clang/amd64.amd64/usr/src/sys/GENERIC-NOD= BG amd64 amd64 1200014 1200014 I'd just cloned and switched from a stable/11 context to head = (12-CURRENT). If this is intentional then I think the man src.conf references and such = should be explicit about the /etc/make.conf vs. /etc/src.conf = distinction for __MAKE_CONF=3D vs. SRC_ENV_CONF=3D . =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Fri Nov 4 03:10:02 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 362E8C2EA7C for ; Fri, 4 Nov 2016 03:10:02 +0000 (UTC) (envelope-from dmagda@ee.ryerson.ca) Received: from eccles.ee.ryerson.ca (eccles.ee.ryerson.ca [141.117.1.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 09C581CB1 for ; Fri, 4 Nov 2016 03:10:01 +0000 (UTC) (envelope-from dmagda@ee.ryerson.ca) Received: from [192.168.10.101] ([45.72.246.78]) (authenticated bits=0) by eccles.ee.ryerson.ca (8.14.9/8.14.9) with ESMTP id uA42unLl032683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Nov 2016 22:56:50 -0400 (EDT) (envelope-from dmagda@ee.ryerson.ca) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: pax(1) needs to learn POSIX-pax format (by libarchive(3)?) From: David Magda In-Reply-To: <5818D48E.8070205@omnilan.de> Date: Thu, 3 Nov 2016 22:56:46 -0400 Cc: freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <35B0FA6B-C2E5-49D4-813E-36C469AE0BC0@ee.ryerson.ca> References: <5818D48E.8070205@omnilan.de> To: Harry Schmalzbauer X-Mailer: Apple Mail (2.3124) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (eccles.ee.ryerson.ca [141.117.1.2]); Thu, 03 Nov 2016 22:56:50 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 03:10:02 -0000 On Nov 1, 2016, at 13:44, Harry Schmalzbauer wrote: > Has anyone ever thought about? Unfortunately I'm lacking skills and = time :-( You=E2=80=99ll want to talk to the folks here: http://libarchive.org That is the upstream project. It actually started on FreeBSD over a = decade ago but spun off on its own, and is used by a wider audience = nowadays. I provided some sample Solaris-ACL files early in the development. If = you provide some problematic files I=E2=80=99m sure they=E2=80=99ll be = willing to help. Regards, David= From owner-freebsd-stable@freebsd.org Fri Nov 4 07:50:28 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8EB5C2F415 for ; Fri, 4 Nov 2016 07:50:28 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 36C231A1B; Fri, 4 Nov 2016 07:50:26 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id uA47oGMV043828; Fri, 4 Nov 2016 18:50:17 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 4 Nov 2016 18:50:16 +1100 (EST) From: Ian Smith To: freebsd-stable@freebsd.org cc: gjb@freebsd.org Subject: 1MB swap partition on 11.0 memstick Message-ID: <20161104183856.U41537@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 07:50:28 -0000 Still wondering .. I have no spare box to install 11.0 on at present but want to be sure the memstick mentioned below will be fit for purpose. I can easily add a 1.0MB swap partition to that, but is it necessary? From: # $FreeBSD: head/release/amd64/make-memstick.sh 293188 2016-01-05 03:20:45Z gjb $ [..] mkimg -s gpt -b ${1}/boot/pmbr -p efi:=${1}/boot/boot1.efifat \ -p freebsd-boot:=${1}/boot/gptboot -p freebsd-ufs:=${2}.part \ -p freebsd-swap::1M -o ${2} === reposted: Tried in -questions but no takers .. root@x200:~ # mdconfig -lv md0 vnode 700M /home/smithi/FreeBSD-11.0-RELEASE-amd64-memstick.img root@x200:~ # gpart show -p md0 => 3 1433741 md0 GPT (700M) 3 1600 md0p1 efi (800k) 1603 125 md0p2 freebsd-boot (62k) 1728 1429968 md0p3 freebsd-ufs (698M) 1431696 2048 md0p4 freebsd-swap (1.0M) What is the 1.0M swap partition for? Is it needed by bsdinstall? I have an MBR-scheme sliced memstick using boot0 with that md0p3 dd'd to da0s2a which boots fine, but have only run it as 'Live CD' and have not run the installer, but am wondering if a) that swap partition is really needed and if so, b) what can usefully be done with 1MB of swap .. cheers, Ian From owner-freebsd-stable@freebsd.org Fri Nov 4 08:55:07 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AFA99C2E018 for ; Fri, 4 Nov 2016 08:55:07 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3A40E1BE6 for ; Fri, 4 Nov 2016 08:55:06 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id uA48sxaA011224; Fri, 4 Nov 2016 09:54:59 +0100 (CET) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 441926CF; Fri, 4 Nov 2016 09:54:59 +0100 (CET) Message-ID: <581C4CE2.20209@omnilan.de> Date: Fri, 04 Nov 2016 09:54:58 +0100 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: David Magda CC: freebsd-stable@freebsd.org Subject: Re: pax(1) needs to learn POSIX-pax format (by libarchive(3)?) References: <5818D48E.8070205@omnilan.de> <35B0FA6B-C2E5-49D4-813E-36C469AE0BC0@ee.ryerson.ca> In-Reply-To: <35B0FA6B-C2E5-49D4-813E-36C469AE0BC0@ee.ryerson.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Fri, 04 Nov 2016 09:54:59 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 08:55:07 -0000 Bezüglich David Magda's Nachricht vom 04.11.2016 03:56 (localtime): > On Nov 1, 2016, at 13:44, Harry Schmalzbauer wrote: > >> Has anyone ever thought about? Unfortunately I'm lacking skills and time :-( > > You’ll want to talk to the folks here: > > http://libarchive.org > > That is the upstream project. It actually started on FreeBSD over a decade ago but spun off on its own, and is used by a wider audience nowadays. > > I provided some sample Solaris-ACL files early in the development. If you provide some problematic files I’m sure they’ll be willing to help. Hello David, thanks for your hint. I'm using libarchive(3)'s pax-support by tar(1) already, so I'm not sure if these are the ones interested to make pax(1) use libarchive(3). If I remember correctly I haven't had problems restoring files with NFSv4 ACLs, but that's not the major problem anyway. My real-world problem is that the pax(1) tool can't restore from/backup to pax-format files. All supported formats by pax(1) have unpractical path/filename length limits. I'm aware of cpio(1) and tar(1)s transition to libarchive several years ago. Unfortunetly pax(1) was overseen :-( Would be wonderful if someone could catch up pax(1)'s libarchive(3) transition, but I guess the libarchive developers aren't interested or have very much spare resources… Thanks, -Harry From owner-freebsd-stable@freebsd.org Fri Nov 4 09:04:36 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F04A9C2EC57; Fri, 4 Nov 2016 09:04:36 +0000 (UTC) (envelope-from garga.bsd@gmail.com) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 A5DBC1343; Fri, 4 Nov 2016 09:04:36 +0000 (UTC) (envelope-from garga.bsd@gmail.com) Received: by mail-qt0-x229.google.com with SMTP id c47so44090547qtc.2; Fri, 04 Nov 2016 02:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=GOGzkNFxV5SB+RwImEltih/eXoLjAFU2VRtxMaWu2NY=; b=B8i6ZffLQPU9vE8ZOQhfbWSNPAPOTCkJa9pvHhXhoUNA7oC4/PE3/pHVQNb2tuNze9 qLQZCaNEoon0xihqiYYDxf8ZyKneTA15Q38//+dMKAKhY8dsTRfeM8+gb/NYkJqxUvpE hPHPZaNfDtJF5WErNQzA/OZ7DNhSem8sVAF76G19hgk5mz5rZLuLZvINNATk0O+lAe/f 11PutFYuNnKsWJHM6kejDyCjlbbOwb6QPypt3KvzeJwvotrDYWI4mnMbPv7Gc0CkFqfW I4L0PzSGUeuipkyIsfli4/WOHn//apC7x5CLQ4vjOfm58zOYdDFg/9XXooVy+i4GIuMt kK2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=GOGzkNFxV5SB+RwImEltih/eXoLjAFU2VRtxMaWu2NY=; b=nORIIlcW0iyUF3IQ9dFkSOzJNdfj5+hAPvtsSpdt+w3ZlS1ghFl7AQzofVlqP3cmji mzTlFB54IVy3NAAxryNth5tvzuBcc/cY3gR7MUV/103Uedn7t+MirrwtdFLLw12YVf+o gaikQaNqABrhKPygcQK9QwA1rhBrAa9a2eWukPT6wHpzA7uv1eLsmDULZghnm9uJMJXy D8nWJFFac6LcfH2/8kOvwkd5hRVkxwaFS4PWgaCHtteAf58ypZ1HTSDm51BYuvpABZsa wC3Lr/qVw/7iD6FXrwXP5ZyVU1zjW+KuJR+MpGdSeY0XKRvC4ogE2EDncxpzxnAqu1MW vK8Q== X-Gm-Message-State: ABUngvf4hw4rj5AHu7sDrqLRaZ1sRrDkdSu6rK11SZhsbYL3Z+OjbpeHipPa5KtcmDpYwQ== X-Received: by 10.200.45.129 with SMTP id p1mr12340403qta.96.1478250275798; Fri, 04 Nov 2016 02:04:35 -0700 (PDT) Received: from mbp-eth.home ([186.249.133.26]) by smtp.gmail.com with ESMTPSA id c189sm6952074qkg.21.2016.11.04.02.04.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Nov 2016 02:04:35 -0700 (PDT) Sender: Renato Botelho From: Renato Botelho Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: Use of env SRC_ENV_CONF=. . . for buildworld does not override/avoid use of /etc/src.conf : Intentional? Date: Fri, 4 Nov 2016 07:04:30 -0200 In-Reply-To: <12E108A2-21FE-4756-B099-334ADD020891@dsl-only.net> Cc: Bryan Drewery , FreeBSD Toolchain , FreeBSD-STABLE Mailing List , FreeBSD Current To: Mark Millard References: <12E108A2-21FE-4756-B099-334ADD020891@dsl-only.net> X-Mailer: Apple Mail (2.3251) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 09:04:37 -0000 > On 3 Nov 2016, at 22:28, Mark Millard wrote: >=20 > I just had a case of "odd" command text in a buildworld that was based = on (in part) env SRC_ENV_CONF=3D. . . >=20 > env __MAKE_CONF=3D. . . does not get the kind of behavior reported = below for /etc/src.conf . >=20 > Overall this means that even with an explicit env SRC_ENV_CONF=3D. . . = one must separately prevent /etc/src.conf from contributing if the = SRC_ENV_CONF file is intended to cover everything. >=20 > Looking in the log from a failure that resulted shows that = .MAKE.MAKEFILES shows both the SRC_ENV_CONF expansion and also a = /etc/src.conf as well (formatted to make the /etc/src.conf and such = stand out: separate lines wiht whitespace before and after and with just = one path on the line for such file paths): >=20 >> Script started on Thu Nov 3 16:37:26 2016 >> Command: env __MAKE_CONF=3D/root/src.configs/make.conf = SRC_ENV_CONF=3D/root/src.configs/src.conf.powerpc64-xtoolchain.amd64-host = WITH_META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/powerpc64vtsc_xtoolchain = make -j 5 buildworld buildkernel > . . . >> .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk >=20 >> /root/src.configs/src.conf.powerpc64-xtoolchain.amd64-host >=20 >> /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk >=20 >> /root/src.configs/make.conf >=20 >> /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk >=20 >> /etc/src.conf >=20 >> /usr/src/include/rpcsvc/Makefile /usr/src/share/mk/bsd.prog.mk = /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk = /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk = /usr/src/share/mk/src.init >> .mk /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.libnames.mk = /usr/src/share/mk/src.libnames.mk /usr/src/share/mk/src.opts.mk = /usr/src/share/mk/bsd.nls.mk /usr/src/share/mk/bsd.confs.mk = /usr/src/share >> /mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk = /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.man.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=3D'. /usr/src/include/rpcsvc' >=20 > Note: >=20 >> # grep src.conf = /root/src.configs/src.conf.powerpc64-xtoolchain.amd64-host >> # >=20 >=20 > The context I was under was: >=20 >> # uname -apKU >> FreeBSD FreeBSDx64 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r308247M: Thu = Nov 3 04:05:55 PDT 2016 = markmi@FreeBSDx64:/usr/obj/amd64_clang/amd64.amd64/usr/src/sys/GENERIC-NOD= BG amd64 amd64 1200014 1200014 >=20 > I'd just cloned and switched from a stable/11 context to head = (12-CURRENT). >=20 > If this is intentional then I think the man src.conf references and = such should be explicit about the /etc/make.conf vs. /etc/src.conf = distinction for __MAKE_CONF=3D vs. SRC_ENV_CONF=3D . There are 3 possible files and 3 possible variables to cover it. = SRC_ENV_CONF is to /etc/src-env.conf and not to /etc/src.conf. Default = values are: __MAKE_CONF=3D/etc/make.conf SRCCONF=3D/etc/src.conf SRC_ENV_CONF=3D/etc/src-env.conf According src.conf(5) there are few items that are supposed to be = defined in /etc/src-env.conf instead of /etc/src.conf -- Renato Botelho From owner-freebsd-stable@freebsd.org Fri Nov 4 11:06:40 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 756F9C2F8E6 for ; Fri, 4 Nov 2016 11:06:40 +0000 (UTC) (envelope-from dmagda@ee.ryerson.ca) Received: from eccles.ee.ryerson.ca (eccles.ee.ryerson.ca [141.117.1.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 481761BD for ; Fri, 4 Nov 2016 11:06:39 +0000 (UTC) (envelope-from dmagda@ee.ryerson.ca) Received: from [192.168.10.101] ([45.72.246.78]) (authenticated bits=0) by eccles.ee.ryerson.ca (8.14.9/8.14.9) with ESMTP id uA4B6b6A061693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Nov 2016 07:06:37 -0400 (EDT) (envelope-from dmagda@ee.ryerson.ca) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: pax(1) needs to learn POSIX-pax format (by libarchive(3)?) From: David Magda In-Reply-To: <581C4CE2.20209@omnilan.de> Date: Fri, 4 Nov 2016 07:06:32 -0400 Cc: freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <5818D48E.8070205@omnilan.de> <35B0FA6B-C2E5-49D4-813E-36C469AE0BC0@ee.ryerson.ca> <581C4CE2.20209@omnilan.de> To: Harry Schmalzbauer X-Mailer: Apple Mail (2.3124) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (eccles.ee.ryerson.ca [141.117.1.2]); Fri, 04 Nov 2016 07:06:37 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 11:06:40 -0000 On Nov 4, 2016, at 04:54, Harry Schmalzbauer wrote: > Would be wonderful if someone could catch up pax(1)'s libarchive(3) > transition, but I guess the libarchive developers aren't interested or > have very much spare resources=E2=80=A6 Have you asked them? Do they know it is a problem? Do they have a bug = tracking system? If people do not tell them about problems they cannot know about them. = If not a lot of people complain about a bug, then they may think it is a = low priority: the more people complain about it the higher up the TODO = list it will go. From owner-freebsd-stable@freebsd.org Fri Nov 4 14:44:53 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8E1E5C2FB76 for ; Fri, 4 Nov 2016 14:44:53 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 7F555C49; Fri, 4 Nov 2016 14:44:53 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id 3EB0F145B; Fri, 4 Nov 2016 14:44:53 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Fri, 4 Nov 2016 14:44:52 +0000 From: Glen Barber To: Ian Smith Cc: freebsd-stable@freebsd.org Subject: Re: 1MB swap partition on 11.0 memstick Message-ID: <20161104144452.GB79915@FreeBSD.org> References: <20161104183856.U41537@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="V0207lvV8h4k8FAm" Content-Disposition: inline In-Reply-To: <20161104183856.U41537@sola.nimnet.asn.au> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer X-Spidey-Sense: Uh oh, Peter logged in User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 14:44:53 -0000 --V0207lvV8h4k8FAm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 04, 2016 at 06:50:16PM +1100, Ian Smith wrote: > Still wondering .. I have no spare box to install 11.0 on at present but= =20 > want to be sure the memstick mentioned below will be fit for purpose. =20 > I can easily add a 1.0MB swap partition to that, but is it necessary? >=20 > From: > # $FreeBSD: head/release/amd64/make-memstick.sh 293188 2016-01-05 03:20:4= 5Z gjb $ > [..] > mkimg -s gpt -b ${1}/boot/pmbr -p efi:=3D${1}/boot/boot1.efifat \ > -p freebsd-boot:=3D${1}/boot/gptboot -p freebsd-ufs:=3D${2}.part \ > -p freebsd-swap::1M -o ${2} >=20 > =3D=3D=3D reposted: >=20 > Tried in -questions but no takers .. >=20 > root@x200:~ # mdconfig -lv > md0 vnode 700M =20 > /home/smithi/FreeBSD-11.0-RELEASE-amd64-memstick.img > root@x200:~ # gpart show -p md0 > =3D> 3 1433741 md0 GPT (700M) > 3 1600 md0p1 efi (800k) > 1603 125 md0p2 freebsd-boot (62k) > 1728 1429968 md0p3 freebsd-ufs (698M) > 1431696 2048 md0p4 freebsd-swap (1.0M) >=20 > What is the 1.0M swap partition for? Is it needed by bsdinstall? >=20 > I have an MBR-scheme sliced memstick using boot0 with that md0p3 dd'd to= =20 > da0s2a which boots fine, but have only run it as 'Live CD' and have not= =20 > run the installer, but am wondering if a) that swap partition is really= =20 > needed and if so, b) what can usefully be done with 1MB of swap .. >=20 I would need to look through the commit logs to confirm, but if I recall correctly, the memstick images failed to boot properly without the 1MB swap after the freebsd-ufs partition after converting the image build to use mkimg(1). Glen --V0207lvV8h4k8FAm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYHJ7kAAoJEAMUWKVHj+KTWn0QAKGZg7Ugb9f+ySe9B2eaiCZM dibm/ntMHshsQ/I3bRfoLzMzkkHGoMJoefKZqk2zFNeadWDLg9r2rIyuo1o/tKsf 8vjWEdJj0JFBtXMhjo/F1xYkHaRbwaGs+2ccl0s4tyDsQ7JFDdUotCkQmRoZAxJj TrBXhG1G1AxxiYHeJAz3v5rEB59JKoPbhA81CUGV+l2/I/fm9vTTUeent7elr4EX VGT5vn6qyhWgBUcw/5vhXrsSf76JgtMD7epyTxLlbJUVAEVVIw52FslR3xQ70v6D 9hfkPM9uLzSQk+0YfTJ/1wwCQXx25D4fDJS4hovBu317m8VOX5nN0b4bPQ5b4aTT DT8bgcnuAQ5j2Hm3D5WyRV7C7KNw+pp1lQtRl5GSgzMBerai9gyoLBTS087cgppq /6eauJKzHz7tl9u4Zf48qDTJord7Su5WZoJBv/56TW9sdKP8g37QNpfyAlsnmQ7E Mm5e0jAbJYOIknQka7iQGb6EWPB2PprZnSH1G6ZzlMXmWpOX7GPVBUcXCGe9xpnq ujPFBhWex82GASfBm985DH9aTtbYB3/o0ZlV7F+m+PmE83o0PUZ60dUN0La8oxgh 4j2pNTdfbS1KGxjrd/4RKL3o2SmOtPPhFkgQBpzS0ENl/Ap/QHpoTmjJSV0miMqR bqw1Z8x9SyImKSakwOWc =t1Rd -----END PGP SIGNATURE----- --V0207lvV8h4k8FAm-- From owner-freebsd-stable@freebsd.org Fri Nov 4 14:50:42 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D31FC2FEB0 for ; Fri, 4 Nov 2016 14:50:42 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 28D83F5E; Fri, 4 Nov 2016 14:50:42 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id F1DCA57; Fri, 4 Nov 2016 14:50:41 +0000 (UTC) Date: Fri, 4 Nov 2016 14:50:27 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-stable@FreeBSD.org Message-ID: <20782177.0.1478271041593.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_stable_10 #447 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 14:50:42 -0000 https://jenkins.FreeBSD.org/job/FreeBSD_stable_10/447/------------------------------------------ [...truncated 329450 lines...] [192.168.10.2] out: lib/msun/exp_test:expm1f_nan -> passed [0.004s] [192.168.10.2] out: lib/msun/exp_test:expm1f_zero_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/exp_test:expm1f_zero_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/fmod_test:fmod -> passed [0.004s] [192.168.10.2] out: lib/msun/infinity_test:infinity_double -> passed [0.004s] [192.168.10.2] out: lib/msun/infinity_test:infinity_float -> passed [0.004s] [192.168.10.2] out: lib/msun/infinity_test:infinity_long_double -> passed [0.004s] [192.168.10.2] out: lib/msun/ldexp_test:ldexp_basic -> passed [0.004s] [192.168.10.2] out: lib/msun/ldexp_test:ldexp_denormal -> passed [0.004s] [192.168.10.2] out: lib/msun/ldexp_test:ldexp_denormal_large -> passed [0.004s] [192.168.10.2] out: lib/msun/ldexp_test:ldexp_exp2 -> passed [0.004s] [192.168.10.2] out: lib/msun/ldexp_test:ldexp_inf_neg -> passed [0.005s] [192.168.10.2] out: lib/msun/ldexp_test:ldexp_inf_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/ldexp_test:ldexp_infinity -> passed [0.004s] [192.168.10.2] out: lib/msun/ldexp_test:ldexp_nan -> passed [0.004s] [192.168.10.2] out: lib/msun/ldexp_test:ldexp_overflow -> passed [0.004s] [192.168.10.2] out: lib/msun/ldexp_test:ldexp_underflow -> passed [0.004s] [192.168.10.2] out: lib/msun/ldexp_test:ldexp_zero -> passed [0.004s] [192.168.10.2] out: lib/msun/ldexp_test:ldexp_zero_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/ldexp_test:ldexp_zero_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/ldexp_test:ldexpf_exp2f -> passed [0.004s] [192.168.10.2] out: lib/msun/ldexp_test:ldexpf_inf_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/ldexp_test:ldexpf_inf_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/ldexp_test:ldexpf_nan -> passed [0.004s] [192.168.10.2] out: lib/msun/ldexp_test:ldexpf_zero_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/ldexp_test:ldexpf_zero_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log10_base -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log10_inf_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log10_inf_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log10_nan -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log10_one_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log10_zero_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log10_zero_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log10f_base -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log10f_inf_neg -> passed [0.005s] [192.168.10.2] out: lib/msun/log_test:log10f_inf_pos -> passed [0.005s] [192.168.10.2] out: lib/msun/log_test:log10f_nan -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log10f_one_pos -> passed [0.005s] [192.168.10.2] out: lib/msun/log_test:log10f_zero_neg -> passed [0.005s] [192.168.10.2] out: lib/msun/log_test:log10f_zero_pos -> passed [0.005s] [192.168.10.2] out: lib/msun/log_test:log1p_inf_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log1p_inf_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log1p_nan -> passed [0.005s] [192.168.10.2] out: lib/msun/log_test:log1p_one_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log1p_zero_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log1p_zero_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log1pf_inf_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log1pf_inf_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log1pf_nan -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log1pf_one_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log1pf_zero_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log1pf_zero_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log2_base -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log2_inf_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log2_inf_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log2_nan -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log2_one_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log2_zero_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log2_zero_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log2f_base -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log2f_inf_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log2f_inf_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log2f_nan -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log2f_one_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log2f_zero_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log2f_zero_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log_base -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log_inf_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log_inf_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log_nan -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log_one_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log_zero_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:log_zero_pos -> passed [0.005s] [192.168.10.2] out: lib/msun/log_test:logf_base -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:logf_inf_neg -> passed [0.005s] [192.168.10.2] out: lib/msun/log_test:logf_inf_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/log_test:logf_nan -> passed [0.005s] [192.168.10.2] out: lib/msun/log_test:logf_one_pos -> passed [0.005s] [192.168.10.2] out: lib/msun/log_test:logf_zero_neg -> passed [0.005s] [192.168.10.2] out: lib/msun/log_test:logf_zero_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/pow_test:pow_inf_neg_x -> passed [0.004s] [192.168.10.2] out: lib/msun/pow_test:pow_inf_neg_y -> passed [0.004s] [192.168.10.2] out: lib/msun/pow_test:pow_inf_pos_x -> passed [0.004s] [192.168.10.2] out: lib/msun/pow_test:pow_inf_pos_y -> passed [0.004s] [192.168.10.2] out: lib/msun/pow_test:pow_nan_x -> passed [0.004s] [192.168.10.2] out: lib/msun/pow_test:pow_nan_y -> passed [0.006s] [192.168.10.2] out: lib/msun/pow_test:pow_one_neg_x -> passed [0.004s] [192.168.10.2] out: lib/msun/pow_test:pow_one_pos_x -> passed [0.004s] [192.168.10.2] out: lib/msun/pow_test:pow_zero_x -> passed [0.005s] [192.168.10.2] out: lib/msun/pow_test:pow_zero_y -> passed [0.004s] [192.168.10.2] out: lib/msun/pow_test:powf_inf_neg_x -> passed [0.004s] [192.168.10.2] out: lib/msun/pow_test:powf_inf_neg_y -> passed [0.004s] [192.168.10.2] out: lib/msun/pow_test:powf_inf_pos_x -> passed [0.004s] [192.168.10.2] out: lib/msun/pow_test:powf_inf_pos_y -> passed [0.004s] [192.168.10.2] out: lib/msun/pow_test:powf_nan_x -> passed [0.004s] [192.168.10.2] out: lib/msun/pow_test:powf_nan_y -> passed [0.005s] [192.168.10.2] out: lib/msun/pow_test:powf_one_neg_x -> passed [0.005s] [192.168.10.2] out: lib/msun/pow_test:powf_one_pos_x -> passed [0.004s] [192.168.10.2] out: lib/msun/pow_test:powf_zero_x -> passed [0.004s] [192.168.10.2] out: lib/msun/pow_test:powf_zero_y -> passed [0.005s] [192.168.10.2] out: lib/msun/precision_test:t_precision -> passed [0.004s] [192.168.10.2] out: lib/msun/round_test:round_dir -> passed [0.004s] [192.168.10.2] out: lib/msun/scalbn_test:scalbn_inf_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/scalbn_test:scalbn_inf_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/scalbn_test:scalbn_ldexp -> passed [0.004s] [192.168.10.2] out: lib/msun/scalbn_test:scalbn_nan -> passed [0.004s] [192.168.10.2] out: lib/msun/scalbn_test:scalbn_val -> passed [0.004s] [192.168.10.2] out: lib/msun/scalbn_test:scalbn_zero_neg -> passed [0.005s] [192.168.10.2] out: lib/msun/scalbn_test:scalbn_zero_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/scalbn_test:scalbnf_inf_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/scalbn_test:scalbnf_inf_pos -> passed [0.005s] [192.168.10.2] out: lib/msun/scalbn_test:scalbnf_ldexpf -> passed [0.004s] [192.168.10.2] out: lib/msun/scalbn_test:scalbnf_nan -> passed [0.004s] [192.168.10.2] out: lib/msun/scalbn_test:scalbnf_val -> passed [0.004s] [192.168.10.2] out: lib/msun/scalbn_test:scalbnf_zero_neg -> passed [0.005s] [192.168.10.2] out: lib/msun/scalbn_test:scalbnf_zero_pos -> passed [0.005s] [192.168.10.2] out: lib/msun/scalbn_test:scalbnl_inf_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/scalbn_test:scalbnl_inf_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/scalbn_test:scalbnl_nan -> passed [0.004s] [192.168.10.2] out: lib/msun/scalbn_test:scalbnl_val -> passed [0.004s] [192.168.10.2] out: lib/msun/scalbn_test:scalbnl_zero_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/scalbn_test:scalbnl_zero_pos -> passed [0.005s] [192.168.10.2] out: lib/msun/sin_test:sin_angles -> passed [0.004s] [192.168.10.2] out: lib/msun/sin_test:sin_inf_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/sin_test:sin_inf_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/sin_test:sin_nan -> passed [0.004s] [192.168.10.2] out: lib/msun/sin_test:sin_zero_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/sin_test:sin_zero_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/sin_test:sinf_angles -> passed [0.004s] [192.168.10.2] out: lib/msun/sin_test:sinf_inf_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/sin_test:sinf_inf_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/sin_test:sinf_nan -> passed [0.004s] [192.168.10.2] out: lib/msun/sin_test:sinf_zero_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/sin_test:sinf_zero_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/sinh_test:sinh_inf_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/sinh_test:sinh_inf_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/sinh_test:sinh_inrange -> passed [0.004s] [192.168.10.2] out: lib/msun/sinh_test:sinh_nan -> passed [0.004s] [192.168.10.2] out: lib/msun/sinh_test:sinh_zero_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/sinh_test:sinh_zero_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/sinh_test:sinhf_inf_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/sinh_test:sinhf_inf_pos -> passed [0.005s] [192.168.10.2] out: lib/msun/sinh_test:sinhf_inrange -> passed [0.003s] [192.168.10.2] out: lib/msun/sinh_test:sinhf_nan -> passed [0.004s] [192.168.10.2] out: lib/msun/sinh_test:sinhf_zero_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/sinh_test:sinhf_zero_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/sqrt_test:sqrt_inf_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/sqrt_test:sqrt_inf_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/sqrt_test:sqrt_nan -> passed [0.004s] [192.168.10.2] out: lib/msun/sqrt_test:sqrt_pow -> passed [0.004s] [192.168.10.2] out: lib/msun/sqrt_test:sqrt_zero_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/sqrt_test:sqrt_zero_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/sqrt_test:sqrtf_inf_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/sqrt_test:sqrtf_inf_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/sqrt_test:sqrtf_nan -> passed [0.004s] [192.168.10.2] out: lib/msun/sqrt_test:sqrtf_powf -> passed [0.004s] [192.168.10.2] out: lib/msun/sqrt_test:sqrtf_zero_neg -> passed [0.013s] [192.168.10.2] out: lib/msun/sqrt_test:sqrtf_zero_pos -> passed [0.005s] [192.168.10.2] out: lib/msun/sqrt_test:sqrtl_inf_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/sqrt_test:sqrtl_inf_pos -> passed [0.005s] [192.168.10.2] out: lib/msun/sqrt_test:sqrtl_nan -> passed [0.004s] [192.168.10.2] out: lib/msun/sqrt_test:sqrtl_powl -> passed [0.004s] [192.168.10.2] out: lib/msun/sqrt_test:sqrtl_zero_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/sqrt_test:sqrtl_zero_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/tan_test:tan_angles -> passed [0.007s] [192.168.10.2] out: lib/msun/tan_test:tan_inf_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/tan_test:tan_inf_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/tan_test:tan_nan -> passed [0.004s] [192.168.10.2] out: lib/msun/tan_test:tan_zero_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/tan_test:tan_zero_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/tan_test:tanf_angles -> passed [0.005s] [192.168.10.2] out: lib/msun/tan_test:tanf_inf_neg -> passed [0.005s] [192.168.10.2] out: lib/msun/tan_test:tanf_inf_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/tan_test:tanf_nan -> passed [0.004s] [192.168.10.2] out: lib/msun/tan_test:tanf_zero_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/tan_test:tanf_zero_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/tanh_test:tanh_inf_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/tanh_test:tanh_inf_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/tanh_test:tanh_nan -> passed [0.004s] [192.168.10.2] out: lib/msun/tanh_test:tanh_zero_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/tanh_test:tanh_zero_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/tanh_test:tanhf_inf_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/tanh_test:tanhf_inf_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/tanh_test:tanhf_nan -> passed [0.004s] [192.168.10.2] out: lib/msun/tanh_test:tanhf_zero_neg -> passed [0.004s] [192.168.10.2] out: lib/msun/tanh_test:tanhf_zero_pos -> passed [0.004s] [192.168.10.2] out: lib/msun/cexp_test:main -> passed [0.006s] [192.168.10.2] out: lib/msun/conj_test:main -> passed [0.006s] [192.168.10.2] out: lib/msun/csqrt_test:main -> passed [0.004s] [192.168.10.2] out: lib/msun/ctrig_test:main -> passed [0.022s] [192.168.10.2] out: lib/msun/exponential_test:main -> passed [0.006s] [192.168.10.2] out: lib/msun/fenv_test:main -> passed [0.009s] [192.168.10.2] out: lib/msun/fma_test:main -> passed [0.007s] [192.168.10.2] out: lib/msun/fmaxmin_test:main -> passed [0.005s] [192.168.10.2] out: lib/msun/ilogb_test:main -> passed [0.020s] [192.168.10.2] out: lib/msun/invtrig_test:main -> passed [0.082s] [192.168.10.2] out: lib/msun/invctrig_test:main -> passed [0.017s] [192.168.10.2] out: lib/msun/logarithm_test:main -> passed [0.009s] [192.168.10.2] out: lib/msun/lrint_test:main -> passed [0.005s] [192.168.10.2] out: lib/msun/nan_test:main -> passed [0.005s] [192.168.10.2] out: lib/msun/nearbyint_test:main -> passed [0.005s] [192.168.10.2] out: lib/msun/next_test:main -> passed [0.005s] [192.168.10.2] out: lib/msun/rem_test:main -> passed [0.004s] [192.168.10.2] out: lib/msun/trig_test:main -> passed [0.004s] [192.168.10.2] out: lib/libarchive/functional_test:test_acl_freebsd_nfs4 -> passed [0.108s] [192.168.10.2] out: lib/libarchive/functional_test:test_acl_freebsd_posix1e_read -> passed [0.080s] [192.168.10.2] out: lib/libarchive/functional_test:test_acl_freebsd_posix1e_restore -> passed [0.078s] [192.168.10.2] out: lib/libarchive/functional_test:test_acl_nfs4 -> passed [0.077s] [192.168.10.2] out: lib/libarchive/functional_test:test_acl_pax -> passed [0.097s] [192.168.10.2] out: lib/libarchive/functional_test:test_acl_posix1e -> passed [0.063s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_api_feature -> passed [0.063s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_clear_error -> passed [0.059s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_cmdline -> passed [0.063s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_getdate -> passed [0.070s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_match_owner -> passed [0.059s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_match_path -> passed [0.070s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_match_time -> passed [2.150s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_md5 -> passed [0.059s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_pathmatch -> passed [0.059s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_read_add_passphrase -> passed [0.061s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_read_add_passphrase_incorrect_sequance -> passed [0.069s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_read_add_passphrase_multiple -> passed [0.060s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_read_add_passphrase_multiple_with_callback -> passed [0.060s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_read_add_passphrase_multiple_with_callback2 -> passed [0.060s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_read_add_passphrase_set_callback1 -> passed [0.070s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_read_add_passphrase_set_callback2 -> passed [0.065s] [192.168.10.2] out: lib/libarchive/functional_test:test_archive_read_add_passphrase_set_callback3 -> passed [0.099s] Resuming build at Fri Nov 04 14:47:40 GMT 2016 after Jenkins restart Waiting to resume part of FreeBSD_stable_10 #447: ??? Waiting to resume part of FreeBSD_stable_10 #447: chaos.ysv.freebsd.org is offline Waiting to resume part of FreeBSD_stable_10 #447: chaos.ysv.freebsd.org is offline Waiting to resume part of FreeBSD_stable_10 #447: chaos.ysv.freebsd.org is offline Waiting to resume part of FreeBSD_stable_10 #447: chaos.ysv.freebsd.org is offline Waiting to resume part of FreeBSD_stable_10 #447: chaos.ysv.freebsd.org is offline Waiting to resume part of FreeBSD_stable_10 #447: chaos.ysv.freebsd.org is offline Waiting to resume part of FreeBSD_stable_10 #447: chaos.ysv.freebsd.org is offline Waiting to resume part of FreeBSD_stable_10 #447: chaos.ysv.freebsd.org is offline Waiting to resume part of FreeBSD_stable_10 #447: chaos.ysv.freebsd.org is offline Waiting to resume part of FreeBSD_stable_10 #447: chaos.ysv.freebsd.org is offline Ready to run at Fri Nov 04 14:50:24 GMT 2016 [192.168.10.2] out: lib/libarchive/functional_test:test_archive_read_add_passphrase_single -> Killed [Pipeline] } [Pipeline] // stage [Pipeline] } [Pipeline] // node [Pipeline] node Running on master in /usr/local/jenkins/workspace/FreeBSD_stable_10 [Pipeline] { [Pipeline] step From owner-freebsd-stable@freebsd.org Fri Nov 4 16:40:40 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 60486C3088C; Fri, 4 Nov 2016 16:40:40 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 453F921D; Fri, 4 Nov 2016 16:40:40 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 3E3EB19CD; Fri, 4 Nov 2016 16:40:40 +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 1186D236A4; Fri, 4 Nov 2016 16:40:40 +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 Mw8msTuiGH6c; Fri, 4 Nov 2016 16:40:37 +0000 (UTC) Subject: Re: Use of env SRC_ENV_CONF=. . . for buildworld does not override/avoid use of /etc/src.conf : Intentional? DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 5D5F22369E To: Mark Millard , FreeBSD Toolchain References: <12E108A2-21FE-4756-B099-334ADD020891@dsl-only.net> Cc: FreeBSD-STABLE Mailing List , FreeBSD Current From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: Date: Fri, 4 Nov 2016 09:40:38 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <12E108A2-21FE-4756-B099-334ADD020891@dsl-only.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oAP7J6QL5dLL0XxERUIdMosoREamTrxRR" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 16:40:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oAP7J6QL5dLL0XxERUIdMosoREamTrxRR Content-Type: multipart/mixed; boundary="looeSuF26cG8JXFF824smikDcS5lhPob6"; protected-headers="v1" From: Bryan Drewery To: Mark Millard , FreeBSD Toolchain Cc: FreeBSD-STABLE Mailing List , FreeBSD Current Message-ID: Subject: Re: Use of env SRC_ENV_CONF=. . . for buildworld does not override/avoid use of /etc/src.conf : Intentional? References: <12E108A2-21FE-4756-B099-334ADD020891@dsl-only.net> In-Reply-To: <12E108A2-21FE-4756-B099-334ADD020891@dsl-only.net> --looeSuF26cG8JXFF824smikDcS5lhPob6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11/3/2016 5:28 PM, Mark Millard wrote: > I just had a case of "odd" command text in a buildworld that was based = on (in part) env SRC_ENV_CONF=3D. . . >=20 > env __MAKE_CONF=3D. . . does not get the kind of behavior reported belo= w for /etc/src.conf . >=20 > Overall this means that even with an explicit env SRC_ENV_CONF=3D. . . = one must separately prevent /etc/src.conf from contributing if the SRC_EN= V_CONF file is intended to cover everything. SRC_ENV_CONF is kind of a special hack to allow setting some specific values that feasibly can't be set later. Just stick to src.conf unless you need to set one of the options that requires src-env.conf. --=20 Regards, Bryan Drewery --looeSuF26cG8JXFF824smikDcS5lhPob6-- --oAP7J6QL5dLL0XxERUIdMosoREamTrxRR 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 iQEcBAEBAgAGBQJYHLoGAAoJEDXXcbtuRpfPfEwIAIUeutQcPuHhDrxl+eziQZpu wxTwm3fdIt/lT2QDpyC50HkaywQvbFyLDP4MWjTnibC/wJ0J9Dq0venUVqZE77I0 k5/bVMM8y9zeYGWELyPgqni1FQif2b1rLDgJMSW84unbLCH5O7qbC10/0eNAsnGw IgKtfGhF3YfvGeqa+KMMBuUgl4fjWgM9++Wq9HshPScwGOBqD4PYcxQMEmwyTK5U +fc5Ut6JSMbBABJuFPvlANLhlDOy6iTNbLW2UNLvUVsbm8WPbFOOt5PPzdWoEa6l dzGfEp+kv8KX8ZWy5AHw7E4quIPnyRtwAcsLiiBqcx+lWZK3CADTWBGzVXrG8S8= =Id5O -----END PGP SIGNATURE----- --oAP7J6QL5dLL0XxERUIdMosoREamTrxRR-- From owner-freebsd-stable@freebsd.org Sat Nov 5 03:46:57 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B0A15C30E7A for ; Sat, 5 Nov 2016 03:46:57 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 13CED832; Sat, 5 Nov 2016 03:46:56 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id uA53kn19084756; Sat, 5 Nov 2016 14:46:50 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 5 Nov 2016 14:46:49 +1100 (EST) From: Ian Smith To: Glen Barber cc: freebsd-stable@FreeBSD.org Subject: Re: 1MB swap partition on 11.0 memstick In-Reply-To: <20161104144452.GB79915@FreeBSD.org> Message-ID: <20161105143511.D41537@sola.nimnet.asn.au> References: <20161104183856.U41537@sola.nimnet.asn.au> <20161104144452.GB79915@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2016 03:46:57 -0000 On Fri, 4 Nov 2016 14:44:52 +0000, Glen Barber wrote: > On Fri, Nov 04, 2016 at 06:50:16PM +1100, Ian Smith wrote: > > 1431696 2048 md0p4 freebsd-swap (1.0M) > I would need to look through the commit logs to confirm, but if I recall > correctly, the memstick images failed to boot properly without the 1MB > swap after the freebsd-ufs partition after converting the image build to > use mkimg(1). Your recall is in perfect working order, for which we are all thankful. https://svnweb.freebsd.org/base?view=revision&revision=265017 cheers, Ian From owner-freebsd-stable@freebsd.org Sat Nov 5 03:50:24 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C4C54C300EC for ; Sat, 5 Nov 2016 03:50:24 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id B5524A6B; Sat, 5 Nov 2016 03:50:24 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id 752EA1CE0; Sat, 5 Nov 2016 03:50:24 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Sat, 5 Nov 2016 03:50:22 +0000 From: Glen Barber To: Ian Smith Cc: freebsd-stable@FreeBSD.org Subject: Re: 1MB swap partition on 11.0 memstick Message-ID: <20161105035022.GJ79915@FreeBSD.org> References: <20161104183856.U41537@sola.nimnet.asn.au> <20161104144452.GB79915@FreeBSD.org> <20161105143511.D41537@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="r4QXMf6/kyF/FvJJ" Content-Disposition: inline In-Reply-To: <20161105143511.D41537@sola.nimnet.asn.au> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer X-Spidey-Sense: Uh oh, Peter logged in User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2016 03:50:24 -0000 --r4QXMf6/kyF/FvJJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 05, 2016 at 02:46:49PM +1100, Ian Smith wrote: > On Fri, 4 Nov 2016 14:44:52 +0000, Glen Barber wrote: > > On Fri, Nov 04, 2016 at 06:50:16PM +1100, Ian Smith wrote: >=20 > > > 1431696 2048 md0p4 freebsd-swap (1.0M) >=20 > > I would need to look through the commit logs to confirm, but if I reca= ll > > correctly, the memstick images failed to boot properly without the 1MB > > swap after the freebsd-ufs partition after converting the image build = to > > use mkimg(1). >=20 > Your recall is in perfect working order, for which we are all thankful. >=20 It is sometimes a curse. :) Glen --r4QXMf6/kyF/FvJJ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYHVb5AAoJEAMUWKVHj+KTLRsP/38TgHB3+pbB0YXOaennmVnH uItN2CQ9rfRrzEHybgx3OA6VxOLQ0Z1OhfuzxooNVeUGSxQSD/My8KDfIDa8P/Kz djz4VLBf5gpnF0CLFjzUg3W8wbufh5Uxbud1Ny/ywyEhgeXyP/HLy93o3yfqqO9I 4PziKT1c61yTeBhh8xyRGCcXgIJmytAwWiZiO8nA/FOw697eBOATrAYX0iylzsCh 3QUkvvMogM1Jzqep9DV2UkMy+27ViSshVp8THdRX1bbltJWueDQjSONP2UTolzVa RfAsPDtvSUfuKb6LsY5g+eNf1gaigLlMM45ZRuSAUvGvHJNMQ2FI8By7EyDYVIJH obUkgLjJ45RhPFUneg1gXn0gPLz1rGO0EezylvglSJKeKk3QDURDTBn+L9wn/PHh dp8U9/0l8hBfx8Yzw/MEh9crvbu630iQ7KwWVhsf4j8Zwev6s0JrdhVYN3Xq/FAx utL1QvefzxbWd2ZOXjooHLfA9b1BwXqj3Vig8lgFvCYYvJjgX3nZbr/Fg7XOIZjN ahMXtQe3SzcGcl/uSQzIXTxuzFX6G+O2+TYN/91wmjo1WK/gTNFhHIiJAiKBa4rS eDiOULxUt8+MUiceGV7nis2eo2uqFF86yBXUKaYQkKF/Vp+HWVwBGBYiMr3UTLK/ xOZrjQKsuDzvMs08YHla =jt4f -----END PGP SIGNATURE----- --r4QXMf6/kyF/FvJJ-- From owner-freebsd-stable@freebsd.org Sat Nov 5 05:05:05 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A89D7C306CD for ; Sat, 5 Nov 2016 05:05:05 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 72728A01 for ; Sat, 5 Nov 2016 05:05:05 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-it0-x234.google.com with SMTP id q124so22533440itd.1 for ; Fri, 04 Nov 2016 22:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=73A9p2dVBwB9VcLWBz3HZ2v5RWNPRe9kWIPqO6+tbeU=; b=FK6fi5+NGvyi6AJFoqoJpGw7O57CW49x/RuWQSq/nAP1OozSwjzYkjNYzywtDLZ/HP cGXG5ZCMdFSXyVN4xRJVFDxifbuduv70B68S4mH90LrTD3MUl3F6jOF5mH/JbGD3Qt35 DX5tqKEogKeKYjtJWz+oACDZnWhub5hbV8XVO7mIKD02dPLmQM+B6gltr3j8mqwssMIc abbgrQubSABNkvrmExkon9qrepZWsAgxOjTqT3MPLJhjFy0lZkFUHubqFCLIsKSsuXOD RPdwU26X5gtk9t6LyoEAOrZNAyBQ42EoLQWQ9Wpd6u26pdTOOOV+rkOZvOFzgrts8IAI nWqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=73A9p2dVBwB9VcLWBz3HZ2v5RWNPRe9kWIPqO6+tbeU=; b=IGIFt+CBgf9gRMOCpYlxzmkmiAFHP0l8ERZFMfzXcDmUTHDSWoqSmXFW4vS2wT5SFg Ak5XKBHA0crK9eGfG7WHkP8bWpux3Vp11+O/IMnmL2YOjpzNok1L+r5LztgjXjxbTtDq hby1zi7axgYx0VmsLVG+b0Ec5ntO27cywfwygJoKasRlQNX4c30g/Vvwcl+K4C+Sflxn 7Y4qqLg01HxQ5HRSgK5f+edGEccE5ZGvAcMTiJFq16t5XVyYmk/cJsH4500nU3vXN+AX pAB+Ek7DnbJftgiNVXjK3kHwga8xroFOHWChJVSeMxpcrY8ZxF9h4eNJ2c7upXyaWKZI bYfQ== X-Gm-Message-State: ABUngvcdjx9Jn8EdoIknmcqPDWEttGJbeg535Znryet1EIbYxGuRa+xhq2JROrd5AqFCLJ9kb9u/n+lHF5IDAQ== X-Received: by 10.107.174.229 with SMTP id n98mr16227523ioo.177.1478322304705; Fri, 04 Nov 2016 22:05:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.39.134 with HTTP; Fri, 4 Nov 2016 22:05:04 -0700 (PDT) In-Reply-To: References: <3e831eea-2035-b658-3bae-784f2aa60eca@m5p.com> From: Adrian Chadd Date: Fri, 4 Nov 2016 22:05:04 -0700 Message-ID: Subject: Re: ath0 associated, wlan0 not associated To: George Mitchell Cc: FreeBSD Stable Mailing List Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2016 05:05:05 -0000 nope, sorry. There's a lot of work in the -11 wifi stack and drivers. -a On 3 November 2016 at 16:04, George Mitchell wrote: > Thanks for the suggestion. I won't be able to try it until after a > business trip next week. Any patches available that apply to 10.3? > -- George > > On 11/03/16 18:48, Adrian Chadd wrote: >> hi, >> >> can you please try freebsd-11.0 ? I fixed a whole bunch of bugs in the >> AR9380 HAL and it may have improved that device. >> >> Thanks! >> >> >> -a >> >> >> On 3 November 2016 at 07:09, George Mitchell wrote: >>> Originally posted to freebsd-wireless; no solution yet so I thought >>> I'd try here. After booting up, my ath0 interface says it is >>> associated, but my wlan0 says it is not: >>> >>> >>> FreeBSD 10.3-RELEASE-p11 >>> wpa_supplicant v2.0 >>> Copyright (c) 2003-2012, Jouni Malinen and contributors >>> >>> ath0@pci0:2:0:0: class=0x028000 card=0x064211ad chip=0x0036168c rev=0x01 >>> hdr=0x00 >>> vendor = 'Qualcomm Atheros' >>> device = 'QCA9565 / AR9565 Wireless Network Adapter' >>> class = network >>> >>> grep wlan /etc/rc.conf: >>> create_args_wlan0="country US" >>> ifconfig_wlan0="WPA DHCP" >>> wlans_ath0="wlan0" >>> >>> And the result is: >>> >>> ifconfig wlan0: >>> wlan0: flags=8c43 metric >>> 0 mtu 1500 >>> ether d0:53:49:91:6f:a1 >>> inet6 fe80::d253:49ff:fe91:6fa1%wlan0 prefixlen 64 scopeid 0x4 >>> inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 >>> nd6 options=23 >>> media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) >>> status: no carrier >>> ssid "" channel 2 (2417 MHz 11g ht/40+) >>> regdomain FCC country US indoor ecm authmode WPA2/802.11i privacy ON >>> deftxkey UNDEF txpower 30 bmiss 7 scanvalid 60 protmode CTS >>> ampdulimit 8k ampdudensity 8 shortgi wme burst roaming MANUAL >>> >>> ifconfig ath0: >>> ath0: flags=8843 metric 0 mtu 2290 >>> ether d0:53:49:91:6f:a1 >>> nd6 options=21 >>> media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng >>> status: associated >>> >>> grep wpa /var/log/messages: >>> ov 1 09:16:54 haymarket wpa_supplicant[389]: wlan0: Trying to associate >>> with xx:xx:xx:xx:xx:xx (SSID='yyyyyyyyyy' freq=2417 MHz) >>> Nov 1 09:16:54 haymarket wpa_supplicant[389]: wlan0: Associated with >>> 60:e3:27:7b:e8:42 >>> Nov 1 09:16:54 haymarket wpa_supplicant[389]: wlan0: WPA: Key >>> negotiation completed with xx:xx:xx:xx:xx:xx [PTK=CCMP GTK=TKIP] >>> Nov 1 09:16:54 haymarket wpa_supplicant[389]: wlan0: >>> CTRL-EVENT-CONNECTED - Connection to xx:xx:xx:xx:xx:xx completed [id=1 >>> id_str=] >>> Nov 1 09:16:55 haymarket wpa_supplicant[389]: wlan0: WPA: Key >>> negotiation completed with xx:xx:xx:xx:xx:xx [PTK=CCMP GTK=TKIP] >>> Nov 1 09:16:56 haymarket wpa_supplicant[389]: wlan0: WPA: Key >>> negotiation completed with xx:xx:xx:xx:xx:xx [PTK=CCMP GTK=TKIP] >>> Nov 1 09:16:57 haymarket wpa_supplicant[389]: wlan0: WPA: Key >>> negotiation completed with xx:xx:xx:xx:xx:xx [PTK=CCMP GTK=TKIP] >>> Nov 1 09:16:57 haymarket wpa_supplicant[389]: wlan0: >>> CTRL-EVENT-DISCONNECTED bssid=xx:xx:xx:xx:xx:xx reason=0 >>> Nov 1 09:16:59 haymarket wpa_supplicant[389]: wlan0: Trying to >>> associate with xx:xx:xx:xx:xx:xx (SSID='yyyyyyyyyy' freq=2417 MHz) >>> Nov 1 09:17:09 haymarket wpa_supplicant[389]: wlan0: Authentication >>> with xx:xx:xx:xx:xx:xx timed out. >>> Nov 1 09:17:09 haymarket wpa_supplicant[389]: wlan0: >>> CTRL-EVENT-DISCONNECTED bssid=xx:xx:xx:xx:xx:xx2 reason=3 >>> locally_generated=1 >>> Nov 1 09:18:13 haymarket wpa_supplicant[389]: wlan0: Trying to >>> associate with xx:xx:xx:xx:xx:xx (SSID='yyyyyyyyyy' freq=2417 MHz >>> >>> etc. >>> >>> So how does ath0 get associated but not wlan0? -- George >>> >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > From owner-freebsd-stable@freebsd.org Sat Nov 5 17:01:04 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3E19AF71C0 for ; Sat, 5 Nov 2016 17:01:04 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [IPv6:2001:418:3fd::f7]) (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 7D48E934 for ; Sat, 5 Nov 2016 17:01:04 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [10.100.0.31] (haymarket.m5p.com [10.100.0.31]) by mailhost.m5p.com (8.15.2/8.15.2) with ESMTP id uA5H0uog020388; Sat, 5 Nov 2016 13:01:02 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Subject: Re: ath0 associated, wlan0 not associated To: Adrian Chadd References: <3e831eea-2035-b658-3bae-784f2aa60eca@m5p.com> Cc: FreeBSD Stable Mailing List From: George Mitchell Message-ID: Date: Sat, 5 Nov 2016 13:00:56 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.0 required=10.0 tests=ALL_TRUSTED, RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on scollay.m5p.com X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (mailhost.m5p.com [10.100.0.247]); Sat, 05 Nov 2016 13:01:02 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2016 17:01:04 -0000 On 11/05/16 01:05, Adrian Chadd wrote: > nope, sorry. There's a lot of work in the -11 wifi stack and drivers. > > > -a > > [...] Okay, I downloaded and installed 11.0-RELEASE on a spare slice, and dmesg tells me the following (with regard to ath0): ath0: mem 0xf0a00000-0xf0a7ffff irq 36 at device 0.0 on pci2 ath0: WB335 2-ANT card detected ath0: Bluetooth Antenna Diversity card detected ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 RX streams; 1 TX streams ath0: QCA9565 mac 704.1 RF5110 phy 2523.1 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 But ifconfig tells me there is no "ath0" interface ... Does 11.0 handle wifi in some unfamiliar manner? I put my usual wifi magic into rc.conf: create_args_wlan0="country US" ifconfig_wlan0="WPA DHCP" wlans_ath0="wlan0" -- George From owner-freebsd-stable@freebsd.org Sat Nov 5 18:58:54 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3B8EFBED2BB for ; Sat, 5 Nov 2016 18:58:54 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [IPv6:2001:418:3fd::f7]) (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 CEB1A75A for ; Sat, 5 Nov 2016 18:58:53 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [10.100.0.31] (haymarket.m5p.com [10.100.0.31]) by mailhost.m5p.com (8.15.2/8.15.2) with ESMTP id uA5Iwk0l021075; Sat, 5 Nov 2016 14:58:51 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Subject: Re: ath0 associated, wlan0 not associated To: Adrian Chadd References: <3e831eea-2035-b658-3bae-784f2aa60eca@m5p.com> Cc: FreeBSD Stable Mailing List From: George Mitchell Message-ID: Date: Sat, 5 Nov 2016 14:58:46 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.0 required=10.0 tests=ALL_TRUSTED, RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on scollay.m5p.com X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (mailhost.m5p.com [10.100.0.247]); Sat, 05 Nov 2016 14:58:52 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2016 18:58:54 -0000 On 11/05/16 13:00, George Mitchell wrote: > On 11/05/16 01:05, Adrian Chadd wrote: >> nope, sorry. There's a lot of work in the -11 wifi stack and drivers. >> >> >> -a >> >> [...] > > Okay, I downloaded and installed 11.0-RELEASE on a spare slice, and > dmesg tells me the following (with regard to ath0): > > > ath0: mem 0xf0a00000-0xf0a7ffff irq 36 at > device 0.0 on pci2 > ath0: WB335 2-ANT card detected > ath0: Bluetooth Antenna Diversity card detected > ath0: [HT] enabling HT modes > ath0: [HT] enabling short-GI in 20MHz mode > ath0: [HT] 1 stream STBC receive enabled > ath0: [HT] 1 RX streams; 1 TX streams > ath0: QCA9565 mac 704.1 RF5110 phy 2523.1 > ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 > > But ifconfig tells me there is no "ath0" interface ... Does 11.0 > handle wifi in some unfamiliar manner? I put my usual wifi magic > into rc.conf: > > create_args_wlan0="country US" > ifconfig_wlan0="WPA DHCP" > wlans_ath0="wlan0" > > -- George > I forgot to copy my wpa_supplicant.conf over. Now it works! (I guess the invisible ath0 is just how 11.0 works?) -- George