From owner-freebsd-stable@freebsd.org Sun Jul 30 05:14:25 2017 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 64CC8DAEDF0 for ; Sun, 30 Jul 2017 05:14:25 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 52BA265CA3 for ; Sun, 30 Jul 2017 05:14:25 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: by mailman.ysv.freebsd.org (Postfix) id 4F31EDAEDEE; Sun, 30 Jul 2017 05:14:25 +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 4C651DAEDEC for ; Sun, 30 Jul 2017 05:14:25 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from hobbes.arroway.org (hobbes.arroway.org [173.199.118.77]) by mx1.freebsd.org (Postfix) with ESMTP id 20C2E65CA2 for ; Sun, 30 Jul 2017 05:14:24 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from [10.1.1.10] (unknown [177.89.5.111]) by hobbes.arroway.org (Postfix) with ESMTPA id E75791FD737 for ; Sun, 30 Jul 2017 02:08:11 -0300 (BRT) Received: from 10.1.1.66 (SquirrelMail authenticated user matheus) by 10.1.1.10 with HTTP; Sun, 30 Jul 2017 02:08:11 -0300 Message-ID: <39221eefb6288d3b9154e85f4faa6501.squirrel@10.1.1.10> Date: Sun, 30 Jul 2017 02:08:11 -0300 Subject: FreeBSD 11.1-R network slowness on Samba From: "Nenhum_de_Nos" To: stable@freebsd.org User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal 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 Jul 2017 05:14:25 -0000 Hi, I was running 10.3-p7 on Atom hardware and using old samba36-3.6.25_1. All was fine. Then I updated to 11.1-R by recompiling from svn, using the same kernelconfig from 10.3, and now my windows client shows timeouts and really slow connection. File copy never past kilobytes per second :( I am compiling a new samba packet from ports, but that slow is weird for me, and I could not find any other cases on web search. thanks, matheus -- "We will call you Cygnus, the God of balance you shall be." From owner-freebsd-stable@freebsd.org Mon Jul 31 06:59:38 2017 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 99A7CDCB70B for ; Mon, 31 Jul 2017 06:59:38 +0000 (UTC) (envelope-from arcade@b1t.name) Received: from limbo.b1t.name (limbo.b1t.name [78.25.32.206]) (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 430B06A92A for ; Mon, 31 Jul 2017 06:59:38 +0000 (UTC) (envelope-from arcade@b1t.name) Received: from [172.29.1.239] (probe.42.lan [172.29.1.239]) by limbo.b1t.name (Postfix) with ESMTPSA id 3A99BDE for ; Mon, 31 Jul 2017 09:51:12 +0300 (EEST) To: FreeBSD Stable From: Volodymyr Kostyrko Subject: ZFS bootable pool detection code strictness Message-ID: <99c0d5c2-6581-4516-6938-50ad84670f2e@b1t.name> Date: Mon, 31 Jul 2017 09:51:11 +0300 User-Agent: Mozilla/5.0 (X11; DragonFly x86_64; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=b1t.name; s=dkim; t=1501483873; bh=kCpO6ngEY0F8PYndcmGQXXmpxrEmiEuiNQE+49Fp67A=; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type:Content-Transfer-Encoding; b=1l3oIAV9JSe/lH1ubQJ5aeECJmIu+Fc5zwfWAYJm/BVpV2thv1vDGj9SFRmhDT1at0HctwHD4jbMhlVA3d0ickUQebobVdIyDgN0zRXx9oW2WJFRY3DSgyK1IDtE7zPFxxwcYP7mh9Bur8+NO8kIHGXsnoOvTa6BGVp3pLAFfWQ= 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 Jul 2017 06:59:38 -0000 Hi all. First of all thank you for working on ZFS support. ZFS stability is unmatchable and I'm heavily relying on ZFS right now. Last bootcode updates had given me some fun time. My pool contains some vdevs with skein enabled so new bootcode forced my pool out of boot. I know that my hands are dirty but I'm sure the pool is bootable as everything required for booting was never touched by unsupported options (I know the boot will fail instantly). Yes, I do like experimenting a lot. From my point of view the code committed is just too strict locking out anyone who tries to play with extra pool properties. The analyzer itself is nice and I don't want it to go away as every extra bit of information about why boot may fail is precious but I'd be very happy to have some loader knob to disable the pool blacklisting so that the code will test the pool, will report everything it finds unsuitable but would allow a booting attempt. Thanks in advance. -- Sphinx of black quartz judge my vow. From owner-freebsd-stable@freebsd.org Mon Jul 31 07:28:36 2017 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 97FBCDCBF4C for ; Mon, 31 Jul 2017 07:28:36 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 85FC86B68F for ; Mon, 31 Jul 2017 07:28:36 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id 82601DCBF4B; Mon, 31 Jul 2017 07:28:36 +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 81EFDDCBF4A for ; Mon, 31 Jul 2017 07:28:36 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 4115B6B68E for ; Mon, 31 Jul 2017 07:28:35 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1dc4pD-00090w-He for stable@freebsd.org; Mon, 31 Jul 2017 10:09:11 +0300 From: Daniel Braniss Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: issues with powerd/freq_levels Message-Id: <8AEC9DBC-BADD-4FB2-8358-DA43F7EF5E68@cs.huji.ac.il> Date: Mon, 31 Jul 2017 10:09:11 +0300 To: stable@freebsd.org X-Mailer: Apple Mail (2.3273) 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 Jul 2017 07:28:36 -0000 I am trying out PCengines latest apu2 boards, and I just noticed that = with different Freebsd versions I get different freq_levels, and so when idling, each box (have 5) has a = different freq/temperature value, ranging from 125/69.1C, 600/59.0C to 75/56.0C FreeBSD apu-4 11.1-STABLE FreeBSD 11.1-STABLE #5 f565b5a06ab3 (11) tip: = Mon Jul 31 09:36:33 IDT 2017 apu-4# sysctl dev.cpu.0.freq_levels dev.cpu.0.freq_levels: 1000/980 800/807 600/609 FreeBSD apu-5 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #0 21e9d1ca9b80 = (11) tip: Tue May 30 11:51:48 IDT 2017 apu-5# sysctl dev.cpu.0.freq_levels dev.cpu.0.freq_levels: 1000/966 875/845 800/795 700/695 600/600 525/525 = 450/450 375/375 300/300 225/225 150/150 75/75 FreeBSD apu-1 10.3-STABLE FreeBSD 10.3-STABLE #4 267788fd852c (10) tip: = Tue Jan 10 09:09:00 IST 2017 apu-1# sysctl dev.cpu.0.freq_levels dev.cpu.0.freq_levels: 1000/-1 875/-1 750/-1 625/-1 500/-1 375/-1 250/-1 = 125/-1 so, any ideas as to what is going on? thanks, danny From owner-freebsd-stable@freebsd.org Mon Jul 31 07:42:59 2017 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 4F13EDCC504 for ; Mon, 31 Jul 2017 07:42:59 +0000 (UTC) (envelope-from peter@pean.org) Received: from system.jails.se (system.jails.se [IPv6:2001:470:6c08::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 069E26BFA4 for ; Mon, 31 Jul 2017 07:42:58 +0000 (UTC) (envelope-from peter@pean.org) Received: from system.jails.se (mail.jails.se [172.31.20.14]) by system.jails.se (Postfix) with SMTP id 7064111195F for ; Mon, 31 Jul 2017 09:42:56 +0200 (CEST) Received: from lune.pean.org (213-67-100-148-no110.tbcn.telia.com [213.67.100.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by system.jails.se (Postfix) with ESMTPSA id B001711195D for ; Mon, 31 Jul 2017 09:42:55 +0200 (CEST) From: =?utf-8?Q?Peter_Ankerst=C3=A5l?= Content-Type: multipart/signed; boundary="Apple-Mail=_89ACE7BC-AC0A-4B8A-9D7C-B57877402DDE"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Upgrade to 11.1-RELEASE fails to boot on aws EC2. Date: Mon, 31 Jul 2017 09:42:54 +0200 References: <23825E1D-AC7B-45A4-97D2-A7B38C1E35BA@pean.org> To: FreeBSD Stable In-Reply-To: <23825E1D-AC7B-45A4-97D2-A7B38C1E35BA@pean.org> Message-Id: X-Mailer: Apple Mail (2.3273) X-DSPAM-Result: Innocent X-DSPAM-Processed: Mon Jul 31 09:42:56 2017 X-DSPAM-Confidence: 1.0000 X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 597edf8072671872110170 X-DSPAM-Factors: 27, me+Because+#+#+not, 0.40000, pean+org+#+#+It, 0.40000, problem+before+when+#+to, 0.40000, peter+#+#+#+On, 0.40000, that+FreeBSD+#+1+RELEASE, 0.40000, give+#+#+output+I, 0.40000, in+the+#+Reverting+to, 0.40000, using+the, 0.40000, 1+#+#+#+on, 0.40000, but, 0.40000, described+#+#+handbook, 0.40000, VM+#+#+the+data, 0.40000, old+build+world, 0.40000, it+actually, 0.40000, 16+#+loader+#+Today, 0.40000, I+have+#+https+forums, 0.40000, of+works, 0.40000, a+#+of+works+fine, 0.40000, Peter+Ankerst%c3%a5l+peter+#+org, 0.40000, Peter+Ankerst%c3%a5l+peter+#+org, 0.40000, when+upgrading+#+#+0, 0.40000, Subject*Re+#+to+#+fails, 0.40000, I+tried, 0.40000, I+tried, 0.40000, just, 0.40000, on+EC2, 0.40000, give+any+video+output, 0.40000 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 Jul 2017 07:42:59 -0000 --Apple-Mail=_89ACE7BC-AC0A-4B8A-9D7C-B57877402DDE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 28 Jul 2017, at 23:28, Peter Ankerst=C3=A5l wrote: >=20 >>=20 >>> On 28 Jul 2017, at 12:41, Peter Ankerst=C3=A5l = wrote: >>>=20 >>> Hi! >>>=20 >>> It seems that FreeBSD 11.1-RELEASE also breaks on EC2 in some cases. = I had this problem before when upgrading to 11.0. This problem was = noticed in the ERRATA: = https://www.freebsd.org/releases/11.0R/errata.html#open-issues >>> and later said to have been resolved with a EN: = https://www.freebsd.org/security/advisories/FreeBSD-EN-16:18.loader.asc >>>=20 >>> Today I tried to upgrade a 11.0-RELEASE-p7 system to 11.1-RELEASE = using the good old build world method as described in the handbook. But = after reboot the machine hangs >>> in the loader. Reverting to a snapshot of / works fine but of course = I have a lot of problems due to kernel/world mismatch. So I tried to = copy the old /boot/ onto the newly updated >>> system and then it actually gets past the loader. But then fails to = boot for some other reason unknown to me. (Because it does not give any = video output) >>>=20 >>> I have also posted to the forums about this with a few screenshots = and more details of what I have tried: >>> https://forums.freebsd.org/threads/61780/ >>>=20 I just installed a new VM and moved the data instead. --Apple-Mail=_89ACE7BC-AC0A-4B8A-9D7C-B57877402DDE Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL1TCCBeIw ggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmlj YXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4X DTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNx WacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+C evdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx 7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8U lVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1Ud DwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB /wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmww ZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYI KwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQU JIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYD VR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY0JdO ruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM 3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2 Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+ q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo 02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf 1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq 2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5 Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1 UeGp/2deoprGevfnxWB+vHNQiu85o6MwggXrMIIE06ADAgECAhAVg7EhX8r2LDRKhDrOrr8zMA0G CSqGSIb3DQEBCwUAMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYD VQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20g Q2xhc3MgMSBDbGllbnQgQ0EwHhcNMTcwMTI2MjAxNDMwWhcNMjAwNDI2MjAxNDMwWjA4MRcwFQYD VQQDDA5wZXRlckBwZWFuLm9yZzEdMBsGCSqGSIb3DQEJARYOcGV0ZXJAcGVhbi5vcmcwggIiMA0G CSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDcqYms37M3iO33p6LWK/fj7JFLGVacfvZf4CaHyg8m jY4sVP9HzeB6A/FOk0fvxDvK0Q7dIkoQdniS7DKcsBXpJ5s+tpszOhQ36RpD3B0xao3z0sI+9MyK 6IDu7pjxunC5qLYnVkcDjBPJ0X8qyR/bSvUQ3kBEOppPs8ol8GHsiRSy3TJL2wGapAdA+1r2KCqe eHrrCTGj4Dl7xvgUkfii6wShPH0yu66raHvdN6DHUyb1EFgS70HZ22+HuffqGvOB+iZZUeE9UQT0 pbzgCcHfkXfgRtNkzKDzrfYmJi9oTIpfyvusu8F9B9L3rZM6V2Stag4LLAo+zhsX1quM20Ilo71U GPhLgvDNjJnx1qli3tAyddxMhqJMhcRYDScIoIi6xZ4jNJvMlHJGTq29oH+A2TjAmM+gJY+0p4RB vVhNf7e0jSaVeHei+H+q9OlQmylXC1GzcUrzFDqWLDB70Sta20rQakZEFsQ+e+shxmj4AakCxY4D x5PvyWk48JWtmfaXboDG8Lr5RaULjHGEtg6ULVQdYakJDuCkjyYtZSZtC8PKk1uFzJu4yhfX9vOb VEabLeO5dSvNWYllUQdOP9nuNh5ZnHxEIHA1k/UgRvdwootCJ4TrTfHp7fQLbMP7AE53x88/M++A wNofKHoNqE7iPh1s9Os0ZWi/czCiFRI7wwIDAQABo4IBsjCCAa4wDgYDVR0PAQH/BAQDAgSwMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBSxDZ1/nnS6 biObk7mYFx6CSYKuFzAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBvBggrBgEFBQcB AQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5BggrBgEFBQcwAoYt aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEuY3J0MDgGA1UdHwQxMC8w LaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGllbnQxLmNybDAZBgNVHREEEjAQ gQ5wZXRlckBwZWFuLm9yZzAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wRwYD VR0gBEAwPjA8BgsrBgEEAYG1NwECBTAtMCsGCCsGAQUFBwIBFh9odHRwczovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQCbKZGNOgGhchJ0IcN9rOEy8cwnHlBVDBTc kCdh6HPTeb7SiPmDLxJ1mp2ptKMjVDItkV9golRi4zWW0Q+aT8lJSbmLRWnTJflQB8zhbvSHwFzU VlsYEJBBUrMrfBeowZIcDLTr5VjmC7WysSSIAPyOLtbbIhYWVDiRc7FR3cMzMx0JHByg8iZqJ5/d S7CXj5NiRb8jp3Uo9Wo5o8qwuA0YQ/7ld7tZbE47jAQ6gOQ/J+yBNWCXOjklFmXeI6fxITO5XTq/ +SN1rp4lMR5KfahwYBf0m0jeZQbxek8XTTa1qHfDuZWdKP9Nab2LPYhOs+ShIMb3BNBgiJe7a3H7 yCwjMYIETjCCBEoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFy dENvbSBDbGFzcyAxIENsaWVudCBDQQIQFYOxIV/K9iw0SoQ6zq6/MzAJBgUrDgMCGgUAoIIBmTAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA3MzEwNzQyNTRaMCMG CSqGSIb3DQEJBDEWBBQXyluLrD/nP78cOggD753pwGwsYTCBmgYJKwYBBAGCNxAEMYGMMIGJMHUx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQg Q0ECEBWDsSFfyvYsNEqEOs6uvzMwgZwGCyqGSIb3DQEJEAILMYGMoIGJMHUxCzAJBgNVBAYTAklM MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0ECEBWDsSFfyvYs NEqEOs6uvzMwDQYJKoZIhvcNAQEBBQAEggIAOmnF4vL3zdZDEP02QZzHVhuqCRGPrdBO/QFzbUlO oSMjwFkk0r62avWw1okgPwAtP+TSQerKmJFRpaBw6bVt/CyPZ61FYxMMgElfcBY/Hhy0vQDA2Fgi 7qzO1/VJZN7O0POV1G8pXKz8KOr56hiL9uAMb2RHKlwHDF/hDVKiye4Zh8Ev11GHREKjM+RiPUFo qPL8SvdyyRfkjZbKxz3hHFbs5vEnUD5rnYkKkFfr5TLK4vUB2ao/pG1nXaXhDz6ubHIwaIsV/P5p coeAk472n5RdygQUPg4+MA3vToPwd6kfEiXiOATz7tC8N5WLj+VKsL3mna0ZoTPxIb3eIEwwjlYf /vs9V+A6fAr9l2OfebzoabYRNbQ4AX/bVgLW6ulXC9bEWTlZAoTSUbjBmO+hec2Btjv2jcbAB1xp HeE2Wiyn2ilNFYrwFlaz6FG4If4QstWBSV93p550zeafxPxb0Lg9NNre7HBz1A4G7Gu0cz+IQCjD fge2sVlBpyss65PsdX3LFZqqVCn/YCMfBN7exK6bz+ok8iICqBcz7q/PJ7DrYftL5ffOh9NzmXY0 OTJhaePj41sLX+6rJaSiWsENzBY75upnygBtMViwQfrd2yMzy/Mlh19P6JjbNtnZL9oxRPOq8Of5 35ZVwgjV4AdA2A4Bfwsui+TkVY/LF2S88R8AAAAAAAA= --Apple-Mail=_89ACE7BC-AC0A-4B8A-9D7C-B57877402DDE-- From owner-freebsd-stable@freebsd.org Mon Jul 31 10:19:58 2017 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 E2B8FDCF51E for ; Mon, 31 Jul 2017 10:19:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C3D8671254 for ; Mon, 31 Jul 2017 10:19:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v6VAJujL060147 for ; Mon, 31 Jul 2017 10:19:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 221050] emulators/virtualbox-ose: Bridged network doesn't work (11.1-RELEASE) Date: Mon, 31 Jul 2017 10:19:57 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: marko.cupac@mimar.rs X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not A Bug X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: vbox@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-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 Jul 2017 10:19:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221050 Marko Cupa=C4=87 changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marko.cupac@mimar.rs --- Comment #12 from Marko Cupa=C4=87 --- (In reply to Eugene Grosbein from comment #9) Thank you for this information, as this updates my understanding that all t= he packages for all the consequent minor releases are always built on an unpat= ched initial major release. Contrary to above concept, I have been building packages for minor releases= on latest binary patchlevels for these releases in poudriere, which resulted in quite a number of complete rebuilds. I've been considering the idea to start building everything on an unpatched 11.0-RELEASE poudriere jail. According = to this PR, it appears it's better not to. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Mon Jul 31 10:48:54 2017 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 3900ADCFEBB for ; Mon, 31 Jul 2017 10:48:54 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 269C1722BA for ; Mon, 31 Jul 2017 10:48:54 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: by mailman.ysv.freebsd.org (Postfix) id 25F4EDCFEBA; Mon, 31 Jul 2017 10:48:54 +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 258F6DCFEB9 for ; Mon, 31 Jul 2017 10:48:54 +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 8E978722B9 for ; Mon, 31 Jul 2017 10:48:52 +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 v6VAmNsJ008967; Mon, 31 Jul 2017 20:48:26 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 31 Jul 2017 20:48:23 +1000 (EST) From: Ian Smith To: Daniel Braniss cc: stable@freebsd.org Subject: Re: issues with powerd/freq_levels In-Reply-To: <8AEC9DBC-BADD-4FB2-8358-DA43F7EF5E68@cs.huji.ac.il> Message-ID: <20170731201323.A6737@sola.nimnet.asn.au> References: <8AEC9DBC-BADD-4FB2-8358-DA43F7EF5E68@cs.huji.ac.il> 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 Jul 2017 10:48:54 -0000 On Mon, 31 Jul 2017 10:09:11 +0300, Daniel Braniss wrote: > I am trying out PCengines latest apu2 boards, and I just noticed that with different Freebsd versions I get > different freq_levels, and so when idling, each box (have 5) has a different freq/temperature value, ranging > from 125/69.1C, 600/59.0C to 75/56.0C > > FreeBSD apu-4 11.1-STABLE FreeBSD 11.1-STABLE #5 f565b5a06ab3 (11) tip: Mon Jul 31 09:36:33 IDT 2017 > apu-4# sysctl dev.cpu.0.freq_levels > dev.cpu.0.freq_levels: 1000/980 800/807 600/609 That looks about right. On a Core2Duo (still on 9.3) I get: dev.est.1.freq_settings: 2401/35000 2400/35000 1600/15000 800/12000 dev.est.0.freq_settings: 2401/35000 2400/35000 1600/15000 800/12000 dev.cpu.0.freq_levels: 2401/35000 2400/35000 1600/15000 800/12000 dev.cpu.0.freq: 800 But only because I'd added to /boot/loader.conf: hint.p4tcc.0.disabled=1 hint.acpi_throttle.0.disabled=1 which became the defaults sometime, maybe not before 11.0? Otherwise mine would look more similar to the one below, with all 12.5% increments in frequency enabled, which doesn't actually save any power at all. > FreeBSD apu-5 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #0 21e9d1ca9b80 (11) tip: Tue May 30 11:51:48 IDT 2017 > apu-5# sysctl dev.cpu.0.freq_levels > dev.cpu.0.freq_levels: 1000/966 875/845 800/795 700/695 600/600 525/525 450/450 375/375 300/300 225/225 150/150 75/75 Looks like either p4tcc or acpi_throttle is enabled? See cpufreq(4). As above, these don't buy you anything but extra busyness for powerd. Also noticed that the (nice, low!) milliwatt figures for 1000/800/600 freqs are a bit different to the -stable one. Slightly Different model? > FreeBSD apu-1 10.3-STABLE FreeBSD 10.3-STABLE #4 267788fd852c (10) tip: Tue Jan 10 09:09:00 IST 2017 > apu-1# sysctl dev.cpu.0.freq_levels > dev.cpu.0.freq_levels: 1000/-1 875/-1 750/-1 625/-1 500/-1 375/-1 250/-1 125/-1 And that looks like est(4) isn't enabled/attaching at all .. see dmesg on all of these for clues. > so, any ideas as to what is going on? Pure guesswork on experience with older versions, I'm not up to date. cheers, Ian From owner-freebsd-stable@freebsd.org Mon Jul 31 13:31:20 2017 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 355A7DADEAE for ; Mon, 31 Jul 2017 13:31:20 +0000 (UTC) (envelope-from lydia.bavis@salientec.com) Received: from mail-yw0-x247.google.com (mail-yw0-x247.google.com [IPv6:2607:f8b0:4002:c05::247]) (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 E986176FC2 for ; Mon, 31 Jul 2017 13:31:19 +0000 (UTC) (envelope-from lydia.bavis@salientec.com) Received: by mail-yw0-x247.google.com with SMTP id v17so402893077ywh.15 for ; Mon, 31 Jul 2017 06:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salientec-com.20150623.gappssmtp.com; s=20150623; h=mime-version:message-id:date:subject:from:to; bh=3BMA0pYHWAv+F1BMSq371byeJFPw0vsnEGqrsileJUE=; b=eaQTCBdb9p/+QdgwwrBEp8F5KMxhyM+Llkf+nGeUvAkIjOK6pqO2LD4Y1YeTueX6Cu gwJO5DzVPz67yUTvgNShiY0WDpaN3btW2AqKUp6nQZEDb2hmz221HprIDoEPrSDS8UYF D1gE6+g4/6LpTPAbTRP4+P6Oym5ozLXtFlmzn19dlxLP9SietgeZGAbe9ik/JBLPEVIL bLij1dpOSdDLVsXDE2bTNfKh5iWUruhqhll3hBlGexR0lIoHuyWZCs5ttbAOVc1R2vOg 0wgmBrd9s3isbo1Bg6M/2VX1EfBIUR6MJZWEYtlaoIy1PmcZk4kxa+PnhYpxuftlM0VY j6Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:message-id:date:subject:from:to; bh=3BMA0pYHWAv+F1BMSq371byeJFPw0vsnEGqrsileJUE=; b=Uz82MOledKC0lXoJJQbkYo7m68Jt8K8ZVRU3q9XYxoruBwRRjrEffMNkMOvKnMae9O 66bZ72DCYF31z88wVE+rl+WG7cA0AdrAXLDkb2zslfdO8hvqd18dkw0cUoRMM5f4mGwp x8krGog1CxwzQAkV5AdWH8UjE0FsGL5G87wu0jn8kavouM5TaPMdSzT6fk4Nf6YvpBF7 C8z3k3dcCEKQyeigTzOQ+KEPYge+Sa9f6E3B2ezKlX/HMJ1yK3Yoh33U1Tgeycq0Pky3 xhkW31/xX4U3dlK9sBYYOxM4nVI2Qr4UFqxFLXxeaQPIACaKHDxif2QyQgEWpJLYKff5 3vXA== X-Gm-Message-State: AIVw112yufPCO/uJYjjT2o5m3o7CdCgCQ8aRCyIEoN3iGs58ZOEMAXTX r++0Fm9arOjTYXZiX1gUPOo1MAV0dExp MIME-Version: 1.0 X-Received: by 10.129.50.17 with SMTP id y17mr11686148ywy.216.1501507879028; Mon, 31 Jul 2017 06:31:19 -0700 (PDT) Message-ID: <001a11421b4ac1d78c05559d0b91@google.com> Date: Mon, 31 Jul 2017 13:31:19 +0000 Subject: Managed Service Providers (MSPs) and Cloud Service Providers (CSPs) Contact List From: lydia.bavis@salientec.com To: freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8"; format=flowed; delsp=yes Content-Transfer-Encoding: base64 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 Jul 2017 13:31:20 -0000 PGRpdiBkaXI9Imx0ciI+PHAgY2xhc3M9ImdtYWlsLU1zb05vU3BhY2luZyI+SGksPC9wPg0KDQo8 cCBjbGFzcz0iZ21haWwtTXNvTm9TcGFjaW5nIj5Xb3VsZCB5b3UgYmUgaW50ZXJlc3RlZCBpbiBh IGxpc3Qgb2YgTWFuYWdlZCAgDQpTZXJ2aWNlDQpQcm92aWRlcnMgKE1TUHMpIGFuZCBDbG91ZCBT ZXJ2aWNlIFByb3ZpZGVycyAoQ1NQcyk/PC9wPg0KDQo8cCBjbGFzcz0iZ21haWwtTXNvTm9TcGFj aW5nIj5Zb3UgbWF5IGFsc28gYmUgaW50ZXJlc3RlZCBpbiBkYXRhYmFzZSBvZjo8L3A+DQoNCjxw IGNsYXNzPSJnbWFpbC1Nc29Ob1NwYWNpbmciIHN0eWxlPSJtYXJnaW4tbGVmdDowLjVpbiI+MS48 c3BhbiAgDQpzdHlsZT0iZm9udC12YXJpYW50LW51bWVyaWM6bm9ybWFsO2ZvbnQtc3RyZXRjaDpu b3JtYWw7Zm9udC1zaXplOjdwdDtsaW5lLWhlaWdodDpub3JtYWw7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgIA0KTmV3IFJvbWFuJnF1b3Q7Ij7CoMKgwqDCoMKgDQo8L3NwYW4+TWFuYWdlZCBTZWN1 cml0eSBTZXJ2aWNlIHByb3ZpZGVycy0gTVNTUHM8c3Bhbj48L3NwYW4+PC9wPg0KDQo8cCBjbGFz cz0iZ21haWwtTXNvTm9TcGFjaW5nIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MC41aW4iPjIuPHNwYW4g IA0Kc3R5bGU9ImZvbnQtdmFyaWFudC1udW1lcmljOm5vcm1hbDtmb250LXN0cmV0Y2g6bm9ybWFs O2ZvbnQtc2l6ZTo3cHQ7bGluZS1oZWlnaHQ6bm9ybWFsO2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVz ICANCk5ldyBSb21hbiZxdW90OyI+wqDCoMKgwqDCoA0KPC9zcGFuPlZhbHVlIEFkZGVkIFJlc2Vs bGVycy0gVkFSczxzcGFuPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPSJnbWFpbC1Nc29Ob1NwYWNp bmciIHN0eWxlPSJtYXJnaW4tbGVmdDowLjVpbiI+My48c3BhbiAgDQpzdHlsZT0iZm9udC12YXJp YW50LW51bWVyaWM6bm9ybWFsO2ZvbnQtc3RyZXRjaDpub3JtYWw7Zm9udC1zaXplOjdwdDtsaW5l LWhlaWdodDpub3JtYWw7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgIA0KTmV3IFJvbWFuJnF1b3Q7 Ij7CoMKgwqDCoMKgDQo8L3NwYW4+SW5kZXBlbmRlbnQgU29mdHdhcmUgVmVuZG9ycy0gSVNWczxz cGFuPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPSJnbWFpbC1Nc29Ob1NwYWNpbmciIHN0eWxlPSJt YXJnaW4tbGVmdDowLjVpbiI+NC48c3BhbiAgDQpzdHlsZT0iZm9udC12YXJpYW50LW51bWVyaWM6 bm9ybWFsO2ZvbnQtc3RyZXRjaDpub3JtYWw7Zm9udC1zaXplOjdwdDtsaW5lLWhlaWdodDpub3Jt YWw7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgIA0KTmV3IFJvbWFuJnF1b3Q7Ij7CoMKgwqDCoMKg DQo8L3NwYW4+U3lzdGVtIEludGVncmF0b3JzLSBTSXM8c3Bhbj48L3NwYW4+PC9wPg0KDQo8cCBj bGFzcz0iZ21haWwtTXNvTm9TcGFjaW5nIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MC41aW4iPjUuPHNw YW4gIA0Kc3R5bGU9ImZvbnQtdmFyaWFudC1udW1lcmljOm5vcm1hbDtmb250LXN0cmV0Y2g6bm9y bWFsO2ZvbnQtc2l6ZTo3cHQ7bGluZS1oZWlnaHQ6bm9ybWFsO2ZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzICANCk5ldyBSb21hbiZxdW90OyI+wqDCoMKgwqDCoA0KPC9zcGFuPlZvSVAgU2VydmljZSBQ cm92aWRlcnMuPC9wPg0KDQo8cCBjbGFzcz0iZ21haWwtTXNvTm9TcGFjaW5nIj5QbGVhc2UgbGV0 IG1lIGtub3cgaWYgdGhpcyBpcyBzb21ldGhpbmcgb2YgIA0KaW50ZXJlc3QgdG8NCnlvdSBzbyB0 aGF0IEkgY2FuIHByb3ZpZGUgeW91IHdpdGggZnVydGhlciBpbmZvcm1hdGlvbi48L3A+DQoNCjxw IGNsYXNzPSJnbWFpbC1Nc29Ob1NwYWNpbmciPkJlc3QgUmVnYXJkcyw8c3Bhbj48L3NwYW4+PC9w Pg0KDQo8cCBjbGFzcz0iZ21haWwtTXNvTm9TcGFjaW5nIj5MeWRpYSBCYXZpczxzcGFuPjwvc3Bh bj48L3A+DQoNCjxwIGNsYXNzPSJnbWFpbC1Nc29Ob1NwYWNpbmciPkRhdGEgR2VuZXJhdGlvbjwv cD4NCg0KPHAgY2xhc3M9ImdtYWlsLU1zb05vU3BhY2luZyI+SWYgc2VlIG5vIGludGVyZXN0IHBs ZWFzZSByZXBseSDigJxObyBOZWVk4oCdIGluICANCnN1YmplY3QNCmxpbmUuPHNwYW4+PC9zcGFu PjwvcD48L2Rpdj4NCjxwPiZuYnNwOzwvcD48YSBzdHlsZT0nZGlzcGxheTogYmxvY2s7IG1hcmdp bjogMzJweCAwIDQwcHggMDsgcGFkZGluZzogIA0KMTBweDsgZm9udC1zaXplOiAxZW07IHRleHQt YWxpZ246IGNlbnRlcjsgYm9yZGVyOiAwOyBib3JkZXItdG9wOiAxcHggc29saWQgIA0KZ3JheTsg JyBocmVmPSdodHRwczovL2dvby5nbC8ya3NkUnYnPnBvd2VyZWQgYnkgR1NNLiBGcmVlIG1haWwg bWVyZ2UgYW5kICANCmVtYWlsIG1hcmtldGluZyBzb2Z0d2FyZSBmb3IgR21haWwuPC9hPg0K From owner-freebsd-stable@freebsd.org Mon Jul 31 19:03:29 2017 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 28C0BDB6E97 for ; Mon, 31 Jul 2017 19:03:29 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 046FA63DC0 for ; Mon, 31 Jul 2017 19:03:29 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 0023ADB6E96; Mon, 31 Jul 2017 19:03:29 +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 F1EAADB6E95 for ; Mon, 31 Jul 2017 19:03:28 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::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 B66F563DBF for ; Mon, 31 Jul 2017 19:03:28 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-pg0-x22b.google.com with SMTP id v189so12444709pgd.2 for ; Mon, 31 Jul 2017 12:03:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ugdzHwe9RfMBB5cDy2J8dvnh6pQ7+pq97bqyNS/acxA=; b=NWlK0KenqnLAlqRcI0VJ0t9fnarPcxddlYfFyMuMnJs3XHF85Qd1y5AGf2dcALeF+m GuCSG/IWftqDRO8PX/SUPY4gnKOXpvW4dQJJOBerDWm3mM2dCV9IVBVK4DynN6532DLy f6xmI8QjKLjx1TyA+OsZjE5wybkGCfxNQ1/B3WImvTHYltrcF3BOZZ+h5os9W07R8uUC /pWhF6nClF8FUkk0iPyiNGs2VuX4TJab92JQYaeCJv2YlGfI6DHAkfo6OoGLTiyvbiHP 8zMnXYnIQ+FpT2Iqbs4yH+oh4fFLGxPmogj5+JOWAJ+meDlEWNO/2zaNPGR9mvdTC1kx DPBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ugdzHwe9RfMBB5cDy2J8dvnh6pQ7+pq97bqyNS/acxA=; b=nsxUZiPu0XmkU+yfMXt5SjDYRxiLulv7cae5E4uJpK9ln+BUxONUrLw8c/mshePgqt tpSwtSOKf2MknjRtU0sCSqZKwv9tvNTHA4MGgYYIYzGPPIJirRX5zeLBcwKbHaYx/F4C uRczubokOHIYT3MS7qkZa9DyVajJb+IO9jVZtU6rm4Sambl6ThJlTX5SoCSbHlCecjGc 6HkXQwo0mFwtCcJENhuy2KVpAjnqeobIYWHEHl9SWBPGDCGzY1WgP43V7GoEKcGzDDPN WeS1QnN1XYlypNnPGCmngvK8xiNSGpeqAGP4ELNLlKI0sj3durej7r/G7OfnLJvWfuyU 5R9Q== X-Gm-Message-State: AIVw111Vxnh/MBth1smDctwKJNE4wQom6lmMhU9/ojkfmcG6GDMpAyTl 2gKkSn/4yDIhVHmUggsQwTg/vWB97Q== X-Received: by 10.98.8.93 with SMTP id c90mr2529696pfd.237.1501527808070; Mon, 31 Jul 2017 12:03:28 -0700 (PDT) MIME-Version: 1.0 Sender: kob6558@gmail.com Received: by 10.100.165.42 with HTTP; Mon, 31 Jul 2017 12:03:27 -0700 (PDT) In-Reply-To: <20170731201323.A6737@sola.nimnet.asn.au> References: <8AEC9DBC-BADD-4FB2-8358-DA43F7EF5E68@cs.huji.ac.il> <20170731201323.A6737@sola.nimnet.asn.au> From: Kevin Oberman Date: Mon, 31 Jul 2017 12:03:27 -0700 X-Google-Sender-Auth: neXMCYCBmtkBiRgjDyyQ2lT9XiE Message-ID: Subject: Re: issues with powerd/freq_levels To: Ian Smith Cc: Daniel Braniss , "stable@freebsd.org" 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 Jul 2017 19:03:29 -0000 On Mon, Jul 31, 2017 at 3:48 AM, Ian Smith wrote: > On Mon, 31 Jul 2017 10:09:11 +0300, Daniel Braniss wrote: > > > I am trying out PCengines latest apu2 boards, and I just noticed that > with different Freebsd versions I get > > different freq_levels, and so when idling, each box (have 5) has a > different freq/temperature value, ranging > > from 125/69.1C, 600/59.0C to 75/56.0C > > > > FreeBSD apu-4 11.1-STABLE FreeBSD 11.1-STABLE #5 f565b5a06ab3 (11) tip: > Mon Jul 31 09:36:33 IDT 2017 > > apu-4# sysctl dev.cpu.0.freq_levels > > dev.cpu.0.freq_levels: 1000/980 800/807 600/609 > > That looks about right. On a Core2Duo (still on 9.3) I get: > dev.est.1.freq_settings: 2401/35000 2400/35000 1600/15000 800/12000 > dev.est.0.freq_settings: 2401/35000 2400/35000 1600/15000 800/12000 > dev.cpu.0.freq_levels: 2401/35000 2400/35000 1600/15000 800/12000 > dev.cpu.0.freq: 800 > > But only because I'd added to /boot/loader.conf: > > hint.p4tcc.0.disabled=1 > hint.acpi_throttle.0.disabled=1 > > which became the defaults sometime, maybe not before 11.0? Otherwise > mine would look more similar to the one below, with all 12.5% increments > in frequency enabled, which doesn't actually save any power at all. > > > FreeBSD apu-5 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #0 21e9d1ca9b80 > (11) tip: Tue May 30 11:51:48 IDT 2017 > > apu-5# sysctl dev.cpu.0.freq_levels > > dev.cpu.0.freq_levels: 1000/966 875/845 800/795 700/695 600/600 525/525 > 450/450 375/375 300/300 225/225 150/150 75/75 > > Looks like either p4tcc or acpi_throttle is enabled? See cpufreq(4). > As above, these don't buy you anything but extra busyness for powerd. > > Also noticed that the (nice, low!) milliwatt figures for 1000/800/600 > freqs are a bit different to the -stable one. Slightly Different model? > > > FreeBSD apu-1 10.3-STABLE FreeBSD 10.3-STABLE #4 267788fd852c (10) tip: > Tue Jan 10 09:09:00 IST 2017 > > apu-1# sysctl dev.cpu.0.freq_levels > > dev.cpu.0.freq_levels: 1000/-1 875/-1 750/-1 625/-1 500/-1 375/-1 > 250/-1 125/-1 > > And that looks like est(4) isn't enabled/attaching at all .. see dmesg > on all of these for clues. > > > so, any ideas as to what is going on? > > Pure guesswork on experience with older versions, I'm not up to date. > Very odd. Are all systems running identical CPUs and BIOSes? Identical loader and sysctl configurations? Look at /var/rn/dmesg.boot for CPU information. Is EST being detected? It used to be early in the boot process, but is now fairly late. (In my case, about 2/3 through the dmesg.boot file. I have p4tcc and throttling explicitly turned off (which should now be the default), but my Sandy Bridge Core i5 still shows: dev.cpu.0.freq_levels: 2501/35000 2500/35000 2000/26426 1800/23233 1600/20164 1400/17226 1200/14408 1000/11713 800/9140 The first is really bogus to indicate "turbo" mode. Temperature is a totally separate issue. It is VERY sensitive to external issue like airflow and position of the CPU in relation to other components in the chassis Also, unless you have a lot of cores, you probably should set both economy_cx_lowest and performance_cx_lowest to Cmax. Economy should default to that, but performance will not as that can cause issues on systems with large numbers of cores, so is set to C2. Many such system used to disable deeper sleep modes in BIOS, but I am way behind the times and don't know about the current state of affairs. Certainly for systems with 32 or fewer cores, this should not be an issue. In any case, Cx state can sharply impact temperature. Finally, the last case with power levels of -1 for all frequencies is probably because the CPU manufacturer (Intel?) has not published this information. For a while they were treating this as "proprietary" information. Very annoying! It's always something that is not readily available. Thi is one reason I suspect your CPUs are not identical. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 From owner-freebsd-stable@freebsd.org Mon Jul 31 19:15:27 2017 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 20E1ADB7245 for ; Mon, 31 Jul 2017 19:15:27 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [67.205.158.196]) by mx1.freebsd.org (Postfix) with ESMTP id D6FE6644E6 for ; Mon, 31 Jul 2017 19:15:26 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197]) by colo1.denninger.net (Postfix) with ESMTP id 0234C2738B for ; Mon, 31 Jul 2017 15:15:21 -0400 (EDT) Received: from [192.168.10.20] (D10.Denninger.Net [192.168.10.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id F11F210E713 for ; Mon, 31 Jul 2017 14:15:19 -0500 (CDT) Subject: Re: issues with powerd/freq_levels To: freebsd-stable@freebsd.org References: <8AEC9DBC-BADD-4FB2-8358-DA43F7EF5E68@cs.huji.ac.il> <20170731201323.A6737@sola.nimnet.asn.au> From: Karl Denninger Message-ID: <7c484581-32d9-ff59-2fc9-f1dd555c0eb7@denninger.net> Date: Mon, 31 Jul 2017 14:15:13 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms080508050205000201040403" 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 Jul 2017 19:15:27 -0000 This is a cryptographically signed message in MIME format. --------------ms080508050205000201040403 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 7/31/2017 14:03, Kevin Oberman wrote: > On Mon, Jul 31, 2017 at 3:48 AM, Ian Smith wrote= : > >> On Mon, 31 Jul 2017 10:09:11 +0300, Daniel Braniss wrote: >> >> > I am trying out PCengines latest apu2 boards, and I just noticed th= at >> with different Freebsd versions I get >> > different freq_levels, and so when idling, each box (have 5) has a >> different freq/temperature value, ranging >> > from 125/69.1C, 600/59.0C to 75/56.0C >> > >> > FreeBSD apu-4 11.1-STABLE FreeBSD 11.1-STABLE #5 f565b5a06ab3 (11) = tip: >> Mon Jul 31 09:36:33 IDT 2017 >> > apu-4# sysctl dev.cpu.0.freq_levels >> > dev.cpu.0.freq_levels: 1000/980 800/807 600/609 >> >> That looks about right. On a Core2Duo (still on 9.3) I get: >> dev.est.1.freq_settings: 2401/35000 2400/35000 1600/15000 800/12000 >> dev.est.0.freq_settings: 2401/35000 2400/35000 1600/15000 800/12000 >> dev.cpu.0.freq_levels: 2401/35000 2400/35000 1600/15000 800/12000 >> dev.cpu.0.freq: 800 >> >> But only because I'd added to /boot/loader.conf: >> >> hint.p4tcc.0.disabled=3D1 >> hint.acpi_throttle.0.disabled=3D1 >> >> which became the defaults sometime, maybe not before 11.0? Otherwise >> mine would look more similar to the one below, with all 12.5% incremen= ts >> in frequency enabled, which doesn't actually save any power at all. >> >> > FreeBSD apu-5 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #0 21e9d1ca9b= 80 >> (11) tip: Tue May 30 11:51:48 IDT 2017 >> > apu-5# sysctl dev.cpu.0.freq_levels >> > dev.cpu.0.freq_levels: 1000/966 875/845 800/795 700/695 600/600 525= /525 >> 450/450 375/375 300/300 225/225 150/150 75/75 >> >> Looks like either p4tcc or acpi_throttle is enabled? See cpufreq(4). >> As above, these don't buy you anything but extra busyness for powerd. >> >> Also noticed that the (nice, low!) milliwatt figures for 1000/800/600 >> freqs are a bit different to the -stable one. Slightly Different mode= l? >> >> > FreeBSD apu-1 10.3-STABLE FreeBSD 10.3-STABLE #4 267788fd852c (10) = tip: >> Tue Jan 10 09:09:00 IST 2017 >> > apu-1# sysctl dev.cpu.0.freq_levels >> > dev.cpu.0.freq_levels: 1000/-1 875/-1 750/-1 625/-1 500/-1 375/-1 >> 250/-1 125/-1 >> >> And that looks like est(4) isn't enabled/attaching at all .. see dmesg= >> on all of these for clues. >> >> > so, any ideas as to what is going on? >> >> Pure guesswork on experience with older versions, I'm not up to date. >> > Very odd. Are all systems running identical CPUs and BIOSes? Identical > loader and sysctl configurations? Look at /var/rn/dmesg.boot for CPU > information. Is EST being detected? It used to be early in the boot > process, but is now fairly late. (In my case, about 2/3 through the > dmesg.boot file. > > I have p4tcc and throttling explicitly turned off (which should now be = the > default), but my Sandy Bridge Core i5 still shows: > dev.cpu.0.freq_levels: 2501/35000 2500/35000 2000/26426 1800/23233 > 1600/20164 1400/17226 1200/14408 1000/11713 800/9140 > The first is really bogus to indicate "turbo" mode. > > Temperature is a totally separate issue. It is VERY sensitive to extern= al > issue like airflow and position of the CPU in relation to other compone= nts > in the chassis Also, unless you have a lot of cores, you probably shoul= d > set both economy_cx_lowest and performance_cx_lowest to Cmax. Economy > should default to that, but performance will not as that can cause iss= ues > on systems with large numbers of cores, so is set to C2. Many such syst= em > used to disable deeper sleep modes in BIOS, but I am way behind the tim= es > and don't know about the current state of affairs. Certainly for system= s > with 32 or fewer cores, this should not be an issue. In any case, Cx st= ate > can sharply impact temperature. > > Finally, the last case with power levels of -1 for all frequencies is > probably because the CPU manufacturer (Intel?) has not published this > information. For a while they were treating this as "proprietary" > information. Very annoying! It's always something that is not readily > available. Thi is one reason I suspect your CPUs are not identical. > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkoberman@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.or= g" I have a very new PCEngines unit here running 11.0-STABLE and this is what I have in the related sysctls: $ sysctl -a|grep cpu.0 dev.cpu.0.cx_method: C1/hlt C2/io dev.cpu.0.cx_usage_counters: 2261969965 3038 dev.cpu.0.cx_usage: 99.99% 0.00% last 798us dev.cpu.0.cx_lowest: C2 dev.cpu.0.cx_supported: C1/1/0 C2/2/400 dev.cpu.0.freq_levels: 1000/924 800/760 600/571 dev.cpu.0.freq: 1000 dev.cpu.0.temperature: 59.2C dev.cpu.0.%parent: acpi0 dev.cpu.0.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.0.%location: handle=3D\_PR_.P000 dev.cpu.0.%driver: cpu dev.cpu.0.%desc: ACPI CPU =2E... $ sysctl -a|grep cx hw.acpi.cpu.cx_lowest: C2 dev.cpu.3.cx_method: C1/hlt dev.cpu.3.cx_usage_counters: 111298364 dev.cpu.3.cx_usage: 100.00% last 30us dev.cpu.3.cx_lowest: C2 dev.cpu.3.cx_supported: C1/1/0 dev.cpu.2.cx_method: C1/hlt dev.cpu.2.cx_usage_counters: 127978480 dev.cpu.2.cx_usage: 100.00% last 35us dev.cpu.2.cx_lowest: C2 dev.cpu.2.cx_supported: C1/1/0 dev.cpu.1.cx_method: C1/hlt dev.cpu.1.cx_usage_counters: 108161434 dev.cpu.1.cx_usage: 100.00% last 29us dev.cpu.1.cx_lowest: C2 dev.cpu.1.cx_supported: C1/1/0 dev.cpu.0.cx_method: C1/hlt C2/io dev.cpu.0.cx_usage_counters: 2261916773 3038 dev.cpu.0.cx_usage: 99.99% 0.00% last 378us dev.cpu.0.cx_lowest: C2 dev.cpu.0.cx_supported: C1/1/0 C2/2/400 These are fanless, 4-core devices that are pretty cool -- they've got AES instructions in them and thus make very nice VPN gateways running something like Strongswan, and come with either 2 or 3 gigabit interfaces on the board. Oh, and they run on 12V. Powerd is logging this, however... hwpstate0: set freq failed, err 6 hwpstate0: set freq failed, err 6 Hmmmm.... --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms080508050205000201040403 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA3MzExOTE1MTNaME8GCSqGSIb3DQEJBDFCBEAPhBY1 I04IXUOknWfcGYJ1tyI2DgsHGFl4UwfmCFVZWDXImqLj2cm/D6rEDu9gqr/NuBV4NV5iyw0i xmu2Nr4eMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAHvttN8r6c+Y6 a2d0F9w6eEIm6/AFgOyHw1xEXK4LCeVO9BiQqHuXmE5OlA86KzhzsFNbi+OpePlQn+myBUli A0zhn4bWEA9VyE9GNn1O92zhrcFqFkmYR8/zNnEoH+jnDKMCtgsf0CqBuA+QqA36IHwTJIGI VcX+IK+lbwSGIpQhVPzVgLj2PuFcy3M3rMOzBh5mCyGaYtfiuitrJDE0T3xNj0we5V5KDARq nYi5BtErzqxGxpXp/HeMABjHCUybQrl8/kX0W5oOdeftPlSzfIAVuiuM/RFi9S2O/wV0yPib hvmMPeF3WsJW5FLwHDqDn0dL94iR8Z9rduVuXofJDGJ3WVUEj0LFr1ixpkDgcYqxOxMhPcdC auDc9LP9FZgsFAx/tPECOo83kwWQY+qbu9psdXWhz7Vpzu0LHpUaAlhBnf4fkLzwNmsi43p7 wrbmIRNxzefA3hwNYet9KYII8Vpp+E9/Lte2jQ7SGhQrI+q3xaPTFr9CiRNsL1y65QJ/oFtN vk6jEX+BbECr8w8QSR2QxJtWqQ1kVuoPknnIUvyCPeAjowelkT1IsWAtlneiezXfv/L7cWVH ahi+tqCk5/0A40jpS8JorvmtiQ7S90Y4As465bexZCA269vbXEz8Fi3mDvUwCHam68irFOW2 0QM2nuAp4scig55YP0pTHNsAAAAAAAA= --------------ms080508050205000201040403-- From owner-freebsd-stable@freebsd.org Mon Jul 31 19:43:11 2017 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 4E60FDB7F47 for ; Mon, 31 Jul 2017 19:43:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3C27F65912 for ; Mon, 31 Jul 2017 19:43:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v6VJhAHo096216 for ; Mon, 31 Jul 2017 19:43:11 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 221050] emulators/virtualbox-ose: Bridged network doesn't work (11.1-RELEASE) Date: Mon, 31 Jul 2017 19:43:11 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: cgull+l-freebsd-bugzilla@glup.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not A Bug X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: vbox@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-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 Jul 2017 19:43:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221050 John Hood changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cgull+l-freebsd-bugzilla@gl | |up.org --- Comment #13 from John Hood --- (In reply to lavr from comment #11) This works for me too-- only virtualbox-ose-kmod must be rebuilt on 11.1, a= ll of its build dependencies can come from packages. This does suggest that there is still some KBI incompatibility between 11.0= and 11.1 though. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Mon Jul 31 23:38:54 2017 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 AF3ACDC0312 for ; Mon, 31 Jul 2017 23:38:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9CD276DAEF for ; Mon, 31 Jul 2017 23:38:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v6VNcodO061526 for ; Mon, 31 Jul 2017 23:38:54 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 221050] emulators/virtualbox-ose: Bridged network doesn't work (11.1-RELEASE) Date: Mon, 31 Jul 2017 23:38:51 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rkoberman@gmail.com X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not A Bug X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: vbox@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-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 Jul 2017 23:38:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221050 rkoberman@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rkoberman@gmail.com --- Comment #14 from rkoberman@gmail.com --- (In reply to John Hood from comment #13) Just to clarify for people, while developers try to not adjust the KBI with= in a major release, it has never been a commitment. The bottom line is that all kernel modules from ports should be re-built ev= ery time the kernel is updated. For those running releases, this is for every release as well as security patches which involve a kernel replacement whet= her by a re-build or freebsd-update. For those of us running stable, it is every time the kernel is updated. While lsof does not involve a kernel module, it does poke around in the ker= nel and will break far more easily with kernel changes than modules as it does = its poking outside the documented KBI. If you build kernels from source, you can list ports needing updating in /etc/src.conf like this: PORTS_MODULES=3Demulators/virtualbox-ose-kmod sysutils/lsof If you install packages you need to wait until a package build has been completed after a release. This is usually two or three days, but I have se= en it take as long as a week. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Tue Aug 1 02:52:46 2017 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 7DC58DC7511 for ; Tue, 1 Aug 2017 02:52:46 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from hobbes.arroway.org (hobbes.arroway.org [173.199.118.77]) by mx1.freebsd.org (Postfix) with ESMTP id 5E1AF747A1 for ; Tue, 1 Aug 2017 02:52:43 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from [10.1.1.10] (unknown [177.89.5.111]) by hobbes.arroway.org (Postfix) with ESMTPA id 3E9181FD737 for ; Mon, 31 Jul 2017 23:52:34 -0300 (BRT) Received: from 10.1.1.86 (SquirrelMail authenticated user matheus) by 10.1.1.10 with HTTP; Mon, 31 Jul 2017 23:52:35 -0300 Message-ID: <419c54e8944df9d6c8a8a15413dfc7ba.squirrel@10.1.1.10> In-Reply-To: <39221eefb6288d3b9154e85f4faa6501.squirrel@10.1.1.10> References: <39221eefb6288d3b9154e85f4faa6501.squirrel@10.1.1.10> Date: Mon, 31 Jul 2017 23:52:35 -0300 Subject: Re: FreeBSD 11.1-R network slowness on Samba and Windows VM on VirtualBox From: "Nenhum_de_Nos" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal 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 Aug 2017 02:52:46 -0000 On Sun, July 30, 2017 02:08, Nenhum_de_Nos wrote: > Hi, > > I was running 10.3-p7 on Atom hardware and using old samba36-3.6.25_1. All > was fine. > > Then I updated to 11.1-R by recompiling from svn, using the same > kernelconfig from 10.3, and now my windows client shows timeouts and > really slow connection. File copy never past kilobytes per second :( > > I am compiling a new samba packet from ports, but that slow is weird for > me, and I could not find any other cases on web search. > > thanks, > > matheus Hi guys, I got this still going, where I installed a new Windows VM and same problem. I reinstalled all ports and same problem. I use Windows shares from another sources (not a VirtualBox VM) and all works fine. Some help were said here https://forums.freebsd.org/threads/61813/, but unfortunately I have no leads so far. I will try to install some 10.3 box to try it out when I get some time and a free machine. If anyone has any clues. thanks, -- "We will call you Cygnus, the God of balance you shall be." From owner-freebsd-stable@freebsd.org Tue Aug 1 06:07:25 2017 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 D5DA0DB2FB4 for ; Tue, 1 Aug 2017 06:07:25 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C273165F90 for ; Tue, 1 Aug 2017 06:07:25 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id BECCCDB2FB2; Tue, 1 Aug 2017 06:07:25 +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 BE331DB2FB1 for ; Tue, 1 Aug 2017 06:07:25 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 7AA4565F8F for ; Tue, 1 Aug 2017 06:07:25 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1dcQKq-0005B0-N6; Tue, 01 Aug 2017 09:07:16 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: issues with powerd/freq_levels From: Daniel Braniss In-Reply-To: <20170731201323.A6737@sola.nimnet.asn.au> Date: Tue, 1 Aug 2017 09:07:15 +0300 Cc: stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <8AEC9DBC-BADD-4FB2-8358-DA43F7EF5E68@cs.huji.ac.il> <20170731201323.A6737@sola.nimnet.asn.au> To: Ian Smith X-Mailer: Apple Mail (2.3273) 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 Aug 2017 06:07:25 -0000 all boards are identical, purchased at the same time. > On 31 Jul 2017, at 13:48, Ian Smith wrote: >=20 > On Mon, 31 Jul 2017 10:09:11 +0300, Daniel Braniss wrote: >=20 >> I am trying out PCengines latest apu2 boards, and I just noticed that = with different Freebsd versions I get >> different freq_levels, and so when idling, each box (have 5) has a = different freq/temperature value, ranging >> from 125/69.1C, 600/59.0C to 75/56.0C >>=20 >> FreeBSD apu-4 11.1-STABLE FreeBSD 11.1-STABLE #5 f565b5a06ab3 (11) = tip: Mon Jul 31 09:36:33 IDT 2017 >> apu-4# sysctl dev.cpu.0.freq_levels >> dev.cpu.0.freq_levels: 1000/980 800/807 600/609 >=20 > That looks about right. On a Core2Duo (still on 9.3) I get: > dev.est.1.freq_settings: 2401/35000 2400/35000 1600/15000 800/12000 > dev.est.0.freq_settings: 2401/35000 2400/35000 1600/15000 800/12000 > dev.cpu.0.freq_levels: 2401/35000 2400/35000 1600/15000 800/12000 > dev.cpu.0.freq: 800 >=20 > But only because I'd added to /boot/loader.conf: >=20 > hint.p4tcc.0.disabled=3D1 > hint.acpi_throttle.0.disabled=3D1 >=20 the above are in my device.hints, so I assume they now standard. > which became the defaults sometime, maybe not before 11.0? Otherwise=20= > mine would look more similar to the one below, with all 12.5% = increments=20 > in frequency enabled, which doesn't actually save any power at all. >=20 >> FreeBSD apu-5 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #0 21e9d1ca9b80 = (11) tip: Tue May 30 11:51:48 IDT 2017 >> apu-5# sysctl dev.cpu.0.freq_levels >> dev.cpu.0.freq_levels: 1000/966 875/845 800/795 700/695 600/600 = 525/525 450/450 375/375 300/300 225/225 150/150 75/75 >=20 > Looks like either p4tcc or acpi_throttle is enabled? See cpufreq(4). > As above, these don't buy you anything but extra busyness for powerd. >=20 > Also noticed that the (nice, low!) milliwatt figures for 1000/800/600=20= > freqs are a bit different to the -stable one. Slightly Different = model? >=20 >> FreeBSD apu-1 10.3-STABLE FreeBSD 10.3-STABLE #4 267788fd852c (10) = tip: Tue Jan 10 09:09:00 IST 2017 >> apu-1# sysctl dev.cpu.0.freq_levels >> dev.cpu.0.freq_levels: 1000/-1 875/-1 750/-1 625/-1 500/-1 375/-1 = 250/-1 125/-1 >=20 > And that looks like est(4) isn't enabled/attaching at all .. see dmesg=20= > on all of these for clues. >=20 >> so, any ideas as to what is going on? >=20 > Pure guesswork on experience with older versions, I'm not up to date. >=20 > cheers, Ian well, since I=E2=80=99m mostly interested in 11.1 at the moment, what = you are saying is that=E2=80=99s ok, fine by me,=20 thanks, danny From owner-freebsd-stable@freebsd.org Tue Aug 1 06:30:01 2017 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 D9E7FDB52B0 for ; Tue, 1 Aug 2017 06:30:01 +0000 (UTC) (envelope-from TERRY@glaver.org) Received: from server.glaver.org (server.glaver.org [204.141.35.63]) (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 B9E4E66731 for ; Tue, 1 Aug 2017 06:30:01 +0000 (UTC) (envelope-from TERRY@glaver.org) Received: from glaver.org by glaver.org (PMDF V6.7-x02 #37010) id <01QHDP0VCU1C006GXB@glaver.org> for freebsd-stable@freebsd.org; Tue, 01 Aug 2017 02:29:52 -0400 (EDT) Date: Tue, 01 Aug 2017 02:13:35 -0400 (EDT) From: Terry Kennedy Subject: Re: FreeBSD 11.1-R network slowness on Samba To: freebsd-stable@freebsd.org Message-id: <01QHDPLW30LG006GXB@glaver.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: Tue, 01 Aug 2017 06:30:02 -0000 > Then I updated to 11.1-R by recompiling from svn, using the same > kernelconfig from 10.3, and now my windows client shows timeouts and > really slow connection. File copy never past kilobytes per second :( I think the issue is with the SAMBA port. I was running the samba36 port under FreeBSD 10.x and things were fine (500Mbyte/sec transfers using 10GbE). At some point the samba36 port broke due to changes in one or more of talloc/tdb/tevent and I tried various samba4x ports (I am using samba44 now, samba46 doesn't seem to work with XP-type client systems). Various directory traversal operations spike the CPU load up to 100% and clients see very bursty behavior. A lot seems to depend on the application in use - my benchmark is clrmamepro: https://mamedev.emulab.it/clrmamepro/ But even things like Windows (7) Photo Viewer will just sit at the "Loading..." message for a random length of time before displaying the next picture. I am seeing easily a 10:1 performance degradation with any of the samba4x ports. I have tried large numbers of SAMBA config tuning changes, different port build options, etc. without any success. I "solved" the problem by using an old FreeBSD 8.4 box with a 10GbE card as an NFS client to the storage server, and then exporting the NFS-mounted storage to clients with samba36. This whole chain is nearly as fast as the old samba36-on-storage-server setup. I may try resurrecting the samba36 port under FreeBSD 11.1 to see if that has the performance I used to get. I'm not sure how hard it will be to build samba36, though. Things have changed since the port was retired. Terry Kennedy http://www.glaver.org New York, NY USA From owner-freebsd-stable@freebsd.org Tue Aug 1 16:20:12 2017 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 44DB0DB20C3 for ; Tue, 1 Aug 2017 16:20:12 +0000 (UTC) (envelope-from Werner.Griessl@uni-bayreuth.de) Received: from btr0xn.rz.uni-bayreuth.de (btr0xn.rz.uni-bayreuth.de [132.180.8.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mailhub-out.uni-bayreuth.de", Issuer "Universitaet Bayreuth CA (UNIBT-CA) G01" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D096181B49 for ; Tue, 1 Aug 2017 16:20:11 +0000 (UTC) (envelope-from Werner.Griessl@uni-bayreuth.de) Received: from btr0xn-rx.rz.uni-bayreuth.de (localhost [127.0.0.1]) by btr0xn.rz.uni-bayreuth.de (8.13.1/8.13.1) with ESMTP id v71EfedZ011054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 1 Aug 2017 16:41:40 +0200 (MEST) Received: from btruxs.rz.uni-bayreuth.de (btruxs [132.180.14.11]) by btr0xn-rx.rz.uni-bayreuth.de (8.13.1/8.13.1) with ESMTP id v71EfbpF011044 for ; Tue, 1 Aug 2017 16:41:38 +0200 (MEST) Reply-To: Werner.Griessl@uni-bayreuth.de Subject: Re: FreeBSD 11.1-R network slowness on Samba and Windows VM on VirtualBox To: freebsd-stable@freebsd.org References: <39221eefb6288d3b9154e85f4faa6501.squirrel@10.1.1.10> <419c54e8944df9d6c8a8a15413dfc7ba.squirrel@10.1.1.10> From: Werner Griessl Organization: UNI Bayreuth ITS Message-ID: Date: Tue, 1 Aug 2017 16:41:37 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <419c54e8944df9d6c8a8a15413dfc7ba.squirrel@10.1.1.10> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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 Aug 2017 16:20:12 -0000 On 08/01/17 04:52, Nenhum_de_Nos wrote: > > On Sun, July 30, 2017 02:08, Nenhum_de_Nos wrote: >> Hi, >> >> I was running 10.3-p7 on Atom hardware and using old samba36-3.6.25_1. All >> was fine. >> >> Then I updated to 11.1-R by recompiling from svn, using the same >> kernelconfig from 10.3, and now my windows client shows timeouts and >> really slow connection. File copy never past kilobytes per second :( >> >> I am compiling a new samba packet from ports, but that slow is weird for >> me, and I could not find any other cases on web search. >> >> thanks, >> >> matheus > > Hi guys, > > I got this still going, where I installed a new Windows VM and same > problem. I reinstalled all ports and same problem. I use Windows shares > from another sources (not a VirtualBox VM) and all works fine. > > Some help were said here https://forums.freebsd.org/threads/61813/, but > unfortunately I have no leads so far. > > I will try to install some 10.3 box to try it out when I get some time and > a free machine. > > If anyone has any clues. > > thanks, > Try comment out in smb4.conf the line: "# case sensitive = true" Worked for me with samba44 Werner -- Werner Grießl D-95440 Bayreuth, Germany Universitaet Bayreuth Tel.: +49 921 55 2685 IT-Servicezentrum/Netze NW2 3.2.U1.143 From owner-freebsd-stable@freebsd.org Tue Aug 1 17:28:18 2017 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 8B296DB4A95 for ; Tue, 1 Aug 2017 17:28:18 +0000 (UTC) (envelope-from juraj.vanco@intel.com) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ORSMGA102.jf.intel.com", Issuer "Intel External Issuing CA 6A" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 69D441FD3 for ; Tue, 1 Aug 2017 17:28:18 +0000 (UTC) (envelope-from juraj.vanco@intel.com) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Aug 2017 10:27:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,306,1498546800"; d="scan'208";a="885157814" Received: from irsmsx106.ger.corp.intel.com ([163.33.3.31]) by FMSMGA003.fm.intel.com with ESMTP; 01 Aug 2017 10:27:03 -0700 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.9]) by IRSMSX106.ger.corp.intel.com ([169.254.8.236]) with mapi id 14.03.0319.002; Tue, 1 Aug 2017 18:27:03 +0100 From: "Vanco, Juraj" To: "freebsd-stable@freebsd.org" Subject: FreeBSD 11.1 - unknown group wheel Thread-Topic: FreeBSD 11.1 - unknown group wheel Thread-Index: AdMK6pIg8rQCFmhiS1+RbaJbAR9WFg== Date: Tue, 1 Aug 2017 17:27:01 +0000 Message-ID: <996B37956731CF40B1A674B085ACCE9440BFA2B9@IRSMSX103.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 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 Aug 2017 17:28:18 -0000 SGVsbG8sDQoNCkkgYW0gdHJ5aW5nIHRvIGJ1aWxkIGEga2VybmVsIGluIEZyZWVCU0QgMTEuMCwg aG93ZXZlciBJIGFtIGdldHRpbmcgYSBtZXNzYWdlDQoNCm10cmVlIC1kZVUgLWYgL3Vzci9zcmMv ZXRjL210cmVlL0JTRC51c3IuZGlzdCAgLXAgL3Vzci9vYmovdXNyL3NyYy90bXAvdXNyID4vZGV2 L251bGwNCm10cmVlOiB1bmtub3duIGdyb3VwIGB3aGVlbCcNCm10cmVlOiBmYWlsZWQgYXQgbGlu ZSA2IG9mIHRoZSBzcGVjaWZpY2F0aW9uDQoqKiogRXJyb3IgY29kZSAxDQoNCg0KSG93ZXZlciB0 aGUgZ3JvdXAgaXMga25vd246DQojIGNhdCAvZXRjL2dyb3VwIHwgaGVhZCAtbiAzDQojICRGcmVl QlNEOiByZWxlbmcvMTEuMC9ldGMvZ3JvdXAgMjk0ODk2IDIwMTYtMDEtMjcgMDY6Mjg6NTZaIGFy YXVqbyAkDQojDQp3aGVlbDoqOjA6cm9vdA0KDQoNCmFuZCBjdXJyZW50bHkgdXNlZDoNCiMgZ3Jv dXBzDQowDQoNCg0KUnVubmluZyBhbnkgcXVlcnkgb24gZ3JvdXAgcmVzdWx0IHdpdGggemVybyBh bnN3ZXI6DQojIGdldGVudCBncm91cCB3aGVlbA0KIw0KIyBnZXRlbnQgZ3JvdXAgdmlkZW8NCiMN Cg0KDQpTaW1pbGFyIHJlc3VsdCBnaXZlcyBtZXJnZW1hc3RlcjoNCiMgbWVyZ2VtYXN0ZXIgLXAN Cg0KKioqIFRoZSBkaXJlY3Rvcnkgc3BlY2lmaWVkIGZvciB0aGUgdGVtcG9yYXJ5IHJvb3QgZW52 aXJvbm1lbnQsDQogICAgL3Zhci90bXAvdGVtcHJvb3QsIGV4aXN0cy4gIFRoaXMgY2FuIGJlIGEg c2VjdXJpdHkgcmlzayBpZiB1bnRydXN0ZWQNCiAgICB1c2VycyBoYXZlIGFjY2VzcyB0byB0aGUg c3lzdGVtLg0KDQogIFVzZSAnZCcgdG8gZGVsZXRlIHRoZSBvbGQgL3Zhci90bXAvdGVtcHJvb3Qg YW5kIGNvbnRpbnVlDQogIFVzZSAndCcgdG8gc2VsZWN0IGEgbmV3IHRlbXBvcmFyeSByb290IGRp cmVjdG9yeQ0KICBVc2UgJ2UnIHRvIGV4aXQgbWVyZ2VtYXN0ZXINCg0KICBEZWZhdWx0IGlzIHRv IHVzZSAvdmFyL3RtcC90ZW1wcm9vdCBhcyBpcw0KDQpIb3cgc2hvdWxkIEkgZGVhbCB3aXRoIHRo aXM/IFtVc2UgdGhlIGV4aXN0aW5nIC92YXIvdG1wL3RlbXByb290XSBkDQoNCiAgICoqKiBEZWxl dGluZyB0aGUgb2xkIC92YXIvdG1wL3RlbXByb290DQoNCioqKiBDcmVhdGluZyB0aGUgdGVtcG9y YXJ5IHJvb3QgZW52aXJvbm1lbnQgaW4gL3Zhci90bXAvdGVtcHJvb3QNCiAqKiogL3Zhci90bXAv dGVtcHJvb3QgcmVhZHkgZm9yIHVzZQ0KICoqKiBDcmVhdGluZyBhbmQgcG9wdWxhdGluZyBkaXJl Y3Rvcnkgc3RydWN0dXJlIGluIC92YXIvdG1wL3RlbXByb290DQoNCmluc3RhbGw6IHVua25vd24g Z3JvdXAgd2hlZWwNCg0KDQpJIGNhbm5vdCBmaW5kIGlmIHRoaXMgaXMgYW55IGtub3duIGlzc3Vl Li4uIEFueSBjbHVlPw0KDQpqdg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KSW50ZWwgUmVzZWFyY2ggYW5kIERldmVsb3BtZW50 IElyZWxhbmQgTGltaXRlZApSZWdpc3RlcmVkIGluIElyZWxhbmQKUmVnaXN0ZXJlZCBPZmZpY2U6 IENvbGxpbnN0b3duIEluZHVzdHJpYWwgUGFyaywgTGVpeGxpcCwgQ291bnR5IEtpbGRhcmUKUmVn aXN0ZXJlZCBOdW1iZXI6IDMwODI2MwoKClRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG1hdGVyaWFsIGZvciB0aGUgc29sZQp1c2Ugb2YgdGhl IGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldyBvciBkaXN0cmlidXRpb24gYnkgb3Ro ZXJzIGlzCnN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZQpzZW5kZXIgYW5kIGRlbGV0ZSBhbGwgY29waWVz Lgo= From owner-freebsd-stable@freebsd.org Tue Aug 1 17:37:14 2017 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 1F78DDB4DE0 for ; Tue, 1 Aug 2017 17:37:14 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A8591251E for ; Tue, 1 Aug 2017 17:37:13 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-wm0-x22a.google.com with SMTP id m85so21249405wma.1 for ; Tue, 01 Aug 2017 10:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=sF7oxOP5YeRDAZIP3cDwf5CRAACkNUA4xa0xWsei2Y4=; b=vIIcYP394PXTdmbr1iiXVx2zY0/aiaBtTQbFbA5GySVhddWVdSl9NkIeXngZMkrgzj wcOHpoKdo34C4GT0QZRqe6PxL4arvmcE8mvjZ+vqD1O6a6Ai09ymQJ6tYSQ1Kjw3kK0y hFLbd+Gqo5tyHVG9ciRwgjJ0GTSgPkOPCwKIw8T92wEGbWKXcxfvv2zS0yyPpe1C3mk3 d7jkV4Pe+CGqCShKBacvJoTc7gVVINgw5kmE4Wxi0tkQj5Om+Syzw9NRfHJNCMX3d0QJ lCZ0dNnL/IbEpNWCbdwlFOgFBErLXogfM+gm/e/S1F0Qq5ZTR+m02wgVHyqrqjb6T5jT 3jNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=sF7oxOP5YeRDAZIP3cDwf5CRAACkNUA4xa0xWsei2Y4=; b=SXsWoBrsc9vyup40O1F1c7k7b9aCXnAQbPdfpJMshINapqemMK+Tf0L7wAmzZyu+ZV UeMaV+XdUHHU2TsqXw+cdD22PEEts9PL8UGzgM8s6QIRUmUWhWJPXut+9zNgA3iULm9c V0VvvdRcaOAbeDO1Q6OzvuiA+9i6l6QoRhanlcM2dLvxyzlXoc8D8neyT/pPoyJIIJsW ZhtEES36+iSw2n+6OwnZzdqAxoTBT4fMUTX+WMM9BStbAOacSXoUATkXWn+A5jB7gfcd Uh0wnGx5fw50ZuUehwOU0Zlg9adMCypzMEykF4ZfJv/Ry9CLAPrPk0p24UKEEKM9sS6U coAw== X-Gm-Message-State: AIVw110NUqW4Te/Jz8zbVvJ9iMPeMhEO5qk3D7yOM98NTqxeEfmccXo4 l9kfdqZ70IfNARxkclM5cRotWWJtkg== X-Received: by 10.28.15.79 with SMTP id 76mr1984831wmp.42.1501609031252; Tue, 01 Aug 2017 10:37:11 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.28.208.3 with HTTP; Tue, 1 Aug 2017 10:37:10 -0700 (PDT) In-Reply-To: <996B37956731CF40B1A674B085ACCE9440BFA2B9@IRSMSX103.ger.corp.intel.com> References: <996B37956731CF40B1A674B085ACCE9440BFA2B9@IRSMSX103.ger.corp.intel.com> From: Alan Somers Date: Tue, 1 Aug 2017 11:37:10 -0600 X-Google-Sender-Auth: 41yDccxVSve6kAG3LW_JsEot4b0 Message-ID: Subject: Re: FreeBSD 11.1 - unknown group wheel To: "Vanco, Juraj" Cc: "freebsd-stable@freebsd.org" 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: Tue, 01 Aug 2017 17:37:14 -0000 Check your /etc/nsswitch.conf file. It's possible to screw that up so that /etc/groups doesn't even get checked. -Alan On Tue, Aug 1, 2017 at 11:27 AM, Vanco, Juraj wrote: > Hello, > > I am trying to build a kernel in FreeBSD 11.0, however I am getting a message > > mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist -p /usr/obj/usr/src/tmp/usr >/dev/null > mtree: unknown group `wheel' > mtree: failed at line 6 of the specification > *** Error code 1 > > > However the group is known: > # cat /etc/group | head -n 3 > # $FreeBSD: releng/11.0/etc/group 294896 2016-01-27 06:28:56Z araujo $ > # > wheel:*:0:root > > > and currently used: > # groups > 0 > > > Running any query on group result with zero answer: > # getent group wheel > # > # getent group video > # > > > Similar result gives mergemaster: > # mergemaster -p > > *** The directory specified for the temporary root environment, > /var/tmp/temproot, exists. This can be a security risk if untrusted > users have access to the system. > > Use 'd' to delete the old /var/tmp/temproot and continue > Use 't' to select a new temporary root directory > Use 'e' to exit mergemaster > > Default is to use /var/tmp/temproot as is > > How should I deal with this? [Use the existing /var/tmp/temproot] d > > *** Deleting the old /var/tmp/temproot > > *** Creating the temporary root environment in /var/tmp/temproot > *** /var/tmp/temproot ready for use > *** Creating and populating directory structure in /var/tmp/temproot > > install: unknown group wheel > > > I cannot find if this is any known issue... Any clue? > > jv > -------------------------------------------------------------- > Intel Research and Development Ireland Limited > Registered in Ireland > Registered Office: Collinstown Industrial Park, Leixlip, County Kildare > Registered Number: 308263 > > > This e-mail and any attachments may contain confidential material for the sole > use of the intended recipient(s). Any review or distribution by others is > strictly prohibited. If you are not the intended recipient, please contact the > sender and delete all copies. > _______________________________________________ > 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 Tue Aug 1 17:46:16 2017 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 6ECA5DB52CE for ; Tue, 1 Aug 2017 17:46:16 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 59B3E2FA7 for ; Tue, 1 Aug 2017 17:46:16 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: by mailman.ysv.freebsd.org (Postfix) id 562B3DB52CD; Tue, 1 Aug 2017 17:46:16 +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 55C61DB52CC for ; Tue, 1 Aug 2017 17:46:16 +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 6EAB82FA5 for ; Tue, 1 Aug 2017 17:46:14 +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 v71HjZFn077624; Wed, 2 Aug 2017 03:45:35 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 2 Aug 2017 03:45:35 +1000 (EST) From: Ian Smith To: Kevin Oberman cc: Daniel Braniss , Karl Denninger , stable@freebsd.org Subject: Re: issues with powerd/freq_levels In-Reply-To: Message-ID: <20170802004343.T6737@sola.nimnet.asn.au> References: <8AEC9DBC-BADD-4FB2-8358-DA43F7EF5E68@cs.huji.ac.il> <20170731201323.A6737@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: Tue, 01 Aug 2017 17:46:16 -0000 On Mon, 31 Jul 2017 12:03:27 -0700, Kevin Oberman wrote: > On Mon, Jul 31, 2017 at 3:48 AM, Ian Smith wrote: > > > On Mon, 31 Jul 2017 10:09:11 +0300, Daniel Braniss wrote: > > > > > I am trying out PCengines latest apu2 boards, and I just noticed that > > with different Freebsd versions I get > > > different freq_levels, and so when idling, each box (have 5) has a > > different freq/temperature value, ranging > > > from 125/69.1C, 600/59.0C to 75/56.0C > > > > > > FreeBSD apu-4 11.1-STABLE FreeBSD 11.1-STABLE #5 f565b5a06ab3 (11) tip: > > Mon Jul 31 09:36:33 IDT 2017 > > > apu-4# sysctl dev.cpu.0.freq_levels > > > dev.cpu.0.freq_levels: 1000/980 800/807 600/609 > > > > That looks about right. On a Core2Duo (still on 9.3) I get: > > dev.est.1.freq_settings: 2401/35000 2400/35000 1600/15000 800/12000 > > dev.est.0.freq_settings: 2401/35000 2400/35000 1600/15000 800/12000 > > dev.cpu.0.freq_levels: 2401/35000 2400/35000 1600/15000 800/12000 > > dev.cpu.0.freq: 800 > > > > But only because I'd added to /boot/loader.conf: > > > > hint.p4tcc.0.disabled=1 > > hint.acpi_throttle.0.disabled=1 > > > > which became the defaults sometime, maybe not before 11.0? Otherwise > > mine would look more similar to the one below, with all 12.5% increments > > in frequency enabled, which doesn't actually save any power at all. > > > > > FreeBSD apu-5 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #0 21e9d1ca9b80 > > (11) tip: Tue May 30 11:51:48 IDT 2017 > > > apu-5# sysctl dev.cpu.0.freq_levels > > > dev.cpu.0.freq_levels: 1000/966 875/845 800/795 700/695 600/600 525/525 > > 450/450 375/375 300/300 225/225 150/150 75/75 > > > > Looks like either p4tcc or acpi_throttle is enabled? See cpufreq(4). > > As above, these don't buy you anything but extra busyness for powerd. > > > > Also noticed that the (nice, low!) milliwatt figures for 1000/800/600 > > freqs are a bit different to the -stable one. Slightly Different model? > > > > > FreeBSD apu-1 10.3-STABLE FreeBSD 10.3-STABLE #4 267788fd852c (10) tip: > > Tue Jan 10 09:09:00 IST 2017 > > > apu-1# sysctl dev.cpu.0.freq_levels > > > dev.cpu.0.freq_levels: 1000/-1 875/-1 750/-1 625/-1 500/-1 375/-1 > > 250/-1 125/-1 > > > > And that looks like est(4) isn't enabled/attaching at all .. see dmesg > > on all of these for clues. > > > > > so, any ideas as to what is going on? > > > > Pure guesswork on experience with older versions, I'm not up to date. > > > > Very odd. Are all systems running identical CPUs and BIOSes? Identical > loader and sysctl configurations? Look at /var/rn/dmesg.boot for CPU > information. Is EST being detected? It used to be early in the boot > process, but is now fairly late. (In my case, about 2/3 through the > dmesg.boot file. Hi Kevin, it's been a while .. Danny, can you put up a verbose boot dmesg.boot of one(?) for a browse? Or maybe apu-4 and -1, if not all. I'd expect error msgs on -1 anyway. > I have p4tcc and throttling explicitly turned off (which should now be the > default), but my Sandy Bridge Core i5 still shows: > dev.cpu.0.freq_levels: 2501/35000 2500/35000 2000/26426 1800/23233 > 1600/20164 1400/17226 1200/14408 1000/11713 800/9140 All truly available I see on more recent processors. Certainly not 1/8 duty-cycle multipliers as p4tcc and maybe? acpi_throttle (not seen here) > The first is really bogus to indicate "turbo" mode. Usefully bogus, in that you can flag powerd to (in your case) -M 2500 to prevent it engaging "turbo" mode, as I do on my old Core2Duo, as advised by Warner years ago to avoid overheating on buildworlds and such - but more recent incarnations of "turbo" are supposedly far more functional. Admittedly a digression .. mostly coming from wondering about data Karl posted in response, indicating different Cx levels available and so used by the latter 3 AP cores, which was news to me. I'd like to know more, if only for gratuitous curiosity. Others can tick their TL;DR box :) > Temperature is a totally separate issue. It is VERY sensitive to external > issue like airflow and position of the CPU in relation to other components > in the chassis Also, unless you have a lot of cores, you probably should > set both economy_cx_lowest and performance_cx_lowest to Cmax. Economy > should default to that, but performance will not as that can cause issues > on systems with large numbers of cores, so is set to C2. Many such system > used to disable deeper sleep modes in BIOS, but I am way behind the times > and don't know about the current state of affairs. Certainly for systems > with 32 or fewer cores, this should not be an issue. In any case, Cx state > can sharply impact temperature. Indeed. But as these are low-power devices already, it's likely less of a concern, but maximising efficiency and minimising stress never hurts. > Finally, the last case with power levels of -1 for all frequencies is > probably because the CPU manufacturer (Intel?) has not published this > information. For a while they were treating this as "proprietary" > information. Very annoying! It's always something that is not readily > available. Thi is one reason I suspect your CPUs are not identical. Hmm, bought as a batch, that sounds unlikely, though their BIOSes (ono) may vary, and would be worth checking on each - and BIOS settings, too. Danny, is powerd running on all these? I doubt it would load on apu-1 as it stands. Note these are 'pure' 1/8 factors of 1000, p4tcc-alike, and I think quite likely indicate that cpufreq(4) failed to initialise? debug.cpufreq.verbose=1 in /boot/loader.conf might show a clue, with a verbose dmesg.boot anyway. Later: oops, just reread Karl's message, where I was unfaniliar with different CPUs showing different C-states, and noticing that despite cpu0 showing C2(io) available, and cx_lowest as C2, yet it used 100% C1 state, which was all that was available to cpu1 to 3. But then I twigged to Karl's hwpstate errors, so with 'apropos hwpstate' still showing nothing after all these years, along with other cpufreq(4) drivers, I used the list search via duckduckgo to finally find one (1) message, which lead to one detailed thread (that I even bought into!) https://lists.freebsd.org/pipermail/freebsd-stable/2012-May/subject.html https://lists.freebsd.org/pipermail/freebsd-stable/2012-June/thread.html /hwpstate Note the May one needs following by Subject, else it splits into 5 separate threads (?) Which may be interesting to cpufreq nerds, but had me remember that hwpstate(0) is for AMD not Intel CPUs. So now I'm totally confused :) Danny, do your results from Karl's sysctl listings agree with his? cheers, Ian From owner-freebsd-stable@freebsd.org Tue Aug 1 18:11:28 2017 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 13A28DB5C89 for ; Tue, 1 Aug 2017 18:11:28 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [67.205.158.196]) by mx1.freebsd.org (Postfix) with ESMTP id CE7226347A for ; Tue, 1 Aug 2017 18:11:27 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197]) by colo1.denninger.net (Postfix) with ESMTP id 3198827335 for ; Tue, 1 Aug 2017 14:11:26 -0400 (EDT) Received: from [192.168.10.20] (D10.Denninger.Net [192.168.10.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 58C0D33ABD for ; Tue, 1 Aug 2017 13:11:24 -0500 (CDT) Subject: Re: issues with powerd/freq_levels To: freebsd-stable@freebsd.org References: <8AEC9DBC-BADD-4FB2-8358-DA43F7EF5E68@cs.huji.ac.il> <20170731201323.A6737@sola.nimnet.asn.au> <20170802004343.T6737@sola.nimnet.asn.au> From: Karl Denninger Message-ID: <56f253a1-4bbe-f3a1-0ffd-a0153d767f3c@denninger.net> Date: Tue, 1 Aug 2017 13:11:23 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170802004343.T6737@sola.nimnet.asn.au> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms000804030807090501070604" 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: Tue, 01 Aug 2017 18:11:28 -0000 This is a cryptographically signed message in MIME format. --------------ms000804030807090501070604 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 8/1/2017 12:45, Ian Smith wrote: > On Mon, 31 Jul 2017 12:03:27 -0700, Kevin Oberman wrote: > > On Mon, Jul 31, 2017 at 3:48 AM, Ian Smith wr= ote: > >=20 > > > On Mon, 31 Jul 2017 10:09:11 +0300, Daniel Braniss wrote: > > > > > > > I am trying out PCengines latest apu2 boards, and I just notice= d that > > > with different Freebsd versions I get > > > > different freq_levels, and so when idling, each box (have 5) ha= s a > > > different freq/temperature value, ranging > > > > from 125/69.1C, 600/59.0C to 75/56.0C > > > > > > > > FreeBSD apu-4 11.1-STABLE FreeBSD 11.1-STABLE #5 f565b5a06ab3 (= 11) tip: > > > Mon Jul 31 09:36:33 IDT 2017 > > > > apu-4# sysctl dev.cpu.0.freq_levels > > > > dev.cpu.0.freq_levels: 1000/980 800/807 600/609 > > > > > > That looks about right. On a Core2Duo (still on 9.3) I get: > > > dev.est.1.freq_settings: 2401/35000 2400/35000 1600/15000 800/1200= 0 > > > dev.est.0.freq_settings: 2401/35000 2400/35000 1600/15000 800/1200= 0 > > > dev.cpu.0.freq_levels: 2401/35000 2400/35000 1600/15000 800/12000 > > > dev.cpu.0.freq: 800 > > > > > > But only because I'd added to /boot/loader.conf: > > > > > > hint.p4tcc.0.disabled=3D1 > > > hint.acpi_throttle.0.disabled=3D1 > > > > > > which became the defaults sometime, maybe not before 11.0? Otherw= ise > > > mine would look more similar to the one below, with all 12.5% incr= ements > > > in frequency enabled, which doesn't actually save any power at all= =2E > > > > > > > FreeBSD apu-5 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #0 21e9d1= ca9b80 > > > (11) tip: Tue May 30 11:51:48 IDT 2017 > > > > apu-5# sysctl dev.cpu.0.freq_levels > > > > dev.cpu.0.freq_levels: 1000/966 875/845 800/795 700/695 600/600= 525/525 > > > 450/450 375/375 300/300 225/225 150/150 75/75 > > > > > > Looks like either p4tcc or acpi_throttle is enabled? See cpufreq(= 4). > > > As above, these don't buy you anything but extra busyness for powe= rd. > > > > > > Also noticed that the (nice, low!) milliwatt figures for 1000/800/= 600 > > > freqs are a bit different to the -stable one. Slightly Different = model? > > > > > > > FreeBSD apu-1 10.3-STABLE FreeBSD 10.3-STABLE #4 267788fd852c (= 10) tip: > > > Tue Jan 10 09:09:00 IST 2017 > > > > apu-1# sysctl dev.cpu.0.freq_levels > > > > dev.cpu.0.freq_levels: 1000/-1 875/-1 750/-1 625/-1 500/-1 375/= -1 > > > 250/-1 125/-1 > > > > > > And that looks like est(4) isn't enabled/attaching at all .. see d= mesg > > > on all of these for clues. > > > > > > > so, any ideas as to what is going on? > > > > > > Pure guesswork on experience with older versions, I'm not up to da= te. > > > > >=20 > > Very odd. Are all systems running identical CPUs and BIOSes? Identic= al > > loader and sysctl configurations? Look at /var/rn/dmesg.boot for CPU= > > information. Is EST being detected? It used to be early in the boot > > process, but is now fairly late. (In my case, about 2/3 through the > > dmesg.boot file. > > Hi Kevin, it's been a while .. > > Danny, can you put up a verbose boot dmesg.boot of one(?) for a browse?= =20 > Or maybe apu-4 and -1, if not all. I'd expect error msgs on -1 anyway.= > > > I have p4tcc and throttling explicitly turned off (which should now = be the > > default), but my Sandy Bridge Core i5 still shows: > > dev.cpu.0.freq_levels: 2501/35000 2500/35000 2000/26426 1800/23233 > > 1600/20164 1400/17226 1200/14408 1000/11713 800/9140 > > All truly available I see on more recent processors. Certainly not 1/8= =20 > duty-cycle multipliers as p4tcc and maybe? acpi_throttle (not seen here= ) > > > The first is really bogus to indicate "turbo" mode. > > Usefully bogus, in that you can flag powerd to (in your case) -M 2500 t= o=20 > prevent it engaging "turbo" mode, as I do on my old Core2Duo, as advise= d=20 > by Warner years ago to avoid overheating on buildworlds and such - but = > more recent incarnations of "turbo" are supposedly far more functional.= > > Admittedly a digression .. mostly coming from wondering about data Karl= > posted in response, indicating different Cx levels available and so use= d=20 > by the latter 3 AP cores, which was news to me. I'd like to know more,= =20 > if only for gratuitous curiosity. Others can tick their TL;DR box :) > > > Temperature is a totally separate issue. It is VERY sensitive to ext= ernal > > issue like airflow and position of the CPU in relation to other comp= onents > > in the chassis Also, unless you have a lot of cores, you probably sh= ould > > set both economy_cx_lowest and performance_cx_lowest to Cmax. Econom= y > > should default to that, but performance will not as that can cause = issues > > on systems with large numbers of cores, so is set to C2. Many such s= ystem > > used to disable deeper sleep modes in BIOS, but I am way behind the = times > > and don't know about the current state of affairs. Certainly for sys= tems > > with 32 or fewer cores, this should not be an issue. In any case, Cx= state > > can sharply impact temperature. > > Indeed. But as these are low-power devices already, it's likely less o= f=20 > a concern, but maximising efficiency and minimising stress never hurts.= > > > Finally, the last case with power levels of -1 for all frequencies i= s > > probably because the CPU manufacturer (Intel?) has not published thi= s > > information. For a while they were treating this as "proprietary" > > information. Very annoying! It's always something that is not readil= y > > available. Thi is one reason I suspect your CPUs are not identical. > > Hmm, bought as a batch, that sounds unlikely, though their BIOSes (ono)= =20 > may vary, and would be worth checking on each - and BIOS settings, too.= > > Danny, is powerd running on all these? I doubt it would load on apu-1 = > as it stands. Note these are 'pure' 1/8 factors of 1000, p4tcc-alike, = > and I think quite likely indicate that cpufreq(4) failed to initialise?= =20 > debug.cpufreq.verbose=3D1 in /boot/loader.conf might show a clue, with = a=20 > verbose dmesg.boot anyway. > > Later: oops, just reread Karl's message, where I was unfaniliar with=20 > different CPUs showing different C-states, and noticing that despite=20 > cpu0 showing C2(io) available, and cx_lowest as C2, yet it used 100% C1= =20 > state, which was all that was available to cpu1 to 3. > > But then I twigged to Karl's hwpstate errors, so with 'apropos hwpstate= '=20 > still showing nothing after all these years, along with other cpufreq(4= )=20 > drivers, I used the list search via duckduckgo to finally find one (1) = > message, which lead to one detailed thread (that I even bought into!) > > https://lists.freebsd.org/pipermail/freebsd-stable/2012-May/subject.ht= ml > https://lists.freebsd.org/pipermail/freebsd-stable/2012-June/thread.ht= ml > > /hwpstate Note the May one needs following by Subject, else it splits = > into 5 separate threads (?) > > Which may be interesting to cpufreq nerds, but had me remember that=20 > hwpstate(0) is for AMD not Intel CPUs. So now I'm totally confused :) > > Danny, do your results from Karl's sysctl listings agree with his? These are not Intel CPUs; they are an embedded AMD 64-bit CPU. The specs on the one I have are: * CPU: AMD Embedded G series GX-412TC, 1 GHz quad Jaguar core with 64 bit and AES-NI support, 32K data + 32K instruction cache per core, shared 2MB L2 cache. * DRAM: 2 or 4 GB DDR3-1333 DRAM * Storage: Boot from m-SATA SSD, SD card (internal sdhci controller), or external USB. 1 SATA + power connector. * 12V DC, about 6 to 12W depending on CPU load. Jack =3D 2.5 mm, center= positive * Connectivity: 2 or 3 Gigabit Ethernet channels (Intel i211AT on apu2b2, i210AT on apu2b4) * I/O: DB9 serial port, 2 USB 3.0 external + + 2 USB 2.0 internal, three front panel LEDs, pushbutton * Expansion: 2 miniPCI express (one with SIM socket), LPC bus, GPIO header, I2C bus, COM2 (3.3V RXD / TXD) * Board size: 6 x 6" (152.4 x 152.4 mm) - same as apu1d, alix2d13 and wrap1e. * Firmware: coreboot (please contact support@pcengines.ch for source code if desired). * Cooling: Conductive cooling from the CPU to the enclosure using a 3 mm alu heat spreader (included). The one I have here is a 2Gb RAM/2 IGB Ethernet interface unit. They're surprisingly capable for their size, conductive cooling and (especially) price. As a firewall/VPN ingress point they perform nicely. I boot the one I have here from an SD card in a NanoBSD config but you can stick a mSATA SSD (laptop-computer style) in the case and boot from that if you want (I've tried it; the internal BIOS it comes with boots from it just fine.) --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms000804030807090501070604 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA4MDExODExMjNaME8GCSqGSIb3DQEJBDFCBEAMlw4M osAabDudme7kkwhxB8CmOvt2pvYFODFg5FPZExxbZrfbhCkfkPWq+D8ISMEl83uiAIg8Nd+G R7NDOOj2MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAVM7z1REF4TAB A8p/PKjeuqux4wJc1JU4mFh98f7JOhs870SrZHw0Kq/bEHEebMi/RHqK4cnXMk3ui3nDuW9w s0cFRd4izJF1EqF+0voct0EPfbwvNzuVN4vC8DcmsfDT5VRPHisIzdQgm7Fw7GweIUfKaW+C zAsevNhXMr4GJf0ZKkEWfSEYud0Vl3RClkXyRiFx9JxtqXzc4C4Dk69bGIM8ZsaTX8J3JStJ E+/zsHyOUXjweLxKmd3xzzi1R+tt4bSdgNd6JphBxcoL0EvzQ2qi5ugP3MQFxEkNZUqunjLD fZ7uVyFKHBPuAFSmY4CcYkZvA706lCIoVuQm2twgGR5UU3B4JwGpUJwGBWzF8gdlr73tdEKo ZoHcr0vpTWjSRu6dH1kkCiL5BTcxjjosQveK+tgWj/r45hLoKQPVEs028hXBzOmkseTgRNn0 8kV08mWQd8mM0ARRRCxCF87OsCRKb/v8AvbtIkF0ULCSYyNOrk6yYdcVWKHfGKbv8K8iIeqx ufHkr1FiacsAcjtD+IT416Ztxb9bZkQmRCMHbXhweawMjMMwPwxLwPR1ALbZcwyDkmd9v5CE cxJgD9kd3LkMS8W0QoI/RhWFKu4DI5LEtl9L4CMKQW1Y6vfqfHTV50fDis/BFASSFYsmo0Kk HFyYPfXpPkxA1WJxIWQ2NncAAAAAAAA= --------------ms000804030807090501070604-- From owner-freebsd-stable@freebsd.org Tue Aug 1 20:10:08 2017 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 1CFB8DBC1FD for ; Tue, 1 Aug 2017 20:10:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F26EB6712E for ; Tue, 1 Aug 2017 20:10:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v71KA7n2051787 for ; Tue, 1 Aug 2017 20:10:07 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 221146] [LAGG] Problem with second laggport Date: Tue, 01 Aug 2017 20:10:07 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: peixoto.cassiano@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-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 Aug 2017 20:10:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221146 Cassiano Peixoto changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |freebsd-stable@FreeBSD.org, | |peixoto.cassiano@gmail.com --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Tue Aug 1 20:39:49 2017 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 15F9ADBCBC6 for ; Tue, 1 Aug 2017 20:39:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 04980682A4 for ; Tue, 1 Aug 2017 20:39:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v71Kdmq9023110 for ; Tue, 1 Aug 2017 20:39:48 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 221146] [LAGG] Problem with second laggport Date: Tue, 01 Aug 2017 20:39:49 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: vegeta@tuxpowered.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-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 Aug 2017 20:39:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221146 vegeta@tuxpowered.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vegeta@tuxpowered.net --- Comment #3 from vegeta@tuxpowered.net --- I have some Intel xl710 running failover lagg and I had an issue not totally unlike this one. One of ports in lagg (and always the same one, unless they were added in different order, then both would always work) would only send frames but never receive them, so the router would become master on carp on vlans on this lagg, never seeing carp advertisements of the primary router. That was on FreeBSD 11.0, though. I used ixgbe-2.5.15 from Intel instead of= the one coming with Kernel and the issue was gone. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Tue Aug 1 20:40:45 2017 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 CA154DBCD30 for ; Tue, 1 Aug 2017 20:40:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B7A1F684BE for ; Tue, 1 Aug 2017 20:40:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v71KejSL026254 for ; Tue, 1 Aug 2017 20:40:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 221146] [LAGG] Problem with second laggport Date: Tue, 01 Aug 2017 20:40:45 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: vegeta@tuxpowered.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-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 Aug 2017 20:40:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221146 --- Comment #4 from vegeta@tuxpowered.net --- Sorry, I meant ixl-1.7.12 from Intel. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Tue Aug 1 21:02:42 2017 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 4D8B6DBD50E for ; Tue, 1 Aug 2017 21:02:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3BF9E6930E for ; Tue, 1 Aug 2017 21:02:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v71L2ftT094417 for ; Tue, 1 Aug 2017 21:02:42 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 221146] [LAGG] Problem with second laggport Date: Tue, 01 Aug 2017 21:02:41 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: peixoto.cassiano@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-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 Aug 2017 21:02:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221146 --- Comment #5 from Cassiano Peixoto --- Hi guys, It's a bug after commit r320897. I have the same issue running an ix interface in netmap mode after this com= mit. I had to downgrade ixgbe drivers to make it works again. Looks like a bug after driver update to 3.2.12-k. I'm copying the author of commit. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Tue Aug 1 22:13:33 2017 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 0BC6CDBEB03 for ; Tue, 1 Aug 2017 22:13:33 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [IPv6:2001:1440:5001:1::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "uucp.dinoex.sub.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8A9A46B4D7 for ; Tue, 1 Aug 2017 22:13:32 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by uucp.dinoex.sub.de (8.15.2/8.14.9) with ESMTPS id v71MD7C4058061 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 2 Aug 2017 00:13:07 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.15.2/8.14.9/Submit) with UUCP id v71MD7pQ058060 for freebsd-stable@FreeBSD.ORG; Wed, 2 Aug 2017 00:13:07 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.15.2/8.15.2) with ESMTP id v71LFSCu013767 for ; Tue, 1 Aug 2017 23:15:29 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.15.2/8.15.2) with ESMTP id v71LEDvJ013453 for ; Tue, 1 Aug 2017 23:14:14 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: (from news@localhost) by gate.oper.dinoex.org (8.15.2/8.15.2/Submit) id v71LECSF013447 for freebsd-stable@FreeBSD.ORG; Tue, 1 Aug 2017 23:14:12 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-Authentication-Warning: gate.oper.dinoex.org: news set sender to li-fbsd@citylink.dinoex.sub.org using -f From: Peter Subject: 11.1-RELEASE: panic! acl_from_aces: a_type is 0x4000 Date: Tue, 1 Aug 2017 22:59:00 +0200 Organization: even some more stinky socks Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Tue, 1 Aug 2017 20:59:00 -0000 (UTC) Injection-Info: oper.dinoex.de; logging-data="70848"; mail-complaints-to="usenet@citylink.dinoex.sub.org" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48 X-Mozilla-News-Host: news://localhost:119 Sender: li-fbsd@citylink.dinoex.sub.org To: freebsd-stable@FreeBSD.ORG X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (uucp.dinoex.sub.de [194.45.71.2]); Wed, 02 Aug 2017 00:13:08 +0200 (CEST) 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 Aug 2017 22:13:33 -0000 This is mostly for the search engines, so others running into it may find it easier to solve. While updating some ports via "portupgrade", I got this panic: Panic String: acl_from_aces: a_type is 0x4000 The phenomen was reproducible; it appeared while creating a backup package from the "glib" port. I checked readability of all concerned files, did a scrub on the pool, but found no errors! As I was busy with other issues, I then neglected the matter and simply deleted and reinstalled that port. A couple days later, working on a different installation, I got the exact same panic at the exact same point, while updating the "glib" port. This time I looked closer into the matter. According to "truss", the panic appears while "pkg" calls __acl_get_link() on a specific file. That file is readable. The directory tree can be searched. But it is not possible to do "ls -l" on the directory -> panic! It is possible to send+recv the Filesystem: the error gets transported to the new filesystem! (From ZFS view it seems to be legal payload; only from FreeBSD file-handling view it is reason for panic.) Finally, the file can be copied, unlinked, and recreated. I did a thorough search and found a dozen other files on the system with the same issue. REMEDY: ------- It seems that such flaws can lure undetected on a system for an indefinite time. The only way to find them seems read all inode data, via something like #find -x `mount -t zfs | awk '{print $3}'` -type d -exec ls -la {} \; ROOT CAUSE: ----------- Not fully clear. It may be related to hardware (memory) flaws. From owner-freebsd-stable@freebsd.org Wed Aug 2 03:26:47 2017 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 2BA2BDC4284 for ; Wed, 2 Aug 2017 03:26:47 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from hobbes.arroway.org (hobbes.arroway.org [173.199.118.77]) by mx1.freebsd.org (Postfix) with ESMTP id DEFB973569 for ; Wed, 2 Aug 2017 03:26:45 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from [10.1.1.10] (unknown [177.89.5.111]) by hobbes.arroway.org (Postfix) with ESMTPA id 0550C1FD737 for ; Wed, 2 Aug 2017 00:26:36 -0300 (BRT) Received: from 10.1.1.86 (SquirrelMail authenticated user matheus) by 10.1.1.10 with HTTP; Wed, 2 Aug 2017 00:26:38 -0300 Message-ID: In-Reply-To: References: <39221eefb6288d3b9154e85f4faa6501.squirrel@10.1.1.10> <419c54e8944df9d6c8a8a15413dfc7ba.squirrel@10.1.1.10> Date: Wed, 2 Aug 2017 00:26:38 -0300 Subject: Re: FreeBSD 11.1-R network slowness on Samba and Windows VM on VirtualBox From: "Nenhum_de_Nos" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal 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 Aug 2017 03:26:47 -0000 On Tue, August 1, 2017 11:41, Werner Griessl wrote: > On 08/01/17 04:52, Nenhum_de_Nos wrote: >> >> On Sun, July 30, 2017 02:08, Nenhum_de_Nos wrote: >>> Hi, >>> >>> I was running 10.3-p7 on Atom hardware and using old samba36-3.6.25_1. >>> All >>> was fine. >>> >>> Then I updated to 11.1-R by recompiling from svn, using the same >>> kernelconfig from 10.3, and now my windows client shows timeouts and >>> really slow connection. File copy never past kilobytes per second :( >>> >>> I am compiling a new samba packet from ports, but that slow is weird >>> for >>> me, and I could not find any other cases on web search. >>> >>> thanks, >>> >>> matheus >> >> Hi guys, >> >> I got this still going, where I installed a new Windows VM and same >> problem. I reinstalled all ports and same problem. I use Windows shares >> from another sources (not a VirtualBox VM) and all works fine. >> >> Some help were said here https://forums.freebsd.org/threads/61813/, but >> unfortunately I have no leads so far. >> >> I will try to install some 10.3 box to try it out when I get some time >> and >> a free machine. >> >> If anyone has any clues. >> >> thanks, >> > > > Try comment out in smb4.conf the line: > "# case sensitive = true" > Worked for me with samba44 > > Werner Hi Werner, as I got my samba conf from old 3.6 I don't have this line there. I tried something today. I got and i386 netbook to work using 4.4 samba and FreeBSD hetchet 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 #0 r306420: Thu Sep 29 03:40:55 UTC 2016 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386. The vm could copy files from it. Then I compiled the samba port on the Atom amd64 machine, same problem. I got to know the amd64 machine has custom kernel conf, but mostly just pf stuff: Code: diff GENERIC FreeBSD-11-amd64-PF 19c19 < # $FreeBSD: releng/11.1/sys/amd64/conf/GENERIC 318763 2017-05-24 00:00:55Z jhb $ --- > # $FreeBSD: releng/11.0/sys/amd64/conf/GENERIC 302410 2016-07-08 00:22:14Z gjb $ 22c22 < ident GENERIC --- > ident FreeBSD-11-amd64-PF 88d87 < options EARLY_AP_STARTUP 360a360,378 > > # pf > > device pf > device pflog > device pfsync > > options ALTQ > options ALTQ_CBQ # Class Bases Queuing (CBQ) > options ALTQ_RED # Random Early Detection (RED) > options ALTQ_RIO # RED In/Out > options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) > options ALTQ_PRIQ # Priority Queuing (PRIQ) > > device carp > > # device polling > options DEVICE_POLLING I just got all ports rebuilt after the upgrade to 11.1-R, so should I do it all again? No forget, just machines under Virtualbox suffer, all other work fine. thanks, > -- > Werner Grießl D-95440 Bayreuth, Germany > Universitaet Bayreuth Tel.: +49 921 55 2685 > IT-Servicezentrum/Netze NW2 3.2.U1.143 > _______________________________________________ > 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" -- "We will call you Cygnus, the God of balance you shall be." From owner-freebsd-stable@freebsd.org Wed Aug 2 08:21:03 2017 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 DBF1EDC97C3 for ; Wed, 2 Aug 2017 08:21:03 +0000 (UTC) (envelope-from juraj.vanco@intel.com) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "orsmga104.jf.intel.com", Issuer "Intel External Issuing CA 6A" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9A7EC7F0FF; Wed, 2 Aug 2017 08:21:02 +0000 (UTC) (envelope-from juraj.vanco@intel.com) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga104.jf.intel.com with ESMTP; 02 Aug 2017 01:20:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,310,1498546800"; d="scan'208";a="132416473" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by orsmga005.jf.intel.com with ESMTP; 02 Aug 2017 01:20:54 -0700 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.9]) by IRSMSX102.ger.corp.intel.com ([169.254.2.211]) with mapi id 14.03.0319.002; Wed, 2 Aug 2017 09:20:54 +0100 From: "Vanco, Juraj" To: Alan Somers CC: "freebsd-stable@freebsd.org" Subject: RE: FreeBSD 11.1 - unknown group wheel Thread-Topic: FreeBSD 11.1 - unknown group wheel Thread-Index: AdMK6pIg8rQCFmhiS1+RbaJbAR9WFv//87MA//74aNA= Date: Wed, 2 Aug 2017 08:20:53 +0000 Message-ID: <996B37956731CF40B1A674B085ACCE9440BFA617@IRSMSX103.ger.corp.intel.com> References: <996B37956731CF40B1A674B085ACCE9440BFA2B9@IRSMSX103.ger.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 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 Aug 2017 08:21:04 -0000 VGhhbmtzIEFsYW4sDQoNCnRoYXQgaGVscGVkLg0KDQpqdg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogYXNvbWVyc0BnbWFpbC5jb20gW21haWx0bzphc29tZXJzQGdtYWlsLmNv bV0gT24gQmVoYWxmIE9mIEFsYW4gU29tZXJzDQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMSwgMjAx NyA2OjM3IFBNDQpUbzogVmFuY28sIEp1cmFqIDxqdXJhai52YW5jb0BpbnRlbC5jb20+DQpDYzog ZnJlZWJzZC1zdGFibGVAZnJlZWJzZC5vcmcNClN1YmplY3Q6IFJlOiBGcmVlQlNEIDExLjEgLSB1 bmtub3duIGdyb3VwIHdoZWVsDQoNCkNoZWNrIHlvdXIgL2V0Yy9uc3N3aXRjaC5jb25mIGZpbGUu ICBJdCdzIHBvc3NpYmxlIHRvIHNjcmV3IHRoYXQgdXAgc28gdGhhdCAvZXRjL2dyb3VwcyBkb2Vz bid0IGV2ZW4gZ2V0IGNoZWNrZWQuDQotQWxhbg0KDQpPbiBUdWUsIEF1ZyAxLCAyMDE3IGF0IDEx OjI3IEFNLCBWYW5jbywgSnVyYWogPGp1cmFqLnZhbmNvQGludGVsLmNvbT4gd3JvdGU6DQo+IEhl bGxvLA0KPg0KPiBJIGFtIHRyeWluZyB0byBidWlsZCBhIGtlcm5lbCBpbiBGcmVlQlNEIDExLjAs IGhvd2V2ZXIgSSBhbSBnZXR0aW5nIGEgDQo+IG1lc3NhZ2UNCj4NCj4gbXRyZWUgLWRlVSAtZiAv dXNyL3NyYy9ldGMvbXRyZWUvQlNELnVzci5kaXN0ICAtcCANCj4gL3Vzci9vYmovdXNyL3NyYy90 bXAvdXNyID4vZGV2L251bGwNCj4gbXRyZWU6IHVua25vd24gZ3JvdXAgYHdoZWVsJw0KPiBtdHJl ZTogZmFpbGVkIGF0IGxpbmUgNiBvZiB0aGUgc3BlY2lmaWNhdGlvbg0KPiAqKiogRXJyb3IgY29k ZSAxDQo+DQo+DQo+IEhvd2V2ZXIgdGhlIGdyb3VwIGlzIGtub3duOg0KPiAjIGNhdCAvZXRjL2dy b3VwIHwgaGVhZCAtbiAzDQo+ICMgJEZyZWVCU0Q6IHJlbGVuZy8xMS4wL2V0Yy9ncm91cCAyOTQ4 OTYgMjAxNi0wMS0yNyAwNjoyODo1NlogYXJhdWpvICQgDQo+ICMgd2hlZWw6KjowOnJvb3QNCj4N Cj4NCj4gYW5kIGN1cnJlbnRseSB1c2VkOg0KPiAjIGdyb3Vwcw0KPiAwDQo+DQo+DQo+IFJ1bm5p bmcgYW55IHF1ZXJ5IG9uIGdyb3VwIHJlc3VsdCB3aXRoIHplcm8gYW5zd2VyOg0KPiAjIGdldGVu dCBncm91cCB3aGVlbA0KPiAjDQo+ICMgZ2V0ZW50IGdyb3VwIHZpZGVvDQo+ICMNCj4NCj4NCj4g U2ltaWxhciByZXN1bHQgZ2l2ZXMgbWVyZ2VtYXN0ZXI6DQo+ICMgbWVyZ2VtYXN0ZXIgLXANCj4N Cj4gKioqIFRoZSBkaXJlY3Rvcnkgc3BlY2lmaWVkIGZvciB0aGUgdGVtcG9yYXJ5IHJvb3QgZW52 aXJvbm1lbnQsDQo+ICAgICAvdmFyL3RtcC90ZW1wcm9vdCwgZXhpc3RzLiAgVGhpcyBjYW4gYmUg YSBzZWN1cml0eSByaXNrIGlmIHVudHJ1c3RlZA0KPiAgICAgdXNlcnMgaGF2ZSBhY2Nlc3MgdG8g dGhlIHN5c3RlbS4NCj4NCj4gICBVc2UgJ2QnIHRvIGRlbGV0ZSB0aGUgb2xkIC92YXIvdG1wL3Rl bXByb290IGFuZCBjb250aW51ZQ0KPiAgIFVzZSAndCcgdG8gc2VsZWN0IGEgbmV3IHRlbXBvcmFy eSByb290IGRpcmVjdG9yeQ0KPiAgIFVzZSAnZScgdG8gZXhpdCBtZXJnZW1hc3Rlcg0KPg0KPiAg IERlZmF1bHQgaXMgdG8gdXNlIC92YXIvdG1wL3RlbXByb290IGFzIGlzDQo+DQo+IEhvdyBzaG91 bGQgSSBkZWFsIHdpdGggdGhpcz8gW1VzZSB0aGUgZXhpc3RpbmcgL3Zhci90bXAvdGVtcHJvb3Rd IGQNCj4NCj4gICAgKioqIERlbGV0aW5nIHRoZSBvbGQgL3Zhci90bXAvdGVtcHJvb3QNCj4NCj4g KioqIENyZWF0aW5nIHRoZSB0ZW1wb3Jhcnkgcm9vdCBlbnZpcm9ubWVudCBpbiAvdmFyL3RtcC90 ZW1wcm9vdA0KPiAgKioqIC92YXIvdG1wL3RlbXByb290IHJlYWR5IGZvciB1c2UNCj4gICoqKiBD cmVhdGluZyBhbmQgcG9wdWxhdGluZyBkaXJlY3Rvcnkgc3RydWN0dXJlIGluIC92YXIvdG1wL3Rl bXByb290DQo+DQo+IGluc3RhbGw6IHVua25vd24gZ3JvdXAgd2hlZWwNCj4NCj4NCj4gSSBjYW5u b3QgZmluZCBpZiB0aGlzIGlzIGFueSBrbm93biBpc3N1ZS4uLiBBbnkgY2x1ZT8NCj4NCj4ganYN Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gSW50ZWwgUmVzZWFyY2ggYW5kIERldmVsb3BtZW50IElyZWxhbmQgTGltaXRl ZCBSZWdpc3RlcmVkIGluIElyZWxhbmQgDQo+IFJlZ2lzdGVyZWQgT2ZmaWNlOiBDb2xsaW5zdG93 biBJbmR1c3RyaWFsIFBhcmssIExlaXhsaXAsIENvdW50eSANCj4gS2lsZGFyZSBSZWdpc3RlcmVk IE51bWJlcjogMzA4MjYzDQo+DQo+DQo+IFRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG1hdGVyaWFsIGZvciANCj4gdGhlIHNvbGUgdXNlIG9m IHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcgb3IgZGlzdHJpYnV0aW9uIA0K PiBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIA0KPiByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0 ZSBhbGwgY29waWVzLg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBmcmVlYnNkLXN0YWJsZUBmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QgDQo+IGh0 dHBzOi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLXN0YWJsZQ0K PiBUbyB1bnN1YnNjcmliZSwgc2VuZCBhbnkgbWFpbCB0byAiZnJlZWJzZC1zdGFibGUtdW5zdWJz Y3JpYmVAZnJlZWJzZC5vcmciDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpJbnRlbCBSZXNlYXJjaCBhbmQgRGV2ZWxvcG1lbnQg SXJlbGFuZCBMaW1pdGVkClJlZ2lzdGVyZWQgaW4gSXJlbGFuZApSZWdpc3RlcmVkIE9mZmljZTog Q29sbGluc3Rvd24gSW5kdXN0cmlhbCBQYXJrLCBMZWl4bGlwLCBDb3VudHkgS2lsZGFyZQpSZWdp c3RlcmVkIE51bWJlcjogMzA4MjYzCgoKVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlCnVzZSBvZiB0aGUg aW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3IG9yIGRpc3RyaWJ1dGlvbiBieSBvdGhl cnMgaXMKc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlCnNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3BpZXMu Cg== From owner-freebsd-stable@freebsd.org Wed Aug 2 08:26:11 2017 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 6C027DC9A70 for ; Wed, 2 Aug 2017 08:26:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 596D87F524 for ; Wed, 2 Aug 2017 08:26:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v728QACf068087 for ; Wed, 2 Aug 2017 08:26:11 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 221146] [LAGG] Problem with second laggport Date: Wed, 02 Aug 2017 08:26:11 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? X-Bugzilla-Changed-Fields: flagtypes.name keywords bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-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 Aug 2017 08:26:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221146 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |mfc-stable11? Keywords| |regression Status|New |Open --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Wed Aug 2 08:39:28 2017 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 6AFE7DCA038 for ; Wed, 2 Aug 2017 08:39:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 598227FE83 for ; Wed, 2 Aug 2017 08:39:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v728dRNh097325 for ; Wed, 2 Aug 2017 08:39:28 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 221146] [LAGG] Problem with second laggport Date: Wed, 02 Aug 2017 08:39:28 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kbowling@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-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 Aug 2017 08:39:28 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221146 Kevin Bowling changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kbowling@freebsd.org --- Comment #6 from Kevin Bowling --- We're seeing this on cxgbe(4) as well, so I think it's related to if_lagg locking changes and the LACP init code. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Wed Aug 2 10:30:16 2017 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 E2E81DCC561 for ; Wed, 2 Aug 2017 10:30:16 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CB22B83F09 for ; Wed, 2 Aug 2017 10:30:16 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id CA632DCC560; Wed, 2 Aug 2017 10:30:16 +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 C9D68DCC55F for ; Wed, 2 Aug 2017 10:30:16 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 23E7683F08 for ; Wed, 2 Aug 2017 10:30:15 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1dcquh-000D5s-Fg; Wed, 02 Aug 2017 13:30:03 +0300 From: Daniel Braniss Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: issues with powerd/freq_levels Date: Wed, 2 Aug 2017 13:30:03 +0300 In-Reply-To: <20170802004343.T6737@sola.nimnet.asn.au> Cc: Kevin Oberman , Karl Denninger , stable@freebsd.org To: Ian Smith References: <8AEC9DBC-BADD-4FB2-8358-DA43F7EF5E68@cs.huji.ac.il> <20170731201323.A6737@sola.nimnet.asn.au> <20170802004343.T6737@sola.nimnet.asn.au> X-Mailer: Apple Mail (2.3273) 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: Wed, 02 Aug 2017 10:30:17 -0000 > On 1 Aug 2017, at 20:45, Ian Smith wrote: >=20 > On Mon, 31 Jul 2017 12:03:27 -0700, Kevin Oberman wrote: >> On Mon, Jul 31, 2017 at 3:48 AM, Ian Smith = wrote: >>=20 >>> On Mon, 31 Jul 2017 10:09:11 +0300, Daniel Braniss wrote: >>>=20 >>>> I am trying out PCengines latest apu2 boards, and I just noticed = that >>> with different Freebsd versions I get >>>> different freq_levels, and so when idling, each box (have 5) has a >>> different freq/temperature value, ranging >>>> from 125/69.1C, 600/59.0C to 75/56.0C >>>>=20 >>>> FreeBSD apu-4 11.1-STABLE FreeBSD 11.1-STABLE #5 f565b5a06ab3 (11) = tip: >>> Mon Jul 31 09:36:33 IDT 2017 >>>> apu-4# sysctl dev.cpu.0.freq_levels >>>> dev.cpu.0.freq_levels: 1000/980 800/807 600/609 >>>=20 >>> That looks about right. On a Core2Duo (still on 9.3) I get: >>> dev.est.1.freq_settings: 2401/35000 2400/35000 1600/15000 800/12000 >>> dev.est.0.freq_settings: 2401/35000 2400/35000 1600/15000 800/12000 >>> dev.cpu.0.freq_levels: 2401/35000 2400/35000 1600/15000 800/12000 >>> dev.cpu.0.freq: 800 >>>=20 >>> But only because I'd added to /boot/loader.conf: >>>=20 >>> hint.p4tcc.0.disabled=3D1 >>> hint.acpi_throttle.0.disabled=3D1 >>>=20 >>> which became the defaults sometime, maybe not before 11.0? = Otherwise >>> mine would look more similar to the one below, with all 12.5% = increments >>> in frequency enabled, which doesn't actually save any power at all. >>>=20 >>>> FreeBSD apu-5 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #0 = 21e9d1ca9b80 >>> (11) tip: Tue May 30 11:51:48 IDT 2017 >>>> apu-5# sysctl dev.cpu.0.freq_levels >>>> dev.cpu.0.freq_levels: 1000/966 875/845 800/795 700/695 600/600 = 525/525 >>> 450/450 375/375 300/300 225/225 150/150 75/75 >>>=20 >>> Looks like either p4tcc or acpi_throttle is enabled? See = cpufreq(4). >>> As above, these don't buy you anything but extra busyness for = powerd. >>>=20 >>> Also noticed that the (nice, low!) milliwatt figures for = 1000/800/600 >>> freqs are a bit different to the -stable one. Slightly Different = model? >>>=20 >>>> FreeBSD apu-1 10.3-STABLE FreeBSD 10.3-STABLE #4 267788fd852c (10) = tip: >>> Tue Jan 10 09:09:00 IST 2017 >>>> apu-1# sysctl dev.cpu.0.freq_levels >>>> dev.cpu.0.freq_levels: 1000/-1 875/-1 750/-1 625/-1 500/-1 375/-1 >>> 250/-1 125/-1 >>>=20 >>> And that looks like est(4) isn't enabled/attaching at all .. see = dmesg >>> on all of these for clues. >>>=20 >>>> so, any ideas as to what is going on? >>>=20 >>> Pure guesswork on experience with older versions, I'm not up to = date. >>>=20 >>=20 >> Very odd. Are all systems running identical CPUs and BIOSes? = Identical >> loader and sysctl configurations? Look at /var/rn/dmesg.boot for CPU >> information. Is EST being detected? It used to be early in the boot >> process, but is now fairly late. (In my case, about 2/3 through the >> dmesg.boot file. >=20 > Hi Kevin, it's been a while .. >=20 > Danny, can you put up a verbose boot dmesg.boot of one(?) for a = browse?=20 > Or maybe apu-4 and -1, if not all. I'd expect error msgs on -1 = anyway. they are now available at: http://www.cs.huji.ac.il/~danny/pcengines/ = >=20 >> I have p4tcc and throttling explicitly turned off (which should now = be the >> default), but my Sandy Bridge Core i5 still shows: >> dev.cpu.0.freq_levels: 2501/35000 2500/35000 2000/26426 1800/23233 >> 1600/20164 1400/17226 1200/14408 1000/11713 800/9140 >=20 > All truly available I see on more recent processors. Certainly not = 1/8=20 > duty-cycle multipliers as p4tcc and maybe? acpi_throttle (not seen = here) >=20 >> The first is really bogus to indicate "turbo" mode. >=20 > Usefully bogus, in that you can flag powerd to (in your case) -M 2500 = to=20 > prevent it engaging "turbo" mode, as I do on my old Core2Duo, as = advised=20 > by Warner years ago to avoid overheating on buildworlds and such - but=20= > more recent incarnations of "turbo" are supposedly far more = functional. >=20 > Admittedly a digression .. mostly coming from wondering about data = Karl > posted in response, indicating different Cx levels available and so = used=20 > by the latter 3 AP cores, which was news to me. I'd like to know = more,=20 > if only for gratuitous curiosity. Others can tick their TL;DR box :) >=20 >> Temperature is a totally separate issue. It is VERY sensitive to = external >> issue like airflow and position of the CPU in relation to other = components >> in the chassis Also, unless you have a lot of cores, you probably = should >> set both economy_cx_lowest and performance_cx_lowest to Cmax. Economy >> should default to that, but performance will not as that can cause = issues >> on systems with large numbers of cores, so is set to C2. Many such = system >> used to disable deeper sleep modes in BIOS, but I am way behind the = times >> and don't know about the current state of affairs. Certainly for = systems >> with 32 or fewer cores, this should not be an issue. In any case, Cx = state >> can sharply impact temperature. >=20 > Indeed. But as these are low-power devices already, it's likely less = of=20 > a concern, but maximising efficiency and minimising stress never = hurts. >=20 >> Finally, the last case with power levels of -1 for all frequencies is >> probably because the CPU manufacturer (Intel?) has not published this >> information. For a while they were treating this as "proprietary" >> information. Very annoying! It's always something that is not readily >> available. Thi is one reason I suspect your CPUs are not identical. >=20 > Hmm, bought as a batch, that sounds unlikely, though their BIOSes = (ono)=20 > may vary, and would be worth checking on each - and BIOS settings, = too. >=20 > Danny, is powerd running on all these? I doubt it would load on apu-1=20= > as it stands. =20 it is working on the apu-1! > Note these are 'pure' 1/8 factors of 1000, = p4tcc-alike,=20 > and I think quite likely indicate that cpufreq(4) failed to = initialise?=20 > debug.cpufreq.verbose=3D1 in /boot/loader.conf might show a clue, with = a=20 > verbose dmesg.boot anyway. >=20 > Later: oops, just reread Karl's message, where I was unfaniliar with=20= > different CPUs showing different C-states, and noticing that despite=20= > cpu0 showing C2(io) available, and cx_lowest as C2, yet it used 100% = C1=20 > state, which was all that was available to cpu1 to 3. >=20 > But then I twigged to Karl's hwpstate errors, so with 'apropos = hwpstate'=20 > still showing nothing after all these years, along with other = cpufreq(4)=20 > drivers, I used the list search via duckduckgo to finally find one (1)=20= > message, which lead to one detailed thread (that I even bought into!) >=20 > = https://lists.freebsd.org/pipermail/freebsd-stable/2012-May/subject.html = = > = https://lists.freebsd.org/pipermail/freebsd-stable/2012-June/thread.html = = >=20 > /hwpstate Note the May one needs following by Subject, else it splits=20= > into 5 separate threads (?) >=20 > Which may be interesting to cpufreq nerds, but had me remember that=20 > hwpstate(0) is for AMD not Intel CPUs. So now I'm totally confused :) >=20 > Danny, do your results from Karl's sysctl listings agree with his? yes, except mine seem to be running at a higher temperature. thanks, danny >=20 > cheers, Ian From owner-freebsd-stable@freebsd.org Wed Aug 2 12:59:45 2017 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 11699DD06A3; Wed, 2 Aug 2017 12:59:45 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 470C56408F; Wed, 2 Aug 2017 12:59:43 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1dcszy-0007ZC-55; Wed, 02 Aug 2017 14:43:38 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: freebsd-fs@freebsd.org, "Eugene M. Zheganin" Cc: freebsd-stable Subject: Re: some general zfs tuning (for iSCSI) References: <8b41e7d6-7a2c-d456-2eee-93efd81aa86a@norma.perm.ru> Date: Wed, 02 Aug 2017 14:43:31 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <8b41e7d6-7a2c-d456-2eee-93efd81aa86a@norma.perm.ru> User-Agent: Opera Mail/1.0 (Win32) X-Authenticated-As-Hash: bdb49c4ff80bd276e321aade33e76e02752072e2 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: ++ X-Spam-Score: 2.0 X-Spam-Status: No, score=2.0 required=5.0 tests=ALL_TRUSTED, BAYES_95 autolearn=disabled version=3.4.0 X-Scan-Signature: 788438cbfdc4dc137ce560360a3a99c7 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 Aug 2017 12:59:45 -0000 On Fri, 28 Jul 2017 12:56:11 +0200, Eugene M. Zheganin wrote: > Hi, > > > I'm using several FreeBSD zfs installations as the iSCSI production > systems, they basically consist of an LSI HBA, and a JBOD with a bunch > of SSD disks (12-24, Intel, Toshiba or Sandisk (avoid Sandisks btw)). > And I observe a problem very often: gstat shows 20-30% of disk load, but > the system reacts very slowly: cloning a dataset takes 10 seconds, > similar operations aren't lightspeeding too. To my knowledge, until the > disks are 90-100% busy, this shouldn't happen. My systems are equipped > with 32-64 gigs of RAM, and the only tuning I use is limiting the ARC > size (in a very tender manner - at least to 16 gigs) and playing with > TRIM. The number of datasets is high enough - hundreds of clones, dozens > of snapshots, most of teh data ovjects are zvols. Pools aren't > overfilled, most are filled up to 60-70% (no questions about low space > pools, but even in this case the situation is clearer - %busy goes up in > the sky). > > So, my question is - is there some obvious zfs tuning not mentioned in > the Handbook ? On the other side - handbook isn't much clear on how to > tune zfs, it's written mostly in the manner of "these are sysctl iods > you can play with". Of course I have seen several ZFS tuning guides. > Like Opensolaris one, but they are mostly file- and > application-specific. Is there some special approach to tune ZFS in the > environment with loads of disks ? I don't know.... like tuning the vdev > cache or something simllar. ? > > > Thanks. > > Eugene. What version of FreeBSD are you running? What is the system doing during all this? How are your pools setup (raidz1/2/3, mirror, 3mirror)? How is your iSCSI configured and what are the clients doing with it? Is the data distributed evenly on all disks? Do the clients write a lot of sync data? I think this kind of information helps people helping you. Regards, Ronald. From owner-freebsd-stable@freebsd.org Wed Aug 2 18:07:25 2017 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 4B845DAF434 for ; Wed, 2 Aug 2017 18:07:25 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 36CCE6FB7C for ; Wed, 2 Aug 2017 18:07:25 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: by mailman.ysv.freebsd.org (Postfix) id 35EB2DAF432; Wed, 2 Aug 2017 18:07:25 +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 35736DAF431 for ; Wed, 2 Aug 2017 18:07:25 +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 7E2F56FB7A for ; Wed, 2 Aug 2017 18:07:23 +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 v72I6jon027509; Thu, 3 Aug 2017 04:06:46 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 3 Aug 2017 04:06:45 +1000 (EST) From: Ian Smith To: Daniel Braniss cc: Kevin Oberman , Karl Denninger , stable@freebsd.org Subject: Re: issues with powerd/freq_levels In-Reply-To: Message-ID: <20170803030735.N22231@sola.nimnet.asn.au> References: <8AEC9DBC-BADD-4FB2-8358-DA43F7EF5E68@cs.huji.ac.il> <20170731201323.A6737@sola.nimnet.asn.au> <20170802004343.T6737@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: Wed, 02 Aug 2017 18:07:25 -0000 On Wed, 2 Aug 2017 13:30:03 +0300, Daniel Braniss wrote: > > On 1 Aug 2017, at 20:45, Ian Smith wrote: > > > > On Mon, 31 Jul 2017 12:03:27 -0700, Kevin Oberman wrote: > >> On Mon, Jul 31, 2017 at 3:48 AM, Ian Smith wrote: > >> > >>> On Mon, 31 Jul 2017 10:09:11 +0300, Daniel Braniss wrote: > >>> > >>>> I am trying out PCengines latest apu2 boards, and I just noticed that > >>> with different Freebsd versions I get > >>>> different freq_levels, and so when idling, each box (have 5) has a > >>> different freq/temperature value, ranging > >>>> from 125/69.1C, 600/59.0C to 75/56.0C > >>>> > >>>> FreeBSD apu-4 11.1-STABLE FreeBSD 11.1-STABLE #5 f565b5a06ab3 (11) tip: > >>> Mon Jul 31 09:36:33 IDT 2017 > >>>> apu-4# sysctl dev.cpu.0.freq_levels > >>>> dev.cpu.0.freq_levels: 1000/980 800/807 600/609 > >>> > >>> That looks about right. Time to cut out lots and summarise a bit, from your dmesgs: apu-3 dmesg that you posted, presumably the same 11.1-STABLE as the apu-4 above, to within a few days, shows only: hwpstate0: on cpu0 random: harvesting attach, 8 bytes (4 bits) from cpufreq0 random: harvesting attach, 8 bytes (4 bits) from hwpstate0 Device configuration finished. Which appears to be what you want - but are you seeing the hwpstate errors from powerd that Karl commented on? > >>> hint.p4tcc.0.disabled=1 > >>> hint.acpi_throttle.0.disabled=1 > >>>> FreeBSD apu-5 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #0 21e9d1ca9b80 > >>> (11) tip: Tue May 30 11:51:48 IDT 2017 > >>>> apu-5# sysctl dev.cpu.0.freq_levels > >>>> dev.cpu.0.freq_levels: 1000/966 875/845 800/795 700/695 600/600 525/525 > >>> 450/450 375/375 300/300 225/225 150/150 75/75 > >>> > >>> Looks like either p4tcc or acpi_throttle is enabled? See cpufreq(4). hwpstate0: on cpu0 random: harvesting attach, 8 bytes (4 bits) from hwpstate0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 acpi_throttle2: on cpu2 acpi_throttle2: failed to attach P_CNT device_attach: acpi_throttle2 attach returned 6 acpi_throttle3: on cpu3 acpi_throttle3: failed to attach P_CNT device_attach: acpi_throttle3 attach returned 6 Device configuration finished. So it's loaded hwpstate(0) but only apparently successfully attached to cpu0, and failed to attach acpi_throttle to cpus 1-3, yet the cpu0 freq_levels are those of your 3 real freqs (1000, 800, 600) times all x/8 factors. So that one may not have hint.acpi_throttle.0.disabled=1? > >>>> FreeBSD apu-1 10.3-STABLE FreeBSD 10.3-STABLE #4 267788fd852c (10) tip: > >>> Tue Jan 10 09:09:00 IST 2017 > >>>> apu-1# sysctl dev.cpu.0.freq_levels > >>>> dev.cpu.0.freq_levels: 1000/-1 875/-1 750/-1 625/-1 500/-1 375/-1 > >>> 250/-1 125/-1 > >>> > >>> And that looks like est(4) isn't enabled/attaching at all .. see dmesg > >>> on all of these for clues. This is a different board entirely. Different CPU, L2 unified cache, ethernet devices (Realtek vs Intel), less memory (4G vs 4.5G) and 2 vs 4 CPUs (unless HT is off on this and on on the others?), SATA-2 vs SATA-3 on ada0, only USB2 vs some USB3 (XHCI), and a different cpufreq setup again .. no sign of hwpstate and: acpi_throttle0: on cpu0 acpi_throttle0: P_CNT from P_BLK 0x810 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 Device configuration finished. Sounds like a bogon must have found its way into your batch? > > Danny, can you put up a verbose boot dmesg.boot of one(?) for a browse? > > Or maybe apu-4 and -1, if not all. I'd expect error msgs on -1 anyway. > they are now available at: > http://www.cs.huji.ac.il/~danny/pcengines/ Thanks, that made it all pretty clear. Not that I know much about lots of this stuff, especially nowadays, but some things stuck out. Kevin wrote: > >> Temperature is a totally separate issue. It is VERY sensitive to external > >> issue like airflow and position of the CPU in relation to other components > >> in the chassis Also, unless you have a lot of cores, you probably should > >> set both economy_cx_lowest and performance_cx_lowest to Cmax. Economy > >> should default to that, but performance will not as that can cause issues > >> on systems with large numbers of cores, so is set to C2. Many such system > >> used to disable deeper sleep modes in BIOS, but I am way behind the times > >> and don't know about the current state of affairs. Certainly for systems > >> with 32 or fewer cores, this should not be an issue. In any case, Cx state > >> can sharply impact temperature. > > > > Indeed. But as these are low-power devices already, it's likely less of > > a concern, but maximising efficiency and minimising stress never hurts. Yes, it might be helpful to see Danny's version of the data Karl showed: $ sysctl -a|grep cpu.0 $ sysctl -a|grep cx on an 11.1-STABLE one at least. In fact Karl's 59.2C temperature (at 1000MHz, perhaps only momentarily as 'sysctl -a' has powerd take my older box to 1133) ~matches Danny's. > > Danny, is powerd running on all these? I doubt it would load on apu-1 > > as it stands. > > it is working on the apu-1! Ok, but using bogus x/8 clock multipliers of 1000MHz. But I expect you'll be wanting to exchange that box for one of the others anyway? Is it working on the others? Does it actually idle at 600MHz? If in doubt, running 'powerd -v' for a while will show you what's happening. Despite being low power, running slower when more or less idle - along with hopefully getting to use C2 state - should cool these down a lot. Perhaps there were hwpstate and/or cpufreq updates between 11.1-PRE and -STABLE? Any deeper out of my depth and I mightn't come up for air! cheers, Ian From owner-freebsd-stable@freebsd.org Wed Aug 2 18:14:57 2017 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 D1A0EDAFCA7 for ; Wed, 2 Aug 2017 18:14:57 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [67.205.158.196]) by mx1.freebsd.org (Postfix) with ESMTP id AA03270417 for ; Wed, 2 Aug 2017 18:14:56 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197]) by colo1.denninger.net (Postfix) with ESMTP id 002EB2737D for ; Wed, 2 Aug 2017 14:14:51 -0400 (EDT) Received: from [192.168.10.20] (D10.Denninger.Net [192.168.10.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 389E83306B for ; Wed, 2 Aug 2017 13:14:50 -0500 (CDT) Subject: Re: issues with powerd/freq_levels To: freebsd-stable@freebsd.org References: <8AEC9DBC-BADD-4FB2-8358-DA43F7EF5E68@cs.huji.ac.il> <20170731201323.A6737@sola.nimnet.asn.au> <20170802004343.T6737@sola.nimnet.asn.au> <20170803030735.N22231@sola.nimnet.asn.au> From: Karl Denninger Message-ID: Date: Wed, 2 Aug 2017 13:14:47 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170803030735.N22231@sola.nimnet.asn.au> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms000407020203010006000003" 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 Aug 2017 18:14:57 -0000 This is a cryptographically signed message in MIME format. --------------ms000407020203010006000003 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 8/2/2017 13:06, Ian Smith wrote: > Is it working on the others? Does it actually idle at 600MHz? If in=20 > doubt, running 'powerd -v' for a while will show you what's happening. = =20 > Despite being low power, running slower when more or less idle - along = > with hopefully getting to use C2 state - should cool these down a lot. > Yes. "powerd -v" sez (once it gets going) load 3%, current freq 600 MHz ( 2), wanted freq 600 MHz load 6%, current freq 600 MHz ( 2), wanted freq 600 MHz load 0%, current freq 600 MHz ( 2), wanted freq 600 MHz load 0%, current freq 600 MHz ( 2), wanted freq 600 MHz load 0%, current freq 600 MHz ( 2), wanted freq 600 MHz load 8%, current freq 600 MHz ( 2), wanted freq 600 MHz load 4%, current freq 600 MHz ( 2), wanted freq 600 MHz load 3%, current freq 600 MHz ( 2), wanted freq 600 MHz load 4%, current freq 600 MHz ( 2), wanted freq 600 MHz load 0%, current freq 600 MHz ( 2), wanted freq 600 MHz load 14%, current freq 600 MHz ( 2), wanted freq 600 MHz dev.cpu.3.temperature: 58.5C dev.cpu.2.temperature: 58.5C dev.cpu.1.temperature: 58.5C dev.cpu.0.temperature: 58.5C --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms000407020203010006000003 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA4MDIxODE0NDdaME8GCSqGSIb3DQEJBDFCBEDf4Dnf 5cS+HuNKCXOnfEv22DThj1Ev2pO3v/WEQYHCRsHbc6Q91j+QyDwFQmyvcKCQjALbOp1+QTyD TJLC4dz+MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAdSlD9BJIezQD uhbDnjcHFVkzIiOMFSHwkhjj3fX4Z0QZShM9JB1YHu45ZausAVegRoQlz2/A1SsEOBxENx8o gkGRXaecReIkff3NT55+XqBGjN1oJ5SJJgTaW2cJrzW5x5XIftjc+m5YEIhiObu5M1eWDZ1A AK4MLaUtYzo0T3UNUcqYtT6A3p91Hr1ue1Sc4CMx9NAuxYsb37eVqEFKma5pZaq8833OeKBc h9Bv5MtXmRFiCWez7UaImuEuH5Vg3uDr60JYT9OFIwqUvTMcXmEO6zGvuvNXD2KSOS2szd4r 4x6JUp2uNj6ZeqQ0y/EyqQKt2U/w6K5hZoe4nmGfZ8oArXOGsva/1hV0Y/RnDRubBv8raLml mSF74CNWD004j/Eh781SQ2RbGXkuz+9QWthxSNvkVWl6DKjZcZBGGDbn5tRxhSdXWuC5eyXz vFoMN0jvh/qw1WRKHRSbD3Vc3i/78M/hY2V/ScD3qYQgwpKNuDXfLHiFm59lHSlWQvNEJW/C oSaPt31AuErl5ou2VSMhEv2kxMvsmTz5AKxTlT9/TKrXzpO17oLd5C8TFq73neIaR5o2bHDR es1+Z2bUG7Bp8gcKTNUJ3LlkIjmlApnXybcQEYy5cb+x9WxhiA/ivuLgtkJaivtE8KG0KaNW sALLhUpWGRA+Wh9AHGHbxkgAAAAAAAA= --------------ms000407020203010006000003-- From owner-freebsd-stable@freebsd.org Thu Aug 3 08:45:54 2017 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 930E3DD13C3; Thu, 3 Aug 2017 08:45:54 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norma.perm.ru [IPv6:2a00:7540:1::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.norma.perm.ru", Issuer "Vivat-Trade UNIX Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 155876D9B3; Thu, 3 Aug 2017 08:45:53 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from bsdrookie.norma.com. (net206-94.perm.ertelecom.ru [46.146.206.94] (may be forged)) by elf.hq.norma.perm.ru (8.15.2/8.15.2) with ESMTPS id v738jgWe083065 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 3 Aug 2017 13:45:43 +0500 (YEKT) (envelope-from emz@norma.perm.ru) Subject: Re: some general zfs tuning (for iSCSI) To: freebsd-fs@freebsd.org Cc: freebsd-stable References: <8b41e7d6-7a2c-d456-2eee-93efd81aa86a@norma.perm.ru> From: "Eugene M. Zheganin" Message-ID: Date: Thu, 3 Aug 2017 13:45:42 +0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spamd-Result: default: False [1.50 / 25.00] BAYES_HAM(-3.00)[100.00%] RBL_SPAMHAUS_PBL(2.00)[94.206.146.46.zen.spamhaus.org : 127.0.0.10] HFILTER_HOSTNAME_UNKNOWN(2.50)[] DMARC_NA(0.00)[norma.perm.ru] MIME_GOOD(-0.10)[text/plain] R_DKIM_NA(0.00)[] R_SPF_SOFTFAIL(0.00)[~all] MID_RHS_MATCH_FROM(0.00)[] RECEIVED_SPAMHAUS(0.00)[94.206.146.46.zen.spamhaus.org] TO_DN_SOME(0.00)[] RCPT_COUNT_2(0.00)[] TO_MATCH_ENVRCPT_ALL(0.00)[] FROM_HAS_DN(0.00)[] FROM_EQ_ENVFROM(0.00)[] RCVD_COUNT_1(0.00)[] ONCE_RECEIVED(0.10)[] X-Rspamd-Server: localhost X-Rspamd-Scan-Time: 1.40 X-Rspamd-Queue-ID: v738jgWe083065 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 Aug 2017 08:45:54 -0000 Hi. On 02.08.2017 17:43, Ronald Klop wrote: > On Fri, 28 Jul 2017 12:56:11 +0200, Eugene M. Zheganin > wrote: > >> Hi, >> >> >> I'm using several FreeBSD zfs installations as the iSCSI production >> systems, they basically consist of an LSI HBA, and a JBOD with a >> bunch of SSD disks (12-24, Intel, Toshiba or Sandisk (avoid Sandisks >> btw)). And I observe a problem very often: gstat shows 20-30% of disk >> load, but the system reacts very slowly: cloning a dataset takes 10 >> seconds, similar operations aren't lightspeeding too. To my >> knowledge, until the disks are 90-100% busy, this shouldn't happen. >> My systems are equipped with 32-64 gigs of RAM, and the only tuning I >> use is limiting the ARC size (in a very tender manner - at least to >> 16 gigs) and playing with TRIM. The number of datasets is high enough >> - hundreds of clones, dozens of snapshots, most of teh data ovjects >> are zvols. Pools aren't overfilled, most are filled up to 60-70% (no >> questions about low space pools, but even in this case the situation >> is clearer - %busy goes up in the sky). >> >> So, my question is - is there some obvious zfs tuning not mentioned >> in the Handbook ? On the other side - handbook isn't much clear on >> how to tune zfs, it's written mostly in the manner of "these are >> sysctl iods you can play with". Of course I have seen several ZFS >> tuning guides. Like Opensolaris one, but they are mostly file- and >> application-specific. Is there some special approach to tune ZFS in >> the environment with loads of disks ? I don't know.... like tuning >> the vdev cache or something simllar. ? >> >> > > What version of FreeBSD are you running? Well, different ones. Mostly some versions of 11.0-RELEASE-pX and 11-STABLE. > What is the system doing during all this? What do you meant by "what" ? Nothing else except serving iSCSI - it's the main purpose of every one of these servers. > How are your pools setup (raidz1/2/3, mirror, 3mirror)? zroot is a mirrored two-disk pool, others are raidz, mostly spans of multiple 5-disk radizs. > How is your iSCSI configured and what are the clients doing with it? Using the kernel ctld of course. As you may know ctl.conf dosn't suppose any performance tweaks, it's just a way of organizing the authorization layer. Clients are the VMWare ESX hypervisors, using iSCSI as disk devices, as for ESX SRs, and as direct iSCSI disks in Windows VMs. > Is the data distributed evenly on all disks? It's not. Does it ever ditrubute evenly anywhere ? > Do the clients write a lot of sync data? What do you exactly mean by "sync data" ? Eugene. From owner-freebsd-stable@freebsd.org Thu Aug 3 08:54:59 2017 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 4EEA1DD1A45 for ; Thu, 3 Aug 2017 08:54:59 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norma.perm.ru [IPv6:2a00:7540:1::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.norma.perm.ru", Issuer "Vivat-Trade UNIX Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C45896E0C3 for ; Thu, 3 Aug 2017 08:54:58 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from bsdrookie.norma.com. (net206-94.perm.ertelecom.ru [46.146.206.94] (may be forged)) by elf.hq.norma.perm.ru (8.15.2/8.15.2) with ESMTPS id v738soVu083466 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 3 Aug 2017 13:54:50 +0500 (YEKT) (envelope-from emz@norma.perm.ru) To: freebsd-stable@FreeBSD.org From: "Eugene M. Zheganin" Subject: panic: dva_get_dsize_sync(): bad DVA on 2016 11-STABLE. Message-ID: <392341d5-3bdc-cf18-6dcc-6e5f07f8e3df@norma.perm.ru> Date: Thu, 3 Aug 2017 13:54:50 +0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spamd-Result: default: False [1.50 / 25.00] RBL_SPAMHAUS_PBL(2.00)[94.206.146.46.zen.spamhaus.org : 127.0.0.10] HFILTER_HOSTNAME_UNKNOWN(2.50)[] BAYES_HAM(-3.00)[99.99%] DMARC_NA(0.00)[norma.perm.ru] MIME_GOOD(-0.10)[text/plain] R_DKIM_NA(0.00)[] R_SPF_SOFTFAIL(0.00)[~all] RCPT_COUNT_1(0.00)[] MID_RHS_MATCH_FROM(0.00)[] RECEIVED_SPAMHAUS(0.00)[94.206.146.46.zen.spamhaus.org] TO_MATCH_ENVRCPT_ALL(0.00)[] FROM_HAS_DN(0.00)[] TO_DN_NONE(0.00)[] FROM_EQ_ENVFROM(0.00)[] RCVD_COUNT_1(0.00)[] ONCE_RECEIVED(0.10)[] X-Rspamd-Server: localhost X-Rspamd-Scan-Time: 5.11 X-Rspamd-Queue-ID: v738soVu083466 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 Aug 2017 08:54:59 -0000 Hi, today I got the following panic on the December 2016 11-STABLE: FreeBSD san02.playkey.net 11.0-STABLE FreeBSD 11.0-STABLE #0 r310734M: Thu Dec 29 19:22:30 UTC 2016 emz@san02:/usr/obj/usr/src/sys/GENERIC amd64 panic: dva_get_dsize_sync(): bad DVA 4294967295:2086400 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: panic: dva_get_dsize_sync(): bad DVA 4294967295:2086400 cpuid = 2 KDB: stack backtrace: #0 0xffffffff80b023a7 at kdb_backtrace+0x67 #1 0xffffffff80ab88e6 at vpanic+0x186 #2 0xffffffff80ab8753 at panic+0x43 #3 0xffffffff8226a148 at bp_get_dsize+0x128 #4 0xffffffff8222cc29 at dmu_tx_count_write+0x589 #5 0xffffffff8222c675 at dmu_tx_hold_write+0x35 #6 0xffffffff822c573e at zvol_strategy+0x21e #7 0xffffffff809f6a10 at g_io_request+0x4a0 #8 0xffffffff8283a45f at ctl_be_block_dispatch_dev+0x20f #9 0xffffffff8283bddc at ctl_be_block_worker+0x6c #10 0xffffffff80b1484a at taskqueue_run_locked+0x14a #11 0xffffffff80b15a38 at taskqueue_thread_loop+0xe8 #12 0xffffffff80a70785 at fork_exit+0x85 #13 0xffffffff80f55f2e at fork_trampoline+0xe Uptime: 78d7h43m31s My question is (since I din't find much on this) what does this "bad DVA" mean ? I've read that this may indicate the on-disk zfs corrupton, but I'm not suer about it. Is this fixable in any way ? Do I have to prepare to recreate the pool (btw I have three pools) from scratch, and how do I determine which one has the corruption. Some [useless ?] zfs info: # zpool status pool: data state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM data ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 da2 ONLINE 0 0 0 da3 ONLINE 0 0 0 da4 ONLINE 0 0 0 da5 ONLINE 0 0 0 raidz1-1 ONLINE 0 0 0 da6 ONLINE 0 0 0 da7 ONLINE 0 0 0 da8 ONLINE 0 0 0 da9 ONLINE 0 0 0 raidz1-2 ONLINE 0 0 0 da10 ONLINE 0 0 0 da11 ONLINE 0 0 0 da12 ONLINE 0 0 0 da13 ONLINE 0 0 0 raidz1-3 ONLINE 0 0 0 da14 ONLINE 0 0 0 da15 ONLINE 0 0 0 da16 ONLINE 0 0 0 da17 ONLINE 0 0 0 errors: No known data errors pool: userdata state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM userdata ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/userdata0 ONLINE 0 0 0 gpt/userdata1 ONLINE 0 0 0 errors: No known data errors pool: zroot state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/zroot0 ONLINE 0 0 0 gpt/zroot1 ONLINE 0 0 0 errors: No known data errors Hardware: # camcontrol devlist at scbus4 target 0 lun 0 (pass0,ses0) at scbus11 target 0 lun 0 (pass1,ses1) at scbus12 target 4 lun 0 (pass2,da0) at scbus12 target 5 lun 0 (pass3,da1) at scbus12 target 8 lun 0 (pass4,da2) at scbus12 target 9 lun 0 (pass5,da3) at scbus12 target 10 lun 0 (pass6,da4) at scbus12 target 11 lun 0 (pass7,da5) at scbus12 target 12 lun 0 (pass8,da6) at scbus12 target 13 lun 0 (pass9,da7) at scbus12 target 14 lun 0 (pass10,da8) at scbus12 target 15 lun 0 (pass11,da9) at scbus12 target 16 lun 0 (pass12,da10) at scbus12 target 17 lun 0 (pass13,da11) at scbus12 target 18 lun 0 (pass14,da12) at scbus12 target 19 lun 0 (pass15,da13) at scbus12 target 20 lun 0 (pass16,da14) at scbus12 target 21 lun 0 (pass17,da15) at scbus12 target 22 lun 0 (pass18,da16) at scbus12 target 23 lun 0 (pass19,da17) at scbus12 target 24 lun 0 (pass20,da18) at scbus12 target 32 lun 0 (pass21,ses2) I also have the zdb -uuumdC for each pool, here they are in case someone needs them: https://enaza.ru/stub-data/zdb-uuumdC-data.txt https://enaza.ru/stub-data/zdb-uuumdC-userdata.txt https://enaza.ru/stub-data/zdb-uuumdC-zroot.txt Thanks. Eugene. From owner-freebsd-stable@freebsd.org Thu Aug 3 20:50:19 2017 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 117FDDD2985 for ; Thu, 3 Aug 2017 20:50:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EE2026A5C9 for ; Thu, 3 Aug 2017 20:50:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v73KoI2k006047 for ; Thu, 3 Aug 2017 20:50:18 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 221146] [LAGG] Problem with second laggport Date: Thu, 03 Aug 2017 20:50:19 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: erj@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-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 Aug 2017 20:50:19 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221146 --- Comment #7 from Eric Joyner --- Do we know who to assign this to, then? If it is actually a lagg problem and not a driver-specific one. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Thu Aug 3 21:01:23 2017 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 65843DD3198 for ; Thu, 3 Aug 2017 21:01:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 540776AD08 for ; Thu, 3 Aug 2017 21:01:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v73L1MpN093319 for ; Thu, 3 Aug 2017 21:01:23 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 221146] [LAGG] Problem with second laggport Date: Thu, 03 Aug 2017 21:01:22 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: peixoto.cassiano@gmail.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-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 Aug 2017 21:01:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221146 --- Comment #8 from Cassiano Peixoto --- (In reply to Eric Joyner from comment #7) So should i open a new PR related to driver update problem and netmap? --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Fri Aug 4 10:45:48 2017 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 A0814DD28EF for ; Fri, 4 Aug 2017 10:45:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8EC4D3D47 for ; Fri, 4 Aug 2017 10:45:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v74AjmxS097958 for ; Fri, 4 Aug 2017 10:45:48 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 221146] [LAGG] Problem with second laggport Date: Fri, 04 Aug 2017 10:45:48 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: konrad.kreciwilk@korbank.pl X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-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 Aug 2017 10:45:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221146 --- Comment #9 from Konrad --- I set LAGG on igb0 and igb1 and seems to be ok: lagg0: flags=3D8843 metric 0 mtu 15= 00 =20=20=20=20=20=20=20 options=3D6403bb ether 00:1e:67:27:1d:5e inet 192.168.202.254 netmask 0xffffff00 broadcast 192.168.202.255=20 nd6 options=3D29 media: Ethernet autoselect status: active groups: lagg=20 laggproto lacp lagghash l2,l3,l4 laggport: igb0 flags=3D1c laggport: igb1 flags=3D1c lagg1: flags=3D8843 metric 0 mtu 15= 00 =20=20=20=20=20=20=20 options=3De400bb ether 0c:c4:7a:bd:65:58 inet 192.168.202.254 netmask 0xffffff00 broadcast 192.168.202.255=20 nd6 options=3D29 media: Ethernet autoselect status: active groups: lagg=20 laggproto lacp lagghash l2,l3,l4 laggport: ix0 flags=3D1c laggport: ix1 flags=3D1c but when ix's ports are configured as lagg1, all laggports work properly. W= hen I switch ix's ports as lagg0 and first in cloned_interfaces the problem appears: lagg0: flags=3D8843 metric 0 mtu 15= 00 =20=20=20=20=20=20=20 options=3De400bb ether 0c:c4:7a:bd:65:58 inet 192.168.202.254 netmask 0xffffff00 broadcast 192.168.202.255=20 nd6 options=3D29 media: Ethernet autoselect status: active groups: lagg=20 laggproto lacp lagghash l2,l3,l4 laggport: ix0 flags=3D1c laggport: ix1 flags=3D0<> lagg1: flags=3D8843 metric 0 mtu 15= 00 =20=20=20=20=20=20=20 options=3D6403bb ether 00:1e:67:27:1d:5e inet 192.168.202.254 netmask 0xffffff00 broadcast 192.168.202.255=20 nd6 options=3D29 media: Ethernet autoselect status: active groups: lagg=20 laggproto lacp lagghash l2,l3,l4 laggport: igb0 flags=3D1c laggport: igb1 flags=3D1c --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Fri Aug 4 11:26:19 2017 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 1C97CDD432B for ; Fri, 4 Aug 2017 11:26:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0B780645A1 for ; Fri, 4 Aug 2017 11:26:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v74BQIav021690 for ; Fri, 4 Aug 2017 11:26:18 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 221146] [LAGG] Problem with second laggport Date: Fri, 04 Aug 2017 11:26:19 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-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 Aug 2017 11:26:19 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221146 --- Comment #10 from Andrey V. Elsukov --- (In reply to Konrad from comment #9) > I set LAGG on igb0 and igb1 and seems to be ok: > but when ix's ports are configured as lagg1, all laggports work properly. > When I switch ix's ports as lagg0 and first in cloned_interfaces the > problem appears: Is it reproducible? Are you doing this in runtime manually without reboot? --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Fri Aug 4 11:49:14 2017 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 1E931DD531E for ; Fri, 4 Aug 2017 11:49:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0CFAB650D4 for ; Fri, 4 Aug 2017 11:49:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v74BnCuO079429 for ; Fri, 4 Aug 2017 11:49:13 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 221146] [LAGG] Problem with second laggport Date: Fri, 04 Aug 2017 11:49:13 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: konrad.kreciwilk@korbank.pl X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-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 Aug 2017 11:49:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221146 --- Comment #11 from Konrad --- Yes, its reproducible. I change lagg configuration in rc.conf and reboot machine. if lagg0 will start with "ix1 flags=3D0" ix1 will have always "no carrier" = even if I remove from laggport. Manually removed ix1 and netif restart does no f= ix the problem (ix1 still has "no carrier"), only reboot. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Fri Aug 4 16:25:21 2017 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 93F6CDBCFE9 for ; Fri, 4 Aug 2017 16:25:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 822EA6EAF2 for ; Fri, 4 Aug 2017 16:25:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v74GPInh067027 for ; Fri, 4 Aug 2017 16:25:21 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 221146] [LAGG] Problem with second laggport Date: Fri, 04 Aug 2017 16:25:18 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mjoras@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-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 Aug 2017 16:25:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221146 Matt Joras changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mjoras@freebsd.org --- Comment #12 from Matt Joras --- Does this only happen with LACP or does it happen with any lagg type (e.g. failover)? --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Sat Aug 5 01:10:50 2017 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 74287DD2DAE for ; Sat, 5 Aug 2017 01:10:50 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::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 3FA6B82BB1; Sat, 5 Aug 2017 01:10:50 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-pg0-x22d.google.com with SMTP id v77so13758646pgb.3; Fri, 04 Aug 2017 18:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=Q+60JO5B4BvmrUDBtCuY4GfJiUn3pZtQTX7yZvhYdvM=; b=O50f8U/9CKeP9UCWweUA/CWAyVqZcClhqWIe3UVH7LxRhM78VmKlzRZnBgeQTmf3m1 VuDDxBKvXO+ATthuLQvlb/Sg4gdprsSsmi2kkW2Q/nX2tzOnNAVFOZCjB16Hx+XTa9n5 eNKoonSj3KHPw45tOLK2cd3ntaDoteIchG97TAH+B/9NpFCipNFqGSjotUB5IZPDqsA+ +lRuWq13JGEtRqrMFNGO3HyQuNsHLcJc7ouSA5xKHXB0w9oEkxEmCCN5C+VvKfg6er2F ebnqPolE9OFv9SQciO9ElBd2p79LQnu/1ZF9O9vKgFtKm9BJw2Fqy2CAGqymLK7AVYt5 lbxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=Q+60JO5B4BvmrUDBtCuY4GfJiUn3pZtQTX7yZvhYdvM=; b=aYSVTSOuQnn1f05ufjZCrToiaVWtLPwVRVJRRnKP6Y7jwwLiIkLP5yK3bOM3elmayc Ihe0hR4b+sRjtozy7Ric/+bMlAIFgUUhbCQBrAFgVFNFkKvzQg3fmUbQZ7r1bmLuglyz gSYdVTvIfDUJWW/tFgGW+ULvSkEBwHlepVQa9BKijYkaMUWebUc1hf4s2lH+gMuw8Xuq C2kmvTF7oCjttVQGu/9F1cBK9ZYJnBTh53VnJksU13roPu520mxiAm9QBxejO+4CHIIG yWqRL++t9hEBHHJOn4Lu3bARZ8uNrpSnKcXHUpbmL8sRRaokqWR9Qg8aQk8vONylynlj lfuw== X-Gm-Message-State: AIVw112hYYsjw0yigDF94AK2I1HRSOBqtLBOGg5wrk8clk9F0AAQNYts L8PLbTuqpJHbG7csgOchs8bSJnx8kWItIOQ= X-Received: by 10.84.128.14 with SMTP id 14mr4954470pla.285.1501895448942; Fri, 04 Aug 2017 18:10:48 -0700 (PDT) MIME-Version: 1.0 Sender: kob6558@gmail.com Received: by 10.100.165.42 with HTTP; Fri, 4 Aug 2017 18:10:48 -0700 (PDT) From: Kevin Oberman Date: Fri, 4 Aug 2017 18:10:48 -0700 X-Google-Sender-Auth: nriiKXzCH1VWyVHB3KaU3yjw5qQ Message-ID: Subject: Program crashes after 320666 To: FreeBSD-STABLE Mailing List , Konstantin Belousov 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: Sat, 05 Aug 2017 01:10:50 -0000 multimedia/avidemux_qt4 has started dumping core with segfaults and other errors in libthread called from Qt4. I am suspicious that the real problem is in Qt4 and those errors were previously not detected and usually not causing a problem. The problem shows up with kernels at r320666 and later. The update on July 5 was: Add MAP_GUARD and use it for stack protection. Should I open a ticket for the Qt4 or should I spend more effort on whether it might be a kernel issue. (Pretty sure it's Qt4 at fault.) I might also look into updating the port to use Qr5 as Qt4 is clearly starting to bitrot and support for Qt5 has already been added upstream. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 From owner-freebsd-stable@freebsd.org Sat Aug 5 09:54:54 2017 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 C847FDCAB8A for ; Sat, 5 Aug 2017 09:54:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 45EC06E854 for ; Sat, 5 Aug 2017 09:54:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v759snhD064090 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 5 Aug 2017 12:54:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v759snhD064090 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v759snds064089; Sat, 5 Aug 2017 12:54:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 5 Aug 2017 12:54:49 +0300 From: Konstantin Belousov To: Kevin Oberman Cc: FreeBSD-STABLE Mailing List Subject: Re: Program crashes after 320666 Message-ID: <20170805095449.GY1700@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) 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: Sat, 05 Aug 2017 09:54:54 -0000 On Fri, Aug 04, 2017 at 06:10:48PM -0700, Kevin Oberman wrote: > multimedia/avidemux_qt4 has started dumping core with segfaults and other > errors in libthread called from Qt4. I am suspicious that the real problem > is in Qt4 and those errors were previously not detected and usually not > causing a problem. > > The problem shows up with kernels at r320666 and later. The update on July > 5 was: > Add MAP_GUARD and use it for stack protection. So the same userspace and application binaries on pre-r320666 works fine, am I right ? > > Should I open a ticket for the Qt4 or should I spend more effort on whether > it might be a kernel issue. (Pretty sure it's Qt4 at fault.) I might also > look into updating the port to use Qr5 as Qt4 is clearly starting to bitrot > and support for Qt5 has already been added upstream. Regardless of tickets, the only way to know what is going on is to debug the app. Build everything with the debug symbols, crash it under debugger control and obtain - backtraces of all threads - content of registers of the faulted thread - disassembly of the function which faulted - memory map of the application From owner-freebsd-stable@freebsd.org Sat Aug 5 17:09:14 2017 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 D9B6EDBEA15; Sat, 5 Aug 2017 17:09:14 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norma.perm.ru [IPv6:2a00:7540:1::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.norma.perm.ru", Issuer "Vivat-Trade UNIX Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A974803B1; Sat, 5 Aug 2017 17:09:13 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from [IPv6:2a02:2698:26:9b0e:d7a:6d28:b07e:5ba6] (dynamic-2a02-2698-26-0-0.perm.ertelecom.ru [IPv6:2a02:2698:26:9b0e:d7a:6d28:b07e:5ba6] (may be forged)) (authenticated bits=0) by elf.hq.norma.perm.ru (8.15.2/8.15.2) with ESMTPSA id v75H98jY007140 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 5 Aug 2017 22:09:09 +0500 (YEKT) (envelope-from emz@norma.perm.ru) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=norma.perm.ru; s=key; t=1501952949; bh=9rFsB6tx5omdomCj49fVy8H9H3xUovof3EKN1OS6VfE=; h=To:Cc:From:Subject:Date; b=Ehb/WDtHVBwMjIZN6CeA32kP/pn804AMyz1iowH0oyuqiuLu4Jv6imnQQEPQXEJWN beNvNmM/pSdDNoDTYt7H3+390FqVWRXWvuIA7QaqFYJJl599rlfNaZQ/76TxLQH9mD aAeyCEAcPLzD71CWaAOnjmv3QPHjSwYQmkTWOtk4= To: freebsd-stable@FreeBSD.org Cc: freebsd-fs@freebsd.org From: "Eugene M. Zheganin" Subject: a strange and terrible saga of the cursed iSCSI ZFS SAN Message-ID: <1bd10b1e-0583-6f44-297e-3147f6daddc5@norma.perm.ru> Date: Sat, 5 Aug 2017 22:08:54 +0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB 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 Aug 2017 17:09:15 -0000 Hi, I got a problem that I cannot solve just by myself. I have a iSCSI zfs SAN system that crashes, corrupting it's data. I'll be short, and try to describe it's genesis shortly: 1) autumn 2016, SAN is set up, supermicro server, external JBOD, sandisk ssds, several redundant pools, FreeBSD 11.x (probably release, don't really remember - see below). 2) this is working just fine until early spring 2017 3) system starts to crash (various panics): panic: general protection fault panic: page fault panic: Solaris(panic): zfs: allocating allocated segment(offset=6599069589504 size=81920) panic: page fault panic: page fault panic: Solaris(panic): zfs: allocating allocated segment(offset=8245779054592 size=8192) panic: page fault panic: page fault panic: page fault panic: Solaris(panic): zfs: allocating allocated segment(offset=1792100934656 size=46080) 4) we memtested it immidiately, no problems found. 5) we switch sandisks to toshibas, we switch also the server to an identical one, JBOD to an identical one, leaving same cables. 6) crashes don't stop. 7) we found that field engineers physically damaged (sic!) the SATA cables (main one and spare ones), and that 90% of the disks show ICRC SMART errors. 8) we replaced the cable (brand new HP one). 9) ATA SMART errors stopped increasing. 10) crashes continue. 11) we decided that probably when ZFS was moved over damaged cables between JBODs it was somehow damaged too, so now it's panicking because of that. so we wiped the data completely, reinitialized the SAN system and put it back into the production. we even dd'ed each disk with zeroes (!) - just in case. Important note: the data was imported using zfs send from another, stable system that is runing in production in another DC. 12) today we got another panic. btw the pools look now like this: # zpool status -v pool: data state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://illumos.org/msg/ZFS-8000-8A scan: none requested config: NAME STATE READ WRITE CKSUM data ONLINE 0 0 62 raidz1-0 ONLINE 0 0 0 da2 ONLINE 0 0 0 da3 ONLINE 0 0 0 da4 ONLINE 0 0 0 da5 ONLINE 0 0 0 da6 ONLINE 0 0 0 raidz1-1 ONLINE 0 0 0 da7 ONLINE 0 0 0 da8 ONLINE 0 0 0 da9 ONLINE 0 0 0 da10 ONLINE 0 0 0 da11 ONLINE 0 0 0 raidz1-2 ONLINE 0 0 62 da12 ONLINE 0 0 0 da13 ONLINE 0 0 0 da14 ONLINE 0 0 0 da15 ONLINE 0 0 0 da16 ONLINE 0 0 0 errors: Permanent errors have been detected in the following files: data/userdata/worker208:<0x1> pool: userdata state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://illumos.org/msg/ZFS-8000-8A scan: none requested config: NAME STATE READ WRITE CKSUM userdata ONLINE 0 0 216K mirror-0 ONLINE 0 0 432K gpt/userdata0 ONLINE 0 0 432K gpt/userdata1 ONLINE 0 0 432K errors: Permanent errors have been detected in the following files: userdata/worker36:<0x1> userdata/worker30:<0x1> userdata/worker31:<0x1> userdata/worker35:<0x1> 12) somewhere between p.5 and p.10 the pool became deduplicated (not directly connected to the problem, just for production reasons). So, concluding: we had bad hardware, we replaced EACH piece (server, adapter, JBOD, cable, disks), and crashes just don't stop. We have 5 another iSCSI SAN systems, almost fully identical that don't crash. Crashes on this particular system began when it was running same set of versions that stable systems. So, besides calling an exorcist, I would like to hear what other options do I have, I really would. And I want to also ask - what happens when the system's memory isn't enough for deduplication - does it crash, or does the problem of mounting the pool appear, like some articles mention ? This message could been encumbered by junky data like the exact FreeBSD releases we ran (asuuming it's normal for some 11.x revisions to crash and damage the data, and some - not, which I believe it's a nonsense), by the pool configurations and disk lists (assuming the same - that you can provoque data loss by some redundant pool configurations - not considering raidz with more than 5 disks - which I believe is not true), and so on. but I decided not to include this until requested. And as I also said, we have 5 another SAN systems running similar/identical configurations without major problems. Thanks. Eugene. From owner-freebsd-stable@freebsd.org Sat Aug 5 17:17:09 2017 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 769C0DBF304; Sat, 5 Aug 2017 17:17:09 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norma.perm.ru [IPv6:2a00:7540:1::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.norma.perm.ru", Issuer "Vivat-Trade UNIX Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EA57880A1E; Sat, 5 Aug 2017 17:17:08 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from [IPv6:2a02:2698:26:9b0e:d7a:6d28:b07e:5ba6] (dynamic-2a02-2698-26-0-0.perm.ertelecom.ru [IPv6:2a02:2698:26:9b0e:d7a:6d28:b07e:5ba6] (may be forged)) (authenticated bits=0) by elf.hq.norma.perm.ru (8.15.2/8.15.2) with ESMTPSA id v75HH5Od007451 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 5 Aug 2017 22:17:05 +0500 (YEKT) (envelope-from emz@norma.perm.ru) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=norma.perm.ru; s=key; t=1501953426; bh=5Rj0MOK5Zp+fXqvmVRPQ3oiWuRY57fHpAHlIRc8XapQ=; h=Subject:From:To:Cc:References:Date:In-Reply-To; b=eAiV6zEnd35O/25aq3n+amRLkDFFOrjd7dP6+YqVz4GnUuTChRkd5V6x5aADeGqe9 S9B064BPGb0gFNwPFuTwjJD82jHrHPHJtxYIr17TYtTc4tOtgPifQuuQxPN7aK0ScU H1UykqzMMUpcXAbRCBeXrlaiszUfF5hZqXcYHOeI= Subject: Re: a strange and terrible saga of the cursed iSCSI ZFS SAN From: "Eugene M. Zheganin" To: freebsd-stable@FreeBSD.org Cc: freebsd-fs@freebsd.org References: <1bd10b1e-0583-6f44-297e-3147f6daddc5@norma.perm.ru> Message-ID: <1d53f489-5135-7633-fef4-35d26e4969dc@norma.perm.ru> Date: Sat, 5 Aug 2017 22:16:51 +0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1bd10b1e-0583-6f44-297e-3147f6daddc5@norma.perm.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB 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 Aug 2017 17:17:09 -0000 Hi, On 05.08.2017 22:08, Eugene M. Zheganin wrote: > > pool: userdata > state: ONLINE > status: One or more devices has experienced an error resulting in data > corruption. Applications may be affected. > action: Restore the file in question if possible. Otherwise restore the > entire pool from backup. > see: http://illumos.org/msg/ZFS-8000-8A > scan: none requested > config: > > NAME STATE READ WRITE CKSUM > userdata ONLINE 0 0 216K > mirror-0 ONLINE 0 0 432K > gpt/userdata0 ONLINE 0 0 432K > gpt/userdata1 ONLINE 0 0 432K That would be funny, if not that sad, but while writing this message, the pool started to look like below (I just asked zpool status twice in a row, comparing to what it was): [root@san1:~]# zpool status userdata pool: userdata state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://illumos.org/msg/ZFS-8000-8A scan: none requested config: NAME STATE READ WRITE CKSUM userdata ONLINE 0 0 728K mirror-0 ONLINE 0 0 1,42M gpt/userdata0 ONLINE 0 0 1,42M gpt/userdata1 ONLINE 0 0 1,42M errors: 4 data errors, use '-v' for a list [root@san1:~]# zpool status userdata pool: userdata state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://illumos.org/msg/ZFS-8000-8A scan: none requested config: NAME STATE READ WRITE CKSUM userdata ONLINE 0 0 730K mirror-0 ONLINE 0 0 1,43M gpt/userdata0 ONLINE 0 0 1,43M gpt/userdata1 ONLINE 0 0 1,43M errors: 4 data errors, use '-v' for a list So, you see, the error rate is like speed of light. And I'm not sure if the data access rate is that enormous, looks like they are increasing on their own. So may be someone have an idea on what this really means. Thanks. Eugene. From owner-freebsd-stable@freebsd.org Sat Aug 5 17:49:41 2017 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 0E4BADC0B7E; Sat, 5 Aug 2017 17:49:41 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BBA65818F2; Sat, 5 Aug 2017 17:49:40 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by mail-qt0-x22c.google.com with SMTP id t37so23413542qtg.5; Sat, 05 Aug 2017 10:49:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0R6LJ9fGoWE4JTkpSXDZaeltyd+X4nKwBC0ysqsqVK0=; b=Bi8oS1icEWVGaNit04OMI3AbGS2BPw3dWAjqAciodvdMn7E85C6+0w0cylbzM8aCMh dvyNFjhlUDHcjdJXvXnonI8H6N9SYS8F8/qJDDhz+nseXlitfjdK75uePGulQjgqJbJn e6JSlgX0XALN+CtHKEX3MlJy8sXhxgNWsPSH5diOsA+DppcNoBCeHJnecg8Y/AOZzPJu OGV3eiPvBVx4ERy6A86YgOwY4lxHPGdn/W2Lrn+/mdoEwQQhzfJuJa0eZUSD7BKJwR6y Lm+ChhR96o6UxmClIKY17Bik8oS+XFE0aC95QC84HQ3wz4RJoQz3dbW0zGrYtZ1TbKDG TPPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0R6LJ9fGoWE4JTkpSXDZaeltyd+X4nKwBC0ysqsqVK0=; b=mkIxkBg4TKzREANqFmOkGSc19gNYxdSUnDfmz30CuUKmxALRaNRBlWB13ThqtC1GhZ RmsQFS6kp9ArWrKd38ZugTKO2eMcAhGx/nDWMI/Ymsc0H4H8J/HSJ+pTdlO/QPxVUaFC /QbnoCjoahMcYhF3H0ehZz9DJLhr/ssikwjChCGK4Dm+H172NT3yJgYf4+qe8+z592mj 7SwmV8vm+7ZqP0iecEXX3h5gWLPKdsJscy3UlgikFs5mQMAzGS1fLjFmiixQgvekJZYr voyQtiY/HIF9SRGqq26yMfJqa4fNuW5ckMsPRgG9RDjBby7yWRuQivGvWNSRMl9waxud 1TiA== X-Gm-Message-State: AHYfb5ikPTW5AbjkGWntSB/2iBrDTJS/WM/lZuJajy+qy6HZYYbk3+9o V4xj5bmSBfIL3YGMVPTqIa8Nn77WXA== X-Received: by 10.237.42.88 with SMTP id k24mr8782754qtf.58.1501955379916; Sat, 05 Aug 2017 10:49:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.32.136 with HTTP; Sat, 5 Aug 2017 10:49:39 -0700 (PDT) Received: by 10.140.32.136 with HTTP; Sat, 5 Aug 2017 10:49:39 -0700 (PDT) In-Reply-To: References: <1bd10b1e-0583-6f44-297e-3147f6daddc5@norma.perm.ru> From: Freddie Cash Date: Sat, 5 Aug 2017 10:49:39 -0700 Message-ID: Subject: Re: a strange and terrible saga of the cursed iSCSI ZFS SAN To: "Eugene M. Zheganin" Cc: FreeBSD Stable , FreeBSD Filesystems 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: Sat, 05 Aug 2017 17:49:41 -0000 On Aug 5, 2017 10:09 AM, "Eugene M. Zheganin" wrote: And I want to also ask - what happens when the system's memory isn't enough for deduplication - does it crash, or does the problem of mounting the pool appear, like some articles mention ? Can't really help with the other issues, but can speak to this one. "Insufficient" RAM for dedupe won't be an issue during normal operation, reading and writing to the pool. Performance will slow down over time as the DDT increases in size taking up ARC/L2ARC space, possibly even spilling over into raw disk reads. Where the issues crop up is during snapshot deletion and filesystem destruction. Those operations can run the system out of usable kmem and lock things up. (Deletions cause a lot of churn in the DDT.) On reboot, the pool import process will continue the deletion process, which will run the system out of kmen locking it up. Rinse and repeat for a week until the deletion process completes. L2ARC helps, but not nearly as much as adding more RAM! Device replacement will also be an issue as the resilver process will be extremely slow (at least, it is for us with a very full, very fragmented pool; equally full pools without d we dedupe resilver very quickly). And don't try to replace two drives in separate vdevs unless you want to increase the resilver time by a huge factor. This is from experience with a 24-drive system with only 48 GB of RAM, and a 90-disk system with 128 GB of RAM. Both with dedupe enabled. Both running at about 90% full, very fragmented as they create and delete snapshots of all filesystems on a daily basis. They've been running file about 5 years now, possibly longer. Cheers, Freddie From owner-freebsd-stable@freebsd.org Sat Aug 5 17:52:35 2017 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 E991BDC1001; Sat, 5 Aug 2017 17:52:35 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.103]) (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 AE52281DA8; Sat, 5 Aug 2017 17:52:35 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [78.35.133.192] (helo=fabiankeil.de) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1de3FR-0006iJ-Oq; Sat, 05 Aug 2017 19:52:25 +0200 Date: Sat, 5 Aug 2017 19:51:44 +0200 From: Fabian Keil To: "Eugene M. Zheganin" Cc: freebsd-stable@FreeBSD.org, freebsd-fs@freebsd.org Subject: Re: a strange and terrible saga of the cursed iSCSI ZFS SAN Message-ID: <20170805195144.1caf98dc@fabiankeil.de> In-Reply-To: <1d53f489-5135-7633-fef4-35d26e4969dc@norma.perm.ru> References: <1bd10b1e-0583-6f44-297e-3147f6daddc5@norma.perm.ru> <1d53f489-5135-7633-fef4-35d26e4969dc@norma.perm.ru> Reply-To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/iPaWgOy.Hpp7k6QXYIQOmL8"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 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 Aug 2017 17:52:36 -0000 --Sig_/iPaWgOy.Hpp7k6QXYIQOmL8 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable "Eugene M. Zheganin" wrote: > On 05.08.2017 22:08, Eugene M. Zheganin wrote: > > > > pool: userdata > > state: ONLINE > > status: One or more devices has experienced an error resulting in data > > corruption. Applications may be affected. > > action: Restore the file in question if possible. Otherwise restore the > > entire pool from backup. > > see: http://illumos.org/msg/ZFS-8000-8A > > scan: none requested > > config: > > > > NAME STATE READ WRITE CKSUM > > userdata ONLINE 0 0 216K > > mirror-0 ONLINE 0 0 432K > > gpt/userdata0 ONLINE 0 0 432K > > gpt/userdata1 ONLINE 0 0 432K =20 > That would be funny, if not that sad, but while writing this message,=20 > the pool started to look like below (I just asked zpool status twice in=20 > a row, comparing to what it was): >=20 > [root@san1:~]# zpool status userdata > pool: userdata > state: ONLINE > status: One or more devices has experienced an error resulting in data > corruption. Applications may be affected. > action: Restore the file in question if possible. Otherwise restore the > entire pool from backup. > see: http://illumos.org/msg/ZFS-8000-8A > scan: none requested > config: >=20 > NAME STATE READ WRITE CKSUM > userdata ONLINE 0 0 728K > mirror-0 ONLINE 0 0 1,42M > gpt/userdata0 ONLINE 0 0 1,42M > gpt/userdata1 ONLINE 0 0 1,42M >=20 > errors: 4 data errors, use '-v' for a list > [root@san1:~]# zpool status userdata > pool: userdata > state: ONLINE > status: One or more devices has experienced an error resulting in data > corruption. Applications may be affected. > action: Restore the file in question if possible. Otherwise restore the > entire pool from backup. > see: http://illumos.org/msg/ZFS-8000-8A > scan: none requested > config: >=20 > NAME STATE READ WRITE CKSUM > userdata ONLINE 0 0 730K > mirror-0 ONLINE 0 0 1,43M > gpt/userdata0 ONLINE 0 0 1,43M > gpt/userdata1 ONLINE 0 0 1,43M >=20 > errors: 4 data errors, use '-v' for a list >=20 > So, you see, the error rate is like speed of light. And I'm not sure if=20 > the data access rate is that enormous, looks like they are increasing on= =20 > their own. > So may be someone have an idea on what this really means. Quoting a comment from sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_m= isc.c: /* * If destroy encounters an EIO while reading metadata (e.g. indirect * blocks), space referenced by the missing metadata can not be freed. * Normally this causes the background destroy to become "stalled", as * it is unable to make forward progress. While in this stalled state, * all remaining space to free from the error-encountering filesystem is * "temporarily leaked". Set this flag to cause it to ignore the EIO, * permanently leak the space from indirect blocks that can not be read, * and continue to free everything else that it can. * * The default, "stalling" behavior is useful if the storage partially * fails (i.e. some but not all i/os fail), and then later recovers. In * this case, we will be able to continue pool operations while it is * partially failed, and when it recovers, we can continue to free the * space, with no leaks. However, note that this case is actually * fairly rare. * * Typically pools either (a) fail completely (but perhaps temporarily, * e.g. a top-level vdev going offline), or (b) have localized, * permanent errors (e.g. disk returns the wrong data due to bit flip or * firmware bug). In case (a), this setting does not matter because the * pool will be suspended and the sync thread will not be able to make * forward progress regardless. In case (b), because the error is * permanent, the best we can do is leak the minimum amount of space, * which is what setting this flag will do. Therefore, it is reasonable * for this flag to normally be set, but we chose the more conservative * approach of not setting it, so that there is no possibility of * leaking space in the "partial temporary" failure case. */ In FreeBSD the "flag" currently isn't easily reachable due to the lack of a powerful kernel debugger (like mdb in Solaris offsprings) but it can be made reachable with a sysctl using the patch from: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218954 Fabian --Sig_/iPaWgOy.Hpp7k6QXYIQOmL8 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTKUNd6H/m3+ByGULIFiohV/3dUnQUCWYYFsQAKCRAFiohV/3dU nd3AAJ94LgHj630WLpNwyH3SKQj2l6hF9ACgqm2KgnEqE0xGYO0wswxBFpktykA= =hqGa -----END PGP SIGNATURE----- --Sig_/iPaWgOy.Hpp7k6QXYIQOmL8--