From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 00:14:46 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E9CB1802; Sun, 10 Nov 2013 00:14:46 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 18F632AD3; Sun, 10 Nov 2013 00:14:43 +0000 (UTC) Received: from ur.dons.net.au (ppp118-210-148-242.lns20.adl6.internode.on.net [118.210.148.242]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id rAA05HYg021884 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 10 Nov 2013 10:35:24 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Subject: Re: cron(8) improvement Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0D88FA8F-AFA4-4E20-881C-3683B3601A52"; protocol="application/pkcs7-signature"; micalg=sha1 From: "Daniel O'Connor" In-Reply-To: <527E3EB3.6000301@FreeBSD.org> Date: Sun, 10 Nov 2013 10:35:16 +1030 Message-Id: <8034B822-F903-43D1-8BF6-DFAD7C22F5B0@gsoft.com.au> References: <52792B60.1030309@allanjude.com> <488180AE-5C23-402A-BAA4-E3263D8C52BF@kientzle.com> <1383788977.14448.44112617.6F0D61A0@webmail.messagingengine.com> <527AFAA1.1040001@allanjude.com> <527BCA55.2000207@allanjude.com> <527C5D52.7030508@allanjude.com> <047405A8-B6EB-427B-A2E4-6254DD1A077B@orthanc.ca> <3E6377FF-69FE-48E4-BFB1-E5095A7FA1BB@orthanc.ca> <527C6DEF.6020102@allanjude.com> <527E3EB3.6000301@FreeBSD.org> To: Matthew Seaman X-Mailer: Apple Mail (2.1816) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 00:14:47 -0000 --Apple-Mail=_0D88FA8F-AFA4-4E20-881C-3683B3601A52 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 10 Nov 2013, at 24:24, Matthew Seaman wrote: >=20 > 2) Should ports / packages populate these cron.d directories? >=20 > This is a much more interesting question. Effectively its = asking > if a port / package should provide some level of automatic > configuration -- a thing that has previously been a no-no for > FreeBSD. I think it would be OK if they installed entries in a disabled state. ie either the file is named such that it is ignored by cron (preferable = IMO) or the entries in them are commented out. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --Apple-Mail=_0D88FA8F-AFA4-4E20-881C-3683B3601A52 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMhDCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGSDCCBTCg AwIBAgIDBuBKMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNjIyMDIwMjA0WhcNMTQwNjIyMTM0MDU5WjBhMRkwFwYDVQQNExBadUs3NzdMY2Fmekk5dzZN MR4wHAYDVQQDDBVkb2Nvbm5vckBnc29mdC5jb20uYXUxJDAiBgkqhkiG9w0BCQEWFWRvY29ubm9y QGdzb2Z0LmNvbS5hdTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAPzgRfq60KDeSy3T VyzQrpPsnXmRBPT//qQild/WeH3Ufa/FCrWUSuLuXP2cySz8hY4IVOqZ1sv4/+V6lu3LQkdkr20P XeZi6sQqyrljjmoWE7AuzU3QjRDa2ArJyoRSZHgWSkHx2EgOYlB+f3aa5+Vgx3jkGiDWOLfxowP4 whevsc7QnlpLddA6/y01hOTYZ9BQsDsrgogJDATlHJovhmBfU7JmkB/m2wQolEA4ZlcXT/7miXg6 0EAnQtSJp24AUbp2DshQN9pMFbV7SE+rUXoAmMpHO66Li1tnCzNQ3LmZG/+1wqoFMWpiE3zu9iaK NgnhQJcfiJCj5DXTDaRPHrcCAwEAAaOCAtswggLXMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUqZ3hJK6DeacEkaanreChG5/c QJYwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIAYDVR0RBBkwF4EVZG9jb25ub3JA Z3NvZnQuY29tLmF1MIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYB BQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHq MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmlj YXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWly ZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBp bnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdh dGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNy bC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3Ns LmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNz bC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAv10Yhugten4yx5ncJOAvSLkgHmtz mcnknxYnXgC97yWgBmq6PcpJpN4b8shau0sQmu5DY8f8Iz0GC9+zL/C81cI/P2J1lj8ntyLTOS7K 3j61LnkVbvDsf2KGWfoEDjIQ6GUEalOGAsj4JZUefZBG8gji1OZEI4tB21L/UeLVFL5wfbB6JISs nswVg9Ld/hndBZZLShp7MvWwE9pgZfguX+zJE6A9oQNytl7MiJCFFEj7M13xh3Xz3shM7UKOjJco HkQhIvEfK8OR4yf25i6E3x/0jCrEXhyPQSiIzNWMwARGtRCtWXn32/cSXzJf4Q9jobI0y4Rkh7/c wp9avBTiczGCA28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwbgSjAJ BgUrDgMCGgUAoIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0x MzExMTAwMDA1MTdaMCMGCSqGSIb3DQEJBDEWBBRvjdWDztwufr+LEnDspkXtlsDhaTCBpQYJKwYB BAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwbgSjCBpwYLKoZIhvcN AQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENv bSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBuBKMA0GCSqGSIb3DQEB AQUABIIBACQB14VYg8ppQr+t7/Za4G+/GYTCY8zNzIjXdsIuRKC5JGIMXJ2jdcVI5qN5gJHD/EEG FnrIshSNoQt6Dn+BPkJBadENWwfVX4gtdfp5HYzd4Acj6guIMGOtrbG0BcZB3xXDsCvRZhhFy1x0 CUbqmmthTTuJG8A+SOS+dNjzR3fZ37gcbKDyyfhKqs8nUJ+0XiD3Ez/KE6eXEUfagh6ON8ix2hL8 9jR9FGY0/SHfWy3hTBF/1RT2nm6+7tEsCvtX8KUrHYPnK2BXCEulfGMaQG5vhhuw/eIGqJPyXU6Q rGVgJEUvIWSOjzTML2tPLtYiFxthHCW8fLa1MPumKMdwMB0AAAAAAAA= --Apple-Mail=_0D88FA8F-AFA4-4E20-881C-3683B3601A52-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 00:18:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DF053A17; Sun, 10 Nov 2013 00:18:03 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x22b.google.com (mail-qe0-x22b.google.com [IPv6:2607:f8b0:400d:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 88B0C2AF6; Sun, 10 Nov 2013 00:18:03 +0000 (UTC) Received: by mail-qe0-f43.google.com with SMTP id nc12so3347798qeb.30 for ; Sat, 09 Nov 2013 16:18:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=YrIBoOFDcaG1WTWGaYZSTAnPqc9FbS+WpEtAAhIw4h4=; b=FbtvC4+B9vGa7VN6UCr0PI3FESRakpQ9QGzH0JPawKblTfvvZicT2FmspfI/u5QzMi lrIN5V6vP8v5Q61dHWTjl7xXPORP94/5PGIR+iC1r/zi3+/8P/kck8n9VjXrQJFwzWlK 2P7XpPaff1Uu30Q5VsYWJTlcGplyZN4y0sL61ZkIIAlA/xf6HSL3sg6KctOSyHCM94hX swu3jWKGNqQ+SWbzvEFBwNRSBWMcMhJukNKSmalJ+NofnKHCSVuuyIOZAcv3+BqHtNmc iTQhugHdqc2uNDXEaOtHTov+9bowN9rAAXYNJFRhWLXdeJUquQLRMvnVH4h5GwjCmSWJ tq2A== MIME-Version: 1.0 X-Received: by 10.224.111.197 with SMTP id t5mr36507977qap.49.1384042682766; Sat, 09 Nov 2013 16:18:02 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Sat, 9 Nov 2013 16:18:02 -0800 (PST) In-Reply-To: <8034B822-F903-43D1-8BF6-DFAD7C22F5B0@gsoft.com.au> References: <52792B60.1030309@allanjude.com> <488180AE-5C23-402A-BAA4-E3263D8C52BF@kientzle.com> <1383788977.14448.44112617.6F0D61A0@webmail.messagingengine.com> <527AFAA1.1040001@allanjude.com> <527BCA55.2000207@allanjude.com> <527C5D52.7030508@allanjude.com> <047405A8-B6EB-427B-A2E4-6254DD1A077B@orthanc.ca> <3E6377FF-69FE-48E4-BFB1-E5095A7FA1BB@orthanc.ca> <527C6DEF.6020102@allanjude.com> <527E3EB3.6000301@FreeBSD.org> <8034B822-F903-43D1-8BF6-DFAD7C22F5B0@gsoft.com.au> Date: Sat, 9 Nov 2013 16:18:02 -0800 X-Google-Sender-Auth: -8lZRpt1BGbOBVrIaDEpBI6_HQo Message-ID: Subject: Re: cron(8) improvement From: Adrian Chadd To: "Daniel O'Connor" Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current , Matthew Seaman X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 00:18:04 -0000 On 9 November 2013 16:05, Daniel O'Connor wrote: > > On 10 Nov 2013, at 24:24, Matthew Seaman wrote: >> >> 2) Should ports / packages populate these cron.d directories? >> >> This is a much more interesting question. Effectively its asking >> if a port / package should provide some level of automatic >> configuration -- a thing that has previously been a no-no for >> FreeBSD. > > I think it would be OK if they installed entries in a disabled state. > > ie either the file is named such that it is ignored by cron (preferable IMO) or the entries in them are commented out. I want the opposite. I'm kinda fed up installing packages that don't enable themselves. 'pkg install xorg' is not enough to get a working xorg. You have to enable hal and dbus and then restart (so things come up in the right order; manually starting them doesn't work) in order to get X working. If people are really worried about this, then I suggest a couple of package options for this stuff: * whether to default enable the package or not; * whether to default enable the cron scripts or not. Please install the cron scripts by default. Please then write up a simple rc.conf style setup where the cron scripts can check a config file to see if they should run. I don't want to have to freaking delete, rename, etc cron.d files. I just want the package files to be almost-untouched and have an option of working out of the box. Please, please allow an option to make this crap work out of the box already. -adrian From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 00:20:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E8CB4B40; Sun, 10 Nov 2013 00:20:53 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4264D2B38; Sun, 10 Nov 2013 00:20:52 +0000 (UTC) Received: from ur.dons.net.au (ppp118-210-148-242.lns20.adl6.internode.on.net [118.210.148.242]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id rAA0KUBX022629 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 10 Nov 2013 10:50:37 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Subject: Re: cron(8) improvement Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9D31786A-359C-4A8B-9879-0F542306600D"; protocol="application/pkcs7-signature"; micalg=sha1 From: "Daniel O'Connor" In-Reply-To: Date: Sun, 10 Nov 2013 10:50:30 +1030 Message-Id: <780C84A0-A55A-44AC-A145-C33A5F175B02@gsoft.com.au> References: <52792B60.1030309@allanjude.com> <488180AE-5C23-402A-BAA4-E3263D8C52BF@kientzle.com> <1383788977.14448.44112617.6F0D61A0@webmail.messagingengine.com> <527AFAA1.1040001@allanjude.com> <527BCA55.2000207@allanjude.com> <527C5D52.7030508@allanjude.com> <047405A8-B6EB-427B-A2E4-6254DD1A077B@orthanc.ca> <3E6377FF-69FE-48E4-BFB1-E5095A7FA1BB@orthanc.ca> <527C6DEF.6020102@allanjude.com> <527E3EB3.6000301@FreeBSD.org> <8034B822-F903-43D1-8BF6-DFAD7C22F5B0@gsoft.com.au> To: Adrian Chadd X-Mailer: Apple Mail (2.1816) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: FreeBSD Current , Matthew Seaman X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 00:20:54 -0000 --Apple-Mail=_9D31786A-359C-4A8B-9879-0F542306600D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 10 Nov 2013, at 10:48, Adrian Chadd wrote: >> ie either the file is named such that it is ignored by cron = (preferable IMO) or the entries in them are commented out. >=20 > I want the opposite. >=20 > I'm kinda fed up installing packages that don't enable themselves. >=20 > 'pkg install xorg' is not enough to get a working xorg. You have to > enable hal and dbus and then restart (so things come up in the right > order; manually starting them doesn't work) in order to get X working. I agree that is a pain in the arse, however it IS existing policy. I don't think changing it here is right - if the policy is to change it = should be changed everywhere. > If people are really worried about this, then I suggest a couple of > package options for this stuff: >=20 > * whether to default enable the package or not; > * whether to default enable the cron scripts or not. >=20 > Please install the cron scripts by default. Please then write up a > simple rc.conf style setup where the cron scripts can check a config > file to see if they should run. I don't want to have to freaking > delete, rename, etc cron.d files. I just want the package files to be > almost-untouched and have an option of working out of the box. >=20 > Please, please allow an option to make this crap work out of the box = already. A rc.conf script sounds good to me. That still won't get you want you want though because the port/pkg = install wouldn't touch it? (would it?) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --Apple-Mail=_9D31786A-359C-4A8B-9879-0F542306600D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMhDCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGSDCCBTCg AwIBAgIDBuBKMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNjIyMDIwMjA0WhcNMTQwNjIyMTM0MDU5WjBhMRkwFwYDVQQNExBadUs3NzdMY2Fmekk5dzZN MR4wHAYDVQQDDBVkb2Nvbm5vckBnc29mdC5jb20uYXUxJDAiBgkqhkiG9w0BCQEWFWRvY29ubm9y QGdzb2Z0LmNvbS5hdTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAPzgRfq60KDeSy3T VyzQrpPsnXmRBPT//qQild/WeH3Ufa/FCrWUSuLuXP2cySz8hY4IVOqZ1sv4/+V6lu3LQkdkr20P XeZi6sQqyrljjmoWE7AuzU3QjRDa2ArJyoRSZHgWSkHx2EgOYlB+f3aa5+Vgx3jkGiDWOLfxowP4 whevsc7QnlpLddA6/y01hOTYZ9BQsDsrgogJDATlHJovhmBfU7JmkB/m2wQolEA4ZlcXT/7miXg6 0EAnQtSJp24AUbp2DshQN9pMFbV7SE+rUXoAmMpHO66Li1tnCzNQ3LmZG/+1wqoFMWpiE3zu9iaK NgnhQJcfiJCj5DXTDaRPHrcCAwEAAaOCAtswggLXMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUqZ3hJK6DeacEkaanreChG5/c QJYwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIAYDVR0RBBkwF4EVZG9jb25ub3JA Z3NvZnQuY29tLmF1MIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYB BQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHq MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmlj YXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWly ZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBp bnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdh dGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNy bC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3Ns LmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNz bC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAv10Yhugten4yx5ncJOAvSLkgHmtz mcnknxYnXgC97yWgBmq6PcpJpN4b8shau0sQmu5DY8f8Iz0GC9+zL/C81cI/P2J1lj8ntyLTOS7K 3j61LnkVbvDsf2KGWfoEDjIQ6GUEalOGAsj4JZUefZBG8gji1OZEI4tB21L/UeLVFL5wfbB6JISs nswVg9Ld/hndBZZLShp7MvWwE9pgZfguX+zJE6A9oQNytl7MiJCFFEj7M13xh3Xz3shM7UKOjJco HkQhIvEfK8OR4yf25i6E3x/0jCrEXhyPQSiIzNWMwARGtRCtWXn32/cSXzJf4Q9jobI0y4Rkh7/c wp9avBTiczGCA28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwbgSjAJ BgUrDgMCGgUAoIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0x MzExMTAwMDIwMzBaMCMGCSqGSIb3DQEJBDEWBBQxKc+tH2Q9wuVAjHYq0DmmyjEkXDCBpQYJKwYB BAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwbgSjCBpwYLKoZIhvcN AQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENv bSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBuBKMA0GCSqGSIb3DQEB AQUABIIBABwZK9cI3ZO6YN5sUvhxgblBLKChDK5YOxdyrsqPsOC7CM1qzdYtf50NwTnKa6ZWl6sk TVJ+kKJPd0qN4iSv0t4ZbIlcir+01/vt+phIiM9b5jtB78J5PgMzNBYoNG+GZlIqOGGpSt/ur3j/ pi2aNva/Olz2d0osJhVGDrZsa8wG9q/m5uQNMbucK59C1kKEvaYfJVHmnKQzmJejVpENE7IuW8wM b1JRcd0AR09/VzcLhA3eK8iINjvSXZuzhkCZY/sK5z2Fh7SBeMAMymI95OIVPmRcwhhzP35FwAD+ BCV+oxTcFXQh7gbwKkU592cryGIYU20Jawc/oKz78POoj8cAAAAAAAA= --Apple-Mail=_9D31786A-359C-4A8B-9879-0F542306600D-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 00:29:00 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2A0CECAC for ; Sun, 10 Nov 2013 00:29:00 +0000 (UTC) (envelope-from freebsd@allanjude.com) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id F005C2B70 for ; Sun, 10 Nov 2013 00:28:58 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.108.129]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id A5155468B1 for ; Sun, 10 Nov 2013 00:28:57 +0000 (UTC) Message-ID: <527ED34A.1060401@allanjude.com> Date: Sat, 09 Nov 2013 19:28:58 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: cron(8) improvement References: <52792B60.1030309@allanjude.com> <488180AE-5C23-402A-BAA4-E3263D8C52BF@kientzle.com> <1383788977.14448.44112617.6F0D61A0@webmail.messagingengine.com> <527AFAA1.1040001@allanjude.com> <527BCA55.2000207@allanjude.com> <527C5D52.7030508@allanjude.com> <047405A8-B6EB-427B-A2E4-6254DD1A077B@orthanc.ca> <3E6377FF-69FE-48E4-BFB1-E5095A7FA1BB@orthanc.ca> <527C6DEF.6020102@allanjude.com> <527E3EB3.6000301@FreeBSD.org> <8034B822-F903-43D1-8BF6-DFAD7C22F5B0@gsoft.com.au> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="saIJgj3CGwl8ae1WlImR04exOemvqKwRF" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 00:29:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --saIJgj3CGwl8ae1WlImR04exOemvqKwRF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-11-09 19:18, Adrian Chadd wrote: > On 9 November 2013 16:05, Daniel O'Connor wrote= : >> On 10 Nov 2013, at 24:24, Matthew Seaman wrote: >>> 2) Should ports / packages populate these cron.d directories? >>> >>> This is a much more interesting question. Effectively its aski= ng >>> if a port / package should provide some level of automatic >>> configuration -- a thing that has previously been a no-no for >>> FreeBSD. >> I think it would be OK if they installed entries in a disabled state. >> >> ie either the file is named such that it is ignored by cron (preferabl= e IMO) or the entries in them are commented out. > I want the opposite. > > I'm kinda fed up installing packages that don't enable themselves. > > 'pkg install xorg' is not enough to get a working xorg. You have to > enable hal and dbus and then restart (so things come up in the right > order; manually starting them doesn't work) in order to get X working. > > If people are really worried about this, then I suggest a couple of > package options for this stuff: > > * whether to default enable the package or not; > * whether to default enable the cron scripts or not. > > Please install the cron scripts by default. Please then write up a > simple rc.conf style setup where the cron scripts can check a config > file to see if they should run. I don't want to have to freaking > delete, rename, etc cron.d files. I just want the package files to be > almost-untouched and have an option of working out of the box. > > Please, please allow an option to make this crap work out of the box al= ready. > > > -adrian > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" Well, what about making these extra directories optional then? packages install the crontab entries, but crond ignores them unless you a= dd: cron_flags=3D"--scandir /etc/cron.d --scandir /usr/local/etc/cron.d" or something to that effect As for packages enabling things, this seems like a good use of the /etc/rc.conf.d/ infrastructure, although it has a kind of odd structure, where the individual files are only included if the name of the service being started patches. So for example, /etc/rc.conf.d/sshd wouldn't be read when starting crond --=20 Allan Jude --saIJgj3CGwl8ae1WlImR04exOemvqKwRF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSftNNAAoJEJrBFpNRJZKf/dEP/i5LjGf28kSMW7QGqPwz9A7U rdf1yMA6SPfN2PC1du1FR9PWYUCK48OEAKau5exkOuYBvj44spUM2ldwzHwJWfR3 8+Ugf9um71F5kbiI+VYD8Zrz4nSflF/M3nGP4F3f41VczMf702AZddhSvYmQ0yec x/8jzW7R/TVHJdQ8Yp4JEm1sTzP2TF9MevnUVahyof/hVVsJOZMiovzVYN8yFKPN Kva5FFkN3qlouLXO9wWWSvOCWbCxRJNOr7MJ95pNvB2JS9wf2uaqYeZYW0w036f7 NYjm+TxIJQR/cisuktq5Inn7RYGAHzb1vrYCvUCKZon3lwryV51vUrhDBCY3gxKB Q3jhEw0b9uwAqt4ABnKD+/i7oNiMcCH4+ktNF7OEieL7uPB0WHmIbFwQ4V1wh0za jT8AC9oim2kjHCJSPGSvmcT/kVddQ7myXUc04bV5n2G+hIAhHZQ6XnBQbuv4Wyg1 DASkDmu5UMVKr21RYt2tKEiddLWV+29cg+pNi56WPNUsPAxs4I1aXZExpznGGx2H 8RRpQUvdzWJ+2JVJs5ocePMAqBLavh6gFLuB3aMJ1XERQEa8E53Z6zQurgrM5J/h 15fzlhgmpgfKSiyOHYht7n1wc85+Mv2B31LEYt0shCwdWRezBIZEQxNFlCgZfNYc 6TwP/G1kBX/QnV8fJwU2 =B9/I -----END PGP SIGNATURE----- --saIJgj3CGwl8ae1WlImR04exOemvqKwRF-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 01:05:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 930621F7 for ; Sun, 10 Nov 2013 01:05:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4DF8C2D01 for ; Sun, 10 Nov 2013 01:05:12 +0000 (UTC) Received: by mail-qa0-f51.google.com with SMTP id hu16so811397qab.10 for ; Sat, 09 Nov 2013 17:05:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=xpeOUofJ59zBuyMbsUF/3vcCs88ENgCs3z75bmcWILg=; b=IpfexE5Mytvae3wIk0GUAB/TnVZYHnoQmMY9nwg81NkIX5Hj4veSUu0HNCU7GkMJBS xrTiujuGUGNZQ52fsP6R5t8Uk9i2DL9CdKo/EI5pZmyiCImkgGSu7EIzV3RLMdn28C1l mmb+7IeMqtS1zQPWK4IpvnNxpJqqPx4h4/rL23V5yOBxWdw5bfQrdqjGCfOVyOA7dve2 13Iyej/yDxNqCW0kZuQ3AqovR9XDsBaiDDNLRTW5IMmq0i+KP0SlFDyglypmsRwnzb7y WL+0dW9+TY8DT6LIbEZWxiBQncaF2t2fbpZiqb+y0dFb7IN07PB42pV/JTWNuVK7NfyY ColA== MIME-Version: 1.0 X-Received: by 10.224.36.201 with SMTP id u9mr36528400qad.76.1384045511547; Sat, 09 Nov 2013 17:05:11 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Sat, 9 Nov 2013 17:05:11 -0800 (PST) In-Reply-To: <527ED34A.1060401@allanjude.com> References: <52792B60.1030309@allanjude.com> <488180AE-5C23-402A-BAA4-E3263D8C52BF@kientzle.com> <1383788977.14448.44112617.6F0D61A0@webmail.messagingengine.com> <527AFAA1.1040001@allanjude.com> <527BCA55.2000207@allanjude.com> <527C5D52.7030508@allanjude.com> <047405A8-B6EB-427B-A2E4-6254DD1A077B@orthanc.ca> <3E6377FF-69FE-48E4-BFB1-E5095A7FA1BB@orthanc.ca> <527C6DEF.6020102@allanjude.com> <527E3EB3.6000301@FreeBSD.org> <8034B822-F903-43D1-8BF6-DFAD7C22F5B0@gsoft.com.au> <527ED34A.1060401@allanjude.com> Date: Sat, 9 Nov 2013 17:05:11 -0800 X-Google-Sender-Auth: FnYkIU_ynKOQlb0rB2Lao8Ypd9w Message-ID: Subject: Re: cron(8) improvement From: Adrian Chadd To: Allan Jude Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 01:05:12 -0000 On 9 November 2013 16:28, Allan Jude wrote: > Well, what about making these extra directories optional then? > > packages install the crontab entries, but crond ignores them unless you add: > > cron_flags="--scandir /etc/cron.d --scandir /usr/local/etc/cron.d" > > or something to that effect > > As for packages enabling things, this seems like a good use of the > /etc/rc.conf.d/ infrastructure, although it has a kind of odd structure, > where the individual files are only included if the name of the service > being started patches. So for example, /etc/rc.conf.d/sshd wouldn't be > read when starting crond Right. I'd rather it read in everything, but I realise that scales poorly. The other alternative is to have a config file populated with the contents of /etc/rc.conf.d/*, so to modify it you'd edit the individual config file(s), then do a "commit" operation to push it into the cache. If the cache file doesn't exist, it simply goes through and reads * if someone wanted to speed up the rcvar set, they could just replace it with a read from an sqlite table or an individual config file (as said above); the rcvar thing is -supposed- to just be attribute=value, so it can be stored anywhere. Note to previous poster: i think the existing policy sucks. :-) -adrian From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 01:40:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D9E42617; Sun, 10 Nov 2013 01:40:39 +0000 (UTC) (envelope-from freebsd@allanjude.com) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 94A582E66; Sun, 10 Nov 2013 01:40:39 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.108.129]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 08E2046937; Sun, 10 Nov 2013 01:40:37 +0000 (UTC) Message-ID: <527EE417.6060704@allanjude.com> Date: Sat, 09 Nov 2013 20:40:39 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: cron(8) improvement References: <52792B60.1030309@allanjude.com> <488180AE-5C23-402A-BAA4-E3263D8C52BF@kientzle.com> <1383788977.14448.44112617.6F0D61A0@webmail.messagingengine.com> <527AFAA1.1040001@allanjude.com> <527BCA55.2000207@allanjude.com> <527C5D52.7030508@allanjude.com> <047405A8-B6EB-427B-A2E4-6254DD1A077B@orthanc.ca> <3E6377FF-69FE-48E4-BFB1-E5095A7FA1BB@orthanc.ca> <527C6DEF.6020102@allanjude.com> <527E3EB3.6000301@FreeBSD.org> <8034B822-F903-43D1-8BF6-DFAD7C22F5B0@gsoft.com.au> <527ED34A.1060401@allanjude.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7qniiipClj8SII16d6UcI3fb5IALoothG" Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 01:40:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7qniiipClj8SII16d6UcI3fb5IALoothG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-11-09 20:05, Adrian Chadd wrote: > On 9 November 2013 16:28, Allan Jude wrote: > >> Well, what about making these extra directories optional then? >> >> packages install the crontab entries, but crond ignores them unless yo= u add: >> >> cron_flags=3D"--scandir /etc/cron.d --scandir /usr/local/etc/cron.d" >> >> or something to that effect >> >> As for packages enabling things, this seems like a good use of the >> /etc/rc.conf.d/ infrastructure, although it has a kind of odd structur= e, >> where the individual files are only included if the name of the servic= e >> being started patches. So for example, /etc/rc.conf.d/sshd wouldn't be= >> read when starting crond > Right. I'd rather it read in everything, but I realise that scales poor= ly. > > The other alternative is to have a config file populated with the > contents of /etc/rc.conf.d/*, so to modify it you'd edit the > individual config file(s), then do a "commit" operation to push it > into the cache. > > If the cache file doesn't exist, it simply goes through and reads * > > if someone wanted to speed up the rcvar set, they could just replace > it with a read from an sqlite table or an individual config file (as > said above); the rcvar thing is -supposed- to just be attribute=3Dvalue= , > so it can be stored anywhere. > > Note to previous poster: i think the existing policy sucks. :-) > > > -adrian I suppose you could easily do something like: cat /etc/rc.conf.d/* > /etc/rc.conf.cat and add rc.conf.cat to rc_conf_files --=20 Allan Jude --7qniiipClj8SII16d6UcI3fb5IALoothG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSfuQaAAoJEJrBFpNRJZKfJ5MQAJFKGLvMdfC5x4vtUQrBHWSL Pv4A/8zmmnJ1xL07jmXV+BEkHGU+z8w5G4KdHFShpHkJOnDjY8H41fnHbRHGd7Os G8VFxcTmy8jZUq57x6gS2VSdS0omczIYFt5g0N8isurNRfingimT6RLEXWoInJx9 Cinjdq2KgS27iOHf/4QUCdt4UEJR8SPxPUm1er/dgWIuWtvVzEwqGbhdnfG4HPJ0 wBOpS8vElh9iNRfyYvEKCRwfs5CCfXBAoAdincVyb+b24UtrfoshfueRhzXexOWh QQzgiHfRuJWbcSnCO9V4y3G6hdFqifgCsUlA5efGckV9r8zjvimgzNpO4TpGmJfQ 38EdBg5TC9rEDaCn0bjkg2I6Qd3+4dTWDkFf7SkV9AdDiwSwlrpj9R09T5K3s2XE XMmyQnNbI9daN3HbBiuWYP7SSkxy2ks8rTxTvlACz0IYPbB2M9bxppe4BW9jeqvB gAehITEzaIrD47x/6jQ/2fQ1y5hATZAz4vkZD55SA1vHM9nt/yTSOIa5+/PuS1GS PATybY0xu+WuGK2GtZc4PJ+V2vDKmcjsulXpLpy3hXjy+ruk09qr/bVjX8UaGGKY Sh9dPgxg+CUXbhgj2NmpSSxFNFhc4c6l+jpfQV1hBbC8937e7aOf3QVMryWmHNoD lV+7XAvGLqhcxFvjiDJf =2P0w -----END PGP SIGNATURE----- --7qniiipClj8SII16d6UcI3fb5IALoothG-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 01:55:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7D1BB80D for ; Sun, 10 Nov 2013 01:55:41 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 372B42EE4 for ; Sun, 10 Nov 2013 01:55:41 +0000 (UTC) Received: by mail-qc0-f177.google.com with SMTP id b10so788505qcw.36 for ; Sat, 09 Nov 2013 17:55:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=z8x/rOHN/zT8BNb7WrPp3+bHUZzihHIqw8L9w/nN4oo=; b=eVYrJs/tMXNNNJ+ex/eX0CwCWwAKaXGG9wL/JcmBXJ6tO/eVH139RkDGEYPuJTa1Lg D3raMbyRui/ppl13cTqjuKfo6oU6NYX4Bvjzs0VqBRHwE/aqGZxP67nB+WvFpdFy1esh n/VNQOpHen8JPBe1TvFMqSMgIB4JE5n4nv6KlPoeliAuudK1w9AjsyyQRL0ddT+ei1X6 Apwhb+EQ+UTJr002eU/Zh+lLd1tWFAh/Er07ISLoru8zAf226ymqPRVzoQHaiBRb1noz Gc7o38s+GboTUI3IlqpBzpqPc3PQC+Cf9tgrUh/63vO53AwQimkUwtb4C7z4uP0RRcGx wIgw== MIME-Version: 1.0 X-Received: by 10.49.35.144 with SMTP id h16mr35086552qej.35.1384048540412; Sat, 09 Nov 2013 17:55:40 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Sat, 9 Nov 2013 17:55:40 -0800 (PST) In-Reply-To: <527EE417.6060704@allanjude.com> References: <52792B60.1030309@allanjude.com> <488180AE-5C23-402A-BAA4-E3263D8C52BF@kientzle.com> <1383788977.14448.44112617.6F0D61A0@webmail.messagingengine.com> <527AFAA1.1040001@allanjude.com> <527BCA55.2000207@allanjude.com> <527C5D52.7030508@allanjude.com> <047405A8-B6EB-427B-A2E4-6254DD1A077B@orthanc.ca> <3E6377FF-69FE-48E4-BFB1-E5095A7FA1BB@orthanc.ca> <527C6DEF.6020102@allanjude.com> <527E3EB3.6000301@FreeBSD.org> <8034B822-F903-43D1-8BF6-DFAD7C22F5B0@gsoft.com.au> <527ED34A.1060401@allanjude.com> <527EE417.6060704@allanjude.com> Date: Sat, 9 Nov 2013 17:55:40 -0800 X-Google-Sender-Auth: R610XlNWYgnRmQ9-aFjDaZtZPGI Message-ID: Subject: Re: cron(8) improvement From: Adrian Chadd To: Allan Jude Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 01:55:41 -0000 On 9 November 2013 17:40, Allan Jude wrote: > On 2013-11-09 20:05, Adrian Chadd wrote: >> On 9 November 2013 16:28, Allan Jude wrote: >> >>> Well, what about making these extra directories optional then? >>> >>> packages install the crontab entries, but crond ignores them unless you add: >>> >>> cron_flags="--scandir /etc/cron.d --scandir /usr/local/etc/cron.d" >>> >>> or something to that effect >>> >>> As for packages enabling things, this seems like a good use of the >>> /etc/rc.conf.d/ infrastructure, although it has a kind of odd structure, >>> where the individual files are only included if the name of the service >>> being started patches. So for example, /etc/rc.conf.d/sshd wouldn't be >>> read when starting crond >> Right. I'd rather it read in everything, but I realise that scales poorly. >> >> The other alternative is to have a config file populated with the >> contents of /etc/rc.conf.d/*, so to modify it you'd edit the >> individual config file(s), then do a "commit" operation to push it >> into the cache. >> >> If the cache file doesn't exist, it simply goes through and reads * >> >> if someone wanted to speed up the rcvar set, they could just replace >> it with a read from an sqlite table or an individual config file (as >> said above); the rcvar thing is -supposed- to just be attribute=value, >> so it can be stored anywhere. >> >> Note to previous poster: i think the existing policy sucks. :-) >> >> >> -adrian > I suppose you could easily do something like: cat /etc/rc.conf.d/* > > /etc/rc.conf.cat > > and add rc.conf.cat to rc_conf_files Right. But what this scheme specifically needs is some semantics for "thing I do to push new config changes into the rc.conf system" and "thing I do to force a commit of these changes." For the rc.conf.cat version, it would do the above. It may just wrap it in a lock file. For the sqlite hack version, it would grab a lock and dump everything into an sqlite table. The point is that it shouldn't be adhoc. there should be some tools in base for "things" to add/remove cron configs, add/remove rc.conf configs, and do a "rebuild" of them. -adrian From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 01:58:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6FD3492D; Sun, 10 Nov 2013 01:58:39 +0000 (UTC) (envelope-from freebsd@allanjude.com) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 3CE172EFB; Sun, 10 Nov 2013 01:58:38 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.108.129]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 8847446970; Sun, 10 Nov 2013 01:58:36 +0000 (UTC) Message-ID: <527EE84D.4060901@allanjude.com> Date: Sat, 09 Nov 2013 20:58:37 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: cron(8) improvement References: <52792B60.1030309@allanjude.com> <527AFAA1.1040001@allanjude.com> <527BCA55.2000207@allanjude.com> <527C5D52.7030508@allanjude.com> <047405A8-B6EB-427B-A2E4-6254DD1A077B@orthanc.ca> <3E6377FF-69FE-48E4-BFB1-E5095A7FA1BB@orthanc.ca> <527C6DEF.6020102@allanjude.com> <527E3EB3.6000301@FreeBSD.org> <8034B822-F903-43D1-8BF6-DFAD7C22F5B0@gsoft.com.au> <527ED34A.1060401@allanjude.com> <527EE417.6060704@allanjude.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="G8prX8sRFpQjf4CDsHhgKspxRnNbqp8IW" Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 01:58:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --G8prX8sRFpQjf4CDsHhgKspxRnNbqp8IW Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-11-09 20:55, Adrian Chadd wrote: > On 9 November 2013 17:40, Allan Jude wrote: >> On 2013-11-09 20:05, Adrian Chadd wrote: >>> On 9 November 2013 16:28, Allan Jude wrote: >>> >>>> Well, what about making these extra directories optional then? >>>> >>>> packages install the crontab entries, but crond ignores them unless = you add: >>>> >>>> cron_flags=3D"--scandir /etc/cron.d --scandir /usr/local/etc/cron.d"= >>>> >>>> or something to that effect >>>> >>>> As for packages enabling things, this seems like a good use of the >>>> /etc/rc.conf.d/ infrastructure, although it has a kind of odd struct= ure, >>>> where the individual files are only included if the name of the serv= ice >>>> being started patches. So for example, /etc/rc.conf.d/sshd wouldn't = be >>>> read when starting crond >>> Right. I'd rather it read in everything, but I realise that scales po= orly. >>> >>> The other alternative is to have a config file populated with the >>> contents of /etc/rc.conf.d/*, so to modify it you'd edit the >>> individual config file(s), then do a "commit" operation to push it >>> into the cache. >>> >>> If the cache file doesn't exist, it simply goes through and reads * >>> >>> if someone wanted to speed up the rcvar set, they could just replace >>> it with a read from an sqlite table or an individual config file (as >>> said above); the rcvar thing is -supposed- to just be attribute=3Dval= ue, >>> so it can be stored anywhere. >>> >>> Note to previous poster: i think the existing policy sucks. :-) >>> >>> >>> -adrian >> I suppose you could easily do something like: cat /etc/rc.conf.d/* > >> /etc/rc.conf.cat >> >> and add rc.conf.cat to rc_conf_files > Right. But what this scheme specifically needs is some semantics for > "thing I do to push new config changes into the rc.conf system" and > "thing I do to force a commit of these changes." > > For the rc.conf.cat version, it would do the above. It may just wrap > it in a lock file. > > For the sqlite hack version, it would grab a lock and dump everything > into an sqlite table. > > The point is that it shouldn't be adhoc. there should be some tools in > base for "things" to add/remove cron configs, add/remove rc.conf > configs, and do a "rebuild" of them. > > > -adrian Well, if the rc.conf config is specific to the daemon being installed by the package, then the existing /etc/rc.conf.d/ system works fine, it just falls down a little on xorg configuring hald, unless you just make the xorg package create /etc/rc.conf.d/hald and /etc/rc.conf.d/dbus I like the simplicity of rc.conf, and I would much rather not involve an sqlite database, I am not sure how that could possibly be faster then sourcing an extra shell script. --=20 Allan Jude --G8prX8sRFpQjf4CDsHhgKspxRnNbqp8IW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSfuhRAAoJEJrBFpNRJZKfrMUQAL2sbCIs9ctiUQcKgm8hv85a 8H/aagTVDqE2FRSAqlafYuPYq84p6+6g5x/3cNDk52KJis2mm7Rr+avb0rvflzH5 EErdcGMDzHWrAQjZ9H1fEa5E2ufOSdRmPGuXy+5cJv+wU7MexREFEAOKf/GAd0n2 Rc3dWpdPb7h+ZLGDgX+qokfp4ua96wbNPnJSir8gQIg7zRTPd3zml3+Jt5H1CXRz JU0AN04sftlVnGxSq6Qoh11C4oswm5pg/LRw55BB71X7JY4LStGWB4CVAY/f1veC s+apT6s7rxtQcRTba8RBJcHTT3pIWOdHRUzlBXzJMDtIx28653zB8gduhOO1OZnO nCtKtPw98kUn9GrGnjPKltpNDfS+drZAopKWG2BYEoJDNTnRokg2vxLxWFl5WnGq eIvvzIzoT7NJTeMnbLZwLXIi3danlFF0CecqOj8FRpXUHscyvoF+kxWZ//8u4T7c uxC8tGEy6fQAMeatXnQxcdMP6UDgpDVGXiG8KWDNSehKa9JTIAMK9I+IlmUEO69T c99FDTpKa5K0BshKrsIODeC4eZCTPS4kqwbBcHO2t7r0SY5aQ+ymbiVQNTnJUhom 1tuFbNugF/eVrL1Oo/X6rinYmz/j2LjaSTQzdI1LRsW56yu7mD7EAIw8/d554ldw 8hRsz3LNhxgfWKEPu1sj =kBzT -----END PGP SIGNATURE----- --G8prX8sRFpQjf4CDsHhgKspxRnNbqp8IW-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 02:13:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 78655BA4 for ; Sun, 10 Nov 2013 02:13:44 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x22a.google.com (mail-qe0-x22a.google.com [IPv6:2607:f8b0:400d:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 312EA2FA2 for ; Sun, 10 Nov 2013 02:13:44 +0000 (UTC) Received: by mail-qe0-f42.google.com with SMTP id df13so61956qeb.29 for ; Sat, 09 Nov 2013 18:13:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=2UpniasgeXMMCULM7qrCjfBpqHf7WK/KNIv4ZmI9qVA=; b=mY7UI+sdltncROOT0oTVFXPnvN72a+QbM3gVS+QRI90zJpWOTIrIcmuLg7xGG5+G8Z IAwRdlP2MhofXF0qSJSnk6Cm/HCHWYeRepL1YOqopplWbAaVP+JmaHj94zwNI4ukyrRX ci2jTXyXBtSUQxqqu0DGvqtMVDRP9jYT5Sc5+dwbrvKosUM8hykQW6uw33qznwyAqRKR 2n4i9SeO/YA+uQJ89Trg3andOUcCf/XOpOyR3VveW1y/OoJRuuyGhQyQOKPVnKOOBpiS FREJfIZmxrKbdFIIq9uxqLkGgbJiSvfuf//5pLyBvc3HxiY3UySGJku0HyJsMJlfoyGM 0WnQ== MIME-Version: 1.0 X-Received: by 10.49.59.70 with SMTP id x6mr34977357qeq.17.1384049623441; Sat, 09 Nov 2013 18:13:43 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Sat, 9 Nov 2013 18:13:43 -0800 (PST) In-Reply-To: <527EE84D.4060901@allanjude.com> References: <52792B60.1030309@allanjude.com> <527AFAA1.1040001@allanjude.com> <527BCA55.2000207@allanjude.com> <527C5D52.7030508@allanjude.com> <047405A8-B6EB-427B-A2E4-6254DD1A077B@orthanc.ca> <3E6377FF-69FE-48E4-BFB1-E5095A7FA1BB@orthanc.ca> <527C6DEF.6020102@allanjude.com> <527E3EB3.6000301@FreeBSD.org> <8034B822-F903-43D1-8BF6-DFAD7C22F5B0@gsoft.com.au> <527ED34A.1060401@allanjude.com> <527EE417.6060704@allanjude.com> <527EE84D.4060901@allanjude.com> Date: Sat, 9 Nov 2013 18:13:43 -0800 X-Google-Sender-Auth: 6BbosFG_A2vd0k4SDIQmCguC69c Message-ID: Subject: Re: cron(8) improvement From: Adrian Chadd To: Allan Jude Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 02:13:44 -0000 On 9 November 2013 17:58, Allan Jude wrote: > Well, if the rc.conf config is specific to the daemon being installed by > the package, then the existing /etc/rc.conf.d/ system works fine, it > just falls down a little on xorg configuring hald, unless you just make > the xorg package create /etc/rc.conf.d/hald and /etc/rc.conf.d/dbus If I install hal/dbus, why wouldn't they themselves populate /etc/rc.conf.d/hald and /etc/rc.conf.d/dbus ? If there are hal/dbus options that need configuring by other packages, then sure, you'll need to add some other things too. > I like the simplicity of rc.conf, and I would much rather not involve an > sqlite database, I am not sure how that could possibly be faster then > sourcing an extra shell script. Don't focus on that. The sqlite example is just that - an example - showing what kind of operations you would want to implement to _allow_ you to do that. I'm not advocating for doing it in freebsd-base. The point I'm making is this: * when populating rc.conf.d/, don't just do 'cp' in a post-install script * when populating the cron daemon entries in rc.cron.d, don't just 'cp' in a post-install script. -adrian From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 02:23:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A2DBFDEB; Sun, 10 Nov 2013 02:23:59 +0000 (UTC) (envelope-from freebsd@allanjude.com) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 5CC342014; Sun, 10 Nov 2013 02:23:58 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.108.129]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 450DF46998; Sun, 10 Nov 2013 02:23:55 +0000 (UTC) Message-ID: <527EEE3D.9000101@allanjude.com> Date: Sat, 09 Nov 2013 21:23:57 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: cron(8) improvement References: <52792B60.1030309@allanjude.com> <527BCA55.2000207@allanjude.com> <527C5D52.7030508@allanjude.com> <047405A8-B6EB-427B-A2E4-6254DD1A077B@orthanc.ca> <3E6377FF-69FE-48E4-BFB1-E5095A7FA1BB@orthanc.ca> <527C6DEF.6020102@allanjude.com> <527E3EB3.6000301@FreeBSD.org> <8034B822-F903-43D1-8BF6-DFAD7C22F5B0@gsoft.com.au> <527ED34A.1060401@allanjude.com> <527EE417.6060704@allanjude.com> <527EE84D.4060901@allanjude.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nrHsfe2G5jHLkHwrrERj4FnXPAnVwFkNj" Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 02:23:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nrHsfe2G5jHLkHwrrERj4FnXPAnVwFkNj Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-11-09 21:13, Adrian Chadd wrote: > On 9 November 2013 17:58, Allan Jude wrote: > >> Well, if the rc.conf config is specific to the daemon being installed = by >> the package, then the existing /etc/rc.conf.d/ system works fine, it >> just falls down a little on xorg configuring hald, unless you just mak= e >> the xorg package create /etc/rc.conf.d/hald and /etc/rc.conf.d/dbus > If I install hal/dbus, why wouldn't they themselves populate > /etc/rc.conf.d/hald and /etc/rc.conf.d/dbus ? > > If there are hal/dbus options that need configuring by other packages, > then sure, you'll need to add some other things too. ahh, right, why didn't I think of that >> I like the simplicity of rc.conf, and I would much rather not involve = an >> sqlite database, I am not sure how that could possibly be faster then >> sourcing an extra shell script. > Don't focus on that. The sqlite example is just that - an example - > showing what kind of operations you would want to implement to _allow_ > you to do that. I'm not advocating for doing it in freebsd-base. > > The point I'm making is this: > > * when populating rc.conf.d/, don't just do 'cp' in a post-install scri= pt > * when populating the cron daemon entries in rc.cron.d, don't just > 'cp' in a post-install script. > > > -adrian If the cron daemon is just scanning /etc/cron.d/* and treating it as if those lines had been appended to /etc/crontab I don't see why you couldn't just cp in the post-install. I think it would be better if you didn't have to 'register' a change. --=20 Allan Jude --nrHsfe2G5jHLkHwrrERj4FnXPAnVwFkNj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSfu4/AAoJEJrBFpNRJZKf/lcP/R56O6PfGHto18/d7UtC8cck jfbdo1s53NcyYwQLMyc67uZaBU7fe+GZtKvoC1rODaDEGaS4oujKRyQEtwgTCnsu 1GsUNnOU4MhZQmJjajiu7cJWzBeoUu2k0V7sobgABsUDAqk7TRzLaee12OeYNRvm +I4UPuLzLUVwFcAepW70ASHzWlv4vGZEE28bQIYsu+LP6/LvG30WWXU9AmzTpXhs GDrfjHiRMuvH4aex5DxkDBJ8KBq9lXjhKU0r9xsdDlY1NtFFRl9Mh6jTbsU7udIr eKX0cYbgTa6zxNuoLz0MYCuNp201CE0GlQYXmYHRDMDLRftj/87dSt/ONMmpiQh6 +i3NYwU8yrJJP6MvjciI19JjlEUJPcOdwUs0nJByUim2DkYfvB88dtVCoikIvcXE 9FSAHOL6njBwo9aqQ18Suifhyz/MJ2QbOClwBFoIBSQXsBpEVLxLWIO6eNRXGd4N GqqHUzYYcPWz8pzCFxYhC7Od3boOqdH0vFoTQ7+h/4wVOsDWrO8z5fVfMcPU70EA 835Hunjowb5YkiDI4zH55T+A2+jYsGd1/eaR+wtoCkJ22MvKEUSdfhtAmFjtvmCw XnZOxMx6M9WNeeZrzy+XtBwiraddWben0ruOkI1g3k59PUvefjRlRZXQ212AQSMk Rz6O9VSGM8MEaTEkeHuJ =ctJr -----END PGP SIGNATURE----- --nrHsfe2G5jHLkHwrrERj4FnXPAnVwFkNj-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 02:29:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0ACBCF2B; Sun, 10 Nov 2013 02:29:31 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D8803205F; Sun, 10 Nov 2013 02:29:30 +0000 (UTC) Received: by mail-pd0-f180.google.com with SMTP id p10so3700072pdj.25 for ; Sat, 09 Nov 2013 18:29:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=ti4p346gIw0xde26TCyVdO88+MAQyRzbAM23XB2Wm+k=; b=EsRkQ9ke3fIFMP5KUkK3bNzncy1MrddJVuW289tz1iQ/lopYpRvv62K30ZIVSXgTmq WK+ZpqwDIEdMQPZ2iYsC+UUgVzRWLpvaJhQ2VrNXosbYzJU+rW5xmtiSsv/QOn8r6Wnu J2cgDgvMUOC+KiEMgHk3KAJM1rda2wIx6dDz+MZgc3x5g44u8svOTl7FOSM4ztR4fZr+ bYuXEAoZrr3yGkv+zaauejhvnU6NW1IR3RV+h92TipLzFKw98f1yDfROJbMkXMMdxvy8 NO4LdiBfN51LVUVQXT2TCGokUfLF/YIF7RGMbkggaSJhhIScZTReATdtKcHgjCBMVS8X 9wAw== MIME-Version: 1.0 X-Received: by 10.66.218.226 with SMTP id pj2mr23837196pac.62.1384050570396; Sat, 09 Nov 2013 18:29:30 -0800 (PST) Received: by 10.68.57.72 with HTTP; Sat, 9 Nov 2013 18:29:30 -0800 (PST) Date: Sat, 9 Nov 2013 20:29:30 -0600 Message-ID: Subject: iwn(4) hangs after r257133 From: Brandon Gooch To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Cc: Adrian Chadd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 02:29:31 -0000 Turns out that not enabling MRR causes my Intel Ultimate N WiFi Link 5300 to hang after only a few moments of use. For now, I've just reverted only those aspects of r257133, enabling MRR and keeping the rate index lookup, which seems to do something on my hardware at least (I assume it's not the right thing based on Adrian's analysis, but it works never-the-less). Has anyone else hit this with Intel WiFi hardware? Also, what needs to be done to have MRR working properly? -Brandon From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 02:46:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 97CD72BA; Sun, 10 Nov 2013 02:46:53 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4815820F5; Sun, 10 Nov 2013 02:46:53 +0000 (UTC) Received: by mail-qc0-f177.google.com with SMTP id b10so807469qcw.36 for ; Sat, 09 Nov 2013 18:46:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4UG5nlmYxNK3xvZyyWTdB42dbKKwLUYFuk13IgDSHr4=; b=F/LRxzfgPCV5w1gOddIK5lNQAJ2ZGYPwc2vGYBys7YMDJqvQT7uYRvT7F26y37lJN6 Nkj6xZ/Bfu2EQFeQAy3AUoKm4Hg1CmIqDjkZrmscrTCvgKmSO445rAo9hvopK46cqen3 kMP813uOQ/cBnbiywetKkVbqNMVa+QK9FGHEcS7bSbCGzaZUKsZfHFc171BUK07iwQXZ fLU7Ub2orUrlkH2H4igRbP2OTbpW9iOxZOFpA1yGdWW8leD8ldHddJA2OpzJMp2feR8z Qx/q0o4R5EAkHgrk/tM0MObFltxjunxhHdAi6QPZr6K0WqhpFv+CoIkDUMX/Dgvlu5mH jZWA== MIME-Version: 1.0 X-Received: by 10.224.28.130 with SMTP id m2mr36627690qac.98.1384051612539; Sat, 09 Nov 2013 18:46:52 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Sat, 9 Nov 2013 18:46:52 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Nov 2013 18:46:52 -0800 X-Google-Sender-Auth: 8AOEOwHf3l0Y9jjERyrAjDQDoSg Message-ID: Subject: Re: iwn(4) hangs after r257133 From: Adrian Chadd To: Brandon Gooch , "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 02:46:53 -0000 Hi! On 9 November 2013 18:29, Brandon Gooch wrote: > Turns out that not enabling MRR causes my Intel Ultimate N WiFi Link > 5300 to hang after only a few moments of use. That's .. odd. Ok. > For now, I've just reverted only those aspects of r257133, enabling > MRR and keeping the rate index lookup, which seems to do something on > my hardware at least (I assume it's not the right thing based on > Adrian's analysis, but it works never-the-less). > > Has anyone else hit this with Intel WiFi hardware? > > Also, what needs to be done to have MRR working properly? So, it could be a fall out of how utterly crap AMRR is at 11n rates. Please compile with IWN_DEBUG, then do this before you associate: sysctl dev.iwn.0.debug=0x1 (that's IWN_DEBUG_XMIT in sys/dev/iwn/if_iwn_debug.h) You can do the same on a kernel with and without the MRR stuff enabled. I'd like to see what the actual rate selection looks like and what the final rate selection is. We may have to patch the kernel to print out the contents of 'rate' and 'tx->rate' in iwn_tx_data() to get that. The MRR stuff is a bit special. I don't know how the link table works in great depth yet. I know it's broken for 11n; it's plainly using the wrong indexes now. That's why I disabled it. It shouldn't take that much work to get it in the tree again; it'll just be fiddly. The easy bit is populating the table. The hard bit is knowing which index to set linkq to when transmitting a frame. -adrian From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 05:08:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BF9695E9; Sun, 10 Nov 2013 05:08:28 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8B44D2642; Sun, 10 Nov 2013 05:08:28 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id y13so968839pdi.14 for ; Sat, 09 Nov 2013 21:08:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a/QEp6YVg5k7svHJjmkqSC6hisv5Y0acsD+v7AocXnQ=; b=GBOhh/Ng/sg2urCPCo25t4pReDPWd24SXDJXfbXaOEhl6sfQm0gSilxhICakRxtKZP NV6UZlW2V8obNr4nIkdQDzzeiyZbGEjEOwC5Ocgu4A4T9dHiDtfQ7tIgWQ1JiS7972kE aExMT4A65wM+xhugdD6WKY6YQS45oZZ9ZVpKkO1u5naUQ5TJYUsMKSxQpF1zI5CURxZU uTS2aLikJ5cZBLo3UdFJDfQP1469ydoQklbao7WkY+aUXApoQtzWVpdC9tGXO+X/hpZu O2wrqo/YgchEEhUfd4nN8ZHvWo71etvl5dLkPkZumwC5rU0MR19bgHVYZWfDP7MUg6HK EMPw== MIME-Version: 1.0 X-Received: by 10.68.191.3 with SMTP id gu3mr18959pbc.142.1384060108188; Sat, 09 Nov 2013 21:08:28 -0800 (PST) Received: by 10.68.57.72 with HTTP; Sat, 9 Nov 2013 21:08:28 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Nov 2013 23:08:28 -0600 Message-ID: Subject: Re: iwn(4) hangs after r257133 From: Brandon Gooch To: Adrian Chadd Content-Type: multipart/mixed; boundary=e89a8ff1c37418c95804eacb9b8c X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-wireless@freebsd.org" , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 05:08:28 -0000 --e89a8ff1c37418c95804eacb9b8c Content-Type: text/plain; charset=ISO-8859-1 On Sat, Nov 9, 2013 at 8:46 PM, Adrian Chadd wrote: > Hi! > > On 9 November 2013 18:29, Brandon Gooch wrote: >> Turns out that not enabling MRR causes my Intel Ultimate N WiFi Link >> 5300 to hang after only a few moments of use. > > That's .. odd. Ok. > >> For now, I've just reverted only those aspects of r257133, enabling >> MRR and keeping the rate index lookup, which seems to do something on >> my hardware at least (I assume it's not the right thing based on >> Adrian's analysis, but it works never-the-less). >> >> Has anyone else hit this with Intel WiFi hardware? >> >> Also, what needs to be done to have MRR working properly? > > So, it could be a fall out of how utterly crap AMRR is at 11n rates. > > Please compile with IWN_DEBUG, then do this before you associate: > > sysctl dev.iwn.0.debug=0x1 > > (that's IWN_DEBUG_XMIT in sys/dev/iwn/if_iwn_debug.h) > > You can do the same on a kernel with and without the MRR stuff enabled. > > I'd like to see what the actual rate selection looks like and what the > final rate selection is. We may have to patch the kernel to print out > the contents of 'rate' and 'tx->rate' in iwn_tx_data() to get that. I've attached the log output, both with and without MRR. The output looks very much the same within iwn_tx_data(); in iwn5000_tx_done() things are clearly different. If I'm reading the rate conversion bits correctly, I see anywhere from 6 Mbps to 60 Mbps, with the the non-MRR module "getting stuck" -- I really don't know what has happened when it does this. Is there any further debugging output that would be helpful? -Brandon > The MRR stuff is a bit special. I don't know how the link table works > in great depth yet. I know it's broken for 11n; it's plainly using the > wrong indexes now. That's why I disabled it. It shouldn't take that > much work to get it in the tree again; it'll just be fiddly. The easy > bit is populating the table. The hard bit is knowing which index to > set linkq to when transmitting a frame. > > > > -adrian --e89a8ff1c37418c95804eacb9b8c-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 06:18:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C76B1CC1; Sun, 10 Nov 2013 06:18:42 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 775132881; Sun, 10 Nov 2013 06:18:42 +0000 (UTC) Received: by mail-qc0-f179.google.com with SMTP id k18so3223526qcv.10 for ; Sat, 09 Nov 2013 22:18:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=I2fy0r4ihOd9uO/QHPUiC8C5QGCdmPjxu2yPsj2Bzt4=; b=s9Tr0SwvdlHwGEoilPqRnmJee/R/wkvebBpBRErbx358sHQ1aRB5JVGu9byFuWTCjt qRe8EfeGEHe7d7OJvEw/cq3pThzFX2ziKivaM6KCuAOcs1UjoZ2v54Sv+8cGjzGB+pMC wNUGvOoRrQnc3Va8+C/Yb78NOEgBag7PlWFshptlsqC4pyOLqyklnvlxpgLGCvSsx6AI dRtw0FhW7hOA8aogAh9kg+mlo7Z1WpurSNba+DMiv3ncjQAoD/W1ywJvbGwIPekkHr1h THhwdqKxP3Egh0IdcnAev710KZOE7Fo/91uOYQS87XCZVAilp6EHSFa7ACvqnXWAr0D8 lMpw== MIME-Version: 1.0 X-Received: by 10.49.59.70 with SMTP id x6mr36083906qeq.17.1384064320964; Sat, 09 Nov 2013 22:18:40 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Sat, 9 Nov 2013 22:18:40 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Nov 2013 22:18:40 -0800 X-Google-Sender-Auth: UlgghoWcP8q-e19zZ2xyCpWxk0Y Message-ID: Subject: Re: iwn(4) hangs after r257133 From: Adrian Chadd To: Brandon Gooch Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 06:18:42 -0000 Sure, flip on 'wlandebug +rate' (assuming you compiled with IEEE80211_DEBUG) -a On 9 November 2013 21:08, Brandon Gooch wrote: > On Sat, Nov 9, 2013 at 8:46 PM, Adrian Chadd wrote: >> Hi! >> >> On 9 November 2013 18:29, Brandon Gooch wrote: >>> Turns out that not enabling MRR causes my Intel Ultimate N WiFi Link >>> 5300 to hang after only a few moments of use. >> >> That's .. odd. Ok. >> >>> For now, I've just reverted only those aspects of r257133, enabling >>> MRR and keeping the rate index lookup, which seems to do something on >>> my hardware at least (I assume it's not the right thing based on >>> Adrian's analysis, but it works never-the-less). >>> >>> Has anyone else hit this with Intel WiFi hardware? >>> >>> Also, what needs to be done to have MRR working properly? >> >> So, it could be a fall out of how utterly crap AMRR is at 11n rates. >> >> Please compile with IWN_DEBUG, then do this before you associate: >> >> sysctl dev.iwn.0.debug=0x1 >> >> (that's IWN_DEBUG_XMIT in sys/dev/iwn/if_iwn_debug.h) >> >> You can do the same on a kernel with and without the MRR stuff enabled. >> >> I'd like to see what the actual rate selection looks like and what the >> final rate selection is. We may have to patch the kernel to print out >> the contents of 'rate' and 'tx->rate' in iwn_tx_data() to get that. > > I've attached the log output, both with and without MRR. > > The output looks very much the same within iwn_tx_data(); in > iwn5000_tx_done() things are > clearly different. > > If I'm reading the rate conversion bits correctly, I see anywhere from > 6 Mbps to 60 Mbps, with the > the non-MRR module "getting stuck" -- I really don't know what has > happened when it does this. > > Is there any further debugging output that would be helpful? > > -Brandon > >> The MRR stuff is a bit special. I don't know how the link table works >> in great depth yet. I know it's broken for 11n; it's plainly using the >> wrong indexes now. That's why I disabled it. It shouldn't take that >> much work to get it in the tree again; it'll just be fiddly. The easy >> bit is populating the table. The hard bit is knowing which index to >> set linkq to when transmitting a frame. >> >> >> >> -adrian From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 06:20:16 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DAC50DE7; Sun, 10 Nov 2013 06:20:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x235.google.com (mail-qe0-x235.google.com [IPv6:2607:f8b0:400d:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8BED32896; Sun, 10 Nov 2013 06:20:15 +0000 (UTC) Received: by mail-qe0-f53.google.com with SMTP id cy11so3471541qeb.12 for ; Sat, 09 Nov 2013 22:20:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=nOAzUpuZLwiOZqBwM0MBrWAXgbhZQhYT/4l7z5/dtvU=; b=GE54VnHwvZL4j3EhyZ2SPIcH1NG13UZkvztBmmjusEipRyCub5Yuo1o3/fIVGPCdCT o3vIpXIWcJz5W5zl1k8oB4oJ8WK3I+FMD0nSN8GvKiP9bKbKiL25y9qtkcxZ+GmlT3bo Ev4e+bCIyHlI5Jb1VOEM3sszallJbcB6aSd5FOnX/tYDye8gLI+L8SBNrUazEdvw3G0x +A16OkQglAqxqr90cDPTtbwbFby2jUUVJOlQZGvng6uiIvaMfNb+Lv5GYkAeYfQD9ihK NLDVaMMP0tFbuLDowbJkxIPUfkI7NEYf7cfS1WBeNXnd7+7f1lf1wRQgr7EGPpFdF36L uGZA== MIME-Version: 1.0 X-Received: by 10.49.19.101 with SMTP id d5mr36206753qee.78.1384064414800; Sat, 09 Nov 2013 22:20:14 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Sat, 9 Nov 2013 22:20:14 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Nov 2013 22:20:14 -0800 X-Google-Sender-Auth: 8_TWKL1JMD7jG1w5jlopM0PSCMk Message-ID: Subject: Re: iwn(4) hangs after r257133 From: Adrian Chadd To: Brandon Gooch Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 06:20:16 -0000 Oh, and you need to print out the tx->rate field using "0x%04x", rather than %d. The completion value is in hex. -adrian On 9 November 2013 22:18, Adrian Chadd wrote: > Sure, flip on 'wlandebug +rate' (assuming you compiled with IEEE80211_DEBUG) > > > -a > > On 9 November 2013 21:08, Brandon Gooch wrote: >> On Sat, Nov 9, 2013 at 8:46 PM, Adrian Chadd wrote: >>> Hi! >>> >>> On 9 November 2013 18:29, Brandon Gooch wrote: >>>> Turns out that not enabling MRR causes my Intel Ultimate N WiFi Link >>>> 5300 to hang after only a few moments of use. >>> >>> That's .. odd. Ok. >>> >>>> For now, I've just reverted only those aspects of r257133, enabling >>>> MRR and keeping the rate index lookup, which seems to do something on >>>> my hardware at least (I assume it's not the right thing based on >>>> Adrian's analysis, but it works never-the-less). >>>> >>>> Has anyone else hit this with Intel WiFi hardware? >>>> >>>> Also, what needs to be done to have MRR working properly? >>> >>> So, it could be a fall out of how utterly crap AMRR is at 11n rates. >>> >>> Please compile with IWN_DEBUG, then do this before you associate: >>> >>> sysctl dev.iwn.0.debug=0x1 >>> >>> (that's IWN_DEBUG_XMIT in sys/dev/iwn/if_iwn_debug.h) >>> >>> You can do the same on a kernel with and without the MRR stuff enabled. >>> >>> I'd like to see what the actual rate selection looks like and what the >>> final rate selection is. We may have to patch the kernel to print out >>> the contents of 'rate' and 'tx->rate' in iwn_tx_data() to get that. >> >> I've attached the log output, both with and without MRR. >> >> The output looks very much the same within iwn_tx_data(); in >> iwn5000_tx_done() things are >> clearly different. >> >> If I'm reading the rate conversion bits correctly, I see anywhere from >> 6 Mbps to 60 Mbps, with the >> the non-MRR module "getting stuck" -- I really don't know what has >> happened when it does this. >> >> Is there any further debugging output that would be helpful? >> >> -Brandon >> >>> The MRR stuff is a bit special. I don't know how the link table works >>> in great depth yet. I know it's broken for 11n; it's plainly using the >>> wrong indexes now. That's why I disabled it. It shouldn't take that >>> much work to get it in the tree again; it'll just be fiddly. The easy >>> bit is populating the table. The hard bit is knowing which index to >>> set linkq to when transmitting a frame. >>> >>> >>> >>> -adrian From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 08:45:46 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0F7D7AD9; Sun, 10 Nov 2013 08:45:46 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D59A52DBB; Sun, 10 Nov 2013 08:45:45 +0000 (UTC) Received: from julian-mbp3.pixel8networks.com (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id rAA8jb2J066229 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 10 Nov 2013 00:45:38 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <527F47AC.50705@freebsd.org> Date: Sun, 10 Nov 2013 00:45:32 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org, "George V. Neville-Neil" Subject: Re: freebsd perf testing References: <527C462F.9040707@elischer.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 08:45:46 -0000 On 11/9/13, 1:24 PM, Erik Cederstrand wrote: > Hi Julian, > > Den 08/11/2013 kl. 03.02 skrev Julian Elischer : > >> Some time ago someone showed some freebsd performance graphs graphed against time. >> He had them up on a website that was updated each day or so. >> >> I think they were network perf tests but I'm not sure. >> He indicated that he was going to continue the daily testing >> but I've not seen any mention of them since. >> >> If you know who that was or how to find him let me (or gnn) know... > I did a master’s thesis on this some years ago. I haven’t kept the project up-to-date, due to lack of time and hardware. it would be interesting to know what you did. and what conclusions you came to.. the actual web page I was thinkng of was: http://lists.freebsd.org/pipermail/freebsd-current/2013-April/041323.html but the more players we have thinking about this the better.. it would be good if we could have some project supported way to follow this. it may be that we could make a 'contributor' image that has all the tools and framework on it that would allow people to submit daily reports (from the same hardware each time) to some central aggregator.. or maybe ot would all be project resources. I see that Mr Symbolics (is that his real name?) has some suggestions in another mail in this thread. I wasn't really going to be doing much in this space myself though I think it is important, I just volunteered in the meeting to try find some examples. Julian > > Erik > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 12:17:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C2D8BE1F; Sun, 10 Nov 2013 12:17:53 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep14.mx.upcmail.net (fep14.mx.upcmail.net [62.179.121.34]) by mx1.freebsd.org (Postfix) with ESMTP id DA3F8270A; Sun, 10 Nov 2013 12:17:52 +0000 (UTC) Received: from edge01.upcmail.net ([192.168.13.236]) by viefep14-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20131110121751.EXU23106.viefep14-int.chello.at@edge01.upcmail.net>; Sun, 10 Nov 2013 13:17:51 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge01.upcmail.net with edge id noHe1m00Y2xdvHc01oHekh; Sun, 10 Nov 2013 13:17:40 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id 271AB6D44C; Sun, 10 Nov 2013 13:17:38 +0100 (CET) Date: Sun, 10 Nov 2013 13:17:38 +0100 From: Stefan Farfeleder To: Brandon Gooch Subject: Re: iwn(4) hangs after r257133 Message-ID: <20131110121737.GA1834@mole.fafoe.narf.at> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: Adrian Chadd , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 12:17:53 -0000 On Sat, Nov 09, 2013 at 08:29:30PM -0600, Brandon Gooch wrote: > Turns out that not enabling MRR causes my Intel Ultimate N WiFi Link > 5300 to hang after only a few moments of use. > > For now, I've just reverted only those aspects of r257133, enabling > MRR and keeping the rate index lookup, which seems to do something on > my hardware at least (I assume it's not the right thing based on > Adrian's analysis, but it works never-the-less). > > Has anyone else hit this with Intel WiFi hardware? > > Also, what needs to be done to have MRR working properly? Hi, I have problems with iwn (Intel WiFi Link 5100) as well. Unlike my previous problems, it associates properly and works fine, at first. But then, after some minutes, the link quality somehow deteriorates and I see serious packet drops. Usually it gets back to normal some minutes later, but restarting the interface "fixes" the problem. I don't think it's a problem with the signal itself, because other devices next to the notebook work just fine during that intervals. Adrian, do you have any ideas, or some data you want from me? Stefan From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 13:14:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A86E3778; Sun, 10 Nov 2013 13:14:59 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 578262A0B; Sun, 10 Nov 2013 13:14:59 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id k4so1039342qaq.5 for ; Sun, 10 Nov 2013 05:14:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=gCzs9enMzqjBI5+D5hUYgbc9khaveCJbJbx+1nMUnik=; b=jPZZaKV9IaWFsMJBHZZRafpmGuLuc0ui6la3Evy7R5FQB+vefR5GcKzt90SwnE69z6 DO0TbUgv+VkF73w6YTC+79FxqARCr2qTUiPEKxdO7HT5Q3NUiZbGDvg51BzLz8he4cfw +oRkpXgdnjZfb+BljM+Fl59zVO1pUMnO70/Dyh78M2I6H+5G5LXe3uNC3QkQqodsCtpw MgCfS0vzgol6MSzEDz1KA9df2oJOYEPoNUeBWP9Ii04Y6xC4iy32uG3dQyyfPjqSmaJ+ +agEgRDedjcoJU+Ccd8pHXp4rLtnbuO5EcWFzNISxIbxs5WhbzqKLFSfTCkmjMgc6P7a 3lbQ== MIME-Version: 1.0 X-Received: by 10.49.71.207 with SMTP id x15mr38649485qeu.49.1384089298426; Sun, 10 Nov 2013 05:14:58 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Sun, 10 Nov 2013 05:14:58 -0800 (PST) In-Reply-To: <20131110121737.GA1834@mole.fafoe.narf.at> References: <20131110121737.GA1834@mole.fafoe.narf.at> Date: Sun, 10 Nov 2013 05:14:58 -0800 X-Google-Sender-Auth: _ywop-ht8jkO9gzE9z6sNLC-7q0 Message-ID: Subject: Re: iwn(4) hangs after r257133 From: Adrian Chadd To: Stefan Farfeleder Content-Type: text/plain; charset=ISO-8859-1 Cc: Brandon Gooch , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 13:14:59 -0000 yup, same info as brandon. :) -a On 10 November 2013 04:17, Stefan Farfeleder wrote: > On Sat, Nov 09, 2013 at 08:29:30PM -0600, Brandon Gooch wrote: >> Turns out that not enabling MRR causes my Intel Ultimate N WiFi Link >> 5300 to hang after only a few moments of use. >> >> For now, I've just reverted only those aspects of r257133, enabling >> MRR and keeping the rate index lookup, which seems to do something on >> my hardware at least (I assume it's not the right thing based on >> Adrian's analysis, but it works never-the-less). >> >> Has anyone else hit this with Intel WiFi hardware? >> >> Also, what needs to be done to have MRR working properly? > > Hi, > > I have problems with iwn (Intel WiFi Link 5100) as well. > > Unlike my previous problems, it associates properly and works fine, at > first. But then, after some minutes, the link quality somehow > deteriorates and I see serious packet drops. Usually it gets back to > normal some minutes later, but restarting the interface "fixes" the > problem. I don't think it's a problem with the signal itself, because > other devices next to the notebook work just fine during that intervals. > > Adrian, do you have any ideas, or some data you want from me? > > Stefan From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 14:04:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6B3FC5F5 for ; Sun, 10 Nov 2013 14:04:21 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1F5292C9E for ; Sun, 10 Nov 2013 14:04:20 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id rAAE4DSs021501 for ; Sun, 10 Nov 2013 09:04:19 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <527F925D.5030201@m5p.com> Date: Sun, 10 Nov 2013 09:04:13 -0500 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: cron(8) improvement References: <52792B60.1030309@allanjude.com> <527BCA55.2000207@allanjude.com> <527C5D52.7030508@allanjude.com> <047405A8-B6EB-427B-A2E4-6254DD1A077B@orthanc.ca> <3E6377FF-69FE-48E4-BFB1-E5095A7FA1BB@orthanc.ca> <527C6DEF.6020102@allanjude.com> <527E3EB3.6000301@FreeBSD.org> <8034B822-F903-43D1-8BF6-DFAD7C22F5B0@gsoft.com.au> <527ED34A.1060401@allanjude.com> <527EE417.6060704@allanjude.com> <527EE84D.4060901@allanjude.com> <527EEE3D.9000101@allanjude.com> In-Reply-To: <527EEE3D.9000101@allanjude.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Sun, 10 Nov 2013 09:04:19 -0500 (EST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 14:04:21 -0000 On 11/09/13 21:23, Allan Jude wrote: > On 2013-11-09 21:13, Adrian Chadd wrote: >> On 9 November 2013 17:58, Allan Jude wrote: >> >>> Well, if the rc.conf config is specific to the daemon being installed by >>> the package, then the existing /etc/rc.conf.d/ system works fine, it >>> just falls down a little on xorg configuring hald, unless you just make >>> the xorg package create /etc/rc.conf.d/hald and /etc/rc.conf.d/dbus >> If I install hal/dbus, why wouldn't they themselves populate >> /etc/rc.conf.d/hald and /etc/rc.conf.d/dbus ? >> >> If there are hal/dbus options that need configuring by other packages, >> then sure, you'll need to add some other things too. > ahh, right, why didn't I think of that > >>> I like the simplicity of rc.conf, and I would much rather not involve an >>> sqlite database, I am not sure how that could possibly be faster then >>> sourcing an extra shell script. >> Don't focus on that. The sqlite example is just that - an example - >> showing what kind of operations you would want to implement to _allow_ >> you to do that. I'm not advocating for doing it in freebsd-base. >> >> The point I'm making is this: >> >> * when populating rc.conf.d/, don't just do 'cp' in a post-install script >> * when populating the cron daemon entries in rc.cron.d, don't just >> 'cp' in a post-install script. >> >> >> -adrian > > If the cron daemon is just scanning /etc/cron.d/* and treating it as if > those lines had been appended to /etc/crontab I don't see why you > couldn't just cp in the post-install. I think it would be better if you > didn't have to 'register' a change. > > For this whole thread, please s,/etc/rc.d,/usr/local/etc/rc.d,g -- George From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 14:19:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DAC84E5A for ; Sun, 10 Nov 2013 14:19:19 +0000 (UTC) (envelope-from dt71@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7145D2D4F for ; Sun, 10 Nov 2013 14:19:19 +0000 (UTC) Received: from [157.181.98.186] ([157.181.98.186]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LqQnR-1W9sac2O13-00e7UP for ; Sun, 10 Nov 2013 15:19:11 +0100 Message-ID: <527F95BE.7080908@gmx.com> Date: Sun, 10 Nov 2013 15:18:38 +0100 From: dt71@gmx.com User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:23.0) Gecko/20100101 Firefox/23.0 SeaMonkey/2.20 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: new Xorg (KMS, etc.) for Radeon 9600 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:DtQ0FdprJiZ5yyVHbIj8uXjmgYqzzUqVHadoiVsGI+ZuJBUJuEd fQRg5ZnBVMqlAAux5BXGVCfxWf73YLg4Gb3X1/cIb70tHUuGS7GbcVnr/y3PCyUjI9RXM3d RjgY2seacBm2offCASVt452c+KuCejGSOygAFVa3H13e+Tps4H0CneVICMBjQo5Xqv142vh 4saj1ThXZR0skDUz0ZtHA== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 14:19:19 -0000 I've built the ports with the following lines in my /etc/make.conf: WITH_NEW_XORG=1 WITH_KMS=1 WITH_GALLIUM=1 And I've attempted to run ``startx''. The compiler was a very recent version of Clang. When building the kernel (not the ports): ============== /etc/make.conf snippet begins ============== CPUTYPE?=native CXXFLAGS+= -stdlib=libc++ KERNCONF=MYKERNCONF MODULES_OVERRIDE="drm2" ============== /etc/make.conf snippet ends ============== ============== /sys/i386/conf/MYKERNCONF begins ============== cpu I686_CPU ident MYKERNCONF options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options MSDOSFS # MSDOS Filesystem options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=1000 # Delay (in ms) before probing SCSI options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. # To make an SMP kernel, the next two lines are needed options SMP # Symmetric MultiProcessor Kernel device apic # I/O APIC # Bus support. device acpi device pci # ATA controllers device ata # Legacy ATA/SATA controllers # ATA/SCSI peripherals device scbus # SCSI bus (required for ATA/SCSI) device da # Direct Access (disks) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device vga # VGA video card driver # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device rl # RealTek 8129/8139 # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device md # Memory "disks" device firmware # firmware assist module # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse # Sound support device sound # Generic sound driver (required) device snd_ich # Intel, NVidia and other ICH AC'97 Audio device drm device radeondrm device iicbus device iic device iicbb ============== /sys/i386/conf/MYKERNCONF ends ============== ============== /etc/X11/xorg.conf begins ============== Section "ServerFlags" Option "DontZoom" "on" Option "VTSysReq" "on" # #Option "BlankTime" "1" # #Option "StandbyTime" "2" # #Option "SuspendTime" "3" # #Option "OffTime" "4" # Option "HandleSpecialKeys" "Always" Option "AIGLX" "off" Option "GlxVisuals" "minimal" Option "AllowEmptyInput" "off" Option "AutoAddDevices" "off" Option "AutoEnableDevices" "off" EndSection Section "InputDevice" Identifier "mouse1" Driver "mouse" Option "Device" "/dev/ums0" EndSection Section "InputDevice" Identifier "keyboard1" Driver "kbd" Option "XkbLayout" "us,hu" Option "AutoRepeat" "320 29" EndSection Section "Device" Identifier "card1" Driver "radeon" VideoRam 131072 #Option "ScalerWidth" "1920" Option "AGPMode" "8" #Option "AGPFastWrite" "on" # sux Option "BusType" "AGP" Option "DisplayPriority" "HIGH" Option "EnablePageFlip" "on" Option "AccelMethod" "XAA" # "EXA" sux Option "AccelDFS" "on" Option "FBTexPercent" "0" #Option "SubPixelOrder" "NONE" Option "LVDSProbePLL" "off" #Option "DefaultTMDSPLL" "on" #Option "DefaultTVDACAdj" "on" Option "Int10" "off" Option "R4xxATOM" "on" EndSection Section "Monitor" Identifier "monitor1" HorizSync 40-80 VertRefresh 56-75 #DisplaySize W H # mm EndSection Section "Screen" Identifier "screen1" Device "card1" Monitor "monitor1" DefaultDepth 24 DefaultFbBpp 32 Option "Int10" "off" Option "MTRR" "on" SubSection "Display" Depth 24 FbBpp 32 Modes "1280x1024" "1024x768" "800x600" "640x480" EndSubSection EndSection Section "ServerLayout" Identifier "layout1" Screen "screen1" InputDevice "mouse1" "CorePointer" InputDevice "keyboard1" "CoreKeyboard" EndSection ============== /etc/X11/xorg.conf ends ============== 1st attempt: failure. ============== /var/log/Xorg.log begins ============== [ 205.270] _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 [ 205.270] _XSERVTransOpen: transport open failed for inet6/:0 [ 205.270] _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 [ 205.324] X.Org X Server 1.12.4 Release Date: 2012-08-27 [ 205.324] X Protocol Version 11, Revision 0 [ 205.324] Build Operating System: FreeBSD 11.0-CURRENT i386 [ 205.324] Current Operating System: FreeBSD 11.0-CURRENT FreeBSD 11.0-CURRENT #4 r257831M: Sun Nov 10 03:46:35 CET 2013 root@:/usr/obj/usr/src/sys/CUSTOM i386 [ 205.325] Build Date: 09 November 2013 11:19:35PM [ 205.325] [ 205.325] Current version of pixman: 0.30.2 [ 205.325] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 205.325] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 205.325] (==) Log file: "/var/log/Xorg.0.log", Time: Sun Nov 10 14:05:57 2013 [ 205.390] (==) Using config file: "/etc/X11/xorg.conf" [ 205.399] (==) ServerLayout "layout1" [ 205.399] (**) |-->Screen "screen1" (0) [ 205.399] (**) | |-->Monitor "monitor1" [ 205.417] (**) | |-->Device "card1" [ 205.417] (**) |-->Input Device "mouse1" [ 205.417] (**) |-->Input Device "keyboard1" [ 205.417] (**) Option "DontZoom" "on" [ 205.417] (**) Option "AIGLX" "off" [ 205.417] (**) Option "AutoAddDevices" "off" [ 205.417] (**) Option "AutoEnableDevices" "off" [ 205.417] (**) Option "GlxVisuals" "minimal" [ 205.417] (**) Not automatically adding devices [ 205.417] (**) Not automatically enabling devices [ 205.582] (==) FontPath set to: /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF/, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/ [ 205.582] (==) ModulePath set to "/usr/local/lib/xorg/modules" [ 205.582] (II) Loader magic: 0x81f0298 [ 205.582] (II) Module ABI versions: [ 205.582] X.Org ANSI C Emulation: 0.4 [ 205.582] X.Org Video Driver: 12.1 [ 205.582] X.Org XInput driver : 16.0 [ 205.582] X.Org Server Extension : 6.0 [ 205.597] (--) PCI:*(0:1:0:0) 1002:4150:17ee:2002 rev 0, Mem @ 0xd0000000/268435456, 0xff0f0000/65536, I/O @ 0x0000a800/256, BIOS @ 0x????????/65536 [ 205.597] (--) PCI: (0:1:0:1) 1002:4170:17ee:2003 rev 0, Mem @ 0xc0000000/268435456, 0xff0e0000/65536 [ 205.597] (II) LoadModule: "extmod" [ 205.611] (II) Loading /usr/local/lib/xorg/modules/extensions/libextmod.so [ 205.626] (II) Module extmod: vendor="X.Org Foundation" [ 205.626] compiled for 1.12.4, module version = 1.0.0 [ 205.626] Module class: X.Org Server Extension [ 205.626] ABI class: X.Org Server Extension, version 6.0 [ 205.626] (II) Loading extension MIT-SCREEN-SAVER [ 205.626] (II) Loading extension XFree86-VidModeExtension [ 205.626] (II) Loading extension XFree86-DGA [ 205.626] (II) Loading extension DPMS [ 205.626] (II) Loading extension XVideo [ 205.626] (II) Loading extension XVideo-MotionCompensation [ 205.627] (II) Loading extension X-Resource [ 205.627] (II) LoadModule: "dbe" [ 205.627] (II) Loading /usr/local/lib/xorg/modules/extensions/libdbe.so [ 205.635] (II) Module dbe: vendor="X.Org Foundation" [ 205.635] compiled for 1.12.4, module version = 1.0.0 [ 205.635] Module class: X.Org Server Extension [ 205.635] ABI class: X.Org Server Extension, version 6.0 [ 205.635] (II) Loading extension DOUBLE-BUFFER [ 205.635] (II) LoadModule: "glx" [ 205.635] (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so [ 205.661] (II) Module glx: vendor="X.Org Foundation" [ 205.661] compiled for 1.12.4, module version = 1.0.0 [ 205.661] ABI class: X.Org Server Extension, version 6.0 [ 205.665] (**) AIGLX disabled [ 205.671] (II) Loading extension GLX [ 205.671] (II) LoadModule: "record" [ 205.671] (II) Loading /usr/local/lib/xorg/modules/extensions/librecord.so [ 205.683] (II) Module record: vendor="X.Org Foundation" [ 205.683] compiled for 1.12.4, module version = 1.13.0 [ 205.683] Module class: X.Org Server Extension [ 205.683] ABI class: X.Org Server Extension, version 6.0 [ 205.683] (II) Loading extension RECORD [ 205.683] (II) LoadModule: "dri" [ 205.683] (II) Loading /usr/local/lib/xorg/modules/extensions/libdri.so [ 205.732] (II) Module dri: vendor="X.Org Foundation" [ 205.732] compiled for 1.12.4, module version = 1.0.0 [ 205.732] ABI class: X.Org Server Extension, version 6.0 [ 205.732] (II) Loading extension XFree86-DRI [ 205.732] (II) LoadModule: "dri2" [ 205.732] (II) Loading /usr/local/lib/xorg/modules/extensions/libdri2.so [ 205.746] (II) Module dri2: vendor="X.Org Foundation" [ 205.746] compiled for 1.12.4, module version = 1.2.0 [ 205.746] ABI class: X.Org Server Extension, version 6.0 [ 205.746] (II) Loading extension DRI2 [ 205.746] (II) LoadModule: "radeon" [ 205.786] (II) Loading /usr/local/lib/xorg/modules/drivers/radeon_drv.so [ 205.865] (II) Module radeon: vendor="X.Org Foundation" [ 205.865] compiled for 1.12.4, module version = 7.2.0 [ 205.865] Module class: X.Org Video Driver [ 205.865] ABI class: X.Org Video Driver, version 12.1 [ 205.865] (II) LoadModule: "mouse" [ 205.866] (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.so [ 205.916] (II) Module mouse: vendor="X.Org Foundation" [ 205.916] compiled for 1.12.4, module version = 1.9.0 [ 205.916] Module class: X.Org XInput Driver [ 205.916] ABI class: X.Org XInput driver, version 16.0 [ 205.916] (II) LoadModule: "kbd" [ 205.917] (II) Loading /usr/local/lib/xorg/modules/input/kbd_drv.so [ 205.932] (II) Module kbd: vendor="X.Org Foundation" [ 205.932] compiled for 1.12.4, module version = 1.7.0 [ 205.932] Module class: X.Org XInput Driver [ 205.932] ABI class: X.Org XInput driver, version 16.0 [ 205.932] (II) RADEON: Driver for ATI Radeon chipsets: ATI Radeon Mobility X600 (M24) 3150 (PCIE), ATI FireMV 2400 (PCI), ATI Radeon Mobility X300 (M24) 3152 (PCIE), ATI FireGL M24 GL 3154 (PCIE), ATI FireMV 2400 3155 (PCI), ATI Radeon X600 (RV380) 3E50 (PCIE), ATI FireGL V3200 (RV380) 3E54 (PCIE), ATI Radeon IGP320 (A3) 4136, ATI Radeon IGP330/340/350 (A4) 4137, ATI Radeon 9500 AD (AGP), ATI Radeon 9500 AE (AGP), ATI Radeon 9600TX AF (AGP), ATI FireGL Z1 AG (AGP), ATI Radeon 9800SE AH (AGP), ATI Radeon 9800 AI (AGP), ATI Radeon 9800 AJ (AGP), ATI FireGL X2 AK (AGP), ATI Radeon 9600 AP (AGP), ATI Radeon 9600SE AQ (AGP), ATI Radeon 9600XT AR (AGP), ATI Radeon 9600 AS (AGP), ATI FireGL T2 AT (AGP), ATI Radeon 9650, ATI FireGL RV360 AV (AGP), ATI Radeon 7000 IGP (A4+) 4237, ATI Radeon 8500 AIW BB (AGP), ATI Radeon IGP320M (U1) 4336, ATI Radeon IGP330M/340M/350M (U2) 4337, ATI Radeon Mobility 7000 IGP 4437, ATI Radeon 9000/PRO If (AGP/PCI), ATI Radeon 9000 Ig (AGP/PCI), ATI Radeon X800 (R420) JH (AGP), ATI Radeon X800PRO (R420) JI (AGP), ATI Radeon X800SE (R420) JJ (AGP), ATI Radeon X800 (R420) JK (AGP), ATI Radeon X800 (R420) JL (AGP), ATI FireGL X3 (R420) JM (AGP), ATI Radeon Mobility 9800 (M18) JN (AGP), ATI Radeon X800 SE (R420) (AGP), ATI Radeon X800XT (R420) JP (AGP), ATI Radeon X800 VE (R420) JT (AGP), ATI Radeon X850 (R480) (AGP), ATI Radeon X850 XT (R480) (AGP), ATI Radeon X850 SE (R480) (AGP), ATI Radeon X850 PRO (R480) (AGP), ATI Radeon X850 XT PE (R480) (AGP), ATI Radeon Mobility M7 LW (AGP), ATI Mobility FireGL 7800 M7 LX (AGP), ATI Radeon Mobility M6 LY (AGP), ATI Radeon Mobility M6 LZ (AGP), ATI FireGL Mobility 9000 (M9) Ld (AGP), ATI Radeon Mobility 9000 (M9) Lf (AGP), ATI Radeon Mobility 9000 (M9) Lg (AGP), ATI FireMV 2400 PCI, ATI Radeon 9700 Pro ND (AGP), ATI Radeon 9700/9500Pro NE (AGP), ATI Radeon 9600TX NF (AGP), ATI FireGL X1 NG (AGP), ATI Radeon 9800PRO NH (AGP), ATI Radeon 9800 NI (AGP), ATI FireGL X2 NK (AGP), ATI Radeon 9800XT NJ (AGP), ATI Radeon Mobility 9600/9700 (M10/M11) NP (AGP), ATI Radeon Mobility 9600 (M10) NQ (AGP), ATI Radeon Mobility 9600 (M11) NR (AGP), ATI Radeon Mobility 9600 (M10) NS (AGP), ATI FireGL Mobility T2 (M10) NT (AGP), ATI FireGL Mobility T2e (M11) NV (AGP), ATI Radeon QD (AGP), ATI Radeon QE (AGP), ATI Radeon QF (AGP), ATI Radeon QG (AGP), ATI FireGL 8700/8800 QH (AGP), ATI Radeon 8500 QL (AGP), ATI Radeon 9100 QM (AGP), ATI Radeon 7500 QW (AGP/PCI), ATI Radeon 7500 QX (AGP/PCI), ATI Radeon VE/7000 QY (AGP/PCI), ATI Radeon VE/7000 QZ (AGP/PCI), ATI ES1000 515E (PCI), ATI Radeon Mobility X300 (M22) 5460 (PCIE), ATI Radeon Mobility X600 SE (M24C) 5462 (PCIE), ATI FireGL M22 GL 5464 (PCIE), ATI Radeon X800 (R423) UH (PCIE), ATI Radeon X800PRO (R423) UI (PCIE), ATI Radeon X800LE (R423) UJ (PCIE), ATI Radeon X800SE (R423) UK (PCIE), ATI Radeon X800 XTP (R430) (PCIE), ATI Radeon X800 XL (R430) (PCIE), ATI Radeon X800 SE (R430) (PCIE), ATI Radeon X800 (R430) (PCIE), ATI FireGL V7100 (R423) (PCIE), ATI FireGL V5100 (R423) UQ (PCIE), ATI FireGL unknown (R423) UR (PCIE), ATI FireGL unknown (R423) UT (PCIE), ATI Mobility FireGL V5000 (M26) (PCIE), ATI Mobility FireGL V5000 (M26) (PCIE), ATI Mobility Radeon X700 XL (M26) (PCIE), ATI Mobility Radeon X700 (M26) (PCIE), ATI Mobility Radeon X700 (M26) (PCIE), ATI Radeon X550XTX 5657 (PCIE), ATI Radeon 9100 IGP (A5) 5834, ATI Radeon Mobility 9100 IGP (U3) 5835, ATI Radeon XPRESS 200 5954 (PCIE), ATI Radeon XPRESS 200M 5955 (PCIE), ATI Radeon 9250 5960 (AGP), ATI Radeon 9200 5961 (AGP), ATI Radeon 9200 5962 (AGP), ATI Radeon 9200SE 5964 (AGP), ATI FireMV 2200 (PCI), ATI ES1000 5969 (PCI), ATI Radeon XPRESS 200 5974 (PCIE), ATI Radeon XPRESS 200M 5975 (PCIE), ATI Radeon XPRESS 200 5A41 (PCIE), ATI Radeon XPRESS 200M 5A42 (PCIE), ATI Radeon XPRESS 200 5A61 (PCIE), ATI Radeon XPRESS 200M 5A62 (PCIE), ATI Radeon X300 (RV370) 5B60 (PCIE), ATI Radeon X600 (RV370) 5B62 (PCIE), ATI Radeon X550 (RV370) 5B63 (PCIE), ATI FireGL V3100 (RV370) 5B64 (PCIE), ATI FireMV 2200 PCIE (RV370) 5B65 (PCIE), ATI Radeon Mobility 9200 (M9+) 5C61 (AGP), ATI Radeon Mobility 9200 (M9+) 5C63 (AGP), ATI Mobility Radeon X800 XT (M28) (PCIE), ATI Mobility FireGL V5100 (M28) (PCIE), ATI Mobility Radeon X800 (M28) (PCIE), ATI Radeon X850 5D4C (PCIE), ATI Radeon X850 XT PE (R480) (PCIE), ATI Radeon X850 SE (R480) (PCIE), ATI Radeon X850 PRO (R480) (PCIE), ATI unknown Radeon / FireGL (R480) 5D50 (PCIE), ATI Radeon X850 XT (R480) (PCIE), ATI Radeon X800XT (R423) 5D57 (PCIE), ATI FireGL V5000 (RV410) (PCIE), ATI Radeon X700 XT (RV410) (PCIE), ATI Radeon X700 PRO (RV410) (PCIE), ATI Radeon X700 SE (RV410) (PCIE), ATI Radeon X700 (RV410) (PCIE), ATI Radeon X700 SE (RV410) (PCIE), ATI Radeon X1800, ATI Mobility Radeon X1800 XT, ATI Mobility Radeon X1800, ATI Mobility FireGL V7200, ATI FireGL V7200, ATI FireGL V5300, ATI Mobility FireGL V7100, ATI Radeon X1800, ATI Radeon X1800, ATI Radeon X1800, ATI Radeon X1800, ATI Radeon X1800, ATI FireGL V7300, ATI FireGL V7350, ATI Radeon X1600, ATI RV505, ATI Radeon X1300/X1550, ATI Radeon X1550, ATI M54-GL, ATI Mobility Radeon X1400, ATI Radeon X1300/X1550, ATI Radeon X1550 64-bit, ATI Mobility Radeon X1300, ATI Mobility Radeon X1300, ATI Mobility Radeon X1300, ATI Mobility Radeon X1300, ATI Radeon X1300, ATI Radeon X1300, ATI RV505, ATI RV505, ATI FireGL V3300, ATI FireGL V3350, ATI Radeon X1300, ATI Radeon X1550 64-bit, ATI Radeon X1300/X1550, ATI Radeon X1600, ATI Radeon X1300/X1550, ATI Mobility Radeon X1450, ATI Radeon X1300/X1550, ATI Mobility Radeon X2300, ATI Mobility Radeon X2300, ATI Mobility Radeon X1350, ATI Mobility Radeon X1350, ATI Mobility Radeon X1450, ATI Radeon X1300, ATI Radeon X1550, ATI Mobility Radeon X1350, ATI FireMV 2250, ATI Radeon X1550 64-bit, ATI Radeon X1600, ATI Radeon X1650, ATI Radeon X1600, ATI Radeon X1600, ATI Mobility FireGL V5200, ATI Mobility Radeon X1600, ATI Radeon X1650, ATI Radeon X1650, ATI Radeon X1600, ATI Radeon X1300 XT/X1600 Pro, ATI FireGL V3400, ATI Mobility FireGL V5250, ATI Mobility Radeon X1700, ATI Mobility Radeon X1700 XT, ATI FireGL V5200, ATI Mobility Radeon X1700, ATI Radeon X2300HD, ATI Mobility Radeon HD 2300, ATI Mobility Radeon HD 2300, ATI Radeon X1950, ATI Radeon X1900, ATI Radeon X1950, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI AMD Stream Processor, ATI Radeon X1900, ATI Radeon X1950, ATI RV560, ATI RV560, ATI Mobility Radeon X1900, ATI RV560, ATI Radeon X1950 GT, ATI RV570, ATI RV570, ATI FireGL V7400, ATI RV560, ATI Radeon X1650, ATI Radeon X1650, ATI RV560, ATI Radeon 9100 PRO IGP 7834, ATI Radeon Mobility 9200 IGP 7835, ATI Radeon X1200, ATI Radeon X1200, ATI Radeon X1200, ATI Radeon X1200, ATI Radeon X1200, ATI RS740, ATI RS740M, ATI RS740, ATI RS740M, ATI Radeon HD 2900 XT, ATI Radeon HD 2900 XT, ATI Radeon HD 2900 XT, ATI Radeon HD 2900 Pro, ATI Radeon HD 2900 GT, ATI FireGL V8650, ATI FireGL V8600, ATI FireGL V7600, ATI Radeon 4800 Series, ATI Radeon HD 4870 x2, ATI Radeon 4800 Series, ATI Radeon HD 4850 x2, ATI FirePro V8750 (FireGL), ATI FirePro V7760 (FireGL), ATI Mobility RADEON HD 4850, ATI Mobility RADEON HD 4850 X2, ATI Radeon 4800 Series, ATI FirePro RV770, AMD FireStream 9270, AMD FireStream 9250, ATI FirePro V8700 (FireGL), ATI Mobility RADEON HD 4870, ATI Mobility RADEON M98, ATI Mobility RADEON HD 4870, ATI Radeon 4800 Series, ATI Radeon 4800 Series, ATI FirePro M7750, ATI M98, ATI M98, ATI M98, ATI Mobility Radeon HD 4650, ATI Radeon RV730 (AGP), ATI Mobility Radeon HD 4670, ATI FirePro M5750, ATI Mobility Radeon HD 4670, ATI Radeon RV730 (AGP), ATI RV730XT [Radeon HD 4670], ATI RADEON E4600, ATI Radeon HD 4600 Series, ATI RV730 PRO [Radeon HD 4650], ATI FirePro V7750 (FireGL), ATI FirePro V5700 (FireGL), ATI FirePro V3750 (FireGL), ATI Mobility Radeon HD 4830, ATI Mobility Radeon HD 4850, ATI FirePro M7740, ATI RV740, ATI Radeon HD 4770, ATI Radeon HD 4700 Series, ATI Radeon HD 4770, ATI FirePro M5750, ATI RV610, ATI Radeon HD 2400 XT, ATI Radeon HD 2400 Pro, ATI Radeon HD 2400 PRO AGP, ATI FireGL V4000, ATI RV610, ATI Radeon HD 2350, ATI Mobility Radeon HD 2400 XT, ATI Mobility Radeon HD 2400, ATI RADEON E2400, ATI RV610, ATI FireMV 2260, ATI RV670, ATI Radeon HD3870, ATI Mobility Radeon HD 3850, ATI Radeon HD3850, ATI Mobility Radeon HD 3850 X2, ATI RV670, ATI Mobility Radeon HD 3870, ATI Mobility Radeon HD 3870 X2, ATI Radeon HD3870 X2, ATI FireGL V7700, ATI Radeon HD3850, ATI Radeon HD3690, AMD Firestream 9170, ATI Radeon HD 4550, ATI Radeon RV710, ATI Radeon RV710, ATI Radeon RV710, ATI Radeon HD 4350, ATI Mobility Radeon 4300 Series, ATI Mobility Radeon 4500 Series, ATI Mobility Radeon 4500 Series, ATI FirePro RG220, ATI Mobility Radeon 4330, ATI RV630, ATI Mobility Radeon HD 2600, ATI Mobility Radeon HD 2600 XT, ATI Radeon HD 2600 XT AGP, ATI Radeon HD 2600 Pro AGP, ATI Radeon HD 2600 XT, ATI Radeon HD 2600 Pro, ATI Gemini RV630, ATI Gemini Mobility Radeon HD 2600 XT, ATI FireGL V5600, ATI FireGL V3600, ATI Radeon HD 2600 LE, ATI Mobility FireGL Graphics Processor, ATI Radeon HD 3470, ATI Mobility Radeon HD 3430, ATI Mobility Radeon HD 3400 Series, ATI Radeon HD 3450, ATI Radeon HD 3450, ATI Radeon HD 3430, ATI Radeon HD 3450, ATI FirePro V3700, ATI FireMV 2450, ATI FireMV 2260, ATI FireMV 2260, ATI Radeon HD 3600 Series, ATI Radeon HD 3650 AGP, ATI Radeon HD 3600 PRO, ATI Radeon HD 3600 XT, ATI Radeon HD 3600 PRO, ATI Mobility Radeon HD 3650, ATI Mobility Radeon HD 3670, ATI Mobility FireGL V5700, ATI Mobility FireGL V5725, ATI Radeon HD 3200 Graphics, ATI Radeon 3100 Graphics, ATI Radeon HD 3200 Graphics, ATI Radeon 3100 Graphics, ATI Radeon HD 3300 Graphics, ATI Radeon HD 3200 Graphics, ATI Radeon 3000 Graphics, SUMO, SUMO, SUMO2, SUMO2, SUMO2, SUMO2, SUMO, SUMO, SUMO, SUMO, SUMO, SUMO, SUMO, SUMO, ATI Radeon HD 4200, ATI Radeon 4100, ATI Mobility Radeon HD 4200, ATI Mobility Radeon 4100, ATI Radeon HD 4290, ATI Radeon HD 4250, AMD Radeon HD 6310 Graphics, AMD Radeon HD 6310 Graphics, AMD Radeon HD 6250 Graphics, AMD Radeon HD 6250 Graphics, AMD Radeon HD 6300 Series Graphics, AMD Radeon HD 6200 Series Graphics, PALM, PALM, PALM, CYPRESS, ATI FirePro (FireGL) Graphics Adapter, ATI FirePro (FireGL) Graphics Adapter, ATI FirePro (FireGL) Graphics Adapter, AMD Firestream 9370, AMD Firestream 9350, ATI Radeon HD 5800 Series, ATI Radeon HD 5800 Series, ATI Radeon HD 5800 Series, ATI Radeon HD 5800 Series, ATI Radeon HD 5900 Series, ATI Radeon HD 5900 Series, ATI Mobility Radeon HD 5800 Series, ATI Mobility Radeon HD 5800 Series, ATI FirePro (FireGL) Graphics Adapter, ATI FirePro (FireGL) Graphics Adapter, ATI Mobility Radeon HD 5800 Series, ATI Radeon HD 5700 Series, ATI Radeon HD 5700 Series, ATI Radeon HD 6700 Series, ATI Radeon HD 5700 Series, ATI Radeon HD 6700 Series, ATI Mobility Radeon HD 5000 Series, ATI Mobility Radeon HD 5000 Series, ATI Mobility Radeon HD 5570, ATI FirePro (FireGL) Graphics Adapter, ATI FirePro (FireGL) Graphics Adapter, ATI Radeon HD 5670, ATI Radeon HD 5570, ATI Radeon HD 5500 Series, REDWOOD, ATI Mobility Radeon HD 5000 Series, ATI Mobility Radeon HD 5000 Series, ATI Mobility Radeon Graphics, ATI Mobility Radeon Graphics, CEDAR, ATI FirePro (FireGL) Graphics Adapter, ATI FirePro (FireGL) Graphics Adapter, ATI FirePro 2270, CEDAR, ATI Radeon HD 5450, CEDAR, CEDAR, CAYMAN, CAYMAN, CAYMAN, CAYMAN, CAYMAN, CAYMAN, CAYMAN, CAYMAN, CAYMAN, CAYMAN, AMD Radeon HD 6900 Series, AMD Radeon HD 6900 Series, CAYMAN, CAYMAN, CAYMAN, AMD Radeon HD 6900M Series, Mobility Radeon HD 6000 Series, BARTS, BARTS, Mobility Radeon HD 6000 Series, Mobility Radeon HD 6000 Series, BARTS, BARTS, BARTS, BARTS, AMD Radeon HD 6800 Series, AMD Radeon HD 6800 Series, AMD Radeon HD 6700 Series, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, CAICOS, CAICOS, CAICOS, CAICOS, CAICOS, CAICOS, CAICOS, CAICOS, CAICOS, CAICOS, CAICOS, CAICOS, CAICOS, CAICOS, CAICOS, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, TAHITI, TAHITI, TAHITI, TAHITI, TAHITI, TAHITI, TAHITI, TAHITI, TAHITI, TAHITI, TAHITI, TAHITI, TAHITI, PITCAIRN, PITCAIRN, PITCAIRN, PITCAIRN, PITCAIRN, PITCAIRN, PITCAIRN, PITCAIRN, PITCAIRN, PITCAIRN, PITCAIRN, PITCAIRN, PITCAIRN, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, OLAND, OLAND, OLAND, OLAND, OLAND, OLAND, OLAND, OLAND, OLAND, OLAND, OLAND, OLAND, OLAND, HAINAN, HAINAN, HAINAN, HAINAN, HAINAN, HAINAN, BONAIRE, BONAIRE, BONAIRE, BONAIRE, BONAIRE, BONAIRE, BONAIRE, BONAIRE, KABINI, KABINI, KABINI, KABINI, KABINI, KABINI, KABINI, KABINI, KABINI, KABINI, KABINI, KABINI, KABINI, KABINI, KABINI, KABINI [ 205.944] (--) Using syscons driver with X support (version 2.0) [ 205.944] (--) using VT number 9 [ 205.949] (II) [KMS] Kernel modesetting enabled. [ 205.949] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [ 205.950] (**) RADEON(0): Depth 24, (**) framebuffer bpp 32 [ 205.950] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) [ 205.950] (==) RADEON(0): Default visual is TrueColor [ 205.950] (**) RADEON(0): Option "EnablePageFlip" "on" [ 205.950] (==) RADEON(0): RGB weight 888 [ 205.950] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) [ 205.950] (--) RADEON(0): Chipset: "ATI Radeon 9600 AP (AGP)" (ChipID = 0x4150) [ 205.950] drmOpenDevice: node name is /dev/dri/card0 [ 205.952] drmOpenDevice: open result is 8, (OK) [ 205.953] drmOpenByBusid: Searching for BusID pci:0000:01:00.0 [ 205.953] drmOpenDevice: node name is /dev/dri/card0 [ 205.954] drmOpenDevice: open result is 8, (OK) [ 205.954] drmOpenByBusid: drmOpenMinor returns 8 [ 205.954] drmOpenByBusid: Interface 1.4 failed, trying 1.1 [ 205.954] drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 [ 205.954] (II) RADEON(0): Kernel too old missing accel information, assuming accel is working [ 205.954] (II) Loading sub module "dri2" [ 205.954] (II) LoadModule: "dri2" [ 205.955] (II) Loading /usr/local/lib/xorg/modules/extensions/libdri2.so [ 205.955] (II) Module dri2: vendor="X.Org Foundation" [ 205.955] compiled for 1.12.4, module version = 1.2.0 [ 205.955] ABI class: X.Org Server Extension, version 6.0 [ 205.955] (II) Loading sub module "exa" [ 205.955] (II) LoadModule: "exa" [ 205.955] (II) Loading /usr/local/lib/xorg/modules/libexa.so [ 205.971] (II) Module exa: vendor="X.Org Foundation" [ 205.971] compiled for 1.12.4, module version = 2.5.0 [ 205.971] ABI class: X.Org Video Driver, version 12.1 [ 205.971] (II) RADEON(0): KMS Color Tiling: enabled [ 205.971] (II) RADEON(0): KMS Color Tiling 2D: disabled [ 205.971] (II) RADEON(0): KMS Pageflipping: enabled [ 205.971] (II) RADEON(0): SwapBuffers wait for vsync: enabled [ 205.971] (EE) RADEON(0): Kernel modesetting setup failed [ 205.973] (II) UnloadModule: "radeon" [ 205.973] (II) UnloadSubModule: "exa" [ 205.973] (II) Unloading exa [ 205.973] (II) UnloadSubModule: "dri2" [ 205.973] (II) Unloading dri2 [ 205.973] (EE) Screen(s) found, but none have a usable configuration. [ 205.973] Fatal server error: [ 205.973] no screens found [ 205.973] Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 205.973] Please also check the log file at "/var/log/Xorg.0.log" for additional information. [ 205.973] [ 205.989] Server terminated with error (1). Closing log file. ============== /var/log/Xorg.log ends ============== 2nd attempt, after removing /etc/X11/xorg.conf: failure. Xorg.0.log appears to be somewhat similar (``(EE) RADEON(0): Kernel modesetting setup failed''); I'll post it upon request. 3rd attempt -- OK, maybe I need to manually (kld)load ``drm2'' or ``radeonkms''; upon doing so: kernel panic! (Initially, my kernel configuration didn't contain any modules (NO_MODULES=1) and didn't contain any ``iic'' stuff; at that time, upon attempting to load some of the ``drm2'' or ``radeonkms'' modules, I got a kernel message saying that ``iic'' was missing. Random note: Upon successfully loading ``drm2'', I got the kernel message: ``[drm] Initialized drm 1.1.0 20060810''; the date appears to be old, especially considering the fact that I was used to seeing ``[drm] Initialized radeon 1.31.0 20080613'' before I attempted to give the new Xorg thing a try.) ============== /var/crash/info.0 begins ============== Dump header from device /dev/... Architecture: i386 Architecture Version: 2 Dump Length: 45830144B (43 MB) Blocksize: 512 Dumptime: Sun Nov 10 03:49:16 2013 Hostname: Magic: FreeBSD Kernel Dump Version String: FreeBSD 11.0-CURRENT #4 r257831M: Sun Nov 10 03:46:35 CET 2013 root@:/usr/obj/usr/src/sys/CUSTOM Panic String: make_dev_credv: bad si_name (error=17, si_name=dri/card0) Dump Parity: 884991553 Bounds: 0 Dump Status: good ============== /var/crash/info.0 ends ============== (Yes, /dev/dri/card0 does exist.) 4th attempt -- ``startx'' with an almost GENERIC kernel, the following lines were added to its configuration file: device drm device radeondrm device iicbus device iic device iicbb Result: instant (hard) reboot. Any tips? From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 16:14:43 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BA0F6767 for ; Sun, 10 Nov 2013 16:14:43 +0000 (UTC) (envelope-from freebsd@allanjude.com) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 6FCBB22D6 for ; Sun, 10 Nov 2013 16:14:42 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.108.129]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id E5C0046F09 for ; Sun, 10 Nov 2013 16:14:41 +0000 (UTC) Message-ID: <527FB0F4.5050206@allanjude.com> Date: Sun, 10 Nov 2013 11:14:44 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: cron(8) improvement References: <52792B60.1030309@allanjude.com> <527BCA55.2000207@allanjude.com> <527C5D52.7030508@allanjude.com> <047405A8-B6EB-427B-A2E4-6254DD1A077B@orthanc.ca> <3E6377FF-69FE-48E4-BFB1-E5095A7FA1BB@orthanc.ca> <527C6DEF.6020102@allanjude.com> <527E3EB3.6000301@FreeBSD.org> <8034B822-F903-43D1-8BF6-DFAD7C22F5B0@gsoft.com.au> <527ED34A.1060401@allanjude.com> <527EE417.6060704@allanjude.com> <527EE84D.4060901@allanjude.com> <527EEE3D.9000101@allanjude.com> <527F925D.5030201@m5p.com> In-Reply-To: <527F925D.5030201@m5p.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jLILN3nSESP1CqHBMC6VU5Kx25ptRmFRJ" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 16:14:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jLILN3nSESP1CqHBMC6VU5Kx25ptRmFRJ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-11-10 09:04, George Mitchell wrote: > On 11/09/13 21:23, Allan Jude wrote: >> On 2013-11-09 21:13, Adrian Chadd wrote: >>> On 9 November 2013 17:58, Allan Jude wrote: >>> >>>> Well, if the rc.conf config is specific to the daemon being >>>> installed by >>>> the package, then the existing /etc/rc.conf.d/ system works fine, it= >>>> just falls down a little on xorg configuring hald, unless you just >>>> make >>>> the xorg package create /etc/rc.conf.d/hald and /etc/rc.conf.d/dbus >>> If I install hal/dbus, why wouldn't they themselves populate >>> /etc/rc.conf.d/hald and /etc/rc.conf.d/dbus ? >>> >>> If there are hal/dbus options that need configuring by other packages= , >>> then sure, you'll need to add some other things too. >> ahh, right, why didn't I think of that >> >>>> I like the simplicity of rc.conf, and I would much rather not >>>> involve an >>>> sqlite database, I am not sure how that could possibly be faster the= n >>>> sourcing an extra shell script. >>> Don't focus on that. The sqlite example is just that - an example - >>> showing what kind of operations you would want to implement to _allow= _ >>> you to do that. I'm not advocating for doing it in freebsd-base. >>> >>> The point I'm making is this: >>> >>> * when populating rc.conf.d/, don't just do 'cp' in a post-install >>> script >>> * when populating the cron daemon entries in rc.cron.d, don't just >>> 'cp' in a post-install script. >>> >>> >>> -adrian >> >> If the cron daemon is just scanning /etc/cron.d/* and treating it as i= f >> those lines had been appended to /etc/crontab I don't see why you >> couldn't just cp in the post-install. I think it would be better if yo= u >> didn't have to 'register' a change. >> >> > > For this whole thread, please s,/etc/rc.d,/usr/local/etc/rc.d,g > -- George > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" We have never once mentioned /etc/rc.d rc.conf.d is an entirely different system (extending rc.conf) and I proposed both /etc/cron.d/ (stuff you'd normally add to /etc/crontab) and /usr/local/etc/cron.d/ (packages) --=20 Allan Jude --jLILN3nSESP1CqHBMC6VU5Kx25ptRmFRJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSf7D3AAoJEJrBFpNRJZKfEH4P/1vZVFZr6eprm2+TbgKXf7Fz rxgSIERWYd8wRAE9veK3rOTCiASxmTYIRtjcYbOwEbM0t/q9w/WUNHtUAxJTH3J4 j57eIaZFZZ+a2eyynEfHolZvuPy5dihV60LnUmiuKhXJj8nEbddlyq0ziwERAd1+ SBswOTDZJV99V/42Hdn6I1VXF4Ppf6xV2XQJdyFpQUwQUnvae2AAdy3i5dxaoKiQ r/LLM1zEAJHBmZ+RuqcmL8qH3/LSe281HD5SGS/pZ/jlcU7jicuFlQnjnOpozbVn 8dYLT4oynp1MV9FSsEDwIdlu1k+Uhc9qA27tYQFa8eOF3ggks4XPH62EwbvQ9nay q56bQHu9ubN5vT2JGM/DDFL0gmt2uhFjegz3VhgrQvV6S8gpUQ6xor22v+Px8tKP tkuKmW+uDuh6wtdtO7FEZXLfzmWwcqf/EkH574+XP+QhENhjpy+W77dLlI5ox8rx r/A2jzsoBCB/CRSzLowhoLfUyiigH2ho5VwR5l4q1s2wIYpnsj7W5S5/4cV9whWR QL0Qqq1qo6WaWlm/HmtR55emEL7VYbxmBiV4lbsNnpJnVWmp5AllFyYSiIeDjXFV eB7LnmK8cPdyPYzg1ZqSD6H4EJ2y7ZitqnwR5mCaWvcPkQjasmw3C8kzE2Xlw78T wG6K0Nz+1vKn2cERQQl3 =PiYj -----END PGP SIGNATURE----- --jLILN3nSESP1CqHBMC6VU5Kx25ptRmFRJ-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 16:22:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A0D4192F; Sun, 10 Nov 2013 16:22:01 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 36BCD2340; Sun, 10 Nov 2013 16:22:01 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id rAAGLsQq090775; Sun, 10 Nov 2013 09:21:54 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id rAAGLroF090772; Sun, 10 Nov 2013 09:21:54 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Sun, 10 Nov 2013 09:21:53 -0700 (MST) From: Warren Block To: "Daniel O'Connor" Subject: Re: cron(8) improvement In-Reply-To: <8034B822-F903-43D1-8BF6-DFAD7C22F5B0@gsoft.com.au> Message-ID: References: <52792B60.1030309@allanjude.com> <488180AE-5C23-402A-BAA4-E3263D8C52BF@kientzle.com> <1383788977.14448.44112617.6F0D61A0@webmail.messagingengine.com> <527AFAA1.1040001@allanjude.com> <527BCA55.2000207@allanjude.com> <527C5D52.7030508@allanjude.com> <047405A8-B6EB-427B-A2E4-6254DD1A077B@orthanc.ca> <3E6377FF-69FE-48E4-BFB1-E5095A7FA1BB@orthanc.ca> <527C6DEF.6020102@allanjude.com> <527E3EB3.6000301@FreeBSD.org> <8034B822-F903-43D1-8BF6-DFAD7C22F5B0@gsoft.com.au> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sun, 10 Nov 2013 09:21:54 -0700 (MST) Cc: FreeBSD Current , Matthew Seaman X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 16:22:01 -0000 On Sun, 10 Nov 2013, Daniel O'Connor wrote: > > On 10 Nov 2013, at 24:24, Matthew Seaman wrote: >> >> 2) Should ports / packages populate these cron.d directories? >> >> This is a much more interesting question. Effectively its asking >> if a port / package should provide some level of automatic >> configuration -- a thing that has previously been a no-no for >> FreeBSD. > > I think it would be OK if they installed entries in a disabled state. That would be my preference also. > ie either the file is named such that it is ignored by cron (preferable IMO) or the entries in them are commented out. Why not just use an additional entry in rc.conf? rsnapshot_cron="YES" (If there is a /usr/local/etc/cron.d/rsnapshot, add it to cron on start/restart.) This brings up another problem. When a port is removed, what is done with ports cron entries that have been user modified? Normally, modified files would not be removed, but a cron entry for a removed port definitely should not be running any more, even if the admin forgot to remove the entry in rc.conf. But just removing the modified file is bad also, because maybe the port was just removed as part of an upgrade. From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 16:34:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 47140C74; Sun, 10 Nov 2013 16:34:38 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep36.mx.upcmail.net (fep36.mx.upcmail.net [62.179.121.54]) by mx1.freebsd.org (Postfix) with ESMTP id 59DF723B1; Sun, 10 Nov 2013 16:34:36 +0000 (UTC) Received: from edge04.upcmail.net ([192.168.13.239]) by viefep21-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20131110163341.BFFZ12754.viefep21-int.chello.at@edge04.upcmail.net>; Sun, 10 Nov 2013 17:33:41 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge04.upcmail.net with edge id nsZh1m00Y2xdvHc03sZh5E; Sun, 10 Nov 2013 17:33:41 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id 38A396D47B; Sun, 10 Nov 2013 17:33:41 +0100 (CET) Date: Sun, 10 Nov 2013 17:33:41 +0100 From: Stefan Farfeleder To: Adrian Chadd Subject: Re: iwn(4) hangs after r257133 Message-ID: <20131110163340.GA1778@mole.fafoe.narf.at> References: <20131110121737.GA1834@mole.fafoe.narf.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: Brandon Gooch , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 16:34:38 -0000 On Sun, Nov 10, 2013 at 05:14:58AM -0800, Adrian Chadd wrote: > yup, same info as brandon. :) http://pastebin.com/MwfL06z7 Stefan > On 10 November 2013 04:17, Stefan Farfeleder wrote: > > On Sat, Nov 09, 2013 at 08:29:30PM -0600, Brandon Gooch wrote: > >> Turns out that not enabling MRR causes my Intel Ultimate N WiFi Link > >> 5300 to hang after only a few moments of use. > >> > >> For now, I've just reverted only those aspects of r257133, enabling > >> MRR and keeping the rate index lookup, which seems to do something on > >> my hardware at least (I assume it's not the right thing based on > >> Adrian's analysis, but it works never-the-less). > >> > >> Has anyone else hit this with Intel WiFi hardware? > >> > >> Also, what needs to be done to have MRR working properly? > > > > Hi, > > > > I have problems with iwn (Intel WiFi Link 5100) as well. > > > > Unlike my previous problems, it associates properly and works fine, at > > first. But then, after some minutes, the link quality somehow > > deteriorates and I see serious packet drops. Usually it gets back to > > normal some minutes later, but restarting the interface "fixes" the > > problem. I don't think it's a problem with the signal itself, because > > other devices next to the notebook work just fine during that intervals. > > > > Adrian, do you have any ideas, or some data you want from me? > > > > Stefan > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 16:40:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B4713EB1 for ; Sun, 10 Nov 2013 16:40:25 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5EA2D23E0 for ; Sun, 10 Nov 2013 16:40:24 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.6/8.14.6/NETPLEX) with ESMTP id rAAGeIdw049271; Sun, 10 Nov 2013 11:40:18 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.1 (mail.netplex.net [204.213.176.9]); Sun, 10 Nov 2013 11:40:18 -0500 (EST) Date: Sun, 10 Nov 2013 11:40:18 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: dt71@gmx.com Subject: Re: new Xorg (KMS, etc.) for Radeon 9600 In-Reply-To: <527F95BE.7080908@gmx.com> Message-ID: References: <527F95BE.7080908@gmx.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 16:40:25 -0000 On Sun, 10 Nov 2013, dt71@gmx.com wrote: > I've built the ports with the following lines in my /etc/make.conf: > WITH_NEW_XORG=1 > WITH_KMS=1 > WITH_GALLIUM=1 > And I've attempted to run ``startx''. My -current is still from ~July 3, and I also got panics when trying new Xorg. Take the drm devices out of your kernel configuration and let X load the necessary drm2 devices when it starts. This allowed it to work for me. -- DE From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 16:57:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 81262284 for ; Sun, 10 Nov 2013 16:57:32 +0000 (UTC) (envelope-from freebsd@allanjude.com) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 1453624BA for ; Sun, 10 Nov 2013 16:57:30 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.108.129]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id EA57246FAF for ; Sun, 10 Nov 2013 16:57:29 +0000 (UTC) Message-ID: <527FBAFC.4040409@allanjude.com> Date: Sun, 10 Nov 2013 11:57:32 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: cron(8) improvement References: <52792B60.1030309@allanjude.com> <488180AE-5C23-402A-BAA4-E3263D8C52BF@kientzle.com> <1383788977.14448.44112617.6F0D61A0@webmail.messagingengine.com> <527AFAA1.1040001@allanjude.com> <527BCA55.2000207@allanjude.com> <527C5D52.7030508@allanjude.com> <047405A8-B6EB-427B-A2E4-6254DD1A077B@orthanc.ca> <3E6377FF-69FE-48E4-BFB1-E5095A7FA1BB@orthanc.ca> <527C6DEF.6020102@allanjude.com> <527E3EB3.6000301@FreeBSD.org> <8034B822-F903-43D1-8BF6-DFAD7C22F5B0@gsoft.com.au> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fPmBAngsQRq8Pi8ve8F4xdfQWxI5WiQPt" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 16:57:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fPmBAngsQRq8Pi8ve8F4xdfQWxI5WiQPt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-11-10 11:21, Warren Block wrote: > On Sun, 10 Nov 2013, Daniel O'Connor wrote: > >> >> On 10 Nov 2013, at 24:24, Matthew Seaman wrote: >>> >>> 2) Should ports / packages populate these cron.d directories? >>> >>> This is a much more interesting question. Effectively its aski= ng >>> if a port / package should provide some level of automatic >>> configuration -- a thing that has previously been a no-no for >>> FreeBSD. >> >> I think it would be OK if they installed entries in a disabled state. > > That would be my preference also. > >> ie either the file is named such that it is ignored by cron >> (preferable IMO) or the entries in them are commented out. > > Why not just use an additional entry in rc.conf? > > rsnapshot_cron=3D"YES" > > (If there is a /usr/local/etc/cron.d/rsnapshot, add it to cron on > start/restart.) > I envisioned crond just scanning the directory for added/removed files, rather than some 'add it to cron' system, and cron doesn't read/parse the rc.conf system. maybe it makes most sense to make it scan /usr/local/etc/cron.d/*.cron So ports can install rsnapshot.cron.sample that the user must manually enable (like we do with config files) > This brings up another problem. When a port is removed, what is done > with ports cron entries that have been user modified? Normally, > modified files would not be removed, but a cron entry for a removed > port definitely should not be running any more, even if the admin > forgot to remove the entry in rc.conf. But just removing the modified > file is bad also, because maybe the port was just removed as part of > an upgrade. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" --=20 Allan Jude --fPmBAngsQRq8Pi8ve8F4xdfQWxI5WiQPt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSf7r/AAoJEJrBFpNRJZKfq9oQAJY7w5mTAKt55+WIRSdxX8OY cAlYPih8w4fhBZ6pzjV/cAOROwgDTdrhPX4dNWrVG7eUTlvC0jkLYwqEsy+4ptXy MRJmcwCYh2gT/eFPgi43HEpJROyXxM4ibcWaoy3epKL5Ws04fwT/Gm1OGf5xmMBN J1cIl5GtlIvxHe5Vszmq/XRJncoFTOBdCKLBaa5RaythSV899VNKSVyE/T2iCWTN FDcQjSYzn9ekhMgaoIShAa3+Nyu11YWo3CyZ1UV+kUQSpmUTjFhmz72eQpD5RB/o 6rSm+Ww9Ck57Wz8Qb4imi4tyypshpARIZhgVvqIePCa4Ec9YsiwhCAXpb82J0O7B aO2r/o3iAQVaz6SZ0EbvJeD3QXStyy7r2k/DXm9bB6x/YNPXFCaKObK1Ra8ubjdO bNXLmmjGZskLZrmJtPfqs5E/+RsE+q3c3JaqRivCYai6OF4HbzYu0OS4DmGERf2C hiDq2HZTrNLblSAwRxSAON+E8AtfV+Barqg9o5BjT3+JjHclM0Rr0Zclne4gMnOB K9UlMh0m7J2HX4idf5irTS4xg8q3jPUy6EojjbuC0qizHuNPs1Pa1XnKI2hNK0ys 0kVkUkhAWOJ8z1Iw0uBApIn921jDJIn0c8jlbOsnb9lU/E8VInJtW5lDgue9WlYV +3MfQH+24IYo06y5ufX7 =eioU -----END PGP SIGNATURE----- --fPmBAngsQRq8Pi8ve8F4xdfQWxI5WiQPt-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 17:06:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 98B104BD for ; Sun, 10 Nov 2013 17:06:18 +0000 (UTC) (envelope-from pj@smo.de) Received: from cetus.uberspace.de (cetus.uberspace.de [95.143.172.140]) by mx1.freebsd.org (Postfix) with SMTP id F17852548 for ; Sun, 10 Nov 2013 17:06:17 +0000 (UTC) Received: (qmail 7060 invoked from network); 10 Nov 2013 16:59:33 -0000 Received: from unknown (HELO ?192.168.43.121?) (80.187.96.37) by cetus.uberspace.de with SMTP; 10 Nov 2013 16:59:33 -0000 Message-ID: <527FBB6B.5020706@smo.de> Date: Sun, 10 Nov 2013 17:59:23 +0100 From: Philipp Ost User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:23.0) Gecko/20100101 Firefox/23.0 SeaMonkey/2.20 MIME-Version: 1.0 To: Warren Block , Daniel O'Connor Subject: Re: cron(8) improvement References: <52792B60.1030309@allanjude.com> <488180AE-5C23-402A-BAA4-E3263D8C52BF@kientzle.com> <1383788977.14448.44112617.6F0D61A0@webmail.messagingengine.com> <527AFAA1.1040001@allanjude.com> <527BCA55.2000207@allanjude.com> <527C5D52.7030508@allanjude.com> <047405A8-B6EB-427B-A2E4-6254DD1A077B@orthanc.ca> <3E6377FF-69FE-48E4-BFB1-E5095A7FA1BB@orthanc.ca> <527C6DEF.6020102@allanjude.com> <527E3EB3.6000301@FreeBSD.org> <8034B822-F903-43D1-8BF6-DFAD7C22F5B0@gsoft.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Matthew Seaman X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 17:06:18 -0000 Warren Block schrieb: [...] >> ie either the file is named such that it is ignored by cron >> (preferable IMO) or the entries in them are commented out. > > Why not just use an additional entry in rc.conf? > > rsnapshot_cron="YES" > > (If there is a /usr/local/etc/cron.d/rsnapshot, add it to cron on > start/restart.) > > This brings up another problem. When a port is removed, what is done > with ports cron entries that have been user modified? Normally, > modified files would not be removed, but a cron entry for a removed port > definitely should not be running any more, even if the admin forgot to > remove the entry in rc.conf. But just removing the modified file is bad > also, because maybe the port was just removed as part of an upgrade. Given the above scenario, would it be acceptable to set the entry in rc.conf, $portname_cron=YES, to $portname_cron=NO without touching the modified files and inform the user about having done so? Philipp From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 17:21:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3DB6D7F3 for ; Sun, 10 Nov 2013 17:21:13 +0000 (UTC) (envelope-from dt71@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C0D7C262A for ; Sun, 10 Nov 2013 17:21:12 +0000 (UTC) Received: from [157.181.98.186] ([157.181.98.186]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MIyCj-1Vd5qo1c1x-002UTI for ; Sun, 10 Nov 2013 18:21:03 +0100 Message-ID: <527FC05D.8080703@gmx.com> Date: Sun, 10 Nov 2013 18:20:29 +0100 From: dt71@gmx.com User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Firefox/24.0 SeaMonkey/2.21 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: new Xorg (KMS, etc.) for Radeon 9600 References: <527F95BE.7080908@gmx.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:B6q8QPx7D6OpCic72l6m8RxPUJ2xqonkOmLHUWDA8F/ms/pMou+ JGzN+j1f++Dm8VOQyKeIWJHoR1RbafjX2SUU9cEZfycevBDTxIzrCpomCIWoT0UJeVdjTU2 TnWXZ1LG2KNOOt6Nm9TvVZM3hHAotgUOSh/O9C6+b9E3h7HWLODuSGKMa0ohbvdha295S3T SVEssm+OgbRaV1B57e9QA== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 17:21:13 -0000 Daniel Eischen wrote, On 11/10/2013 17:40: > My -current is still from ~July 3, and I also got panics > when trying new Xorg. Take the drm devices out of your > kernel configuration and let X load the necessary drm2 > devices when it starts. This allowed it to work for me. Hmm, works for me to avoid panics and hard reboots. Problems: 1. Switching to the virtual terminals or shutting down X causes the display to go black and unrevivable -- a (soft) reboot is necessary. 2. A 3D application crashes with SIGBUS, and the stack gets toasted. ============== dmesg begins ============== Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #6 r257831M: Sun Nov 10 17:55:45 CET 2013 root@:/usr/obj/usr/src/sys/CUSTOM i386 clang version 3.4 (trunk 194164) CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2999.72-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf41 Family = 0xf Model = 0x4 Stepping = 1 Features=0xbfebfbff Features2=0x441d TSC: P-state invariant real memory = 536870912 (512 MB) avail memory = 515149824 (491 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard random: initialized acpi0: on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 1ff00000 (3) failed cpu0: on acpi0 cpu1: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xa800-0xa8ff mem 0xd0000000-0xdfffffff,0xff0f0000-0xff0fffff irq 16 at device 0.0 on pci1 vgapci1: mem 0xc0000000-0xcfffffff,0xff0e0000-0xff0effff at device 0.1 on pci1 uhci0: port 0xe000-0xe01f irq 16 at device 29.0 on pci0 usbus0 on uhci0 uhci1: port 0xe400-0xe41f irq 19 at device 29.1 on pci0 usbus1 on uhci1 uhci2: port 0xe800-0xe81f irq 18 at device 29.2 on pci0 usbus2 on uhci2 uhci3: port 0xec00-0xec1f irq 16 at device 29.3 on pci0 usbus3 on uhci3 ehci0: mem 0xff2ffc00-0xff2fffff irq 23 at device 29.7 on pci0 usbus4: EHCI version 1.0 usbus4 on ehci0 pcib2: at device 30.0 on pci0 pci2: on pcib2 rl0: port 0xb800-0xb8ff mem 0xff1ffc00-0xff1ffcff irq 22 at device 5.0 on pci2 miibus0: on rl0 rlphy0: PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:25:22:10:7c:de isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 pci0: at device 31.3 (no driver attached) pcm0: port 0xd800-0xd8ff,0xdc00-0xdc3f mem 0xff2ff800-0xff2ff9ff,0xff2ff400-0xff2ff4ff irq 17 at device 31.5 on pci0 pcm0: acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd0: [GIANT-LOCKED] orm0: at iomem 0xc0000-0xccfff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 acpi_throttle0: on cpu0 Timecounters tick every 1.000 msec random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ugen1.1: at usbus1 uhub0: on usbus1 ugen0.1: at usbus0 uhub1: on usbus0 ugen4.1: at usbus4 uhub2: on usbus4 ugen3.1: at usbus3 uhub3: on usbus3 ugen2.1: at usbus2 uhub4: on usbus2 ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: ATA-7 device ada0: Serial Number Y2JPFJPE ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) ada0: 78167MB (160086528 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 ada1 at ata0 bus 0 scbus0 target 1 lun 0 ada1: ATA-6 device ada1: Serial Number 5JS3G715 ada1: 100.000MB/s transfers (UDMA5, PIO 8192bytes) ada1: 114473MB (234441648 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad1 ada2 at ata1 bus 0 scbus1 target 0 lun 0 ada2: ATA-7 device ada2: Serial Number Y22NCZKC ada2: 100.000MB/s transfers (UDMA5, PIO 8192bytes) ada2: 78167MB (160086528 512 byte sectors: 16H 63S/T 16383C) ada2: Previously was known as ad2 ada3 at ata1 bus 0 scbus1 target 1 lun 0 ada3: ATA-6 device ada3: Serial Number 3JV2VCE9 ada3: 100.000MB/s transfers (UDMA5, PIO 8192bytes) ada3: 38166MB (78165360 512 byte sectors: 16H 63S/T 16383C) ada3: Previously was known as ad3 SMP: AP CPU #1 Launched! Timecounter "TSC-low" frequency 1499861876 Hz quality 1000 uhub3: 2 ports with 2 removable, self powered uhub0: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered Root mount waiting for: usbus4 Root mount waiting for: usbus4 Root mount waiting for: usbus4 uhub2: 8 ports with 8 removable, self powered Trying to mount root from ufs:/dev/gpt/rusty_plate [rw,noatime]... ugen0.2: at usbus0 ums0: on usbus0 ums0: 5 buttons and [XYZT] coordinates ID=1 warning: total configured swap (1047552 pages) exceeds maximum recommended amount (1011584 pages). warning: increase kern.maxswzone or reduce amount of swap. rl0: link state changed to UP info: [drm] Initialized drm 1.1.0 20060810 drmn0: on vgapci0 info: [drm] AGP at 0xf0000000 128MB info: [drm] RADEON_IS_AGP info: [drm] initializing kernel modesetting (RV350 0x1002:0x4150 0x17EE:0x2002). info: [drm] register mmio base: 0xFF0F0000 info: [drm] register mmio size: 65536 info: [drm] radeon_atrm_get_bios: ===> Try ATRM... info: [drm] radeon_atrm_get_bios: pci_find_class() found: 0:1:0:0, vendor=1002, device=4150 info: [drm] radeon_atrm_get_bios: Get ACPI device handle info: [drm] radeon_acpi_vfct_bios: ===> Try VFCT... info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_FOUND info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM... info: [drm] igp_read_bios_from_vram: VRAM base address: 0xd0000000 info: [drm] igp_read_bios_from_vram: Map address: 0xdaea9000 (262144 bytes) info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0x7807 info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... info: [drm] radeon_read_bios: Map address: 0xc00c0000 (131072 bytes) drmn0: info: GTT: 0M 0xF0000000 - 0xEFFFFFFF info: [drm] Generation 2 PCI interface, using max accessible memory drmn0: info: VRAM: 256M 0x00000000D0000000 - 0x00000000DFFFFFFF (128M used) info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. info: [drm] radeon: irq initialized. info: [drm] Detected VRAM RAM=256M, BAR=256M info: [drm] RAM width 128bits DDR [TTM] Zone kernel: Available graphics memory: 257392 kiB [TTM] Initializing pool allocator info: [drm] radeon: 128M of VRAM memory ready info: [drm] radeon: 0M of GTT memory ready. info: [drm] radeon: 1 quad pipes, 1 Z pipes initialized. drmn0: warning: (-12) create WB bo failed drmn0: error: Disabling GPU acceleration info: [drm] radeon: cp finalized info: [drm] radeon: cp finalized [TTM] Finalizing pool allocator [TTM] Zone kernel: Used memory at exit: 0 kiB info: [drm] radeon: ttm finalized info: [drm] Forcing AGP to PCI mode info: [drm] radeon_atrm_get_bios: ===> Try ATRM... info: [drm] radeon_atrm_get_bios: pci_find_class() found: 0:1:0:0, vendor=1002, device=4150 info: [drm] radeon_atrm_get_bios: Get ACPI device handle info: [drm] radeon_acpi_vfct_bios: ===> Try VFCT... info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_FOUND info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM... info: [drm] igp_read_bios_from_vram: VRAM base address: 0xd0000000 info: [drm] igp_read_bios_from_vram: Map address: 0xdaeac000 (262144 bytes) info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0x7807 info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... info: [drm] radeon_read_bios: Map address: 0xc00c0000 (131072 bytes) info: [drm] Generation 2 PCI interface, using max accessible memory drmn0: info: VRAM: 256M 0x00000000D0000000 - 0x00000000DFFFFFFF (128M used) drmn0: info: GTT: 512M 0x00000000B0000000 - 0x00000000CFFFFFFF info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. info: [drm] radeon: irq initialized. info: [drm] Detected VRAM RAM=256M, BAR=256M info: [drm] RAM width 128bits DDR [TTM] Zone kernel: Available graphics memory: 257392 kiB [TTM] Initializing pool allocator info: [drm] radeon: 128M of VRAM memory ready info: [drm] radeon: 512M of GTT memory ready. info: [drm] GART: num cpu pages 131072, num gpu pages 131072 info: [drm] radeon: 1 quad pipes, 1 Z pipes initialized. info: [drm] PCI GART of 512M enabled (table at 0x000000000A6AD000). drmn0: info: WB enabled drmn0: info: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0x0xd8b21000 info: [drm] Loading R300 Microcode radeonkmsfw_R300_cp: could not load firmware image, error 2 error: [drm:pid667:r100_cp_init_microcode] *ERROR* radeon_cp: Failed to load firmware "radeonkmsfw_R300_cp" error: [drm:pid667:r100_cp_init] *ERROR* Failed to load firmware! drmn0: error: failed initializing CP (-2). drmn0: error: Disabling GPU acceleration info: [drm] radeon: cp finalized info: [drm] radeon_device_init: Taking over the fictitious range 0xd0000000-0xe0000000 iicbus0: on iicbb0 addr 0xda iic0: on iicbus0 iicbus1: on iicbb1 addr 0xc4 iic1: on iicbus1 iicbus2: on iicbb2 addr 0xc4 iic2: on iicbus2 info: [drm] No TV DAC info found in BIOS info: [drm] Radeon Display Connectors info: [drm] Connector 0: info: [drm] VGA-1 info: [drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60 info: [drm] Encoders: info: [drm] CRT1: INTERNAL_DAC1 info: [drm] Connector 1: info: [drm] DVI-I-1 info: [drm] HPD1 info: [drm] DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64 info: [drm] Encoders: info: [drm] CRT2: INTERNAL_DAC2 info: [drm] DFP1: INTERNAL_TMDS1 info: [drm] Connector 2: info: [drm] SVIDEO-1 info: [drm] Encoders: info: [drm] TV1: INTERNAL_DAC2 error: [drm:pid667:r100_irq_set] *ERROR* Can't enable IRQ/MSI because no handler is installed info: [drm] Initialized radeon 2.29.0 20080528 ============== dmesg ends ============== From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 17:23:33 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 52C16922; Sun, 10 Nov 2013 17:23:33 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DCEE22648; Sun, 10 Nov 2013 17:23:32 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id rAAHNVpi091226; Sun, 10 Nov 2013 10:23:31 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id rAAHNUVA091222; Sun, 10 Nov 2013 10:23:30 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Sun, 10 Nov 2013 10:23:30 -0700 (MST) From: Warren Block To: Philipp Ost Subject: Re: cron(8) improvement In-Reply-To: <527FBB6B.5020706@smo.de> Message-ID: References: <52792B60.1030309@allanjude.com> <488180AE-5C23-402A-BAA4-E3263D8C52BF@kientzle.com> <1383788977.14448.44112617.6F0D61A0@webmail.messagingengine.com> <527AFAA1.1040001@allanjude.com> <527BCA55.2000207@allanjude.com> <527C5D52.7030508@allanjude.com> <047405A8-B6EB-427B-A2E4-6254DD1A077B@orthanc.ca> <3E6377FF-69FE-48E4-BFB1-E5095A7FA1BB@orthanc.ca> <527C6DEF.6020102@allanjude.com> <527E3EB3.6000301@FreeBSD.org> <8034B822-F903-43D1-8BF6-DFAD7C22F5B0@gsoft.com.au> <527FBB6B.5020706@smo.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sun, 10 Nov 2013 10:23:31 -0700 (MST) Cc: FreeBSD Current , Matthew Seaman X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 17:23:33 -0000 On Sun, 10 Nov 2013, Philipp Ost wrote: > Warren Block schrieb: > [...] >>> ie either the file is named such that it is ignored by cron >>> (preferable IMO) or the entries in them are commented out. >> >> Why not just use an additional entry in rc.conf? >> >> rsnapshot_cron="YES" >> >> (If there is a /usr/local/etc/cron.d/rsnapshot, add it to cron on >> start/restart.) >> >> This brings up another problem. When a port is removed, what is done >> with ports cron entries that have been user modified? Normally, >> modified files would not be removed, but a cron entry for a removed port >> definitely should not be running any more, even if the admin forgot to >> remove the entry in rc.conf. But just removing the modified file is bad >> also, because maybe the port was just removed as part of an upgrade. > > Given the above scenario, would it be acceptable to set the entry in rc.conf, > $portname_cron=YES, to $portname_cron=NO without touching the modified files > and inform the user about having done so? I would not want the system modifying rc.conf for me, but don't have a better idea at present. Maybe move customized cronfiles to an "old" folder on deinstall, so at least the user could recover them. From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 17:48:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6067D3EA for ; Sun, 10 Nov 2013 17:48:36 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DBB712762 for ; Sun, 10 Nov 2013 17:48:35 +0000 (UTC) Received: from [10.0.0.52] (ip-414b102e.ct.fixed.ntplx.com [65.75.16.46]) by mail.ntplx.net (8.14.6/8.14.6/NETPLEX) with ESMTP id rAAHYqi2014243 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 10 Nov 2013 12:34:57 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.1 (mail.ntplx.net [204.213.176.10]); Sun, 10 Nov 2013 12:34:58 -0500 (EST) References: <527F95BE.7080908@gmx.com> <527FC05D.8080703@gmx.com> Mime-Version: 1.0 (1.0) In-Reply-To: <527FC05D.8080703@gmx.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11B511) From: Daniel Eischen Subject: Re: new Xorg (KMS, etc.) for Radeon 9600 Date: Sun, 10 Nov 2013 12:34:54 -0500 To: "dt71@gmx.com" Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 17:48:36 -0000 On Nov 10, 2013, at 12:20 PM, dt71@gmx.com wrote: >=20 > Daniel Eischen wrote, On 11/10/2013 17:40: >> My -current is still from ~July 3, and I also got panics >> when trying new Xorg. Take the drm devices out of your >> kernel configuration and let X load the necessary drm2 >> devices when it starts. This allowed it to work for me. >=20 > Hmm, works for me to avoid panics and hard reboots. Problems: > 1. Switching to the virtual terminals or shutting down X causes the displa= y to go black and unrevivable -- a (soft) reboot is necessary. > 2. A 3D application crashes with SIGBUS, and the stack gets toasted. Yes, I can get it to crash also when using a Java-based GUI, but it works fo= r all the basic X apps that I need. I also have the virtual terminal switch= ing problem also, but I think that is being addressed with newsyscons. It really does suck not having a functional X. -- DE= From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 18:48:49 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AB2DC131; Sun, 10 Nov 2013 18:48:49 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x22c.google.com (mail-qe0-x22c.google.com [IPv6:2607:f8b0:400d:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5B4AE2A0D; Sun, 10 Nov 2013 18:48:49 +0000 (UTC) Received: by mail-qe0-f44.google.com with SMTP id 6so3747697qeb.17 for ; Sun, 10 Nov 2013 10:48:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HMg+zoAB7DLf/dhx0bwDWmw+Bgkzub/KZDPYwbwW8GI=; b=bzRtjeJM1BMTY9/AXEezEncjfzjj24/BWY1NvlTGB2PaMy5MINC0ceVh1bn/K4wus2 swipXdYLZNjs11XFJSF3CrnhYHPx7kDd8wkV/Ezoa+Q99OPNAWvtjHETZqAX8TOc+t9j Ro/gH7ejkP5izuPJp7nP4ucbvQbSqq2Nzv3kcfXjybgMB5AY6qHvqYlpbhFLuWFxOfoy BTGc8BHaEe78QbBRYDSBUwCjAHm+Y47785+LbWB0OVDyCj0abmEKKEkt0aWL8BC2gCzt zGU6jrGKg2PEsrOgMQKUTtQHJ4nz2Mbpanc69QGqk1yAUOeXp8kPhNkSh1T2tUZ/F9/Y LSWw== MIME-Version: 1.0 X-Received: by 10.224.64.200 with SMTP id f8mr43248777qai.55.1384109328550; Sun, 10 Nov 2013 10:48:48 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Sun, 10 Nov 2013 10:48:48 -0800 (PST) In-Reply-To: <20131110163340.GA1778@mole.fafoe.narf.at> References: <20131110121737.GA1834@mole.fafoe.narf.at> <20131110163340.GA1778@mole.fafoe.narf.at> Date: Sun, 10 Nov 2013 10:48:48 -0800 X-Google-Sender-Auth: o2nk0y8lSslqAbyexyA5joB2h8A Message-ID: Subject: Re: iwn(4) hangs after r257133 From: Adrian Chadd To: Stefan Farfeleder Content-Type: text/plain; charset=ISO-8859-1 Cc: Brandon Gooch , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 18:48:49 -0000 Right near the end there you have 'status 83' which means 'transmit failed, long retry hit' (the status codes are in if_iwnreg.h somewhere.) The retry count hit 16, which is the max set for the frame. rate=80 (hex) is MCS0. So, you're seeing retransmits and failures at MCS0, which is a bad sign. But, notice how AMRR increased it to MCS2 at a couple stages, and that _always_ fails. But AMRR waits for 10 frame transmits before it adjusts the rate up or down. So yes, we do need to enable MRR again on iwn for things to behave better. There are other issues when you start doing larger amounts of traffic but I'll cover those later.what? If someone wants to take a crack at correctly implementing the link quality table stuff again then please let me know. As I said before, the link quality table setup code is mostly sane. The problem is actually correctly setting 'linkq' to start at the selected rate, as linkq is an index into that table, not the initial rate. Thanks! -adrian On 10 November 2013 08:33, Stefan Farfeleder wrote: > On Sun, Nov 10, 2013 at 05:14:58AM -0800, Adrian Chadd wrote: >> yup, same info as brandon. :) > > http://pastebin.com/MwfL06z7 > > Stefan > >> On 10 November 2013 04:17, Stefan Farfeleder wrote: >> > On Sat, Nov 09, 2013 at 08:29:30PM -0600, Brandon Gooch wrote: >> >> Turns out that not enabling MRR causes my Intel Ultimate N WiFi Link >> >> 5300 to hang after only a few moments of use. >> >> >> >> For now, I've just reverted only those aspects of r257133, enabling >> >> MRR and keeping the rate index lookup, which seems to do something on >> >> my hardware at least (I assume it's not the right thing based on >> >> Adrian's analysis, but it works never-the-less). >> >> >> >> Has anyone else hit this with Intel WiFi hardware? >> >> >> >> Also, what needs to be done to have MRR working properly? >> > >> > Hi, >> > >> > I have problems with iwn (Intel WiFi Link 5100) as well. >> > >> > Unlike my previous problems, it associates properly and works fine, at >> > first. But then, after some minutes, the link quality somehow >> > deteriorates and I see serious packet drops. Usually it gets back to >> > normal some minutes later, but restarting the interface "fixes" the >> > problem. I don't think it's a problem with the signal itself, because >> > other devices next to the notebook work just fine during that intervals. >> > >> > Adrian, do you have any ideas, or some data you want from me? >> > >> > Stefan >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 19:01:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C4CAA48F; Sun, 10 Nov 2013 19:01:17 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 744252AB7; Sun, 10 Nov 2013 19:01:17 +0000 (UTC) Received: by mail-qc0-f179.google.com with SMTP id k18so3419096qcv.38 for ; Sun, 10 Nov 2013 11:01:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=bEuMEEA6Jrb34Hnum3HWefM0Thf05JAw7n9M7SI1nks=; b=aRHnCF1Gj/15MRnYZsmSGyIY5+XWzJYdtQ8iJXo+xeUnkz8rdPYV91fJ5YZPMs9UPw hDyTW1OxW6mq8fd9YWTyfOY2mhmfIlG/5igEXDmMVx0TQhFKabTdYTONMtDdxHZF0460 WhkjfXfQemuwR7vx896XdaVsyPQRnkDNxPuM9mnllYJlgXp7ytAVZbeNYyFtoo4BqU3w 4HsP2TYArI7Trb7iyt/CcdyRk7JKgfF9kCZfiiFdM2UYcqsyHiECi8zQpKqtHm8jUhS/ 4D0o6Z30x/NVQXjEKIpqLuAqJVoKK/5SGyfbqgzRzqrauE+iQ+uxAiGqrsKDikozyPu+ xY+g== MIME-Version: 1.0 X-Received: by 10.229.79.70 with SMTP id o6mr41153562qck.21.1384110076718; Sun, 10 Nov 2013 11:01:16 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Sun, 10 Nov 2013 11:01:16 -0800 (PST) In-Reply-To: References: <20131110121737.GA1834@mole.fafoe.narf.at> <20131110163340.GA1778@mole.fafoe.narf.at> Date: Sun, 10 Nov 2013 11:01:16 -0800 X-Google-Sender-Auth: ePz5vqPFH3Ekv1mtgBT4n_XfYkQ Message-ID: Subject: Re: iwn(4) hangs after r257133 From: Adrian Chadd To: Stefan Farfeleder Content-Type: text/plain; charset=ISO-8859-1 Cc: Brandon Gooch , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 19:01:17 -0000 And for reference, here's the paper: http://hal.inria.fr/docs/00/07/07/84/PDF/RR-5208.pdf -adrian On 10 November 2013 10:48, Adrian Chadd wrote: > Right near the end there you have 'status 83' which means 'transmit > failed, long retry hit' (the status codes are in if_iwnreg.h > somewhere.) The retry count hit 16, which is the max set for the > frame. > > rate=80 (hex) is MCS0. So, you're seeing retransmits and failures at > MCS0, which is a bad sign. > > But, notice how AMRR increased it to MCS2 at a couple stages, and that > _always_ fails. But AMRR waits for 10 frame transmits before it > adjusts the rate up or down. > > So yes, we do need to enable MRR again on iwn for things to behave > better. There are other issues when you start doing larger amounts of > traffic but I'll cover those later.what? > > If someone wants to take a crack at correctly implementing the link > quality table stuff again then please let me know. As I said before, > the link quality table setup code is mostly sane. The problem is > actually correctly setting 'linkq' to start at the selected rate, as > linkq is an index into that table, not the initial rate. > > Thanks! > > > > -adrian > > > On 10 November 2013 08:33, Stefan Farfeleder wrote: >> On Sun, Nov 10, 2013 at 05:14:58AM -0800, Adrian Chadd wrote: >>> yup, same info as brandon. :) >> >> http://pastebin.com/MwfL06z7 >> >> Stefan >> >>> On 10 November 2013 04:17, Stefan Farfeleder wrote: >>> > On Sat, Nov 09, 2013 at 08:29:30PM -0600, Brandon Gooch wrote: >>> >> Turns out that not enabling MRR causes my Intel Ultimate N WiFi Link >>> >> 5300 to hang after only a few moments of use. >>> >> >>> >> For now, I've just reverted only those aspects of r257133, enabling >>> >> MRR and keeping the rate index lookup, which seems to do something on >>> >> my hardware at least (I assume it's not the right thing based on >>> >> Adrian's analysis, but it works never-the-less). >>> >> >>> >> Has anyone else hit this with Intel WiFi hardware? >>> >> >>> >> Also, what needs to be done to have MRR working properly? >>> > >>> > Hi, >>> > >>> > I have problems with iwn (Intel WiFi Link 5100) as well. >>> > >>> > Unlike my previous problems, it associates properly and works fine, at >>> > first. But then, after some minutes, the link quality somehow >>> > deteriorates and I see serious packet drops. Usually it gets back to >>> > normal some minutes later, but restarting the interface "fixes" the >>> > problem. I don't think it's a problem with the signal itself, because >>> > other devices next to the notebook work just fine during that intervals. >>> > >>> > Adrian, do you have any ideas, or some data you want from me? >>> > >>> > Stefan >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 19:34:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E651AC29; Sun, 10 Nov 2013 19:34:24 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep20.mx.upcmail.net (fep20.mx.upcmail.net [62.179.121.40]) by mx1.freebsd.org (Postfix) with ESMTP id 064272CA7; Sun, 10 Nov 2013 19:34:23 +0000 (UTC) Received: from edge03.upcmail.net ([192.168.13.238]) by viefep20-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20131110193422.TWL1918.viefep20-int.chello.at@edge03.upcmail.net>; Sun, 10 Nov 2013 20:34:22 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge03.upcmail.net with edge id nvaN1m00J2xdvHc03vaNES; Sun, 10 Nov 2013 20:34:22 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id F1FC86D47B; Sun, 10 Nov 2013 20:34:21 +0100 (CET) Date: Sun, 10 Nov 2013 20:34:21 +0100 From: Stefan Farfeleder To: Adrian Chadd Subject: Re: iwn(4) hangs after r257133 Message-ID: <20131110193421.GB1778@mole.fafoe.narf.at> References: <20131110121737.GA1834@mole.fafoe.narf.at> <20131110163340.GA1778@mole.fafoe.narf.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: Brandon Gooch , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 19:34:25 -0000 On Sun, Nov 10, 2013 at 10:48:48AM -0800, Adrian Chadd wrote: > Right near the end there you have 'status 83' which means 'transmit > failed, long retry hit' (the status codes are in if_iwnreg.h > somewhere.) The retry count hit 16, which is the max set for the > frame. > > rate=80 (hex) is MCS0. So, you're seeing retransmits and failures at > MCS0, which is a bad sign. > > But, notice how AMRR increased it to MCS2 at a couple stages, and that > _always_ fails. But AMRR waits for 10 frame transmits before it > adjusts the rate up or down. > > So yes, we do need to enable MRR again on iwn for things to behave > better. There are other issues when you start doing larger amounts of > traffic but I'll cover those later.what? > > If someone wants to take a crack at correctly implementing the link > quality table stuff again then please let me know. As I said before, > the link quality table setup code is mostly sane. The problem is > actually correctly setting 'linkq' to start at the selected rate, as > linkq is an index into that table, not the initial rate. Hi, after some trial and error I found out that disabling AMPDU makes my iwn0 usable again. Now I actually see the rate as reported by `list sta' going up and down (mostly between 54M and 121M). Before it was always fixed at 135M. Could this be related? Stefan From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 21:05:46 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5B6F9DD; Sun, 10 Nov 2013 21:05:46 +0000 (UTC) (envelope-from erik+lists@cederstrand.dk) Received: from csmtp2.one.com (csmtp2.one.com [91.198.169.22]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 198EC2206; Sun, 10 Nov 2013 21:05:45 +0000 (UTC) Received: from bigmac.router9fbd7c.com (unknown [176.222.238.90]) by csmtp2.one.com (Postfix) with ESMTPA id E7F3E20E8D; Sun, 10 Nov 2013 21:05:37 +0000 (UTC) Received: from bigmac.router9fbd7c.com ([UNAVAILABLE]. [176.222.238.90]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:2500 (trex/4.8.87); Sun, 10 Nov 2013 21:05:38 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: freebsd perf testing From: Erik Cederstrand In-Reply-To: <527F47AC.50705@freebsd.org> Date: Sun, 10 Nov 2013 22:05:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2034DAAF-F264-42B7-A497-4B2CB846381A@cederstrand.dk> References: <527C462F.9040707@elischer.org> <527F47AC.50705@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1822) Cc: George Neville-Neil , FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 21:05:46 -0000 Den 10/11/2013 kl. 09.45 skrev Julian Elischer : >=20 > it would be interesting to know what you did. and what conclusions you = came to.. I created a system with a build server, a set of slaves, and a website = to collect and publish the benchmark data in graphs and raw data and = highlight significant changes. The build server built FreeBSD and any required ports and benchmark = software, and bundled it in installation images complete with a script = to run the benchmarks on the slave and push data to the website. The slaves were dedicated machines that booted via PXE, wiped the hard = drive, fetched and installed an image and proceeded to run the specified = benchmarks. The website published graphs, and the graphs were linked to useful = related data like raw measurements, slave hardware, commit messages, = changed source files and binaries etc. It actually worked pretty well. I only ran benchmarks over a couple of = months of commits, but I did identify some significant regressions in = MySQL and some of the unixbench microbenchmarks. I did not spend much = time designing the benchmarking strategy, and =93symbolics=94 has many = good points there. I did find out that all the current continuous = integration / performance benchmark frameworks (Jenkins etc) did not = play well with a situation where the entire operating system is = reinstalled. A wide range of useful benchmarks can be collected in just 10-20 = minutes, but building FreeBSD and all the ports takes much longer than = that (1-2 hours using the default procedure from the handbook). Most of = my work went into optimizing build times, installation image sizes and = slave installation times, so I could build an image in just 10-15 = minutes and use ca. 10MB disk space amortized, and install an image on a = slave in just 2 minutes (cheap 2008-era hardware). But having a complete archive of ready-to-install images for each commit = is a real advantage, not just for performance benchmarking. Imagine = being able to fetch a VirtualBox disk image for a random SVN commit, = booting it and start debugging right away. Or you could write a script = to test if a bug is present in a FreeBSD installation, and then let an = automated process do a binary search to find the offending commit in = maybe less than an hour. My work was completed in 2008 and would (at least) require updating the = scripts to handle the upgrade from GCC to Clang, and from CVS to SVN. Erik= From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 22:01:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 47790D2E; Sun, 10 Nov 2013 22:01:14 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E66F224FD; Sun, 10 Nov 2013 22:01:13 +0000 (UTC) Received: by mail-qc0-f181.google.com with SMTP id w4so3572219qcr.12 for ; Sun, 10 Nov 2013 14:01:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=gntL3o/ILZBzpBGtQ2V+eL+z9ULKnvM1MxMnk20LT2o=; b=uQ2Gfy0DZ227y3yfUBmaiKHmA3gGT7/4KLZf5Phadklc7q2/GrAvsWhkEGHDHhyvC0 SiDJz0Bc+dSrGYZwpEOLcz22XNm9YNHPtLybT0q+e1+7n9ppS7mODRimuj8iqm3UbJ4l ZuZGsCEbBx9B9gA3nosS8lfdn4M8FZEtpbu8RXgTUuvXds6Ka8OIioqZEbrUv2oECvDm lkxVTgPx7Js2Kvww9TlqVt5js4RCDwh7V6qY2rgW4yAFOUVfUIs8TWs/3V8zHWXzecK1 8nuEuf8isygG/Duo20Dc/NjnOe08NgGHvjpR36ZF5u1FnatiqwhsvhuFBuNdQ23yi8I1 IxjQ== MIME-Version: 1.0 X-Received: by 10.49.19.101 with SMTP id d5mr42120437qee.78.1384120873030; Sun, 10 Nov 2013 14:01:13 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Sun, 10 Nov 2013 14:01:12 -0800 (PST) Received: by 10.224.207.66 with HTTP; Sun, 10 Nov 2013 14:01:12 -0800 (PST) In-Reply-To: <20131110193421.GB1778@mole.fafoe.narf.at> References: <20131110121737.GA1834@mole.fafoe.narf.at> <20131110163340.GA1778@mole.fafoe.narf.at> <20131110193421.GB1778@mole.fafoe.narf.at> Date: Sun, 10 Nov 2013 14:01:12 -0800 X-Google-Sender-Auth: 8B0swMie1ntvJ7oy_ivg8Ke7TTM Message-ID: Subject: Re: iwn(4) hangs after r257133 From: Adrian Chadd To: Stefan Farfeleder Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Brandon Gooch , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 22:01:14 -0000 Yes. So one of the.. unfortunately broken things in iwn is the ampdu tx code doesn't do retransmits. So if amrr picks a rate that fails to transmit everything, the driver doesn't retransmit them. It frees them. Now when amrr is enabled the hardware will retry at lower rates until something succeeds. But it still doesn't retransmit things. I believe it should be. So yes its more broken with Mrr disabled. But enabling mrr doesn't fix it. It just makes it less broken. Someone needs to implement ampdu retransmit. The latest iwn code in head at least tells the rate selection code that a total ampdu tx failure occured. This BTW is one of the hangs I fixed - if you hit a point where you never successfully transmitted an ampdu at a rate the rate would never be decreased. Now to be clear. I won't be in implementing ampdu retransmit. I'll maybe fix last multi rate retry once the new hardware support is in. I would really appreciate help here with these. Everyone with iwn hardware will appreciate it :) Thanks, Adrian Adrian On Nov 10, 2013 11:34 AM, "Stefan Farfeleder" wrote: > On Sun, Nov 10, 2013 at 10:48:48AM -0800, Adrian Chadd wrote: > > Right near the end there you have 'status 83' which means 'transmit > > failed, long retry hit' (the status codes are in if_iwnreg.h > > somewhere.) The retry count hit 16, which is the max set for the > > frame. > > > > rate=80 (hex) is MCS0. So, you're seeing retransmits and failures at > > MCS0, which is a bad sign. > > > > But, notice how AMRR increased it to MCS2 at a couple stages, and that > > _always_ fails. But AMRR waits for 10 frame transmits before it > > adjusts the rate up or down. > > > > So yes, we do need to enable MRR again on iwn for things to behave > > better. There are other issues when you start doing larger amounts of > > traffic but I'll cover those later.what? > > > > If someone wants to take a crack at correctly implementing the link > > quality table stuff again then please let me know. As I said before, > > the link quality table setup code is mostly sane. The problem is > > actually correctly setting 'linkq' to start at the selected rate, as > > linkq is an index into that table, not the initial rate. > > Hi, > > after some trial and error I found out that disabling AMPDU makes my > iwn0 usable again. Now I actually see the rate as reported by `list sta' > going up and down (mostly between 54M and 121M). Before it was always > fixed at 135M. > > Could this be related? > > Stefan > From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 22:03:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0473AE5C; Sun, 10 Nov 2013 22:03:14 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C948B251A; Sun, 10 Nov 2013 22:03:13 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id bj1so3201680pad.28 for ; Sun, 10 Nov 2013 14:03:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=YG2vIcG3fW2AvOPnvEoZxg9TFl2fHffCPaH9J8OQ7HE=; b=AlbwPrWnNPMaIXGYHyh6ps5g+8v02/IlxU4AZZvLWql7fyCMOyz4OcD9M37SgCZruP IH6mhRpPerMtHB77s8e4BYERG00xsgIujCjNziey58NW/RTiWzSBhAkRrbBqVLwBZ/MM 7P00GDoKoI6M9FNijF0ORM9Ki/G/gggx8NzPvpptDiI0T/Qi/E7njRGNClOpf6mfFrzZ lIYP5paEVlNQ7W1Rf6kwPOpBsLJ1YzBlYn+egZjBBzeHe3ELyrwo/D3g4glQ7W9Wp/oX CJtPc38lYmUIJQeTtb9fciJOHmqF0bM0rtahheZonCXAB7NyMFeoGxc8LoShUKsQTCqy GC+A== MIME-Version: 1.0 X-Received: by 10.66.246.229 with SMTP id xz5mr4302115pac.128.1384120993073; Sun, 10 Nov 2013 14:03:13 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.67.23.101 with HTTP; Sun, 10 Nov 2013 14:03:13 -0800 (PST) In-Reply-To: References: <527F95BE.7080908@gmx.com> <527FC05D.8080703@gmx.com> Date: Sun, 10 Nov 2013 14:03:13 -0800 X-Google-Sender-Auth: YrqE2k7OgpgRbPJXaILWlG9wOsQ Message-ID: Subject: Re: new Xorg (KMS, etc.) for Radeon 9600 From: Kevin Oberman To: Daniel Eischen Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "dt71@gmx.com" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 22:03:14 -0000 On Sun, Nov 10, 2013 at 9:34 AM, Daniel Eischen wrote: > > On Nov 10, 2013, at 12:20 PM, dt71@gmx.com wrote: > > > > Daniel Eischen wrote, On 11/10/2013 17:40: > >> My -current is still from ~July 3, and I also got panics > >> when trying new Xorg. Take the drm devices out of your > >> kernel configuration and let X load the necessary drm2 > >> devices when it starts. This allowed it to work for me. > > > > Hmm, works for me to avoid panics and hard reboots. Problems: > > 1. Switching to the virtual terminals or shutting down X causes the > display to go black and unrevivable -- a (soft) reboot is necessary. > > 2. A 3D application crashes with SIGBUS, and the stack gets toasted. > > Yes, I can get it to crash also when using a Java-based GUI, but it works > for all the basic X apps that I need. I also have the virtual terminal > switching problem also, but I think that is being addressed with newsyscons. > > It really does suck not having a functional X. > > For the record, newcons (not newsyscons) is available for testing. I'll admit that I have not tried it, but there have been quite a few positive reports on it. https://wiki.freebsd.org/Newcons. -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 00:22:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 19D5A609 for ; Mon, 11 Nov 2013 00:22:52 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E2FFD2C46 for ; Mon, 11 Nov 2013 00:22:51 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id ro12so1357683pbb.13 for ; Sun, 10 Nov 2013 16:22:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=192MOVEn2PgUFr2IoOuxvEtUT7HuwboZJqeCnsEL8Mw=; b=N19wEJP/I/2qY4aPxOOImI0HZwzO2qgYki2LfpJbVrjP6BxEFLe0YOatVrkOCoh/qE iIJHM15oqMq5xkMjQsyMgUcX0rnHpoqO+9isQPzO2CwAzd0xxc9J5ZqLTQXcwGItWK2j b7ri984sLeUKm9lsQaDsbAnfRevHBhVEzv4Zs7ogFOtJZyiAmm/2A0byE7yU5MCLh9Ju pU9upvGqTxpJLUvg3+ylSl019c4cRHLtL9rynyZWCXTYnCPIhJqHrM+YO5sfN6mV9rkn Hfb4hkEmUwOh2g6P9jGWpARQ4uE27R2O1KosyX6/pFLMFYcF785Jo8lTJ1POTz9GxB5K 2t8g== X-Gm-Message-State: ALoCoQl5doyOj0axdy6oPwIUEjH4Xy7B8MeL5JLVh8IsyZ5viqjoYJGUSj7XahB1X96hG6S80tFH X-Received: by 10.68.180.131 with SMTP id do3mr27483523pbc.34.1384129371110; Sun, 10 Nov 2013 16:22:51 -0800 (PST) Received: from [192.168.2.126] (99-74-169-43.lightspeed.sntcca.sbcglobal.net. [99.74.169.43]) by mx.google.com with ESMTPSA id i6sm26768671pbc.1.2013.11.10.16.22.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 Nov 2013 16:22:50 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: freebsd perf testing From: Tim Kientzle In-Reply-To: <2034DAAF-F264-42B7-A497-4B2CB846381A@cederstrand.dk> Date: Sun, 10 Nov 2013 16:22:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0EF12A1A-401D-4EC4-8492-E7AC893470F0@kientzle.com> References: <527C462F.9040707@elischer.org> <527F47AC.50705@freebsd.org> <2034DAAF-F264-42B7-A497-4B2CB846381A@cederstrand.dk> To: Erik Cederstrand X-Mailer: Apple Mail (2.1822) Cc: George Neville-Neil , FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 00:22:52 -0000 On Nov 10, 2013, at 1:05 PM, Erik Cederstrand = wrote: > Imagine being able to fetch a VirtualBox disk image for a random SVN = commit, booting it and start debugging right away.=20 I=92ve been working on Crochet=92s support for building VMWare images recently and have started using that approach to iterate my dev environment (using one VM to build a new VM instead of upgrading in place). Tim From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 04:17:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 41665D2E; Mon, 11 Nov 2013 04:17:26 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id EBE4226B5; Mon, 11 Nov 2013 04:17:25 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id 92DBED63D75; Mon, 11 Nov 2013 14:21:57 +1100 (EST) Date: Mon, 11 Nov 2013 14:21:56 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Andreas Tobler Subject: Re: WEAK_REFERENCE? In-Reply-To: <527EB428.6070104@FreeBSD.org> Message-ID: <20131111141824.H944@besplex.bde.org> References: <527EB428.6070104@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=bpB1Wiqi c=1 sm=1 tr=0 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=-YheC53aFHcA:10 a=6I5d2MoRAAAA:8 a=rmbFQbMWqEFq1J6Obm8A:9 a=CjuIK1q_8ugA:10 X-Mailman-Approved-At: Mon, 11 Nov 2013 04:25:47 +0000 Cc: Current , brde@optusnet.com.au X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 04:17:26 -0000 On Sat, 9 Nov 2013, Andreas Tobler wrote: > anyone interested in this patch to remove the WEAK_ALIAS and introduce > the WEAK_REFERENCE? > > http://people.freebsd.org/~andreast/weak_ref.amd64.diff > > I have this running since months on amd64 and I have no issues with. > > I remember having had a communication with bde@ that he is in favour in > doing that but I lacked the time to complete. > A similar thing is pending for i386 and sparc64. The ppc stuff is > already committed since a longer time. > > If no one is interested, I'm happy to clean up my tree and skip this. I have only minor interest in it. I might have looked at it before. This version formats the backslashes in macro definitions very badly by putting them in random columns between about 96 and 120 instead of in column 72. Bruce From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 05:46:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 296638BD; Mon, 11 Nov 2013 05:46:01 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8FA182AA3; Mon, 11 Nov 2013 05:46:00 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id l18so4159668wgh.30 for ; Sun, 10 Nov 2013 21:45:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YNd6YF0+O9X9nXuxmoeKddFzqmchZLMA4wbsBGYgOnM=; b=NL9qFTUZR7PfY9U/KO5oSsazXYKooYrSb2jGJjWZ3vc8C2LHBCNFpLRi3+AYDSyQgS YI7kdkaDcOBTjgRyV73yBEXTrZSNhKOd6AIqaJh9RzFTl7w5SIPEaIYHWTbaHE8lffh3 PKEmA9vG4jXiaSE5+L1TBorxHNoctThYNz7/a4MoI9jb0Y3JVKlI8xr7i3VnpW+cc08w G/CdPhCIbxVl5TZgFC184LHY9CpCtXnZ/7dVQuHgqc4XirK9638B9hOgm+i8L6s57nfh MteMbPwll6qhlNbGeKs7GDzU7KSpVCoGGCVjyETgM12d8emES/RSIUusaAIm46oDDx0t HAkQ== X-Received: by 10.194.235.138 with SMTP id um10mr21412037wjc.30.1384148758896; Sun, 10 Nov 2013 21:45:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.240.198 with HTTP; Sun, 10 Nov 2013 21:45:28 -0800 (PST) In-Reply-To: References: <52792B60.1030309@allanjude.com> <527AFAA1.1040001@allanjude.com> <527BCA55.2000207@allanjude.com> <527C5D52.7030508@allanjude.com> <047405A8-B6EB-427B-A2E4-6254DD1A077B@orthanc.ca> <3E6377FF-69FE-48E4-BFB1-E5095A7FA1BB@orthanc.ca> <527C6DEF.6020102@allanjude.com> <527E3EB3.6000301@FreeBSD.org> <8034B822-F903-43D1-8BF6-DFAD7C22F5B0@gsoft.com.au> <527ED34A.1060401@allanjude.com> <527EE417.6060704@allanjude.com> <527EE84D.4060901@allanjude.com> From: Jia-Shiun Li Date: Mon, 11 Nov 2013 13:45:28 +0800 Message-ID: Subject: Re: cron(8) improvement To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 05:46:01 -0000 On Sun, Nov 10, 2013 at 10:13 AM, Adrian Chadd wrote: > > The point I'm making is this: > > * when populating rc.conf.d/, don't just do 'cp' in a post-install script > * when populating the cron daemon entries in rc.cron.d, don't just > 'cp' in a post-install script. > > sounds like we need a ports/pkg config system for admins *after* they have been installed, if bsdconfig interface for en-/disabling services is too simple to do what users want. For cron.d I believe only a few will object it. It is only question who should put files in it. Taking dbus/hald for example, that probably belongs to xorg meta-ports to do the necessary works to enable it, if dbus users prefer to enable it manually. And that will involve painful package dependencies. Imagine more complex cases like letting user choose cron tasks to enable. ports/pkg being a wrapper around 3rd party packages, inevitably it will need to decide some default settings in advance for user. For compile time it is probably ok, or user can choose to compile it with different options. Do we need to agree on some common user interface to do the run-time user-adjustable settings for applications? That's probably also subject to what a pkg install should do by definition. -Jia-Shiun. From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 07:47:16 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9F7F6A0D; Mon, 11 Nov 2013 07:47:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 12F472100; Mon, 11 Nov 2013 07:47:15 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rAB7l6pY017116; Mon, 11 Nov 2013 09:47:06 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rAB7l6pY017116 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rAB7l60t017115; Mon, 11 Nov 2013 09:47:06 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 11 Nov 2013 09:47:06 +0200 From: Konstantin Belousov To: Andreas Tobler Subject: Re: WEAK_REFERENCE? Message-ID: <20131111074706.GK59496@kib.kiev.ua> References: <527EB428.6070104@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Lh8gT63l/JjxhvGL" Content-Disposition: inline In-Reply-To: <527EB428.6070104@FreeBSD.org> User-Agent: Mutt/1.5.22 (2013-10-16) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Current , brde@optusnet.com.au X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 07:47:16 -0000 --Lh8gT63l/JjxhvGL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 09, 2013 at 11:16:08PM +0100, Andreas Tobler wrote: > Hi all, >=20 > anyone interested in this patch to remove the WEAK_ALIAS and introduce > the WEAK_REFERENCE? >=20 > http://people.freebsd.org/~andreast/weak_ref.amd64.diff >=20 > I have this running since months on amd64 and I have no issues with. >=20 > I remember having had a communication with bde@ that he is in favour in > doing that but I lacked the time to complete. > A similar thing is pending for i386 and sparc64. The ppc stuff is > already committed since a longer time. >=20 > If no one is interested, I'm happy to clean up my tree and skip this. I am not sure why do you include the changes to END() in the same patch. Did you looked over the all END() usages on amd64, is it always paired with ENTRY() ? The CNAME() for ELF is the pedantism anyway. Other than the somewhat questionable inclusion of the END() change, which should be committed separately, if ever, I think the change is fine. --Lh8gT63l/JjxhvGL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSgIt5AAoJEJDCuSvBvK1B3P0P/0HMeWYpDt6fguj67/UnNQWt CyWQt4SGtNOugxwcTSamM9Iyi+u0Ug7I+ksi+5EoiZZOQsII3rXxOa+dKRYBz6nf /lhQogzrWuQRrHZw+eBFqiRarNJ06y6vWqBVJx5ENJv5BPAApOCeoJNvlJqZpYZ6 nQwOwvqeanFKsMfJa7BizG+dTXDn7T5AOcRrv7VJ3Q3RhP9ejnjFnFvWV8rYoXcd 5RTdeDv0hW0rtywVoBL/UsnBhjcokOBLMH3/XsG5ZFEbm+UKT8WWeykpQ0aE/Ycx v+38+i8bDv6XLY8z6CQDurfzX8PsSev4HS2U7Fh8h7/1/0Rr+4gWcG+Cp66GVh4c NjI6GtcJ3X0TU43nzQLbCW3uNnDnVyjVsHQ13ChpznzFWdolmFzDMhW1ZlEYXFhZ Iy78UlP0jlGsN5xI+G42HrTYBkh/QqKTVVzREeCLd6n1y5Btpa9lYOYM+y9r3SUm UnpwNf6iZS4rarA8epqy7oe8LeTLXnRBJZRwBBfQr4EWzClnssRXRM162Bf7xECq pHQVZRd665S0iopIKV4YSCvJ21BGKWGT9O6NqkRif70wrlZ9DBi2Jw+mZxP6wYo1 16hkoSjlMj3umyKZaRFrt94vhug39UDDM92oKP1N8TbOlrSQGnHpngFIH15smrWT 0uelLJrSL5arkQ0/Acf9 =bKth -----END PGP SIGNATURE----- --Lh8gT63l/JjxhvGL-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 08:19:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7E966D58; Mon, 11 Nov 2013 08:19:07 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep23.mx.upcmail.net (fep23.mx.upcmail.net [62.179.121.43]) by mx1.freebsd.org (Postfix) with ESMTP id A98702292; Mon, 11 Nov 2013 08:19:06 +0000 (UTC) Received: from edge04.upcmail.net ([192.168.13.239]) by viefep23-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20131111081858.JGC13029.viefep23-int.chello.at@edge04.upcmail.net>; Mon, 11 Nov 2013 09:18:58 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge04.upcmail.net with edge id o8Jy1m01G2xdvHc038Jyuj; Mon, 11 Nov 2013 09:18:58 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id 3C8176D44C; Mon, 11 Nov 2013 09:18:58 +0100 (CET) Date: Mon, 11 Nov 2013 09:18:58 +0100 From: Stefan Farfeleder To: Adrian Chadd Subject: Re: iwn(4) hangs after r257133 Message-ID: <20131111081857.GA1809@mole.fafoe.narf.at> References: <20131110121737.GA1834@mole.fafoe.narf.at> <20131110163340.GA1778@mole.fafoe.narf.at> <20131110193421.GB1778@mole.fafoe.narf.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: Brandon Gooch , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 08:19:07 -0000 On Sun, Nov 10, 2013 at 02:01:12PM -0800, Adrian Chadd wrote: > Yes. So one of the.. unfortunately broken things in iwn is the ampdu tx > code doesn't do retransmits. So if amrr picks a rate that fails to transmit > everything, the driver doesn't retransmit them. It frees them. > > Now when amrr is enabled the hardware will retry at lower rates until > something succeeds. But it still doesn't retransmit things. I believe it > should be. > > So yes its more broken with Mrr disabled. But enabling mrr doesn't fix it. > It just makes it less broken. Someone needs to implement ampdu retransmit. > > The latest iwn code in head at least tells the rate selection code that a > total ampdu tx failure occured. This BTW is one of the hangs I fixed - if > you hit a point where you never successfully transmitted an ampdu at a rate > the rate would never be decreased. > > Now to be clear. I won't be in implementing ampdu retransmit. I'll maybe > fix last multi rate retry once the new hardware support is in. I would > really appreciate help here with these. Everyone with iwn hardware will > appreciate it :) In the mean time, wouldn't it make sense to disable ampdu tx in iwn then? Or to disallow the combination Mrr + ampdu? Stefan From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 09:07:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 61F53C77 for ; Mon, 11 Nov 2013 09:07:12 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay008.isp.belgacom.be (mailrelay008.isp.belgacom.be [195.238.6.174]) by mx1.freebsd.org (Postfix) with ESMTP id 018432569 for ; Mon, 11 Nov 2013 09:07:11 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMGAJGdgFJbsUjb/2dsb2JhbABZgwfAHYEvF3SCJQEBBTocIxALGAklDyoeGYdvAxMBvX+MdYJyBxaEGgOYDpILgyc7 Received: from 219.72-177-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.177.72.219]) by relay.skynet.be with ESMTP; 11 Nov 2013 10:07:09 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.7/8.14.7) with ESMTP id rAB978Uq001439; Mon, 11 Nov 2013 10:07:08 +0100 (CET) (envelope-from tijl@coosemans.org) Date: Mon, 11 Nov 2013 10:07:07 +0100 From: Tijl Coosemans To: dt71@gmx.com Subject: Re: new Xorg (KMS, etc.) for Radeon 9600 Message-ID: <20131111100707.481d2fbf@kalimero.tijl.coosemans.org> In-Reply-To: <527FC05D.8080703@gmx.com> References: <527F95BE.7080908@gmx.com> <527FC05D.8080703@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 09:07:12 -0000 On Sun, 10 Nov 2013 18:20:29 +0100 dt71@gmx.com wrote: > info: [drm] Loading R300 Microcode > radeonkmsfw_R300_cp: could not load firmware image, error 2 > error: [drm:pid667:r100_cp_init_microcode] *ERROR* radeon_cp: Failed to load firmware "radeonkmsfw_R300_cp" > error: [drm:pid667:r100_cp_init] *ERROR* Failed to load firmware! > drmn0: error: failed initializing CP (-2). > drmn0: error: Disabling GPU acceleration Make sure you have /boot/kernel/radeonkmsfw_R300_cp.ko. From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 09:28:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 40C637FB for ; Mon, 11 Nov 2013 09:28:12 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm14-vm1.bullet.mail.ird.yahoo.com (nm14-vm1.bullet.mail.ird.yahoo.com [77.238.189.91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 301B2268B for ; Mon, 11 Nov 2013 09:28:10 +0000 (UTC) Received: from [77.238.189.50] by nm14.bullet.mail.ird.yahoo.com with NNFMP; 11 Nov 2013 09:28:03 -0000 Received: from [46.228.39.90] by tm3.bullet.mail.ird.yahoo.com with NNFMP; 11 Nov 2013 09:28:03 -0000 Received: from [127.0.0.1] by smtp127.mail.ir2.yahoo.com with NNFMP; 11 Nov 2013 09:28:03 -0000 X-Yahoo-Newman-Id: 672496.37574.bm@smtp127.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: LBqEcVQVM1mUZHVBtKzuT_6mKxjvzrPdqHtVoUaACUm99S3 n1i6WAjjTAH6HL5WetR2KAgiZyKKj6diaXD8xnqDnT3CVRcRNy6jAsut.3Bf F_.qw5Hq5jfndPlSm72yFtuQv0MtYqnWDZqdm9BtvtWQPo91RvFxQZWuIVfu Iv0QBd29pperPojoOtpZi0FOAFmiVrKnf31lGCcqxefmaqe2nTbhxpvMijqG eYnNMJGleHpyRM8wmtNLXEgyuePNMyjHC80fwQJ_0YMe7oErIaqb3WC5rDmD 7Z_H4.Vxmp5hl3E.P1vZYBv6t3TwmThktJANQOiTIPEnIs6qhibo8QooD.LY 9rDgmt_gs0Laus5PMqG4a24yjv8mYAAsexUPdCq3oO5Xh2YOa0IX1oQCAS2F Bmf0P_1b4Kpjt8nHKtG4arWimd_Cbz17hy9VIDJPPm5ipq80Kxuo2H0VB__o rYc5VWTsGYdroTk3WinEASY4jym7IWwJskP5.RxR0yWIvFmrFUOYAng5_qkw H39WVNt4cQ319nL4PHgxMB63DZta6DTo- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. X-Rocket-Received: from [192.168.119.11] (se@84.154.104.222 with ) by smtp127.mail.ir2.yahoo.com with SMTP; 11 Nov 2013 09:28:03 +0000 UTC Message-ID: <5280A320.9020705@freebsd.org> Date: Mon, 11 Nov 2013 10:28:00 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: cron(8) improvement References: <52792B60.1030309@allanjude.com> <488180AE-5C23-402A-BAA4-E3263D8C52BF@kientzle.com> <1383788977.14448.44112617.6F0D61A0@webmail.messagingengine.com> <527AFAA1.1040001@allanjude.com> <527BCA55.2000207@allanjude.com> <527C5D52.7030508@allanjude.com> <047405A8-B6EB-427B-A2E4-6254DD1A077B@orthanc.ca> <3E6377FF-69FE-48E4-BFB1-E5095A7FA1BB@orthanc.ca> <527C6DEF.6020102@allanjude.com> <527E3EB3.6000301@FreeBSD.org> <8034B822-F903-43D1-8BF6-DFAD7C22F5B0@gsoft.com.au> <527FBB6B.5020706@smo.de> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 09:28:12 -0000 Am 10.11.2013 18:23, schrieb Warren Block: > On Sun, 10 Nov 2013, Philipp Ost wrote: >> Warren Block schrieb: >> [...] >> Given the above scenario, would it be acceptable to set the entry in >> rc.conf, $portname_cron=YES, to $portname_cron=NO without touching the >> modified files and inform the user about having done so? > > I would not want the system modifying rc.conf for me, but don't have a > better idea at present. Maybe move customized cronfiles to an "old" > folder on deinstall, so at least the user could recover them. I like the idea that entries are ignored unless they end in ".cron". This does not only allow to install inactive cron scheduled in a file ending in ".cron.sample", it also lets you rename modified cron tabs to e.g. ".cron.off" (a convention often used by me). If the port is re-installed, it is up the administrator to decide whether a schedule based on a freshly installed ".cron.sample" or the old ".cron.off" should be enabled. This would require the deinstall target / tool to rename any cron entry of the port / package by appending ".off", but that's a minor change, IMHO. This might lead to some clutter in ".../cron.d/", but I do not think that stale files should be automatically removed (even if they were older than some threshold). Regards, STefan From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 13:03:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0AC6857A; Mon, 11 Nov 2013 13:03:56 +0000 (UTC) (envelope-from bsiegert@gmail.com) Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AF6F325AB; Mon, 11 Nov 2013 13:03:55 +0000 (UTC) Received: by mail-vb0-f47.google.com with SMTP id g10so945305vbg.6 for ; Mon, 11 Nov 2013 05:03:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=TLmbx8XOk6j7OBqG9BWrFhUiZ3TKBLZcyf5MPj/OlDs=; b=diw0mWRAt+0N9M45I2rOyZtCNDDd9JjMHigFu886vues5MPGm8Ym9D4QrLOspHkCQy ZmkKXxjjW+vYgvSirw7mhQWOurQCP/eNDyKVeQhKCqVlOWH06gDTe2nAI+ZO6Byl4YoD 5uOMEb1IzpO9GTFhlV4PHV7H+O9PJAMM0I3GcYRFKImAlsaKevo5I66GQU/m2BJI2F8l h4zCtRRkaSddfsCoBKs34Wz4CndUaPiS9twd+hFHE+fUETQiZyRHnoQmHUEoDCUvG4dt KJstftg41o/d/awV8GhkqrvulUg/jEQiuUdoNWnm5x4ZjyLTMISzHiIs1Rwn6kJXFRSP T/Ew== MIME-Version: 1.0 X-Received: by 10.220.184.70 with SMTP id cj6mr1790731vcb.23.1384175034863; Mon, 11 Nov 2013 05:03:54 -0800 (PST) Received: by 10.52.168.169 with HTTP; Mon, 11 Nov 2013 05:03:54 -0800 (PST) Date: Mon, 11 Nov 2013 14:03:54 +0100 Message-ID: Subject: Call for presentations: BSD devroom at FOSDEM 2014 From: Benny Siegert To: freebsd-advocacy@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 11 Nov 2013 13:25:48 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 13:03:56 -0000 Hello all, FOSDEM 2014 will take place on 1=E2=80=932 February, 2014, in Brussels, Belgium. Just like in the last years, there will be both a BSD booth and a developer's room (on Saturday). The topics of the devroom include all BSD operating systems. Every talk is welcome, from internal hacker discussion to real-world examples and presentations about new and shiny features. The default duration for talks will be 45 minutes including discussion. Feel free to ask if you want to have a longer or a shorter slot. If you already submitted a talk last time, please note that the procedure is slightly different. To submit your proposal, visit https://penta.fosdem.org/submission/FOSDEM14/ and follow the instructions to create an account and an =E2=80=9Cevent=E2= =80=9D. Please select =E2=80=9CBSD devroom=E2=80=9D as the track. (Click on =E2=80= =9CShow all=E2=80=9D in the top right corner to display the full form.) Please include the following information in your submission: * The title and subtitle of your talk (please be descriptive, as titles will be listed with ~500 from other projects) * A short abstract of one paragraph * A longer description if you wish to do so * Links to related websites/blogs etc. The deadline for submissions is December 20, 2013. The talk committee, consisting of Daniel Seuffert, Marius N=C3=BCnnerich and Benny Siegert, will consider the proposals. If yours has been accepted, you will be informed by e-mail before the end of the year. Best regards, Benny Siegert (for the BSD devroom organizers) From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 15:04:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 96D3D3EC for ; Mon, 11 Nov 2013 15:04:05 +0000 (UTC) (envelope-from lars.engels@0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 591952DA7 for ; Mon, 11 Nov 2013 15:04:05 +0000 (UTC) Received: from 0x20.net (0x20.net [217.69.76.212]) (Authenticated sender: lala) by mail.0x20.net (Postfix) with ESMTPA id A16056A6004 for ; Mon, 11 Nov 2013 16:03:59 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 11 Nov 2013 16:03:59 +0100 From: Lars Engels To: freebsd-current@freebsd.org Subject: Re: iwn(4) hangs after r257133 In-Reply-To: <20131111081857.GA1809@mole.fafoe.narf.at> References: <20131110121737.GA1834@mole.fafoe.narf.at> <20131110163340.GA1778@mole.fafoe.narf.at> <20131110193421.GB1778@mole.fafoe.narf.at> <20131111081857.GA1809@mole.fafoe.narf.at> Message-ID: <751d83f294765dbf0c213e18e8eb721b@mail.0x20.net> X-Sender: lars.engels@0x20.net User-Agent: Roundcube Webmail/0.7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 15:04:05 -0000 Am 11.11.2013 09:18, schrieb Stefan Farfeleder: > On Sun, Nov 10, 2013 at 02:01:12PM -0800, Adrian Chadd wrote: >> Yes. So one of the.. unfortunately broken things in iwn is the ampdu >> tx >> code doesn't do retransmits. So if amrr picks a rate that fails to >> transmit >> everything, the driver doesn't retransmit them. It frees them. >> >> Now when amrr is enabled the hardware will retry at lower rates until >> something succeeds. But it still doesn't retransmit things. I believe >> it >> should be. >> >> So yes its more broken with Mrr disabled. But enabling mrr doesn't fix >> it. >> It just makes it less broken. Someone needs to implement ampdu >> retransmit. >> >> The latest iwn code in head at least tells the rate selection code >> that a >> total ampdu tx failure occured. This BTW is one of the hangs I fixed - >> if >> you hit a point where you never successfully transmitted an ampdu at a >> rate >> the rate would never be decreased. >> >> Now to be clear. I won't be in implementing ampdu retransmit. I'll >> maybe >> fix last multi rate retry once the new hardware support is in. I would >> really appreciate help here with these. Everyone with iwn hardware >> will >> appreciate it :) > > In the mean time, wouldn't it make sense to disable ampdu tx in iwn > then? Or to disallow the combination Mrr + ampdu? Yes, please. I'm also encountering this. From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 20:18:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5A0D4C5E; Mon, 11 Nov 2013 20:18:15 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1FA0123EC; Mon, 11 Nov 2013 20:18:14 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa02.fnfis.com (8.14.5/8.14.5) with ESMTP id rABKIDlH012125 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Nov 2013 14:18:13 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.152]) by LTCFISWMSGHT04.FNFIS.com ([10.132.206.15]) with mapi id 14.03.0158.001; Mon, 11 Nov 2013 14:18:11 -0600 From: "Teske, Devin" To: Michael Dexter Subject: Re: [CFT] bsdinstall and zfsboot enhancements Thread-Topic: [CFT] bsdinstall and zfsboot enhancements Thread-Index: AQHO1/VTfN3AabWEO0qqCcwz4iQiNg== Date: Mon, 11 Nov 2013 20:18:11 +0000 Message-ID: References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> <5281340E.8080009@callfortesting.org> In-Reply-To: <5281340E.8080009@callfortesting.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-11-11_03:2013-11-11,2013-11-11,1970-01-01 signatures=0 Cc: Current Current , Devin Teske , "Teske, Devin" , Peter Grehan , Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:18:15 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBNTEyDQoNCg0KT24g Tm92IDExLCAyMDEzLCBhdCAxMTo0NiBBTSwgTWljaGFlbCBEZXh0ZXIgd3JvdGU6DQoNCg0KSGVs bG8gYWxsLA0KDQpJIGhhdmUgYmVlbiBleHBlcmltZW50aW5nIHdpdGggdmFyaW91cyBCU0QgYW5k IEdOVS9MaW51eCBib290IG1lZGlhDQp1bmRlciBiaHl2ZSBhbmQgbm90aWNlZCB0aGF0IHdlIG1h eSB3YW50IHRvIGFjY29tbW9kYXRlIHRoZSAiTGl2ZUNEIg0KbW9kZSBvZiB0aGUgaW5zdGFsbGVy LCB3aGljaCBpbiB0dXJuIHJlcXVpcmVzIHRoZSBjb3JyZWN0IGNvbnNvbGUuDQoNCkN1cnJlbnRs eSwgb25lIGlzIHByb21wdGVkIGZvciBWVDEwMCBmb3IgaW5zdGFsbGF0aW9uIGJ1dCB0aGlzIGRv ZXMgbm90DQphcHBlYXIgdG8gd29yay9zdGljayBmb3IgTGl2ZUNEIG1vZGUuDQoNCkNhbiBhbnlv bmUgdmVyaWZ5IHRoaXM/DQoNCg0KV2hpbGUgSSBkZXZlbG9wZWQgdGhpcyBwYXRjaC4uLg0KaHR0 cDovL2RydWlkYnNkLmN2cy5zZi5uZXQvdmlld3ZjL2RydWlkYnNkL2JzZGluc3RhbGxfemZzL3Vz ci5zYmluJTNBJTNBYnNkaW5zdGFsbCUzQSUzQXNjcmlwdHMlM0ElM0Fjb25maWcucGF0Y2g/cmV2 aXNpb249MS4xMCZ2aWV3PW1hcmt1cA0KDQpSZWFzb25zIGV4aXN0IHRvIHNlYXJjaCBmb3IgYSBi ZXR0ZXIgc29sdXRpb24sIHNlZSBoZXJlOg0KaHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL3BpcGVy bWFpbC9mcmVlYnNkLWN1cnJlbnQvMjAxMy1Ob3ZlbWJlci8wNDYxNDguaHRtbA0KKGFuZCBtZXNz YWdlcyB0aGF0IGZvbGxvdyBpdCkNCg0KSXMgbW9kaWZ5aW5nIGluaXQoOCkgc3RpbGwgdGhlIHdh eSB0byBnbz8gV2hhdCBtb2RpZmljYXRpb24gZG8gd2Ugd2FudCB0byBtYWtlPw0KSSdsbCBkbyB0 aGUgd29yayBpZiB3ZSBjYW4gY29tZSB0byBjb25zZW5zdXMuDQoNCk9yIHNob3VsZCB3ZSB0b3Vj aCB1cCB0aGUgcGF0Y2ggaW4gc29tZSB3YXkgdG8gYWRkcmVzcyB0aGUgb3JpZ2luYWwgY29uY2Vy bnM/DQotIC0tIA0KRGV2aW4NCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQpDb21tZW50 OiBHUEdUb29scyAtIGh0dHBzOi8vZ3BndG9vbHMub3JnDQoNCmlRRWNCQUVCQ2dBR0JRSlNnVHVD QUFvSkVLck1uNVI5bnBxNU05MEgvUnJJaE9xaENBUGo5bHlHOUVsTTZObEMNCkcyRUR5YWp6SXFu dHpPUVk2TzlBWlhsK0NyS25kTWtPQXRoT0FZQmZXVFhDSUtWMEo1dGxWMTY3R21mbTI1dFoNCkdR cEprbmVPaUh3TXVoajdGZTBXV0FLYVhXd0xqOEFTVEk2YmoyYkZ6M1hscy81cDBRNllBMFRNQnJh VXA5SzMNCk5WSkdic2NwNFMrQkc2d1lRam9BRXp3ZWsyS3o1eWM0akhTSmhmcmFMVEVXbVV3SGN6 UFY3TGV2cDM3ckxlaVcNCm4vT1FUMXAzdzVPSlZnblJGeTlwdFFDU1QvTWFZVTlLSldQMzYwYlhu cUdZZzZOcnJybEZkSWVqbklJc1NreFgNCnUyMU11K3NGNzZTM3JnMEQrTCtCeVpnYlA5NTdhemNK OU5lRFRvb2kzR2IrL1RxZ1dMOWo0UXlwN0RrUjJubz0NCj1UMkZYDQotLS0tLUVORCBQR1AgU0lH TkFUVVJFLS0tLS0NCgpfX19fX19fX19fX19fClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4g dGhpcyBtZXNzYWdlIGlzIHByb3ByaWV0YXJ5IGFuZC9vciBjb25maWRlbnRpYWwuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZTogKGkpIGRlbGV0ZSB0aGUgbWVz c2FnZSBhbmQgYWxsIGNvcGllczsgKGlpKSBkbyBub3QgZGlzY2xvc2UsIGRpc3RyaWJ1dGUgb3Ig dXNlIHRoZSBtZXNzYWdlIGluIGFueSBtYW5uZXI7IGFuZCAoaWlpKSBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseS4gSW4gYWRkaXRpb24sIHBsZWFzZSBiZSBhd2FyZSB0aGF0IGFueSBtZXNz YWdlIGFkZHJlc3NlZCB0byBvdXIgZG9tYWluIGlzIHN1YmplY3QgdG8gYXJjaGl2aW5nIGFuZCBy ZXZpZXcgYnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIFRoYW5r IHlvdS4K From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 19:46:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 22E205FA for ; Mon, 11 Nov 2013 19:46:27 +0000 (UTC) (envelope-from editor@callfortesting.org) Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E97F421CB for ; Mon, 11 Nov 2013 19:46:25 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id y13so2795081pdi.28 for ; Mon, 11 Nov 2013 11:46:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pkoqHyIQP2yBIO3a0HQEIKS/JhOpwHAWz8E7Knl7yps=; b=YEMvBk+KPRNla0GgEPWDRxiy0CiIHE+f3fJ8PmjB6HylUcAZ8OJBNnpD6idQDun9rX KtWKdG7SXnTMF0bYtfeP7kIl+MvmhVQBanEL4SUwpcyhAzEh9kBG6Cgx7z/SNrsY5DYv jKys4XhzcOdPF2+B8U+Q97EO6IhklT1o/pgPvKkcpLP041ZiEo6tvYybR4nVxb2Lp5l0 LPqhilyO/impiOK7qtFxqcxMI9pxKW/D8F5rpuGKnvI2InTYyogtq5LlCFrbwOa/82W2 JTPQrBaXBCxROfAzrrDR61k4Wm0DEQ1AD6k0ikQD2/pc3cgQRVYQwV8aZ8mbArPyNK+u e/ew== X-Gm-Message-State: ALoCoQmu2smH0UprLoMvEvbuDhxy6/lzWH1s5Ac6MM7ehOqaSrdV8aD8bgGShEcg0rNNJTakIHkN X-Received: by 10.66.149.73 with SMTP id ty9mr31989252pab.36.1384199185240; Mon, 11 Nov 2013 11:46:25 -0800 (PST) Received: from Michaels-MacBook-Pro.local (c-98-246-202-204.hsd1.or.comcast.net. [98.246.202.204]) by mx.google.com with ESMTPSA id at4sm32574608pbc.30.2013.11.11.11.46.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Nov 2013 11:46:24 -0800 (PST) Message-ID: <5281340E.8080009@callfortesting.org> Date: Mon, 11 Nov 2013 11:46:22 -0800 From: Michael Dexter User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Peter Grehan Subject: Re: [CFT] bsdinstall and zfsboot enhancements References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> In-Reply-To: <52769CFE.5080707@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 11 Nov 2013 20:23:48 +0000 Cc: Devin Teske , Nathan Whitehorn , " Current" , "Teske, Devin" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 19:46:27 -0000 Hello all, I have been experimenting with various BSD and GNU/Linux boot media under bhyve and noticed that we may want to accommodate the "LiveCD" mode of the installer, which in turn requires the correct console. Currently, one is prompted for VT100 for installation but this does not appear to work/stick for LiveCD mode. Can anyone verify this? Michael From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 20:30:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 921773A6; Mon, 11 Nov 2013 20:30:18 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id 4A4DB2497; Mon, 11 Nov 2013 20:30:17 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 9D1A958392; Mon, 11 Nov 2013 14:30:11 -0600 (CST) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id y4ulwpv8TmrF; Mon, 11 Nov 2013 14:30:11 -0600 (CST) Received: from terminus.icecube.wisc.edu (terminus.icecube.wisc.edu [172.16.223.97]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 7A80C58391; Mon, 11 Nov 2013 14:30:11 -0600 (CST) Message-ID: <52813E53.20403@freebsd.org> Date: Mon, 11 Nov 2013 14:30:11 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Devin Teske , Michael Dexter Subject: Re: [CFT] bsdinstall and zfsboot enhancements References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> <5281340E.8080009@callfortesting.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Current Current , "Teske, Devin" , Peter Grehan , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:30:18 -0000 On 11/11/13 14:18, Teske, Devin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > > On Nov 11, 2013, at 11:46 AM, Michael Dexter wrote: > > > Hello all, > > I have been experimenting with various BSD and GNU/Linux boot media > under bhyve and noticed that we may want to accommodate the "LiveCD" > mode of the installer, which in turn requires the correct console. > > Currently, one is prompted for VT100 for installation but this does not > appear to work/stick for LiveCD mode. > > Can anyone verify this? > > > While I developed this patch... > http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/usr.sbin%3A%3Absdinstall%3A%3Ascripts%3A%3Aconfig.patch?revision=1.10&view=markup > > Reasons exist to search for a better solution, see here: > http://lists.freebsd.org/pipermail/freebsd-current/2013-November/046148.html > (and messages that follow it) > > Is modifying init(8) still the way to go? What modification do we want to make? > I'll do the work if we can come to consensus. > > Or should we touch up the patch in some way to address the original concerns? > I think modifying init is the way to go -- it keeps the install system from interfering with the installed one, as well as fixing this kind of issue with moved hard drives or PXE booting or what have you. If we can provide a guarantee that any system that displays text has a working console (unless explicitly configured not to), useability is improved. I would propose one of the following (and volunteer to write the code): Option A ------------ 1. init checks if there is an entry in /etc/ttys for the terminal[s] corresponding to the value[s] in kern.console 2. If an entry for each console terminal exists in /etc/ttys, enable it 3. If not, invent one with a terminal type of "ansi" The one issue here is that someone may want to force a particular entry to off and still have it be the kernel console. This is tricky. We could invent a new "status" field that is not "on" or "off" ("auto", maybe, or "ifconsole"?). Which brings us to: Option B ----------- Very similar to Option A, except only provide an automatic console using (2) and (3) if the "console" terminal is marked "on". This would increase the magic attached to "console" in /etc/ttys, but fix the problem with (A). It's possible another approach would work as well. Does anyone have thoughts on this? -Nathan From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 20:30:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 392CE55C; Mon, 11 Nov 2013 20:30:53 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0018C24B5; Mon, 11 Nov 2013 20:30:52 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa05.fnfis.com (8.14.5/8.14.5) with ESMTP id rABKUp3t022477 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Nov 2013 14:30:51 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.152]) by LTCFISWMSGHT04.FNFIS.com ([10.132.206.15]) with mapi id 14.03.0158.001; Mon, 11 Nov 2013 14:30:50 -0600 From: "Teske, Devin" To: Michael Dexter Subject: Re: [CFT] bsdinstall and zfsboot enhancements Thread-Topic: [CFT] bsdinstall and zfsboot enhancements Thread-Index: AQHO1/VTfN3AabWEO0qqCcwz4iQiNg== Date: Mon, 11 Nov 2013 20:30:50 +0000 Message-ID: References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> <5281340E.8080009@callfortesting.org> In-Reply-To: <5281340E.8080009@callfortesting.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-11-11_03:2013-11-11,2013-11-11,1970-01-01 signatures=0 Cc: Current Current , Devin Teske , "Teske, Devin" , Peter Grehan , Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:30:53 -0000 (disabling default gpg-signing until they fix a bug with the quoting) On Nov 11, 2013, at 11:46 AM, Michael Dexter wrote: >=20 > Hello all, >=20 > I have been experimenting with various BSD and GNU/Linux boot media > under bhyve and noticed that we may want to accommodate the "LiveCD" > mode of the installer, which in turn requires the correct console. >=20 > Currently, one is prompted for VT100 for installation but this does not > appear to work/stick for LiveCD mode. >=20 > Can anyone verify this? >=20 Sorry, I mistook your issue in the previous e-mail to be on-going with the thread it was inline with. "LiveCD" changes things a bit. (thinks) I would expect that a prompt could do: 1. modify /etc/ttys on the boot media 2. run "init q" But there's a couple of assumptions... 3. Can we even write to /etc/ttys? NB: We can write to /tmp because it's an md0 swap device So do we have to get fancy with slipping a unionfs layer backed by another md swap device above the root? That would make every file on the boot media writable (writes would go to the swap-backed md device and if you execute "rm -fW file" you can get back files that have been previously unlinked -- unlinks are stored as whiteouts= in the swap backed md device). For all intents and purposes, the read-only fil= e- system becomes writable and we could then munge /etc/ttys to enable serial only when a menu item is chosen. If I'm off-base, let me know... sounds like a lot of trouble. The alternative being that you enable serial by default but then I have to = tell field engineers to unplug barcode readers before they do an install??? (tha= t's a question, it may be entirely safe, but I've never tried, seems unsafe) Question is, how would you disable it? Goes back to writable filesystem. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 20:35:43 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DE611B39; Mon, 11 Nov 2013 20:35:43 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id 962452520; Mon, 11 Nov 2013 20:35:43 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id E3C4258392; Mon, 11 Nov 2013 14:35:42 -0600 (CST) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id HCQirX47sX-U; Mon, 11 Nov 2013 14:35:42 -0600 (CST) Received: from terminus.icecube.wisc.edu (terminus.icecube.wisc.edu [172.16.223.97]) by mail.icecube.wisc.edu (Postfix) with ESMTP id C428158391; Mon, 11 Nov 2013 14:35:42 -0600 (CST) Message-ID: <52813F9E.8080304@freebsd.org> Date: Mon, 11 Nov 2013 14:35:42 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Devin Teske , Michael Dexter Subject: Re: [CFT] bsdinstall and zfsboot enhancements References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> <5281340E.8080009@callfortesting.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Current Current , "Teske, Devin" , Peter Grehan X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:35:43 -0000 On 11/11/13 14:30, Teske, Devin wrote: > (disabling default gpg-signing until they fix a bug with the quoting) > > On Nov 11, 2013, at 11:46 AM, Michael Dexter wrote: > >> Hello all, >> >> I have been experimenting with various BSD and GNU/Linux boot media >> under bhyve and noticed that we may want to accommodate the "LiveCD" >> mode of the installer, which in turn requires the correct console. >> >> Currently, one is prompted for VT100 for installation but this does not >> appear to work/stick for LiveCD mode. >> >> Can anyone verify this? >> > Sorry, I mistook your issue in the previous e-mail to be on-going with the > thread it was inline with. > > "LiveCD" changes things a bit. > > (thinks) > > I would expect that a prompt could do: > > 1. modify /etc/ttys on the boot media > 2. run "init q" > > But there's a couple of assumptions... > > 3. Can we even write to /etc/ttys? > NB: We can write to /tmp because it's an md0 swap device > > So do we have to get fancy with slipping a unionfs layer backed by another > md swap device above the root? > > That would make every file on the boot media writable (writes would go to > the swap-backed md device and if you execute "rm -fW file" you can get back > files that have been previously unlinked -- unlinks are stored as whiteouts in > the swap backed md device). For all intents and purposes, the read-only file- > system becomes writable and we could then munge /etc/ttys to enable serial > only when a menu item is chosen. > > If I'm off-base, let me know... sounds like a lot of trouble. > > The alternative being that you enable serial by default but then I have to tell > field engineers to unplug barcode readers before they do an install??? (that's > a question, it may be entirely safe, but I've never tried, seems unsafe) > > Question is, how would you disable it? Goes back to writable filesystem. This is why I don't think we want to modify /etc/ttys. Instead we want to have init do the right thing (follow the boot console) with a single unchanged /etc/ttys. -Nathan From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 20:42:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DFF15154; Mon, 11 Nov 2013 20:42:03 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 569E025AC; Mon, 11 Nov 2013 20:42:03 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa02.fnfis.com (8.14.5/8.14.5) with ESMTP id rABKg0XN008749 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Nov 2013 14:42:01 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.152]) by LTCFISWMSGHT04.FNFIS.com ([10.132.206.15]) with mapi id 14.03.0158.001; Mon, 11 Nov 2013 14:40:54 -0600 From: "Teske, Devin" To: Nathan Whitehorn Subject: Re: [CFT] bsdinstall and zfsboot enhancements Thread-Topic: [CFT] bsdinstall and zfsboot enhancements Thread-Index: AQHO1/VTfN3AabWEO0qqCcwz4iQiNg== Date: Mon, 11 Nov 2013 20:40:53 +0000 Message-ID: <4E00C3CC-75EA-4249-8D9F-42F37988F4CE@fisglobal.com> References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> <5281340E.8080009@callfortesting.org> <52813F9E.8080304@freebsd.org> In-Reply-To: <52813F9E.8080304@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-11-11_03:2013-11-11,2013-11-11,1970-01-01 signatures=0 Cc: Current Current , Devin Teske , "Teske, Devin" , Peter Grehan , Michael Dexter X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:42:04 -0000 On Nov 11, 2013, at 12:35 PM, Nathan Whitehorn wrote: > On 11/11/13 14:30, Teske, Devin wrote: >> (disabling default gpg-signing until they fix a bug with the quoting) >>=20 >> On Nov 11, 2013, at 11:46 AM, Michael Dexter wrote: >>=20 >>> Hello all, >>>=20 >>> I have been experimenting with various BSD and GNU/Linux boot media >>> under bhyve and noticed that we may want to accommodate the "LiveCD" >>> mode of the installer, which in turn requires the correct console. >>>=20 >>> Currently, one is prompted for VT100 for installation but this does not >>> appear to work/stick for LiveCD mode. >>>=20 >>> Can anyone verify this? >>>=20 >> Sorry, I mistook your issue in the previous e-mail to be on-going with t= he >> thread it was inline with. >>=20 >> "LiveCD" changes things a bit. >>=20 >> (thinks) >>=20 >> I would expect that a prompt could do: >>=20 >> 1. modify /etc/ttys on the boot media >> 2. run "init q" >>=20 >> But there's a couple of assumptions... >>=20 >> 3. Can we even write to /etc/ttys? >> NB: We can write to /tmp because it's an md0 swap device >>=20 >> So do we have to get fancy with slipping a unionfs layer backed by anoth= er >> md swap device above the root? >>=20 >> That would make every file on the boot media writable (writes would go to >> the swap-backed md device and if you execute "rm -fW file" you can get b= ack >> files that have been previously unlinked -- unlinks are stored as whiteo= uts in >> the swap backed md device). For all intents and purposes, the read-only = file- >> system becomes writable and we could then munge /etc/ttys to enable seri= al >> only when a menu item is chosen. >>=20 >> If I'm off-base, let me know... sounds like a lot of trouble. >>=20 >> The alternative being that you enable serial by default but then I have = to tell >> field engineers to unplug barcode readers before they do an install??? (= that's >> a question, it may be entirely safe, but I've never tried, seems unsafe) >>=20 >> Question is, how would you disable it? Goes back to writable filesystem. >=20 > This is why I don't think we want to modify /etc/ttys. Instead we want to= have init do the right thing (follow the boot console) with a single uncha= nged /etc/ttys. Let me see if I've got it right... Already-knowns: + The boot variables are influenced by loader.conf which is read-only media. + But Michael is loading the media from bhyve. Question: Does bhyve set kern.console irrespective of loader.conf values? If so, then yeah... I'm all for supporting your stated Option-A in the othe= r thread. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 20:43:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A3453286; Mon, 11 Nov 2013 20:43:24 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) by mx1.freebsd.org (Postfix) with ESMTP id 6009F25C2; Mon, 11 Nov 2013 20:43:24 +0000 (UTC) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by alto.onthenet.com.au (Postfix) with ESMTPS id C59CB11E42; Tue, 12 Nov 2013 06:43:22 +1000 (EST) Received: from Peter-Grehans-MacBook-Pro-2.local ([64.245.0.210]) by dommail.onthenet.com.au (MOS 4.2.4-GA) with ESMTP id BPY31834 (AUTH peterg@ptree32.com.au); Tue, 12 Nov 2013 06:43:20 +1000 Message-ID: <52814166.4040105@freebsd.org> Date: Mon, 11 Nov 2013 12:43:18 -0800 From: Peter Grehan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Nathan Whitehorn , Devin Teske , Michael Dexter Subject: Re: [CFT] bsdinstall and zfsboot enhancements References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> <5281340E.8080009@callfortesting.org> <52813E53.20403@freebsd.org> In-Reply-To: <52813E53.20403@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Current Current , "Teske, Devin" , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:43:24 -0000 Hi Nathan, > I think modifying init is the way to go -- it keeps the install system > from interfering with the installed one, as well as fixing this kind of > issue with moved hard drives or PXE booting or what have you. I now agree with this :) Modifying /etc/ttys at install time doesn't work for a lot of cases, LiveCD being the most obvious. > I would propose one of the following (and volunteer to write the code): > > Option A > ------------ > > 1. init checks if there is an entry in /etc/ttys for the terminal[s] > corresponding to the value[s] in kern.console > 2. If an entry for each console terminal exists in /etc/ttys, enable it > 3. If not, invent one with a terminal type of "ansi" > > The one issue here is that someone may want to force a particular entry > to off and still have it be the kernel console. This is tricky. We could > invent a new "status" field that is not "on" or "off" ("auto", maybe, or > "ifconsole"?). Which brings us to: I'd guess that this mode is really a once-off thing - for a live CD, init could ask the user if they want a getty spawned on this tty similar to asking for a shell in single-user mode. Presumably post-install the user would have edited the ttys file and init would then be able to locate the entry and not have to prompt. later, Peter. From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 20:44:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AB4B9450; Mon, 11 Nov 2013 20:44:41 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6EE5125E2; Mon, 11 Nov 2013 20:44:41 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa01.fnfis.com (8.14.5/8.14.5) with ESMTP id rABKickN032145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Nov 2013 14:44:40 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.152]) by LTCFISWMSGHT06.FNFIS.com ([10.132.206.17]) with mapi id 14.03.0158.001; Mon, 11 Nov 2013 14:44:16 -0600 From: "Teske, Devin" To: Nathan Whitehorn Subject: Re: [CFT] bsdinstall and zfsboot enhancements Thread-Topic: [CFT] bsdinstall and zfsboot enhancements Thread-Index: AQHO1/VTfN3AabWEO0qqCcwz4iQiNg== Date: Mon, 11 Nov 2013 20:44:15 +0000 Message-ID: References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> <5281340E.8080009@callfortesting.org> <52813E53.20403@freebsd.org> In-Reply-To: <52813E53.20403@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="us-ascii" Content-ID: <9B18163F37F1CF46B1D1634B73334A3F@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-11-11_03:2013-11-11,2013-11-11,1970-01-01 signatures=0 Cc: "Teske, Devin" , Current Current , "freebsd-arch@freebsd.org" , Devin Teske , Peter Grehan , Michael Dexter X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:44:41 -0000 On Nov 11, 2013, at 12:30 PM, Nathan Whitehorn wrote: > On 11/11/13 14:18, Teske, Devin wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >>=20 >>=20 >> On Nov 11, 2013, at 11:46 AM, Michael Dexter wrote: >>=20 >>=20 >> Hello all, >>=20 >> I have been experimenting with various BSD and GNU/Linux boot media >> under bhyve and noticed that we may want to accommodate the "LiveCD" >> mode of the installer, which in turn requires the correct console. >>=20 >> Currently, one is prompted for VT100 for installation but this does not >> appear to work/stick for LiveCD mode. >>=20 >> Can anyone verify this? >>=20 >>=20 >> While I developed this patch... >> https://urldefense.proofpoint.com/v1/url?u=3Dhttp://druidbsd.cvs.sf.net/= viewvc/druidbsd/bsdinstall_zfs/usr.sbin%253A%253Absdinstall%253A%253Ascript= s%253A%253Aconfig.patch?revision%3D1.10%26view%3Dmarkup&k=3D%2FbkpAUdJWZuiT= ILCq%2FFnQg%3D%3D%0A&r=3DLTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0= A&m=3DCRY%2BFNOe6Q01s5oKeCFeGOhE0bW%2BvEmw6GTjyy5eHFo%3D%0A&s=3D3e5345ea6b1= 3f84e719068bb993b66978f1971b648b430edfde9165677c279de >>=20 >> Reasons exist to search for a better solution, see here: >> https://urldefense.proofpoint.com/v1/url?u=3Dhttp://lists.freebsd.org/pi= permail/freebsd-current/2013-November/046148.html&k=3D%2FbkpAUdJWZuiTILCq%2= FFnQg%3D%3D%0A&r=3DLTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=3D= CRY%2BFNOe6Q01s5oKeCFeGOhE0bW%2BvEmw6GTjyy5eHFo%3D%0A&s=3D9ebff0354adb26340= 06e52cb4c0048287b7518bd7f4defe420ce5f34675ce5cd >> (and messages that follow it) >>=20 >> Is modifying init(8) still the way to go? What modification do we want t= o make? >> I'll do the work if we can come to consensus. >>=20 >> Or should we touch up the patch in some way to address the original conc= erns? >>=20 >=20 > I think modifying init is the way to go -- it keeps the install system fr= om interfering with the installed one, as well as fixing this kind of issue= with moved hard drives or PXE booting or what have you. If we can provide = a guarantee that any system that displays text has a working console (unles= s explicitly configured not to), useability is improved. >=20 > I would propose one of the following (and volunteer to write the code): >=20 > Option A > ------------ >=20 > 1. init checks if there is an entry in /etc/ttys for the terminal[s] corr= esponding to the value[s] in kern.console Is kern.console set by bhyve while NULL or unset when booting from a physical PC (bare metal)? > 2. If an entry for each console terminal exists in /etc/ttys, enable it > 3. If not, invent one with a terminal type of "ansi" >=20 > The one issue here is that someone may want to force a particular entry t= o off and still have it be the kernel console. This is tricky. We could inv= ent a new "status" field that is not "on" or "off" ("auto", maybe, or "ifco= nsole"?). Which brings us to: >=20 Trying to think of an edge-case where they would want to force it to off. If the kern.console setting is only expected to be set via ... help me out = here... + bhyve ? + pxe ? + what else ? Then maybe the secret sauce shouldn't be in /etc/ttys, but in the value that is passed in via kern.console (that is, ... of the above ruminated technolo= gies which allow you to customize the value?) > Option B > ----------- >=20 > Very similar to Option A, except only provide an automatic console using = (2) and (3) if the "console" terminal is marked "on". This would increase t= he magic attached to "console" in /etc/ttys, but fix the problem with (A). >=20 > It's possible another approach would work as well. Does anyone have thoug= hts on this? If I'm not wrong, there's a third Option C that skirts the issue by bolster= ing the ability to change things for different needs. That prior change that I had made to bsdinstall/scripts/config (iirc) was a= big agressive because it tried to automatically figure things out. If we simply made it a choice (a scriptable one), then that would solve the= problem for the installation. But for the LiveCD issue (Michael wants to bring up the installer's LiveCD = via serial), then perhaps we could solve it by using unionfs in the installer to make th= e install environment writable (and again, change on-the-fly for different needs). Just a thought. Tell me if it's not an option ;D I won't mind. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 20:44:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C4FE75F9; Mon, 11 Nov 2013 20:44:52 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) by mx1.freebsd.org (Postfix) with ESMTP id 8309C25EF; Mon, 11 Nov 2013 20:44:52 +0000 (UTC) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by alto.onthenet.com.au (Postfix) with ESMTPS id D0B4411E42; Tue, 12 Nov 2013 06:44:51 +1000 (EST) Received: from Peter-Grehans-MacBook-Pro-2.local ([64.245.0.210]) by dommail.onthenet.com.au (MOS 4.2.4-GA) with ESMTP id BPY31877 (AUTH peterg@ptree32.com.au); Tue, 12 Nov 2013 06:44:50 +1000 Message-ID: <528141C1.7080409@freebsd.org> Date: Mon, 11 Nov 2013 12:44:49 -0800 From: Peter Grehan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Devin Teske , Nathan Whitehorn Subject: Re: [CFT] bsdinstall and zfsboot enhancements References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> <5281340E.8080009@callfortesting.org> <52813F9E.8080304@freebsd.org> <4E00C3CC-75EA-4249-8D9F-42F37988F4CE@fisglobal.com> In-Reply-To: <4E00C3CC-75EA-4249-8D9F-42F37988F4CE@fisglobal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Current Current , "Teske, Devin" , Michael Dexter X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:44:52 -0000 Hi Devin, > Question: > Does bhyve set kern.console irrespective of loader.conf values? The kernel sets it based on what it determines the console to be. Bhyve influences that by requesting a serial console. This is no different than booting on a headless machine with a serial console. later, Peter. From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 20:48:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DA2A2A0E; Mon, 11 Nov 2013 20:48:24 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id 8E56C2625; Mon, 11 Nov 2013 20:48:24 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 0B80E58391; Mon, 11 Nov 2013 14:48:24 -0600 (CST) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id QtRblLhhATOM; Mon, 11 Nov 2013 14:48:23 -0600 (CST) Received: from terminus.icecube.wisc.edu (terminus.icecube.wisc.edu [172.16.223.97]) by mail.icecube.wisc.edu (Postfix) with ESMTP id D49B65838F; Mon, 11 Nov 2013 14:48:23 -0600 (CST) Message-ID: <52814297.8050209@freebsd.org> Date: Mon, 11 Nov 2013 14:48:23 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Devin Teske Subject: Re: [CFT] bsdinstall and zfsboot enhancements References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> <5281340E.8080009@callfortesting.org> <52813E53.20403@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-arch@freebsd.org" , Current Current , "Teske, Devin" , Peter Grehan , Michael Dexter X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:48:24 -0000 On 11/11/13 14:44, Teske, Devin wrote: > On Nov 11, 2013, at 12:30 PM, Nathan Whitehorn wrote: > >> On 11/11/13 14:18, Teske, Devin wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA512 >>> >>> >>> On Nov 11, 2013, at 11:46 AM, Michael Dexter wrote: >>> >>> >>> Hello all, >>> >>> I have been experimenting with various BSD and GNU/Linux boot media >>> under bhyve and noticed that we may want to accommodate the "LiveCD" >>> mode of the installer, which in turn requires the correct console. >>> >>> Currently, one is prompted for VT100 for installation but this does not >>> appear to work/stick for LiveCD mode. >>> >>> Can anyone verify this? >>> >>> >>> While I developed this patch... >>> https://urldefense.proofpoint.com/v1/url?u=http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/usr.sbin%253A%253Absdinstall%253A%253Ascripts%253A%253Aconfig.patch?revision%3D1.10%26view%3Dmarkup&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=CRY%2BFNOe6Q01s5oKeCFeGOhE0bW%2BvEmw6GTjyy5eHFo%3D%0A&s=3e5345ea6b13f84e719068bb993b66978f1971b648b430edfde9165677c279de >>> >>> Reasons exist to search for a better solution, see here: >>> https://urldefense.proofpoint.com/v1/url?u=http://lists.freebsd.org/pipermail/freebsd-current/2013-November/046148.html&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=CRY%2BFNOe6Q01s5oKeCFeGOhE0bW%2BvEmw6GTjyy5eHFo%3D%0A&s=9ebff0354adb2634006e52cb4c0048287b7518bd7f4defe420ce5f34675ce5cd >>> (and messages that follow it) >>> >>> Is modifying init(8) still the way to go? What modification do we want to make? >>> I'll do the work if we can come to consensus. >>> >>> Or should we touch up the patch in some way to address the original concerns? >>> >> I think modifying init is the way to go -- it keeps the install system from interfering with the installed one, as well as fixing this kind of issue with moved hard drives or PXE booting or what have you. If we can provide a guarantee that any system that displays text has a working console (unless explicitly configured not to), useability is improved. >> >> I would propose one of the following (and volunteer to write the code): >> >> Option A >> ------------ >> >> 1. init checks if there is an entry in /etc/ttys for the terminal[s] corresponding to the value[s] in kern.console > Is kern.console set by bhyve while NULL or unset when booting from > a physical PC (bare metal)? It's set by the kernel console probe sequence and so is portable. If you see boot messages, then it worked. > >> 2. If an entry for each console terminal exists in /etc/ttys, enable it >> 3. If not, invent one with a terminal type of "ansi" >> >> The one issue here is that someone may want to force a particular entry to off and still have it be the kernel console. This is tricky. We could invent a new "status" field that is not "on" or "off" ("auto", maybe, or "ifconsole"?). Which brings us to: >> > Trying to think of an edge-case where they would want to force it to off. > If the kern.console setting is only expected to be set via ... help me out here... > > + bhyve ? > + pxe ? > + what else ? > > Then maybe the secret sauce shouldn't be in /etc/ttys, but in the value that > is passed in via kern.console (that is, ... of the above ruminated technologies > which allow you to customize the value?) kern.console is a read-only variable (it's a struct, actually) set by the kernel. It reflects the state of the kernel console mechanism. The reason you might want to turn it off is if you want to use a machine that boots over serial temporarily as a console for another one (e.g. if a serial-only machine happens to be the only device you have with a serial port at that particular moment). It's an unusual case, but I've done it. > >> Option B >> ----------- >> >> Very similar to Option A, except only provide an automatic console using (2) and (3) if the "console" terminal is marked "on". This would increase the magic attached to "console" in /etc/ttys, but fix the problem with (A). >> >> It's possible another approach would work as well. Does anyone have thoughts on this? > If I'm not wrong, there's a third Option C that skirts the issue by bolstering the ability > to change things for different needs. > > That prior change that I had made to bsdinstall/scripts/config (iirc) was a big agressive > because it tried to automatically figure things out. > > If we simply made it a choice (a scriptable one), then that would solve the problem for > the installation. > > But for the LiveCD issue (Michael wants to bring up the installer's LiveCD via serial), > then perhaps we could solve it by using unionfs in the installer to make the install > environment writable (and again, change on-the-fly for different needs). > > Just a thought. Tell me if it's not an option ;D I won't mind. I'd really prefer not to have unionfs. To begin with, our unionfs mostly doesn't work, but my major objection is that it makes the install CDs magical. It's hard to replicate that in the analogous situation where you have moved a disk to a new machine or are PXE booting. -Nathan From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 20:52:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BF0F3D4B; Mon, 11 Nov 2013 20:52:28 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 825722687; Mon, 11 Nov 2013 20:52:28 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa05.fnfis.com (8.14.5/8.14.5) with ESMTP id rABKqNA9015804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Nov 2013 14:52:25 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.152]) by LTCFISWMSGHT06.FNFIS.com ([10.132.206.17]) with mapi id 14.03.0158.001; Mon, 11 Nov 2013 14:52:23 -0600 From: "Teske, Devin" To: Peter Grehan Subject: Re: [CFT] bsdinstall and zfsboot enhancements Thread-Topic: [CFT] bsdinstall and zfsboot enhancements Thread-Index: AQHO1/VTfN3AabWEO0qqCcwz4iQiNg== Date: Mon, 11 Nov 2013 20:52:22 +0000 Message-ID: <29ADA509-0BB7-435C-8AC1-1D5BC32D6DC8@fisglobal.com> References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> <5281340E.8080009@callfortesting.org> <52813F9E.8080304@freebsd.org> <4E00C3CC-75EA-4249-8D9F-42F37988F4CE@fisglobal.com> <528141C1.7080409@freebsd.org> In-Reply-To: <528141C1.7080409@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <10D0408AE3A87841BF93C152BADC74E3@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-11-11_03:2013-11-11,2013-11-11,1970-01-01 signatures=0 Cc: Michael Dexter , Devin Teske , "Teske, Devin" , Current Current , Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:52:28 -0000 On Nov 11, 2013, at 12:44 PM, Peter Grehan wrote: > Hi Devin, >=20 >> Question: >> Does bhyve set kern.console irrespective of loader.conf values? >=20 > The kernel sets it based on what it determines the console to be. Bhyve i= nfluences that by requesting a serial console. This is no different than bo= oting on a headless machine with a serial console. >=20 Well, for a headless meachine, I would set console=3Dcomconsole,vidconsole in loader.conf(5), then our Forth code slurps it in via loader.4th + suppor= t.4th routines... When boot is executed, I know I can see "kenv console", but hadn't realized that there were/are a host of others that are slurped into the kernel for l= ater (very purposeful) fetching. So when you say that bhyve requests a serial console... I assume now it's setting variables... but via raw Forth? C code? loader.conf(5)? I've seen my menu come up under bhyve, and I noticed that it only has a 5-second count- down instead of the usual 9 -- but I'm curious how you're exporting the var= iables. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 20:54:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EBBC4E8E; Mon, 11 Nov 2013 20:54:55 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id A0B9126AB; Mon, 11 Nov 2013 20:54:55 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 2669858392; Mon, 11 Nov 2013 14:54:55 -0600 (CST) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id 1lmZIlXGkq+0; Mon, 11 Nov 2013 14:54:55 -0600 (CST) Received: from terminus.icecube.wisc.edu (terminus.icecube.wisc.edu [172.16.223.97]) by mail.icecube.wisc.edu (Postfix) with ESMTP id E9C2458391; Mon, 11 Nov 2013 14:54:54 -0600 (CST) Message-ID: <5281441E.7060806@freebsd.org> Date: Mon, 11 Nov 2013 14:54:54 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Devin Teske , Michael Dexter , "freebsd-arch@freebsd.org" , "freebsd-current@freebsd.org" , Peter Grehan Subject: Re: [CFT] bsdinstall and zfsboot enhancements References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> <5281340E.8080009@callfortesting.org> <52813E53.20403@freebsd.org> In-Reply-To: <52813E53.20403@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:54:56 -0000 On 11/11/13 14:30, Nathan Whitehorn wrote: > On 11/11/13 14:18, Teske, Devin wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> >> On Nov 11, 2013, at 11:46 AM, Michael Dexter wrote: >> >> >> Hello all, >> >> I have been experimenting with various BSD and GNU/Linux boot media >> under bhyve and noticed that we may want to accommodate the "LiveCD" >> mode of the installer, which in turn requires the correct console. >> >> Currently, one is prompted for VT100 for installation but this does not >> appear to work/stick for LiveCD mode. >> >> Can anyone verify this? >> >> >> While I developed this patch... >> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/usr.sbin%3A%3Absdinstall%3A%3Ascripts%3A%3Aconfig.patch?revision=1.10&view=markup >> >> >> Reasons exist to search for a better solution, see here: >> http://lists.freebsd.org/pipermail/freebsd-current/2013-November/046148.html >> >> (and messages that follow it) >> >> Is modifying init(8) still the way to go? What modification do we >> want to make? >> I'll do the work if we can come to consensus. >> >> Or should we touch up the patch in some way to address the original >> concerns? >> > > I think modifying init is the way to go -- it keeps the install system > from interfering with the installed one, as well as fixing this kind > of issue with moved hard drives or PXE booting or what have you. If we > can provide a guarantee that any system that displays text has a > working console (unless explicitly configured not to), useability is > improved. > > I would propose one of the following (and volunteer to write the code): > > Option A > ------------ > > 1. init checks if there is an entry in /etc/ttys for the terminal[s] > corresponding to the value[s] in kern.console > 2. If an entry for each console terminal exists in /etc/ttys, enable it > 3. If not, invent one with a terminal type of "ansi" > > The one issue here is that someone may want to force a particular > entry to off and still have it be the kernel console. This is tricky. > We could invent a new "status" field that is not "on" or "off" > ("auto", maybe, or "ifconsole"?). Which brings us to: One easy way to accomplish this is just to only implement (1) and (3), then comment out the ttyu0 entry in /etc/ttys on x86 instead of marking it "off". Then the behavior is just that a tty marked "off" stays off, one marked "on" stays on, and one not present spawns login with a terminal type corresponding to "console" (by default "unknown") if it happens to be the console. I will implement this over the next few days and then send patches unless anyone has an objection. -Nathan From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 20:56:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2A1B1E0; Mon, 11 Nov 2013 20:56:45 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id E3C4826C4; Mon, 11 Nov 2013 20:56:44 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 386E55838F; Mon, 11 Nov 2013 14:56:44 -0600 (CST) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id iqpz0i+HFjiT; Mon, 11 Nov 2013 14:56:44 -0600 (CST) Received: from terminus.icecube.wisc.edu (terminus.icecube.wisc.edu [172.16.223.97]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 048D858388; Mon, 11 Nov 2013 14:56:44 -0600 (CST) Message-ID: <5281448B.8010809@freebsd.org> Date: Mon, 11 Nov 2013 14:56:43 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Devin Teske , Peter Grehan Subject: Re: [CFT] bsdinstall and zfsboot enhancements References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> <5281340E.8080009@callfortesting.org> <52813F9E.8080304@freebsd.org> <4E00C3CC-75EA-4249-8D9F-42F37988F4CE@fisglobal.com> <528141C1.7080409@freebsd.org> <29ADA509-0BB7-435C-8AC1-1D5BC32D6DC8@fisglobal.com> In-Reply-To: <29ADA509-0BB7-435C-8AC1-1D5BC32D6DC8@fisglobal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Current Current , "Teske, Devin" , Michael Dexter X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:56:45 -0000 On 11/11/13 14:52, Teske, Devin wrote: > On Nov 11, 2013, at 12:44 PM, Peter Grehan wrote: > >> Hi Devin, >> >>> Question: >>> Does bhyve set kern.console irrespective of loader.conf values? >> The kernel sets it based on what it determines the console to be. Bhyve influences that by requesting a serial console. This is no different than booting on a headless machine with a serial console. >> > Well, for a headless meachine, I would set console=comconsole,vidconsole > in loader.conf(5), then our Forth code slurps it in via loader.4th + support.4th > routines... > > When boot is executed, I know I can see "kenv console", but hadn't realized > that there were/are a host of others that are slurped into the kernel for later > (very purposeful) fetching. > > So when you say that bhyve requests a serial console... I assume now it's > setting variables... but via raw Forth? C code? loader.conf(5)? I've seen my > menu come up under bhyve, and I noticed that it only has a 5-second count- > down instead of the usual 9 -- but I'm curious how you're exporting the variables. I think you've misunderstood. kern.console isn't set by loader. It reflects the state of the kernel, which decides what to do autonomously based on a number of driver and platform-dependent things including, but not limited to, kenv (loader variables, for instance). -Nathan From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 20:57:08 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8B7A91F3; Mon, 11 Nov 2013 20:57:08 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4FF5226D4; Mon, 11 Nov 2013 20:57:08 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa07.fnfis.com (8.14.5/8.14.5) with ESMTP id rABKv6H0026518 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Nov 2013 14:57:07 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.152]) by LTCFISWMSGHT06.FNFIS.com ([10.132.206.17]) with mapi id 14.03.0158.001; Mon, 11 Nov 2013 14:57:05 -0600 From: "Teske, Devin" To: Nathan Whitehorn Subject: Re: [CFT] bsdinstall and zfsboot enhancements Thread-Topic: [CFT] bsdinstall and zfsboot enhancements Thread-Index: AQHO1/VTfN3AabWEO0qqCcwz4iQiNg== Date: Mon, 11 Nov 2013 20:57:04 +0000 Message-ID: References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> <5281340E.8080009@callfortesting.org> <52813E53.20403@freebsd.org> <5281441E.7060806@freebsd.org> In-Reply-To: <5281441E.7060806@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <487C3101B60CC24E98DABF63D8F8D01A@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-11-11_03:2013-11-11,2013-11-11,1970-01-01 signatures=0 Cc: "Teske, Devin" , Current Current , "freebsd-arch@freebsd.org" , Devin Teske , Peter Grehan , Michael Dexter X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:57:08 -0000 On Nov 11, 2013, at 12:54 PM, Nathan Whitehorn wrote: > On 11/11/13 14:30, Nathan Whitehorn wrote: >> On 11/11/13 14:18, Teske, Devin wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA512 >>>=20 >>>=20 >>> On Nov 11, 2013, at 11:46 AM, Michael Dexter wrote: >>>=20 >>>=20 >>> Hello all, >>>=20 >>> I have been experimenting with various BSD and GNU/Linux boot media >>> under bhyve and noticed that we may want to accommodate the "LiveCD" >>> mode of the installer, which in turn requires the correct console. >>>=20 >>> Currently, one is prompted for VT100 for installation but this does not >>> appear to work/stick for LiveCD mode. >>>=20 >>> Can anyone verify this? >>>=20 >>>=20 >>> While I developed this patch... >>> https://urldefense.proofpoint.com/v1/url?u=3Dhttp://druidbsd.cvs.sf.net= /viewvc/druidbsd/bsdinstall_zfs/usr.sbin%253A%253Absdinstall%253A%253Ascrip= ts%253A%253Aconfig.patch?revision%3D1.10%26view%3Dmarkup&k=3D%2FbkpAUdJWZui= TILCq%2FFnQg%3D%3D%0A&r=3DMrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=3DaZg%2Bxwq= LTX6Zcpf3Rc44iPtAQhFrpqoS4FC5B8ykxJQ%3D%0A&s=3D6d54d337ea5472f5713ddbe7788d= 3248c45feefd4b291eab0a976c39e9d40428=20 >>>=20 >>> Reasons exist to search for a better solution, see here: >>> https://urldefense.proofpoint.com/v1/url?u=3Dhttp://lists.freebsd.org/p= ipermail/freebsd-current/2013-November/046148.html&k=3D%2FbkpAUdJWZuiTILCq%= 2FFnQg%3D%3D%0A&r=3DMrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=3DaZg%2BxwqLTX6Zc= pf3Rc44iPtAQhFrpqoS4FC5B8ykxJQ%3D%0A&s=3D5f8128901747346f937ffc4478eadb4bc3= 9059504258dfb9b36f0fb9e7a61b79=20 >>> (and messages that follow it) >>>=20 >>> Is modifying init(8) still the way to go? What modification do we want = to make? >>> I'll do the work if we can come to consensus. >>>=20 >>> Or should we touch up the patch in some way to address the original con= cerns? >>>=20 >>=20 >> I think modifying init is the way to go -- it keeps the install system f= rom interfering with the installed one, as well as fixing this kind of issu= e with moved hard drives or PXE booting or what have you. If we can provide= a guarantee that any system that displays text has a working console (unle= ss explicitly configured not to), useability is improved. >>=20 >> I would propose one of the following (and volunteer to write the code): >>=20 >> Option A >> ------------ >>=20 >> 1. init checks if there is an entry in /etc/ttys for the terminal[s] cor= responding to the value[s] in kern.console >> 2. If an entry for each console terminal exists in /etc/ttys, enable it >> 3. If not, invent one with a terminal type of "ansi" >>=20 >> The one issue here is that someone may want to force a particular entry = to off and still have it be the kernel console. This is tricky. We could in= vent a new "status" field that is not "on" or "off" ("auto", maybe, or "ifc= onsole"?). Which brings us to: >=20 > One easy way to accomplish this is just to only implement (1) and (3), th= en comment out the ttyu0 entry in /etc/ttys on x86 instead of marking it "o= ff". Then the behavior is just that a tty marked "off" stays off, one marke= d "on" stays on, and one not present spawns login with a terminal type corr= esponding to "console" (by default "unknown") if it happens to be the conso= le. I will implement this over the next few days and then send patches unle= ss anyone has an objection. I love it. (smiles) Excellent idea and that's the winner I think. +1 --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 20:59:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 61DDD4EF; Mon, 11 Nov 2013 20:59:12 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) by mx1.freebsd.org (Postfix) with ESMTP id 1E14926F6; Mon, 11 Nov 2013 20:59:11 +0000 (UTC) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by alto.onthenet.com.au (Postfix) with ESMTPS id 7D4EF122E1; Tue, 12 Nov 2013 06:59:10 +1000 (EST) Received: from Peter-Grehans-MacBook-Pro-2.local ([64.245.0.210]) by dommail.onthenet.com.au (MOS 4.2.4-GA) with ESMTP id BPY32184 (AUTH peterg@ptree32.com.au); Tue, 12 Nov 2013 06:59:08 +1000 Message-ID: <5281451A.5000804@freebsd.org> Date: Mon, 11 Nov 2013 12:59:06 -0800 From: Peter Grehan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Devin Teske Subject: Re: [CFT] bsdinstall and zfsboot enhancements References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> <5281340E.8080009@callfortesting.org> <52813F9E.8080304@freebsd.org> <4E00C3CC-75EA-4249-8D9F-42F37988F4CE@fisglobal.com> <528141C1.7080409@freebsd.org> <29ADA509-0BB7-435C-8AC1-1D5BC32D6DC8@fisglobal.com> In-Reply-To: <29ADA509-0BB7-435C-8AC1-1D5BC32D6DC8@fisglobal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Michael Dexter , "Teske, Devin" , Current Current , Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:59:12 -0000 Hi Devin, > When boot is executed, I know I can see "kenv console", but hadn't realized > that there were/are a host of others that are slurped into the kernel for later > (very purposeful) fetching. > > So when you say that bhyve requests a serial console... I assume now it's > setting variables... but via raw Forth? C code? loader.conf(5)? I've seen my > menu come up under bhyve, and I noticed that it only has a 5-second count- > down instead of the usual 9 -- but I'm curious how you're exporting the variables. bhyve uses the loader facility to set env variables directly from loader code. This is no different than other arch ports of the loader that set env variables. The forced setting of boot_serial is just a convenience for users since that is the only supported console type. It doesn't touch the timeout code - should be whatever FreeBSD loader forth scripts tell it to do. later, Peter. From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 20:59:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E0ED2602; Mon, 11 Nov 2013 20:59:44 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A64B22707; Mon, 11 Nov 2013 20:59:44 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa01.fnfis.com (8.14.5/8.14.5) with ESMTP id rABKxhr2018054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Nov 2013 14:59:43 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.152]) by LTCFISWMSGHT05.FNFIS.com ([10.132.206.16]) with mapi id 14.03.0158.001; Mon, 11 Nov 2013 14:59:41 -0600 From: "Teske, Devin" To: Nathan Whitehorn Subject: Re: [CFT] bsdinstall and zfsboot enhancements Thread-Topic: [CFT] bsdinstall and zfsboot enhancements Thread-Index: AQHO1/VTfN3AabWEO0qqCcwz4iQiNg== Date: Mon, 11 Nov 2013 20:59:41 +0000 Message-ID: <0FAF7C99-AF13-45EC-A531-2E04418A01B5@fisglobal.com> References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> <5281340E.8080009@callfortesting.org> <52813F9E.8080304@freebsd.org> <4E00C3CC-75EA-4249-8D9F-42F37988F4CE@fisglobal.com> <528141C1.7080409@freebsd.org> <29ADA509-0BB7-435C-8AC1-1D5BC32D6DC8@fisglobal.com> <5281448B.8010809@freebsd.org> In-Reply-To: <5281448B.8010809@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-11-11_03:2013-11-11,2013-11-11,1970-01-01 signatures=0 Cc: Current Current , Devin Teske , "Teske, Devin" , Peter Grehan , Michael Dexter X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:59:45 -0000 On Nov 11, 2013, at 12:56 PM, Nathan Whitehorn wrote: > On 11/11/13 14:52, Teske, Devin wrote: >> On Nov 11, 2013, at 12:44 PM, Peter Grehan wrote: >>=20 >>> Hi Devin, >>>=20 >>>> Question: >>>> Does bhyve set kern.console irrespective of loader.conf values? >>> The kernel sets it based on what it determines the console to be. Bhyve= influences that by requesting a serial console. This is no different than = booting on a headless machine with a serial console. >>>=20 >> Well, for a headless meachine, I would set console=3Dcomconsole,vidconso= le >> in loader.conf(5), then our Forth code slurps it in via loader.4th + sup= port.4th >> routines... >>=20 >> When boot is executed, I know I can see "kenv console", but hadn't reali= zed >> that there were/are a host of others that are slurped into the kernel fo= r later >> (very purposeful) fetching. >>=20 >> So when you say that bhyve requests a serial console... I assume now it's >> setting variables... but via raw Forth? C code? loader.conf(5)? I've see= n my >> menu come up under bhyve, and I noticed that it only has a 5-second coun= t- >> down instead of the usual 9 -- but I'm curious how you're exporting the = variables. >=20 > I think you've misunderstood. kern.console isn't set by loader. It reflec= ts the state of the kernel, which decides what to do autonomously based on = a number of driver and platform-dependent things including, but not limited= to, kenv (loader variables, for instance). I was thinking it, but didn't express it properly... yes... kern.console is= influenced by loader variables. "slurped" is definitely not the technical explanation I should be striving = for ;D (that is, if I'm trying to be clear). --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 21:01:23 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7BF8F7AA; Mon, 11 Nov 2013 21:01:23 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3FA282757; Mon, 11 Nov 2013 21:01:22 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa02.fnfis.com (8.14.5/8.14.5) with ESMTP id rABL1MEx032592 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Nov 2013 15:01:22 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.152]) by LTCFISWMSGHT04.FNFIS.com ([10.132.206.15]) with mapi id 14.03.0158.001; Mon, 11 Nov 2013 15:01:20 -0600 From: "Teske, Devin" To: Peter Grehan Subject: Re: [CFT] bsdinstall and zfsboot enhancements Thread-Topic: [CFT] bsdinstall and zfsboot enhancements Thread-Index: AQHO1/VTfN3AabWEO0qqCcwz4iQiNg== Date: Mon, 11 Nov 2013 21:01:20 +0000 Message-ID: <06B994A9-8438-434C-A7B3-E7A4A5991031@fisglobal.com> References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> <5281340E.8080009@callfortesting.org> <52813F9E.8080304@freebsd.org> <4E00C3CC-75EA-4249-8D9F-42F37988F4CE@fisglobal.com> <528141C1.7080409@freebsd.org> <29ADA509-0BB7-435C-8AC1-1D5BC32D6DC8@fisglobal.com> <5281451A.5000804@freebsd.org> In-Reply-To: <5281451A.5000804@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-11-11_03:2013-11-11,2013-11-11,1970-01-01 signatures=0 Cc: Michael Dexter , Devin Teske , "Teske, Devin" , Current Current , Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 21:01:23 -0000 On Nov 11, 2013, at 12:59 PM, Peter Grehan wrote: > Hi Devin, >=20 >> When boot is executed, I know I can see "kenv console", but hadn't reali= zed >> that there were/are a host of others that are slurped into the kernel fo= r later >> (very purposeful) fetching. >>=20 >> So when you say that bhyve requests a serial console... I assume now it's >> setting variables... but via raw Forth? C code? loader.conf(5)? I've see= n my >> menu come up under bhyve, and I noticed that it only has a 5-second coun= t- >> down instead of the usual 9 -- but I'm curious how you're exporting the = variables. >=20 > bhyve uses the loader facility to set env variables directly from loader = code. This is no different than other arch ports of the loader that set env= variables. The forced setting of boot_serial is just a convenience for use= rs since that is the only supported console type. >=20 Thank you much for the explanation. I see it from end-to-end now. > It doesn't touch the timeout code - should be whatever FreeBSD loader for= th scripts tell it to do. >=20 Ah, must have been something Michael did. I noticed this whilst getting demos from him on his laptop. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 21:19:30 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 671444F9; Mon, 11 Nov 2013 21:19:30 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 347DD2857; Mon, 11 Nov 2013 21:19:29 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa02.fnfis.com (8.14.5/8.14.5) with ESMTP id rABLJP3d020931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Nov 2013 15:19:25 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.152]) by LTCFISWMSGHT06.FNFIS.com ([10.132.206.17]) with mapi id 14.03.0158.001; Mon, 11 Nov 2013 15:19:24 -0600 From: "Teske, Devin" To: Allan Jude Subject: Default MBR boot "manager" Thread-Topic: Default MBR boot "manager" Thread-Index: AQHO3yOxLX+gV+R89keqYsOt5bsQkg== Date: Mon, 11 Nov 2013 21:19:23 +0000 Message-ID: <33391A36-2E7A-473B-87E0-88BDE1AC97D1@fisglobal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-11-11_03:2013-11-11,2013-11-11,1970-01-01 signatures=0 Cc: Devin Teske , "Teske, Devin" , Current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 21:19:30 -0000 Topic: Lenovo Laptops and bsdinstall zfsboot with MBR layout... Should we do the quick patch to change the default from /boot/boot0 to /boot/mbr: Index: zfsboot =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- zfsboot (revision 258016) +++ zfsboot (working copy) @@ -764,7 +764,7 @@ zfs_create_diskpart() # f_eval_catch $funcname gpart "$GPART_CREATE" mbr \$disk || return $FAILURE - f_eval_catch $funcname gpart "$GPART_BOOTCODE" /boot/boot0 \ + f_eval_catch $funcname gpart "$GPART_BOOTCODE" /boot/mbr \ \$disk || return $FAILURE # That would fix things for Lenovo laptops for the next release until I finish up the bootcode selection menu. I'd like to take my time in making sure Allan and I design a worthy bootcode selection menu. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 21:28:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C6DE17B3 for ; Mon, 11 Nov 2013 21:28:52 +0000 (UTC) (envelope-from freebsd@allanjude.com) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 9D05F28E0 for ; Mon, 11 Nov 2013 21:28:52 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.108.129]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 2D33847528 for ; Mon, 11 Nov 2013 21:28:41 +0000 (UTC) Message-ID: <52814C0E.50902@allanjude.com> Date: Mon, 11 Nov 2013 16:28:46 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: [CFT] bsdinstall and zfsboot enhancements References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> <5281340E.8080009@callfortesting.org> <52813E53.20403@freebsd.org> <5281441E.7060806@freebsd.org> In-Reply-To: <5281441E.7060806@freebsd.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mbVspx2N2mdQMigV4TTEagB2dgVXEGaJk" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 21:28:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mbVspx2N2mdQMigV4TTEagB2dgVXEGaJk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-11-11 15:54, Nathan Whitehorn wrote: > On 11/11/13 14:30, Nathan Whitehorn wrote: >> On 11/11/13 14:18, Teske, Devin wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA512 >>> >>> >>> On Nov 11, 2013, at 11:46 AM, Michael Dexter wrote: >>> >>> >>> Hello all, >>> >>> I have been experimenting with various BSD and GNU/Linux boot media >>> under bhyve and noticed that we may want to accommodate the "LiveCD" >>> mode of the installer, which in turn requires the correct console. >>> >>> Currently, one is prompted for VT100 for installation but this does n= ot >>> appear to work/stick for LiveCD mode. >>> >>> Can anyone verify this? >>> >>> >>> While I developed this patch... >>> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/usr.sbin%3A= %3Absdinstall%3A%3Ascripts%3A%3Aconfig.patch?revision=3D1.10&view=3Dmarku= p >>> >>> >>> Reasons exist to search for a better solution, see here: >>> http://lists.freebsd.org/pipermail/freebsd-current/2013-November/0461= 48.html >>> >>> (and messages that follow it) >>> >>> Is modifying init(8) still the way to go? What modification do we >>> want to make? >>> I'll do the work if we can come to consensus. >>> >>> Or should we touch up the patch in some way to address the original >>> concerns? >>> >> >> I think modifying init is the way to go -- it keeps the install >> system from interfering with the installed one, as well as fixing >> this kind of issue with moved hard drives or PXE booting or what have >> you. If we can provide a guarantee that any system that displays text >> has a working console (unless explicitly configured not to), >> useability is improved. >> >> I would propose one of the following (and volunteer to write the code)= : >> >> Option A >> ------------ >> >> 1. init checks if there is an entry in /etc/ttys for the terminal[s] >> corresponding to the value[s] in kern.console >> 2. If an entry for each console terminal exists in /etc/ttys, enable i= t >> 3. If not, invent one with a terminal type of "ansi" >> >> The one issue here is that someone may want to force a particular >> entry to off and still have it be the kernel console. This is tricky. >> We could invent a new "status" field that is not "on" or "off" >> ("auto", maybe, or "ifconsole"?). Which brings us to: > > One easy way to accomplish this is just to only implement (1) and (3), > then comment out the ttyu0 entry in /etc/ttys on x86 instead of > marking it "off". Then the behavior is just that a tty marked "off" > stays off, one marked "on" stays on, and one not present spawns login > with a terminal type corresponding to "console" (by default "unknown") > if it happens to be the console. I will implement this over the next > few days and then send patches unless anyone has an objection. > -Nathan > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" These seems the best approach to me. The ttyu's are off by default, so changing that to commented out has no effect on anyone, and it allows you to do the right magic in init. Thank you for the offer to write this up, look forward to testing the patches --=20 Allan Jude --mbVspx2N2mdQMigV4TTEagB2dgVXEGaJk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSgUwRAAoJEJrBFpNRJZKffbcP/R7CF2VFHzeWJp88f3iEhSzo qN9G+7vWKMzxznp3QF2jOYAgqavIL6XJ+gkZpWJJ/drUFNIivyi1/Ofzp5mVaFhM 2j54iUhqg/4QA3lBd/oq9jcOrm28Eeo4M3KxUopvsJPKBv/0Wyhq8wv87vI9+SpS CPgvubUZ+JBSoJ94EtYBaLkyFK5zCHImhZcOU2lPnMnfdEMVWMy8sNz5QT57ZFcK J7+FTq06QZ2DKCEGe2LFFEYFrY9WSBaMAmra03zzQcaeoifY5mA3kb5pyZ+/4qM8 tKwtJOJiEJ2yQa50fkwAz2Q2k3wqnM+JUJ5/K3YtZ3vvICgIVvm3xZ4p1zzPfKwa JmkGXipBMSEtFSDQBaS06HugzGuQXHJ6u9CeDhDvIXUxKLBTgeDVh0uo/B5GQhTV nuFRvNmhacZ1OYAvS0zqLmhaH48uc87cxzR8fRIJV1DioTseCBi/QOgivFL0/Gav 0tqsCfETMnVVzH84gDv/DQe4ienBXc0+YnDa7BVwu+xLZ4DPMQZ5fnfwT4jCa7EV GNVMZi6ZHECsaMoD7j2LI6XFXdr7BiNGJmYDKtRp4arPBCgsBxyPl5XNY+AQxLJf YmKMbkCyoXjteR2rCSJi8SamDB34AjkoF+pdYsrzybnwHbb28TZAli/ZGQKONZoz YFZiOe7QLqiHCo1ge+a8 =rI7d -----END PGP SIGNATURE----- --mbVspx2N2mdQMigV4TTEagB2dgVXEGaJk-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 21:30:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 808FF94E; Mon, 11 Nov 2013 21:30:41 +0000 (UTC) (envelope-from freebsd@allanjude.com) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 59D2F2931; Mon, 11 Nov 2013 21:30:40 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.108.129]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id EA0DE4756D; Mon, 11 Nov 2013 21:30:39 +0000 (UTC) Message-ID: <52814C88.6080309@allanjude.com> Date: Mon, 11 Nov 2013 16:30:48 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Devin Teske Subject: Re: Default MBR boot "manager" References: <33391A36-2E7A-473B-87E0-88BDE1AC97D1@fisglobal.com> In-Reply-To: <33391A36-2E7A-473B-87E0-88BDE1AC97D1@fisglobal.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LBn4uebB9lmh85MOukjfNS1A2UUR1ShHQ" Cc: Current Current , "Teske, Devin" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 21:30:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LBn4uebB9lmh85MOukjfNS1A2UUR1ShHQ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-11-11 16:19, Teske, Devin wrote: > Topic: Lenovo Laptops and bsdinstall zfsboot with MBR layout... > > Should we do the quick patch to change the default > from /boot/boot0 to /boot/mbr: > > Index: zfsboot > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- zfsboot (revision 258016) > +++ zfsboot (working copy) > @@ -764,7 +764,7 @@ zfs_create_diskpart() > # > f_eval_catch $funcname gpart "$GPART_CREATE" mbr \$disk= || > return $FAILURE > - f_eval_catch $funcname gpart "$GPART_BOOTCODE" /boot/bo= ot0 \ > + f_eval_catch $funcname gpart "$GPART_BOOTCODE" /boot/mb= r \ > \$disk || return $FAILURE > > # > > That would fix things for Lenovo laptops for the next > release until I finish up the bootcode selection menu. > I'd like to take my time in making sure Allan and I design > a worthy bootcode selection menu. These seems like the best approach for now, based on the feedback I have gotten from people with BIOSs that won't boot GPT and often choke on the boot0 boot manager. --=20 Allan Jude --LBn4uebB9lmh85MOukjfNS1A2UUR1ShHQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSgUyIAAoJEJrBFpNRJZKfcKsP/1+49SZ04VIsLg2WZ4cmRnBE vGPdpjmodOBusCf7Zuow2yYz2dHnsh/LvBwWW9LzPREH82OLLcE1ASWEHJ0p9+JN RPDfg+pI+ZEDRuyeX946AywLJVkPUIbZryytY4k2Jo8wo3aaWqIRhEe9eLhx21Ds bBhYPIyHt4U8tYGJ00l9EVPEYfCjn5I4MGjHHm0/XgVan5+w3PcBuF1w/42NfXhv 0Yq9J97hxkOK4iY2I71K/dBk0jZk69J4ziGttw4htRAt+KysOVOEpMXj+YBKpadi Afja56bFaGbtcJXVKy4RutkhjgsGygqCrxQT0855KUybdfXlXHLa1vetIVFKE2Cn uKhv24D8G3dlZY2rq5kqeKWUGbbO5vRUC0sSBmpCIGF2Zeiidsfn25gaM7+bXq30 qTiGXl8ctkQ0XeKVyxuUs4Ig296UhSwG0LA812bX/SsgS/zUfK6nvDn9VMMjVuT8 uDGf0uoEb6/2DViJG7yJbE3EniUxt7TldU0k1T8ejV4NdqWWoGbww3TBF5zbbuaJ zdsHBbm8zl8yHxxusni79Y5ShB6cT0d+Ls0PyCFRKIikO28allBuJsPOMSbxibw+ fd7mVOFYeLi1VFCBoKFmC5tBJTFAam4sx1NkjNTYvMOtzqCNFOYkiVVRtX2fyOgy 2QfsbbYL6URh5+vaUg7s =Cjce -----END PGP SIGNATURE----- --LBn4uebB9lmh85MOukjfNS1A2UUR1ShHQ-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 21:32:09 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F05C2A64 for ; Mon, 11 Nov 2013 21:32:09 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id AC4A02948 for ; Mon, 11 Nov 2013 21:32:09 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id AD9AA58388 for ; Mon, 11 Nov 2013 15:32:08 -0600 (CST) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id CQGv-Jd7plvO for ; Mon, 11 Nov 2013 15:32:08 -0600 (CST) Received: from terminus.icecube.wisc.edu (terminus.icecube.wisc.edu [172.16.223.97]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 746A658385 for ; Mon, 11 Nov 2013 15:32:08 -0600 (CST) Message-ID: <52814CD8.5020708@freebsd.org> Date: Mon, 11 Nov 2013 15:32:08 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Default MBR boot "manager" References: <33391A36-2E7A-473B-87E0-88BDE1AC97D1@fisglobal.com> In-Reply-To: <33391A36-2E7A-473B-87E0-88BDE1AC97D1@fisglobal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 21:32:10 -0000 On 11/11/13 15:19, Teske, Devin wrote: > Topic: Lenovo Laptops and bsdinstall zfsboot with MBR layout... > > Should we do the quick patch to change the default > from /boot/boot0 to /boot/mbr: > > Index: zfsboot > =================================================================== > --- zfsboot (revision 258016) > +++ zfsboot (working copy) > @@ -764,7 +764,7 @@ zfs_create_diskpart() > # > f_eval_catch $funcname gpart "$GPART_CREATE" mbr \$disk || > return $FAILURE > - f_eval_catch $funcname gpart "$GPART_BOOTCODE" /boot/boot0 \ > + f_eval_catch $funcname gpart "$GPART_BOOTCODE" /boot/mbr \ > \$disk || return $FAILURE > > # > > That would fix things for Lenovo laptops for the next > release until I finish up the bootcode selection menu. > I'd like to take my time in making sure Allan and I design > a worthy bootcode selection menu. This patch looks good (I don't remember why it was boot0 in the first place). I think gpart automatically installs something like /boot/mbr by default, so I'd be interested to know if making the diff purely negative still works. On another note, I think we should move away from a selector. Right now, we have three kinds of boot code: 1. ZFS boot code 2. UFS boot code 3. boot0 Unifying 1 and 2 would help a lot -- I don't know of any reason we need both except for tradition. #3 is probably best done as a post-install config step ("Install FreeBSD boot manager" or something), which also means it works for UFS systems. -Nathan From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 21:35:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 55A5EBD8 for ; Mon, 11 Nov 2013 21:35:15 +0000 (UTC) (envelope-from freebsd@allanjude.com) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 116F7296B for ; Mon, 11 Nov 2013 21:35:14 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.108.129]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 11B3D4758E for ; Mon, 11 Nov 2013 21:35:12 +0000 (UTC) Message-ID: <52814D98.9050404@allanjude.com> Date: Mon, 11 Nov 2013 16:35:20 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Default MBR boot "manager" References: <33391A36-2E7A-473B-87E0-88BDE1AC97D1@fisglobal.com> <52814CD8.5020708@freebsd.org> In-Reply-To: <52814CD8.5020708@freebsd.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Jx8jksmRvPacXCT5FFoc5PP9eWtutpilG" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 21:35:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Jx8jksmRvPacXCT5FFoc5PP9eWtutpilG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-11-11 16:32, Nathan Whitehorn wrote: > On 11/11/13 15:19, Teske, Devin wrote: >> Topic: Lenovo Laptops and bsdinstall zfsboot with MBR layout... >> >> Should we do the quick patch to change the default >> from /boot/boot0 to /boot/mbr: >> >> Index: zfsboot >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- zfsboot (revision 258016) >> +++ zfsboot (working copy) >> @@ -764,7 +764,7 @@ zfs_create_diskpart() >> # >> f_eval_catch $funcname gpart "$GPART_CREATE" mbr >> \$disk || >> return $FAILURE >> - f_eval_catch $funcname gpart "$GPART_BOOTCODE" >> /boot/boot0 \ >> + f_eval_catch $funcname gpart "$GPART_BOOTCODE" >> /boot/mbr \ >> \$disk || return $FAILURE >> >> # >> >> That would fix things for Lenovo laptops for the next >> release until I finish up the bootcode selection menu. >> I'd like to take my time in making sure Allan and I design >> a worthy bootcode selection menu. > > This patch looks good (I don't remember why it was boot0 in the first > place). I think gpart automatically installs something like /boot/mbr > by default, so I'd be interested to know if making the diff purely > negative still works. > > On another note, I think we should move away from a selector. Right > now, we have three kinds of boot code: > 1. ZFS boot code > 2. UFS boot code > 3. boot0 > > Unifying 1 and 2 would help a lot -- I don't know of any reason we > need both except for tradition. #3 is probably best done as a > post-install config step ("Install FreeBSD boot manager" or > something), which also means it works for UFS systems. > -Nathan > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" You have to do down right evil things to boot ZFS on MBR. dd'ing the 'remainder' of the boot loader into a reserved space at the head of the ZFS partition. The GPT boot code is 14k, and the code to boot ZFS is 40k, whereas the UFS stuff is 512 bytes and fits in the intended slot. --=20 Allan Jude --Jx8jksmRvPacXCT5FFoc5PP9eWtutpilG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSgU2ZAAoJEJrBFpNRJZKfiT8QAJNCIP3lTczwVLVJ7kzUNma5 lIDYdN1AcVwr/t+gYDQ2RvCHlj8PTpOxF3eFYsm4k9MGyhLqewLnHVhmNdKvdB2X BSKaoeXnpTEkB0iixeUPvqrTz0WtmA17z99V1zxtrDWRy915jeZWR+3XY/nMqsXX 5H7u98KGL+7DPQQAfXls84pycN4Zvc/diWtysv8bPYe6eFX/Kjj7MPkd82aZqIAA 5Q+BpvzI055V9WnbAQxYMXt9gSJi1rVDfaWZJCBPnq3jwaV6PhCuxMplzCCtpPy9 pyj/D1pyJiyA723JmKRzrR9wBFEUJi9NglBhU44VCfeMzIoytpz0JZ9gsUB589VB /cQOly0twNOuaPPZO4bmWhfPTCzobKiQzXfXRDQQmTOsepTXOoth9slpEOwWn4a/ gOo3R77jLaJ5jEDgXM++6fyA1aFw+KajYGMPDkUohWD6HkdyzDzYGBBa1ZB5v1nV kwqRbZkP3yA/qXfI8fOASrQtySxl0jSeAEEH755TnmmrMcAjCVth9/Q+R3wVQDYm 4VAOPNboJ0DVWd/cUZxQeoAPDbIxOVncOKSsVP0RhnSLXRsDMrDjJhVAt+mK8duL y70IF8Wp3sGo+n1iECkzNSdIcfVW9xbPhxJFV+HwgCdKGVg1Momj+1ktJ0+naSz4 ZkY/c0j5MxPy67yd1p4Z =iQ+L -----END PGP SIGNATURE----- --Jx8jksmRvPacXCT5FFoc5PP9eWtutpilG-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 21:36:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0D7C2D41 for ; Mon, 11 Nov 2013 21:36:32 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id D332D2985 for ; Mon, 11 Nov 2013 21:36:31 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 0529358389 for ; Mon, 11 Nov 2013 15:36:31 -0600 (CST) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id ZekJK4v13kSu for ; Mon, 11 Nov 2013 15:36:30 -0600 (CST) Received: from terminus.icecube.wisc.edu (terminus.icecube.wisc.edu [172.16.223.97]) by mail.icecube.wisc.edu (Postfix) with ESMTP id D58D758388 for ; Mon, 11 Nov 2013 15:36:30 -0600 (CST) Message-ID: <52814DDE.6040109@freebsd.org> Date: Mon, 11 Nov 2013 15:36:30 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Default MBR boot "manager" References: <33391A36-2E7A-473B-87E0-88BDE1AC97D1@fisglobal.com> <52814CD8.5020708@freebsd.org> <52814D98.9050404@allanjude.com> In-Reply-To: <52814D98.9050404@allanjude.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 21:36:32 -0000 On 11/11/13 15:35, Allan Jude wrote: > On 2013-11-11 16:32, Nathan Whitehorn wrote: >> On 11/11/13 15:19, Teske, Devin wrote: >>> Topic: Lenovo Laptops and bsdinstall zfsboot with MBR layout... >>> >>> Should we do the quick patch to change the default >>> from /boot/boot0 to /boot/mbr: >>> >>> Index: zfsboot >>> =================================================================== >>> --- zfsboot (revision 258016) >>> +++ zfsboot (working copy) >>> @@ -764,7 +764,7 @@ zfs_create_diskpart() >>> # >>> f_eval_catch $funcname gpart "$GPART_CREATE" mbr >>> \$disk || >>> return $FAILURE >>> - f_eval_catch $funcname gpart "$GPART_BOOTCODE" >>> /boot/boot0 \ >>> + f_eval_catch $funcname gpart "$GPART_BOOTCODE" >>> /boot/mbr \ >>> \$disk || return $FAILURE >>> >>> # >>> >>> That would fix things for Lenovo laptops for the next >>> release until I finish up the bootcode selection menu. >>> I'd like to take my time in making sure Allan and I design >>> a worthy bootcode selection menu. >> This patch looks good (I don't remember why it was boot0 in the first >> place). I think gpart automatically installs something like /boot/mbr >> by default, so I'd be interested to know if making the diff purely >> negative still works. >> >> On another note, I think we should move away from a selector. Right >> now, we have three kinds of boot code: >> 1. ZFS boot code >> 2. UFS boot code >> 3. boot0 >> >> Unifying 1 and 2 would help a lot -- I don't know of any reason we >> need both except for tradition. #3 is probably best done as a >> post-install config step ("Install FreeBSD boot manager" or >> something), which also means it works for UFS systems. >> -Nathan >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" > You have to do down right evil things to boot ZFS on MBR. dd'ing the > 'remainder' of the boot loader into a reserved space at the head of the > ZFS partition. The GPT boot code is 14k, and the code to boot ZFS is > 40k, whereas the UFS stuff is 512 bytes and fits in the intended slot. > We could just decide we won't support booting from ZFS on MBR. For GPT, there is no size limit, which simplifies everything. -Nathan From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 21:39:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 521E7E6C; Mon, 11 Nov 2013 21:39:17 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1D47D29A0; Mon, 11 Nov 2013 21:39:16 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa01.fnfis.com (8.14.5/8.14.5) with ESMTP id rABLdFae000320 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Nov 2013 15:39:16 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.152]) by LTCFISWMSGHT05.FNFIS.com ([10.132.206.16]) with mapi id 14.03.0158.001; Mon, 11 Nov 2013 15:39:14 -0600 From: "Teske, Devin" To: Nathan Whitehorn Subject: Re: Default MBR boot "manager" Thread-Topic: Default MBR boot "manager" Thread-Index: AQHO3yOxLX+gV+R89keqYsOt5bsQkg== Date: Mon, 11 Nov 2013 21:39:14 +0000 Message-ID: <236424BC-EC62-4FDC-B9F6-E08653FF2F4B@fisglobal.com> References: <33391A36-2E7A-473B-87E0-88BDE1AC97D1@fisglobal.com> <52814CD8.5020708@freebsd.org> In-Reply-To: <52814CD8.5020708@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="us-ascii" Content-ID: <54930C9078F2D54DAE2981AFE513C883@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-11-11_04:2013-11-11,2013-11-11,1970-01-01 signatures=0 Cc: Devin Teske , Current Current , "Teske, Devin" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 21:39:17 -0000 On Nov 11, 2013, at 1:32 PM, Nathan Whitehorn wrote: > On 11/11/13 15:19, Teske, Devin wrote: >> Topic: Lenovo Laptops and bsdinstall zfsboot with MBR layout... >>=20 >> Should we do the quick patch to change the default >> from /boot/boot0 to /boot/mbr: >>=20 >> Index: zfsboot >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- zfsboot (revision 258016) >> +++ zfsboot (working copy) >> @@ -764,7 +764,7 @@ zfs_create_diskpart() >> # >> f_eval_catch $funcname gpart "$GPART_CREATE" mbr \$disk = || >> return $FAILURE >> - f_eval_catch $funcname gpart "$GPART_BOOTCODE" /boot/boo= t0 \ >> + f_eval_catch $funcname gpart "$GPART_BOOTCODE" /boot/mbr= \ >> \$disk || return $FAILURE >>=20 >> # >>=20 >> That would fix things for Lenovo laptops for the next >> release until I finish up the bootcode selection menu. >> I'd like to take my time in making sure Allan and I design >> a worthy bootcode selection menu. >=20 > This patch looks good (I don't remember why it was boot0 in the first pla= ce). I think gpart automatically installs something like /boot/mbr by defau= lt, so I'd be interested to know if making the diff purely negative still w= orks. >=20 > On another note, I think we should move away from a selector. Right now, = we have three kinds of boot code: > 1. ZFS boot code > 2. UFS boot code > 3. boot0 >=20 > Unifying 1 and 2 would help a lot -- I don't know of any reason we need b= oth except for tradition. #3 is probably best done as a post-install config= step ("Install FreeBSD boot manager" or something), which also means it wo= rks for UFS systems. Well, I'm sensitive to the fact that sysinstall offered "none" and even explained why in an F1 dialog that brought up "drives.hlp" to explain that you might want to keep whatever (alternate) boot manager you may be using already. In a proposed selector, the full breadth of options that I was envisioning was: GPT + gptboot GPT + none (use your existing boot manager... syslinux?) MBR + mbr MBR + boot0 MBR + none (again, BYOBM) Hadn't got around to zfsboot yet. Where would that go? at the top? GPT + zfsboot ? (and of course, this is x86 specific... I was gleaning from sysinstall that for systems like pc98, they call it an IPL and there's only two options... a standard IPL or bring your own boot manager, aka "none"). I imagine that there would be architectures that are like the ol' pc98, wherein they don't have all these options (is, for example? sparc64 GPT only?) --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 21:39:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B8409F6A for ; Mon, 11 Nov 2013 21:39:21 +0000 (UTC) (envelope-from freebsd@allanjude.com) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 915B429A3 for ; Mon, 11 Nov 2013 21:39:21 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.108.129]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id ABD4F475A4 for ; Mon, 11 Nov 2013 21:39:20 +0000 (UTC) Message-ID: <52814E8F.5050608@allanjude.com> Date: Mon, 11 Nov 2013 16:39:27 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Default MBR boot "manager" References: <33391A36-2E7A-473B-87E0-88BDE1AC97D1@fisglobal.com> <52814CD8.5020708@freebsd.org> <52814D98.9050404@allanjude.com> <52814DDE.6040109@freebsd.org> In-Reply-To: <52814DDE.6040109@freebsd.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="O1qHI4a8e0trmn8ujkII0wGqte6ob75ta" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 21:39:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --O1qHI4a8e0trmn8ujkII0wGqte6ob75ta Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-11-11 16:36, Nathan Whitehorn wrote: > On 11/11/13 15:35, Allan Jude wrote: >> On 2013-11-11 16:32, Nathan Whitehorn wrote: >>> On 11/11/13 15:19, Teske, Devin wrote: >>>> Topic: Lenovo Laptops and bsdinstall zfsboot with MBR layout... >>>> >>>> Should we do the quick patch to change the default >>>> from /boot/boot0 to /boot/mbr: >>>> >>>> Index: zfsboot >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> --- zfsboot (revision 258016) >>>> +++ zfsboot (working copy) >>>> @@ -764,7 +764,7 @@ zfs_create_diskpart() >>>> # >>>> f_eval_catch $funcname gpart "$GPART_CREATE" mbr >>>> \$disk || >>>> return $FAILURE >>>> - f_eval_catch $funcname gpart "$GPART_BOOTCODE" >>>> /boot/boot0 \ >>>> + f_eval_catch $funcname gpart "$GPART_BOOTCODE" >>>> /boot/mbr \ >>>> \$disk || return $FAILURE >>>> >>>> # >>>> >>>> That would fix things for Lenovo laptops for the next >>>> release until I finish up the bootcode selection menu. >>>> I'd like to take my time in making sure Allan and I design >>>> a worthy bootcode selection menu. >>> This patch looks good (I don't remember why it was boot0 in the first= >>> place). I think gpart automatically installs something like /boot/mbr= >>> by default, so I'd be interested to know if making the diff purely >>> negative still works. >>> >>> On another note, I think we should move away from a selector. Right >>> now, we have three kinds of boot code: >>> 1. ZFS boot code >>> 2. UFS boot code >>> 3. boot0 >>> >>> Unifying 1 and 2 would help a lot -- I don't know of any reason we >>> need both except for tradition. #3 is probably best done as a >>> post-install config step ("Install FreeBSD boot manager" or >>> something), which also means it works for UFS systems. >>> -Nathan >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to >>> "freebsd-current-unsubscribe@freebsd.org" >> You have to do down right evil things to boot ZFS on MBR. dd'ing the >> 'remainder' of the boot loader into a reserved space at the head of th= e >> ZFS partition. The GPT boot code is 14k, and the code to boot ZFS is >> 40k, whereas the UFS stuff is 512 bytes and fits in the intended slot.= >> > > We could just decide we won't support booting from ZFS on MBR. For > GPT, there is no size limit, which simplifies everything. > -Nathan > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" With GPT you just make a partition to put the boot code in, so, there can be a size limit, but the zfsboot script uses a generous 512kb (and aligns the first partition to 1mb) I had originally thought to just use GPT all the time, but there was significant demand for ZFS on MBR. Seems people don't want to replace their laptops just to get ZFS --=20 Allan Jude --O1qHI4a8e0trmn8ujkII0wGqte6ob75ta Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSgU6PAAoJEJrBFpNRJZKfTfAP/1nM7Ku2KtUvk9yqCxrSzZ/d 4K5WweyASDydc3RvhdDaNVxhl75sXp0NtyQTsBrlL0RGkFA0XtdEMvaJvHb/txxG f0BP5oSabatH6KNgdiNNIJaaSnXsT4zdbLiRhB+riN3TlWRJerQHr8Wyk5MTAgex AwdC8nxnABKpceIyb5LAfO9ZSGtag+QPd87UdKQ8OH9Ah7VDc9FL0nX4wOYALmYx BMOARe4xB5tEoe6uVf29E+anYrFlZTBc4yqWoRQ4Q3W9lMsJCNry//yYdSvc/DFi vBTfLHtJPMyf/oM/iLeR1l5R0MZDLq+blqnVBz6ZGvMLJXyH0pf3SCE/mMj/1OHz qC0i6RwuS8T8WmURfAccJ7iNvtBdyvo1BhkVzgYe6zXJl0tcBSfuqZubiyjV4VjL VKEXyUD9r+/MQFw/B6jc+UZm0YSHCgUVdcnQDrWXLB7gOyp9TfFDZJbqejrsc+AZ 4hce17Kry2INSG8X3/xRcmOqHJ30TWZpnoFzNDwxILhh7leFsTy/gQJTrhRg+aMb TXWF5Cq2/QUY0eADZsXesH/cb+Tnqvmmq6wgoDEwEyg3PFoV8RRXnf46xUMZJzuT JBqgxDmP/y8u09L55J9VAmAMHCeRbzIVImaCxKQkICouXveObRk+SwBVdmHDOz9X sqLvNLVJlbltkZ4e+Mjq =KeMa -----END PGP SIGNATURE----- --O1qHI4a8e0trmn8ujkII0wGqte6ob75ta-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 21:41:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BE2291CF for ; Mon, 11 Nov 2013 21:41:22 +0000 (UTC) (envelope-from freebsd@allanjude.com) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 786812A00 for ; Mon, 11 Nov 2013 21:41:22 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.108.129]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 8BB3B475B8 for ; Mon, 11 Nov 2013 21:41:21 +0000 (UTC) Message-ID: <52814F09.5090000@allanjude.com> Date: Mon, 11 Nov 2013 16:41:29 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Default MBR boot "manager" References: <33391A36-2E7A-473B-87E0-88BDE1AC97D1@fisglobal.com> <52814CD8.5020708@freebsd.org> <236424BC-EC62-4FDC-B9F6-E08653FF2F4B@fisglobal.com> In-Reply-To: <236424BC-EC62-4FDC-B9F6-E08653FF2F4B@fisglobal.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7lT8v9O7Ef7PcBelprjKEtB3UPA3fwkSG" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 21:41:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7lT8v9O7Ef7PcBelprjKEtB3UPA3fwkSG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-11-11 16:39, Teske, Devin wrote: > On Nov 11, 2013, at 1:32 PM, Nathan Whitehorn wrote: > >> On 11/11/13 15:19, Teske, Devin wrote: >>> Topic: Lenovo Laptops and bsdinstall zfsboot with MBR layout... >>> >>> Should we do the quick patch to change the default >>> from /boot/boot0 to /boot/mbr: >>> >>> Index: zfsboot >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- zfsboot (revision 258016) >>> +++ zfsboot (working copy) >>> @@ -764,7 +764,7 @@ zfs_create_diskpart() >>> # >>> f_eval_catch $funcname gpart "$GPART_CREATE" mbr \$di= sk || >>> return $FAILURE >>> - f_eval_catch $funcname gpart "$GPART_BOOTCODE" /boot/= boot0 \ >>> + f_eval_catch $funcname gpart "$GPART_BOOTCODE" /boot/= mbr \ >>> \$disk || return $FAILURE >>> >>> # >>> >>> That would fix things for Lenovo laptops for the next >>> release until I finish up the bootcode selection menu. >>> I'd like to take my time in making sure Allan and I design >>> a worthy bootcode selection menu. >> This patch looks good (I don't remember why it was boot0 in the first = place). I think gpart automatically installs something like /boot/mbr by = default, so I'd be interested to know if making the diff purely negative = still works. >> >> On another note, I think we should move away from a selector. Right no= w, we have three kinds of boot code: >> 1. ZFS boot code >> 2. UFS boot code >> 3. boot0 >> >> Unifying 1 and 2 would help a lot -- I don't know of any reason we nee= d both except for tradition. #3 is probably best done as a post-install c= onfig step ("Install FreeBSD boot manager" or something), which also mean= s it works for UFS systems. > Well, I'm sensitive to the fact that sysinstall offered "none" and > even explained why in an F1 dialog that brought up "drives.hlp" > to explain that you might want to keep whatever (alternate) boot > manager you may be using already. > > In a proposed selector, the full breadth of options that I was > envisioning was: > > GPT + gptboot > GPT + none (use your existing boot manager... syslinux?) > MBR + mbr > MBR + boot0 > MBR + none (again, BYOBM) > > Hadn't got around to zfsboot yet. Where would that go? at the top? > > GPT + zfsboot ? > > (and of course, this is x86 specific... I was gleaning from sysinstall > that for systems like pc98, they call it an IPL and there's only two > options... a standard IPL or bring your own boot manager, aka "none"). > > I imagine that there would be architectures that are like the ol' pc98,= > wherein they don't have all these options (is, for example? sparc64 > GPT only?) for ZFS on GPT It would be /boot/gptzfsboot /boot/zfsboot is the bits for MBR that get's DDd into the ZFS partition --=20 Allan Jude --7lT8v9O7Ef7PcBelprjKEtB3UPA3fwkSG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSgU8JAAoJEJrBFpNRJZKfmWoP/jJ+YrM40E6Hq+U4I7dsbc2X FikSxy04cS6sCAAGsoR4ceo4iiMMKsfmpEia7Q15u3dToMH8ZzpIStw4Yt1TbBb4 zQLK5qRGI+afhq2norfnMpp27Jx1sDh7ee9nngAYtt0v2aA0DkC8qexQHQeiPISi t03Lmcl1kBJxfnaYpjjZsxGs0NifNQLBW8jCobnsudbYUxZ+4cVy3eJmKBfiLK+e yxA2uQxH+bWLlRhglKqkmKc/HeqtrF+UpbZN0f1h0kgGnGqzJ8NAwRMBMXWJKtb0 zIssTQXg6SgCAKJ7apY3bB8T7KfcWktuCKLO0b9CmAtLoE6fcnp09Spwpw+Yqtci RRHO4RwTFnqRHXHTsHbLZfTeGF7yFCnpJLF3zT0GW6GpZNXqMgxYlwDGcgd7elhz pRG1UA29CQmXAVWUde/Jp4U08tprVQRfAfQTbQX42IIjOKLXg3BVl/wyGN+WMaUE vKSyDF2FKX/akcsDiMN3ITqQ22TIlX1/O7XILu+n5ntZmlpcC3nBifAYojezWCcM BDfEUTVXvAx8SmhX2AxiwVOVvNmpDsqcK17Fqb09iqZefu4GzQ4DEmc+/mRijaUE iaZyxhleyZDY08DByLWXuUOGsmAVxq2TFmcBYjVOdJMD+aQvzDKwAGLGrrvKAGkA DQl0gvLm1MTa1YvS41un =YMzQ -----END PGP SIGNATURE----- --7lT8v9O7Ef7PcBelprjKEtB3UPA3fwkSG-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 21:43:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 836975E6; Mon, 11 Nov 2013 21:43:05 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id 36D682A1A; Mon, 11 Nov 2013 21:43:04 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 79A9F5838F; Mon, 11 Nov 2013 15:43:04 -0600 (CST) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id a4ruQLx+Amfs; Mon, 11 Nov 2013 15:43:04 -0600 (CST) Received: from terminus.icecube.wisc.edu (terminus.icecube.wisc.edu [172.16.223.97]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 4292458389; Mon, 11 Nov 2013 15:43:04 -0600 (CST) Message-ID: <52814F68.2090504@freebsd.org> Date: Mon, 11 Nov 2013 15:43:04 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Devin Teske Subject: Re: Default MBR boot "manager" References: <33391A36-2E7A-473B-87E0-88BDE1AC97D1@fisglobal.com> <52814CD8.5020708@freebsd.org> <236424BC-EC62-4FDC-B9F6-E08653FF2F4B@fisglobal.com> In-Reply-To: <236424BC-EC62-4FDC-B9F6-E08653FF2F4B@fisglobal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Current Current , "Teske, Devin" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 21:43:05 -0000 On 11/11/13 15:39, Teske, Devin wrote: > On Nov 11, 2013, at 1:32 PM, Nathan Whitehorn wrote: > >> On 11/11/13 15:19, Teske, Devin wrote: >>> Topic: Lenovo Laptops and bsdinstall zfsboot with MBR layout... >>> >>> Should we do the quick patch to change the default >>> from /boot/boot0 to /boot/mbr: >>> >>> Index: zfsboot >>> =================================================================== >>> --- zfsboot (revision 258016) >>> +++ zfsboot (working copy) >>> @@ -764,7 +764,7 @@ zfs_create_diskpart() >>> # >>> f_eval_catch $funcname gpart "$GPART_CREATE" mbr \$disk || >>> return $FAILURE >>> - f_eval_catch $funcname gpart "$GPART_BOOTCODE" /boot/boot0 \ >>> + f_eval_catch $funcname gpart "$GPART_BOOTCODE" /boot/mbr \ >>> \$disk || return $FAILURE >>> >>> # >>> >>> That would fix things for Lenovo laptops for the next >>> release until I finish up the bootcode selection menu. >>> I'd like to take my time in making sure Allan and I design >>> a worthy bootcode selection menu. >> This patch looks good (I don't remember why it was boot0 in the first place). I think gpart automatically installs something like /boot/mbr by default, so I'd be interested to know if making the diff purely negative still works. >> >> On another note, I think we should move away from a selector. Right now, we have three kinds of boot code: >> 1. ZFS boot code >> 2. UFS boot code >> 3. boot0 >> >> Unifying 1 and 2 would help a lot -- I don't know of any reason we need both except for tradition. #3 is probably best done as a post-install config step ("Install FreeBSD boot manager" or something), which also means it works for UFS systems. > Well, I'm sensitive to the fact that sysinstall offered "none" and > even explained why in an F1 dialog that brought up "drives.hlp" > to explain that you might want to keep whatever (alternate) boot > manager you may be using already. > > In a proposed selector, the full breadth of options that I was > envisioning was: > > GPT + gptboot > GPT + none (use your existing boot manager... syslinux?) > MBR + mbr > MBR + boot0 > MBR + none (again, BYOBM) > > Hadn't got around to zfsboot yet. Where would that go? at the top? > > GPT + zfsboot ? > > (and of course, this is x86 specific... I was gleaning from sysinstall > that for systems like pc98, they call it an IPL and there's only two > options... a standard IPL or bring your own boot manager, aka "none"). > > I imagine that there would be architectures that are like the ol' pc98, > wherein they don't have all these options (is, for example? sparc64 > GPT only?) This would be super-unportable. SPARC uses VTOC8, for example, and doesn't support GPT at all. PC98 has the differences you mentioned. PowerPC uses MBR sometimes, sometimes APM, sometimes GPT. You never have a choice. No platforms except x86 have any analog to boot0. Etc, etc. This is why I'd like to pull ZFS into partedit, which already knows how to set up everything and does the right thing everywhere. For the only system (x86) where there is a real choice (do you want to replace whatever you have already with boot0?), it makes sense to do this as a post-install config. -Nathan From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 21:51:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4FA94858; Mon, 11 Nov 2013 21:51:05 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 18DEE2AA0; Mon, 11 Nov 2013 21:51:04 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa07.fnfis.com (8.14.5/8.14.5) with ESMTP id rABLp3KZ024787 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Nov 2013 15:51:03 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.152]) by LTCFISWMSGHT03.FNFIS.com ([10.132.206.31]) with mapi id 14.03.0158.001; Mon, 11 Nov 2013 15:51:02 -0600 From: "Teske, Devin" To: Nathan Whitehorn Subject: Re: Default MBR boot "manager" Thread-Topic: Default MBR boot "manager" Thread-Index: AQHO3yOxLX+gV+R89keqYsOt5bsQkg== Date: Mon, 11 Nov 2013 21:51:01 +0000 Message-ID: <8C7FE7C5-3F51-4748-B242-8DA93F441684@fisglobal.com> References: <33391A36-2E7A-473B-87E0-88BDE1AC97D1@fisglobal.com> <52814CD8.5020708@freebsd.org> <236424BC-EC62-4FDC-B9F6-E08653FF2F4B@fisglobal.com> <52814F68.2090504@freebsd.org> In-Reply-To: <52814F68.2090504@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4696898CD38C07459AF479802ECDA78E@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-11-11_04:2013-11-11,2013-11-11,1970-01-01 signatures=0 Cc: Devin Teske , "Teske, Devin" , Current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 21:51:05 -0000 On Nov 11, 2013, at 1:43 PM, Nathan Whitehorn wrote: > On 11/11/13 15:39, Teske, Devin wrote: >> On Nov 11, 2013, at 1:32 PM, Nathan Whitehorn wrote: >>=20 >>> On 11/11/13 15:19, Teske, Devin wrote: >>>> Topic: Lenovo Laptops and bsdinstall zfsboot with MBR layout... >>>>=20 >>>> Should we do the quick patch to change the default >>>> from /boot/boot0 to /boot/mbr: >>>>=20 >>>> Index: zfsboot >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> --- zfsboot (revision 258016) >>>> +++ zfsboot (working copy) >>>> @@ -764,7 +764,7 @@ zfs_create_diskpart() >>>> # >>>> f_eval_catch $funcname gpart "$GPART_CREATE" mbr \$dis= k || >>>> return $FAILURE >>>> - f_eval_catch $funcname gpart "$GPART_BOOTCODE" /boot/b= oot0 \ >>>> + f_eval_catch $funcname gpart "$GPART_BOOTCODE" /boot/m= br \ >>>> \$disk || return $FAILURE >>>>=20 >>>> # >>>>=20 >>>> That would fix things for Lenovo laptops for the next >>>> release until I finish up the bootcode selection menu. >>>> I'd like to take my time in making sure Allan and I design >>>> a worthy bootcode selection menu. >>> This patch looks good (I don't remember why it was boot0 in the first p= lace). I think gpart automatically installs something like /boot/mbr by def= ault, so I'd be interested to know if making the diff purely negative still= works. >>>=20 >>> On another note, I think we should move away from a selector. Right now= , we have three kinds of boot code: >>> 1. ZFS boot code >>> 2. UFS boot code >>> 3. boot0 >>>=20 >>> Unifying 1 and 2 would help a lot -- I don't know of any reason we need= both except for tradition. #3 is probably best done as a post-install conf= ig step ("Install FreeBSD boot manager" or something), which also means it = works for UFS systems. >> Well, I'm sensitive to the fact that sysinstall offered "none" and >> even explained why in an F1 dialog that brought up "drives.hlp" >> to explain that you might want to keep whatever (alternate) boot >> manager you may be using already. >>=20 >> In a proposed selector, the full breadth of options that I was >> envisioning was: >>=20 >> GPT + gptboot >> GPT + none (use your existing boot manager... syslinux?) >> MBR + mbr >> MBR + boot0 >> MBR + none (again, BYOBM) >>=20 >> Hadn't got around to zfsboot yet. Where would that go? at the top? >>=20 >> GPT + zfsboot ? >>=20 >> (and of course, this is x86 specific... I was gleaning from sysinstall >> that for systems like pc98, they call it an IPL and there's only two >> options... a standard IPL or bring your own boot manager, aka "none"). >>=20 >> I imagine that there would be architectures that are like the ol' pc98, >> wherein they don't have all these options (is, for example? sparc64 >> GPT only?) >=20 > This would be super-unportable. SPARC uses VTOC8, for example, and doesn'= t support GPT at all. PC98 has the differences you mentioned. PowerPC uses = MBR sometimes, sometimes APM, sometimes GPT. You never have a choice. No pl= atforms except x86 have any analog to boot0. Etc, etc. This is why I'd like= to pull ZFS into partedit, which already knows how to set up everything an= d does the right thing everywhere. For the only system (x86) where there is= a real choice (do you want to replace whatever you have already with boot0= ?), it makes sense to do this as a post-install config. Two migration paths before us, and I do rather like the idea of benefiting from all your work there. My biggest concern is how to maximize functionality in the migration of the ZFS stuff to partedit. You know the code better there better than I, ... have you given much thought to how you might integrate what we've done? It's sad that we would be giving up i18n, X11, and discrete scripting (surely there are more parts to ZFS than what partedit supports now -- e.g., datasets, etc.). Naturally, the scripting can be solved. i18n is a bit harder to solve as it's a "start from the bottom" venture. And I fear X11 is a lost cause in its current state for partedit. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 22:36:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CFEAD6A7; Mon, 11 Nov 2013 22:36:41 +0000 (UTC) (envelope-from neel@neelc.org) Received: from mail.neelc.org (maya.neelc.org [72.0.227.50]) by mx1.freebsd.org (Postfix) with ESMTP id 6A4892CB2; Mon, 11 Nov 2013 22:36:40 +0000 (UTC) Received: from mail.neelc.org (maya.neelc.org [72.0.227.50]) by mail.neelc.org (Postfix) with ESMTPA id 703A9118701C; Mon, 11 Nov 2013 17:29:18 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 11 Nov 2013 17:29:18 -0500 From: Neel Chauhan To: freebsd-current@freebsd.org, freebsd-x11@freebsd.org Subject: [PATCH] Haswell Kernel Mode Setting Mail-Reply-To: neel@neelc.org Message-ID: X-Sender: neel@neelc.org User-Agent: Roundcube Webmail/0.9.5 X-Mailman-Approved-At: Mon, 11 Nov 2013 22:47:35 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: neel@neelc.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 22:36:42 -0000 Hello FreeBSD-CURRENT and FreeBSD-X11 mailing list(s), I have a patch to add support for kernel mode setting on Intel Haswell/4th generation Core i(3/5/7) chips. The patch is: diff -u -r -N head/sys/dev/agp/agp_i810.c tree/sys/dev/agp/agp_i810.c --- head/sys/dev/agp/agp_i810.c 2013-11-11 16:18:23.000000000 -0500 +++ tree/sys/dev/agp/agp_i810.c 2013-11-11 17:09:33.000000000 -0500 @@ -734,6 +734,41 @@ .name = "IvyBridge server GT2 IG", .driver = &agp_i810_sb_driver }, + { + .devid = 0x04028086, + .name = "Haswell desktop GT1 IG", + .driver = &agp_i810_sb_driver + }, + { + .devid = 0x04128086, + .name = "Haswell desktop GT2 IG", + .driver = &agp_i810_sb_driver + }, + { + .devid = 0x04068086, + .name = "Haswell mobile GT1 IG", + .driver = &agp_i810_sb_driver + }, + { + .devid = 0x04168086, + .name = "Haswell mobile GT2 IG", + .driver = &agp_i810_sb_driver + }, + { + .devid = 0x040a8086, + .name = "Haswell server GT1 IG", + .driver = &agp_i810_sb_driver + }, + { + .devid = 0x041a8086, + .name = "Haswell server GT2 IG", + .driver = &agp_i810_sb_driver + }, + { + .devid = 0x0c168086, + .name = "Haswell SDV", + .driver = &agp_i810_sb_driver + }, { .devid = 0, } diff -u -r -N head/sys/dev/drm2/drm_pciids.h tree/sys/dev/drm2/drm_pciids.h --- head/sys/dev/drm2/drm_pciids.h 2013-11-11 16:17:33.000000000 -0500 +++ tree/sys/dev/drm2/drm_pciids.h 2013-11-11 17:09:37.000000000 -0500 @@ -48,6 +48,42 @@ {0x8086, 0x0162, CHIP_I9XX|CHIP_I915, "Intel IvyBridge"}, \ {0x8086, 0x0166, CHIP_I9XX|CHIP_I915, "Intel IvyBridge (M)"}, \ {0x8086, 0x016A, CHIP_I9XX|CHIP_I915, "Intel IvyBridge (S)"}, \ + {0x8086, 0x0402, CHIP_I9XX|CHIP_I915, "Intel Haswell"}, \ + {0x8086, 0x0412, CHIP_I9XX|CHIP_I915, "Intel Haswell"}, \ + {0x8086, 0x0422, CHIP_I9XX|CHIP_I915, "Intel Haswell"}, \ + {0x8086, 0x0406, CHIP_I9XX|CHIP_I915, "Intel Haswell (M)"}, \ + {0x8086, 0x0416, CHIP_I9XX|CHIP_I915, "Intel Haswell (M)"}, \ + {0x8086, 0x0426, CHIP_I9XX|CHIP_I915, "Intel Haswell (M)"}, \ + {0x8086, 0x040A, CHIP_I9XX|CHIP_I915, "Intel Haswell (S)"}, \ + {0x8086, 0x041A, CHIP_I9XX|CHIP_I915, "Intel Haswell (S)"}, \ + {0x8086, 0x042A, CHIP_I9XX|CHIP_I915, "Intel Haswell (S)"}, \ + {0x8086, 0x0C02, CHIP_I9XX|CHIP_I915, "Intel Haswell"}, \ + {0x8086, 0x0C12, CHIP_I9XX|CHIP_I915, "Intel Haswell"}, \ + {0x8086, 0x0C22, CHIP_I9XX|CHIP_I915, "Intel Haswell"}, \ + {0x8086, 0x0C06, CHIP_I9XX|CHIP_I915, "Intel Haswell (M)"}, \ + {0x8086, 0x0C16, CHIP_I9XX|CHIP_I915, "Intel Haswell (M)"}, \ + {0x8086, 0x0C26, CHIP_I9XX|CHIP_I915, "Intel Haswell (M)"}, \ + {0x8086, 0x0C0A, CHIP_I9XX|CHIP_I915, "Intel Haswell (S)"}, \ + {0x8086, 0x0C1A, CHIP_I9XX|CHIP_I915, "Intel Haswell (S)"}, \ + {0x8086, 0x0C2A, CHIP_I9XX|CHIP_I915, "Intel Haswell (S)"}, \ + {0x8086, 0x0A02, CHIP_I9XX|CHIP_I915, "Intel Haswell"}, \ + {0x8086, 0x0A12, CHIP_I9XX|CHIP_I915, "Intel Haswell"}, \ + {0x8086, 0x0A22, CHIP_I9XX|CHIP_I915, "Intel Haswell"}, \ + {0x8086, 0x0A06, CHIP_I9XX|CHIP_I915, "Intel Haswell (M)"}, \ + {0x8086, 0x0A16, CHIP_I9XX|CHIP_I915, "Intel Haswell (M)"}, \ + {0x8086, 0x0A26, CHIP_I9XX|CHIP_I915, "Intel Haswell (M)"}, \ + {0x8086, 0x0A0A, CHIP_I9XX|CHIP_I915, "Intel Haswell (S)"}, \ + {0x8086, 0x0A1A, CHIP_I9XX|CHIP_I915, "Intel Haswell (S)"}, \ + {0x8086, 0x0A2A, CHIP_I9XX|CHIP_I915, "Intel Haswell (S)"}, \ + {0x8086, 0x0D12, CHIP_I9XX|CHIP_I915, "Intel Haswell"}, \ + {0x8086, 0x0D22, CHIP_I9XX|CHIP_I915, "Intel Haswell"}, \ + {0x8086, 0x0D32, CHIP_I9XX|CHIP_I915, "Intel Haswell"}, \ + {0x8086, 0x0D16, CHIP_I9XX|CHIP_I915, "Intel Haswell (M)"}, \ + {0x8086, 0x0D26, CHIP_I9XX|CHIP_I915, "Intel Haswell (M)"}, \ + {0x8086, 0x0D36, CHIP_I9XX|CHIP_I915, "Intel Haswell (M)"}, \ + {0x8086, 0x0D1A, CHIP_I9XX|CHIP_I915, "Intel Haswell (S)"}, \ + {0x8086, 0x0D2A, CHIP_I9XX|CHIP_I915, "Intel Haswell (S)"}, \ + {0x8086, 0x0D3A, CHIP_I9XX|CHIP_I915, "Intel Haswell (S)"}, \ {0x8086, 0x2562, CHIP_I8XX, "Intel i845G GMCH"}, \ {0x8086, 0x2572, CHIP_I8XX, "Intel i865G GMCH"}, \ {0x8086, 0x2582, CHIP_I9XX|CHIP_I915, "Intel i915G"}, \ diff -u -r -N head/sys/dev/drm2/i915/i915_drv.c tree/sys/dev/drm2/i915/i915_drv.c --- head/sys/dev/drm2/i915/i915_drv.c 2013-11-11 16:17:24.000000000 -0500 +++ tree/sys/dev/drm2/i915/i915_drv.c 2013-11-11 17:10:05.000000000 -0500 @@ -173,6 +173,22 @@ .has_llc = 1, }; +static const struct intel_device_info intel_haswell_d_info = { + .is_haswell = 1, .gen = 8, + .need_gfx_hws = 1, .has_hotplug = 1, + .has_bsd_ring = 1, + .has_blt_ring = 1, + .has_llc = 1, +}; + +static const struct intel_device_info intel_haswell_m_info = { + .is_haswell = 1, .gen = 8, .is_mobile = 1, + .need_gfx_hws = 1, .has_hotplug = 1, + .has_bsd_ring = 1, + .has_blt_ring = 1, + .has_llc = 1, +}; + #define INTEL_VGA_DEVICE(id, info_) { \ .device = id, \ .info = info_, \ @@ -226,6 +242,42 @@ INTEL_VGA_DEVICE(0x0162, &intel_ivybridge_d_info), /* GT2 desktop */ INTEL_VGA_DEVICE(0x015a, &intel_ivybridge_d_info), /* GT1 server */ INTEL_VGA_DEVICE(0x016a, &intel_ivybridge_d_info), /* GT2 server */ + INTEL_VGA_DEVICE(0x0402, &intel_haswell_d_info), /* GT1 desktop */ + INTEL_VGA_DEVICE(0x0412, &intel_haswell_d_info), /* GT2 desktop */ + INTEL_VGA_DEVICE(0x0422, &intel_haswell_d_info), /* GT2 desktop */ + INTEL_VGA_DEVICE(0x040a, &intel_haswell_d_info), /* GT1 server */ + INTEL_VGA_DEVICE(0x041a, &intel_haswell_d_info), /* GT2 server */ + INTEL_VGA_DEVICE(0x042a, &intel_haswell_d_info), /* GT2 server */ + INTEL_VGA_DEVICE(0x0406, &intel_haswell_m_info), /* GT1 mobile */ + INTEL_VGA_DEVICE(0x0416, &intel_haswell_m_info), /* GT2 mobile */ + INTEL_VGA_DEVICE(0x0426, &intel_haswell_m_info), /* GT2 mobile */ + INTEL_VGA_DEVICE(0x0C02, &intel_haswell_d_info), /* SDV GT1 desktop */ + INTEL_VGA_DEVICE(0x0C12, &intel_haswell_d_info), /* SDV GT2 desktop */ + INTEL_VGA_DEVICE(0x0C22, &intel_haswell_d_info), /* SDV GT2 desktop */ + INTEL_VGA_DEVICE(0x0C0A, &intel_haswell_d_info), /* SDV GT1 server */ + INTEL_VGA_DEVICE(0x0C1A, &intel_haswell_d_info), /* SDV GT2 server */ + INTEL_VGA_DEVICE(0x0C2A, &intel_haswell_d_info), /* SDV GT2 server */ + INTEL_VGA_DEVICE(0x0C06, &intel_haswell_m_info), /* SDV GT1 mobile */ + INTEL_VGA_DEVICE(0x0C16, &intel_haswell_m_info), /* SDV GT2 mobile */ + INTEL_VGA_DEVICE(0x0C26, &intel_haswell_m_info), /* SDV GT2 mobile */ + INTEL_VGA_DEVICE(0x0A02, &intel_haswell_d_info), /* ULT GT1 desktop */ + INTEL_VGA_DEVICE(0x0A12, &intel_haswell_d_info), /* ULT GT2 desktop */ + INTEL_VGA_DEVICE(0x0A22, &intel_haswell_d_info), /* ULT GT2 desktop */ + INTEL_VGA_DEVICE(0x0A0A, &intel_haswell_d_info), /* ULT GT1 server */ + INTEL_VGA_DEVICE(0x0A1A, &intel_haswell_d_info), /* ULT GT2 server */ + INTEL_VGA_DEVICE(0x0A2A, &intel_haswell_d_info), /* ULT GT2 server */ + INTEL_VGA_DEVICE(0x0A06, &intel_haswell_m_info), /* ULT GT1 mobile */ + INTEL_VGA_DEVICE(0x0A16, &intel_haswell_m_info), /* ULT GT2 mobile */ + INTEL_VGA_DEVICE(0x0A26, &intel_haswell_m_info), /* ULT GT2 mobile */ + INTEL_VGA_DEVICE(0x0D02, &intel_haswell_d_info), /* CRW GT1 desktop */ + INTEL_VGA_DEVICE(0x0D12, &intel_haswell_d_info), /* CRW GT2 desktop */ + INTEL_VGA_DEVICE(0x0D22, &intel_haswell_d_info), /* CRW GT2 desktop */ + INTEL_VGA_DEVICE(0x0D0A, &intel_haswell_d_info), /* CRW GT1 server */ + INTEL_VGA_DEVICE(0x0D1A, &intel_haswell_d_info), /* CRW GT2 server */ + INTEL_VGA_DEVICE(0x0D2A, &intel_haswell_d_info), /* CRW GT2 server */ + INTEL_VGA_DEVICE(0x0D06, &intel_haswell_m_info), /* CRW GT1 mobile */ + INTEL_VGA_DEVICE(0x0D16, &intel_haswell_m_info), /* CRW GT2 mobile */ + INTEL_VGA_DEVICE(0x0D26, &intel_haswell_m_info), /* CRW GT2 mobile */ {0, 0} }; diff -u -r -N head/sys/dev/drm2/i915/i915_drv.h tree/sys/dev/drm2/i915/i915_drv.h --- head/sys/dev/drm2/i915/i915_drv.h 2013-11-11 16:17:24.000000000 -0500 +++ tree/sys/dev/drm2/i915/i915_drv.h 2013-11-11 17:10:05.000000000 -0500 @@ -152,6 +152,7 @@ u8 is_broadwater:1; u8 is_crestline:1; u8 is_ivybridge:1; + u8 is_haswell:1; u8 has_fbc:1; u8 has_pipe_cxsr:1; u8 has_hotplug:1; @@ -1406,6 +1407,7 @@ #define IS_IRONLAKE_D(dev) ((dev)->pci_device == 0x0042) #define IS_IRONLAKE_M(dev) ((dev)->pci_device == 0x0046) #define IS_IVYBRIDGE(dev) (INTEL_INFO(dev)->is_ivybridge) +#define IS_HASWELL(dev) (INTEL_INFO(dev)->is_haswell) #define IS_MOBILE(dev) (INTEL_INFO(dev)->is_mobile) /* XXXKIB LEGACY */ diff -u -r -N head/sys/dev/drm2/i915/i915_irq.c tree/sys/dev/drm2/i915/i915_irq.c --- head/sys/dev/drm2/i915/i915_irq.c 2013-11-11 16:17:26.000000000 -0500 +++ tree/sys/dev/drm2/i915/i915_irq.c 2013-11-11 17:10:05.000000000 -0500 @@ -1875,6 +1875,14 @@ dev->driver->irq_uninstall = ironlake_irq_uninstall; dev->driver->enable_vblank = ivybridge_enable_vblank; dev->driver->disable_vblank = ivybridge_disable_vblank; + } else if (IS_HASWELL(dev)) { + /* Share interrupts handling with IVB */ + dev->driver->irq_handler = ivybridge_irq_handler; + dev->driver->irq_preinstall = ironlake_irq_preinstall; + dev->driver->irq_postinstall = ivybridge_irq_postinstall; + dev->driver->irq_uninstall = ironlake_irq_uninstall; + dev->driver->enable_vblank = ivybridge_enable_vblank; + dev->driver->disable_vblank = ivybridge_disable_vblank; } else if (HAS_PCH_SPLIT(dev)) { dev->driver->irq_handler = ironlake_irq_handler; dev->driver->irq_preinstall = ironlake_irq_preinstall; Sorry if I sent a similar patch before. It didn't get accepted so I am sending one now. Enjoy. Thanks, Neel From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 01:15:29 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD5875E7; Tue, 12 Nov 2013 01:15:29 +0000 (UTC) Received: from smtpauth4.wiscmail.wisc.edu (wmauth4.doit.wisc.edu [144.92.197.145]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6893521AC; Mon, 11 Nov 2013 23:57:14 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth4.wiscmail.wisc.edu by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MW400I00FPX5100@smtpauth4.wiscmail.wisc.edu>; Mon, 11 Nov 2013 16:57:07 -0600 (CST) X-Spam-PmxInfo: Server=avs-4, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.11.224515, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from comporellon.tachypleus.net (adsl-76-208-69-44.dsl.mdsnwi.sbcglobal.net [76.208.69.44]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MW400BP8FR5QA00@smtpauth4.wiscmail.wisc.edu>; Mon, 11 Nov 2013 16:57:07 -0600 (CST) Message-id: <528160C1.4090501@freebsd.org> Date: Mon, 11 Nov 2013 16:57:05 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 To: Devin Teske Subject: Re: Default MBR boot "manager" References: <33391A36-2E7A-473B-87E0-88BDE1AC97D1@fisglobal.com> <52814CD8.5020708@freebsd.org> <236424BC-EC62-4FDC-B9F6-E08653FF2F4B@fisglobal.com> <52814F68.2090504@freebsd.org> <8C7FE7C5-3F51-4748-B242-8DA93F441684@fisglobal.com> In-reply-to: <8C7FE7C5-3F51-4748-B242-8DA93F441684@fisglobal.com> Cc: Current Current , "Teske, Devin" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 01:15:30 -0000 On 11/11/13 15:51, Teske, Devin wrote: > On Nov 11, 2013, at 1:43 PM, Nathan Whitehorn wrote: > >> On 11/11/13 15:39, Teske, Devin wrote: >>> On Nov 11, 2013, at 1:32 PM, Nathan Whitehorn wrote: >>> >>>> On 11/11/13 15:19, Teske, Devin wrote: >>>>> Topic: Lenovo Laptops and bsdinstall zfsboot with MBR layout... >>>>> >>>>> Should we do the quick patch to change the default >>>>> from /boot/boot0 to /boot/mbr: >>>>> >>>>> Index: zfsboot >>>>> =================================================================== >>>>> --- zfsboot (revision 258016) >>>>> +++ zfsboot (working copy) >>>>> @@ -764,7 +764,7 @@ zfs_create_diskpart() >>>>> # >>>>> f_eval_catch $funcname gpart "$GPART_CREATE" mbr \$disk || >>>>> return $FAILURE >>>>> - f_eval_catch $funcname gpart "$GPART_BOOTCODE" /boot/boot0 \ >>>>> + f_eval_catch $funcname gpart "$GPART_BOOTCODE" /boot/mbr \ >>>>> \$disk || return $FAILURE >>>>> >>>>> # >>>>> >>>>> That would fix things for Lenovo laptops for the next >>>>> release until I finish up the bootcode selection menu. >>>>> I'd like to take my time in making sure Allan and I design >>>>> a worthy bootcode selection menu. >>>> This patch looks good (I don't remember why it was boot0 in the first place). I think gpart automatically installs something like /boot/mbr by default, so I'd be interested to know if making the diff purely negative still works. >>>> >>>> On another note, I think we should move away from a selector. Right now, we have three kinds of boot code: >>>> 1. ZFS boot code >>>> 2. UFS boot code >>>> 3. boot0 >>>> >>>> Unifying 1 and 2 would help a lot -- I don't know of any reason we need both except for tradition. #3 is probably best done as a post-install config step ("Install FreeBSD boot manager" or something), which also means it works for UFS systems. >>> Well, I'm sensitive to the fact that sysinstall offered "none" and >>> even explained why in an F1 dialog that brought up "drives.hlp" >>> to explain that you might want to keep whatever (alternate) boot >>> manager you may be using already. >>> >>> In a proposed selector, the full breadth of options that I was >>> envisioning was: >>> >>> GPT + gptboot >>> GPT + none (use your existing boot manager... syslinux?) >>> MBR + mbr >>> MBR + boot0 >>> MBR + none (again, BYOBM) >>> >>> Hadn't got around to zfsboot yet. Where would that go? at the top? >>> >>> GPT + zfsboot ? >>> >>> (and of course, this is x86 specific... I was gleaning from sysinstall >>> that for systems like pc98, they call it an IPL and there's only two >>> options... a standard IPL or bring your own boot manager, aka "none"). >>> >>> I imagine that there would be architectures that are like the ol' pc98, >>> wherein they don't have all these options (is, for example? sparc64 >>> GPT only?) >> This would be super-unportable. SPARC uses VTOC8, for example, and doesn't support GPT at all. PC98 has the differences you mentioned. PowerPC uses MBR sometimes, sometimes APM, sometimes GPT. You never have a choice. No platforms except x86 have any analog to boot0. Etc, etc. This is why I'd like to pull ZFS into partedit, which already knows how to set up everything and does the right thing everywhere. For the only system (x86) where there is a real choice (do you want to replace whatever you have already with boot0?), it makes sense to do this as a post-install config. > Two migration paths before us, and I do rather like the idea of > benefiting from all your work there. > > My biggest concern is how to maximize functionality in the > migration of the ZFS stuff to partedit. > > You know the code better there better than I, ... have you given > much thought to how you might integrate what we've done? Some, though not as much as it deserves. The general idea would be to treat ZFS as a kind of partitioning. I don't think we can realistically expose all ZFS features through the installer. > It's sad that we would be giving up i18n, X11, and discrete > scripting (surely there are more parts to ZFS than what partedit > supports now -- e.g., datasets, etc.). > > Naturally, the scripting can be solved. i18n is a bit harder to > solve as it's a "start from the bottom" venture. And I fear X11 is > a lost cause in its current state for partedit. This is a pity. I'm not sure what to do there. Would be nice to have something libdialog-alike for X, but that leaves all these other issues too. One option would be to factor out the important bits of partedit longer-term, similar to the way to the scripting interface exists now (e.g. format this disk with these partitions, make the first one bootable, I don't care how it's done) and then call that from something prettier. Interactivity and the complexity of the things you can do with GEOM makes doing that fully hard, however (even the existing functionality ended up requiring kernel patches). -Nathan From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 01:20:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 355C1B9B for ; Tue, 12 Nov 2013 01:20:26 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5142F8C for ; Mon, 11 Nov 2013 23:35:03 +0000 (UTC) Received: from [157.181.98.186] ([157.181.98.186]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MWT8s-1WDTGE2EQ6-00XdX2 for ; Tue, 12 Nov 2013 00:34:56 +0100 Message-ID: <52816980.8000200@gmx.com> Date: Tue, 12 Nov 2013 00:34:24 +0100 From: dt71@gmx.com User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Firefox/24.0 SeaMonkey/2.21 MIME-Version: 1.0 To: Tijl Coosemans Subject: Re: new Xorg (KMS, etc.) for Radeon 9600 References: <527F95BE.7080908@gmx.com> <527FC05D.8080703@gmx.com> <20131111100707.481d2fbf@kalimero.tijl.coosemans.org> In-Reply-To: <20131111100707.481d2fbf@kalimero.tijl.coosemans.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:zc+qRPQybZpJN7/IM52jNCvjoIWbrjxnS/GlMsNeMbXrkoWvK04 WIsuaI/e3jrGyS/0ovzAmKNmFc8Wjd4qVFXJKAm8tewy01UlMzXn47kq8YguM7uLOtUVqvo L95x39PcYvAqfzH8MRY9qpMn4gpL6cBnzcI4D8coaVzby0AcraO+v49QFWYhJ5VPcayVff4 okqqvN7T8HdYJxF4Mgo0g== Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 01:20:26 -0000 Tijl Coosemans wrote, On 11/11/2013 10:07: > On Sun, 10 Nov 2013 18:20:29 +0100 dt71@gmx.com wrote: >> error: [drm:pid667:r100_cp_init_microcode] *ERROR* radeon_cp: Failed to load firmware "radeonkmsfw_R300_cp" > > Make sure you have /boot/kernel/radeonkmsfw_R300_cp.ko. Oops, my bad. I had WITHOUT_SOURCELESS=1 in /etc/src.conf. Now the said 3D application works, though the performance is crappier than with the old Xorg... From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 01:30:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 597B6F0; Tue, 12 Nov 2013 01:30:27 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 691862F71; Mon, 11 Nov 2013 23:31:44 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa05.fnfis.com (8.14.5/8.14.5) with ESMTP id rABNVhX9000958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Nov 2013 17:31:43 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.152]) by LTCFISWMSGHT06.FNFIS.com ([10.132.206.17]) with mapi id 14.03.0158.001; Mon, 11 Nov 2013 17:31:42 -0600 From: "Teske, Devin" To: Nathan Whitehorn Subject: Re: Default MBR boot "manager" Thread-Topic: Default MBR boot "manager" Thread-Index: AQHO3yOxLX+gV+R89keqYsOt5bsQkg== Date: Mon, 11 Nov 2013 23:31:41 +0000 Message-ID: <7806EBD9-46CC-4924-803A-E15C05566162@fisglobal.com> References: <33391A36-2E7A-473B-87E0-88BDE1AC97D1@fisglobal.com> <52814CD8.5020708@freebsd.org> <236424BC-EC62-4FDC-B9F6-E08653FF2F4B@fisglobal.com> <52814F68.2090504@freebsd.org> <8C7FE7C5-3F51-4748-B242-8DA93F441684@fisglobal.com> <528160C1.4090501@freebsd.org> In-Reply-To: <528160C1.4090501@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="us-ascii" Content-ID: <76A80304C484E64E9DE7849734A85C34@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-11-11_04:2013-11-11,2013-11-11,1970-01-01 signatures=0 Cc: Devin Teske , "Teske, Devin" , Current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 01:30:27 -0000 On Nov 11, 2013, at 2:57 PM, Nathan Whitehorn wrote: > On 11/11/13 15:51, Teske, Devin wrote: >> On Nov 11, 2013, at 1:43 PM, Nathan Whitehorn wrote: >>=20 >>> On 11/11/13 15:39, Teske, Devin wrote: >>>> On Nov 11, 2013, at 1:32 PM, Nathan Whitehorn wrote: >>>>=20 >>>>> On 11/11/13 15:19, Teske, Devin wrote: >>>>>> Topic: Lenovo Laptops and bsdinstall zfsboot with MBR layout... >>>>>>=20 >>>>>> Should we do the quick patch to change the default >>>>>> from /boot/boot0 to /boot/mbr: >>>>>>=20 >>>>>> Index: zfsboot >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>> --- zfsboot (revision 258016) >>>>>> +++ zfsboot (working copy) >>>>>> @@ -764,7 +764,7 @@ zfs_create_diskpart() >>>>>> # >>>>>> f_eval_catch $funcname gpart "$GPART_CREATE" mbr \$d= isk || >>>>>> return $FAILURE >>>>>> - f_eval_catch $funcname gpart "$GPART_BOOTCODE" /boot= /boot0 \ >>>>>> + f_eval_catch $funcname gpart "$GPART_BOOTCODE" /boot= /mbr \ >>>>>> \$disk || return $FAILURE >>>>>>=20 >>>>>> # >>>>>>=20 >>>>>> That would fix things for Lenovo laptops for the next >>>>>> release until I finish up the bootcode selection menu. >>>>>> I'd like to take my time in making sure Allan and I design >>>>>> a worthy bootcode selection menu. >>>>> This patch looks good (I don't remember why it was boot0 in the first= place). I think gpart automatically installs something like /boot/mbr by d= efault, so I'd be interested to know if making the diff purely negative sti= ll works. >>>>>=20 >>>>> On another note, I think we should move away from a selector. Right n= ow, we have three kinds of boot code: >>>>> 1. ZFS boot code >>>>> 2. UFS boot code >>>>> 3. boot0 >>>>>=20 >>>>> Unifying 1 and 2 would help a lot -- I don't know of any reason we ne= ed both except for tradition. #3 is probably best done as a post-install co= nfig step ("Install FreeBSD boot manager" or something), which also means i= t works for UFS systems. >>>> Well, I'm sensitive to the fact that sysinstall offered "none" and >>>> even explained why in an F1 dialog that brought up "drives.hlp" >>>> to explain that you might want to keep whatever (alternate) boot >>>> manager you may be using already. >>>>=20 >>>> In a proposed selector, the full breadth of options that I was >>>> envisioning was: >>>>=20 >>>> GPT + gptboot >>>> GPT + none (use your existing boot manager... syslinux?) >>>> MBR + mbr >>>> MBR + boot0 >>>> MBR + none (again, BYOBM) >>>>=20 >>>> Hadn't got around to zfsboot yet. Where would that go? at the top? >>>>=20 >>>> GPT + zfsboot ? >>>>=20 >>>> (and of course, this is x86 specific... I was gleaning from sysinstall >>>> that for systems like pc98, they call it an IPL and there's only two >>>> options... a standard IPL or bring your own boot manager, aka "none"). >>>>=20 >>>> I imagine that there would be architectures that are like the ol' pc98, >>>> wherein they don't have all these options (is, for example? sparc64 >>>> GPT only?) >>> This would be super-unportable. SPARC uses VTOC8, for example, and does= n't support GPT at all. PC98 has the differences you mentioned. PowerPC use= s MBR sometimes, sometimes APM, sometimes GPT. You never have a choice. No = platforms except x86 have any analog to boot0. Etc, etc. This is why I'd li= ke to pull ZFS into partedit, which already knows how to set up everything = and does the right thing everywhere. For the only system (x86) where there = is a real choice (do you want to replace whatever you have already with boo= t0?), it makes sense to do this as a post-install config. >> Two migration paths before us, and I do rather like the idea of >> benefiting from all your work there. >>=20 >> My biggest concern is how to maximize functionality in the >> migration of the ZFS stuff to partedit. >>=20 >> You know the code better there better than I, ... have you given >> much thought to how you might integrate what we've done? >=20 > Some, though not as much as it deserves. The general idea would be to tre= at ZFS as a kind of partitioning. I don't think we can realistically expose= all ZFS features through the installer. >=20 >> It's sad that we would be giving up i18n, X11, and discrete >> scripting (surely there are more parts to ZFS than what partedit >> supports now -- e.g., datasets, etc.). >>=20 >> Naturally, the scripting can be solved. i18n is a bit harder to >> solve as it's a "start from the bottom" venture. And I fear X11 is >> a lost cause in its current state for partedit. >=20 > This is a pity. I'm not sure what to do there. Would be nice to have some= thing libdialog-alike for X, but that leaves all these other issues too. No matter which way I look at it, that sounds like a lot of work. One way is that it would just fork-exec Xdialog and return the results. Another way would be interfacing with an actual UI library like Tk, Gtk, Gtk2 or your favorite. But then, do we risk the app not looking like the rest of the functions if they use Xdialog(1)? But I'm thinking... We'd have to use dlopen(3) for conditional support anyway, because whatever dependency-chain we choose for X11, we can't link the binary (which will go into base) against the port dependency. Has to be runtime value-add. > One option would be to factor out the important bits of partedit longer-t= erm, similar to the way to the scripting interface exists now (e.g. format = this disk with these partitions, make the first one bootable, I don't care = how it's done) and then call that from something prettier. Factor which part out how? Sounds good, but what were you envisioning? > Interactivity and the complexity of the things you can do with GEOM makes= doing that fully hard, however (even the existing functionality ended up r= equiring kernel patches). I've struggled many times to think (on the fly) of a good clean way to make the UI, but I have come up with some ideas. When I think about the person that wants to do everything manually (but also wants the value-add of the UI, so doesn't necessarily want to do things with commands): NB: Based on $work deployments, currently done by hand + should be able to visit a menu for legacy partitioning + in that menu, request an MBR layout on mfid0 + in that MBR layout on mfid0, request part 1 of 4 to be FreeBSD (taking the entire disk) NB: bootcode requested to be written to this layout + in that FreeBSD part, add index 1 freebsd-ufs (taking 512G) + add index 2 freebsd-ufs taking up the rest + write requested changes and then go back to the previous menu + visit a gmultipath menu + write a multipath label with components da0 and da2 + write a multipath label with components da1 and da3 + return to the previous menu + visit a GPT menu + request GPT layout for multipath label based on da0/da2 + add a freebsd-ufs part to the GPT layout taking the entire disk NB: No bootcode to be written to this layout + write requested changes and then go back to the previous menu + visit a ZFS menu + request a new pool consisting of mfid0s1g and mfid1 + write requested changes and then go back to the previous menu + proceed with install (shakes head) Yeah... we do that. It's complicated, but there's reasoning behind it. But I'm envisioning a menu of compartmentalized partitioning menus. Allowing you to visit each one in any particular order. The gmultipath one is critical to our setup. NB: We have more complicated setups that require visiting the proposed menus in precisely the right order. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 01:40:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 28B346E9 for ; Tue, 12 Nov 2013 01:40:26 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4615926F2 for ; Tue, 12 Nov 2013 00:24:54 +0000 (UTC) Received: from julian-mbp3.pixel8networks.com (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id rAC0Or0H072218 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 11 Nov 2013 16:24:54 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <5281755A.3090301@freebsd.org> Date: Mon, 11 Nov 2013 16:24:58 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Default MBR boot "manager" References: <33391A36-2E7A-473B-87E0-88BDE1AC97D1@fisglobal.com> <52814CD8.5020708@freebsd.org> <52814D98.9050404@allanjude.com> <52814DDE.6040109@freebsd.org> In-Reply-To: <52814DDE.6040109@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 01:40:26 -0000 On 11/11/13, 1:36 PM, Nathan Whitehorn wrote: > On 11/11/13 15:35, Allan Jude wrote: >> On 2013-11-11 16:32, Nathan Whitehorn wrote: >>> On 11/11/13 15:19, Teske, Devin wrote: >>>> Topic: Lenovo Laptops and bsdinstall zfsboot with MBR layout... >>>> >>>> Should we do the quick patch to change the default >>>> from /boot/boot0 to /boot/mbr: >>>> >>>> Index: zfsboot >>>> =================================================================== >>>> --- zfsboot (revision 258016) >>>> +++ zfsboot (working copy) >>>> @@ -764,7 +764,7 @@ zfs_create_diskpart() >>>> # >>>> f_eval_catch $funcname gpart "$GPART_CREATE" mbr >>>> \$disk || >>>> return $FAILURE >>>> - f_eval_catch $funcname gpart "$GPART_BOOTCODE" >>>> /boot/boot0 \ >>>> + f_eval_catch $funcname gpart "$GPART_BOOTCODE" >>>> /boot/mbr \ >>>> \$disk || return $FAILURE >>>> >>>> # >>>> >>>> That would fix things for Lenovo laptops for the next >>>> release until I finish up the bootcode selection menu. >>>> I'd like to take my time in making sure Allan and I design >>>> a worthy bootcode selection menu. >>> This patch looks good (I don't remember why it was boot0 in the first >>> place). I think gpart automatically installs something like /boot/mbr >>> by default, so I'd be interested to know if making the diff purely >>> negative still works. >>> >>> On another note, I think we should move away from a selector. Right >>> now, we have three kinds of boot code: >>> 1. ZFS boot code >>> 2. UFS boot code >>> 3. boot0 >>> >>> Unifying 1 and 2 would help a lot -- I don't know of any reason we >>> need both except for tradition. #3 is probably best done as a >>> post-install config step ("Install FreeBSD boot manager" or >>> something), which also means it works for UFS systems. >>> -Nathan >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to >>> "freebsd-current-unsubscribe@freebsd.org" >> You have to do down right evil things to boot ZFS on MBR. dd'ing the >> 'remainder' of the boot loader into a reserved space at the head of >> the >> ZFS partition. The GPT boot code is 14k, and the code to boot ZFS is >> 40k, whereas the UFS stuff is 512 bytes and fits in the intended slot. >> for mbr/zfs , just declare a zfs-boot slice type, and put it in there sure it complicates it a bit but it is basically what happens in gpt right? > > We could just decide we won't support booting from ZFS on MBR. For > GPT, there is no size limit, which simplifies everything. > -Nathan > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 01:40:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 393876F2; Tue, 12 Nov 2013 01:40:26 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A360726C7; Tue, 12 Nov 2013 00:22:17 +0000 (UTC) Received: from julian-mbp3.pixel8networks.com (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id rAC0MFG3072213 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 11 Nov 2013 16:22:16 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <528174BC.60001@freebsd.org> Date: Mon, 11 Nov 2013 16:22:20 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Nathan Whitehorn , freebsd-current@freebsd.org Subject: Re: Default MBR boot "manager" References: <33391A36-2E7A-473B-87E0-88BDE1AC97D1@fisglobal.com> <52814CD8.5020708@freebsd.org> In-Reply-To: <52814CD8.5020708@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 01:40:26 -0000 On 11/11/13, 1:32 PM, Nathan Whitehorn wrote: > On 11/11/13 15:19, Teske, Devin wrote: >> Topic: Lenovo Laptops and bsdinstall zfsboot with MBR layout... >> >> Should we do the quick patch to change the default >> from /boot/boot0 to /boot/mbr: >> >> Index: zfsboot >> =================================================================== >> --- zfsboot (revision 258016) >> +++ zfsboot (working copy) >> @@ -764,7 +764,7 @@ zfs_create_diskpart() >> # >> f_eval_catch $funcname gpart "$GPART_CREATE" mbr >> \$disk || >> return $FAILURE >> - f_eval_catch $funcname gpart "$GPART_BOOTCODE" >> /boot/boot0 \ >> + f_eval_catch $funcname gpart "$GPART_BOOTCODE" >> /boot/mbr \ >> \$disk || return $FAILURE >> >> # >> >> That would fix things for Lenovo laptops for the next >> release until I finish up the bootcode selection menu. >> I'd like to take my time in making sure Allan and I design >> a worthy bootcode selection menu. > > This patch looks good (I don't remember why it was boot0 in the > first place). I think gpart automatically installs something like > /boot/mbr by default, so I'd be interested to know if making the > diff purely negative still works. > > On another note, I think we should move away from a selector. Right > now, we have three kinds of boot code: > 1. ZFS boot code > 2. UFS boot code > 3. boot0 you forget network booting. > > Unifying 1 and 2 would help a lot -- I don't know of any reason we > need both except for tradition. #3 is probably best done as a > post-install config step ("Install FreeBSD boot manager" or > something), which also means it works for UFS systems. > -Nathan > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 01:45:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF53ABDC; Tue, 12 Nov 2013 01:45:35 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7F62C20AE; Mon, 11 Nov 2013 23:39:13 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 4B99B1776A; Mon, 11 Nov 2013 15:39:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1384213147; bh=uKKioD3ECUTb/p/9CU7JNBAnmuI8lzWzF16VVviVHf4=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=b9lzMxd4JRh9CZSVTj3FRB+Xyvl3BFIEX/vBDq5bc3xWFwDGFuZF6gxz0hNN5zvEN sZk7wAIPvDb8rxJJuRe8AgNuwNy8fUXVbe46Dt3+MijmHtiYJLWSqogXUGZOmvW3D4 n07LVXoOeFxakldlxBVdCyAhsTyeyRQPMGC5zf20= Message-ID: <52816A9A.4050305@delphij.net> Date: Mon, 11 Nov 2013 15:39:06 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: neel@neelc.org, freebsd-current@freebsd.org, freebsd-x11@freebsd.org Subject: Re: [PATCH] Haswell Kernel Mode Setting References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 01:45:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/11/13 14:29, Neel Chauhan wrote: > Sorry if I sent a similar patch before. It didn't get accepted so I > am sending one now. Enjoy. What does "didn't get accepted" mean? :) Since this looks like a PCI-ID only change that do not affect other existing hardware, if it's not an explicit objection from a reviewer, I think it's Okay to just go ahead and commit the change after a reasonable timeout instead of waiting indefinitely. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJSgWqaAAoJEJW2GBstM+ns7pgP/iTu4VI4UYgj/nCmSblhVsjH kO+YPaBoXkO+3e7GQ+E6LKqnH3Byjvc8WZH6/fBA2qY9Kfjjte0gJIG8t7Fu34IQ SRiQaErRYUyXCHIIfgjrvRVIrk7bvwe70awnMVQOIktmzdJ4i6cxxEzsvsLqd5OY Argc77bBkSSa0w/QiWR04bG119u/WVyEhNnJ1XdYq3IzJqTb/fkOYAHm/JaWkhSy F8Vj2bxSr9fiKD36wb/kV5cFC4ZNP/SounurAhMTMaHfWAGJE/KuUy5aRP0bHzOY FwcpAAqIsuy13tBKXXsDNgETTJrbnSGQp7AM7BMZJXkX7kfX8SIfpmG0rjoJH02G V3SDdvMmS/x4sIrKmgwQsUT1MGNGdJtD0Xzx27ng0BVSItPKXkB1azxvRkfRE03N yyWX4C0IQg/U/UgkV3jwe+8LAezPXNRbnKD5QX165g+EnAkRmferAT1/kNnV1zV/ G7eU7x9TTml8fCi0g5Oid3smL+BiwGOkZA36r+Js+lQd5Pmkn3GUJw1qx3vNTWKz P6UHeRzSppez1aWx6NigvPH9qUz+HpaN4aWf+Zzl9MFbKcEohtzT8LaBCB/F1BdG pvGOXcCb+BeUy/IBW+Yx7zal5Ri7YIRIAb2hssqACVBOYwbVzMQidEWuSERMyNdo gMcNWZw+kXLE5wCklwm9 =zbWH -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 02:18:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C98565E0 for ; Tue, 12 Nov 2013 02:18:51 +0000 (UTC) Received: from smtpauth2.wiscmail.wisc.edu (wmauth2.doit.wisc.edu [144.92.197.222]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9D2A93711 for ; Tue, 12 Nov 2013 02:18:51 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MW400G00OXLGC00@smtpauth2.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Mon, 11 Nov 2013 20:18:44 -0600 (CST) X-Spam-PmxInfo: Server=avs-2, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.12.20314, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from comporellon.tachypleus.net (adsl-76-208-69-44.dsl.mdsnwi.sbcglobal.net [76.208.69.44]) by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MW4007S8P37RZ10@smtpauth2.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Mon, 11 Nov 2013 20:18:43 -0600 (CST) Message-id: <52819002.3050908@freebsd.org> Date: Mon, 11 Nov 2013 20:18:42 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 To: freebsd-current@freebsd.org Subject: Re: Default MBR boot "manager" References: <33391A36-2E7A-473B-87E0-88BDE1AC97D1@fisglobal.com> <52814CD8.5020708@freebsd.org> <528174BC.60001@freebsd.org> In-reply-to: <528174BC.60001@freebsd.org> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 02:18:51 -0000 On 11/11/13 18:22, Julian Elischer wrote: > On 11/11/13, 1:32 PM, Nathan Whitehorn wrote: >> On 11/11/13 15:19, Teske, Devin wrote: >>> Topic: Lenovo Laptops and bsdinstall zfsboot with MBR layout... >>> >>> Should we do the quick patch to change the default >>> from /boot/boot0 to /boot/mbr: >>> >>> Index: zfsboot >>> =================================================================== >>> --- zfsboot (revision 258016) >>> +++ zfsboot (working copy) >>> @@ -764,7 +764,7 @@ zfs_create_diskpart() >>> # >>> f_eval_catch $funcname gpart "$GPART_CREATE" mbr >>> \$disk || >>> return $FAILURE >>> - f_eval_catch $funcname gpart "$GPART_BOOTCODE" >>> /boot/boot0 \ >>> + f_eval_catch $funcname gpart "$GPART_BOOTCODE" >>> /boot/mbr \ >>> \$disk || return $FAILURE >>> >>> # >>> >>> That would fix things for Lenovo laptops for the next >>> release until I finish up the bootcode selection menu. >>> I'd like to take my time in making sure Allan and I design >>> a worthy bootcode selection menu. >> >> This patch looks good (I don't remember why it was boot0 in the first >> place). I think gpart automatically installs something like /boot/mbr >> by default, so I'd be interested to know if making the diff purely >> negative still works. >> >> On another note, I think we should move away from a selector. Right >> now, we have three kinds of boot code: >> 1. ZFS boot code >> 2. UFS boot code >> 3. boot0 > > you forget network booting. > > That isn't something written to disk, though (unless you are doing something really weird), so probably isn't relevant for a partitioning tool. -Nathan From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 08:25:08 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 473286E6 for ; Tue, 12 Nov 2013 08:25:08 +0000 (UTC) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CC90A28D3 for ; Tue, 12 Nov 2013 08:25:07 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id x18so4346711lbi.30 for ; Tue, 12 Nov 2013 00:25:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=p/qOwrUda6F0JsQ5oS2ZrwBZmJk5VsaiDit2y2iDqo0=; b=H3Y9N09coQ7Kl++zKDxbGWyGeWb1EKGiLeLapNSzATnGD+Dt6Pmbmd6eqz3MkK6moY jU2bNGRebRAfvnoMwYP7k/yoyghLULA4gcaQcn0lZxiAZ8OSGUzYjSOPpDiyZ2ylr0bS xDJBJSaixxWhmXAPOeDmsMCZBhlVAf+FlDb47BdxzgDJRAKzx3DIKU/324f7f3FJKNBG i5dlk0SSYr7lUKb2JK8drb1ar/IkABSpZuzK1w7ShQRE16tBSYqG2rLDUClbX0oQncUd K0a8tJ1k2nerqzzfkveEBS2Yg5W6+GcBCSZ9HZi5qNY+YWai1w9/t45+NtlfsZEOJi9+ 8tXg== X-Received: by 10.112.205.164 with SMTP id lh4mr25268141lbc.15.1384244705813; Tue, 12 Nov 2013 00:25:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.4.194 with HTTP; Tue, 12 Nov 2013 00:24:25 -0800 (PST) From: swapnil vaidya Date: Tue, 12 Nov 2013 13:54:25 +0530 Message-ID: Subject: Issues in compiling apache server on one machine and transfer to second To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 08:25:08 -0000 Hi All, I have 2 linux machine. I have compiled apache 2.4.6 on one of the linux machine with following commands: ./configure --prefix=/usr/apache--with-ssl=/usr/local/ssl --enable-ssl --enable-modules="all" --enable-mods-shared="most" make make install This has installed apache on this machine and it works fine. However when i copy this apache (where it got installed) folder on other linux machine. I am getting following error while starting httpd with following commad: command: httpd -k start error: /httpd: symbol lookup error: /usr/papache/lib/libapr-1.so.0: undefined symbol: dlopen Can you please help me to understand what is going wrong. From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 08:29:49 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 135078AB; Tue, 12 Nov 2013 08:29:49 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 96B46291C; Tue, 12 Nov 2013 08:29:48 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rAC8TWTE029658; Tue, 12 Nov 2013 10:29:32 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rAC8TWTE029658 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rAC8TW7X029657; Tue, 12 Nov 2013 10:29:32 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 12 Nov 2013 10:29:32 +0200 From: Konstantin Belousov To: d@delphij.net Subject: Re: [PATCH] Haswell Kernel Mode Setting Message-ID: <20131112082932.GU59496@kib.kiev.ua> References: <52816A9A.4050305@delphij.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AgFe1kDvcheJvJOe" Content-Disposition: inline In-Reply-To: <52816A9A.4050305@delphij.net> User-Agent: Mutt/1.5.22 (2013-10-16) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-x11@freebsd.org, freebsd-current@freebsd.org, neel@neelc.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 08:29:49 -0000 --AgFe1kDvcheJvJOe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 11, 2013 at 03:39:06PM -0800, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > On 11/11/13 14:29, Neel Chauhan wrote: > > Sorry if I sent a similar patch before. It didn't get accepted so I > > am sending one now. Enjoy. >=20 > What does "didn't get accepted" mean? :) Since this looks like a > PCI-ID only change that do not affect other existing hardware, if it's > not an explicit objection from a reviewer, I think it's Okay to just > go ahead and commit the change after a reasonable timeout instead of > waiting indefinitely. I very much doubt that this patch works. More, I believe that it was not tested at all. Talking about the trivially obvious things, the PGTT handling must be updated since page tables have different format comparing with Ivy, there are some changes to ring dispatching, and lot of changes in the display pipeline. All this is missing from the patch. Oh, and the Series 8 chipset PCH detection is missing. I probably should stop now. HSW support is much more than just adding the Ids, I am (slowly) starting the work on importing the Linux updates. --AgFe1kDvcheJvJOe Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSgebrAAoJEJDCuSvBvK1BvzEP/0y6MHsO623n6Zzy2nx/3S4W mNhmexgKBmVj7bBil59W7AeesBwZLI24OFYIcvP5vjBnkPOK9jZvsHDcWYbbSjlX HKxZRzU2nf/eszr7ziD5vul3D/wciWBSjtt/0U9AVr/o1sCV/WZakNxz/lWt21hp XLu2/u7N9bb/2phdz+JP5FicEMWxJBaOEwyXkU8liklTd5/fE/Fvjah+Elr20xIr 2FGB0V0Qm7J+c1seZuRLyGQEeRRyYjtxl5T1PO5sptCDhNIs1zXJt0MJvF9bcNJg /DX5xtvDLc8H1yoRuAFrHH0/m09hiDrAlSOQcC/VVjaXAmI0kabM9zAbOIjmT71E LCR5Vn2OTlTyiST2OhRS6H6ysjsRMDW+iWQhH1ncov4myg6fICQl4vO/81hO2Cmp hcxrzGkwgr43lFxgz1NGnWE3DeGRTqJDZgf2lJbjnI3udbhGHkS6GInbDz+ebh61 EEG1gro6w2Q0PDehFBQJPj0TQlbYiFXCoCnM3C7Xg3n0dTZn7IRM6MDb5bpGo3qW 5kK6zpR6P0l+orubtfFv59WPE1ZBngz5i/KlFH6aBD/SIn2A5m21uCp/Pj4s0HqD 23rDxzZcSyH4KGl5kWcj/b4b0j2DCmgX3qJGapfrw+4B5Vi+UJaQ/HX1H9H/rPBN 6Li4u4C1539eTczv1sLZ =YkUS -----END PGP SIGNATURE----- --AgFe1kDvcheJvJOe-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 08:33:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E4C3BB04 for ; Tue, 12 Nov 2013 08:33:31 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id C001D2972 for ; Tue, 12 Nov 2013 08:33:31 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.108.129]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 6C29E47623 for ; Tue, 12 Nov 2013 08:33:30 +0000 (UTC) Message-ID: <5281E7DF.8000907@allanjude.com> Date: Tue, 12 Nov 2013 03:33:35 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Issues in compiling apache server on one machine and transfer to second References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hv7m7xk76qqWXGcUjPs1gedhndmtEJgGj" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 08:33:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hv7m7xk76qqWXGcUjPs1gedhndmtEJgGj Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-11-12 03:24, swapnil vaidya wrote: > Hi All, > I have 2 linux machine. > I have compiled apache 2.4.6 on one of the linux machine with following= > commands: > ./configure --prefix=3D/usr/apache--with-ssl=3D/usr/local/ssl --enable-= ssl > --enable-modules=3D"all" --enable-mods-shared=3D"most" > make > make install > > This has installed apache on this machine and it works fine. > However when i copy this apache (where it got installed) folder on othe= r > linux machine. > I am getting following error while starting httpd with following commad= : > command: > httpd -k start > > error: > > /httpd: symbol lookup error: /usr/papache/lib/libapr-1.so.0: undefined > symbol: dlopen > > Can you please help me to understand what is going wrong. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" Firstly, you are mailing a FreeBSD list about a Linux question Secondly, apache depends on libapr (apache runtime), there are other files you need than just the ones in your apache directory. --=20 Allan Jude --hv7m7xk76qqWXGcUjPs1gedhndmtEJgGj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSgefiAAoJEJrBFpNRJZKfqHEQAKInYdicpbKNsX91YQ/ekctp euvxeMaAlDl7bdiDvd42feMfRGLsoZbKGlowBD0wMQ5F46zJFPPkBfhn5HFYoYKD XEOA12ww6fbprTKiKC9RvdfIdXO/ZPCVrYOwacLhsxD/jh3EfSoeJdKhbVBVT1uP YIZxBRYNsaxToB2TkvOOOq5XGA7Z6D6tP46iNiHEiVIIbaaefzaH1X5hbSRFoRO3 porpQwNTytU3j9T3U9z3TPNAEW5Nr8ebVRqWjlpKJyUxZ2hBWG4HCmIW5pd8Etkk g76PYAp5YV5kYA9c5sZGtq3+BVelMF8V1DSHgQ0LADW/rxFfEIXcpzEZH4KJi7FC buEclumu29FdWX1z+aV3J1sHZ9+eQ8/VkUHJMvzjyArTdVVc2TbYMEM9c3tzPX69 AmhIIS/LrgdjdPjxshjqZrBbOsW3nMYWK3UGpumE/zBG2pXE2hNOnRjJglm4ij+k YaU96IJ8p+YBEQ2bv+NqVoOlx5LTUUKLFD6WzKiMD+xKN53M2ltnd+zor8h3XAyt Dm6VHUFeIaiE89t8S3Ioh0qCtLlzf3Tfc7xS+QNKrIptXpVCO11y3GV1nf1xB/HC snk3rAlGv8+C8FzWXDrznC73gE0BfCZWTDugSjuDwRkPSqoGOBSllSKLSAeB7S53 chfv+KvXjsLemn5KzyVx =qAEw -----END PGP SIGNATURE----- --hv7m7xk76qqWXGcUjPs1gedhndmtEJgGj-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 08:37:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB595C67 for ; Tue, 12 Nov 2013 08:37:28 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C47B9299D for ; Tue, 12 Nov 2013 08:37:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=aw5sP1YwIpDbrGIWa6bShG2j/F/WysnPN865+psdoVM=; b=KdDDI9inC/CGuhywZjFBROBVDq1qfqNjs60E8M51ukU98GBIHwi9wqd1tHKKRIA0YLJc24FyxkQ+ckT01CMY0Uz20c4l39lfqrqHXVk7/PTlWMu5NHmSmnpGk15fdtYoItqJBeUViMNM/J24KTUL0o2+ewPZ6CWz4n2tz4p4+jc=; Received: from [182.14.132.28] (port=56795 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1Vg9TS-000Pwm-8u; Tue, 12 Nov 2013 01:37:27 -0700 Date: Tue, 12 Nov 2013 16:37:18 +0800 From: Erich Dollansky To: swapnil vaidya Subject: Re: Issues in compiling apache server on one machine and transfer to second Message-ID: <20131112163718.60dbbf0e@X220.ovitrap.com> In-Reply-To: References: X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 08:37:29 -0000 Hi, On Tue, 12 Nov 2013 13:54:25 +0530 swapnil vaidya wrote: > Hi All, > I have 2 linux machine. you might be on the wrong mailing list. This here is for FreeBSD. > I have compiled apache 2.4.6 on one of the linux machine with > following commands: > ./configure --prefix=/usr/apache--with-ssl=/usr/local/ssl --enable-ssl > --enable-modules="all" --enable-mods-shared="most" > make > make install > > This has installed apache on this machine and it works fine. > However when i copy this apache (where it got installed) folder on > other linux machine. > I am getting following error while starting httpd with following > commad: command: > httpd -k start > > error: > > /httpd: symbol lookup error: /usr/papache/lib/libapr-1.so.0: undefined > symbol: dlopen > > Can you please help me to understand what is going wrong. It looks really strange to me. Erich From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 09:16:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F4230721; Tue, 12 Nov 2013 09:16:27 +0000 (UTC) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AC0DF2BD1; Tue, 12 Nov 2013 09:16:27 +0000 (UTC) Received: by mail-qc0-f170.google.com with SMTP id n9so5097930qcw.1 for ; Tue, 12 Nov 2013 01:16:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=EfQhv53oWCc33jHH8gkqNXbrytLakkLyf54xoeqES+Y=; b=Na57bdFudnbHSg7QBsh6AlsG164uTGsd1yNme9ryYX2X1PkchVJA/Srg8dbwSEJD5D zopGxc2gpGAgD91nvrK/4K0LoomSXMDh85GwJa8K93bUYR+ogY6aFLbtlBqS08J1SFXi wp9VtMbb82+xKH/TR644o5XTCS8KTDBHz27MDdpnYXthpT6/UYbDNbyKnosLT5iXMgho 8mCmYc2zBw5u9CWq1uWA7muhujoOa5HA2XraAREyYoWmFBdybcqJIBGXKABbyGuvG03e 6qUetFDH2TcdWZhH2GIXVNwWVhIROLqkpWVErHiOPbO5MHlN4z+O1LCaTDOtYP3KGw/0 fWcg== MIME-Version: 1.0 X-Received: by 10.49.50.38 with SMTP id z6mr32623268qen.30.1384247786870; Tue, 12 Nov 2013 01:16:26 -0800 (PST) Received: by 10.96.180.233 with HTTP; Tue, 12 Nov 2013 01:16:26 -0800 (PST) Date: Tue, 12 Nov 2013 11:16:26 +0200 Message-ID: Subject: freebsd-version(1) enchancement From: Kimmo Paasiala To: FreeBSD current , des@FreeBSD.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 09:16:28 -0000 I didn't even know this tool existed before tried to complete freebsd- today, very nice. Would it make sense to also include the svnversion(1) of the system sources in the version output? Maybe with a separate option (-u perhaps?) if it's not ok to change the meaning of -k and -u options anymore. -Kimmo From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 09:32:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF02BDC9; Tue, 12 Nov 2013 09:32:24 +0000 (UTC) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 853DD2CDA; Tue, 12 Nov 2013 09:32:24 +0000 (UTC) Received: by mail-qc0-f170.google.com with SMTP id n9so5106256qcw.1 for ; Tue, 12 Nov 2013 01:32:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=rRgn1ZqE6o9kCqV9l3EzTA6RZmhuUuHcSjmENdVsvdw=; b=ksA/AoZ+8zLglhHz7yMyTLIys59A+tN2xxc4MyWsdTU9UzOP/A1D6MRXfZtGePc1Zo aEuBz8Xm1RbG4BCjTeHpwXOO/uU81vTSb6Rvdfm9rZz/FgL4SCv4Nz4/Gwir7aysqthi i1qPuT/JC7s2c/TmqQDgZFHO1wPQ8nAeIZBpcWW+5iU6fEEkE1iffGFl6ITA5BNLxKyO eMpDa4qpm4FDbVONHw6klqUddpoDSsZEioyL61Vbul6j75XgkvtmAKf6rDh8FbT8Di9z atjuF6CjJEUf9QFVyfgd3xqoFgDSPPzIfjWBhnz0y8phlvrkAx9druiL0W0/raAyxZVX CoCw== MIME-Version: 1.0 X-Received: by 10.49.50.38 with SMTP id z6mr32713151qen.30.1384248743752; Tue, 12 Nov 2013 01:32:23 -0800 (PST) Received: by 10.96.180.233 with HTTP; Tue, 12 Nov 2013 01:32:23 -0800 (PST) In-Reply-To: References: Date: Tue, 12 Nov 2013 11:32:23 +0200 Message-ID: Subject: Re: freebsd-version(1) enchancement From: Kimmo Paasiala To: FreeBSD current , des@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 09:32:24 -0000 On Tue, Nov 12, 2013 at 11:16 AM, Kimmo Paasiala wrote: > I didn't even know this tool existed before tried to complete > freebsd- today, very nice. > > Would it make sense to also include the svnversion(1) of the system > sources in the version output? Maybe with a separate option (-u > perhaps?) if it's not ok to change the meaning of -k and -u options > anymore. > > -Kimmo Woops... I just noticed freebsd-version is nothing but a shell script. In that case could the svnversion(1) information be included in the loader(8) binary? There's already a timestamp in it like this: # strings /boot/loader | grep -A2 "bootstrap loader" FreeBSD/x86 bootstrap loader Sat Nov 9 15:29:40 EET 2013 toor@freebsd10.rdnzl.info -Kimmo From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 09:43:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0EE28235; Tue, 12 Nov 2013 09:43:38 +0000 (UTC) Received: from mailrelay010.isp.belgacom.be (mailrelay010.isp.belgacom.be [195.238.6.177]) by mx1.freebsd.org (Postfix) with ESMTP id 771942D85; Tue, 12 Nov 2013 09:43:37 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApYGAH33gVJbsLPN/2dsb2JhbABZgwfAJ4EqF3SCJQEBBTocIxALGAklDyoeGYdvAxMBvj2MbYJyBxaEGwOYDpILgyc7 Received: from 205.179-176-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.176.179.205]) by relay.skynet.be with ESMTP; 12 Nov 2013 10:43:26 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.7/8.14.7) with ESMTP id rAC9hOot002095; Tue, 12 Nov 2013 10:43:25 +0100 (CET) (envelope-from tijl@coosemans.org) Date: Tue, 12 Nov 2013 10:43:23 +0100 From: Tijl Coosemans To: dt71@gmx.com Subject: Re: new Xorg (KMS, etc.) for Radeon 9600 Message-ID: <20131112104323.6fa5facd@kalimero.tijl.coosemans.org> In-Reply-To: <52816980.8000200@gmx.com> References: <527F95BE.7080908@gmx.com> <527FC05D.8080703@gmx.com> <20131111100707.481d2fbf@kalimero.tijl.coosemans.org> <52816980.8000200@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 09:43:38 -0000 On Tue, 12 Nov 2013 00:34:24 +0100 dt71@gmx.com wrote: > Tijl Coosemans wrote, On 11/11/2013 10:07: >> On Sun, 10 Nov 2013 18:20:29 +0100 dt71@gmx.com wrote: >>> error: [drm:pid667:r100_cp_init_microcode] *ERROR* radeon_cp: Failed to load firmware "radeonkmsfw_R300_cp" >> >> Make sure you have /boot/kernel/radeonkmsfw_R300_cp.ko. > > Oops, my bad. I had WITHOUT_SOURCELESS=1 in /etc/src.conf. > > Now the said 3D application works, though the performance is crappier > than with the old Xorg... That could be because of this: info: [drm] Detected VRAM RAM=256M, BAR=256M info: [drm] RAM width 128bits DDR [TTM] Zone kernel: Available graphics memory: 257392 kiB [TTM] Initializing pool allocator info: [drm] radeon: 128M of VRAM memory ready info: [drm] radeon: 0M of GTT memory ready. info: [drm] radeon: 1 quad pipes, 1 Z pipes initialized. drmn0: warning: (-12) create WB bo failed drmn0: error: Disabling GPU acceleration info: [drm] radeon: cp finalized info: [drm] radeon: cp finalized [TTM] Finalizing pool allocator [TTM] Zone kernel: Used memory at exit: 0 kiB info: [drm] radeon: ttm finalized info: [drm] Forcing AGP to PCI mode It fails to use AGP. I have the same problem. From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 09:56:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9EE3D78E for ; Tue, 12 Nov 2013 09:56:01 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 6358D2E63 for ; Tue, 12 Nov 2013 09:56:01 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 72104648B; Tue, 12 Nov 2013 09:56:00 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 973351D7E; Tue, 12 Nov 2013 10:56:04 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Kimmo Paasiala Subject: Re: freebsd-version(1) enchancement References: Date: Tue, 12 Nov 2013 10:56:04 +0100 In-Reply-To: (Kimmo Paasiala's message of "Tue, 12 Nov 2013 11:16:26 +0200") Message-ID: <861u2mj64r.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 09:56:01 -0000 Kimmo Paasiala writes: > Would it make sense to also include the svnversion(1) of the system > sources in the version output? No. It is not available in the most important use case for freebsd-version(1), i.e. freebsd-update builds. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 11:13:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 12C0A32D; Tue, 12 Nov 2013 11:13:26 +0000 (UTC) Received: from mail.droso.net (koala.droso.dk [IPv6:2a01:4f8:a0:7163::2]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C61CB2364; Tue, 12 Nov 2013 11:13:25 +0000 (UTC) Received: by mail.droso.net (Postfix, from userid 1001) id 6E0D9EA5; Tue, 12 Nov 2013 12:13:23 +0100 (CET) Date: Tue, 12 Nov 2013 12:13:23 +0100 From: Erwin Lansing To: George Kontostanos Subject: Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf Message-ID: <20131112111322.GV90670@droso.dk> References: <20131103220654.GU52889@FreeBSD.org> <6AA4A8E1-CBCE-4C87-A320-BB08EC76715F@lassitu.de> <20131104083443.GZ52889@FreeBSD.org> <2B21E123-23BA-4E07-B9DD-9DE1CDE40D08@FreeBSD.org> <20131104163457.GJ52889@FreeBSD.org> <868B00D6-101A-4B17-995F-A3E2AFE41908@lansing.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <868B00D6-101A-4B17-995F-A3E2AFE41908@lansing.dk> X-Operating-System: FreeBSD/amd64 9.1-RELEASE User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Release Engineering Team , Stefan Bethke , FreeBSD Current , Gleb Smirnoff , freebsd-stable , Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , =?iso-8859-1?Q?=D6zkan?= KIRIK X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 11:13:26 -0000 On Wed, Nov 06, 2013 at 02:59:15PM +0100, Erwin Lansing wrote: > >> E> > > >> E> > Erwin, can you please handle that? > >> E> > >> E> Things are much worse that this, the ports are completely written under the assumption that there is a Bind in base, which of course would already break with WITHOUT_BIND before Bind was completely removed. It will be hard to fix without breaking the installed base of 8 and 9. Sigh. > >> E> > >> E> I'll try to work on it this week, but unfortunately have a full schedule of meetings and travel as well. > > > > Suggestion. An option to install the rc script would solve that problem. > > > > If only it was that simple, it would have been done a long time ago. As Gleb points out, the ports are broken by design. The rc script needs a complete rewrite, and that's only after fixing all configuration files, setting up chroot, etc etc and all that while not breaking the installed base on 8 and 9. I spent most of yesterday on this and if I'm lucky, I'm halfway through. > Sorry about the delay, but I did finally update all three dns/bind9* ports today. I have dropped the complicated chroot, and related symlinking, logic from the default rc script as I don't think that is the right place to implement things. I would recommend users who want the extra security to use jail(8) instead of a mere chroot. This change should not affect the installed base of FreeBSD 9.x and earlier systems, but new installations there should note that the symlink option is no longer turned on by default, but still supported. I tested some default cases, but by no means can test every corner case, so please let me know how this works out. Best, Erwin From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 11:49:08 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7F4ED0C for ; Tue, 12 Nov 2013 11:49:08 +0000 (UTC) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9E104253B for ; Tue, 12 Nov 2013 11:49:08 +0000 (UTC) Received: by mail-qc0-f170.google.com with SMTP id n9so5090073qcw.15 for ; Tue, 12 Nov 2013 03:49:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=q79JSk7lArVxkiIUGDlsgfZ2f1WcsBTT/EGtoz84yH4=; b=gev5x8ysQQFtWXVawlDWyV+LR5ujEm43owt1Qlu6ifTVbrADqccMbJg+AhcQuqMoxV hS8zwZPy+BXhVKem6Q1FL/zShX//yg35QoyoslUOeV1CkQB0JYM6WS0GMt15MgHbnN4o q6bSBihv72CbjQgvIor9btEG5P4apjuLOZSlYEVYGMNb5jbj+ULwNtUdSN21liLspot+ N/pQ2JPvYHh2upXEsLfh11jzCGDtJldLUjiuZRnneY1mGhB1oKzRrUj8M5zft1nreZDU SZMn6ai0uLjMHSyzEjNMijiek4HWs15RvBjQDksNxAP13z4T6pEHRb19C5conzrM0xKw RfbQ== MIME-Version: 1.0 X-Received: by 10.224.129.202 with SMTP id p10mr57463408qas.84.1384256947861; Tue, 12 Nov 2013 03:49:07 -0800 (PST) Received: by 10.96.180.233 with HTTP; Tue, 12 Nov 2013 03:49:07 -0800 (PST) In-Reply-To: <861u2mj64r.fsf@nine.des.no> References: <861u2mj64r.fsf@nine.des.no> Date: Tue, 12 Nov 2013 13:49:07 +0200 Message-ID: Subject: Re: freebsd-version(1) enchancement From: Kimmo Paasiala To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 11:49:08 -0000 On Tue, Nov 12, 2013 at 11:56 AM, Dag-Erling Sm=C3=B8rgrav wro= te: > Kimmo Paasiala writes: >> Would it make sense to also include the svnversion(1) of the system >> sources in the version output? > > No. It is not available in the most important use case for > freebsd-version(1), i.e. freebsd-update builds. > > DES > -- > Dag-Erling Sm=C3=B8rgrav - des@des.no I didn't express myself well enough I guess. What I'm after is inclusion of the svnversion(1) information to a binary that gets always built and installed as part of 'make buildworld/installworld' regardless of src.conf(5) settings so that it would be possible to identify the SVN version where the currently installed world comes from. Now that I think loader(8) is not a good candidate for that because of WITHOUT_BOOT. I was hoping that freebsd-version would be such binary but since it's only a shell script that extracts the information from various binaries it won't work unless those other binaries have that information included in them. -Kimmo From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 11:55:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5007BB for ; Tue, 12 Nov 2013 11:55:39 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 784AF25B8 for ; Tue, 12 Nov 2013 11:55:39 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 4309965BF; Tue, 12 Nov 2013 11:55:38 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 6D13D1E06; Tue, 12 Nov 2013 12:55:42 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Kimmo Paasiala Subject: Re: freebsd-version(1) enchancement References: <861u2mj64r.fsf@nine.des.no> Date: Tue, 12 Nov 2013 12:55:42 +0100 In-Reply-To: (Kimmo Paasiala's message of "Tue, 12 Nov 2013 13:49:07 +0200") Message-ID: <86siv1j0ld.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 11:55:39 -0000 Kimmo Paasiala writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Kimmo Paasiala writes: > > > Would it make sense to also include the svnversion(1) of the > > > system sources in the version output? > > No. It is not available in the most important use case for > > freebsd-version(1), i.e. freebsd-update builds. > I didn't express myself well enough I guess. I understood you perfectly, but the svn revision number is not available to the freebsd-update build, nor to users who build from a git checkout. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 12:02:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A826C295; Tue, 12 Nov 2013 12:02:11 +0000 (UTC) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 21BF7262F; Tue, 12 Nov 2013 12:02:10 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id m19so3588633wiv.2 for ; Tue, 12 Nov 2013 04:02:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6Bk0ru8mNIbblAnlFvf70j2B0LNOTAQJ5U78rZfdfaE=; b=HHwyx2R4uKWtaB+gSESeq3JIZtirmjEA6Cu3BH8vPoXwVfPDLQKnP1b8xyJTYIrY6u dTM9m2kFO4ykMgdcLxHeTgzX6mK/tm1mf6ya1cdJsXJCa0o+WZg3agOX6PWMHHVgGQlg E0mzwA9T/3qTjEzXCJ3JJ+sBar+LFgCC0FFxdYDoI5RjkThYSekt0yp0VBlVQW3wekuf 7nrwmrC4ikKeB4Lb+5Xa8V45zbJiPTYuCuasUQfVyAPNXMbSEL6Nso/7Q5dujKaN0e6c vOz+D4NKUgXfUT7QeKlxW2LvyugRAy3SKJS07ZVK7GWMwWN+WbwXM7BPb33NCZ4daf1a TsuA== X-Received: by 10.194.235.138 with SMTP id um10mr26978053wjc.30.1384257729595; Tue, 12 Nov 2013 04:02:09 -0800 (PST) Received: from [192.168.1.129] ([193.173.55.180]) by mx.google.com with ESMTPSA id ma3sm43792782wic.1.2013.11.12.04.02.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Nov 2013 04:02:08 -0800 (PST) Message-ID: <528218C2.1010106@gmail.com> Date: Tue, 12 Nov 2013 13:02:10 +0100 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Devin Teske Subject: Re: [CFT] bsdinstall and zfsboot enhancements References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 12:02:11 -0000 Teske, Devin schreef: > Hi all, > > Another Call For Testing... > This one is for bsdinstall. > > Two patchsets are required for this CFT: > > http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_debug/ > http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ > > The enhancements are: > > + Add a `-D FILE" command-line option for overriding the > path to the bsdinstall log file (BSDINSTALL_LOG env var). > > + Document new `-D FILE' in the man page for bsdinstall. > > + If FILE in `-D FILE' begins with a +, debug output goes to > stdout (interleaved between dialog(1) invocations/output) as > well as to FILE (minus the leading + of course). > > + If BSDINSTALL_LOG cannot be written, then debugging is > disabled (except in the case of a leading + in the pathname, > wherein debug will still be printed to stdout). > > + Update source code format to approximate a future shstyle(9) > > + Fix a dangling participle ("Begun ..." -> "Began ...") > > + Rewrite the docsinstall script (was necessary to abate direct > dependency on BSDINSTALL_LOG (instead, use fault-tolerant > bsdconfig framework which displays appropriate errors for > package management). > > + Add additional debug output for dhclient/rtsol/wpa_cliscan > > + Display script errors in a textbox rather than just on stdout > > + Update many coments. > > + Add new f_show_err() API call (like f_show_msg but changes > the dialog title to "Error")(see bsdconfig's `common.subr'). > > + Add new f_eval_catch() API call for executing a command via > eval but not before logging the command to debug. Several > example cases documented in API header for function in > bsdconfig's `common.subr'. > > + Fix dialog auto-sizing when launched as an rvalue to a pipe > for indirected scripts (previously would default to 80x24 sizing > in this case, now it can autosize to full size even when in a pipe > chain). > > + Fix a bug in f_snprintf wherein if the $format argument began > with a "-" or "--" it would be misinterpreted as a flag to printf. (this > is in bsdcofig's strings.subr) > > + Add accompanying f_sprintf() and f_vsprintf() to go along with > already existing f_snprintf() and f_vsnprintf() (see bsdconfig's > strings.subr). > > + Update bsdinstall's "config" script to adjust ttyu* entries in > /etc/ttys when it is determined that we are in-fact doing an install > over serial (e.g. bhyve). > > + Remove some unnecessary default ZFS datasets from the > automatic "zfsboot" script. Such as: /usr/ports/distfiles > /usr/ports/packages /usr/obj /var/db /var/empty /var/mail and > /var/run (these can all be created as-needed once the system is > installed). > > + Remove setuid=off for /usr/home (as discussed with others from > last round of CFT). > > + Fix some i18n string violations in "zfsboot" > > + Bolster debugging output in "zfsboot" > > + Fix some string quoting issues in "zfsboot" > > + Fix some variable scope issues in "zfsboot" > > + Only display the ZFS vdev type selection menu when running > interactively (duh). > > + Change "Create" to "Install" in "zfsboot" main menu > > + Increase pedantic error checking in "zfsboot" (type-check > arguments and such). > > + Add a call to "graid destroy" to kill automatic metadata (part of > the series of pedantic destructions we do when bootstrapping > a new/naked disk). > > + Make judicious use of new f_eval_catch() in "zfsboot" > > + More comments (zfsboot). > > + Fixup some variable names for consistency (zfsboot). > I did not try this installer myself, but one question, can i seperate the swap space from the pool? I have seen to many strange hangs on a server where i use swap on zfs! regards Johan From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 12:48:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B6778129; Tue, 12 Nov 2013 12:48:37 +0000 (UTC) Received: from mail.neelc.org (maya.neelc.org [72.0.227.50]) by mx1.freebsd.org (Postfix) with ESMTP id 918612959; Tue, 12 Nov 2013 12:48:37 +0000 (UTC) Received: from mail.neelc.org (maya.neelc.org [72.0.227.50]) by mail.neelc.org (Postfix) with ESMTPA id 96F3D1186F9A; Tue, 12 Nov 2013 07:48:36 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 12 Nov 2013 07:48:36 -0500 From: Neel Chauhan To: Konstantin Belousov Subject: Re: [PATCH] Haswell Kernel Mode Setting Mail-Reply-To: neel@neelc.org In-Reply-To: <20131112082932.GU59496@kib.kiev.ua> References: <52816A9A.4050305@delphij.net> <20131112082932.GU59496@kib.kiev.ua> Message-ID: <8f255aa45ade695995d53eafd939d35e@mail.neelc.org> X-Sender: neel@neelc.org User-Agent: Roundcube Webmail/0.9.5 X-Mailman-Approved-At: Tue, 12 Nov 2013 12:54:41 +0000 Cc: freebsd-x11@freebsd.org, freebsd-current@freebsd.org, d@delphij.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list Reply-To: neel@neelc.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 12:48:37 -0000 On 2013-11-12 03:29, Konstantin Belousov wrote: > On Mon, Nov 11, 2013 at 03:39:06PM -0800, Xin Li wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> On 11/11/13 14:29, Neel Chauhan wrote: >> > Sorry if I sent a similar patch before. It didn't get accepted so I >> > am sending one now. Enjoy. >> >> What does "didn't get accepted" mean? :) Since this looks like a >> PCI-ID only change that do not affect other existing hardware, if it's >> not an explicit objection from a reviewer, I think it's Okay to just >> go ahead and commit the change after a reasonable timeout instead of >> waiting indefinitely. > > I very much doubt that this patch works. More, I believe that it was > not tested at all. Talking about the trivially obvious things, the PGTT > handling must be updated since page tables have different format > comparing > with Ivy, there are some changes to ring dispatching, and lot of > changes in the display pipeline. All this is missing from the patch. > > Oh, and the Series 8 chipset PCH detection is missing. I probably > should stop now. > > HSW support is much more than just adding the Ids, I am (slowly) > starting > the work on importing the Linux updates. Konstantin, Thanks for telling me. The reality is, I don't really know about the insides of the FreeBSD kernel, Linux, or drm. I just looked at a few files. I should really get a book about FreeBSD before trying to send patches again. And anyways, this patch is untested. I was in a rush to send it to the mailing list, hoping it would get accepted. Thanks, Neel From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 16:32:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B74297DD for ; Tue, 12 Nov 2013 16:32:25 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 813012A42 for ; Tue, 12 Nov 2013 16:32:25 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id rACGWJUu002846 for ; Tue, 12 Nov 2013 08:32:19 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id rACGWJsk002845 for freebsd-current@freebsd.org; Tue, 12 Nov 2013 08:32:19 -0800 (PST) (envelope-from sgk) Date: Tue, 12 Nov 2013 08:32:19 -0800 From: Steve Kargl To: freebsd-current@freebsd.org Subject: Are clang++ and libc++ compatible? Message-ID: <20131112163219.GA2834@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:32:25 -0000 Trying to build news/pan with clang++ dies with gmake[3]: Entering directory `/usr/ports/news/pan/work/pan-0.139/pan/general' CXX file-util.o In file included from file-util.cc:38: In file included from ./log.h:26: /usr/include/c++/v1/deque:907:49: error: invalid application of 'sizeof' to an incomplete type 'value_type' (aka 'pan::Log::Entry') static const difference_type __block_size = sizeof(value_type) < 256 ? 4... Anyone know how to fix either clang++ or libc++? -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 16:38:28 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 479539AC for ; Tue, 12 Nov 2013 16:38:28 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 19BEA2AA8 for ; Tue, 12 Nov 2013 16:38:27 +0000 (UTC) Received: from c120.sec.cl.cam.ac.uk (c120.sec.cl.cam.ac.uk [128.232.18.120]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id rACGcIrN009867 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 12 Nov 2013 16:38:19 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Are clang++ and libc++ compatible? From: David Chisnall In-Reply-To: <20131112163219.GA2834@troutmask.apl.washington.edu> Date: Tue, 12 Nov 2013 16:38:17 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> References: <20131112163219.GA2834@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.1508) Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:38:28 -0000 On 12 Nov 2013, at 16:32, Steve Kargl = wrote: > Trying to build news/pan with clang++ dies with >=20 > gmake[3]: Entering directory = `/usr/ports/news/pan/work/pan-0.139/pan/general' > CXX file-util.o > In file included from file-util.cc:38: > In file included from ./log.h:26: > /usr/include/c++/v1/deque:907:49: error: invalid application of = 'sizeof' to an > incomplete type 'value_type' (aka 'pan::Log::Entry') > static const difference_type __block_size =3D sizeof(value_type) < = 256 ? 4... >=20 > Anyone know how to fix either clang++ or libc++? The error here does not appear to be in clang or libc++, but in the use = by the thing that you are compiling. This is saying that you have tried to create a = std::dequeu, but pan::Log::Entry is a forward = declaration and so the template instantiation fails. The fix is to move the definition of pan::Log::Entry such that it is = visible at the time of its use. David From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 16:54:23 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 038A9115; Tue, 12 Nov 2013 16:54:23 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D98412C1F; Tue, 12 Nov 2013 16:54:22 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id rACGsM9l003000; Tue, 12 Nov 2013 08:54:22 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id rACGsMZM002999; Tue, 12 Nov 2013 08:54:22 -0800 (PST) (envelope-from sgk) Date: Tue, 12 Nov 2013 08:54:22 -0800 From: Steve Kargl To: David Chisnall Subject: Re: Are clang++ and libc++ compatible? Message-ID: <20131112165422.GA2939@troutmask.apl.washington.edu> References: <20131112163219.GA2834@troutmask.apl.washington.edu> <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:54:23 -0000 On Tue, Nov 12, 2013 at 04:38:17PM +0000, David Chisnall wrote: > On 12 Nov 2013, at 16:32, Steve Kargl wrote: > >> Trying to build news/pan with clang++ dies with >> >> gmake[3]: Entering directory `/usr/ports/news/pan/work/pan-0.139/pan/general' >> CXX file-util.o >> In file included from file-util.cc:38: >> In file included from ./log.h:26: >> /usr/include/c++/v1/deque:907:49: error: invalid application of 'sizeof' to an >> incomplete type 'value_type' (aka 'pan::Log::Entry') >> static const difference_type __block_size = sizeof(value_type) < 256 ? 4... >> >> Anyone know how to fix either clang++ or libc++? > > The error here does not appear to be in clang or libc++, but in the > use by the thing that you are compiling. > This is saying that you have tried to create a std::dequeu, > but pan::Log::Entry is a forward declaration and so the template > instantiation fails. > The fix is to move the definition of pan::Log::Entry such that it > is visible at the time of its use. > I don't know C++, but it is at all like C, then the header files are normally placed at the top of a file before one's code. In this case, the code in news/pan/work/pan-0.139/pan/general/log.h looks like (where I've striped comment to keep it short) #ifndef __Log_h__ #define __Log_h__ #include #include #include #include namespace pan { class Log { public: enum Severity { PAN_SEVERITY_INFO = 1, PAN_SEVERITY_ERROR = 2, PAN_SEVERITY_URGENT = (1<<10) }; struct Entry { time_t date; Severity severity; std::deque messages; std::string message; bool is_child; Entry() : is_child(false) { } }; void add_entry(Entry& e, std::deque& list); Are you saying that I need to move '#include ' to the location above the 'void add_entry(...)' line? -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 17:10:03 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD5696CF for ; Tue, 12 Nov 2013 17:10:03 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 870A42D7F for ; Tue, 12 Nov 2013 17:10:03 +0000 (UTC) Received: from [192.168.0.2] (cpc27-cmbg15-2-0-cust235.5-4.cable.virginm.net [86.27.188.236]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id rACHA0UX010014 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 12 Nov 2013 17:10:02 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Are clang++ and libc++ compatible? From: David Chisnall In-Reply-To: <20131112165422.GA2939@troutmask.apl.washington.edu> Date: Tue, 12 Nov 2013 17:09:54 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <48CC87B2-C2D2-44F8-A7DE-4D870E68E7D9@FreeBSD.org> References: <20131112163219.GA2834@troutmask.apl.washington.edu> <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.1508) Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 17:10:03 -0000 On 12 Nov 2013, at 16:54, Steve Kargl = wrote: > On Tue, Nov 12, 2013 at 04:38:17PM +0000, David Chisnall wrote: >> On 12 Nov 2013, at 16:32, Steve Kargl = wrote: >>=20 >>> Trying to build news/pan with clang++ dies with >>>=20 >>> gmake[3]: Entering directory = `/usr/ports/news/pan/work/pan-0.139/pan/general' >>> CXX file-util.o >>> In file included from file-util.cc:38: >>> In file included from ./log.h:26: >>> /usr/include/c++/v1/deque:907:49: error: invalid application of = 'sizeof' to an >>> incomplete type 'value_type' (aka 'pan::Log::Entry') >>> static const difference_type __block_size =3D sizeof(value_type) < = 256 ? 4... >>>=20 >>> Anyone know how to fix either clang++ or libc++? >>=20 >> The error here does not appear to be in clang or libc++, but in the >> use by the thing that you are compiling. >> This is saying that you have tried to create a = std::dequeu, >> but pan::Log::Entry is a forward declaration and so the template >> instantiation fails. >> The fix is to move the definition of pan::Log::Entry such that it >> is visible at the time of its use. >>=20 >=20 > I don't know C++, but it is at all like C, then the header files > are normally placed at the top of a file before one's code. Yes, that's normal in C++ too. > In > this case, the code in news/pan/work/pan-0.139/pan/general/log.h > looks like (where I've striped comment to keep it short) >=20 > #ifndef __Log_h__ > #define __Log_h__ >=20 > #include > #include > #include > #include >=20 > namespace pan > { > class Log > { > public: > enum Severity { > PAN_SEVERITY_INFO =3D 1, > PAN_SEVERITY_ERROR =3D 2, > PAN_SEVERITY_URGENT =3D (1<<10) > }; >=20 > struct Entry { > time_t date; > Severity severity; > std::deque messages; > std::string message; > bool is_child; > Entry() : is_child(false) { } > }; >=20 > void add_entry(Entry& e, std::deque& list); >=20 >=20 > Are you saying that I need to move '#include ' to > the location above the 'void add_entry(...)' line? No, I'm saying that the definition of struct Entry needs to be complete = before its use in the specialisation of std::deque. =20 I'd perhaps be able to be more helpful if you hadn't removed from the = error message the part that tells you where the error actually is... David From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 17:38:00 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25BC85CD; Tue, 12 Nov 2013 17:38:00 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D80BA2805; Tue, 12 Nov 2013 17:37:59 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::d18c:20bf:ce3b:e453] (unknown [IPv6:2001:7b8:3a7:0:d18c:20bf:ce3b:e453]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id C4BBC5C43; Tue, 12 Nov 2013 18:37:48 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_2303F7FD-863D-41F9-A151-3A02CD1681E1"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: Are clang++ and libc++ compatible? From: Dimitry Andric In-Reply-To: <20131112165422.GA2939@troutmask.apl.washington.edu> Date: Tue, 12 Nov 2013 18:37:39 +0100 Message-Id: References: <20131112163219.GA2834@troutmask.apl.washington.edu> <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.1822) Cc: freebsd-current@FreeBSD.org, David Chisnall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 17:38:00 -0000 --Apple-Mail=_2303F7FD-863D-41F9-A151-3A02CD1681E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 12 Nov 2013, at 17:54, Steve Kargl = wrote: ... > namespace pan > { > class Log > { > public: > enum Severity { > PAN_SEVERITY_INFO =3D 1, > PAN_SEVERITY_ERROR =3D 2, > PAN_SEVERITY_URGENT =3D (1<<10) > }; >=20 > struct Entry { > time_t date; > Severity severity; > std::deque messages; > std::string message; > bool is_child; > Entry() : is_child(false) { } > }; I think the problem is that the code tries to use std::deque as a member of struct Entry, before it is completely defined. This is not allowed by the standard, although some libraries (e.g. GNU libstdc++) apparently permit it for some container types. You could try to work around it with -fdelayed-template-parsing, but I am not sure if it will help. Alternatively, compile the code with libstdc++, or rewrite it to conform. :-) -Dimitry --Apple-Mail=_2303F7FD-863D-41F9-A151-3A02CD1681E1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlKCZ2oACgkQsF6jCi4glqOBiQCg/HJ9zP7erIqE0yLAZ1N6UR7j ZNoAn0mG05UT9+8uKBZJBljupGe25Grm =ZDEJ -----END PGP SIGNATURE----- --Apple-Mail=_2303F7FD-863D-41F9-A151-3A02CD1681E1-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 17:55:57 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B6105BAC; Tue, 12 Nov 2013 17:55:57 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7C4282940; Tue, 12 Nov 2013 17:55:57 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id rACHtu1X003404; Tue, 12 Nov 2013 09:55:56 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id rACHtuen003403; Tue, 12 Nov 2013 09:55:56 -0800 (PST) (envelope-from sgk) Date: Tue, 12 Nov 2013 09:55:56 -0800 From: Steve Kargl To: Dimitry Andric Subject: Re: Are clang++ and libc++ compatible? Message-ID: <20131112175556.GA3319@troutmask.apl.washington.edu> References: <20131112163219.GA2834@troutmask.apl.washington.edu> <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org, David Chisnall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 17:55:57 -0000 On Tue, Nov 12, 2013 at 06:37:39PM +0100, Dimitry Andric wrote: > On 12 Nov 2013, at 17:54, Steve Kargl wrote: > > > > struct Entry { > > time_t date; > > Severity severity; > > std::deque messages; > > std::string message; > > bool is_child; > > Entry() : is_child(false) { } > > }; > > I think the problem is that the code tries to use std::deque as a > member of struct Entry, before it is completely defined. This is not > allowed by the standard, although some libraries (e.g. GNU libstdc++) > apparently permit it for some container types. > > You could try to work around it with -fdelayed-template-parsing, but I > am not sure if it will help. Alternatively, compile the code with > libstdc++, or rewrite it to conform. :-) > Thanks for the suggestions. -fdelayed-template-parsing did not help. (Un)fortunately, I know very little about C++, so rewriting the code is not option for me. I guess I'll add a USE_GCC to the port's Makefile to if it will build. -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 18:11:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9A081A6 for ; Tue, 12 Nov 2013 18:11:35 +0000 (UTC) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 78C922A4F for ; Tue, 12 Nov 2013 18:11:35 +0000 (UTC) Received: by mail-qa0-f42.google.com with SMTP id ii20so3106372qab.1 for ; Tue, 12 Nov 2013 10:11:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=V0bZC9ZWr/xnIEPQpWbrBHzUkYJ0CeMbo0xTIQN5VUQ=; b=IqqjwkxIVJKI4iCe4Wx8RkTxEHtNCmZzf+MeWuOVaCU+ZSCKUupvEjg8RAxjZJ8PBV 41NWdKPbcQX5L7K/RKavrDsxu1imAFn7IhQ/OLYrYGbZGiZkdcW8HlukvkK15TEdX3qO eSYeoo2OYxZRxRW1nCHahUjtseILaVjVN9HWA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=V0bZC9ZWr/xnIEPQpWbrBHzUkYJ0CeMbo0xTIQN5VUQ=; b=YTGVTYiCTUWBG066KR+9P9n97PYvOef6gF3O8E6XTC7/dmh+f09lwwaOxog+auTWvy B2eSaRVasT72JPB/RqyYQxS/Abn0XLMi4WOgU7OQ3AQ5JniV267udKr/IZx0Z50qvhOa HWQsQHdOmrzUGEzRqAS3ZxgZ8GKTaTN4PsYnKsbOhAY3066A1mpaycpIH1R/TGS9zegO 9S4Rt8zPZdR1as7xHUGO2C2EyBHpYtkhzT0eTEG8e3Vf8p8hPf7LmI49RJ6akL6cxFui xawBCbRVwsfiFTyHOlIoDupIQnCThlrxhhlIcMGg6YGzysG3/80AECIBNvgZ/kSjg2MI 1SRA== X-Gm-Message-State: ALoCoQlqlUOsMRA8FUT8vbGGjBcrJF5I9xDZj2K8kRo4QNLOfTrnV0442U94JASncs8735MQYW3g X-Received: by 10.224.69.132 with SMTP id z4mr60371537qai.78.1384279894590; Tue, 12 Nov 2013 10:11:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.63.101 with HTTP; Tue, 12 Nov 2013 10:11:04 -0800 (PST) In-Reply-To: <20131112165422.GA2939@troutmask.apl.washington.edu> References: <20131112163219.GA2834@troutmask.apl.washington.edu> <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> From: Eitan Adler Date: Tue, 12 Nov 2013 13:11:04 -0500 Message-ID: Subject: Re: Are clang++ and libc++ compatible? To: Steve Kargl Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current Current , David Chisnall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 18:11:35 -0000 On Tue, Nov 12, 2013 at 11:54 AM, Steve Kargl wrote: > On Tue, Nov 12, 2013 at 04:38:17PM +0000, David Chisnall wrote: >> On 12 Nov 2013, at 16:32, Steve Kargl wrote: >> >>> Trying to build news/pan with clang++ dies with >>> >>> gmake[3]: Entering directory `/usr/ports/news/pan/work/pan-0.139/pan/general' >>> CXX file-util.o >>> In file included from file-util.cc:38: >>> In file included from ./log.h:26: >>> /usr/include/c++/v1/deque:907:49: error: invalid application of 'sizeof' to an >>> incomplete type 'value_type' (aka 'pan::Log::Entry') >>> static const difference_type __block_size = sizeof(value_type) < 256 ? 4... >>> >>> Anyone know how to fix either clang++ or libc++? >> >> The error here does not appear to be in clang or libc++, but in the >> use by the thing that you are compiling. >> This is saying that you have tried to create a std::dequeu, >> but pan::Log::Entry is a forward declaration and so the template >> instantiation fails. >> The fix is to move the definition of pan::Log::Entry such that it >> is visible at the time of its use. >> > > I don't know C++, but it is at all like C, then the header files > are normally placed at the top of a file before one's code. In > this case, the code in news/pan/work/pan-0.139/pan/general/log.h > looks like (where I've striped comment to keep it short) > > #ifndef __Log_h__ > #define __Log_h__ > > #include > #include > #include > #include > > namespace pan > { > class Log > { > public: > enum Severity { > PAN_SEVERITY_INFO = 1, > PAN_SEVERITY_ERROR = 2, > PAN_SEVERITY_URGENT = (1<<10) > }; > > struct Entry { > time_t date; > Severity severity; > std::deque messages; > std::string message; > bool is_child; > Entry() : is_child(false) { } > }; > > void add_entry(Entry& e, std::deque& list); > > > Are you saying that I need to move '#include ' to > the location above the 'void add_entry(...)' line? The problem here is that the code is trying to make a std::deque of the type Entry before Entry is fully defined. This is nearly identical to the problem in the simplified C code below: struct foo { struct foo bar; } -- Eitan Adler From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 19:11:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E04A733; Tue, 12 Nov 2013 19:11:12 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4AC252DDE; Tue, 12 Nov 2013 19:11:11 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa05.fnfis.com (8.14.5/8.14.5) with ESMTP id rACJBBxu016300 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 12 Nov 2013 13:11:11 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.152]) by LTCFISWMSGHT04.FNFIS.com ([10.132.206.15]) with mapi id 14.03.0158.001; Tue, 12 Nov 2013 13:11:09 -0600 From: "Teske, Devin" To: Johan Hendriks Subject: Re: [CFT] bsdinstall and zfsboot enhancements Thread-Topic: [CFT] bsdinstall and zfsboot enhancements Thread-Index: AQHO1/VTfN3AabWEO0qqCcwz4iQiNg== Date: Tue, 12 Nov 2013 19:11:09 +0000 Message-ID: <015FE59A-C792-48D0-B806-24D9E83050AA@fisglobal.com> References: <528218C2.1010106@gmail.com> In-Reply-To: <528218C2.1010106@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-11-12_08:2013-11-12,2013-11-12,1970-01-01 signatures=0 Cc: Devin Teske , "Teske, Devin" , FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 19:11:12 -0000 On Nov 12, 2013, at 4:02 AM, Johan Hendriks wrote: > Teske, Devin schreef: >> Hi all, >>=20 >> Another Call For Testing... >> This one is for bsdinstall. >>=20 >> Two patchsets are required for this CFT: >>=20 >> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_debug/ >> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ >>=20 >> The enhancements are: >>=20 >> + Add a `-D FILE" command-line option for overriding the >> path to the bsdinstall log file (BSDINSTALL_LOG env var). >>=20 >> + Document new `-D FILE' in the man page for bsdinstall. >>=20 >> + If FILE in `-D FILE' begins with a +, debug output goes to >> stdout (interleaved between dialog(1) invocations/output) as >> well as to FILE (minus the leading + of course). >>=20 >> + If BSDINSTALL_LOG cannot be written, then debugging is >> disabled (except in the case of a leading + in the pathname, >> wherein debug will still be printed to stdout). >>=20 >> + Update source code format to approximate a future shstyle(9) >>=20 >> + Fix a dangling participle ("Begun ..." -> "Began ...") >>=20 >> + Rewrite the docsinstall script (was necessary to abate direct >> dependency on BSDINSTALL_LOG (instead, use fault-tolerant >> bsdconfig framework which displays appropriate errors for >> package management). >>=20 >> + Add additional debug output for dhclient/rtsol/wpa_cliscan >>=20 >> + Display script errors in a textbox rather than just on stdout >>=20 >> + Update many coments. >>=20 >> + Add new f_show_err() API call (like f_show_msg but changes >> the dialog title to "Error")(see bsdconfig's `common.subr'). >>=20 >> + Add new f_eval_catch() API call for executing a command via >> eval but not before logging the command to debug. Several >> example cases documented in API header for function in >> bsdconfig's `common.subr'. >>=20 >> + Fix dialog auto-sizing when launched as an rvalue to a pipe >> for indirected scripts (previously would default to 80x24 sizing >> in this case, now it can autosize to full size even when in a pipe >> chain). >>=20 >> + Fix a bug in f_snprintf wherein if the $format argument began >> with a "-" or "--" it would be misinterpreted as a flag to printf. (this >> is in bsdcofig's strings.subr) >>=20 >> + Add accompanying f_sprintf() and f_vsprintf() to go along with >> already existing f_snprintf() and f_vsnprintf() (see bsdconfig's >> strings.subr). >>=20 >> + Update bsdinstall's "config" script to adjust ttyu* entries in >> /etc/ttys when it is determined that we are in-fact doing an install >> over serial (e.g. bhyve). >>=20 >> + Remove some unnecessary default ZFS datasets from the >> automatic "zfsboot" script. Such as: /usr/ports/distfiles >> /usr/ports/packages /usr/obj /var/db /var/empty /var/mail and >> /var/run (these can all be created as-needed once the system is >> installed). >>=20 >> + Remove setuid=3Doff for /usr/home (as discussed with others from >> last round of CFT). >>=20 >> + Fix some i18n string violations in "zfsboot" >>=20 >> + Bolster debugging output in "zfsboot" >>=20 >> + Fix some string quoting issues in "zfsboot" >>=20 >> + Fix some variable scope issues in "zfsboot" >>=20 >> + Only display the ZFS vdev type selection menu when running >> interactively (duh). >>=20 >> + Change "Create" to "Install" in "zfsboot" main menu >>=20 >> + Increase pedantic error checking in "zfsboot" (type-check >> arguments and such). >>=20 >> + Add a call to "graid destroy" to kill automatic metadata (part of >> the series of pedantic destructions we do when bootstrapping >> a new/naked disk). >>=20 >> + Make judicious use of new f_eval_catch() in "zfsboot" >>=20 >> + More comments (zfsboot). >>=20 >> + Fixup some variable names for consistency (zfsboot). >>=20 > I did not try this installer myself, but one question, can i seperate the= swap space from the pool? > I have seen to many strange hangs on a server where i use swap on zfs! >=20 If I understand correctly, it does this by default. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 19:47:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57089B7B for ; Tue, 12 Nov 2013 19:47:21 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 31473206E for ; Tue, 12 Nov 2013 19:47:20 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.108.129]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 20FFE4876C for ; Tue, 12 Nov 2013 19:47:16 +0000 (UTC) Message-ID: <528285C1.3030309@allanjude.com> Date: Tue, 12 Nov 2013 14:47:13 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: [CFT] bsdinstall and zfsboot enhancements References: <528218C2.1010106@gmail.com> <015FE59A-C792-48D0-B806-24D9E83050AA@fisglobal.com> In-Reply-To: <015FE59A-C792-48D0-B806-24D9E83050AA@fisglobal.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vqhfavdVoF9LiRao8HrDQehUNRWUsB8eu" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 19:47:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vqhfavdVoF9LiRao8HrDQehUNRWUsB8eu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-11-12 14:11, Teske, Devin wrote: > On Nov 12, 2013, at 4:02 AM, Johan Hendriks wrote: > >> Teske, Devin schreef: >>> Hi all, >>> >>> Another Call For Testing... >>> This one is for bsdinstall. >>> >>> Two patchsets are required for this CFT: >>> >>> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_debug/ >>> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ >>> >>> The enhancements are: >>> >>> + Add a `-D FILE" command-line option for overriding the >>> path to the bsdinstall log file (BSDINSTALL_LOG env var). >>> >>> + Document new `-D FILE' in the man page for bsdinstall. >>> >>> + If FILE in `-D FILE' begins with a +, debug output goes to >>> stdout (interleaved between dialog(1) invocations/output) as >>> well as to FILE (minus the leading + of course). >>> >>> + If BSDINSTALL_LOG cannot be written, then debugging is >>> disabled (except in the case of a leading + in the pathname, >>> wherein debug will still be printed to stdout). >>> >>> + Update source code format to approximate a future shstyle(9) >>> >>> + Fix a dangling participle ("Begun ..." -> "Began ...") >>> >>> + Rewrite the docsinstall script (was necessary to abate direct >>> dependency on BSDINSTALL_LOG (instead, use fault-tolerant >>> bsdconfig framework which displays appropriate errors for >>> package management). >>> >>> + Add additional debug output for dhclient/rtsol/wpa_cliscan >>> >>> + Display script errors in a textbox rather than just on stdout >>> >>> + Update many coments. >>> >>> + Add new f_show_err() API call (like f_show_msg but changes >>> the dialog title to "Error")(see bsdconfig's `common.subr'). >>> >>> + Add new f_eval_catch() API call for executing a command via >>> eval but not before logging the command to debug. Several >>> example cases documented in API header for function in >>> bsdconfig's `common.subr'. >>> >>> + Fix dialog auto-sizing when launched as an rvalue to a pipe >>> for indirected scripts (previously would default to 80x24 sizing >>> in this case, now it can autosize to full size even when in a pipe >>> chain). >>> >>> + Fix a bug in f_snprintf wherein if the $format argument began >>> with a "-" or "--" it would be misinterpreted as a flag to printf. (t= his >>> is in bsdcofig's strings.subr) >>> >>> + Add accompanying f_sprintf() and f_vsprintf() to go along with >>> already existing f_snprintf() and f_vsnprintf() (see bsdconfig's >>> strings.subr). >>> >>> + Update bsdinstall's "config" script to adjust ttyu* entries in >>> /etc/ttys when it is determined that we are in-fact doing an install >>> over serial (e.g. bhyve). >>> >>> + Remove some unnecessary default ZFS datasets from the >>> automatic "zfsboot" script. Such as: /usr/ports/distfiles >>> /usr/ports/packages /usr/obj /var/db /var/empty /var/mail and >>> /var/run (these can all be created as-needed once the system is >>> installed). >>> >>> + Remove setuid=3Doff for /usr/home (as discussed with others from >>> last round of CFT). >>> >>> + Fix some i18n string violations in "zfsboot" >>> >>> + Bolster debugging output in "zfsboot" >>> >>> + Fix some string quoting issues in "zfsboot" >>> >>> + Fix some variable scope issues in "zfsboot" >>> >>> + Only display the ZFS vdev type selection menu when running >>> interactively (duh). >>> >>> + Change "Create" to "Install" in "zfsboot" main menu >>> >>> + Increase pedantic error checking in "zfsboot" (type-check >>> arguments and such). >>> >>> + Add a call to "graid destroy" to kill automatic metadata (part of >>> the series of pedantic destructions we do when bootstrapping >>> a new/naked disk). >>> >>> + Make judicious use of new f_eval_catch() in "zfsboot" >>> >>> + More comments (zfsboot). >>> >>> + Fixup some variable names for consistency (zfsboot). >>> >> I did not try this installer myself, but one question, can i seperate = the swap space from the pool? >> I have seen to many strange hangs on a server where i use swap on zfs!= >> > If I understand correctly, it does this by default. Yes, the zfsboot script in bsdinstall creates a raw swap partition, it does not use swap-on-zfs --=20 Allan Jude --vqhfavdVoF9LiRao8HrDQehUNRWUsB8eu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSgoXDAAoJEJrBFpNRJZKf1YcQALsuegL4Y1G8aH91omYu5SqS q44cPe/HIDE2v+k6fGrvDroQAymcSW875b5obqJQVLccFeN/cInyBVHAj4f3typZ h+WCRXHf3CfGt2ILaTsOv/AMckTocTTUqtrEkxgAW0q9UfzGOLK9E5fyGAKoZTx7 RofS3lTfVwkCQ/gSFeHtF9GwOqbEE1kf57t5g+qFhxg/EmyCVRan7kCrXZF8fl/z iJRn/XX2QDMsr4NjwlwlyzS6+juINNM3LNs6YjfGoECJSnne9CAY8nkpTZh/CA6k pSTMEgSWRmaBAUXsU6OFY1cgfXnDioMGrDr5V/UHmcnzggHHv4ewnDXRjhqPlnV0 TrwjVjSXVDc9BUsvhl9vDOykBecPtAVUSBjneKTidC1ZWF3sWw5ABe8tTBdJEoUm etVh6pk3sCnFiNFolM2lRnVeP0DzA5RxiXM1zrV4XdtaOdgeqgZsXDvHVKvSUd4J 6/DOTAxmVlWYZtbSON2z0QDnPQ4oD3MXR8sCKjECg/e2IrGh6ZPBDg2IMb4Cbmxf NqlmsbWFeRzMhPWMA7XNX8CyIf0DaJQ2KTpbAh8wkvPnJ8WyWFaR0MuIDGx0uVjE 0uhr2Efj1u6lR8HohZ+SMVuIHAK595/RUze7lmXuGh9bOuE7TZ/jNByiB9V7i93W FfoiSbpWtaiQOCLrQAO2 =J97Y -----END PGP SIGNATURE----- --vqhfavdVoF9LiRao8HrDQehUNRWUsB8eu-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 19:48:00 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 42C30CC6 for ; Tue, 12 Nov 2013 19:48:00 +0000 (UTC) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 15F892085 for ; Tue, 12 Nov 2013 19:47:59 +0000 (UTC) Received: from [209.249.190.124] (port=51204 helo=dhcp-10-2-210-27.hudson-trading.com) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VgJvF-0005lC-4b; Tue, 12 Nov 2013 14:46:49 -0500 Content-Type: multipart/signed; boundary="Apple-Mail=_182B71E1-B7B8-4992-9709-AA1737B9E9D3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: freebsd perf testing From: George Neville-Neil In-Reply-To: <0EF12A1A-401D-4EC4-8492-E7AC893470F0@kientzle.com> Date: Tue, 12 Nov 2013 14:46:53 -0500 Message-Id: References: <527C462F.9040707@elischer.org> <527F47AC.50705@freebsd.org> <2034DAAF-F264-42B7-A497-4B2CB846381A@cederstrand.dk> <0EF12A1A-401D-4EC4-8492-E7AC893470F0@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1822) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freebsd.org X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com Cc: FreeBSD current , Erik Cederstrand X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 19:48:00 -0000 --Apple-Mail=_182B71E1-B7B8-4992-9709-AA1737B9E9D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 10, 2013, at 19:22 , Tim Kientzle wrote: >=20 > On Nov 10, 2013, at 1:05 PM, Erik Cederstrand = wrote: >=20 >> Imagine being able to fetch a VirtualBox disk image for a random SVN = commit, booting it and start debugging right away.=20 >=20 > I=92ve been working on Crochet=92s support for building > VMWare images recently and have started using > that approach to iterate my dev environment > (using one VM to build a new VM instead of > upgrading in place). >=20 Sorry to come in late. All this sounds good, and I=92d like to point = out that the project has network testing hardware in place, if people want to use it for these types of = experiments. In the absence of a lab just for regression testing (which is also in the works) I=92d = suggest that prototyping be done here: https://wiki.freebsd.org/TestClusterOnePointers Anyone who is a FreeBSD committer can get access, and those who want = access but are not yet committers should contact me so we can try to work something out. Best, George --Apple-Mail=_182B71E1-B7B8-4992-9709-AA1737B9E9D3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlKCha0ACgkQYdh2wUQKM9JU0ACfR+ZGMmhcDUFIW1EhuyhCWkCi MvkAn1R1proWQCNH4jl2llp87Flshde3 =UZ8l -----END PGP SIGNATURE----- --Apple-Mail=_182B71E1-B7B8-4992-9709-AA1737B9E9D3-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 19:48:49 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25EEEEC2; Tue, 12 Nov 2013 19:48:49 +0000 (UTC) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E98C9209D; Tue, 12 Nov 2013 19:48:48 +0000 (UTC) Received: from [209.249.190.124] (port=51204 helo=dhcp-10-2-210-27.hudson-trading.com) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VgJw8-0005lC-Gq; Tue, 12 Nov 2013 14:47:44 -0500 Content-Type: multipart/signed; boundary="Apple-Mail=_7DEF8B22-DD49-40D3-B1F9-68EEF234FB98"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: axing KAME interface ioctls From: George Neville-Neil In-Reply-To: <20131105120240.GA7577@FreeBSD.org> Date: Tue, 12 Nov 2013 14:47:48 -0500 Message-Id: <6FE2CC33-D647-436D-A40D-7BEDC25D9619@neville-neil.com> References: <20131105110114.GQ1467@FreeBSD.org> <20131105120240.GA7577@FreeBSD.org> To: Gleb Smirnoff X-Mailer: Apple Mail (2.1822) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com Cc: current@FreeBSD.org, net@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 19:48:49 -0000 --Apple-Mail=_7DEF8B22-DD49-40D3-B1F9-68EEF234FB98 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 5, 2013, at 7:02 , Gleb Smirnoff wrote: > On Tue, Nov 05, 2013 at 03:01:14PM +0400, Gleb Smirnoff wrote: > T> Hello. > T>=20 > T> Since 1999 we have got some dead code from KAME, namely support = for these > T> ioctls: > T>=20 > T> SIOCALIFADDR > T> SIOCGLIFADDR > T> SIOCDLIFADDR > T> SIOCSLIFPHYADDR > T> SIOCGLIFPHYADDR > T>=20 > T> We don not have any software in base that use (or used) them. The = ports > T> exp-run with SIOC.LIFADDR undefined didn't reveal any port that use = them. > T> I forgot to add SIOC.LIFPHYADDR to exp-run, but pretty sure these = are unused, > T> too. > T>=20 > T> What did this ioctls do? They are KAME version of SIOCAIFADDR, = and > T> SIOCSIFPHYADDR respectively. Some operating systems (at least HPUX) > T> have adopted them, and some software may use them on these systems. > T> Anyway, in FreeBSD all software always used our native ioctls. > T>=20 > T> I hope there is no objections against axing these in head/. >=20 > Patch attached. >=20 Please do. Best, George --Apple-Mail=_7DEF8B22-DD49-40D3-B1F9-68EEF234FB98 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlKCheQACgkQYdh2wUQKM9LRqgCfTxyySeTkF4lBH2CO4xIVu5nj RaMAnR/OXqQxFk06IBwHW1QyqU8Hjrhu =2hBB -----END PGP SIGNATURE----- --Apple-Mail=_7DEF8B22-DD49-40D3-B1F9-68EEF234FB98-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 19:54:46 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 454DB278; Tue, 12 Nov 2013 19:54:46 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 19174212E; Tue, 12 Nov 2013 19:54:46 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3213FB943; Tue, 12 Nov 2013 14:54:44 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: Are clang++ and libc++ compatible? Date: Tue, 12 Nov 2013 13:21:07 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <20131112163219.GA2834@troutmask.apl.washington.edu> <20131112165422.GA2939@troutmask.apl.washington.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201311121321.07330.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 12 Nov 2013 14:54:45 -0500 (EST) Cc: Eitan Adler , David Chisnall , Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 19:54:46 -0000 On Tuesday, November 12, 2013 1:11:04 pm Eitan Adler wrote: > On Tue, Nov 12, 2013 at 11:54 AM, Steve Kargl > wrote: > > On Tue, Nov 12, 2013 at 04:38:17PM +0000, David Chisnall wrote: > >> On 12 Nov 2013, at 16:32, Steve Kargl wrote: > >> > >>> Trying to build news/pan with clang++ dies with > >>> > >>> gmake[3]: Entering directory `/usr/ports/news/pan/work/pan-0.139/pan/general' > >>> CXX file-util.o > >>> In file included from file-util.cc:38: > >>> In file included from ./log.h:26: > >>> /usr/include/c++/v1/deque:907:49: error: invalid application of 'sizeof' to an > >>> incomplete type 'value_type' (aka 'pan::Log::Entry') > >>> static const difference_type __block_size = sizeof(value_type) < 256 ? 4... > >>> > >>> Anyone know how to fix either clang++ or libc++? > >> > >> The error here does not appear to be in clang or libc++, but in the > >> use by the thing that you are compiling. > >> This is saying that you have tried to create a std::dequeu, > >> but pan::Log::Entry is a forward declaration and so the template > >> instantiation fails. > >> The fix is to move the definition of pan::Log::Entry such that it > >> is visible at the time of its use. > >> > > > > I don't know C++, but it is at all like C, then the header files > > are normally placed at the top of a file before one's code. In > > this case, the code in news/pan/work/pan-0.139/pan/general/log.h > > looks like (where I've striped comment to keep it short) > > > > #ifndef __Log_h__ > > #define __Log_h__ > > > > #include > > #include > > #include > > #include > > > > namespace pan > > { > > class Log > > { > > public: > > enum Severity { > > PAN_SEVERITY_INFO = 1, > > PAN_SEVERITY_ERROR = 2, > > PAN_SEVERITY_URGENT = (1<<10) > > }; > > > > struct Entry { > > time_t date; > > Severity severity; > > std::deque messages; > > std::string message; > > bool is_child; > > Entry() : is_child(false) { } > > }; > > > > void add_entry(Entry& e, std::deque& list); > > > > > > Are you saying that I need to move '#include ' to > > the location above the 'void add_entry(...)' line? > > The problem here is that the code is trying to make a std::deque of > the type Entry before Entry is fully defined. > This is nearly identical to the problem in the simplified C code below: > > struct foo { > struct foo bar; > } Except it isn't. It's declaring the head of a container. This is more like: struct foo { TAILQ_HEAD(, foo) messages; }; The problem is that unlike the queue macros (which are broken out into chunks), the compiler has to instantiate all of std::deque<> even though it will only use a portion of its definition. I understand why this is a limitation of C++, but it's not quite as brain damaged as your example. The above would not be unreasonable if the foo objects should be stored in a tree and messages was a list of the child nodes. Depending on how this library works you might be able to shim around this by having the dequeue store pointers instead of Entry structs. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 20:05:34 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 42CA4BDE; Tue, 12 Nov 2013 20:05:34 +0000 (UTC) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E6F0521E9; Tue, 12 Nov 2013 20:05:33 +0000 (UTC) Received: by mail-vc0-f173.google.com with SMTP id lh4so4605484vcb.18 for ; Tue, 12 Nov 2013 12:05:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jjWpEygFzF9YUIbt0ATZT7B+l9xsYbmBLZtq61hEoVo=; b=YAoSRZ6H8bKJsKrhGODrv1kc8YloSeURblG6cFJV4Aue0bIT++5OzdzqODozOtrfJO Z1j4iYlKRj2vMTI9TefHQrcJCeYvDACedYKzgrkvBWUZrcWDAwVR/LqYkD/qxCH8MgEz CJ7gWxJDELtmBG6fsCxCvTtrLhDgj0w/PrkNoDHST/C4sejndMMD9Gj8jJOJdBw9GbW9 YdvjDypPdcur9C+xWkv5ho/xR2Qif8Tpg56GuoURT1cmSOKDQ9P0LnadNzpEYctIHozx m/oYJcQw0uEP5SHXXs2FDLr2tP4tMbpoJVMCJ0nLDyQARBN57nmn+z1VWB8skHD3qfxh gisA== MIME-Version: 1.0 X-Received: by 10.220.97.145 with SMTP id l17mr1774877vcn.35.1384286732990; Tue, 12 Nov 2013 12:05:32 -0800 (PST) Received: by 10.221.0.145 with HTTP; Tue, 12 Nov 2013 12:05:32 -0800 (PST) In-Reply-To: <20131112165422.GA2939@troutmask.apl.washington.edu> References: <20131112163219.GA2834@troutmask.apl.washington.edu> <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> Date: Tue, 12 Nov 2013 15:05:32 -0500 Message-ID: Subject: Re: Are clang++ and libc++ compatible? From: Zhihao Yuan To: Steve Kargl Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD current , David Chisnall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 20:05:34 -0000 On Tue, Nov 12, 2013 at 11:54 AM, Steve Kargl wrote: > struct Entry { > time_t date; > Severity severity; > std::deque messages; > std::string message; > bool is_child; > Entry() : is_child(false) { } > }; This is a libc++ QoI issue; T had better not be required to be compete at the instantiation time of the class template itself. I've reported this forward this issue to libc++ upstream. BTW, iirc VC STL has the same issue. But libstdc++ has an honorable history of supporting incomplete type in STL declaration. -- Zhihao Yuan, ID lichray The best way to predict the future is to invent it. ___________________________________________________ 4BSD -- http://4bsd.biz/ From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 17:13:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DABB8963 for ; Tue, 12 Nov 2013 17:13:45 +0000 (UTC) Received: from mail-s68.mailgun.info (mail-s68.mailgun.info [184.173.153.196]) by mx1.freebsd.org (Postfix) with ESMTP id 856BE2DB9 for ; Tue, 12 Nov 2013 17:13:45 +0000 (UTC) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=miator.net; q=dns/txt; s=krs; t=1384276419; h=Mime-Version: In-Reply-To: References: Date: Message-Id: Subject: From: To: Cc: Content-Type: Sender; bh=5XZCEReQHIwe3sinm6ljqE0YLd5DX2mkhjKrtng5V7Y=; b=C20P3Vk8z761kc++GFrQeeV7WDjDrreGrPBQdMhicKI6pIGTm/NZ6a4sifU7JCVg5yGUO5XO LZ+eSJ2DShKcHgjzW16nUU4ZaktPFPrbl1FhyEpASqyEpu+mntcpY+9Rm9yxXKifKXyJ2oJC eslqvid15JnhqXD7MAvcUr/J/h0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=miator.net; s=krs; q=dns; h=Mime-Version: In-Reply-To: References: Date: Message-Id: Subject: From: To: Cc: Content-Type: Sender; b=b8SIbCKAk4aLQXs8Caj3mOn/xdHH3rJhglBAGwj13LG01kPAhtF/e8ZEBfSXCw/mgRNfHc 2xw7uDu4ltTYsAgs20ww4hVKEJeSiGvDt7yoUiyYTSXUfwnlBsWxRF1ytMCxGfueEt2dxGQs av9sXX6jV+seRg5U6xUIv+24urvJ8= Received: from mail-vb0-f46.google.com (mail-vb0-f46.google.com [209.85.212.46]) by mxa.mailgun.org with ESMTP id 528261c3.577b9b0-in2; Tue, 12 Nov 2013 17:13:39 -0000 (UTC) Received: by mail-vb0-f46.google.com with SMTP id 10so4378255vbe.5 for ; Tue, 12 Nov 2013 09:13:38 -0800 (PST) X-Google-Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5XZCEReQHIwe3sinm6ljqE0YLd5DX2mkhjKrtng5V7Y=; b=KLjG8rYzZa6zCtbdMaR83hL9ZPQ03slBr+8h/LWKVXMNNC3GyAvJjNWaJNfcslir6N aN6E32Io0/IYqswjKT2vqkVWhmxjucmjztxF4IXJ9+hBMYDPE8ZNWJymgcwfnIaw7a2Q ljh+5/DdkUF9xCFYR1AtwzqVwiNQXfJR8LzW12CXcg4CofIa1F6hRu1NsmEx5Fnk02Mv 4sDLC769oDm47uvqaPQ3Gt0PRfOTmMC3zA0uXuRhx/ZPYYtUDymiLqN61ZW2+QOjWdVz UcFyQPwA0whCO+K4TRGGexPyZGJAo3/je39mLUlLBYNwlzHY5KERqiH3QxvPeqlfLipG MQNQ== Mime-Version: 1.0 X-Received: by 10.220.86.69 with SMTP id r5mr29934105vcl.9.1384276418568; Tue, 12 Nov 2013 09:13:38 -0800 (PST) Received: by 10.221.0.145 with HTTP; Tue, 12 Nov 2013 09:13:38 -0800 (PST) In-Reply-To: <20131112165422.GA2939@troutmask.apl.washington.edu> References: <20131112163219.GA2834@troutmask.apl.washington.edu> <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> Date: Tue, 12 Nov 2013 12:13:38 -0500 Message-Id: Subject: Re: Are clang++ and libc++ compatible? From: Zhihao Yuan To: Steve Kargl Content-Type: text/plain; charset="UTF-8" X-Mailgun-Sid: WyJmNmI2MCIsICJmcmVlYnNkLWN1cnJlbnRAZnJlZWJzZC5vcmciLCAiNjkxMTAiXQ== Sender: zy@miator.net X-Mailman-Approved-At: Tue, 12 Nov 2013 20:09:11 +0000 Cc: FreeBSD current , David Chisnall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 17:13:45 -0000 On Tue, Nov 12, 2013 at 11:54 AM, Steve Kargl wrote: > struct Entry { > time_t date; > Severity severity; > std::deque messages; > std::string message; > bool is_child; > Entry() : is_child(false) { } > }; This is a libc++ QoI issue; T should not be required to be compete at the instantiation time of the class template itself. I'll forward this message to libc++. BTW, iirc VC STL has the same issue. But libstdc++ has an honorable history of supporting incomplete type in STL declaration. -- Zhihao Yuan, ID lichray The best way to predict the future is to invent it. ___________________________________________________ 4BSD -- http://4bsd.biz/ From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 20:19:23 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A4677349; Tue, 12 Nov 2013 20:19:23 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 82FC0230D; Tue, 12 Nov 2013 20:19:23 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id rACKJMls004389; Tue, 12 Nov 2013 12:19:22 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id rACKJMFn004388; Tue, 12 Nov 2013 12:19:22 -0800 (PST) (envelope-from sgk) Date: Tue, 12 Nov 2013 12:19:22 -0800 From: Steve Kargl To: Dimitry Andric Subject: Re: Are clang++ and libc++ compatible? Message-ID: <20131112201922.GA4330@troutmask.apl.washington.edu> References: <20131112163219.GA2834@troutmask.apl.washington.edu> <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> <20131112175556.GA3319@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131112175556.GA3319@troutmask.apl.washington.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org, David Chisnall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 20:19:23 -0000 On Tue, Nov 12, 2013 at 09:55:56AM -0800, Steve Kargl wrote: > On Tue, Nov 12, 2013 at 06:37:39PM +0100, Dimitry Andric wrote: > > On 12 Nov 2013, at 17:54, Steve Kargl wrote: > > > > > > struct Entry { > > > time_t date; > > > Severity severity; > > > std::deque messages; > > > std::string message; > > > bool is_child; > > > Entry() : is_child(false) { } > > > }; > > > > I think the problem is that the code tries to use std::deque as a > > member of struct Entry, before it is completely defined. This is not > > allowed by the standard, although some libraries (e.g. GNU libstdc++) > > apparently permit it for some container types. > > > > You could try to work around it with -fdelayed-template-parsing, but I > > am not sure if it will help. Alternatively, compile the code with > > libstdc++, or rewrite it to conform. :-) > > > > Thanks for the suggestions. -fdelayed-template-parsing did not > help. (Un)fortunately, I know very little about C++, so rewriting > the code is not option for me. I guess I'll add a USE_GCC to the > port's Makefile to if it will build. > Sigh. Adding USE_GCC isn't the solution. % pan Segmentation fault (core dumped) % ldd /usr/local/bin/pan | grep ++ libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 (0x3c52bf000) libc++.so.1 => /usr/lib/libc++.so.1 (0x3c81ea000) This can't be good. And, unfortunately, testing math/octave shows no better :( % octave Segmentation fault (core dumped) % ldd /usr/local/bin/octave-3.6.4 | grep ++ libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 (0x3c92ec000) libc++.so.1 => /usr/lib/libc++.so.1 (0x3c9801000) -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 19:25:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9ED0FDA5 for ; Tue, 12 Nov 2013 19:25:05 +0000 (UTC) Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 711C62EC6 for ; Tue, 12 Nov 2013 19:25:05 +0000 (UTC) Received: by mail-pd0-f180.google.com with SMTP id v10so3234694pde.25 for ; Tue, 12 Nov 2013 11:24:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=u03D9atludtWWQG/ycvRdxNzDVRGCPjPJ8os8xYkGeQ=; b=GtR7jA8E/hdufKxuThLsrUz/7yeoBB9C0QsbigMn9Gru36/jGORny9fYLwyj6ATa72 zt7KqsGt/7ULKf6haetPHwQhUHRtd+92/IKvqttlsBPF+DW5lnvDdnwQzVet5lDhczHw 2WvFHAKC7IivxFtC5rbtlDaFUa9m7gu5l6pAZ1AgSv1az7j1PMbUiMkqqFSTilstk5cR Fc0tHIKja46jh2jaWHAv/QSF6myi+ExLcsgFBihORdJmyqtPzAbKuGcvWcfKCc1EP4A1 q+jQccSS5dCRiIEXpbWsWcv6ZrtZ/ObWMmBFIjZujYEZk2JM67dH2jhCiNUZgcYhNZMl aeBw== X-Gm-Message-State: ALoCoQlfZKGVW4ftclA+stSnseBKwOZou/XmGd4viS+usvV8hmtQLchZ7ScPB5kmMy/x69H2zfKo X-Received: by 10.68.221.233 with SMTP id qh9mr37415220pbc.103.1384284299078; Tue, 12 Nov 2013 11:24:59 -0800 (PST) Received: from Michaels-MacBook-Pro.local (c-98-246-202-204.hsd1.or.comcast.net. [98.246.202.204]) by mx.google.com with ESMTPSA id b3sm35017096pbu.38.2013.11.12.11.24.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Nov 2013 11:24:58 -0800 (PST) Message-ID: <52828088.4070405@callfortesting.org> Date: Tue, 12 Nov 2013 11:24:56 -0800 From: Michael Dexter User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Devin Teske Subject: Re: [CFT] bsdinstall and zfsboot enhancements References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> <5281340E.8080009@callfortesting.org> <52813F9E.8080304@freebsd.org> <4E00C3CC-75EA-4249-8D9F-42F37988F4CE@fisglobal.com> <528141C1.7080409@freebsd.org> <29ADA509-0BB7-435C-8AC1-1D5BC32D6DC8@fisglobal.com> <5281451A.5000804@freebsd.org> <06B994A9-8438-434C-A7B3-E7A4A5991031@fisglobal.com> In-Reply-To: <06B994A9-8438-434C-A7B3-E7A4A5991031@fisglobal.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 12 Nov 2013 20:23:37 +0000 Cc: Current Current , "Teske, Devin" , Peter Grehan , Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 19:25:05 -0000 On 11/11/13 1:01 PM, Teske, Devin wrote: >> > It doesn't touch the timeout code - should be whatever FreeBSD loader forth scripts tell it to do. >> > > Ah, must have been something Michael did. I noticed this whilst getting > demos from him on his laptop. Please clarify. What specifically? Michael From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 20:23:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E911C634; Tue, 12 Nov 2013 20:23:55 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AFD742387; Tue, 12 Nov 2013 20:23:55 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa07.fnfis.com (8.14.5/8.14.5) with ESMTP id rACKNlQL016428 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 12 Nov 2013 14:23:47 -0600 Received: from dtwin (10.242.182.25) by smtp.fisglobal.com (10.132.206.17) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Nov 2013 14:23:46 -0600 From: Sender: Devin Teske To: "'Michael Dexter'" , "'Devin Teske'" References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> <5281340E.8080009@callfortesting.org> <52813F9E.8080304@freebsd.org> <4E00C3CC-75EA-4249-8D9F-42F37988F4CE@fisglobal.com> <528141C1.7080409@freebsd.org> <29ADA509-0BB7-435C-8AC1-1D5BC32D6DC8@fisglobal.com> <5281451A.5000804@freebsd.org> <06B994A9-8438-434C-A7B3-E7A4A5991031@fisglobal.com> <52828088.4070405@callfortesting.org> In-Reply-To: <52828088.4070405@callfortesting.org> Subject: RE: [CFT] bsdinstall and zfsboot enhancements Date: Tue, 12 Nov 2013 12:22:00 -0800 Message-ID: <088201cedfe4$d96697c0$8c33c740$@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFP6zv6BnOMPrT4RKfUUTCN8KifdwFuFGbcAo+LsZABvWijHgDl0O8OAj00Es8COplZbAJdDRG/AYgJX6MCFen1ywIEILVLAfq81DQDqnun8AG1wuL1mkxcpHA= Content-Language: en-us X-Originating-IP: [10.242.182.25] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-11-12_08:2013-11-12,2013-11-12,1970-01-01 signatures=0 Cc: 'Current Current' , 'Nathan Whitehorn' , 'Peter Grehan' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 20:23:56 -0000 > -----Original Message----- > From: Michael Dexter [mailto:editor@callfortesting.org] > Sent: Tuesday, November 12, 2013 11:25 AM > To: Devin Teske > Cc: Teske, Devin; Peter Grehan; Nathan Whitehorn; Current Current > Subject: Re: [CFT] bsdinstall and zfsboot enhancements > > On 11/11/13 1:01 PM, Teske, Devin wrote: > >> > It doesn't touch the timeout code - should be whatever FreeBSD loader > forth scripts tell it to do. > >> > > > Ah, must have been something Michael did. I noticed this whilst getting > > demos from him on his laptop. > > Please clarify. What specifically? > When the boot menu comes up, it counts down to from 5, 4, 3, ... Instead of 9, 8, 7, ... Sounds like autoboot_delay is modified... in the installed distro? Did you script that or do it by hand? in loader.conf? in the VM? Just curious. -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 20:27:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 86E4C7C9 for ; Tue, 12 Nov 2013 20:27:36 +0000 (UTC) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5A22B23C8 for ; Tue, 12 Nov 2013 20:27:36 +0000 (UTC) Received: by mail-pb0-f46.google.com with SMTP id un15so7484386pbc.19 for ; Tue, 12 Nov 2013 12:27:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+uazEu42XG110INoAaYO2dqcvbZ61FD6SvnkvrCD9IY=; b=iQAdXp+4eAQO+/KtmI9O8MR3i+Db3fzkLXoTkAIaznm3X+klzg6naiEbei0lXOD8P3 Rzhvy6ktRi0aI6K04blcOPc/cI8EhSVuBvHpyzHLfnDD3ckHhvcc8rD9xVc6a/yVjn65 X7099AS9hYdpd58Nvg34vcJFjE+gwTFW3BF2ypM8rkbfwl7xzom9RaJl4mbZSaqcIR3S p44oKWnmI1k0aJMzNF0TPAI5XMdDWFVyaac/8EAeCHyYP6MGqH9pcpYsGYa6ZORI7S48 yMCJcsl0HiSA6Ng3G803fCzFt7ERXjTBTYLzlnY0BaM6zKjCSMlAD9qPrSxQ1/QqTvhB c3Xg== X-Gm-Message-State: ALoCoQmefW+KWI61+79FaSsq0hAUgiN7R6p4KO9D5YS8bvBJwHyl2g8Z+GQTDWUeZJyEV30PSQOl X-Received: by 10.66.231.42 with SMTP id td10mr10197911pac.144.1384288055475; Tue, 12 Nov 2013 12:27:35 -0800 (PST) Received: from Michaels-MacBook-Pro.local (c-98-246-202-204.hsd1.or.comcast.net. [98.246.202.204]) by mx.google.com with ESMTPSA id er3sm39434225pbb.40.2013.11.12.12.27.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Nov 2013 12:27:34 -0800 (PST) Message-ID: <52828F36.7000504@callfortesting.org> Date: Tue, 12 Nov 2013 12:27:34 -0800 From: Michael Dexter User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dteske@freebsd.org Subject: Re: [CFT] bsdinstall and zfsboot enhancements References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> <5281340E.8080009@callfortesting.org> <52813F9E.8080304@freebsd.org> <4E00C3CC-75EA-4249-8D9F-42F37988F4CE@fisglobal.com> <528141C1.7080409@freebsd.org> <29ADA509-0BB7-435C-8AC1-1D5BC32D6DC8@fisglobal.com> <5281451A.5000804@freebsd.org> <06B994A9-8438-434C-A7B3-E7A4A5991031@fisglobal.com> <52828088.4070405@callfortesting.org> <088201cedfe4$d96697c0$8c33c740$@freebsd.org> In-Reply-To: <088201cedfe4$d96697c0$8c33c740$@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 12 Nov 2013 20:56:52 +0000 Cc: 'Current Current' , 'Nathan Whitehorn' , 'Peter Grehan' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 20:27:36 -0000 On 11/12/13 12:22 PM, dteske@freebsd.org wrote: > When the boot menu comes up, it counts down to from 5, 4, 3, ... > Instead of 9, 8, 7, ... > > Sounds like autoboot_delay is modified... in the installed distro? > Did you script that or do it by hand? in loader.conf? in the VM? > > Just curious. Good eye! My scripts have been throwing in autoboot_delay="5" to short the time between load an potential kernel panic. No fun when the countdown was the longest part for the whole process. :) Michael From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 21:19:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51275291; Tue, 12 Nov 2013 21:19:58 +0000 (UTC) Received: from mailrelay004.isp.belgacom.be (mailrelay004.isp.belgacom.be [195.238.6.170]) by mx1.freebsd.org (Postfix) with ESMTP id 7FFA8278B; Tue, 12 Nov 2013 21:19:57 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmMGAJiaglJbsLPN/2dsb2JhbABaDoJ5wCGBKRd0giUBAQU6HCMQCw4KCSUPKh4GExuHagG/Q49fB4QxA5gOkguCZ0A7 Received: from 205.179-176-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.176.179.205]) by relay.skynet.be with ESMTP; 12 Nov 2013 22:19:49 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.7/8.14.7) with ESMTP id rACLJlpd012854; Tue, 12 Nov 2013 22:19:48 +0100 (CET) (envelope-from tijl@coosemans.org) Date: Tue, 12 Nov 2013 22:19:46 +0100 From: Tijl Coosemans To: Steve Kargl Subject: Re: Are clang++ and libc++ compatible? Message-ID: <20131112221946.78602db0@kalimero.tijl.coosemans.org> In-Reply-To: <20131112201922.GA4330@troutmask.apl.washington.edu> References: <20131112163219.GA2834@troutmask.apl.washington.edu> <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> <20131112175556.GA3319@troutmask.apl.washington.edu> <20131112201922.GA4330@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: David Chisnall , freebsd-current@FreeBSD.org, Dimitry Andric X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 21:19:58 -0000 On Tue, 12 Nov 2013 12:19:22 -0800 Steve Kargl wrote: > On Tue, Nov 12, 2013 at 09:55:56AM -0800, Steve Kargl wrote: >> On Tue, Nov 12, 2013 at 06:37:39PM +0100, Dimitry Andric wrote: >>> On 12 Nov 2013, at 17:54, Steve Kargl wrote: >>>> >>>> struct Entry { >>>> time_t date; >>>> Severity severity; >>>> std::deque messages; >>>> std::string message; >>>> bool is_child; >>>> Entry() : is_child(false) { } >>>> }; >>> >>> I think the problem is that the code tries to use std::deque as a >>> member of struct Entry, before it is completely defined. This is not >>> allowed by the standard, although some libraries (e.g. GNU libstdc++) >>> apparently permit it for some container types. >>> >>> You could try to work around it with -fdelayed-template-parsing, but I >>> am not sure if it will help. Alternatively, compile the code with >>> libstdc++, or rewrite it to conform. :-) >> >> Thanks for the suggestions. -fdelayed-template-parsing did not >> help. (Un)fortunately, I know very little about C++, so rewriting >> the code is not option for me. I guess I'll add a USE_GCC to the >> port's Makefile to if it will build. > > Sigh. Adding USE_GCC isn't the solution. There's a similar problem with graphics/blender. There's a class TreeElement which links to its parent TreeElement like this: std::map::const_iterator parent; Works with libstdc++, fails with libc++. If the standard doesn't specify this it would still be a very convenient extension. > % pan > Segmentation fault (core dumped) > % ldd /usr/local/bin/pan | grep ++ > libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 (0x3c52bf000) > libc++.so.1 => /usr/lib/libc++.so.1 (0x3c81ea000) > > This can't be good. And, unfortunately, testing math/octave shows > no better :( > > % octave > Segmentation fault (core dumped) > % ldd /usr/local/bin/octave-3.6.4 | grep ++ > libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 (0x3c92ec000) > libc++.so.1 => /usr/lib/libc++.so.1 (0x3c9801000) This could be because you enabled the OPENMP option in math/fftw3. From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 21:28:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E18E64A6 for ; Tue, 12 Nov 2013 21:28:35 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 719272838 for ; Tue, 12 Nov 2013 21:28:35 +0000 (UTC) Received: from mandree.no-ip.org ([78.48.103.134]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MGWR2-1VtYw52HSq-00DFuK for ; Tue, 12 Nov 2013 22:28:33 +0100 Received: from [IPv6:::1] (localhost6.localdomain6 [IPv6:::1]) by apollo.emma.line.org (Postfix) with ESMTP id 62F8223CE8F for ; Tue, 12 Nov 2013 22:28:32 +0100 (CET) Message-ID: <52829D80.6000303@gmx.de> Date: Tue, 12 Nov 2013 22:28:32 +0100 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Are clang++ and libc++ compatible? References: <20131112163219.GA2834@troutmask.apl.washington.edu> <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:dBUKFBNZDTv6PqZN6VuUXkzQOsca6mD9p6wjXle4SE/uFveQnhx PHZpx/+4U6EEde7sujhUKdJSTxtQvAWgGcHFhUPPwhEIFWi+zwBumgGgXrexOFtQDtg/RnU zNmeUMtk9/IzmP0CbH7A6I00WKecM9HOKZKGXszN679svLRQS2JBJPY1D5XFQcgz5e9ik6s /qQLZ9JMEqIemxNNrfKOA== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 21:28:35 -0000 Am 12.11.2013 18:13, schrieb Zhihao Yuan: > BTW, iirc VC STL has the same issue. But libstdc++ has an honorable > history of supporting incomplete type in STL declaration. A disservice, not honorable. Nonstandard extensions, however convenient, are a pain when writing portable code. I am usually setting -std=c++11 -pedantic first up these days to avoid pitfalls later. (or -std=c11) And hope the compiler actually complains. From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 21:32:50 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA8837D1 for ; Tue, 12 Nov 2013 21:32:50 +0000 (UTC) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6909628B0 for ; Tue, 12 Nov 2013 21:32:50 +0000 (UTC) Received: by mail-qe0-f46.google.com with SMTP id s14so5960972qeb.5 for ; Tue, 12 Nov 2013 13:32:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=El4LoUFXBqqSPBtbStDcqZQFU6B2NvbjDol9vbOdyBs=; b=rUg4cAzpV2Gu/BYD/ZuMT1IEqFeb50bm/FO4+PoCO56sdPJhnIYm25C1teDkIL1Xs2 wm8KdGfQFCccturDcOr4qkPAIVl6Zs8JoqdsqlzdsE9UVG0LDtXtfKzxAc9vFRkHszEY fcS3cfPqmLxeArrQz1IFx3cPtgTvbyuCfrsyQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=El4LoUFXBqqSPBtbStDcqZQFU6B2NvbjDol9vbOdyBs=; b=ECqB8AGQzlkApZuEWN5wbpf6TUtHVvge/vGUH8r3WvZZ/b6ePJl76DZ+quziCKcM7n 7gTapph9KOhyo79ZQew7uIijKrDtPozPKT6QJtWSG4hnmzvXnLYtGAtAfGhiIBcceazC Lpm7JUWHuaWru3qDX5P1EWWourvc22Z8iO+69q98aYnbYROUfyb6xObBtzvmu4wb6E0+ iJZVZhbdvQfotZQqMHHiqBZH7dmIAxQlLvyG51N0YwcHo9Ay+RXHrGoLm+qxiRghUGYj YTpCkLI1nfEDsC38UNCwPovXL7kwkIvOBCqNawOwLCWniFBqYwppX/xCqeZ7b+v6qcE0 6OiQ== X-Gm-Message-State: ALoCoQlHxrnHaRTvuibF42y1O6e+xNbMcy/IL1u6N9r8ZsNG5Hxktpor36o2LXoxraT16Qviy0KG X-Received: by 10.229.41.130 with SMTP id o2mr17184098qce.20.1384291969594; Tue, 12 Nov 2013 13:32:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.63.101 with HTTP; Tue, 12 Nov 2013 13:32:19 -0800 (PST) In-Reply-To: <201311121321.07330.jhb@freebsd.org> References: <20131112163219.GA2834@troutmask.apl.washington.edu> <20131112165422.GA2939@troutmask.apl.washington.edu> <201311121321.07330.jhb@freebsd.org> From: Eitan Adler Date: Tue, 12 Nov 2013 16:32:19 -0500 Message-ID: Subject: Re: Are clang++ and libc++ compatible? To: John Baldwin Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current Current , David Chisnall , Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 21:32:50 -0000 On Tue, Nov 12, 2013 at 1:21 PM, John Baldwin wrote: > On Tuesday, November 12, 2013 1:11:04 pm Eitan Adler wrote: >> On Tue, Nov 12, 2013 at 11:54 AM, Steve Kargl >> wrote: >> > On Tue, Nov 12, 2013 at 04:38:17PM +0000, David Chisnall wrote: >> >> On 12 Nov 2013, at 16:32, Steve Kargl > wrote: >> >> >> >>> Trying to build news/pan with clang++ dies with >> >>> >> >>> gmake[3]: Entering directory > `/usr/ports/news/pan/work/pan-0.139/pan/general' >> >>> CXX file-util.o >> >>> In file included from file-util.cc:38: >> >>> In file included from ./log.h:26: >> >>> /usr/include/c++/v1/deque:907:49: error: invalid application of 'sizeof' > to an >> >>> incomplete type 'value_type' (aka 'pan::Log::Entry') >> >>> static const difference_type __block_size = sizeof(value_type) < 256 > ? 4... >> >>> >> >>> Anyone know how to fix either clang++ or libc++? >> >> >> >> The error here does not appear to be in clang or libc++, but in the >> >> use by the thing that you are compiling. >> >> This is saying that you have tried to create a > std::dequeu, >> >> but pan::Log::Entry is a forward declaration and so the template >> >> instantiation fails. >> >> The fix is to move the definition of pan::Log::Entry such that it >> >> is visible at the time of its use. >> >> >> > >> > I don't know C++, but it is at all like C, then the header files >> > are normally placed at the top of a file before one's code. In >> > this case, the code in news/pan/work/pan-0.139/pan/general/log.h >> > looks like (where I've striped comment to keep it short) >> > >> > #ifndef __Log_h__ >> > #define __Log_h__ >> > >> > #include >> > #include >> > #include >> > #include >> > >> > namespace pan >> > { >> > class Log >> > { >> > public: >> > enum Severity { >> > PAN_SEVERITY_INFO = 1, >> > PAN_SEVERITY_ERROR = 2, >> > PAN_SEVERITY_URGENT = (1<<10) >> > }; >> > >> > struct Entry { >> > time_t date; >> > Severity severity; >> > std::deque messages; >> > std::string message; >> > bool is_child; >> > Entry() : is_child(false) { } >> > }; >> > >> > void add_entry(Entry& e, std::deque& list); >> > >> > >> > Are you saying that I need to move '#include ' to >> > the location above the 'void add_entry(...)' line? >> >> The problem here is that the code is trying to make a std::deque of >> the type Entry before Entry is fully defined. >> This is nearly identical to the problem in the simplified C code below: >> >> struct foo { >> struct foo bar; >> } > > Except it isn't. It's declaring the head of a container. This is more > like: > > struct foo { > TAILQ_HEAD(, foo) messages; > }; > > The problem is that unlike the queue macros (which are broken out into > chunks), the compiler has to instantiate all of std::deque<> even though > it will only use a portion of its definition. I understand why this is > a limitation of C++, but it's not quite as brain damaged as your > example. Yes, I'm aware of this difference. -- Eitan Adler From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 21:35:48 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61D04B13 for ; Tue, 12 Nov 2013 21:35:48 +0000 (UTC) Received: from mail-qe0-x234.google.com (mail-qe0-x234.google.com [IPv6:2607:f8b0:400d:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1033528FD for ; Tue, 12 Nov 2013 21:35:47 +0000 (UTC) Received: by mail-qe0-f52.google.com with SMTP id t9so1840562qeq.11 for ; Tue, 12 Nov 2013 13:35:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=RrQWmPK4N8w6NQafdiYqqFU6yj9NV5ZrG0V8vq6GXXY=; b=QpKYkAWGas8m+IGsx1YxKY61INi5cLW0Ls6s0acZC0MLIQyfqJrPirXWCGfmK6/rdK Cm7Tm56Zux9M1MUwa+aZEbXQcI264tcNw6sWDZF4vQZCOHhPEGIFrbTBPCJPWxzn+Sbn obdf2WpKwEU6kA8GB4R5ceKzuQNQckGOML/IU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=RrQWmPK4N8w6NQafdiYqqFU6yj9NV5ZrG0V8vq6GXXY=; b=Uhez82AX28HIOqhCa6ubCEAwf+B+zBjYIGDUDNLiDVcIbaoPdjywuO8RSUm+yCvwAz iLXDD8yF54/EYFd8mQOM0LVKmjcOB/S4WGjf0hkPRNBpmMlQH6C9O4FMVw5J7gCWLhXj Ga2OAzxGxWm2LeSkAwkxPZlbchSWbxMWyKecSsCtNj241cEZO52ddPCN4fyTCmfBYni3 NcCWyLYcbJGn4SnQYeFnIb4NG7OBsv0kJSKPoOzx7mAAvmZ91EB6ScUFMdYPy6nQYhU7 tLdCorrfisViC2FEUDVFmByrMtcb6SStD9gTvfSp7nGeHd5IyQNsl9waCjVyJInYGRTP zyaA== X-Gm-Message-State: ALoCoQnjaLymgELQeXXQ+ALsFnla4kSOTBB6P8JHZVCG8EDxCBrQZsKexuI8QidI4BlpVDwVT1Jf X-Received: by 10.49.103.161 with SMTP id fx1mr59967738qeb.68.1384292147137; Tue, 12 Nov 2013 13:35:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.63.101 with HTTP; Tue, 12 Nov 2013 13:35:16 -0800 (PST) In-Reply-To: <20131112201922.GA4330@troutmask.apl.washington.edu> References: <20131112163219.GA2834@troutmask.apl.washington.edu> <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> <20131112175556.GA3319@troutmask.apl.washington.edu> <20131112201922.GA4330@troutmask.apl.washington.edu> From: Eitan Adler Date: Tue, 12 Nov 2013 16:35:16 -0500 Message-ID: Subject: Re: Are clang++ and libc++ compatible? To: Steve Kargl Content-Type: text/plain; charset=UTF-8 Cc: David Chisnall , freebsd-current Current , Dimitry Andric X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 21:35:48 -0000 On Tue, Nov 12, 2013 at 3:19 PM, Steve Kargl wrote: > On Tue, Nov 12, 2013 at 09:55:56AM -0800, Steve Kargl wrote: >> On Tue, Nov 12, 2013 at 06:37:39PM +0100, Dimitry Andric wrote: >> > On 12 Nov 2013, at 17:54, Steve Kargl wrote: >> > > >> > > struct Entry { >> > > time_t date; >> > > Severity severity; >> > > std::deque messages; >> > > std::string message; >> > > bool is_child; >> > > Entry() : is_child(false) { } >> > > }; >> > >> > I think the problem is that the code tries to use std::deque as a >> > member of struct Entry, before it is completely defined. This is not >> > allowed by the standard, although some libraries (e.g. GNU libstdc++) >> > apparently permit it for some container types. >> > >> > You could try to work around it with -fdelayed-template-parsing, but I >> > am not sure if it will help. Alternatively, compile the code with >> > libstdc++, or rewrite it to conform. :-) >> > >> >> Thanks for the suggestions. -fdelayed-template-parsing did not >> help. (Un)fortunately, I know very little about C++, so rewriting >> the code is not option for me. I guess I'll add a USE_GCC to the >> port's Makefile to if it will build. >> > > Sigh. Adding USE_GCC isn't the solution. Try USES=compiler:libstd++ - I think this is the syntax required. -- Eitan Adler From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 21:46:46 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF45A10F; Tue, 12 Nov 2013 21:46:46 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9B1B429C0; Tue, 12 Nov 2013 21:46:46 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::d18c:20bf:ce3b:e453] (unknown [IPv6:2001:7b8:3a7:0:d18c:20bf:ce3b:e453]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 2A2D95C43; Tue, 12 Nov 2013 22:46:44 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_71532245-877E-43D3-8257-567251A582E0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: Are clang++ and libc++ compatible? From: Dimitry Andric In-Reply-To: <20131112221946.78602db0@kalimero.tijl.coosemans.org> Date: Tue, 12 Nov 2013 22:46:38 +0100 Message-Id: <9169A1F8-5773-459F-9763-5B50B4452D16@FreeBSD.org> References: <20131112163219.GA2834@troutmask.apl.washington.edu> <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> <20131112175556.GA3319@troutmask.apl.washington.edu> <20131112201922.GA4330@troutmask.apl.washington.edu> <20131112221946.78602db0@kalimero.tijl.coosemans.org> To: Tijl Coosemans X-Mailer: Apple Mail (2.1822) Cc: freebsd-current@FreeBSD.org, David Chisnall , Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 21:46:46 -0000 --Apple-Mail=_71532245-877E-43D3-8257-567251A582E0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 12 Nov 2013, at 22:19, Tijl Coosemans wrote: ... There's a similar problem with graphics/blender. There's a class > TreeElement which links to its parent TreeElement like this: > > std::map::const_iterator parent; > > Works with libstdc++, fails with libc++. If the standard doesn't > specify this it would still be a very convenient extension. The standard explicitly says this is undefined, except for a few specific (non-container) classes in C++11. So to write portable code, you should not rely on this "feature" to be available. Besides, it is relatively easy to work around. Except for the case of pan, where it is abused all over the place, and it seems tricky to fix without overhauling a lot of code... :-/ -Dimitry --Apple-Mail=_71532245-877E-43D3-8257-567251A582E0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlKCocYACgkQsF6jCi4glqMnXwCfebZAyTrZDE6onQPIYv4yCZMq 9mQAoIMVXZCILkkytPfWvlOGMoTSBRh/ =l7hj -----END PGP SIGNATURE----- --Apple-Mail=_71532245-877E-43D3-8257-567251A582E0-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 22:40:47 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1CA33849; Tue, 12 Nov 2013 22:40:47 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D5C602DCC; Tue, 12 Nov 2013 22:40:46 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id rACMegmD005091; Tue, 12 Nov 2013 14:40:42 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id rACMeg2p005090; Tue, 12 Nov 2013 14:40:42 -0800 (PST) (envelope-from sgk) Date: Tue, 12 Nov 2013 14:40:42 -0800 From: Steve Kargl To: Tijl Coosemans Subject: Re: Are clang++ and libc++ compatible? Message-ID: <20131112224042.GA5050@troutmask.apl.washington.edu> References: <20131112163219.GA2834@troutmask.apl.washington.edu> <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> <20131112175556.GA3319@troutmask.apl.washington.edu> <20131112201922.GA4330@troutmask.apl.washington.edu> <20131112221946.78602db0@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131112221946.78602db0@kalimero.tijl.coosemans.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: David Chisnall , freebsd-current@FreeBSD.org, Dimitry Andric X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 22:40:47 -0000 On Tue, Nov 12, 2013 at 10:19:46PM +0100, Tijl Coosemans wrote: > On Tue, 12 Nov 2013 12:19:22 -0800 Steve Kargl wrote: > > This can't be good. And, unfortunately, testing math/octave shows > > no better :( > > > > % octave > > Segmentation fault (core dumped) > > % ldd /usr/local/bin/octave-3.6.4 | grep ++ > > libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 (0x3c92ec000) > > libc++.so.1 => /usr/lib/libc++.so.1 (0x3c9801000) > > This could be because you enabled the OPENMP option in math/fftw3. Unfortuantely, that's not it. Just rebuilt fftw3 and octave still dies. ldd shows that /usr/local/lib/octave/3.6.4/liboctinterp.so.1 is bringing in both libc++ and libstdc++, but it is also linked to 52 other libraries. -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 23:13:37 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61A4B2F1; Tue, 12 Nov 2013 23:13:37 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3E5D72FF3; Tue, 12 Nov 2013 23:13:37 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id rACNDYLn005229; Tue, 12 Nov 2013 15:13:34 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id rACNDYZn005228; Tue, 12 Nov 2013 15:13:34 -0800 (PST) (envelope-from sgk) Date: Tue, 12 Nov 2013 15:13:34 -0800 From: Steve Kargl To: Tijl Coosemans Subject: Re: Are clang++ and libc++ compatible? Message-ID: <20131112231334.GA5188@troutmask.apl.washington.edu> References: <20131112163219.GA2834@troutmask.apl.washington.edu> <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> <20131112175556.GA3319@troutmask.apl.washington.edu> <20131112201922.GA4330@troutmask.apl.washington.edu> <20131112221946.78602db0@kalimero.tijl.coosemans.org> <20131112224042.GA5050@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131112224042.GA5050@troutmask.apl.washington.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Dimitry Andric , freebsd-current@FreeBSD.org, David Chisnall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 23:13:37 -0000 On Tue, Nov 12, 2013 at 02:40:42PM -0800, Steve Kargl wrote: > On Tue, Nov 12, 2013 at 10:19:46PM +0100, Tijl Coosemans wrote: > > On Tue, 12 Nov 2013 12:19:22 -0800 Steve Kargl wrote: > > > This can't be good. And, unfortunately, testing math/octave shows > > > no better :( > > > > > > % octave > > > Segmentation fault (core dumped) > > > % ldd /usr/local/bin/octave-3.6.4 | grep ++ > > > libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 (0x3c92ec000) > > > libc++.so.1 => /usr/lib/libc++.so.1 (0x3c9801000) > > > > This could be because you enabled the OPENMP option in math/fftw3. > > Unfortuantely, that's not it. Just rebuilt fftw3 and octave still > dies. ldd shows that /usr/local/lib/octave/3.6.4/liboctinterp.so.1 > is bringing in both libc++ and libstdc++, but it is also linked > to 52 other libraries. > What a rabbit hole FreeBSD has dug! Needed to recompile fltk, libGL, and libGLU with USE_GCC=any in their Makefile to eliminate octave's dependence on libc++. Octave now will start as expected. Guess I need to chase down other ports that may use fltk, libGL, and/or libGLU to ensure the new installation does not cause a new libc++ vs libstdc++ conflict. -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Nov 13 07:29:43 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2C2626EA; Wed, 13 Nov 2013 07:29:43 +0000 (UTC) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by mx1.freebsd.org (Postfix) with ESMTP id 6251D2A05; Wed, 13 Nov 2013 07:29:42 +0000 (UTC) Received: from ppp118-210-43-157.lns20.adl2.internode.on.net (HELO leader.local) ([118.210.43.157]) by ipmail06.adl2.internode.on.net with ESMTP; 13 Nov 2013 17:59:41 +1030 Message-ID: <52832A63.1000601@ShaneWare.Biz> Date: Wed, 13 Nov 2013 17:59:39 +1030 From: Shane Ambler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Tijl Coosemans , Steve Kargl Subject: Re: Are clang++ and libc++ compatible? References: <20131112163219.GA2834@troutmask.apl.washington.edu> <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> <20131112175556.GA3319@troutmask.apl.washington.edu> <20131112201922.GA4330@troutmask.apl.washington.edu> <20131112221946.78602db0@kalimero.tijl.coosemans.org> In-Reply-To: <20131112221946.78602db0@kalimero.tijl.coosemans.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Dimitry Andric , freebsd-current@FreeBSD.org, David Chisnall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 07:29:43 -0000 On 13/11/2013 07:49, Tijl Coosemans wrote: > On Tue, 12 Nov 2013 12:19:22 -0800 Steve Kargl wrote: >> On Tue, Nov 12, 2013 at 09:55:56AM -0800, Steve Kargl wrote: >>> On Tue, Nov 12, 2013 at 06:37:39PM +0100, Dimitry Andric wrote: >>>> On 12 Nov 2013, at 17:54, Steve Kargl wrote: >>>>> >>>>> struct Entry { >>>>> time_t date; >>>>> Severity severity; >>>>> std::deque messages; >>>>> std::string message; >>>>> bool is_child; >>>>> Entry() : is_child(false) { } >>>>> }; >>>> >>>> I think the problem is that the code tries to use std::deque as a >>>> member of struct Entry, before it is completely defined. This is not >>>> allowed by the standard, although some libraries (e.g. GNU libstdc++) >>>> apparently permit it for some container types. > There's a similar problem with graphics/blender. There's a class > TreeElement which links to its parent TreeElement like this: > > std::map::const_iterator parent; > > Works with libstdc++, fails with libc++. If the standard doesn't > specify this it would still be a very convenient extension. > A possible solution I found looking into this is to wrap the Entry reference in a std::unique_ptr - so changing - std::deque messages; to - std::deque> messages; This turns messages into a pointer so you need to change messages.date into messages->date This got blender compiling past that issue but I haven't got the rest of it compiling to test that it runs. From owner-freebsd-current@FreeBSD.ORG Wed Nov 13 07:46:28 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7C89B59; Wed, 13 Nov 2013 07:46:28 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 83ADF2B0D; Wed, 13 Nov 2013 07:46:28 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::d18c:20bf:ce3b:e453] (unknown [IPv6:2001:7b8:3a7:0:d18c:20bf:ce3b:e453]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 194E95C43; Wed, 13 Nov 2013 08:46:23 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_BB35E160-ADA6-419E-88B7-4FCC0C494202"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: Are clang++ and libc++ compatible? From: Dimitry Andric In-Reply-To: <52832A63.1000601@ShaneWare.Biz> Date: Wed, 13 Nov 2013 08:46:18 +0100 Message-Id: References: <20131112163219.GA2834@troutmask.apl.washington.edu> <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> <20131112175556.GA3319@troutmask.apl.washington.edu> <20131112201922.GA4330@troutmask.apl.washington.edu> <20131112221946.78602db0@kalimero.tijl.coosemans.org> <52832A63.1000601@ShaneWare.Biz> To: Shane Ambler X-Mailer: Apple Mail (2.1822) Cc: Tijl Coosemans , David Chisnall , Steve Kargl , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 07:46:28 -0000 --Apple-Mail=_BB35E160-ADA6-419E-88B7-4FCC0C494202 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 On 13 Nov 2013, at 08:29, Shane Ambler wrote: > On 13/11/2013 07:49, Tijl Coosemans wrote: ... >> There's a similar problem with graphics/blender. There's a class >> TreeElement which links to its parent TreeElement like this: >> >> std::map::const_iterator parent; >> >> Works with libstdc++, fails with libc++. If the standard doesn't >> specify this it would still be a very convenient extension. >> > > A possible solution I found looking into this is to wrap the Entry > reference in a std::unique_ptr - so changing - > std::deque messages; > to - > std::deque> messages; > > This turns messages into a pointer so you need to change > messages.date into messages->date With pan, this is not so easy, unfortunately. It needs changes all over the place to make it work. There was a patch for pkgsrc [1] which attempted this, but it was backed out because it caused crashes. -Dimitry [1] http://mail-index.netbsd.org/pkgsrc-changes/2013/06/16/msg091009.html --Apple-Mail=_BB35E160-ADA6-419E-88B7-4FCC0C494202 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlKDLk4ACgkQsF6jCi4glqMKqwCfS9owFajqzF9xGXhQwvP/dMxd ywEAnivrD+YnXlS5HJ3Bba4LSkuQ07sv =lMiM -----END PGP SIGNATURE----- --Apple-Mail=_BB35E160-ADA6-419E-88B7-4FCC0C494202-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 13 10:04:44 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B134B307; Wed, 13 Nov 2013 10:04:44 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7FCEC23B0; Wed, 13 Nov 2013 10:04:44 +0000 (UTC) Received: from [192.168.0.2] (cpc27-cmbg15-2-0-cust235.5-4.cable.virginm.net [86.27.188.236]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id rADA4eWo014235 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Nov 2013 10:04:41 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Are clang++ and libc++ compatible? From: David Chisnall In-Reply-To: <201311121321.07330.jhb@freebsd.org> Date: Wed, 13 Nov 2013 10:04:36 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <9071A5A2-9F8D-4F5A-9EAD-66A680246AFE@FreeBSD.org> References: <20131112163219.GA2834@troutmask.apl.washington.edu> <20131112165422.GA2939@troutmask.apl.washington.edu> <201311121321.07330.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1508) Cc: Eitan Adler , freebsd-current@FreeBSD.org, Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 10:04:44 -0000 On 12 Nov 2013, at 18:21, John Baldwin wrote: >> struct foo { >> struct foo bar; >> } >=20 > Except it isn't. It's declaring the head of a container. This is = more > like: >=20 > struct foo { > TAILQ_HEAD(, foo) messages; > }; Eitan is correct here. The definition of std::deque is that it copies = the value that is the template argument and does not require = modifications to the layout. A deque is more akin to an array, so in C = it would be something like: struct foo { struct foo bar[10]; }; This is clearly nonsense - you can't have a structure that contains = itself. The same is true for the deque. It's not clear what the pan = people actually wanted, but an efficient implementation of a deque would = most likely contain space for a small number of the template argument = elements, so they are literally defining a structure containing a = structure containing the parent structure. The same would be true if = they did: struct Entry { std::vector v; }; An implementation of the vector class might allocate all of the elements = on the heap lazily, but it's not required to and could equally have = space for a small number inside the object, expanding to something like = this: struct Entry { struct MangledNameOfVectorOfEntry { size_t size; Entry small[4]; Entry *ptr; }; }; It would make sense to have a std:deque or std:deque, = because then you're only storing references or pointers to the outer = structure in the inner structure. =20 David From owner-freebsd-current@FreeBSD.ORG Wed Nov 13 14:51:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1CBA2E87; Wed, 13 Nov 2013 14:51:52 +0000 (UTC) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AE1BB2737; Wed, 13 Nov 2013 14:51:51 +0000 (UTC) Received: by mail-vc0-f180.google.com with SMTP id ib11so343871vcb.39 for ; Wed, 13 Nov 2013 06:51:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tebgeUyC+k8HrsPlUHmXvpFx4zY8SNOheJk1adweTiI=; b=hfhcFtdHCpcT0g+V7rUbR1F5Sk1O4qiuTBsvPQTyzEzObAhcMpMWF4dPmGgL6CdnmT MekfLPC9brBRrk5WbFVL30mR3T0u8H1xVYJvkUpq8NY/Rf8EXkl7cIdJT0rb64rnhOST wbWSuoqdBtaowI2dE2rzI5SsNTvfi/GRAnJSldpn3DvFtqghv6DElQVbc+ZhUc19RIAT r4x3UebKxIiC5yYfkmJ+b9PziGP9w6KkDVtBX+e0CEz/8DLFtCu2oxCV+cToxtUyCS30 a4Kqjw7Y9CwWAZFNM7f62jh7gMbSNr9j6fBSKvjcMkfcUxyqi+NKw9sVgADcc/LOAEA/ 72Sw== MIME-Version: 1.0 X-Received: by 10.58.233.98 with SMTP id tv2mr34688909vec.11.1384354310733; Wed, 13 Nov 2013 06:51:50 -0800 (PST) Received: by 10.221.0.145 with HTTP; Wed, 13 Nov 2013 06:51:50 -0800 (PST) In-Reply-To: <9071A5A2-9F8D-4F5A-9EAD-66A680246AFE@FreeBSD.org> References: <20131112163219.GA2834@troutmask.apl.washington.edu> <20131112165422.GA2939@troutmask.apl.washington.edu> <201311121321.07330.jhb@freebsd.org> <9071A5A2-9F8D-4F5A-9EAD-66A680246AFE@FreeBSD.org> Date: Wed, 13 Nov 2013 09:51:50 -0500 Message-ID: Subject: Re: Are clang++ and libc++ compatible? From: Zhihao Yuan To: David Chisnall Content-Type: text/plain; charset=UTF-8 Cc: Eitan Adler , FreeBSD current , Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 14:51:52 -0000 On Wed, Nov 13, 2013 at 5:04 AM, David Chisnall wrote: > A deque is more akin to an array, so in C it would be something like: > [...] > This is clearly nonsense - you can't have a structure that contains itself. > [...] > An implementation of the vector class might allocate all of the elements on the heap lazily, but it's not required to and could equally have space for a small number inside the object, expanding to something like this: > > struct Entry { > struct MangledNameOfVectorOfEntry { > size_t size; > Entry small[4]; > Entry *ptr; > }; > }; If you don't learn C++, then just don't make claims like these. If I can not recursively declare std::array, which is totally allocated on stack with layout exactly same as T[N], I would say this implementation is mad. > It would make sense to have a std:deque or std:deque, because then you're only storing references or pointers to the outer structure in the inner structure. It makes no sense, since you switched from value semantics to reference semantics. -- Zhihao Yuan, ID lichray The best way to predict the future is to invent it. ___________________________________________________ 4BSD -- http://4bsd.biz/ From owner-freebsd-current@FreeBSD.ORG Wed Nov 13 14:52:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9E426FAB; Wed, 13 Nov 2013 14:52:36 +0000 (UTC) Received: from mail-vb0-x22c.google.com (mail-vb0-x22c.google.com [IPv6:2607:f8b0:400c:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 399482751; Wed, 13 Nov 2013 14:52:36 +0000 (UTC) Received: by mail-vb0-f44.google.com with SMTP id 11so345395vbe.17 for ; Wed, 13 Nov 2013 06:52:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w7B2ZUF++XYcSM5X2dzA0CLuNLVx3CXlDVWZHiv4FO0=; b=O9oZ+kWv1s1u80vydmvAe5dnBwUtHMSuFI2wh7J9zHTdIWClIBVUbXXmtAfVMdbuKw sBYPQhq1ZWl+DXxBJ05HJV7rXsIBoWaOKPy7T0VA11zK7Rhws0zgtM1nUveO/2QEPThI k2N2S9zP/U3WWHQCqVwbP5nxw9WNvsLI0SRemcUujV++MKeaKFflrjMaX+rVetPvUkNA qF61rzaE+oxCwmWHmt5dTfDoedPrK6hp4cUDKIz3PNGwqgOv4QjRRJ2dKyBziKGxcBtX k3P0WFpE592AhyfeKTNM4D94qxaUfHh62Qfz7dEHzjmvm5BgU8zGylm7XgPXc2mZhdDB x34g== MIME-Version: 1.0 X-Received: by 10.220.75.73 with SMTP id x9mr553968vcj.38.1384354355336; Wed, 13 Nov 2013 06:52:35 -0800 (PST) Received: by 10.221.0.145 with HTTP; Wed, 13 Nov 2013 06:52:35 -0800 (PST) In-Reply-To: <52832A63.1000601@ShaneWare.Biz> References: <20131112163219.GA2834@troutmask.apl.washington.edu> <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> <20131112175556.GA3319@troutmask.apl.washington.edu> <20131112201922.GA4330@troutmask.apl.washington.edu> <20131112221946.78602db0@kalimero.tijl.coosemans.org> <52832A63.1000601@ShaneWare.Biz> Date: Wed, 13 Nov 2013 09:52:35 -0500 Message-ID: Subject: Re: Are clang++ and libc++ compatible? From: Zhihao Yuan To: Shane Ambler Content-Type: text/plain; charset=UTF-8 Cc: David Chisnall , Tijl Coosemans , Dimitry Andric , Steve Kargl , FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 14:52:36 -0000 On Wed, Nov 13, 2013 at 2:29 AM, Shane Ambler wrote: > A possible solution I found looking into this is to wrap the Entry > reference in a std::unique_ptr - so changing - > std::deque messages; > to - > std::deque> messages; This "fix" is wrong. (Smart) pointers of T have comparison behaviors different from T itself, so this may silently change a program's runtime behavior. A better fix is to use `std::deque>`. Both libstdc++ and libc++ support vector, and vector's comparison behavior is as same as T. And of course,they both have value semantics. -- Zhihao Yuan, ID lichray The best way to predict the future is to invent it. ___________________________________________________ 4BSD -- http://4bsd.biz/ From owner-freebsd-current@FreeBSD.ORG Wed Nov 13 15:18:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3290B96F; Wed, 13 Nov 2013 15:18:10 +0000 (UTC) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C131E28EA; Wed, 13 Nov 2013 15:18:09 +0000 (UTC) Received: by mail-ve0-f176.google.com with SMTP id c14so409438vea.35 for ; Wed, 13 Nov 2013 07:18:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZLqGGbuQN6bWiT6lHcBWyyqncfZh5PBKh7DNfRp3wj0=; b=z+P96aW/82lO2D7j8FbWewp5cUofkgslJFB7XqtJDGWXVbMtx1mmfwHSMGCGB3Jjdy tBvpBkRBH0+2tZMFoBXAVXy8wefCZ6C2ALJwDImNRj/2g6DkmwzFe/djcedAlWkARyW6 VUyoFb8Nzhyr9ntdrjKmDQv9kQ+W29QVuh5e5qxbpjXOzWNbe5dDt2ph9yqjpfjMsuZy GDi6XsnQe5oD0NLae8QvcpOZbtISBWdGJ/M/4pC9NEZNhfmYf8IN8vMB0Ri8IkQImyr8 bEb5R6/JgV1zYi/sVFPp4sOoHErRWQD8hYyR+WoolOxBZD5DJjpARpQGug0Ab4H8AEkB EINA== MIME-Version: 1.0 X-Received: by 10.52.64.143 with SMTP id o15mr29863426vds.16.1384355888996; Wed, 13 Nov 2013 07:18:08 -0800 (PST) Received: by 10.221.0.145 with HTTP; Wed, 13 Nov 2013 07:18:08 -0800 (PST) In-Reply-To: References: <20131112163219.GA2834@troutmask.apl.washington.edu> <20131112165422.GA2939@troutmask.apl.washington.edu> <201311121321.07330.jhb@freebsd.org> <9071A5A2-9F8D-4F5A-9EAD-66A680246AFE@FreeBSD.org> Date: Wed, 13 Nov 2013 10:18:08 -0500 Message-ID: Subject: Re: Are clang++ and libc++ compatible? From: Zhihao Yuan To: David Chisnall Content-Type: text/plain; charset=UTF-8 Cc: Eitan Adler , FreeBSD current , Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 15:18:10 -0000 On Wed, Nov 13, 2013 at 9:51 AM, Zhihao Yuan wrote: >> An implementation of the vector class might allocate all of the elements on the heap lazily, but it's not required to and could equally have space for a small number inside the object, expanding to something like this: >> >> struct Entry { >> struct MangledNameOfVectorOfEntry { >> size_t size; >> Entry small[4]; >> Entry *ptr; >> }; >> }; > > If you don't learn C++, then just don't make claims like these. If I can > not recursively declare std::array, which is totally allocated on > stack with layout exactly same as T[N], I would say this implementation > is mad. Sorry, this part is wrong. Stack allocation does require complete type. > A deque is more akin to an array, so in C it would be something like: > [...] > This is clearly nonsense - you can't have a structure that contains itself. > [...] These part has nothing to do with C++. -- Zhihao Yuan, ID lichray The best way to predict the future is to invent it. ___________________________________________________ 4BSD -- http://4bsd.biz/ From owner-freebsd-current@FreeBSD.ORG Wed Nov 13 16:32:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B811C13A for ; Wed, 13 Nov 2013 16:32:58 +0000 (UTC) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7559B2D9F for ; Wed, 13 Nov 2013 16:32:58 +0000 (UTC) Received: from [80.67.16.112] (helo=webmailfront02.ispgateway.de) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1VgdLz-0000N0-UL for freebsd-current@freebsd.org; Wed, 13 Nov 2013 17:31:43 +0100 Received: from his1.his.de (his1.his.de [192.124.237.237]) by webmail.df.eu (Horde Framework) with HTTP; Wed, 13 Nov 2013 17:31:43 +0100 Date: Wed, 13 Nov 2013 17:31:43 +0100 Message-ID: <20131113173143.Horde.a-9M7JQ_vHo3tpDIMsGK6g1@webmail.df.eu> From: Marcus von Appen To: freebsd-current@freebsd.org Subject: libc++ vs. libstdc++ usage in the ports tree (was: Re: Are clang++ and libc++ compatible?) References: <20131112163219.GA2834@troutmask.apl.washington.edu> <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> <20131112175556.GA3319@troutmask.apl.washington.edu> <20131112201922.GA4330@troutmask.apl.washington.edu> In-Reply-To: <20131112201922.GA4330@troutmask.apl.washington.edu> User-Agent: Internet Messaging Program (IMP) H5 (6.0.4) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-Df-Sender: ZnJlZWJzZEBzeXNmYXVsdC5vcmc= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list Reply-To: mva@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 16:32:58 -0000 Steve Kargl : [...] > Sigh. Adding USE_GCC isn't the solution. > > % pan > Segmentation fault (core dumped) > % ldd /usr/local/bin/pan | grep ++ > libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 (0x3c52bf000) > libc++.so.1 => /usr/lib/libc++.so.1 (0x3c81ea000) > > This can't be good. And, unfortunately, testing math/octave shows > no better :( > > % octave > Segmentation fault (core dumped) > % ldd /usr/local/bin/octave-3.6.4 | grep ++ > libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 (0x3c92ec000) > libc++.so.1 => /usr/lib/libc++.so.1 (0x3c9801000) > This brings up another point into which I am running with the previously discussed blender issue. Let's assume port A_defcompiler does not specify a compiler and c++ lib, it will default to libc++ and clang++ on 10.x or newer, correct? If now a port B_gnuish depends on port A_defcompiler, but at the same defines GCC + libstdc++, the resulting binary might link against libc++ and libstdc++ at the same time. This in turn makes the port unusable. The same applies to the other way around. Right now we do not have mechanism to detect and handle those flaws. Maintainers might be even less aware of those issues. Does anyone know a proper way to deal with this at the moment on 10.x+ or is this something that was missed until now? Cheers Marcus From owner-freebsd-current@FreeBSD.ORG Wed Nov 13 16:59:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 205F7B85; Wed, 13 Nov 2013 16:59:20 +0000 (UTC) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D50E02F4C; Wed, 13 Nov 2013 16:59:19 +0000 (UTC) Received: by mail-oa0-f41.google.com with SMTP id g12so783813oah.0 for ; Wed, 13 Nov 2013 08:59:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nd9vwXqzPtEdsASLgZlMVzaU31Mr3YxeVBT/LuL0/Dw=; b=KXxQUsippSyINGlairrStQm2TgV6Jw4VpTRIVv5zd1pAKJ4K9csHVUKmRuA0h1hsEh 4UX10HJVXdnpdh41eO5WnpM/vH4TtTVxHwnieLw3qgYuZMQsgUk4Kldt2J2KMBxseoM9 a7dCu4MAMwkB/P+bNgALuuJmuij9HkdF0WL9klkmNgJT7uDpwXVyGB7+n8XYNt+80dWX WBCkW2okyJqOe+iZPXIyxzKEKagRrYZYoQDq+hHqbcgpkWrBILTfwlj78MqIVEYB0nTg PkM+o6m9ryriA2YtZBErO4uyFdXGcrAjaO/89hA6QrGED1o0D7kyXTkIGhpPoNtt1xU7 +jyg== MIME-Version: 1.0 X-Received: by 10.182.18.9 with SMTP id s9mr37803613obd.15.1384361959217; Wed, 13 Nov 2013 08:59:19 -0800 (PST) Received: by 10.76.177.234 with HTTP; Wed, 13 Nov 2013 08:59:19 -0800 (PST) In-Reply-To: <20131113173143.Horde.a-9M7JQ_vHo3tpDIMsGK6g1@webmail.df.eu> References: <20131112163219.GA2834@troutmask.apl.washington.edu> <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> <20131112175556.GA3319@troutmask.apl.washington.edu> <20131112201922.GA4330@troutmask.apl.washington.edu> <20131113173143.Horde.a-9M7JQ_vHo3tpDIMsGK6g1@webmail.df.eu> Date: Wed, 13 Nov 2013 17:59:19 +0100 Message-ID: Subject: Re: libc++ vs. libstdc++ usage in the ports tree (was: Re: Are clang++ and libc++ compatible?) From: Andreas Nilsson To: mva@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 16:59:20 -0000 https://wiki.freebsd.org/NewC++Stack says things about linking against both libc++ and libstdc++ , do they still apply? Best regards Andreas From owner-freebsd-current@FreeBSD.ORG Wed Nov 13 17:52:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61B88FA4; Wed, 13 Nov 2013 17:52:17 +0000 (UTC) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1F97B2327; Wed, 13 Nov 2013 17:52:17 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id wp4so837474obc.21 for ; Wed, 13 Nov 2013 09:52:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0rmA2WjXH26yhNqjs10XwljV6C0wIjdugAkZ5LnRbC4=; b=XsoJkr7wXhWULqNXX0RMDUg/DwlsPXIqbHN7LJGQkoIXPqe21lAY9oYWecoLzVnyoG w4fDQcqdbqsFTGbdFXP7FM4VnM/7Xl9I5zA3nRGtxgwm61ctePssIifjXqc2bgQG0E1F EUfzTD0RESnaRB32RNbFm8ZEY3+/1AJIq7M6/YZa5s/EPGftleXJASaJqEEeasrjQayQ KO1SbbmWuOHoYxxSDRRsSN6oDg/I7OQ5cH3d2+35UMp/+4UeE6AiXN2HlCljcLe80ucZ EyjxAPZyspFCmoeIPfHmwrmw1AYSpN/2DWMXiv5a8I7EMd499QY1pnnwGxI4IRqjAzoz HKrw== MIME-Version: 1.0 X-Received: by 10.60.93.67 with SMTP id cs3mr37557305oeb.12.1384365136323; Wed, 13 Nov 2013 09:52:16 -0800 (PST) Received: by 10.76.69.1 with HTTP; Wed, 13 Nov 2013 09:52:16 -0800 (PST) In-Reply-To: <20131113173143.Horde.a-9M7JQ_vHo3tpDIMsGK6g1@webmail.df.eu> References: <20131112163219.GA2834@troutmask.apl.washington.edu> <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> <20131112175556.GA3319@troutmask.apl.washington.edu> <20131112201922.GA4330@troutmask.apl.washington.edu> <20131113173143.Horde.a-9M7JQ_vHo3tpDIMsGK6g1@webmail.df.eu> Date: Wed, 13 Nov 2013 12:52:16 -0500 Message-ID: Subject: Re: libc++ vs. libstdc++ usage in the ports tree (was: Re: Are clang++ and libc++ compatible?) From: Ryan Stone To: mva@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 17:52:17 -0000 On Wed, Nov 13, 2013 at 11:31 AM, Marcus von Appen wrote: > This brings up another point into which I am running with the previously > discussed blender issue. > > Let's assume port A_defcompiler does not specify a compiler and c++ lib, it > will default to libc++ and clang++ on 10.x or newer, correct? > If now a port B_gnuish depends on port A_defcompiler, but at the same > defines > GCC + libstdc++, the resulting binary might link against libc++ and > libstdc++ > at the same time. This in turn makes the port unusable. The same applies > to the other way around. > > Right now we do not have mechanism to detect and handle those flaws. > Maintainers > might be even less aware of those issues. Does anyone know a proper way to > deal > with this at the moment on 10.x+ or is this something that was missed until > now? How different is this from the previous situation? As I understand it previously A_defcompiler would be linked against the system libstdc++ and B_gnuish would be linked against the gccXX port libstdc++. In my experience libstdc++ does not have good ABI stability between versions so shouldn't you have the same potential for problems? From owner-freebsd-current@FreeBSD.ORG Wed Nov 13 17:59:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2D6B1E9; Wed, 13 Nov 2013 17:59:23 +0000 (UTC) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ACBBA2390; Wed, 13 Nov 2013 17:59:23 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id lf10so780418pab.36 for ; Wed, 13 Nov 2013 09:59:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8t9hqgdUkMu75dbFjyujkU8e/09RZJAzKsnEgQ+98pM=; b=GBERDowzW7yC+AVBXFmQPqIKGnsIUaOimPSXLtGUolXhe+4N9cfkwF7EtnmY5dJPDM x+ZEhVh8lwLf1wo3lEjRa2kmLQEwqw7r3kyH0hk0g7XyA8xVnsBIlyzJKwT+gwKHEevH w0um+mmcNzYmd2Wcg8JxpNJHmnffmoIvH0lXdxpjbBWtcXSCwzOfAb2A3PDwrIrJhFHy yHXRDyZL+poLHcX/+HPgX3iFsksDdrxd4+8QArM9TLreuR+ztGdpPgPIcM+QRqhct8kA fPkXG3v9DOAsHUGgBV26oUQOmASk1mitJXKN/O2y6YJjusa0FAeYb4tnf6GVj8aRbqom lQzg== MIME-Version: 1.0 X-Received: by 10.68.233.135 with SMTP id tw7mr42594262pbc.112.1384365563339; Wed, 13 Nov 2013 09:59:23 -0800 (PST) Received: by 10.68.248.106 with HTTP; Wed, 13 Nov 2013 09:59:23 -0800 (PST) In-Reply-To: <20131112111322.GV90670@droso.dk> References: <20131103220654.GU52889@FreeBSD.org> <6AA4A8E1-CBCE-4C87-A320-BB08EC76715F@lassitu.de> <20131104083443.GZ52889@FreeBSD.org> <2B21E123-23BA-4E07-B9DD-9DE1CDE40D08@FreeBSD.org> <20131104163457.GJ52889@FreeBSD.org> <868B00D6-101A-4B17-995F-A3E2AFE41908@lansing.dk> <20131112111322.GV90670@droso.dk> Date: Wed, 13 Nov 2013 19:59:23 +0200 Message-ID: Subject: Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf From: George Kontostanos To: Erwin Lansing Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: FreeBSD Release Engineering Team , Stefan Bethke , FreeBSD Current , Gleb Smirnoff , freebsd-stable , =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= , =?ISO-8859-1?Q?=D6zkan_KIRIK?= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 17:59:24 -0000 On Tue, Nov 12, 2013 at 1:13 PM, Erwin Lansing wrote: > On Wed, Nov 06, 2013 at 02:59:15PM +0100, Erwin Lansing wrote: > > >> E> > > > >> E> > Erwin, can you please handle that? > > >> E> > > >> E> Things are much worse that this, the ports are completely written > under the assumption that there is a Bind in base, which of course would > already break with WITHOUT_BIND before Bind was completely removed. It > will be hard to fix without breaking the installed base of 8 and 9. Sigh. > > >> E> > > >> E> I'll try to work on it this week, but unfortunately have a full > schedule of meetings and travel as well. > > > > > > Suggestion. An option to install the rc script would solve that > problem. > > > > > > > If only it was that simple, it would have been done a long time ago. As > Gleb points out, the ports are broken by design. The rc script needs a > complete rewrite, and that's only after fixing all configuration files, > setting up chroot, etc etc and all that while not breaking the installed > base on 8 and 9. I spent most of yesterday on this and if I'm lucky, I'm > halfway through. > > > > > Sorry about the delay, but I did finally update all three dns/bind9* > ports today. I have dropped the complicated chroot, and related > symlinking, logic from the default rc script as I don't think that > is the right place to implement things. I would recommend users > who want the extra security to use jail(8) instead of a mere chroot. > > This change should not affect the installed base of FreeBSD 9.x and > earlier systems, but new installations there should note that the > symlink option is no longer turned on by default, but still supported. > > I tested some default cases, but by no means can test every corner case, > so please let me know how this works out. > > Best, > Erwin > > Excellent thanks so much! If you had named running using the old rc scripts and config in 10 you will need to: 1) Backup your zones & stop named 2) Delete /var/named/* 3) Create a new symlink in etc to /usr/local/etc/namedb 4) Restore your zones 5) Start named from the new rc script -- George Kontostanos --- http://www.aisecure.net From owner-freebsd-current@FreeBSD.ORG Wed Nov 13 18:05:08 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0CAD0572; Wed, 13 Nov 2013 18:05:08 +0000 (UTC) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B867B2423; Wed, 13 Nov 2013 18:05:07 +0000 (UTC) Received: by mail-pb0-f45.google.com with SMTP id mc8so772284pbc.32 for ; Wed, 13 Nov 2013 10:05:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2lAGtftmfJGxDyj77YLx7bUgjoKp6nSMoCGxMWfsmTQ=; b=SU8W4YY/ovkUTlrOGqahFWY67yMyoZ1wGhhYl9gmClYEDzqZ9bfoNv++hZG0xR/crj 3bH2fuqNuFDggoXUiKqIpcRNj6moACICj2DttwsNw0B1+BVauGwCVr9Ovc8CwCW055WZ yCKxQdPFTQZyfk8q3rfktEe6Bi/R/AgCz2Q9gO3N8mocuPFfe7KnydBJiCcMOeTUQ0KB bb4f8kaZ5ELrtHXGIiUJTqSMF/Gy9xirhAuyRrhXJreNycKP138ihadBEVKr2iUVK9MP R5zeWgzHtveIAKuxLh6OvINpnWW4ePrttNWW3XHTvhTDP9oztfbRk3cP3WeclWANPTC5 xK6w== MIME-Version: 1.0 X-Received: by 10.66.119.202 with SMTP id kw10mr43760628pab.118.1384365907432; Wed, 13 Nov 2013 10:05:07 -0800 (PST) Received: by 10.68.248.106 with HTTP; Wed, 13 Nov 2013 10:05:07 -0800 (PST) In-Reply-To: References: <20131103220654.GU52889@FreeBSD.org> <6AA4A8E1-CBCE-4C87-A320-BB08EC76715F@lassitu.de> <20131104083443.GZ52889@FreeBSD.org> <2B21E123-23BA-4E07-B9DD-9DE1CDE40D08@FreeBSD.org> <20131104163457.GJ52889@FreeBSD.org> <868B00D6-101A-4B17-995F-A3E2AFE41908@lansing.dk> <20131112111322.GV90670@droso.dk> Date: Wed, 13 Nov 2013 20:05:07 +0200 Message-ID: Subject: Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf From: George Kontostanos To: Erwin Lansing Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: FreeBSD Release Engineering Team , Stefan Bethke , FreeBSD Current , Gleb Smirnoff , freebsd-stable , =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= , =?ISO-8859-1?Q?=D6zkan_KIRIK?= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 18:05:08 -0000 On Wed, Nov 13, 2013 at 7:59 PM, George Kontostanos wrote: > On Tue, Nov 12, 2013 at 1:13 PM, Erwin Lansing wrote: > >> On Wed, Nov 06, 2013 at 02:59:15PM +0100, Erwin Lansing wrote: >> > >> E> > >> > >> E> > Erwin, can you please handle that? >> > >> E> >> > >> E> Things are much worse that this, the ports are completely written >> under the assumption that there is a Bind in base, which of course would >> already break with WITHOUT_BIND before Bind was completely removed. It >> will be hard to fix without breaking the installed base of 8 and 9. Sigh. >> > >> E> >> > >> E> I'll try to work on it this week, but unfortunately have a full >> schedule of meetings and travel as well. >> > > >> > > Suggestion. An option to install the rc script would solve that >> problem. >> > > >> > >> > If only it was that simple, it would have been done a long time ago. >> As Gleb points out, the ports are broken by design. The rc script needs a >> complete rewrite, and that's only after fixing all configuration files, >> setting up chroot, etc etc and all that while not breaking the installed >> base on 8 and 9. I spent most of yesterday on this and if I'm lucky, I'm >> halfway through. >> > >> >> >> Sorry about the delay, but I did finally update all three dns/bind9* >> ports today. I have dropped the complicated chroot, and related >> symlinking, logic from the default rc script as I don't think that >> is the right place to implement things. I would recommend users >> who want the extra security to use jail(8) instead of a mere chroot. >> >> This change should not affect the installed base of FreeBSD 9.x and >> earlier systems, but new installations there should note that the >> symlink option is no longer turned on by default, but still supported. >> >> I tested some default cases, but by no means can test every corner case, >> so please let me know how this works out. >> >> Best, >> Erwin >> >> > Excellent thanks so much! > > If you had named running using the old rc scripts and config in 10 you > will need to: > > 1) Backup your zones & stop named > 2) Delete /var/named/* > 3) Create a new symlink in etc to /usr/local/etc/namedb > 4) Restore your zones > 5) Start named from the new rc script > > Sorry I forgot also that if if you don't specify the location of named in the rc.conf: named_program="/usr/local/sbin/named" You will get an error message: root@hp:/etc # /usr/local/etc/rc.d/named start /usr/local/etc/rc.d/named: WARNING: run_rc_command: cannot run /usr/sbin/named Those are observations from a test machine that I use which was running bind with the old rc style. Thanks -- George Kontostanos --- http://www.aisecure.net From owner-freebsd-current@FreeBSD.ORG Wed Nov 13 18:26:57 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A4C92B79; Wed, 13 Nov 2013 18:26:57 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 682DB25A8; Wed, 13 Nov 2013 18:26:57 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id rADIQlpX009994; Wed, 13 Nov 2013 10:26:47 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id rADIQkbJ009993; Wed, 13 Nov 2013 10:26:46 -0800 (PST) (envelope-from sgk) Date: Wed, 13 Nov 2013 10:26:46 -0800 From: Steve Kargl To: Ryan Stone Subject: Re: libc++ vs. libstdc++ usage in the ports tree (was: Re: Are clang++ and libc++ compatible?) Message-ID: <20131113182646.GA9887@troutmask.apl.washington.edu> References: <20131112163219.GA2834@troutmask.apl.washington.edu> <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> <20131112175556.GA3319@troutmask.apl.washington.edu> <20131112201922.GA4330@troutmask.apl.washington.edu> <20131113173143.Horde.a-9M7JQ_vHo3tpDIMsGK6g1@webmail.df.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Current , mva@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 18:26:57 -0000 On Wed, Nov 13, 2013 at 12:52:16PM -0500, Ryan Stone wrote: > On Wed, Nov 13, 2013 at 11:31 AM, Marcus von Appen wrote: > > This brings up another point into which I am running with the previously > > discussed blender issue. > > > > Let's assume port A_defcompiler does not specify a compiler and c++ lib, it > > will default to libc++ and clang++ on 10.x or newer, correct? > > If now a port B_gnuish depends on port A_defcompiler, but at the same > > defines > > GCC + libstdc++, the resulting binary might link against libc++ and > > libstdc++ > > at the same time. This in turn makes the port unusable. The same applies > > to the other way around. > > > > Right now we do not have mechanism to detect and handle those flaws. > > Maintainers > > might be even less aware of those issues. Does anyone know a proper way to > > deal > > with this at the moment on 10.x+ or is this something that was missed until > > now? > > How different is this from the previous situation? As I understand it > previously A_defcompiler would be linked against the system libstdc++ > and B_gnuish would be linked against the gccXX port libstdc++. In my > experience libstdc++ does not have good ABI stability between versions > so shouldn't you have the same potential for problems? I haven't seen a problem with mixing the system's libstdc++ with a version from lang/gcc46. I can assure you that the problem is very really with libc++ vs libstdc++ within the ports collection. To getting working news/pan and math/octave, I had to recompile graphics/graphite2, graphics/libGL, graphics/libGLU, and x11-toolkits/fltk with "USE_GCC=any" to avoid the conflict. Fortunately, I have only another 360 installed ports to check for the conflict. -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Nov 13 18:52:46 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D93074D9 for ; Wed, 13 Nov 2013 18:52:46 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1C45D2774 for ; Wed, 13 Nov 2013 18:52:45 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA23974; Wed, 13 Nov 2013 20:52:37 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VgfYK-000KFi-UK; Wed, 13 Nov 2013 20:52:36 +0200 Message-ID: <5283CA3C.3080201@FreeBSD.org> Date: Wed, 13 Nov 2013 20:51:40 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ryan Stone Subject: Re: libc++ vs. libstdc++ usage in the ports tree References: <20131112163219.GA2834@troutmask.apl.washington.edu> <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> <20131112175556.GA3319@troutmask.apl.washington.edu> <20131112201922.GA4330@troutmask.apl.washington.edu> <20131113173143.Horde.a-9M7JQ_vHo3tpDIMsGK6g1@webmail.df.eu> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 18:52:46 -0000 on 13/11/2013 19:52 Ryan Stone said the following: > In my experience libstdc++ does not have good ABI stability between versions In my experience it does. In either case compatibility between different versions of relatively modern libstdc++ version is no doubt much better than between libstdc++ and libc++. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Nov 13 19:40:40 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 854C73E2; Wed, 13 Nov 2013 19:40:40 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 406B12A71; Wed, 13 Nov 2013 19:40:40 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::e94f:b84:94c0:5083] (unknown [IPv6:2001:7b8:3a7:0:e94f:b84:94c0:5083]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 7256F5C47; Wed, 13 Nov 2013 20:40:31 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_483127B8-4ABE-4B28-984B-78383E7B1CC2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: libc++ vs. libstdc++ usage in the ports tree From: Dimitry Andric In-Reply-To: <5283CA3C.3080201@FreeBSD.org> Date: Wed, 13 Nov 2013 20:40:25 +0100 Message-Id: <352D9465-9840-43F0-A3A9-327DC12B0967@FreeBSD.org> References: <20131112163219.GA2834@troutmask.apl.washington.edu> <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> <20131112175556.GA3319@troutmask.apl.washington.edu> <20131112201922.GA4330@troutmask.apl.washington.edu> <20131113173143.Horde.a-9M7JQ_vHo3tpDIMsGK6g1@webmail.df.eu> <5283CA3C.3080201@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1822) Cc: FreeBSD Current , Ryan Stone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 19:40:40 -0000 --Apple-Mail=_483127B8-4ABE-4B28-984B-78383E7B1CC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 13 Nov 2013, at 19:51, Andriy Gapon wrote: > on 13/11/2013 19:52 Ryan Stone said the following: >> In my experience libstdc++ does not have good ABI stability between = versions >=20 > In my experience it does. > In either case compatibility between different versions of relatively = modern > libstdc++ version is no doubt much better than between libstdc++ and = libc++. Well, GNU libstdc++ is backwards compatible, so you can run programs originally linked against our 4.2.1 version of libstdc++.so, using the latest ports version of libstdc++.so, and they should work. (Not vice versa, but that is not a supported use case.)=20 On the other hand, different C++ standard libraries simply cannot be mixed. The internal implementations are usually completely different. This is not really news at all, certainly not to the ports people. :-) -Dimitry --Apple-Mail=_483127B8-4ABE-4B28-984B-78383E7B1CC2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlKD1a4ACgkQsF6jCi4glqM1nQCeKCI49CEuI9/BWwOYHLHJSKAF RAUAnApgzxrwD1QYig0yMlNUxEPNBoIg =rHvu -----END PGP SIGNATURE----- --Apple-Mail=_483127B8-4ABE-4B28-984B-78383E7B1CC2-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 13 20:29:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6E21536 for ; Wed, 13 Nov 2013 20:29:22 +0000 (UTC) Received: from mail.made4.biz (unknown [IPv6:2001:41d0:1:7018::1:3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A01F82CF6 for ; Wed, 13 Nov 2013 20:29:22 +0000 (UTC) Received: from 141.7.19.93.rev.sfr.net ([93.19.7.141] helo=[192.168.1.179]) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Vgh3w-000Idu-Td for freebsd-current@freebsd.org; Wed, 13 Nov 2013 21:29:21 +0100 Message-ID: <5283E123.5000305@FreeBSD.org> Date: Wed, 13 Nov 2013 21:29:23 +0100 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: new Xorg (KMS, etc.) for Radeon 9600 References: <527F95BE.7080908@gmx.com> <527FC05D.8080703@gmx.com> In-Reply-To: <527FC05D.8080703@gmx.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 20:29:22 -0000 Le 10/11/2013 18:20, dt71@gmx.com a écrit : > drmn0: info: GTT: 0M 0xF0000000 - 0xEFFFFFFF Tijl Coosemans is right, the problem is this line. As I don't really now how AGP works and have no AGP hardware to reproduce the problem, can you post the output of the following commands as a start? pciconf -lvbce devinfo -vr Thanks! -- Jean-Sébastien Pédron From owner-freebsd-current@FreeBSD.ORG Wed Nov 13 21:18:40 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5BCCD36B for ; Wed, 13 Nov 2013 21:18:40 +0000 (UTC) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EBDD92FFC for ; Wed, 13 Nov 2013 21:18:39 +0000 (UTC) Received: from deuterium.andreas.nets (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id rADLIRit048837; Wed, 13 Nov 2013 22:18:36 +0100 (CET) (envelope-from andreast@FreeBSD.org) Message-ID: <5283ECA3.4080502@FreeBSD.org> Date: Wed, 13 Nov 2013 22:18:27 +0100 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: WEAK_REFERENCE? References: <527EB428.6070104@FreeBSD.org> <20131111074706.GK59496@kib.kiev.ua> In-Reply-To: <20131111074706.GK59496@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: Current , brde@optusnet.com.au X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 21:18:40 -0000 On 11.11.13 08:47, Konstantin Belousov wrote: > On Sat, Nov 09, 2013 at 11:16:08PM +0100, Andreas Tobler wrote: >> Hi all, >> >> anyone interested in this patch to remove the WEAK_ALIAS and introduce >> the WEAK_REFERENCE? >> >> http://people.freebsd.org/~andreast/weak_ref.amd64.diff >> >> I have this running since months on amd64 and I have no issues with. >> >> I remember having had a communication with bde@ that he is in favour in >> doing that but I lacked the time to complete. >> A similar thing is pending for i386 and sparc64. The ppc stuff is >> already committed since a longer time. >> >> If no one is interested, I'm happy to clean up my tree and skip this. > > I am not sure why do you include the changes to END() in the same patch. > Did you looked over the all END() usages on amd64, is it always paired > with ENTRY() ? The CNAME() for ELF is the pedantism anyway. > > Other than the somewhat questionable inclusion of the END() change, which > should be committed separately, if ever, I think the change is fine. Am I correct, without this line in sys/amd64/include/asm.h? #define END(name) .size CNAME(name), . - CNAME(name) If so, I just need a usable dot.emacs file to match the formatting expectations from bde. Sounds easy, but I didn't succeed so far. Thank you for the feedback! Andreas From owner-freebsd-current@FreeBSD.ORG Wed Nov 13 23:23:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D62BDBE2 for ; Wed, 13 Nov 2013 23:23:28 +0000 (UTC) Received: from server.i805.com.br (mailhost.i805.com.br [72.52.97.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A93E9299A for ; Wed, 13 Nov 2013 23:23:28 +0000 (UTC) Received: from i805.com.br (localhost [127.0.0.1]) by server.i805.com.br (8.14.6/8.14.5) with ESMTP id rADNNLV5033411 for ; Wed, 13 Nov 2013 21:23:21 -0200 (BRST) (envelope-from rizzo@i805.com.br) From: "Nilton Jose Rizzo" To: freebsd-current@freebsd.org Subject: buildworld error on -current Date: Wed, 13 Nov 2013 20:23:21 -0300 Message-Id: <20131113231748.M92739@i805.com.br> X-Mailer: OpenWebMail 3.00_beta4 20121104 671 X-OriginatingIP: 186.221.6.231 (rizzo) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on server.i805.com.br X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 23:23:28 -0000 Hi all, I have some problens with -current: building shared library librpcsvc.so.5 ===> lib/libsbuf (all) ===> lib/libtacplus (all) ===> lib/libutil (all) ===> lib/libypclnt (all) ===> lib/libcxxrt (all) ===> lib/libc++ (all) c++ -O2 -pipe -I/usr/src/lib/libc++/../../contrib/libc++/include -I/usr/src/li b/libc++/../../contrib/libcxxrt -nostdlib -DLIBCXXRT -Qunused-arguments -fstack- protector -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-un used-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -std=c++0x -Wno-c++11-extensions -c /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp -o algorithm.o In file included from /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp:10: In file included from /usr/src/lib/libc++/../../contrib/libc++/include/algorithm:627: /usr/src/lib/libc++/../../contrib/libc++/include/memory:3331:3: error: no matching literal operator for call to 'operator "" __len' with argument of type 'unsigned long long' or 'const char *', and no matching literal operator template 0__len = (__len - 1) & ~static_cast<_Size>(63); ^ 1 error generated. *** Error code 1 Stop. make[5]: stopped in /usr/src/lib/libc++ *** Error code 1 Stop. make[4]: stopped in /usr/src/lib *** Error code 1 And some ports not compile, as gnash vlc and others, and sound not work with some other multimidea softwares, like parole and xmms, with parole I can't change the default driver to OSS, and when I build this ports I tried use pulsealdio, Alsa and others supports but anyone work. Olny firefox can play some movies but not all my box: root@valfenda:/usr/src # uname -a FreeBSD valfenda 11.0-CURRENT FreeBSD 11.0-CURRENT #6 r257602: Mon Nov 4 05:59:42 BRST 2013 rizzo@valfenda:/usr/obj/usr/src/sys/VALFENDA amd64 root@valfenda:/usr # svn info src Caminho: src Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Relative URL: ^/head Raiz do Repositório: svn://svn.freebsd.org/base UUID do repositório: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revisão: 258094 Tipo de Nó: diretório Agendado: normal Autor da Última Mudança: emaste Revisão da Última Mudança: 258094 Data da Última Mudança: 2013-11-13 12:46:41 -0200 (Qua, 13 Nov 2013) TIA, Rizzo From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 01:29:33 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6DDD0B68 for ; Thu, 14 Nov 2013 01:29:33 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 130A22169 for ; Thu, 14 Nov 2013 01:29:32 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id rAE1TQnm070352 for ; Wed, 13 Nov 2013 17:29:30 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201311140129.rAE1TQnm070352@gw.catspoiler.org> Date: Wed, 13 Nov 2013 17:29:26 -0800 (PST) From: Don Lewis Subject: CAM panic with tethered Virgin Mobile Mifi 2200 To: freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 01:29:33 -0000 I've had a Virgin Mobile MiFi 2200 CDMA modem for a few years that I've successfully been using in tethered mode on my 8-STABLE laptop. The only issue is that I have to do a camcontrol eject to get it to switch from being a umass device to being a modem. Today I decided to try to add this device to usbdevices and u3g, with the U3GINIT_SCSIEJECT quirk so it would be more convenient to use. I plugged it into my 11-CURRENT machine to find it's ID. This showed up in /var/log/messages: Nov 13 16:42:16 scratch kernel: ugen2.2: at usbus2 Nov 13 16:42:16 scratch kernel: umass0: on usbus2 Nov 13 16:42:16 scratch kernel: umass0: SCSI over Bulk-Only; quirks = 0x0100 Nov 13 16:42:16 scratch kernel: umass0:9:0: Attached to scbus9 Nov 13 16:42:16 scratch kernel: cd0 at umass-sim0 bus 0 scbus9 target 0 lun 0 Nov 13 16:42:16 scratch kernel: cd0: Removable CD-ROM SCSI-2 device Nov 13 16:42:16 scratch kernel: cd0: Serial Number 091166643730000 Nov 13 16:42:16 scratch kernel: cd0: 1.000MB/s transfers Nov 13 16:42:16 scratch kernel: cd0: Attempt to query device size failed: NOT READY, Medium not present Nov 13 16:42:16 scratch kernel: cd0: quirks=0x10<10_BYTE_ONLY> Nov 13 16:42:17 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 Nov 13 16:42:17 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error Nov 13 16:42:17 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition Nov 13 16:42:17 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) Nov 13 16:42:17 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) Nov 13 16:42:17 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 Nov 13 16:42:17 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error Nov 13 16:42:17 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition Nov 13 16:42:17 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) Nov 13 16:42:17 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) Nov 13 16:42:18 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 Nov 13 16:42:18 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error Nov 13 16:42:18 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition Nov 13 16:42:18 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) Nov 13 16:42:18 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) Nov 13 16:42:18 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 Nov 13 16:42:18 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error Nov 13 16:42:18 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition Nov 13 16:42:18 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) Nov 13 16:42:18 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) Nov 13 16:42:19 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 Nov 13 16:42:19 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error Nov 13 16:42:19 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition Nov 13 16:42:19 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) Nov 13 16:42:19 scratch kernel: (cd0:umass-sim0:0:0:0): Error 6, Retries exhausted Nov 13 16:42:19 scratch kernel: (cd0:umass-sim0:0:0:0): cddone: got error 0x6 back Nov 13 16:42:20 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 Nov 13 16:42:20 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error Nov 13 16:42:20 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition Nov 13 16:42:20 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) Nov 13 16:42:20 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) Nov 13 16:42:21 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 Nov 13 16:42:21 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error Nov 13 16:42:21 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition Nov 13 16:42:21 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) Nov 13 16:42:21 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) Nov 13 16:42:21 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 Nov 13 16:42:21 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error Nov 13 16:42:21 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition Nov 13 16:42:21 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) Nov 13 16:42:21 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) Nov 13 16:42:22 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 Nov 13 16:42:22 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error Nov 13 16:42:22 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition Nov 13 16:42:22 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) Nov 13 16:42:22 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) Nov 13 16:42:22 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 Nov 13 16:42:22 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error Nov 13 16:42:22 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition Nov 13 16:42:22 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) Nov 13 16:42:22 scratch kernel: (cd0:umass-sim0:0:0:0): Error 6, Retries exhausted Nov 13 16:42:22 scratch kernel: (cd0:umass-sim0:0:0:0): cddone: got error 0x6 back Nov 13 16:42:23 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 Nov 13 16:42:23 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error Nov 13 16:42:23 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition Nov 13 16:42:23 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) Nov 13 16:42:23 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) Nov 13 16:42:24 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 Nov 13 16:42:24 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error Nov 13 16:42:24 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition Nov 13 16:42:24 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) Nov 13 16:42:24 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) Nov 13 16:42:24 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 Nov 13 16:42:24 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error Nov 13 16:42:24 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition Nov 13 16:42:24 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) Nov 13 16:42:24 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) Nov 13 16:42:25 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 Nov 13 16:42:25 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error Nov 13 16:42:25 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition Nov 13 16:42:25 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) Nov 13 16:42:25 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) Nov 13 16:42:25 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 Nov 13 16:42:25 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error Nov 13 16:42:25 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition Nov 13 16:42:25 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) Nov 13 16:42:25 scratch kernel: (cd0:umass-sim0:0:0:0): Error 6, Retries exhausted Nov 13 16:42:25 scratch kernel: (cd0:umass-sim0:0:0:0): cddone: got error 0x6 back Nov 13 16:42:26 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 Nov 13 16:42:26 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error Nov 13 16:42:26 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition Nov 13 16:42:26 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) Nov 13 16:42:26 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) Nov 13 16:42:27 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 Nov 13 16:42:27 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error Nov 13 16:42:27 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition Nov 13 16:42:27 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) Nov 13 16:42:27 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) Nov 13 16:42:27 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 Nov 13 16:42:27 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error Nov 13 16:42:27 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition Nov 13 16:42:27 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) Nov 13 16:42:27 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) Nov 13 16:42:28 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 Nov 13 16:42:28 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error Nov 13 16:42:28 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition Nov 13 16:42:28 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) Nov 13 16:42:28 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) Nov 13 16:42:28 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 Nov 13 16:42:28 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error Nov 13 16:42:28 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition Nov 13 16:42:28 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) Nov 13 16:42:28 scratch kernel: (cd0:umass-sim0:0:0:0): Error 6, Retries exhausted Nov 13 16:42:28 scratch kernel: (cd0:umass-sim0:0:0:0): cddone: got error 0x6 back I'm assuming that the errors are caused by some missing quirk for the umass device. A short while later, I got this panic, possibly triggered by doing ls -l /dev/cd0 cd0 at umass-sim0 bus 0 scbus9 target 0 lun 0 cd0: s/n 091166643730000 detached (cd0:umass-sim0:0:0:0): Periph destroyed panic: mtx_lock() of destroyed mutex @ /usr/src/sys/cam/cam_xpt.c:5251 cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper(c112eacc,a3135,10000000,e4f97b90,e4f97b88,...) at db_trace_self_wrapper+0x2d/frame 0xe4f97b50 kdb_backtrace(c12eca4f,1,c1127e81,e4f97c28,e4f97bf8,...) at kdb_backtrace+0x30/frame 0xe4f97bb8 vpanic(c140ca38,100,c1127e81,e4f97c28,e4f97c28,...) at vpanic+0x11f/frame 0xe4f97bf8 kassert_panic(c1127e81,c0fee59f,1483,c0fee59f,0,...) at kassert_panic+0xea/frame 0xe4f97c1c __mtx_lock_flags(c9a70ad0,0,c0fee59f,1483,c9a70ad0,...) at __mtx_lock_flags+0x153/frame 0xe4f97c50 xpt_done_process(c13d2a10,0,c0fee59f,1499,0,...) at xpt_done_process+0x44f/frame 0xe4f97c80 xpt_done_td(c13d2a00,e4f97d08,c1123cf4,3db,0,...) at xpt_done_td+0x164/frame 0xe4f97ccc fork_exit(c04c7b80,c13d2a00,e4f97d08) at fork_exit+0x7f/frame 0xe4f97cf4 fork_trampoline() at fork_trampoline+0x8/frame 0xe4f97cf4 --- trap 0, eip = 0, esp = 0xe4f97d40, ebp = 0 --- KDB: enter: panic I've got the vmcore file, so I can extract more info from it if necessary. This is what I see when I plug it into my 8.4-STABLE laptop: umass0: on usbus1 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:2:0:-1: Attached to scbus2 (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 00 00 00 00 00 00 (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI status: Check Condition (probe0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) cd1 at umass-sim0 bus 0 scbus2 target 0 lun 0 cd1: Removable CD-ROM SCSI-2 device cd1: 1.000MB/s transfers cd1: Attempt to query device size failed: NOT READY, Medium not present cd1: quirks=0x10<10_BYTE_ONLY> From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 06:00:33 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2244A6B9; Thu, 14 Nov 2013 06:00:33 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ADA7E2EA7; Thu, 14 Nov 2013 06:00:32 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rAE60RTJ076256; Thu, 14 Nov 2013 08:00:27 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rAE60RTJ076256 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rAE60Qg9076254; Thu, 14 Nov 2013 08:00:26 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 14 Nov 2013 08:00:26 +0200 From: Konstantin Belousov To: Andreas Tobler Subject: Re: WEAK_REFERENCE? Message-ID: <20131114060026.GH59496@kib.kiev.ua> References: <527EB428.6070104@FreeBSD.org> <20131111074706.GK59496@kib.kiev.ua> <5283ECA3.4080502@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NW8tLX0+7pBPLam0" Content-Disposition: inline In-Reply-To: <5283ECA3.4080502@FreeBSD.org> User-Agent: Mutt/1.5.22 (2013-10-16) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Current , brde@optusnet.com.au X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 06:00:33 -0000 --NW8tLX0+7pBPLam0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 13, 2013 at 10:18:27PM +0100, Andreas Tobler wrote: > On 11.11.13 08:47, Konstantin Belousov wrote: > > On Sat, Nov 09, 2013 at 11:16:08PM +0100, Andreas Tobler wrote: > >> Hi all, > >> > >> anyone interested in this patch to remove the WEAK_ALIAS and introduce > >> the WEAK_REFERENCE? > >> > >> http://people.freebsd.org/~andreast/weak_ref.amd64.diff > >> > >> I have this running since months on amd64 and I have no issues with. > >> > >> I remember having had a communication with bde@ that he is in favour in > >> doing that but I lacked the time to complete. > >> A similar thing is pending for i386 and sparc64. The ppc stuff is > >> already committed since a longer time. > >> > >> If no one is interested, I'm happy to clean up my tree and skip this. > >=20 > > I am not sure why do you include the changes to END() in the same patch. > > Did you looked over the all END() usages on amd64, is it always paired > > with ENTRY() ? The CNAME() for ELF is the pedantism anyway. > >=20 > > Other than the somewhat questionable inclusion of the END() change, whi= ch > > should be committed separately, if ever, I think the change is fine. >=20 > Am I correct, without this line in sys/amd64/include/asm.h? >=20 > #define END(name) .size CNAME(name), . - CNAME(name) Yes. If committing it, please make separate commit. >=20 > If so, I just need a usable dot.emacs file to match the formatting > expectations from bde. Sounds easy, but I didn't succeed so far. Nah, cannot be. Emacs source code has too many inconsistencies, the code does not follow its own style. I doubt Bruce would use it. --NW8tLX0+7pBPLam0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJShGb5AAoJEJDCuSvBvK1B/nYQAKXufI4SzXM1d1G+KyBUI/pt Z9rwMVMBmC+4QJpTsHM1pOPWlt10YMI7FcwExPZGu6c93LeOHaqGkz9Z+VBvFgc1 p8xir7ztglGv3dnYKAXaxqTqOIv0scvgv0tfBuMldgBwAqbB9dojK7lQyKP3Pbv5 lDBCYyxRG0SF2/Giss7u/zB+g+laOVkRSxJbQg6U/oozzvG2RYGZ+ygdEIFRF9EA K67Wok0jr6+aYWtATe7ZiLT9AiUyY3GF9bf5fa2nhvTD1Bkepw/5LoZVvnHGITVs JwvZRq3N2+nSOW7YxuTF0TNuR4x/NZ5hKvi1OSdmJaYU96VrsQAgd67iYM88vLEA i1eggsEEej/ooKgYUhn1c5zaI6DUYoWWY4cftOczHRbZo/TtcPtgmrJkQOW2lIjQ bFZmOQo/p+Sf1W96eqCkeMnfh5ERM0a/RNqBf7NptZGGXICEhB8tZZ3f18UHVIqV zXLhyqkpEFs2c24AmQWOEAJ9IjtLkUGlZqarb8UYyYjvjXVTsBuI2pZJTtq3dona rZne0NxbYzjTbs/nz//ipum3cB6PZQbn88V5TwaARsgiNKjYCDTsLUpF3mqzDOSn QOEQ9LCs9ZsBOlxuwQ1Ao1+sYMFG8jV+ex7A99TjiHtFsBf1foKwAVJ4vG4MKGS9 TQOwwbgaAi9iJdBqvIjD =2+CE -----END PGP SIGNATURE----- --NW8tLX0+7pBPLam0-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 08:39:50 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A30319EC; Thu, 14 Nov 2013 08:39:50 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 60E5726E8; Thu, 14 Nov 2013 08:39:50 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAE8dhk1022996; Thu, 14 Nov 2013 03:39:43 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAE8dhA6022993; Thu, 14 Nov 2013 08:39:43 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 14 Nov 2013 08:39:43 GMT Message-Id: <201311140839.rAE8dhA6022993@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on armv6/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 08:39:50 -0000 TB --- 2013-11-14 06:00:18 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-14 06:00:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-14 06:00:18 - starting HEAD tinderbox run for armv6/arm TB --- 2013-11-14 06:00:18 - cleaning the object tree TB --- 2013-11-14 06:00:18 - /usr/local/bin/svn stat /src TB --- 2013-11-14 06:00:23 - At svn revision 258116 TB --- 2013-11-14 06:00:24 - building world TB --- 2013-11-14 06:00:24 - CROSS_BUILD_TESTING=YES TB --- 2013-11-14 06:00:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-14 06:00:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-14 06:00:24 - SRCCONF=/dev/null TB --- 2013-11-14 06:00:24 - TARGET=arm TB --- 2013-11-14 06:00:24 - TARGET_ARCH=armv6 TB --- 2013-11-14 06:00:24 - TZ=UTC TB --- 2013-11-14 06:00:24 - __MAKE_CONF=/dev/null TB --- 2013-11-14 06:00:24 - cd /src TB --- 2013-11-14 06:00:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Nov 14 06:00:30 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] c++ -O -pipe -Qunused-arguments -Wsystem-headers -Werror -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-c++11-extensions -I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc:782:11: error: format string is empty [-Werror,-Wformat-zero-length] "", option.get_size_type()); ^~ /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc:1910:11: error: format string is empty [-Werror,-Wformat-zero-length] "", option.get_size_type()); ^~ 2 errors generated. *** Error code 1 Stop. bmake[4]: stopped in /src/gnu/usr.bin/gperf *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/usr.bin *** Error code 1 Stop. bmake[2]: stopped in /src/gnu *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-14 08:39:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-14 08:39:43 - ERROR: failed to build world TB --- 2013-11-14 08:39:43 - 7683.83 user 1292.60 system 9564.50 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-armv6-arm.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 08:39:50 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B4AA69ED; Thu, 14 Nov 2013 08:39:50 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 72BC326E9; Thu, 14 Nov 2013 08:39:50 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAE8dhvL022997; Thu, 14 Nov 2013 03:39:43 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAE8dhB9022990; Thu, 14 Nov 2013 08:39:43 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 14 Nov 2013 08:39:43 GMT Message-Id: <201311140839.rAE8dhB9022990@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 08:39:50 -0000 TB --- 2013-11-14 06:00:18 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-14 06:00:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-14 06:00:18 - starting HEAD tinderbox run for arm/arm TB --- 2013-11-14 06:00:18 - cleaning the object tree TB --- 2013-11-14 06:00:18 - /usr/local/bin/svn stat /src TB --- 2013-11-14 06:00:23 - At svn revision 258116 TB --- 2013-11-14 06:00:24 - building world TB --- 2013-11-14 06:00:24 - CROSS_BUILD_TESTING=YES TB --- 2013-11-14 06:00:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-14 06:00:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-14 06:00:24 - SRCCONF=/dev/null TB --- 2013-11-14 06:00:24 - TARGET=arm TB --- 2013-11-14 06:00:24 - TARGET_ARCH=arm TB --- 2013-11-14 06:00:24 - TZ=UTC TB --- 2013-11-14 06:00:24 - __MAKE_CONF=/dev/null TB --- 2013-11-14 06:00:24 - cd /src TB --- 2013-11-14 06:00:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Nov 14 06:00:30 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] c++ -O -pipe -Qunused-arguments -Wsystem-headers -Werror -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-c++11-extensions -I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc:782:11: error: format string is empty [-Werror,-Wformat-zero-length] "", option.get_size_type()); ^~ /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc:1910:11: error: format string is empty [-Werror,-Wformat-zero-length] "", option.get_size_type()); ^~ 2 errors generated. *** Error code 1 Stop. bmake[4]: stopped in /src/gnu/usr.bin/gperf *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/usr.bin *** Error code 1 Stop. bmake[2]: stopped in /src/gnu *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-14 08:39:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-14 08:39:43 - ERROR: failed to build world TB --- 2013-11-14 08:39:43 - 7682.90 user 1292.12 system 9564.50 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 08:40:54 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 12DF7D5B for ; Thu, 14 Nov 2013 08:40:54 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B67CC2742 for ; Thu, 14 Nov 2013 08:40:53 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id rAE8ekt1072792 for ; Thu, 14 Nov 2013 00:40:50 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201311140840.rAE8ekt1072792@gw.catspoiler.org> Date: Thu, 14 Nov 2013 00:40:46 -0800 (PST) From: Don Lewis Subject: Re: CAM panic with tethered Virgin Mobile Mifi 2200 To: freebsd-current@FreeBSD.org In-Reply-To: <201311140129.rAE1TQnm070352@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 08:40:54 -0000 On 13 Nov, To: freebsd-current@freebsd.org wrote: > I've had a Virgin Mobile MiFi 2200 CDMA modem for a few years that I've > successfully been using in tethered mode on my 8-STABLE laptop. The > only issue is that I have to do a camcontrol eject to get it to switch > from being a umass device to being a modem. > > Today I decided to try to add this device to usbdevices and u3g, with > the U3GINIT_SCSIEJECT quirk so it would be more convenient to use. > > I plugged it into my 11-CURRENT machine to find it's ID. This showed > up in /var/log/messages: > > Nov 13 16:42:16 scratch kernel: ugen2.2: at usbus2 > Nov 13 16:42:16 scratch kernel: umass0: on usbus2 > Nov 13 16:42:16 scratch kernel: umass0: SCSI over Bulk-Only; quirks = 0x0100 > Nov 13 16:42:16 scratch kernel: umass0:9:0: Attached to scbus9 > Nov 13 16:42:16 scratch kernel: cd0 at umass-sim0 bus 0 scbus9 target 0 lun 0 > Nov 13 16:42:16 scratch kernel: cd0: Removable CD-ROM SCSI-2 device > Nov 13 16:42:16 scratch kernel: cd0: Serial Number 091166643730000 > Nov 13 16:42:16 scratch kernel: cd0: 1.000MB/s transfers > Nov 13 16:42:16 scratch kernel: cd0: Attempt to query device size failed: NOT READY, Medium not present > Nov 13 16:42:16 scratch kernel: cd0: quirks=0x10<10_BYTE_ONLY> > Nov 13 16:42:17 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 > Nov 13 16:42:17 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error > Nov 13 16:42:17 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition > Nov 13 16:42:17 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) > Nov 13 16:42:17 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) > Nov 13 16:42:17 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 > Nov 13 16:42:17 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error > Nov 13 16:42:17 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition > Nov 13 16:42:17 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) > Nov 13 16:42:17 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) > Nov 13 16:42:18 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 > Nov 13 16:42:18 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error > Nov 13 16:42:18 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition > Nov 13 16:42:18 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) > Nov 13 16:42:18 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) > Nov 13 16:42:18 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 > Nov 13 16:42:18 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error > Nov 13 16:42:18 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition > Nov 13 16:42:18 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) > Nov 13 16:42:18 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) > Nov 13 16:42:19 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 > Nov 13 16:42:19 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error > Nov 13 16:42:19 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition > Nov 13 16:42:19 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) > Nov 13 16:42:19 scratch kernel: (cd0:umass-sim0:0:0:0): Error 6, Retries exhausted > Nov 13 16:42:19 scratch kernel: (cd0:umass-sim0:0:0:0): cddone: got error 0x6 back > Nov 13 16:42:20 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 > Nov 13 16:42:20 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error > Nov 13 16:42:20 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition > Nov 13 16:42:20 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) > Nov 13 16:42:20 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) > Nov 13 16:42:21 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 > Nov 13 16:42:21 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error > Nov 13 16:42:21 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition > Nov 13 16:42:21 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) > Nov 13 16:42:21 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) > Nov 13 16:42:21 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 > Nov 13 16:42:21 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error > Nov 13 16:42:21 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition > Nov 13 16:42:21 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) > Nov 13 16:42:21 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) > Nov 13 16:42:22 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 > Nov 13 16:42:22 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error > Nov 13 16:42:22 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition > Nov 13 16:42:22 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) > Nov 13 16:42:22 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) > Nov 13 16:42:22 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 > Nov 13 16:42:22 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error > Nov 13 16:42:22 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition > Nov 13 16:42:22 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) > Nov 13 16:42:22 scratch kernel: (cd0:umass-sim0:0:0:0): Error 6, Retries exhausted > Nov 13 16:42:22 scratch kernel: (cd0:umass-sim0:0:0:0): cddone: got error 0x6 back > Nov 13 16:42:23 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 > Nov 13 16:42:23 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error > Nov 13 16:42:23 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition > Nov 13 16:42:23 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) > Nov 13 16:42:23 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) > Nov 13 16:42:24 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 > Nov 13 16:42:24 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error > Nov 13 16:42:24 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition > Nov 13 16:42:24 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) > Nov 13 16:42:24 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) > Nov 13 16:42:24 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 > Nov 13 16:42:24 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error > Nov 13 16:42:24 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition > Nov 13 16:42:24 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) > Nov 13 16:42:24 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) > Nov 13 16:42:25 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 > Nov 13 16:42:25 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error > Nov 13 16:42:25 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition > Nov 13 16:42:25 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) > Nov 13 16:42:25 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) > Nov 13 16:42:25 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 > Nov 13 16:42:25 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error > Nov 13 16:42:25 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition > Nov 13 16:42:25 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) > Nov 13 16:42:25 scratch kernel: (cd0:umass-sim0:0:0:0): Error 6, Retries exhausted > Nov 13 16:42:25 scratch kernel: (cd0:umass-sim0:0:0:0): cddone: got error 0x6 back > Nov 13 16:42:26 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 > Nov 13 16:42:26 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error > Nov 13 16:42:26 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition > Nov 13 16:42:26 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) > Nov 13 16:42:26 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) > Nov 13 16:42:27 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 > Nov 13 16:42:27 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error > Nov 13 16:42:27 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition > Nov 13 16:42:27 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) > Nov 13 16:42:27 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) > Nov 13 16:42:27 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 > Nov 13 16:42:27 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error > Nov 13 16:42:27 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition > Nov 13 16:42:27 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) > Nov 13 16:42:27 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) > Nov 13 16:42:28 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 > Nov 13 16:42:28 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error > Nov 13 16:42:28 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition > Nov 13 16:42:28 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) > Nov 13 16:42:28 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) > Nov 13 16:42:28 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 > Nov 13 16:42:28 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error > Nov 13 16:42:28 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition > Nov 13 16:42:28 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) > Nov 13 16:42:28 scratch kernel: (cd0:umass-sim0:0:0:0): Error 6, Retries exhausted > Nov 13 16:42:28 scratch kernel: (cd0:umass-sim0:0:0:0): cddone: got error 0x6 back > > > I'm assuming that the errors are caused by some missing quirk for the > umass device. > > A short while later, I got this panic, possibly triggered by doing > ls -l /dev/cd0 > > cd0 at umass-sim0 bus 0 scbus9 target 0 lun 0 > cd0: s/n 091166643730000 detached > (cd0:umass-sim0:0:0:0): Periph destroyed > panic: mtx_lock() of destroyed mutex @ /usr/src/sys/cam/cam_xpt.c:5251 > cpuid = 1 > KDB: stack backtrace: > db_trace_self_wrapper(c112eacc,a3135,10000000,e4f97b90,e4f97b88,...) at db_trace_self_wrapper+0x2d/frame 0xe4f97b50 > kdb_backtrace(c12eca4f,1,c1127e81,e4f97c28,e4f97bf8,...) at kdb_backtrace+0x30/frame 0xe4f97bb8 > vpanic(c140ca38,100,c1127e81,e4f97c28,e4f97c28,...) at vpanic+0x11f/frame 0xe4f97bf8 > kassert_panic(c1127e81,c0fee59f,1483,c0fee59f,0,...) at kassert_panic+0xea/frame 0xe4f97c1c > __mtx_lock_flags(c9a70ad0,0,c0fee59f,1483,c9a70ad0,...) at __mtx_lock_flags+0x153/frame 0xe4f97c50 > xpt_done_process(c13d2a10,0,c0fee59f,1499,0,...) at xpt_done_process+0x44f/frame 0xe4f97c80 > xpt_done_td(c13d2a00,e4f97d08,c1123cf4,3db,0,...) at xpt_done_td+0x164/frame 0xe4f97ccc > fork_exit(c04c7b80,c13d2a00,e4f97d08) at fork_exit+0x7f/frame 0xe4f97cf4 > fork_trampoline() at fork_trampoline+0x8/frame 0xe4f97cf4 > --- trap 0, eip = 0, esp = 0xe4f97d40, ebp = 0 --- > KDB: enter: panic > > I've got the vmcore file, so I can extract more info from it if > necessary. > > > This is what I see when I plug it into my 8.4-STABLE laptop: > > umass0: on usbus1 > umass0: SCSI over Bulk-Only; quirks = 0x0100 > umass0:2:0:-1: Attached to scbus2 > (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 00 00 00 00 00 00 > (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error > (probe0:umass-sim0:0:0:0): SCSI status: Check Condition > (probe0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) > cd1 at umass-sim0 bus 0 scbus2 target 0 lun 0 > cd1: Removable CD-ROM SCSI-2 device > cd1: 1.000MB/s transfers > cd1: Attempt to query device size failed: NOT READY, Medium not present > cd1: quirks=0x10<10_BYTE_ONLY> I discovered that if I just wait a while (about 10 minutes), the umass device on my laptop will just go away by itself and the u3g device will appear: ugen1.2: at usbus1 (disconnected) umass0: at uhub1, port 1, addr 2 (disconnected) (cd1:umass-sim0:0:0:0): lost device (cd1:umass-sim0:0:0:0): removing device entry That might be what triggered the panic on my 11-CURRENT box. If I add this quirk on my 11-CURRENT box, the CAM errors above go away, and the panic seems to go away as well: Index: dev/usb/quirk/usb_quirk.c =================================================================== --- dev/usb/quirk/usb_quirk.c (revision 258079) +++ dev/usb/quirk/usb_quirk.c (working copy) @@ -288,6 +288,7 @@ UQ_MSC_NO_INQUIRY), USB_QUIRK(NIKON, D300, 0x0000, 0xffff, UQ_MSC_FORCE_WIRE_BBB, UQ_MSC_FORCE_PROTO_SCSI), + USB_QUIRK(NOVATEL, MIFI2200V, 0x0000, 0xffff, UQ_MSC_NO_PREVENT_ALLOW), USB_QUIRK(OLYMPUS, C1, 0x0000, 0xffff, UQ_MSC_FORCE_WIRE_BBB, UQ_MSC_FORCE_PROTO_SCSI, UQ_MSC_WRONG_CSWSIG), USB_QUIRK(OLYMPUS, C700, 0x0000, 0xffff, UQ_MSC_NO_GETMAXLUN), Index: dev/usb/usbdevs =================================================================== --- dev/usb/usbdevs (revision 258079) +++ dev/usb/usbdevs (working copy) @@ -3174,6 +3174,7 @@ product NOVATEL U727 0x4100 Merlin U727 CDMA product NOVATEL MC950D 0x4400 Novatel MC950D HSUPA product NOVATEL ZEROCD 0x5010 Novatel ZeroCD +product NOVATEL MIFI2200V 0x5020 Novatel MiFi 2200 CDMA Virgin Mobile product NOVATEL ZEROCD2 0x5030 Novatel ZeroCD product NOVATEL MIFI2200 0x5041 Novatel MiFi 2200 CDMA product NOVATEL U727_2 0x5100 Merlin U727 CDMA Now I see this: ugen2.2: at usbus2 umass0: on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x8100 umass0:9:0: Attached to scbus9 cd0 at umass-sim0 bus 0 scbus9 target 0 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: Serial Number 091166643730000 cd0: 1.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present cd0: quirks=0x10<10_BYTE_ONLY> [long pause] ugen2.2: at usbus2 (disconnected) umass0: at uhub0, port 1, addr 2 (disconnected) cd0 at umass-sim0 bus 0 scbus9 target 0 lun 0 cd0: s/n 091166643730000 detached (cd0:umass-sim0:0:0:0): Periph destroyed usb_alloc_device: set address 2 failed (USB_ERR_IOERROR, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR ugen2.2: at usbus2 u3g0: on usbus2 u3g0: Found 3 ports. I'm getting some new USB errors, but they seem to be harmless. Next I tried adding this quirk to trigger the eject, but I still see a 10 minute pause before the umass device goes away and the u3g device shows up. Index: dev/usb/serial/u3g.c =================================================================== --- dev/usb/serial/u3g.c (revision 258079) +++ dev/usb/serial/u3g.c (working copy) @@ -345,6 +345,7 @@ U3G_DEV(NOVATEL, MC547, 0), U3G_DEV(NOVATEL, MC950D, 0), U3G_DEV(NOVATEL, MIFI2200, U3GINIT_SCSIEJECT), + U3G_DEV(NOVATEL, MIFI2200V, U3GINIT_SCSIEJECT), U3G_DEV(NOVATEL, U720, 0), U3G_DEV(NOVATEL, U727, 0), U3G_DEV(NOVATEL, U727_2, 0), Hmn ... From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 08:48:34 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 85BF7F4F; Thu, 14 Nov 2013 08:48:34 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 42DD52797; Thu, 14 Nov 2013 08:48:34 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAE8mXou093223; Thu, 14 Nov 2013 03:48:33 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAE8mXqQ093222; Thu, 14 Nov 2013 08:48:33 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 14 Nov 2013 08:48:33 GMT Message-Id: <201311140848.rAE8mXqQ093222@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 08:48:34 -0000 TB --- 2013-11-14 06:00:18 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-14 06:00:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-14 06:00:18 - starting HEAD tinderbox run for i386/i386 TB --- 2013-11-14 06:00:18 - cleaning the object tree TB --- 2013-11-14 06:00:18 - /usr/local/bin/svn stat /src TB --- 2013-11-14 06:00:23 - At svn revision 258116 TB --- 2013-11-14 06:00:24 - building world TB --- 2013-11-14 06:00:24 - CROSS_BUILD_TESTING=YES TB --- 2013-11-14 06:00:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-14 06:00:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-14 06:00:24 - SRCCONF=/dev/null TB --- 2013-11-14 06:00:24 - TARGET=i386 TB --- 2013-11-14 06:00:24 - TARGET_ARCH=i386 TB --- 2013-11-14 06:00:24 - TZ=UTC TB --- 2013-11-14 06:00:24 - __MAKE_CONF=/dev/null TB --- 2013-11-14 06:00:24 - cd /src TB --- 2013-11-14 06:00:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Nov 14 06:00:31 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] c++ -O2 -pipe -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-c++11-extensions -I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc:782:11: error: format string is empty [-Werror,-Wformat-zero-length] "", option.get_size_type()); ^~ /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc:1910:11: error: format string is empty [-Werror,-Wformat-zero-length] "", option.get_size_type()); ^~ 2 errors generated. *** Error code 1 Stop. bmake[4]: stopped in /src/gnu/usr.bin/gperf *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/usr.bin *** Error code 1 Stop. bmake[2]: stopped in /src/gnu *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-14 08:48:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-14 08:48:33 - ERROR: failed to build world TB --- 2013-11-14 08:48:33 - 8315.08 user 1341.48 system 10094.46 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 08:48:34 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A9607F50; Thu, 14 Nov 2013 08:48:34 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 669842798; Thu, 14 Nov 2013 08:48:34 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAE8mXtH093235; Thu, 14 Nov 2013 03:48:33 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAE8mXN9093231; Thu, 14 Nov 2013 08:48:33 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 14 Nov 2013 08:48:33 GMT Message-Id: <201311140848.rAE8mXN9093231@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 08:48:34 -0000 TB --- 2013-11-14 06:00:18 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-14 06:00:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-14 06:00:18 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-11-14 06:00:18 - cleaning the object tree TB --- 2013-11-14 06:00:18 - /usr/local/bin/svn stat /src TB --- 2013-11-14 06:00:23 - At svn revision 258116 TB --- 2013-11-14 06:00:24 - building world TB --- 2013-11-14 06:00:24 - CROSS_BUILD_TESTING=YES TB --- 2013-11-14 06:00:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-14 06:00:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-14 06:00:24 - SRCCONF=/dev/null TB --- 2013-11-14 06:00:24 - TARGET=amd64 TB --- 2013-11-14 06:00:24 - TARGET_ARCH=amd64 TB --- 2013-11-14 06:00:24 - TZ=UTC TB --- 2013-11-14 06:00:24 - __MAKE_CONF=/dev/null TB --- 2013-11-14 06:00:24 - cd /src TB --- 2013-11-14 06:00:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Nov 14 06:00:30 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] c++ -O2 -pipe -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-c++11-extensions -I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc:782:11: error: format string is empty [-Werror,-Wformat-zero-length] "", option.get_size_type()); ^~ /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc:1910:11: error: format string is empty [-Werror,-Wformat-zero-length] "", option.get_size_type()); ^~ 2 errors generated. *** Error code 1 Stop. bmake[4]: stopped in /src/gnu/usr.bin/gperf *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/usr.bin *** Error code 1 Stop. bmake[2]: stopped in /src/gnu *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-14 08:48:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-14 08:48:33 - ERROR: failed to build world TB --- 2013-11-14 08:48:33 - 8314.66 user 1318.48 system 10094.80 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 09:55:08 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70777F38; Thu, 14 Nov 2013 09:55:08 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3D6882BC8; Thu, 14 Nov 2013 09:55:07 +0000 (UTC) Received: from [192.168.0.2] (cpc27-cmbg15-2-0-cust235.5-4.cable.virginm.net [86.27.188.236]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id rAE9suHS019937 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Nov 2013 09:54:59 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: libc++ vs. libstdc++ usage in the ports tree From: David Chisnall In-Reply-To: <352D9465-9840-43F0-A3A9-327DC12B0967@FreeBSD.org> Date: Thu, 14 Nov 2013 09:54:52 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131112163219.GA2834@troutmask.apl.washington.edu> <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> <20131112175556.GA3319@troutmask.apl.washington.edu> <20131112201922.GA4330@troutmask.apl.washington.edu> <20131113173143.Horde.a-9M7JQ_vHo3tpDIMsGK6g1@webmail.df.eu> <5283CA3C.3080201@FreeBSD.org> <352D9465-9840-43F0-A3A9-327DC12B0967@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.1508) Cc: FreeBSD Current , Ryan Stone , Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 09:55:08 -0000 On 13 Nov 2013, at 19:40, Dimitry Andric wrote: > On the other hand, different C++ standard libraries simply cannot be > mixed. The internal implementations are usually completely different. > This is not really news at all, certainly not to the ports people. :-) That said, it should still be possible to mix them in different = libraries. The constraint from the wiki still applies: if you don't use STL types = at library boundaries, then it should still work. If you do, then the = libc++ and libstdc++ symbols will be mangled differently and so you will = get link-time errors. In theory, if it links it should run... David From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 10:02:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DCFB725C for ; Thu, 14 Nov 2013 10:02:58 +0000 (UTC) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0D4132C7D for ; Thu, 14 Nov 2013 10:02:57 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id u57so1167184wes.37 for ; Thu, 14 Nov 2013 02:02:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=u/xmcf3vYPQe/bfuvztaMqB2H6Nhatv2qtgWntRyU0c=; b=WMIGXGMjhnBNS/IsnsXg1OGkfWL9cl6YM/tSQOg8UyvaIKISWxSEAFivyODSxrX7vs yZf+pM7JYoy+EQ/zIjn3wR4CNBSxDp1GciT8WFQ6joCWbI24Ck/Itz+wOMjLKpWhBt7q 5kpSfKGLNGiRwUimvBoro03ZIwigxMQizRtMXquJAd5KoxfD4+uF86z3NxixYY3FuO+B C81YeXaA21ZLLOv8s2AQtDMj7LOOHtf9ERBjlNV22Sf/aU1FeSEPryD6ctURUH1lkHG5 8Y0JW/yRfdKn9EBccfanYSUHeLIhOw5Jw7qWkWZZlqkU7UakO6F8rB31fbTewS0Xy8e5 RcJw== X-Gm-Message-State: ALoCoQnwOZpfd/m7tmYBDqFV6tJ1XBdQlBo0Ju1npqlT4xINguIT0CRAY8CFIg+JQ76bR6N6Cs2B MIME-Version: 1.0 X-Received: by 10.180.37.134 with SMTP id y6mr1541091wij.48.1384423369528; Thu, 14 Nov 2013 02:02:49 -0800 (PST) Received: by 10.14.100.135 with HTTP; Thu, 14 Nov 2013 02:02:49 -0800 (PST) Date: Thu, 14 Nov 2013 11:02:49 +0100 Message-ID: Subject: bind9 remnants From: Olivier Smedts To: "freebsd-current@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: glebius@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 10:02:59 -0000 Hello, cc'ing glebius since he committed r257694 ("Remove remnants of BIND from /etc, since there is no BIND in base now.") which removed remnants of BIND from /etc but not from /usr/src/etc. Can we please remove bind9 references from etc/mtree/BSD.usr.dist ? /usr/share/doc/bind9, /usr/share/doc/bind9/arm and /usr/share/doc/bind9/misc are constantly re-created during a "make installworld" or "make hierarchy" and are then removed by "make delete-old". I'm using stable/10 right now, where r257694 has been MFCed as r258121. # cd /usr/src # mkdir /tmp/test # make hierarchy DESTDIR=/tmp/test # make check-old DESTDIR=/tmp/test >>> Checking for old files >>> Checking for old libraries >>> Checking for old directories /tmp/test/usr/share/doc/bind9 /tmp/test/usr/share/doc/bind9/arm /tmp/test/usr/share/doc/bind9/misc To remove old files and directories run 'make delete-old'. To remove old libraries run 'make delete-old-libs'. Thanks ! -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 10:30:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1EB183F; Thu, 14 Nov 2013 10:30:03 +0000 (UTC) Received: from owm.eumx.net (eumx.net [91.82.101.43]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8DE892DDC; Thu, 14 Nov 2013 10:30:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=eumx.net; h=date :message-id:from:to:cc:subject:references:in-reply-to :content-type:mime-version; s=default; bh=QnY7eGZ0by/i5bcJb11BCp R2hI0=; b=uRLm4cfhf92cRj9dUZsJcKqM6tyJA1eGTxOyiCaZyggk9SLjBT/w1h OTgBaSCm8su3CPnyHecJs8zhIzCE9xXM6h56xsbpoj3oCbSPpaI+7GevNhv+fK90 HxBKMvHfHz03LRf2BcmkLv1Viu8a+TUYHsvAbpEW9F3B2hM96eT9A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=eumx.net; h=date:message-id :from:to:cc:subject:references:in-reply-to:content-type :mime-version; q=dns; s=default; b=ycEx+ZLUSRpNaNcOGlt/9Y2Q7kP7Q a34yvQZDDS3zCktNVeCx47ElvKDq21qXs5JwnaPJPisYBPmQe2sHglmGTdUZFakA dqF2IuZoM5rPbUJA0WVSqsz/JiDMqJUuSKJnSNmOAT5cID9SKvdaTHcueU09dBdF hlSrWnHXOuAKOM= Date: Thu, 14 Nov 2013 10:29:50 +0000 Message-ID: <20131114102950.Horde.uCQ5LSTB66L6bzvi29QHlw1@ssl.eumx.net> From: "Herbert J. Skuhra" To: Olivier Smedts Subject: Re: bind9 remnants References: In-Reply-To: User-Agent: Internet Messaging Program (IMP) H5 (6.1.4) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Cc: "freebsd-current@freebsd.org" , glebius@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 10:30:03 -0000 to. 14. nov. 2013 kl. 11.02 +0100 skrev Olivier Smedts: > Hello, > > cc'ing glebius since he committed r257694 ("Remove remnants of BIND from > /etc, since there is no BIND in base now.") which removed remnants of BIND > from /etc but not from /usr/src/etc. > > Can we please remove bind9 references from etc/mtree/BSD.usr.dist ? > /usr/share/doc/bind9, /usr/share/doc/bind9/arm and > /usr/share/doc/bind9/misc are constantly re-created during a "make > installworld" or "make hierarchy" and are then removed by "make > delete-old". I'm using stable/10 right now, where r257694 has been MFCed as > r258121. It's already in HEAD: http://svnweb.freebsd.org/base?view=revision&revision=256769 -- Herbert From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 10:38:57 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D8DB8BDE; Thu, 14 Nov 2013 10:38:57 +0000 (UTC) Received: from mailrelay010.isp.belgacom.be (mailrelay010.isp.belgacom.be [195.238.6.177]) by mx1.freebsd.org (Postfix) with ESMTP id 4552E2E83; Thu, 14 Nov 2013 10:38:56 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAGAJ2nhFJbsLPN/2dsb2JhbABagwfAK4EgF3SCJQEBBScvIxALGAklDyoeBgESh28DEwHAD4xtgnIHhDEDkDCHX5INgyk7 Received: from 205.179-176-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.176.179.205]) by relay.skynet.be with ESMTP; 14 Nov 2013 11:38:48 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.7/8.14.7) with ESMTP id rAEAclq8001970; Thu, 14 Nov 2013 11:38:47 +0100 (CET) (envelope-from tijl@FreeBSD.org) Date: Thu, 14 Nov 2013 11:38:46 +0100 From: Tijl Coosemans To: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= , dt71@gmx.com Subject: Re: new Xorg (KMS, etc.) for Radeon 9600 Message-ID: <20131114113846.4dcb2037@kalimero.tijl.coosemans.org> In-Reply-To: <5283E123.5000305@FreeBSD.org> References: <527F95BE.7080908@gmx.com> <527FC05D.8080703@gmx.com> <5283E123.5000305@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/pp3RINC0rlEZsakB5e13j9s" Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 10:38:57 -0000 --MP_/pp3RINC0rlEZsakB5e13j9s Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 13 Nov 2013 21:29:23 +0100 Jean-S=E9bastien P=E9dron wrote: > Le 10/11/2013 18:20, dt71@gmx.com a =E9crit : >> drmn0: info: GTT: 0M 0xF0000000 - 0xEFFFFFFF >=20 > Tijl Coosemans is right, the problem is this line. >=20 > As I don't really now how AGP works and have no AGP hardware to=20 > reproduce the problem, can you post the output of the following commands= =20 > as a start? > pciconf -lvbce > devinfo -vr The attached patch should fix it, but I haven't been able to test it yet. The ai_aperture_size field is in bytes. --MP_/pp3RINC0rlEZsakB5e13j9s Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=radeon_agp.patch Index: sys/dev/drm2/radeon/radeon_agp.c =================================================================== --- sys/dev/drm2/radeon/radeon_agp.c (revision 258128) +++ sys/dev/drm2/radeon/radeon_agp.c (working copy) @@ -153,11 +153,11 @@ int radeon_agp_init(struct radeon_device return ret; } - if (rdev->ddev->agp->info.ai_aperture_size < 32) { + if (rdev->ddev->agp->info.ai_aperture_size < (32 << 20)) { drm_agp_release(rdev->ddev); dev_warn(rdev->dev, "AGP aperture too small (%zuM) " "need at least 32M, disabling AGP\n", - rdev->ddev->agp->info.ai_aperture_size); + rdev->ddev->agp->info.ai_aperture_size >> 20); return -EINVAL; } @@ -246,7 +246,7 @@ int radeon_agp_init(struct radeon_device } rdev->mc.agp_base = rdev->ddev->agp->info.ai_aperture_base; - rdev->mc.gtt_size = rdev->ddev->agp->info.ai_aperture_size << 20; + rdev->mc.gtt_size = rdev->ddev->agp->info.ai_aperture_size; rdev->mc.gtt_start = rdev->mc.agp_base; rdev->mc.gtt_end = rdev->mc.gtt_start + rdev->mc.gtt_size - 1; dev_info(rdev->dev, "GTT: %juM 0x%08jX - 0x%08jX\n", --MP_/pp3RINC0rlEZsakB5e13j9s-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 10:59:00 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D16D4E2 for ; Thu, 14 Nov 2013 10:59:00 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 238772FBC for ; Thu, 14 Nov 2013 10:59:00 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id E402D7300A; Thu, 14 Nov 2013 12:01:07 +0100 (CET) Date: Thu, 14 Nov 2013 12:01:07 +0100 From: Luigi Rizzo To: current@freebsd.org Subject: RFC: adding queue number/size fields to ifnet Message-ID: <20131114110107.GA36421@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 10:59:00 -0000 Hi, it would be useful to have a common place with the indication of NIC parameters such as number of tx/rx queues and their lengths. Various 10G drivers do include this information in various places in the softc, but there is no common place. I was wondering if there is any objection to either or both of these options: 1. four fields to the struct ifnet (field names are bikeshed material and irrelevant for the discussion): if_tx_queues, if_rx_queues, if_tx_slots, if_rx_slots 2. a sysctl-like get/set method for key-value pairs (key is always a string, value is possibly one of a few simple types such as INT64, UINT64, STRING) so that we extend the system in the future, e.g. to handle RSS, flow control and whatnot. Of course this also requires to settle on names of features. This is meant for low-frequency access to the parameters of the device, so performance is not an issue. cheers luigi From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 11:37:11 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E461AA61; Thu, 14 Nov 2013 11:37:10 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A25D922C2; Thu, 14 Nov 2013 11:37:10 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAEBb9fd088155; Thu, 14 Nov 2013 06:37:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAEBb9M7088131; Thu, 14 Nov 2013 11:37:09 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 14 Nov 2013 11:37:09 GMT Message-Id: <201311141137.rAEBb9M7088131@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 11:37:11 -0000 TB --- 2013-11-14 08:39:43 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-14 08:39:43 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-14 08:39:43 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-11-14 08:39:43 - cleaning the object tree TB --- 2013-11-14 08:39:43 - /usr/local/bin/svn stat /src TB --- 2013-11-14 08:39:56 - At svn revision 258116 TB --- 2013-11-14 08:39:57 - building world TB --- 2013-11-14 08:39:57 - CROSS_BUILD_TESTING=YES TB --- 2013-11-14 08:39:57 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-14 08:39:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-14 08:39:57 - SRCCONF=/dev/null TB --- 2013-11-14 08:39:57 - TARGET=pc98 TB --- 2013-11-14 08:39:57 - TARGET_ARCH=i386 TB --- 2013-11-14 08:39:57 - TZ=UTC TB --- 2013-11-14 08:39:57 - __MAKE_CONF=/dev/null TB --- 2013-11-14 08:39:57 - cd /src TB --- 2013-11-14 08:39:57 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Nov 14 08:40:05 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] c++ -O2 -pipe -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-c++11-extensions -I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc:782:11: error: format string is empty [-Werror,-Wformat-zero-length] "", option.get_size_type()); ^~ /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc:1910:11: error: format string is empty [-Werror,-Wformat-zero-length] "", option.get_size_type()); ^~ 2 errors generated. *** Error code 1 Stop. bmake[4]: stopped in /src/gnu/usr.bin/gperf *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/usr.bin *** Error code 1 Stop. bmake[2]: stopped in /src/gnu *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-14 11:37:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-14 11:37:09 - ERROR: failed to build world TB --- 2013-11-14 11:37:09 - 8833.15 user 1118.12 system 10645.61 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 11:49:40 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 614EEDA8; Thu, 14 Nov 2013 11:49:40 +0000 (UTC) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 09C882365; Thu, 14 Nov 2013 11:49:39 +0000 (UTC) Received: from gate.nw-fva.de ([134.76.242.1] helo=pc028.nfv) by mailer.gwdg.de with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1VgvQR-00019z-C1; Thu, 14 Nov 2013 12:49:31 +0100 Message-ID: <5284B8C7.6070701@gwdg.de> Date: Thu, 14 Nov 2013 12:49:27 +0100 From: Rainer Hurling User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: David Chisnall , Dimitry Andric Subject: Re: libc++ vs. libstdc++ usage in the ports tree References: <20131112163219.GA2834@troutmask.apl.washington.edu> <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> <20131112175556.GA3319@troutmask.apl.washington.edu> <20131112201922.GA4330@troutmask.apl.washington.edu> <20131113173143.Horde.a-9M7JQ_vHo3tpDIMsGK6g1@webmail.df.eu> <5283CA3C.3080201@FreeBSD.org> <352D9465-9840-43F0-A3A9-327DC12B0967@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: FreeBSD Current , Ryan Stone , Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 11:49:40 -0000 Am 14.11.2013 10:54 (UTC+1) schrieb David Chisnall: > On 13 Nov 2013, at 19:40, Dimitry Andric wrote: > >> On the other hand, different C++ standard libraries simply cannot be >> mixed. The internal implementations are usually completely different. >> This is not really news at all, certainly not to the ports people. :-) > > That said, it should still be possible to mix them in different libraries. > The constraint from the wiki still applies: if you don't use STL types at library boundaries, then it should still work. If you do, then the libc++ and libstdc++ symbols will be mangled differently and so you will get link-time errors. > > In theory, if it links it should run... > > David With the in this thread described change of the behaviour in 10.x and HEAD, I have massive problems with building my port math/saga. Before the changes, all built and worked fine. Now, even when I add USES= compiler:openmp CXXFLAGS+= -std=gnu++0x and commenting out USE_GCC=any in the Makefile of math/saga, the build breaks with problems between x11-toolkits/wxgtk29 (build with clang) and math/saga (try to build with gcc46), see below, please. I am clueless, what to do here. Building x11-toolkits/wxgtk29 with gcc46+ is not an option. Any help is really appreciated, Rainer Hurling make -D MAKE_JOBS_UNSAFE=yes ===> Building for saga-2.1.0_2 --- all --- /usr/bin/make all-recursive --- all-recursive --- Making all in . Making all in src --- all-recursive --- Making all in saga_core --- all-recursive --- Making all in saga_api Making all in saga_odbc Making all in saga_gdi Making all in saga_cmd --- all-recursive --- Making all in man Making all in saga_gui --- all-recursive --- Making all in man --- saga_gui --- /bin/sh ../../../libtool --tag=CXX --mode=link g++46 -fPIC -D_SAGA_LINUX -D_TYPEDEF_BYTE -D_TYPEDEF_WORD -D_SAGA_DONOTUSE_HARU -D"MODULE_LIBRARY_PATH=\"/usr/local/lib/saga\"" -D"SHARE_PATH=\"/usr/local/share/saga\"" -I.. -I. `/usr/local/bin/wxgtk2u-2.9-config --unicode=yes --cxxflags` -D_SAGA_UNICODE -fopenmp -O2 -pipe -I/usr/local/include -Wl,-rpath=/usr/local/lib/gcc46 -fno-strict-aliasing -std=gnu++0x -Wl,-rpath=/usr/local/lib/gcc46 -fPIC `/usr/local/bin/wxgtk2u-2.9-config --unicode=yes --libs adv,aui,base,core,html,net,propgrid,xml` -L/usr/local/lib -lopencv_core -pthread -Wl,-rpath=/usr/local/lib/gcc46 -o saga_gui active.o active_attributes.o active_description.o active_history.o active_HTMLExtraInfo.o active_legend.o active_parameters.o callback.o data_source.o data_source_files.o data_source_odbc.o dc_helper.o dlg_about.o dlg_about_logo.o dlg_base.o dlg_colors.o dlg_colors_control.o dlg_list_base.o dlg_list_grid.o dlg_list_pointcloud.o dlg_list_shapes.o dlg_list_table.o dlg_list_tin.o dlg_parameters.o dlg_table.o dlg_text.o helper.o info.o info_messages.o parameters_control.o parameters_properties.o project.o res_commands.o res_controls.o res_dialogs.o res_images.o saga.o saga_frame.o saga_frame_droptarget.o view_base.o view_histogram.o view_layout.o view_layout_control.o view_layout_info.o view_layout_printout.o view_map.o view_map_3d.o view_map_3d_image.o view_map_control.o view_ruler.o view_scatterplot.o view_table.o view_table_control.o view_table_diagram.o wksp.o wksp_base_control.o wksp_base_item.o wksp_base_manager.o wksp_data_control.o wksp_data_item.o wksp_data_layers.o wksp_data_manager.o wksp_data_menu_file.o wksp_data_menu_files.o wksp_grid.o wksp_grid_manager.o wksp_grid_system.o wksp_layer.o wksp_layer_classify.o wksp_layer_legend.o wksp_map.o wksp_map_buttons.o wksp_map_control.o wksp_map_dc.o wksp_map_layer.o wksp_map_manager.o wksp_module.o wksp_module_control.o wksp_module_library.o wksp_module_manager.o wksp_module_menu.o wksp_pointcloud.o wksp_pointcloud_manager.o wksp_shapes.o wksp_shapes_edit.o wksp_shapes_line.o wksp_shapes_manager.o wksp_shapes_point.o wksp_shapes_points.o wksp_shapes_polygon.o wksp_shapes_type.o wksp_table.o wksp_table_manager.o wksp_tin.o wksp_tin_manager.o ../saga_api/libsaga_api.la ../saga_odbc/libsaga_odbc.la libtool: link: g++46 -fPIC -D_SAGA_LINUX -D_TYPEDEF_BYTE -D_TYPEDEF_WORD -D_SAGA_DONOTUSE_HARU -DMODULE_LIBRARY_PATH=\"/usr/local/lib/saga\" -DSHARE_PATH=\"/usr/local/share/saga\" -I.. -I. -I/usr/local/lib/wx/include/gtk2-unicode-2.9 -I/usr/local/include/wx-2.9 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread -D_THREAD_SAFE -D_SAGA_UNICODE -fopenmp -O2 -pipe -I/usr/local/include -Wl,-rpath=/usr/local/lib/gcc46 -fno-strict-aliasing -std=gnu++0x -Wl,-rpath=/usr/local/lib/gcc46 -fPIC -pthread -pthread -Wl,-rpath=/usr/local/lib/gcc46 -o .libs/saga_gui active.o active_attributes.o active_description.o active_history.o active_HTMLExtraInfo.o active_legend.o active_parameters.o callback.o data_source.o data_source_files.o data_source_odbc.o dc_helper.o dlg_about.o dlg_about_logo.o dlg_base.o dlg_colors.o dlg_colors_control.o dlg_list_base.o dlg_list_grid.o dlg_list_pointcloud.o dlg_list_shapes.o dlg_list_table.o dlg_list_tin.o dlg_parameters.o dlg_table.o dlg_text.o helper.o info.o info_messages.o parameters_control.o parameters_properties.o project.o res_commands.o res_controls.o res_dialogs.o res_images.o saga.o saga_frame.o saga_frame_droptarget.o view_base.o view_histogram.o view_layout.o view_layout_control.o view_layout_info.o view_layout_printout.o view_map.o view_map_3d.o view_map_3d_image.o view_map_control.o view_ruler.o view_scatterplot.o view_table.o view_table_control.o view_table_diagram.o wksp.o wksp_base_control.o wksp_base_item.o wksp_base_manager.o wksp_data_control.o wksp_data_item.o wksp_data_layers.o wksp_data_manager.o wksp_data_menu_file.o wksp_data_menu_files.o wksp_grid.o wksp_grid_manager.o wksp_grid_system.o wksp_layer.o wksp_layer_classify.o wksp_layer_legend.o wksp_map.o wksp_map_buttons.o wksp_map_control.o wksp_map_dc.o wksp_map_layer.o wksp_map_manager.o wksp_module.o wksp_module_control.o wksp_module_library.o wksp_module_manager.o wksp_module_menu.o wksp_pointcloud.o wksp_pointcloud_manager.o wksp_shapes.o wksp_shapes_edit.o wksp_shapes_line.o wksp_shapes_manager.o wksp_shapes_point.o wksp_shapes_points.o wksp_shapes_polygon.o wksp_shapes_type.o wksp_table.o wksp_table_manager.o wksp_tin.o wksp_tin_manager.o -L/usr/local/lib -lwx_gtk2u_aui-2.9 -lwx_gtk2u_propgrid-2.9 ../saga_api/.libs/libsaga_api.so -L/usr/lib ../saga_odbc/.libs/libsaga_odbc.so -lodbc /usr/ports/math/saga/work/saga_2.1.0_src/src/saga_core/saga_api/.libs/libsaga_api.so -lwx_gtk2u_xrc-2.9 -lwx_gtk2u_webview-2.9 -lwx_gtk2u_html-2.9 -lwx_gtk2u_qa-2.9 -lwx_gtk2u_adv-2.9 -lwx_gtk2u_core-2.9 -lwx_baseu_xml-2.9 -lwx_baseu_net-2.9 -lwx_baseu-2.9 /usr/local/lib/libhpdf.so -lm -lz -lpng -lopencv_core -fopenmp -pthread -Wl,-rpath -Wl,/usr/local/lib active_description.o:(.data.rel.ro._ZTV19CACTIVE_Description[vtable for CACTIVE_Description]+0x740): undefined reference to `non-virtual thunk to wxHtmlWindow::SetHTMLWindowTitle(wxString const&)' active_description.o:(.data.rel.ro._ZTV19CACTIVE_Description[vtable for CACTIVE_Description]+0x748): undefined reference to `non-virtual thunk to wxHtmlWindow::OnHTMLLinkClicked(wxHtmlLinkInfo const&)' active_description.o:(.data.rel.ro._ZTV19CACTIVE_Description[vtable for CACTIVE_Description]+0x750): undefined reference to `non-virtual thunk to wxHtmlWindow::OnHTMLOpeningURL(wxHtmlURLType, wxString const&, wxString*) const' active_description.o:(.data.rel.ro._ZTV19CACTIVE_Description[vtable for CACTIVE_Description]+0x758): undefined reference to `non-virtual thunk to wxHtmlWindow::HTMLCoordsToWindow(wxHtmlCell*, wxPoint const&) const' active_description.o:(.data.rel.ro._ZTV19CACTIVE_Description[vtable for CACTIVE_Description]+0x760): undefined reference to `non-virtual thunk to wxHtmlWindow::GetHTMLWindow()' active_description.o:(.data.rel.ro._ZTV19CACTIVE_Description[vtable for CACTIVE_Description]+0x768): undefined reference to `non-virtual thunk to wxHtmlWindow::GetHTMLBackgroundColour() const' active_description.o:(.data.rel.ro._ZTV19CACTIVE_Description[vtable for CACTIVE_Description]+0x770): undefined reference to `non-virtual thunk to wxHtmlWindow::SetHTMLBackgroundColour(wxColour const&)' active_description.o:(.data.rel.ro._ZTV19CACTIVE_Description[vtable for CACTIVE_Description]+0x778): undefined reference to `non-virtual thunk to wxHtmlWindow::SetHTMLBackgroundImage(wxBitmap const&)' active_description.o:(.data.rel.ro._ZTV19CACTIVE_Description[vtable for CACTIVE_Description]+0x780): undefined reference to `non-virtual thunk to wxHtmlWindow::SetHTMLStatusText(wxString const&)' active_description.o:(.data.rel.ro._ZTV19CACTIVE_Description[vtable for CACTIVE_Description]+0x788): undefined reference to `non-virtual thunk to wxHtmlWindow::GetHTMLCursor(wxHtmlWindowInterface::HTMLCursor) const' active_HTMLExtraInfo.o:(.data.rel.ro._ZTV21CACTIVE_HTMLExtraInfo[vtable for CACTIVE_HTMLExtraInfo]+0x740): undefined reference to `non-virtual thunk to wxHtmlWindow::SetHTMLWindowTitle(wxString const&)' active_HTMLExtraInfo.o:(.data.rel.ro._ZTV21CACTIVE_HTMLExtraInfo[vtable for CACTIVE_HTMLExtraInfo]+0x748): undefined reference to `non-virtual thunk to wxHtmlWindow::OnHTMLLinkClicked(wxHtmlLinkInfo const&)' active_HTMLExtraInfo.o:(.data.rel.ro._ZTV21CACTIVE_HTMLExtraInfo[vtable for CACTIVE_HTMLExtraInfo]+0x750): undefined reference to `non-virtual thunk to wxHtmlWindow::OnHTMLOpeningURL(wxHtmlURLType, wxString const&, wxString*) const' active_HTMLExtraInfo.o:(.data.rel.ro._ZTV21CACTIVE_HTMLExtraInfo[vtable for CACTIVE_HTMLExtraInfo]+0x758): undefined reference to `non-virtual thunk to wxHtmlWindow::HTMLCoordsToWindow(wxHtmlCell*, wxPoint const&) const' active_HTMLExtraInfo.o:(.data.rel.ro._ZTV21CACTIVE_HTMLExtraInfo[vtable for CACTIVE_HTMLExtraInfo]+0x760): undefined reference to `non-virtual thunk to wxHtmlWindow::GetHTMLWindow()' active_HTMLExtraInfo.o:(.data.rel.ro._ZTV21CACTIVE_HTMLExtraInfo[vtable for CACTIVE_HTMLExtraInfo]+0x768): undefined reference to `non-virtual thunk to wxHtmlWindow::GetHTMLBackgroundColour() const' active_HTMLExtraInfo.o:(.data.rel.ro._ZTV21CACTIVE_HTMLExtraInfo[vtable for CACTIVE_HTMLExtraInfo]+0x770): undefined reference to `non-virtual thunk to wxHtmlWindow::SetHTMLBackgroundColour(wxColour const&)' active_HTMLExtraInfo.o:(.data.rel.ro._ZTV21CACTIVE_HTMLExtraInfo[vtable for CACTIVE_HTMLExtraInfo]+0x778): undefined reference to `non-virtual thunk to wxHtmlWindow::SetHTMLBackgroundImage(wxBitmap const&)' active_HTMLExtraInfo.o:(.data.rel.ro._ZTV21CACTIVE_HTMLExtraInfo[vtable for CACTIVE_HTMLExtraInfo]+0x780): undefined reference to `non-virtual thunk to wxHtmlWindow::SetHTMLStatusText(wxString const&)' active_HTMLExtraInfo.o:(.data.rel.ro._ZTV21CACTIVE_HTMLExtraInfo[vtable for CACTIVE_HTMLExtraInfo]+0x788): undefined reference to `non-virtual thunk to wxHtmlWindow::GetHTMLCursor(wxHtmlWindowInterface::HTMLCursor) const' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0x7f0): undefined reference to `non-virtual thunk to wxTextCtrlBase::overflow(int)' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0x818): undefined reference to `non-virtual thunk to wxTextCtrl::GetLineLength(long) const' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0x820): undefined reference to `non-virtual thunk to wxTextCtrl::GetLineText(long) const' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0x828): undefined reference to `non-virtual thunk to wxTextCtrl::GetNumberOfLines() const' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0x830): undefined reference to `non-virtual thunk to wxTextCtrl::IsModified() const' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0x838): undefined reference to `non-virtual thunk to wxTextCtrl::MarkDirty()' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0x840): undefined reference to `non-virtual thunk to wxTextCtrl::DiscardEdits()' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0x848): undefined reference to `non-virtual thunk to wxTextCtrl::SetStyle(long, long, wxTextAttr const&)' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0x850): undefined reference to `non-virtual thunk to wxTextCtrl::GetStyle(long, wxTextAttr&)' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0x858): undefined reference to `non-virtual thunk to wxTextCtrlBase::SetDefaultStyle(wxTextAttr const&)' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0x868): undefined reference to `non-virtual thunk to wxTextCtrl::XYToPosition(long, long) const' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0x870): undefined reference to `non-virtual thunk to wxTextCtrl::PositionToXY(long, long*, long*) const' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0x878): undefined reference to `non-virtual thunk to wxTextCtrl::ShowPosition(long)' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0x880): undefined reference to `non-virtual thunk to wxTextCtrl::HitTest(wxPoint const&, long*) const' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0x890): undefined reference to `non-virtual thunk to wxTextCtrl::GetValue() const' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0x8b8): undefined reference to `non-virtual thunk to wxTextCtrl::DoPositionToCoords(long) const' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0x8f0): undefined reference to `non-virtual thunk to wxTextCtrl::WriteText(wxString const&)' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0x900): undefined reference to `non-virtual thunk to wxTextCtrl::GetValue() const' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0x918): undefined reference to `non-virtual thunk to wxTextCtrl::Remove(long, long)' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0x928): undefined reference to `non-virtual thunk to wxTextCtrl::Copy()' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0x930): undefined reference to `non-virtual thunk to wxTextCtrl::Cut()' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0x938): undefined reference to `non-virtual thunk to wxTextCtrl::Paste()' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0x978): undefined reference to `non-virtual thunk to wxTextCtrl::SetInsertionPoint(long)' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0x988): undefined reference to `non-virtual thunk to wxTextCtrl::GetInsertionPoint() const' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0x990): undefined reference to `non-virtual thunk to wxTextCtrl::GetLastPosition() const' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0x998): undefined reference to `non-virtual thunk to wxTextCtrl::SetSelection(long, long)' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0x9b0): undefined reference to `non-virtual thunk to wxTextCtrl::GetSelection(long*, long*) const' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0x9c0): undefined reference to `non-virtual thunk to wxTextCtrl::IsEditable() const' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0x9c8): undefined reference to `non-virtual thunk to wxTextCtrl::SetEditable(bool)' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0x9d8): undefined reference to `non-virtual thunk to wxTextCtrlBase::SetHint(wxString const&)' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0x9e8): undefined reference to `non-virtual thunk to wxTextCtrl::DoSetValue(wxString const&, int)' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0xa28): undefined reference to `non-virtual thunk to wxTextCtrl::EnableTextChangedEvents(bool)' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0xa30): undefined reference to `non-virtual thunk to wxTextCtrl::GTKIMFilterKeypress(_GdkEventKey*) const' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0xa38): undefined reference to `non-virtual thunk to wxTextCtrl::GetEditable() const' info_messages.o:(.data.rel.ro._ZTV14CINFO_Messages[vtable for CINFO_Messages]+0xa40): undefined reference to `non-virtual thunk to wxTextCtrl::GetEntry() const' view_table_control.o:(.data.rel.ro._ZTV19CVIEW_Table_Control[vtable for CVIEW_Table_Control]+0x6f8): undefined reference to `non-virtual thunk to wxGrid::GetSizeAvailableForScrollTarget(wxSize const&)' collect2: ld returned 1 exit status *** [saga_gui] Error code 1 make[7]: stopped in /usr/ports/math/saga/work/saga_2.1.0_src/src/saga_core/saga_gui 1 error From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 05:45:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 051B2396; Thu, 14 Nov 2013 05:45:21 +0000 (UTC) Received: from gate.utahime.jp (ipq210.utahime.jp [183.180.29.210]) by mx1.freebsd.org (Postfix) with ESMTP id C52DE2DBD; Thu, 14 Nov 2013 05:45:20 +0000 (UTC) Received: from eastasia.home.utahime.org (eastasia.home.utahime.org [192.168.174.1]) by gate.utahime.jp (Postfix) with ESMTP id 2347861F9D; Thu, 14 Nov 2013 14:45:12 +0900 (JST) Received: from eastasia.home.utahime.org (localhost [127.0.0.1]) by localhost-backdoor.home.utahime.org (Postfix) with ESMTP id F01234E642; Thu, 14 Nov 2013 14:45:11 +0900 (JST) Received: from localhost (rolling.home.utahime.org [192.168.174.11]) by eastasia.home.utahime.org (Postfix) with ESMTPA id 9FB554E637; Thu, 14 Nov 2013 14:45:11 +0900 (JST) Date: Thu, 14 Nov 2013 14:44:35 +0900 (JST) Message-Id: <20131114.144435.452831467.yasu@utahime.org> To: re@freebsd.org Subject: Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf From: Yasuhiro KIMURA In-Reply-To: <20131112111322.GV90670@droso.dk> References: <868B00D6-101A-4B17-995F-A3E2AFE41908@lansing.dk> <20131112111322.GV90670@droso.dk> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Thu, 14 Nov 2013 12:19:59 +0000 Cc: freebsd-stable@freebsd.org, stb@lassitu.de, freebsd-current@freebsd.org, glebius@freebsd.org, gkontos.mail@gmail.com, des@freebsd.org, ozkan.kirik@gmail.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 05:45:21 -0000 From: Erwin Lansing Subject: Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf Date: Tue, 12 Nov 2013 12:13:23 +0100 > Sorry about the delay, but I did finally update all three dns/bind9* > ports today. I have dropped the complicated chroot, and related > symlinking, logic from the default rc script as I don't think that > is the right place to implement things. I would recommend users > who want the extra security to use jail(8) instead of a mere chroot. > > This change should not affect the installed base of FreeBSD 9.x and > earlier systems, but new installations there should note that the > symlink option is no longer turned on by default, but still supported. > > I tested some default cases, but by no means can test every corner case, > so please let me know how this works out. Please merge r257694 to stable/10 because remnants of BIND are still left. Best Regards. --- Yasuhiro KIMURA From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 12:52:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6FCD1D40 for ; Thu, 14 Nov 2013 12:52:14 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 30F8F2893 for ; Thu, 14 Nov 2013 12:52:14 +0000 (UTC) Received: from [192.168.2.2] (unknown [77.243.161.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id F0FF25C43; Thu, 14 Nov 2013 13:52:09 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_C939A203-2B8E-4278-BA67-741C694C3DAB"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: buildworld error on -current From: Dimitry Andric In-Reply-To: <20131113231748.M92739@i805.com.br> Date: Thu, 14 Nov 2013 13:51:59 +0100 Message-Id: References: <20131113231748.M92739@i805.com.br> To: Nilton Jose Rizzo X-Mailer: Apple Mail (2.1822) Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 12:52:14 -0000 --Apple-Mail=_C939A203-2B8E-4278-BA67-741C694C3DAB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 14 Nov 2013, at 00:23, Nilton Jose Rizzo wrote: ... > =3D=3D=3D> lib/libc++ (all) > c++ -O2 -pipe -I/usr/src/lib/libc++/../../contrib/libc++/include = -I/usr/src/li > b/libc++/../../contrib/libcxxrt -nostdlib -DLIBCXXRT = -Qunused-arguments -fstack- > protector -Wno-empty-body -Wno-string-plus-int = -Wno-tautological-compare -Wno-un > used-value -Wno-parentheses-equality -Wno-unused-function = -Wno-conversion > -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter = -Wno-parentheses > -std=3Dc++0x -Wno-c++11-extensions -c > /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp -o = algorithm.o > In file included from > /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp:10: > In file included from > /usr/src/lib/libc++/../../contrib/libc++/include/algorithm:627: > /usr/src/lib/libc++/../../contrib/libc++/include/memory:3331:3: error: = no > matching literal operator for call to 'operator "" __len' with = argument of > type 'unsigned long long' or 'const char *', and no matching = literal > operator template > 0__len =3D (__len - 1) & ~static_cast<_Size>(63); > ^ > 1 error generated. There is a stray '0' character in front of that line. Did you modify the file by accident? Try doing: svn revert -R /usr/src/contrib/libc++/include/memory or if that still does not remove the stray character, delete your source tree and re-checkout. -Dimitry --Apple-Mail=_C939A203-2B8E-4278-BA67-741C694C3DAB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlKEx3MACgkQsF6jCi4glqPAyACeNSFbcjDjeWZlWea0l9LZURR4 e+IAnRjVCgvjxSnsMygMAh3n3vKfoNfA =7pMZ -----END PGP SIGNATURE----- --Apple-Mail=_C939A203-2B8E-4278-BA67-741C694C3DAB-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 13:17:55 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 350D685F for ; Thu, 14 Nov 2013 13:17:55 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AF16C2A23 for ; Thu, 14 Nov 2013 13:17:54 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id rAEDHqla039028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 Nov 2013 17:17:52 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id rAEDHpJI039027; Thu, 14 Nov 2013 17:17:51 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 14 Nov 2013 17:17:51 +0400 From: Gleb Smirnoff To: Luigi Rizzo Subject: Re: RFC: adding queue number/size fields to ifnet Message-ID: <20131114131751.GI7577@FreeBSD.org> References: <20131114110107.GA36421@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131114110107.GA36421@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 13:17:55 -0000 On Thu, Nov 14, 2013 at 12:01:07PM +0100, Luigi Rizzo wrote: L> Hi, L> it would be useful to have a common place with the indication of L> NIC parameters such as number of tx/rx queues and their lengths. L> L> Various 10G drivers do include this information in various places L> in the softc, but there is no common place. L> L> I was wondering if there is any objection to either or both L> of these options: L> L> 1. four fields to the struct ifnet (field names are bikeshed material L> and irrelevant for the discussion): L> if_tx_queues, if_rx_queues, if_tx_slots, if_rx_slots L> L> 2. a sysctl-like get/set method for key-value pairs (key is always a L> string, value is possibly one of a few simple types such as L> INT64, UINT64, STRING) so that we extend the system in the future, L> e.g. to handle RSS, flow control and whatnot. L> Of course this also requires to settle on names of features. L> L> This is meant for low-frequency access to the parameters of the L> device, so performance is not an issue. The API for drivers to express to the stack their capabilities is planned to be implemented soon. Andre has grant from FF for that. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 14:45:56 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18365BB5; Thu, 14 Nov 2013 14:45:56 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CEF852146; Thu, 14 Nov 2013 14:45:55 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id rAEEjtgG022116; Thu, 14 Nov 2013 06:45:55 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id rAEEjtb5022115; Thu, 14 Nov 2013 06:45:55 -0800 (PST) (envelope-from sgk) Date: Thu, 14 Nov 2013 06:45:55 -0800 From: Steve Kargl To: David Chisnall Subject: Re: libc++ vs. libstdc++ usage in the ports tree Message-ID: <20131114144555.GA22093@troutmask.apl.washington.edu> References: <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> <20131112175556.GA3319@troutmask.apl.washington.edu> <20131112201922.GA4330@troutmask.apl.washington.edu> <20131113173143.Horde.a-9M7JQ_vHo3tpDIMsGK6g1@webmail.df.eu> <5283CA3C.3080201@FreeBSD.org> <352D9465-9840-43F0-A3A9-327DC12B0967@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Ryan Stone , FreeBSD Current , Dimitry Andric , Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 14:45:56 -0000 On Thu, Nov 14, 2013 at 09:54:52AM +0000, David Chisnall wrote: > On 13 Nov 2013, at 19:40, Dimitry Andric wrote: > > > On the other hand, different C++ standard libraries simply cannot be > > mixed. The internal implementations are usually completely different. > > This is not really news at all, certainly not to the ports people. :-) > > That said, it should still be possible to mix them in different > libraries. The constraint from the wiki still applies: if you > don't use STL types at library boundaries, then it should still > work. If you do, then the libc++ and libstdc++ symbols will be > mangled differently and so you will get link-time errors. > > In theory, if it links it should run... > And in practice, it is broken. http://lists.freebsd.org/pipermail/freebsd-current/2013-November/046565.html QED -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 17:21:49 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1801E3EB; Thu, 14 Nov 2013 17:21:49 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C38DF2D10; Thu, 14 Nov 2013 17:21:48 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAEHLlGX099726; Thu, 14 Nov 2013 12:21:47 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAEHLlkQ099710; Thu, 14 Nov 2013 17:21:47 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 14 Nov 2013 17:21:47 GMT Message-Id: <201311141721.rAEHLlkQ099710@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 17:21:49 -0000 TB --- 2013-11-14 14:40:18 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-14 14:40:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-14 14:40:18 - starting HEAD tinderbox run for arm/arm TB --- 2013-11-14 14:40:18 - cleaning the object tree TB --- 2013-11-14 14:45:32 - /usr/local/bin/svn stat /src TB --- 2013-11-14 14:45:36 - At svn revision 258133 TB --- 2013-11-14 14:45:37 - building world TB --- 2013-11-14 14:45:37 - CROSS_BUILD_TESTING=YES TB --- 2013-11-14 14:45:37 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-14 14:45:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-14 14:45:37 - SRCCONF=/dev/null TB --- 2013-11-14 14:45:37 - TARGET=arm TB --- 2013-11-14 14:45:37 - TARGET_ARCH=arm TB --- 2013-11-14 14:45:37 - TZ=UTC TB --- 2013-11-14 14:45:37 - __MAKE_CONF=/dev/null TB --- 2013-11-14 14:45:37 - cd /src TB --- 2013-11-14 14:45:37 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Nov 14 14:45:43 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] c++ -O -pipe -Qunused-arguments -Wsystem-headers -Werror -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-c++11-extensions -I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc:782:11: error: format string is empty [-Werror,-Wformat-zero-length] "", option.get_size_type()); ^~ /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc:1910:11: error: format string is empty [-Werror,-Wformat-zero-length] "", option.get_size_type()); ^~ 2 errors generated. *** Error code 1 Stop. bmake[4]: stopped in /src/gnu/usr.bin/gperf *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/usr.bin *** Error code 1 Stop. bmake[2]: stopped in /src/gnu *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-14 17:21:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-14 17:21:47 - ERROR: failed to build world TB --- 2013-11-14 17:21:47 - 7680.11 user 1272.88 system 9688.66 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 17:21:49 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 144083EA; Thu, 14 Nov 2013 17:21:49 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C393D2D11; Thu, 14 Nov 2013 17:21:48 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAEHLlsV099747; Thu, 14 Nov 2013 12:21:47 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAEHLlRp099737; Thu, 14 Nov 2013 17:21:47 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 14 Nov 2013 17:21:47 GMT Message-Id: <201311141721.rAEHLlRp099737@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on armv6/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 17:21:49 -0000 TB --- 2013-11-14 14:40:18 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-14 14:40:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-14 14:40:18 - starting HEAD tinderbox run for armv6/arm TB --- 2013-11-14 14:40:18 - cleaning the object tree TB --- 2013-11-14 14:45:34 - /usr/local/bin/svn stat /src TB --- 2013-11-14 14:45:37 - At svn revision 258133 TB --- 2013-11-14 14:45:38 - building world TB --- 2013-11-14 14:45:38 - CROSS_BUILD_TESTING=YES TB --- 2013-11-14 14:45:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-14 14:45:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-14 14:45:38 - SRCCONF=/dev/null TB --- 2013-11-14 14:45:38 - TARGET=arm TB --- 2013-11-14 14:45:38 - TARGET_ARCH=armv6 TB --- 2013-11-14 14:45:38 - TZ=UTC TB --- 2013-11-14 14:45:38 - __MAKE_CONF=/dev/null TB --- 2013-11-14 14:45:38 - cd /src TB --- 2013-11-14 14:45:38 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Nov 14 14:45:45 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] c++ -O -pipe -Qunused-arguments -Wsystem-headers -Werror -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-c++11-extensions -I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc:782:11: error: format string is empty [-Werror,-Wformat-zero-length] "", option.get_size_type()); ^~ /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc:1910:11: error: format string is empty [-Werror,-Wformat-zero-length] "", option.get_size_type()); ^~ 2 errors generated. *** Error code 1 Stop. bmake[4]: stopped in /src/gnu/usr.bin/gperf *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/usr.bin *** Error code 1 Stop. bmake[2]: stopped in /src/gnu *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-14 17:21:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-14 17:21:47 - ERROR: failed to build world TB --- 2013-11-14 17:21:47 - 7678.09 user 1278.44 system 9688.78 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-armv6-arm.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 17:32:35 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0DA76A72; Thu, 14 Nov 2013 17:32:35 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BBC462DFF; Thu, 14 Nov 2013 17:32:34 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAEHWXiU091469; Thu, 14 Nov 2013 12:32:33 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAEHWSup089876; Thu, 14 Nov 2013 17:32:28 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 14 Nov 2013 17:32:28 GMT Message-Id: <201311141732.rAEHWSup089876@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 17:32:35 -0000 TB --- 2013-11-14 14:40:18 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-14 14:40:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-14 14:40:18 - starting HEAD tinderbox run for i386/i386 TB --- 2013-11-14 14:40:18 - cleaning the object tree TB --- 2013-11-14 14:45:32 - /usr/local/bin/svn stat /src TB --- 2013-11-14 14:45:36 - At svn revision 258133 TB --- 2013-11-14 14:45:37 - building world TB --- 2013-11-14 14:45:37 - CROSS_BUILD_TESTING=YES TB --- 2013-11-14 14:45:37 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-14 14:45:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-14 14:45:37 - SRCCONF=/dev/null TB --- 2013-11-14 14:45:37 - TARGET=i386 TB --- 2013-11-14 14:45:37 - TARGET_ARCH=i386 TB --- 2013-11-14 14:45:37 - TZ=UTC TB --- 2013-11-14 14:45:37 - __MAKE_CONF=/dev/null TB --- 2013-11-14 14:45:37 - cd /src TB --- 2013-11-14 14:45:37 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Nov 14 14:45:43 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] c++ -O2 -pipe -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-c++11-extensions -I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc:782:11: error: format string is empty [-Werror,-Wformat-zero-length] "", option.get_size_type()); ^~ /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc:1910:11: error: format string is empty [-Werror,-Wformat-zero-length] "", option.get_size_type()); ^~ 2 errors generated. *** Error code 1 Stop. bmake[4]: stopped in /src/gnu/usr.bin/gperf *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/usr.bin *** Error code 1 Stop. bmake[2]: stopped in /src/gnu *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-14 17:32:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-14 17:32:28 - ERROR: failed to build world TB --- 2013-11-14 17:32:28 - 8314.08 user 1345.45 system 10329.94 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 17:32:35 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07438A71; Thu, 14 Nov 2013 17:32:35 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B63BB2DFE; Thu, 14 Nov 2013 17:32:34 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAEHWXmP091468; Thu, 14 Nov 2013 12:32:33 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAEHWSUo089875; Thu, 14 Nov 2013 17:32:28 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 14 Nov 2013 17:32:28 GMT Message-Id: <201311141732.rAEHWSUo089875@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 17:32:35 -0000 TB --- 2013-11-14 14:40:18 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-14 14:40:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-14 14:40:18 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-11-14 14:40:18 - cleaning the object tree TB --- 2013-11-14 14:45:35 - /usr/local/bin/svn stat /src TB --- 2013-11-14 14:45:38 - At svn revision 258133 TB --- 2013-11-14 14:45:39 - building world TB --- 2013-11-14 14:45:39 - CROSS_BUILD_TESTING=YES TB --- 2013-11-14 14:45:39 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-14 14:45:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-14 14:45:39 - SRCCONF=/dev/null TB --- 2013-11-14 14:45:39 - TARGET=amd64 TB --- 2013-11-14 14:45:39 - TARGET_ARCH=amd64 TB --- 2013-11-14 14:45:39 - TZ=UTC TB --- 2013-11-14 14:45:39 - __MAKE_CONF=/dev/null TB --- 2013-11-14 14:45:39 - cd /src TB --- 2013-11-14 14:45:39 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Nov 14 14:45:46 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] c++ -O2 -pipe -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-c++11-extensions -I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc:782:11: error: format string is empty [-Werror,-Wformat-zero-length] "", option.get_size_type()); ^~ /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc:1910:11: error: format string is empty [-Werror,-Wformat-zero-length] "", option.get_size_type()); ^~ 2 errors generated. *** Error code 1 Stop. bmake[4]: stopped in /src/gnu/usr.bin/gperf *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/usr.bin *** Error code 1 Stop. bmake[2]: stopped in /src/gnu *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-14 17:32:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-14 17:32:28 - ERROR: failed to build world TB --- 2013-11-14 17:32:28 - 8312.62 user 1328.08 system 10329.94 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 17:46:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3528E171 for ; Thu, 14 Nov 2013 17:46:14 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EA9A82EEE for ; Thu, 14 Nov 2013 17:46:13 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1Vh0zc-0049bv-HS>; Thu, 14 Nov 2013 18:46:12 +0100 Received: from g226178108.adsl.alicedsl.de ([92.226.178.108] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1Vh0zc-001yzk-EJ>; Thu, 14 Nov 2013 18:46:12 +0100 Date: Thu, 14 Nov 2013 18:46:11 +0100 From: "O. Hartmann" To: FreeBSD CURRENT Subject: CURRENT r 258138 fails to build: usr.bin/gperf: error: format string is empty Message-ID: <20131114184611.6ab510f4@thor.walstatt.dyndns.org> Organization: FU Berlin X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/hCe8.0VSO_qUE+Yu3uSpfUn"; protocol="application/pgp-signature" X-Originating-IP: 92.226.178.108 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 17:46:14 -0000 --Sig_/hCe8.0VSO_qUE+Yu3uSpfUn Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I receive this error now in CURRENT r258138: cc -O2 -pipe -O3 -march=3Dnative -pipe -O3 -DRESCUE -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -c /usr/src/usr.bin/tail/tail.c --- gnu.all__D --- /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc:1910:11: error: format string is empty [-Werror,-Wformat-zero-length] "", option.get_size_type()); ^~ 2 errors generated. *** [output.o] Error code 1 Oliver --Sig_/hCe8.0VSO_qUE+Yu3uSpfUn Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJShQxkAAoJEOgBcD7A/5N8/1sIAMJ+HNDmhlEhA7vjxXKME63R KlPPqJBtFY/Mi/yuCHynR3l5wN9gguKY7PgDSUqL0D0CRRJmj6UoYOUZd9NsXE7l GXXonptJR2XOMNv+7s5aoNVF5eVsyGj9bv4HkfrJ8F7SHPM7vmlUgEHxdO3F2e9a 4XmHFiTipS94Oy+/RUwQLgWfIdVnimGHsayPQ2XhLntqDoNPm+gtPSlyKdH9/ksL ZQrOpxt5/TfM1OfxYTCXamB1oCYicfZCQWN4O4lH7O6YtcgPfyvkvedrq45PzqxX ALYl3cvq30MiVNemjDIXywo24J17zZuZiV8lR2vWifot1AkfqQTFKpbIhVWEcRg= =AU3x -----END PGP SIGNATURE----- --Sig_/hCe8.0VSO_qUE+Yu3uSpfUn-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 17:48:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F216A3B0 for ; Thu, 14 Nov 2013 17:48:28 +0000 (UTC) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 828B72F0D for ; Thu, 14 Nov 2013 17:48:28 +0000 (UTC) Received: by mail-la0-f43.google.com with SMTP id n7so1851135lam.2 for ; Thu, 14 Nov 2013 09:48:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=vmgRcD7PQHK2u6cb4+IQTqbb2sN6pUzzfPQRTKOrgHM=; b=qT3o3LjNmcE4AQvu/B8SG7DTq8nIqEHS8BK9/auF0YRgSwhByESo35OhDbzorlUoN8 tX3Ky2P1TFXBp+W427FpXk8aHI9Uw0xXo1pmueNqI7vu8lPAT8DuBzQ7PxI7Pfopiejv PXSQ3vIVNk/Tk8y1yzUtAmZdxwCwawwKMRMV032YlPLuYS1QpZhlyUV2PQ3urVj3jp2q 4iseFXO1cIExDAuZYrQb7U86UQxZ29i93U1JufGMu7XQ0iXaafXbl30muonZenuO60Pu CCuozQSpRWXP9aCr6Q7cr++9m7XnugjQph1TXlr9BA4v2O3PoTsVRaYYzQgYu+2fNc9r ZWMA== MIME-Version: 1.0 X-Received: by 10.112.132.70 with SMTP id os6mr1498760lbb.38.1384451306397; Thu, 14 Nov 2013 09:48:26 -0800 (PST) Received: by 10.114.200.10 with HTTP; Thu, 14 Nov 2013 09:48:26 -0800 (PST) Date: Thu, 14 Nov 2013 09:48:26 -0800 Message-ID: Subject: ZSF and installkernel 10.0-BETA1 From: Phillip Kinsley To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 17:48:29 -0000 I installed Beta1 using the ZFS option, all default settings. I sync the source the other day and did a buildworld and buildkernel. When I do installkernel I get mkdir -p /boot/kernel mkdir: /boot: No such file or directory and the install stops. With another box that used a standard UFS installation I have no problem. I'm sure the ZFS installkernel is know issue, but I can't seem to find if there is a solution or not. Is there a work around or not? Thanks Phillip From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 18:06:17 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B54FD13; Thu, 14 Nov 2013 18:06:17 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E7AAF20E4; Thu, 14 Nov 2013 18:06:16 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAEI6FvO041211; Thu, 14 Nov 2013 13:06:15 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAEI6Fp0041194; Thu, 14 Nov 2013 18:06:15 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 14 Nov 2013 18:06:15 GMT Message-Id: <201311141806.rAEI6Fp0041194@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 18:06:17 -0000 TB --- 2013-11-14 17:21:47 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-14 17:21:47 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-14 17:21:47 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-11-14 17:21:47 - cleaning the object tree TB --- 2013-11-14 17:23:01 - /usr/local/bin/svn stat /src TB --- 2013-11-14 17:23:04 - At svn revision 258133 TB --- 2013-11-14 17:23:05 - building world TB --- 2013-11-14 17:23:05 - CROSS_BUILD_TESTING=YES TB --- 2013-11-14 17:23:05 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-14 17:23:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-14 17:23:05 - SRCCONF=/dev/null TB --- 2013-11-14 17:23:05 - TARGET=pc98 TB --- 2013-11-14 17:23:05 - TARGET_ARCH=i386 TB --- 2013-11-14 17:23:05 - TZ=UTC TB --- 2013-11-14 17:23:05 - __MAKE_CONF=/dev/null TB --- 2013-11-14 17:23:05 - cd /src TB --- 2013-11-14 17:23:05 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Nov 14 17:23:14 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools [...] c++ -O2 -pipe -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/include -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter -I. -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/pc98.i386/src/tmp\" -I/obj/pc98.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter/DwarfCFIException.cpp -o DwarfCFIException.o c++ -O2 -pipe -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/include -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter -I. -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/pc98.i386/src/tmp\" -I/obj/pc98.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp -o DwarfCompileUnit.o c++ -O2 -pipe -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/include -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter -I. -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/pc98.i386/src/tmp\" -I/obj/pc98.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp -o DwarfDebug.o /src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp: In destructor 'llvm::DwarfDebug::~DwarfDebug()': /src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:212: internal compiler error: in var_ann, at tree-flow-inline.h:128 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop. bmake[3]: stopped in /src/lib/clang/libllvmasmprinter *** Error code 1 Stop. bmake[2]: stopped in /src/lib/clang *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-14 18:06:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-14 18:06:15 - ERROR: failed to build world TB --- 2013-11-14 18:06:15 - 2219.88 user 266.31 system 2668.11 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 18:06:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8157FE51 for ; Thu, 14 Nov 2013 18:06:53 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 3AF9420FC for ; Thu, 14 Nov 2013 18:06:53 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.108.129]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id D0F5A1832C for ; Thu, 14 Nov 2013 17:57:24 +0000 (UTC) Message-ID: <52850F03.50203@allanjude.com> Date: Thu, 14 Nov 2013 12:57:23 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: ZSF and installkernel 10.0-BETA1 References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HaBUl9OigGbCSflueks8cAtl7iD7ea4Kr" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 18:06:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HaBUl9OigGbCSflueks8cAtl7iD7ea4Kr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-11-14 12:48, Phillip Kinsley wrote: > I installed Beta1 using the ZFS option, all default settings. I sync th= e > source the other day and did a buildworld and buildkernel. When I do > installkernel I get > > mkdir -p /boot/kernel > mkdir: /boot: No such file or directory > > and the install stops. With another box that used a standard UFS > installation I have no problem. > > I'm sure the ZFS installkernel is know issue, but I can't seem to find = if > there is a solution or not. > Is there a work around or not? > > Thanks > > > Phillip > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" What do you mean 'the zfs option'? You mean you used the ZFS installation option in bsdinstall? That is a known issue that was fixed in later versions, here are the instructions to fix it: http://lists.freebsd.org/pipermail/freebsd-stable/2013-October/075504.htm= l o Updates to bsdinstall(8). Please note the following: - 10.0-BETA1 introduces a number of updates to bsdinstall(8), notably the ability to install to a full ZFS filesystem. Please keep in mind that this is an experimental feature. - If using the ZFS installation option in *and* have enabled full-disk encryption is enabled, a few entries will need to be manually added to loader.conf(5) before the 'bootpool' zpool will be available after the system boots. This manual step is expected to be fixed in 10.0-BETA2. The entries that need to be added are: zpool_cache_load=3D"YES" zpool_cache_type=3D"/boot/zfs/zpool.cache" zpool_cache_name=3D"/boot/zfs/zpool.cache" This can be done at the final menu of bsdinstall(8), when prompted to boot into the newly-installed system; alternatively, this can be done post-install, in which case, the following must be run before appending loader.conf(5): # zpool import -f bootpool --=20 Allan Jude --HaBUl9OigGbCSflueks8cAtl7iD7ea4Kr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJShQ8GAAoJEJrBFpNRJZKf/joP/RYqDbscJPfRA9rT9g0NIVIL LJMXkPTT7rwpb6+bNOpMFSrZs/DGPSnOIMrZ7ZhpxXLf5CaY+CpY5gPARGnBv8ho ZzQuMrbBHRJJ2ayuhJlS61GbTYq28S4u5Tmb0DEYT76fv1vznSlxiCZFh2BKGJZ2 SeTnYOzCL/2dpdPRrbfEtbKovd7XILWS6/fLpV598oFvxHSyYmWjbpABWpZ5T5VC 6q3ExSOmEk9rVlWt17zsel6jFPgkbdwe3f/LIO2PktpJ0RXAXFVXEuleZIMsCnSn qbvD+yYXm6zgbc9fV1PqOWeTK96mzB/CHtsakEbEFnUu17UoC6WcYSuBaZrKTNMP 6APvzWvZJLv2jKIXB6kATZEA+2noB96XQrVbCvAm7B2hjY3WZcIUzoAsycvUjARo uZewyil4JHvXSHyQRXVv4GcB8tPlOBgraH3yt+fZdL1DD4LDnEr7HahzZYY8+/Ir w8CTdX5OtJoSbKtp5hZ0cynnaML6+Myl53ke0VpHE9+OVv2FH0NOAGC6p3f9s8qb bpijIwU+9+SDyN34anY1qI+mVXni0BONZUX1GpBb0PAyH/K5VfCzDfp8RRO7/g2m nXIswYE8D6tG9p+jmdO8N2OFexVAfa7xRzistgfHu4uZfkQWQz7mxa1aPA1nekAr K4bSb6tzJDbdwCOOMMen =NAJa -----END PGP SIGNATURE----- --HaBUl9OigGbCSflueks8cAtl7iD7ea4Kr-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 18:29:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD1B6802 for ; Thu, 14 Nov 2013 18:29:13 +0000 (UTC) Received: from cohiba.eagle.ca (cohiba.eagle.ca [208.70.104.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 65D28233E for ; Thu, 14 Nov 2013 18:29:13 +0000 (UTC) Received: (qmail 19471 invoked by uid 89); 14 Nov 2013 18:22:30 -0000 Received: from unknown (HELO MattRauchPC) (mattr-lists@eagle.ca@208.70.104.100) by cohiba.eagle.ca with ESMTPA; 14 Nov 2013 18:22:30 -0000 From: "Matt Rauch" To: Subject: FreeBSD 9.1 Server hanging while backing up full disk with Amanda Date: Thu, 14 Nov 2013 13:22:27 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac7hZnk37/GhkX6MQrik3J0QQN51fw== X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 18:29:13 -0000 Hello, I think I am having almost the same issue as was reported here: http://thr3ads.net/freebsd-stable/2008/11/388646-System-deadlock-when-using- mksnap_ffs I would have thought something that old would have been patched by this point, but perhaps not? It looks like when the Amanda process is running on the server and doing the Dump phase, it hangs during when the snapshot is being created (mksnap_ffs) for about 20 mins. The box is pingable, but most services stop responding during that time. Then after that 20 mins or so, it clears up and the dump continues on and finishes successfully. I have 9 servers that are backed up with Amanda, and this is the only one giving me this issue. It is the only one running FreeBSD 9.1 as well as the only one with one partition instead of separate partitions for the various directories (/usr, /var /home etc). Disk size: Filesystem Size Used Avail Capacity Mounted on /dev/da0p2 3.5T 133G 3.1T 4% / Any one having similar issues or know of a fix? Thanks, Matt Rauch From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 18:43:06 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8BC1F3C for ; Thu, 14 Nov 2013 18:43:05 +0000 (UTC) Received: from nm4.bullet.mail.bf1.yahoo.com (nm4.bullet.mail.bf1.yahoo.com [98.139.212.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 98B732457 for ; Thu, 14 Nov 2013 18:43:05 +0000 (UTC) Received: from [66.196.81.173] by nm4.bullet.mail.bf1.yahoo.com with NNFMP; 14 Nov 2013 18:42:58 -0000 Received: from [98.139.213.12] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 14 Nov 2013 18:42:58 -0000 Received: from [127.0.0.1] by smtp112.mail.bf1.yahoo.com with NNFMP; 14 Nov 2013 18:42:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1384454578; bh=rDV94xwcIphuWXRX+mcz9JvZfydzMIoJkej2sfAjMt4=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:Cc:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer; b=zUjFr7aRSBDOnTGzNqbXKk+48FwN1tiDoBNSl0Vonzg5azsZpHgA03pFqBNZcMgvfof1BI8MeeKs2xuGbdCsGcJ54Dgg613DpZukbThoM6/PWDcUhzdiXSvytPPwF/46IJRu+P3SjU0QFuMpD2p66amEV6KDk7j2d+N3aT37KJQ= X-Yahoo-Newman-Id: 248602.3488.bm@smtp112.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: R8TiORsVM1lHkHqCp8bQIeWKFcQNfnOORnM1dx05X.BZPQ. aUn.lEYL51t6XKu5ftqLmLC.Anf9lL.dUCfAGG7SpdnKVRUFW9gublgfPmWl _USkn6URzd1uSyvEmb68YASwd0cO0NuJMWmgA039_qViiAIaZwfrGKPyye9Z S8543ALoJsjQN6dU_7LhimRK9hCrm0eC_yas0W6Ciggh9Mr2HLr5Ad2ptfeZ W3ITZmve0HrB6ffiwl2TWRQsImE30SAlm.tGXmzivDh.ea7w9j._iuPI9zpL _iv6k8oywdi23c1hXEzSDQOWKlDoP.SY2KmF7RrE_5dnEp8qhkSrUPzYfeES d1SbrfAT5i8.9sLNvc3ThALiDjB0zOrCrijTR2A7RO_pF0Z9TO6V9GGSS8_g GR1Y3Z80sDPIfT4N2rrs.MeDQXzWmg7jYiVMlWJ_dlVNxyviCwNxIJPIvAoh em01tCGui0efCSEt9rWdDpBm3WAV7VXIGhEhwgZ3KcZQnzhq_FqOvmjp9p8D HgumcW_6DxjJGJ1fho983AO7.P03iPE0lNUfnh8nkX4BtkUlifqWpaTRlYhQ aZPvMYSxjldwCxPseRQBrcZzJzqQFWJ0amrRTz.a8kzE6PJ3b20IM X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [10.73.160.242] (sean_bruno@209.131.62.116 with ) by smtp112.mail.bf1.yahoo.com with SMTP; 14 Nov 2013 10:42:58 -0800 PST Subject: Re: [head tinderbox] failure on amd64/amd64 From: Sean Bruno To: FreeBSD Tinderbox In-Reply-To: <201311141732.rAEHWSUo089875@freebsd-current.sentex.ca> References: <201311141732.rAEHWSUo089875@freebsd-current.sentex.ca> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-39HwgSNusdug+FdXq+WA" Date: Thu, 14 Nov 2013 10:42:56 -0800 Message-ID: <1384454576.2676.12.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: amd64@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 18:43:06 -0000 --=-39HwgSNusdug+FdXq+WA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > [...] > c++ -O2 -pipe -Qunused-arguments -fstack-protector -Wsystem-headers -Wer= ror -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unu= sed-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -W= no-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wn= o-c++11-extensions -I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/s= rc/gnu/usr.bin/gperf -c /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/o= utput.cc > /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc:782:11: error= : format string is empty [-Werror,-Wformat-zero-length] > "", option.get_size_type()); > ^~ > /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc:1910:11: erro= r: format string is empty [-Werror,-Wformat-zero-length] > "", option.get_size_type()); Theoretically fixed at svn R258139. sean --=-39HwgSNusdug+FdXq+WA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iQEcBAABAgAGBQJShRmwAAoJEBkJRdwI6BaHkdQH/0Q2sYYQxmc+EBGhLJaksvtj U3D+jVR6vAsDQZi38B18+J+GgaeGkQUh/kWAnFWPQ29suVH+7zehxApmdUqV9BG7 8J1UGjPpUScoFnr9CE/EZUeu2k9lVAJ/nlpVF6tNihMXYEKhaDCiYmWCmxoQpnBz EPR2OM4Gr0CMk2hEQ6jW3wNw6PpkIPNUGce7jjAv+LjqepASAblzvtVmXlxgVHXY x4nkwqxwwLZK1ycQEPULZwati3iORNmm7yr3m336/jn8j7JOfe1rL8fDRps5jnI1 IMZgfezZQvFI3wB4Wb8/T/GpS/d2kfs4FwT3mnc5pvWzDg1RvCaHGjag1y6jOFM= =VXTT -----END PGP SIGNATURE----- --=-39HwgSNusdug+FdXq+WA-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 18:51:10 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 193C9525 for ; Thu, 14 Nov 2013 18:51:10 +0000 (UTC) Received: from nm25-vm1.bullet.mail.bf1.yahoo.com (nm25-vm1.bullet.mail.bf1.yahoo.com [98.139.212.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 94F9A24E6 for ; Thu, 14 Nov 2013 18:51:09 +0000 (UTC) Received: from [66.196.81.172] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 14 Nov 2013 18:51:02 -0000 Received: from [98.139.211.203] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 14 Nov 2013 18:50:02 -0000 Received: from [127.0.0.1] by smtp212.mail.bf1.yahoo.com with NNFMP; 14 Nov 2013 18:50:02 -0000 X-Yahoo-Newman-Id: 340139.28444.bm@smtp212.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: qhy_gBYVM1nnBohCEv7HFx4rp94_HVDpr5jbyrQT0yI.Nz5 SprPZ3Ydh2tTkvRjp8My8FASvX9IKmcYADZe7sSsicTMQIfzyufsvIb1ivSx HCE3J5HFBoZJCKWAn4zszsOFwHvUjHP.i2YxQlaPIdLT6QwQXyHVcPH16k83 U2_WUK7x1Pp33JwRECLyHvIB3msdWSfr3LEPKLFUpf7uiqGTW._WMD9dotLD 3dpzXkkfpoSD9MzP59dg2V.LsGhMYZ0CSN9rJMkXMCgs74drwZaBd1tFEHVm e4wfWpjHstzGWNY09rotRbWqnJ7TRNcyHz8xQKSO5V_dja.ssS5272weV9QX zOVzURqi4BC_ZdpzPLSC4iA3I8.X3pEUti0yk0VU0cHI8QHj5PLw615pxyCz FLQ5FU_mqj_wqUGdmWdq.SjCIzxL1zFYBKlP4h4aJ6c4xpr4mrM7D1oKZaaA i.Gp0kCQcS8hW6QAvlbYoEcQm_cDTsh53sKz4pV10wb0p3TEzIzKVcuk7ssC Gf2BoAso6GOJFch5S.UJJ4fYBK2RGACRP0Eal68Ryb17Ju9nwz1uOngzanTk lcAp0PWaCGx1zJRotxKahFxB7R4ySxc1ahND9944jbVM- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with ) by smtp212.mail.bf1.yahoo.com with SMTP; 14 Nov 2013 10:50:02 -0800 PST Message-ID: <52851B58.2020906@FreeBSD.org> Date: Thu, 14 Nov 2013 13:50:00 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: sbruno@freebsd.org, FreeBSD Tinderbox Subject: Re: [head tinderbox] failure on amd64/amd64 References: <201311141732.rAEHWSUo089875@freebsd-current.sentex.ca> <1384454576.2676.12.camel@powernoodle.corp.yahoo.com> In-Reply-To: <1384454576.2676.12.camel@powernoodle.corp.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: amd64@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 18:51:10 -0000 On 14.11.2013 13:42, Sean Bruno wrote: >> [...] >> c++ -O2 -pipe -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-c++11-extensions -I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc >> /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc:782:11: error: format string is empty [-Werror,-Wformat-zero-length] >> "", option.get_size_type()); >> ^~ >> /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc:1910:11: error: format string is empty [-Werror,-Wformat-zero-length] >> "", option.get_size_type()); > Theoretically fixed at svn R258139. > > sean Thank you! FWIW, I had a similar fix but was waiting for confirmation before committing. Regards, Pedro. From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 19:36:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 329636A4; Thu, 14 Nov 2013 19:36:15 +0000 (UTC) Received: from server.i805.com.br (mailhost.i805.com.br [72.52.97.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1DA48280A; Thu, 14 Nov 2013 19:36:14 +0000 (UTC) Received: from i805.com.br (localhost [127.0.0.1]) by server.i805.com.br (8.14.6/8.14.5) with ESMTP id rAEJaBjb037257; Thu, 14 Nov 2013 17:36:12 -0200 (BRST) (envelope-from rizzo@i805.com.br) From: "Nilton Jose Rizzo" To: Dimitry Andric Subject: Re: buildworld error on -current Date: Thu, 14 Nov 2013 16:36:11 -0300 Message-Id: <20131114193454.M46834@i805.com.br> In-Reply-To: References: <20131113231748.M92739@i805.com.br> X-Mailer: OpenWebMail 3.00_beta4 20121104 671 X-OriginatingIP: 146.164.32.147 (rizzo) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on server.i805.com.br Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 19:36:15 -0000 Em Thu, 14 Nov 2013 13:51:59 +0100, Dimitry Andric escreveu > On 14 Nov 2013, at 00:23, Nilton Jose Rizzo > wrote: ... > > ===> lib/libc++ (all) > > c++ -O2 -pipe -I/usr/src/lib/libc++/../../contrib/libc++/include - I/usr/src/li > > b/libc++/../../contrib/libcxxrt -nostdlib -DLIBCXXRT -Qunused-arguments - fstack- > > protector -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare - Wno-un > > used-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion > > -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses > > -std=c++0x -Wno-c++11-extensions -c > > /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp -o algorithm.o > > In file included from > > /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp:10: > > In file included from > > /usr/src/lib/libc++/../../contrib/libc++/include/algorithm:627: > > /usr/src/lib/libc++/../../contrib/libc++/include/memory:3331:3: error: no > > matching literal operator for call to 'operator "" __len' with argument of > > type 'unsigned long long' or 'const char *', and no matching literal > > operator template > > 0__len = (__len - 1) & ~static_cast<_Size>(63); > > ^ > > 1 error generated. > > There is a stray '0' character in front of that line. Did you modify > the file by accident? Try doing: > No, only update the source via svn > svn revert -R /usr/src/contrib/libc++/include/memory > > or if that still does not remove the stray character, delete your source > tree and re-checkout. I'll try it. > > -Dimitry Thanx, Rizzo From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 20:34:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DA3F6E41; Thu, 14 Nov 2013 20:34:25 +0000 (UTC) Received: from odin.blazingdot.com (odin.blazingdot.com [199.48.133.254]) by mx1.freebsd.org (Postfix) with ESMTP id A1A972BA9; Thu, 14 Nov 2013 20:34:25 +0000 (UTC) Received: by odin.blazingdot.com (Postfix, from userid 1001) id B3D30114155; Thu, 14 Nov 2013 20:34:24 +0000 (UTC) Date: Thu, 14 Nov 2013 20:34:24 +0000 From: Marcus Reid To: Devin Teske Subject: Re: Defaults in 10.0 ZFS through bsdinstall Message-ID: <20131114203424.GA22267@blazingdot.com> References: <20131114173423.GA21761@blazingdot.com> <59A9B68B-4134-4217-83F3-B99759174EFE@fisglobal.com> <5285148E.6020903@allanjude.com> <3D3332FA-0ABF-4573-8E65-4E7FBB37100B@fisglobal.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D3332FA-0ABF-4573-8E65-4E7FBB37100B@fisglobal.com> X-Coffee-Level: nearly-fatal User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs , freebsd-current@freebsd.org, "Teske, Devin" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 20:34:25 -0000 On Thu, Nov 14, 2013 at 06:35:43PM +0000, Teske, Devin wrote: > On Nov 14, 2013, at 10:21 AM, Allan Jude wrote: > > On 2013-11-14 9:34, Reid, Marcus wrote: > > > > Hi, > > > > I noticed a couple of things with the ZFS defaults that result from > > using the new installer in 10.0-BETA3. > > > > One, atime is turned off everywhere by default. There was a thread > > on this list on June 8 with a subject of 'Changing the default for > > ZFS atime to off?', and from what I can tell the idea of turning off > > atime by default was not a popular one. > > > > Two, and probably less controversial, is that fletcher4 is specified > > exlicitly on the root pool, even though it is default (wouldn't you > > just want to go with the default, in case it changes?) > > > > Marcus > > I have never heard a good argument for having atime on. Can you address some of the issues that people brought up in the thread I mentioned earlier? I'll summarize some: - breaks some software (MTAs were mentioned), and the admin should know when to turn atime on in those cases. - "any mail program using mbox mail folders uses them to correctly report which mailboxes have not been read yet" - "Of course it can't be turned off by default. It is specified by POSIX." - "If the overhead were a real problem then file systems would use a special atime cache" > The performance penalty on ZFS is quite large This is subjective, and if it were that bad it seems like other ZFS-based systems would have turned it off as well, or done something like caching/logging or relatime it to mitigate the performance hit. > and it also makes your snapshots grow constant. This does not seem to be the case. For example, if I snapshot zroot/usr/src and then tar it up, I generate a bunch of writes and the snapshot grows to 70.5MB. However, when I tar it up a second time, there are writes but the snapshot remains 70.5MB. It seems to use the same blocks for subsequent atime updates. If you made another snapshot, you would see more space used for that one, of course. > If you have a use for it, you can turn it on I guess. This would be > solved by having the dataset editor we're planning for 10.1 > > Seems easy enough to turn on once installed. And like Allan says, the > editor for 10.1 would allow changing of the default. The same case could be made for turning it off, make that an option in the installer instead. Some people don't seem to use atime on a regular basis, but I use it a lot when troubleshooting things, and I think others do to when they get to the point where they realize how useful it is. > I'll add that if scripting it, you can (in current state for 10.0) > change the dataset options at-will. > > The fletcher4 thing is a leftover, from older versions of ZFS where > the default was fletcher2, I suppose we can remove it While I'm picking nits: There are some other locally set things that are default (exec set to on on zroot/var/tmp is one), that might just inherit that from zroot/var. Also, zroot doesn't appear to be mounted on /zroot, as it is on other ZFS-based systems. This has the side-effect of newly created datasets not having a mountpoint by default, instead of /zroot/dataset. I don't know of the reason behind this change either. I'm going to cross-post this to -current, this is a topic that I think warrants a wider audience. Thanks, Marcus > > > Let me put something together. > - -- > Devin > > -----BEGIN PGP SIGNATURE----- > Comment: GPGTools - https://gpgtools.org > > iQEcBAEBCgAGBQJShRf/AAoJEKrMn5R9npq5TYwH/j8RMceM4STpCAoMTAz8zkKn > gpftMrdf37TnAPHxsXJaiZejlp+D85/a9lglYbB7e4WdgoDX9ZXA0QLtCEmEtN4y > jz7KNa5oABq1GjDtwm2xQISDIe8yYI+znLSaHA9W18kCUZzi8AOj70C+O5gyY28c > c3N3j6Y4EZP2wtQnWSgxvCwIX5p86Jvr3QvhrRuuMnKMCTAhzwIx24qcnA4EcTzn > p9w25CKLtOzF23n3McodaUmibbBCHOYyraLQJ+eJGDXcsPBipls3oiWyiYuqpcQr > 18QpLN1lS35RnULcb5pxnP9Oy9rAwxHKves9Mfu0UoWw3qTjSAf8gsGyu6QaMgc= > =GjYk > -----END PGP SIGNATURE----- > > _____________ > The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 21:04:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 743FCC7; Thu, 14 Nov 2013 21:04:31 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3E1D02DE5; Thu, 14 Nov 2013 21:04:31 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa05.fnfis.com (8.14.5/8.14.5) with ESMTP id rAEL4Po0021942 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Nov 2013 15:04:25 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.152]) by LTCFISWMSGHT06.FNFIS.com ([10.132.206.17]) with mapi id 14.03.0158.001; Thu, 14 Nov 2013 15:04:24 -0600 From: "Teske, Devin" To: Marcus Reid Subject: Re: Defaults in 10.0 ZFS through bsdinstall Thread-Topic: Defaults in 10.0 ZFS through bsdinstall Thread-Index: AQHO4WP56r1WdCmD2k+in4awofQcqw== Date: Thu, 14 Nov 2013 21:04:23 +0000 Message-ID: <19B09C7A-10E5-41BC-BD5E-B15179651F6D@fisglobal.com> References: <20131114173423.GA21761@blazingdot.com> <59A9B68B-4134-4217-83F3-B99759174EFE@fisglobal.com> <5285148E.6020903@allanjude.com> <3D3332FA-0ABF-4573-8E65-4E7FBB37100B@fisglobal.com> <20131114203424.GA22267@blazingdot.com> In-Reply-To: <20131114203424.GA22267@blazingdot.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.14, 0.0.0000 definitions=2013-11-14_07:2013-11-13,2013-11-14,1970-01-01 signatures=0 Cc: freebsd-fs , Devin Teske , "Teske, Devin" , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 21:04:31 -0000 On Nov 14, 2013, at 12:34 PM, Marcus Reid wrote: > On Thu, Nov 14, 2013 at 06:35:43PM +0000, Teske, Devin wrote: >> On Nov 14, 2013, at 10:21 AM, Allan Jude wrote: >>> On 2013-11-14 9:34, Reid, Marcus wrote: >>>=20 >>> Hi, >>>=20 >>> I noticed a couple of things with the ZFS defaults that result from >>> using the new installer in 10.0-BETA3. >>>=20 >>> One, atime is turned off everywhere by default. There was a thread >>> on this list on June 8 with a subject of 'Changing the default for >>> ZFS atime to off?', and from what I can tell the idea of turning off >>> atime by default was not a popular one. >>>=20 >>> Two, and probably less controversial, is that fletcher4 is specified >>> exlicitly on the root pool, even though it is default (wouldn't you >>> just want to go with the default, in case it changes?) >>>=20 >>> Marcus >>=20 >> I have never heard a good argument for having atime on. >=20 > Can you address some of the issues that people brought up in the thread > I mentioned earlier? I'll summarize some: >=20 > - breaks some software (MTAs were mentioned), and the admin should > know when to turn atime on in those cases. >=20 > - "any mail program using mbox mail folders uses them to correctly > report which mailboxes have not been read yet" >=20 I'm looking at HEAD and I don't see "atime=3Doff" for the /var dataset. Knowing that most folks (accepting the defaults) will store their mail in /var/mail ... does the concern over atime=3Doff still exist? However, I did notice that before we go creating the /var dataset, we do set "atime=3Doff" for the boot pool/dataset. Is inheritance at-play here? and /var is turning up with atime=3Doff even though it's not specified? In that case, I certainly agree we should remove atime=3Doff from the last place it is used -- the boot pool (nowhere else). > - "Of course it can't be turned off by default. It is specified by > POSIX." >=20 > - "If the overhead were a real problem then file systems would use a > special atime cache" >=20 >> The performance penalty on ZFS is quite large >=20 > This is subjective, and if it were that bad it seems like other > ZFS-based systems would have turned it off as well, or done something > like caching/logging or relatime it to mitigate the performance hit. >=20 I do recall discussions about bringing over relatime and making it the default. Allan was the one that brought up the performance hit... Similarly where I $work, we turn it off where need performance (large storage arrays and such). I gather it's only a matter of time until relatime is default. >> and it also makes your snapshots grow constant. >=20 > This does not seem to be the case. For example, if I snapshot > zroot/usr/src and then tar it up, I generate a bunch of writes and the > snapshot grows to 70.5MB. However, when I tar it up a second time, > there are writes but the snapshot remains 70.5MB. It seems to use the > same blocks for subsequent atime updates. >=20 > If you made another snapshot, you would see more space used for that > one, of course. >=20 I'll defer to Allan to expand (was his recollection on snapshots) >> If you have a use for it, you can turn it on I guess. This would be >> solved by having the dataset editor we're planning for 10.1 >>=20 >> Seems easy enough to turn on once installed. And like Allan says, the >> editor for 10.1 would allow changing of the default. >=20 > The same case could be made for turning it off, make that an option in > the installer instead. >=20 Fair enough. Good idea. > Some people don't seem to use atime on a regular basis, but I use it a > lot when troubleshooting things, and I think others do to when they get > to the point where they realize how useful it is. >=20 >> I'll add that if scripting it, you can (in current state for 10.0) >> change the dataset options at-will. >>=20 >> The fletcher4 thing is a leftover, from older versions of ZFS where >> the default was fletcher2, I suppose we can remove it >=20 > While I'm picking nits: >=20 > There are some other locally set things that are default (exec set to on > on zroot/var/tmp is one), that might just inherit that from zroot/var. >=20 Need a +1 from Allan on that. > Also, zroot doesn't appear to be mounted on /zroot, as it is on other > ZFS-based systems. This has the side-effect of newly created > datasets not having a mountpoint by default, instead of /zroot/dataset. > I don't know of the reason behind this change either. >=20 Hmm, wonder if that's been fixed in HEAD already. > I'm going to cross-post this to -current, this is a topic that I think > warrants a wider audience. >=20 Cool. Thanks. --=20 Devin >> -----BEGIN PGP SIGNATURE----- >> Comment: GPGTools - https://urldefense.proofpoint.com/v1/url?u=3Dhttps:/= /gpgtools.org/&k=3D%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=3DLTzUWWrRnz2iN3Pt= HDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=3DwXwxswJCpc3K%2Bud90aYI%2B82v%2Fyfs1= mrTBzzeCe5XIXw%3D%0A&s=3Da9e0697e43ce4744f130997648d0104319221bba6924c28a94= 93ffa1cf6c3719 >>=20 >> iQEcBAEBCgAGBQJShRf/AAoJEKrMn5R9npq5TYwH/j8RMceM4STpCAoMTAz8zkKn >> gpftMrdf37TnAPHxsXJaiZejlp+D85/a9lglYbB7e4WdgoDX9ZXA0QLtCEmEtN4y >> jz7KNa5oABq1GjDtwm2xQISDIe8yYI+znLSaHA9W18kCUZzi8AOj70C+O5gyY28c >> c3N3j6Y4EZP2wtQnWSgxvCwIX5p86Jvr3QvhrRuuMnKMCTAhzwIx24qcnA4EcTzn >> p9w25CKLtOzF23n3McodaUmibbBCHOYyraLQJ+eJGDXcsPBipls3oiWyiYuqpcQr >> 18QpLN1lS35RnULcb5pxnP9Oy9rAwxHKves9Mfu0UoWw3qTjSAf8gsGyu6QaMgc=3D >> =3DGjYk >> -----END PGP SIGNATURE----- >>=20 >> _____________ >> The information contained in this message is proprietary and/or confiden= tial. If you are not the intended recipient, please: (i) delete the message= and all copies; (ii) do not disclose, distribute or use the message in any= manner; and (iii) notify the sender immediately. In addition, please be aw= are that any message addressed to our domain is subject to archiving and re= view by persons other than the intended recipient. Thank you. _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 21:04:34 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A5751C3; Thu, 14 Nov 2013 21:04:34 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 549C42DE6; Thu, 14 Nov 2013 21:04:34 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa05.fnfis.com (8.14.5/8.14.5) with ESMTP id rAEL4Qb9021943 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Nov 2013 15:04:26 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.152]) by LTCFISWMSGHT03.FNFIS.com ([10.132.206.31]) with mapi id 14.03.0158.001; Thu, 14 Nov 2013 15:04:24 -0600 From: "Teske, Devin" To: Marcus Reid Subject: Re: Defaults in 10.0 ZFS through bsdinstall Thread-Topic: Defaults in 10.0 ZFS through bsdinstall Thread-Index: AQHO4WP56r1WdCmD2k+in4awofQcqw== Date: Thu, 14 Nov 2013 21:04:23 +0000 Message-ID: References: <20131114173423.GA21761@blazingdot.com> <59A9B68B-4134-4217-83F3-B99759174EFE@fisglobal.com> <5285148E.6020903@allanjude.com> <3D3332FA-0ABF-4573-8E65-4E7FBB37100B@fisglobal.com> <20131114203424.GA22267@blazingdot.com> In-Reply-To: <20131114203424.GA22267@blazingdot.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="us-ascii" Content-ID: <7E3EBB51ACF7F3468410C0EEC8412229@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.14, 0.0.0000 definitions=2013-11-14_07:2013-11-13,2013-11-14,1970-01-01 signatures=0 Cc: freebsd-fs , Devin Teske , "Teske, Devin" , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 21:04:34 -0000 On Nov 14, 2013, at 12:34 PM, Marcus Reid wrote: > On Thu, Nov 14, 2013 at 06:35:43PM +0000, Teske, Devin wrote: >> On Nov 14, 2013, at 10:21 AM, Allan Jude wrote: >>> On 2013-11-14 9:34, Reid, Marcus wrote: >>>=20 >>> Hi, >>>=20 >>> I noticed a couple of things with the ZFS defaults that result from >>> using the new installer in 10.0-BETA3. >>>=20 >>> One, atime is turned off everywhere by default. There was a thread >>> on this list on June 8 with a subject of 'Changing the default for >>> ZFS atime to off?', and from what I can tell the idea of turning off >>> atime by default was not a popular one. >>>=20 >>> Two, and probably less controversial, is that fletcher4 is specified >>> exlicitly on the root pool, even though it is default (wouldn't you >>> just want to go with the default, in case it changes?) >>>=20 >>> Marcus >>=20 >> I have never heard a good argument for having atime on. >=20 > Can you address some of the issues that people brought up in the thread > I mentioned earlier? I'll summarize some: >=20 > - breaks some software (MTAs were mentioned), and the admin should > know when to turn atime on in those cases. >=20 > - "any mail program using mbox mail folders uses them to correctly > report which mailboxes have not been read yet" >=20 I'm looking at HEAD and I don't see "atime=3Doff" for the /var dataset. Knowing that most folks (accepting the defaults) will store their mail in /var/mail ... does the concern over atime=3Doff still exist? However, I did notice that before we go creating the /var dataset, we do set "atime=3Doff" for the boot pool/dataset. Is inheritance at-play here? and /var is turning up with atime=3Doff even though it's not specified? In that case, I certainly agree we should remove atime=3Doff from the last place it is used -- the boot pool (nowhere else). > - "Of course it can't be turned off by default. It is specified by > POSIX." >=20 > - "If the overhead were a real problem then file systems would use a > special atime cache" >=20 >> The performance penalty on ZFS is quite large >=20 > This is subjective, and if it were that bad it seems like other > ZFS-based systems would have turned it off as well, or done something > like caching/logging or relatime it to mitigate the performance hit. >=20 I do recall discussions about bringing over relatime and making it the default. Allan was the one that brought up the performance hit... Similarly where I $work, we turn it off where need performance (large storage arrays and such). I gather it's only a matter of time until relatime is default. >> and it also makes your snapshots grow constant. >=20 > This does not seem to be the case. For example, if I snapshot > zroot/usr/src and then tar it up, I generate a bunch of writes and the > snapshot grows to 70.5MB. However, when I tar it up a second time, > there are writes but the snapshot remains 70.5MB. It seems to use the > same blocks for subsequent atime updates. >=20 > If you made another snapshot, you would see more space used for that > one, of course. >=20 I'll defer to Allan to expand (was his recollection on snapshots) >> If you have a use for it, you can turn it on I guess. This would be >> solved by having the dataset editor we're planning for 10.1 >>=20 >> Seems easy enough to turn on once installed. And like Allan says, the >> editor for 10.1 would allow changing of the default. >=20 > The same case could be made for turning it off, make that an option in > the installer instead. >=20 Fair enough. Good idea. > Some people don't seem to use atime on a regular basis, but I use it a > lot when troubleshooting things, and I think others do to when they get > to the point where they realize how useful it is. >=20 >> I'll add that if scripting it, you can (in current state for 10.0) >> change the dataset options at-will. >>=20 >> The fletcher4 thing is a leftover, from older versions of ZFS where >> the default was fletcher2, I suppose we can remove it >=20 > While I'm picking nits: >=20 > There are some other locally set things that are default (exec set to on > on zroot/var/tmp is one), that might just inherit that from zroot/var. >=20 Need a +1 from Allan on that. > Also, zroot doesn't appear to be mounted on /zroot, as it is on other > ZFS-based systems. This has the side-effect of newly created > datasets not having a mountpoint by default, instead of /zroot/dataset. > I don't know of the reason behind this change either. >=20 Hmm, wonder if that's been fixed in HEAD already. > I'm going to cross-post this to -current, this is a topic that I think > warrants a wider audience. >=20 Cool. Thanks. --=20 Devin >> -----BEGIN PGP SIGNATURE----- >> Comment: GPGTools - https://urldefense.proofpoint.com/v1/url?u=3Dhttps:/= /gpgtools.org/&k=3D%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=3DLTzUWWrRnz2iN3Pt= HDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=3DwXwxswJCpc3K%2Bud90aYI%2B82v%2Fyfs1= mrTBzzeCe5XIXw%3D%0A&s=3Da9e0697e43ce4744f130997648d0104319221bba6924c28a94= 93ffa1cf6c3719 >>=20 >> iQEcBAEBCgAGBQJShRf/AAoJEKrMn5R9npq5TYwH/j8RMceM4STpCAoMTAz8zkKn >> gpftMrdf37TnAPHxsXJaiZejlp+D85/a9lglYbB7e4WdgoDX9ZXA0QLtCEmEtN4y >> jz7KNa5oABq1GjDtwm2xQISDIe8yYI+znLSaHA9W18kCUZzi8AOj70C+O5gyY28c >> c3N3j6Y4EZP2wtQnWSgxvCwIX5p86Jvr3QvhrRuuMnKMCTAhzwIx24qcnA4EcTzn >> p9w25CKLtOzF23n3McodaUmibbBCHOYyraLQJ+eJGDXcsPBipls3oiWyiYuqpcQr >> 18QpLN1lS35RnULcb5pxnP9Oy9rAwxHKves9Mfu0UoWw3qTjSAf8gsGyu6QaMgc=3D >> =3DGjYk >> -----END PGP SIGNATURE----- >>=20 >> _____________ >> The information contained in this message is proprietary and/or confiden= tial. If you are not the intended recipient, please: (i) delete the message= and all copies; (ii) do not disclose, distribute or use the message in any= manner; and (iii) notify the sender immediately. In addition, please be aw= are that any message addressed to our domain is subject to archiving and re= view by persons other than the intended recipient. Thank you. _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 21:35:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 029636AD; Thu, 14 Nov 2013 21:35:54 +0000 (UTC) Received: from mailrelay004.isp.belgacom.be (mailrelay004.isp.belgacom.be [195.238.6.170]) by mx1.freebsd.org (Postfix) with ESMTP id 685BD2002; Thu, 14 Nov 2013 21:35:53 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwGACNBhVJbsLPN/2dsb2JhbABbgwd/vyiBIBd0giUBAQVWIxALGAklDyoeBhOHbwMTAcBQjG2CPzMHhDEDmA+SDYMpOw Received: from 205.179-176-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.176.179.205]) by relay.skynet.be with ESMTP; 14 Nov 2013 22:35:46 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.7/8.14.7) with ESMTP id rAELZjgD054540; Thu, 14 Nov 2013 22:35:45 +0100 (CET) (envelope-from tijl@FreeBSD.org) Date: Thu, 14 Nov 2013 22:35:45 +0100 From: Tijl Coosemans To: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= Subject: Re: new Xorg (KMS, etc.) for Radeon 9600 Message-ID: <20131114223545.320b94fc@kalimero.tijl.coosemans.org> In-Reply-To: <20131114113846.4dcb2037@kalimero.tijl.coosemans.org> References: <527F95BE.7080908@gmx.com> <527FC05D.8080703@gmx.com> <5283E123.5000305@FreeBSD.org> <20131114113846.4dcb2037@kalimero.tijl.coosemans.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dt71@gmx.com, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 21:35:54 -0000 On Thu, 14 Nov 2013 11:38:46 +0100 Tijl Coosemans wrote: > On Wed, 13 Nov 2013 21:29:23 +0100 Jean-S=E9bastien P=E9dron wrote: >> Le 10/11/2013 18:20, dt71@gmx.com a =E9crit : >>> drmn0: info: GTT: 0M 0xF0000000 - 0xEFFFFFFF >>=20 >> Tijl Coosemans is right, the problem is this line. >>=20 >> As I don't really now how AGP works and have no AGP hardware to=20 >> reproduce the problem, can you post the output of the following commands= =20 >> as a start? >> pciconf -lvbce >> devinfo -vr >=20 > The attached patch should fix it, but I haven't been able to test it > yet. The ai_aperture_size field is in bytes. So it doesn't work, but it gets a bit further: drmn0: info: GTT: 256M 0xE0000000 - 0xEFFFFFFF info: [drm] Generation 2 PCI interface, using max accessible memory drmn0: info: VRAM: 128M 0x00000000D0000000 - 0x00000000D7FFFFFF (64M used) info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. info: [drm] radeon: irq initialized. info: [drm] Detected VRAM RAM=3D128M, BAR=3D128M info: [drm] RAM width 128bits DDR [TTM] Zone kernel: Available graphics memory: 519536 kiB [TTM] Initializing pool allocator info: [drm] radeon: 64M of VRAM memory ready info: [drm] radeon: 256M of GTT memory ready. info: [drm] radeon: 1 quad pipes, 1 Z pipes initialized. error: [drm:pid54242:radeon_gart_bind] *ERROR* trying to bind memory to uni= nitialized GART ! error: [drm:pid54242:radeon_ttm_backend_bind] *ERROR* failed to bind 1 page= s at 0x00000000 drmn0: warning: (-22) create WB bo failed drmn0: error: Disabling GPU acceleration info: [drm] radeon: cp finalized info: [drm] radeon: cp finalized [TTM] Finalizing pool allocator [TTM] Zone kernel: Used memory at exit: 0 kiB info: [drm] radeon: ttm finalized info: [drm] Forcing AGP to PCI mode It looks like some support for AGP is missing in radeon_ttm.c. It's hidden behind #ifdef DUMBBELL_WIP. From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 21:46:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6806EA33 for ; Thu, 14 Nov 2013 21:46:22 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DFA0B20B6 for ; Thu, 14 Nov 2013 21:46:21 +0000 (UTC) Received: from [157.181.98.186] ([157.181.98.186]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M5uLh-1VVteO3ok5-00xqlI for ; Thu, 14 Nov 2013 22:46:14 +0100 Message-ID: <52854485.8090208@gmx.com> Date: Thu, 14 Nov 2013 22:45:41 +0100 From: dt71@gmx.com User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Firefox/24.0 SeaMonkey/2.21 MIME-Version: 1.0 To: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= , freebsd-current@freebsd.org Subject: Re: new Xorg (KMS, etc.) for Radeon 9600 References: <527F95BE.7080908@gmx.com> <527FC05D.8080703@gmx.com> <5283E123.5000305@FreeBSD.org> In-Reply-To: <5283E123.5000305@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:wn6Zv9cxXHRfyCqwwPmCke1EjnbLVDurrmtBgrvPxEBRpOeN9sb 6ZqvYpomnh0L81GN660yX/Etlgdq1GavYD+9l8I8saDuDnkTnXcHSCbcJMIB3qORRymtdVM 4aG/5PTvfjT3h6eDpTCo4aWOp0wxQGFY7HM6uJhzQQfcz30G9ylOH2W9+Z+PbDc0SkPHmYe JlKoWYy2ZNXmueeg/Fb9w== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 21:46:22 -0000 Jean-Sébastien Pédron wrote, On 11/13/2013 21:29: > As I don't really now how AGP works and have no AGP hardware to reproduce the problem, can you post the output of the following commands as a start? > pciconf -lvbce hostb0@pci0:0:0:0: class=0x060000 card=0x25701849 chip=0x25708086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82865G/PE/P DRAM Controller/Host-Hub Interface' class = bridge subclass = HOST-PCI bar [10] = type Prefetchable Memory, range 32, base 0xf0000000, size 134217728, enabled cap 09[e4] = vendor (length 6) Intel cap 0 version 1 cap 02[a0] = AGP v3 8x 4x SBA disabled PCI errors = Received Master-Abort pcib1@pci0:0:1:0: class=0x060400 card=0x00000000 chip=0x25718086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '82865G/PE/P AGP Bridge' class = bridge subclass = PCI-PCI uhci0@pci0:0:29:0: class=0x0c0300 card=0x24d01849 chip=0x24d28086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) USB UHCI Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0xe000, size 32, enabled uhci1@pci0:0:29:1: class=0x0c0300 card=0x24d01849 chip=0x24d48086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) USB UHCI Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0xe400, size 32, enabled uhci2@pci0:0:29:2: class=0x0c0300 card=0x24d01849 chip=0x24d78086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) USB UHCI Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0xe800, size 32, enabled uhci3@pci0:0:29:3: class=0x0c0300 card=0x24d01849 chip=0x24de8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) USB UHCI Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0xec00, size 32, enabled ehci0@pci0:0:29:7: class=0x0c0320 card=0x24d01849 chip=0x24dd8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xff2ffc00, size 1024, enabled cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 pcib2@pci0:0:30:0: class=0x060400 card=0x00000000 chip=0x244e8086 rev=0xc2 hdr=0x01 vendor = 'Intel Corporation' device = '82801 PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x00000000 chip=0x24d08086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) LPC Interface Bridge' class = bridge subclass = PCI-ISA atapci0@pci0:0:31:1: class=0x01018a card=0x24d01849 chip=0x24db8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) IDE Controller' class = mass storage subclass = ATA bar [20] = type I/O Port, range 32, base 0xfc00, size 16, enabled bar [24] = type Memory, range 32, base 0, size 1024, enabled none0@pci0:0:31:3: class=0x0c0500 card=0x24d01849 chip=0x24d38086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) SMBus Controller' class = serial bus subclass = SMBus bar [20] = type I/O Port, range 32, base 0x400, size 32, enabled pcm0@pci0:0:31:5: class=0x040100 card=0x97611849 chip=0x24d58086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller' class = multimedia subclass = audio bar [10] = type I/O Port, range 32, base 0xd800, size 256, enabled bar [14] = type I/O Port, range 32, base 0xdc00, size 64, enabled bar [18] = type Memory, range 32, base 0xff2ff800, size 512, enabled bar [1c] = type Memory, range 32, base 0xff2ff400, size 256, enabled cap 01[50] = powerspec 2 supports D0 D3 current D0 vgapci0@pci0:1:0:0: class=0x030000 card=0x200217ee chip=0x41501002 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD] nee ATI' device = 'RV350 AP [Radeon 9600]' class = display subclass = VGA bar [10] = type Prefetchable Memory, range 32, base 0xd0000000, size 268435456, enabled bar [14] = type I/O Port, range 32, base 0xa800, size 256, enabled bar [18] = type Memory, range 32, base 0xff0f0000, size 65536, enabled cap 02[58] = AGP v3 8x 4x SBA disabled cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 vgapci1@pci0:1:0:1: class=0x038000 card=0x200317ee chip=0x41701002 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD] nee ATI' device = 'RV350 AP [Radeon 9600] (Secondary)' class = display bar [10] = type Prefetchable Memory, range 32, base 0xc0000000, size 268435456, enabled bar [14] = type Memory, range 32, base 0xff0e0000, size 65536, enabled cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 rl0@pci0:2:5:0: class=0x020000 card=0x81391849 chip=0x813910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL-8139/8139C/8139C+' class = network subclass = ethernet bar [10] = type I/O Port, range 32, base 0xb800, size 256, enabled bar [14] = type Memory, range 32, base 0xff1ffc00, size 256, enabled cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 > devinfo -vr nexus0 npx0 apic0 ram0 I/O memory addresses: 0x0-0x9fbff 0x100000-0x1ff3ffff acpi0 Interrupt request lines: 9 I/O ports: 0x10-0x1f 0x22-0x3f 0x44-0x5f 0x62-0x63 0x65-0x6f 0x72-0x7f 0x80 0x84-0x86 0x88 0x8c-0x8e 0x90-0x9f 0xa2-0xbf 0xe0-0xef 0x295-0x296 0x480-0x4bf 0x4d0-0x4d1 0x680-0x6ff 0x800-0x87f I/O memory addresses: 0xc0000-0xdffff 0xe0000-0xfffff 0xfec00000-0xfec00fff 0xfed20000-0xfed8ffff 0xfee00000-0xfee00fff 0xff380000-0xffefffff 0xfff00000-0xffffffff cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU1 acpi_throttle0 ACPI I/O ports: 0x810-0x813 cpufreq0 cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU2 unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU3 unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU4 pcib0 pnpinfo _HID=PNP0A03 _UID=0 at handle=\_SB_.PCI0 I/O ports: 0xcf8-0xcff pci0 hostb0 pnpinfo vendor=0x8086 device=0x2570 subvendor=0x1849 subdevice=0x2570 class=0x060000 at slot=0 function=0 I/O memory addresses: 0xf0000000-0xf7ffffff agp0 pcib1 pnpinfo vendor=0x8086 device=0x2571 subvendor=0x0000 subdevice=0x0000 class=0x060400 at slot=1 function=0 handle=\_SB_.PCI0.P0P1 I/O ports: 0xa000-0xafff I/O memory addresses: 0xaff00000-0xefefffff 0xff000000-0xff0fffff pci1 vgapci0 pnpinfo vendor=0x1002 device=0x4150 subvendor=0x17ee subdevice=0x2002 class=0x030000 at slot=0 function=0 Interrupt request lines: 16 pcib1 I/O port window: 0xa800-0xa8ff pcib1 memory window: 0xff0f0000-0xff0fffff pcib1 prefetch window: 0xd0000000-0xdfffffff vgapm0 drm0 drmn0 radeon_iicbb0 iicbb0 iicbus0 iic0 at addr=0 radeon_iicbb1 iicbb1 iicbus1 iic1 at addr=0 radeon_iicbb2 iicbb2 iicbus2 iic2 at addr=0 vgapci1 pnpinfo vendor=0x1002 device=0x4170 subvendor=0x17ee subdevice=0x2003 class=0x038000 at slot=0 function=1 pcib1 memory window: 0xff0e0000-0xff0effff pcib1 prefetch window: 0xc0000000-0xcfffffff drm1 drmn1 uhci0 pnpinfo vendor=0x8086 device=0x24d2 subvendor=0x1849 subdevice=0x24d0 class=0x0c0300 at slot=29 function=0 handle=\_SB_.PCI0.USB1 Interrupt request lines: 16 I/O ports: 0xe000-0xe01f usbus0 uhub1 ums0 pnpinfo vendor=0x04fc product=0x0801 devclass=0x00 devsubclass=0x00 sernum="" release=0x1611 mode=host intclass=0x03 intsubclass=0x01 i at bus=1 hubaddr=2 port=0 devaddr=2 interface=0 uhci1 pnpinfo vendor=0x8086 device=0x24d4 subvendor=0x1849 subdevice=0x24d0 class=0x0c0300 at slot=29 function=1 handle=\_SB_.PCI0.USB2 Interrupt request lines: 19 I/O ports: 0xe400-0xe41f usbus1 uhub0 uhci2 pnpinfo vendor=0x8086 device=0x24d7 subvendor=0x1849 subdevice=0x24d0 class=0x0c0300 at slot=29 function=2 handle=\_SB_.PCI0.USB3 Interrupt request lines: 18 I/O ports: 0xe800-0xe81f usbus2 uhub4 uhci3 pnpinfo vendor=0x8086 device=0x24de subvendor=0x1849 subdevice=0x24d0 class=0x0c0300 at slot=29 function=3 handle=\_SB_.PCI0.USB4 Interrupt request lines: 16 I/O ports: 0xec00-0xec1f usbus3 uhub3 ehci0 pnpinfo vendor=0x8086 device=0x24dd subvendor=0x1849 subdevice=0x24d0 class=0x0c0320 at slot=29 function=7 handle=\_SB_.PCI0.EUSB Interrupt request lines: 23 I/O memory addresses: 0xff2ffc00-0xff2fffff usbus4 uhub2 pcib2 pnpinfo vendor=0x8086 device=0x244e subvendor=0x0000 subdevice=0x0000 class=0x060400 at slot=30 function=0 handle=\_SB_.PCI0.P0P4 I/O ports: 0xb000-0xb0ff 0xb400-0xb4ff 0xb800-0xb8ff 0xbc00-0xbcff I/O memory addresses: 0xff100000-0xff1fffff pci2 rl0 pnpinfo vendor=0x10ec device=0x8139 subvendor=0x1849 subdevice=0x8139 class=0x020000 at slot=5 function=0 Interrupt request lines: 22 pcib2 I/O port window: 0xb800-0xb8ff pcib2 memory window: 0xff1ffc00-0xff1ffcff miibus0 rlphy0 pnpinfo oui=0x0 model=0x0 rev=0x0 at phyno=0 isab0 pnpinfo vendor=0x8086 device=0x24d0 subvendor=0x0000 subdevice=0x0000 class=0x060100 at slot=31 function=0 handle=\_SB_.PCI0.SBRG isa0 sc0 vga0 I/O ports: 0x3c0-0x3df I/O memory addresses: 0xa0000-0xbffff orm0 pnpinfo pnpid=ORM0000 ACPI I/O memory addresses: 0xc0000-0xccfff fdc0 ppc0 uart0 uart1 wbwd0 atapci0 pnpinfo vendor=0x8086 device=0x24db subvendor=0x1849 subdevice=0x24d0 class=0x01018a at slot=31 function=1 handle=\_SB_.PCI0.IDE0 I/O ports: 0x170-0x177 0x1f0-0x1f7 0x376 0x3f6 0xfc00-0xfc0f ata0 at channel=0 Interrupt request lines: 14 ata1 at channel=1 Interrupt request lines: 15 unknown pnpinfo vendor=0x8086 device=0x24d3 subvendor=0x1849 subdevice=0x24d0 class=0x0c0500 at slot=31 function=3 I/O ports: 0x400-0x41f pcm0 pnpinfo vendor=0x8086 device=0x24d5 subvendor=0x1849 subdevice=0x9761 class=0x040100 at slot=31 function=5 Interrupt request lines: 17 I/O ports: 0xd800-0xd8ff 0xdc00-0xdc3f I/O memory addresses: 0xff2ff400-0xff2ff4ff 0xff2ff800-0xff2ff9ff atpic0 pnpinfo _HID=PNP0000 _UID=0 at handle=\_SB_.PCI0.SBRG.PIC_ I/O ports: 0x20-0x21 0xa0-0xa1 atdma0 pnpinfo _HID=PNP0200 _UID=0 at handle=\_SB_.PCI0.SBRG.DMAD DMA request lines: 4 I/O ports: 0x0-0xf 0x81-0x83 0x87 0x89-0x8b 0x8f 0xc0-0xdf attimer0 pnpinfo _HID=PNP0100 _UID=0 at handle=\_SB_.PCI0.SBRG.TMR_ Interrupt request lines: 0 I/O ports: 0x40-0x43 atrtc0 pnpinfo _HID=PNP0B00 _UID=0 at handle=\_SB_.PCI0.SBRG.RTC0 Interrupt request lines: 8 I/O ports: 0x70-0x71 unknown pnpinfo _HID=PNP0800 _UID=0 at handle=\_SB_.PCI0.SBRG.SPKR I/O ports: 0x61 npxisa0 pnpinfo _HID=PNP0C04 _UID=0 at handle=\_SB_.PCI0.SBRG.COPR I/O ports: 0xf0-0xff unknown pnpinfo _HID=PNP0501 _UID=2 at handle=\_SB_.PCI0.SBRG.UAR2 unknown pnpinfo _HID=PNP0700 _UID=0 at handle=\_SB_.PCI0.SBRG.FDC_ unknown pnpinfo _HID=PNP0400 _UID=1 at handle=\_SB_.PCI0.SBRG.LPTE unknown pnpinfo _HID=PNPB02F _UID=0 at handle=\_SB_.PCI0.SBRG.GAME unknown pnpinfo _HID=PNPB006 _UID=0 at handle=\_SB_.PCI0.SBRG.MIDI acpi_sysresource0 pnpinfo _HID=PNP0C02 _UID=16 at handle=\_SB_.PCI0.SBRG.RMSC acpi_sysresource1 pnpinfo _HID=PNP0C02 _UID=0 at handle=\_SB_.PCI0.SBRG.OMSC atkbdc0 pnpinfo _HID=PNP0303 _UID=0 at handle=\_SB_.PCI0.SBRG.PS2K Interrupt request lines: 1 I/O ports: 0x60 0x64 atkbd0 unknown pnpinfo _HID=PNP0F03 _UID=0 at handle=\_SB_.PCI0.SBRG.PS2M unknown pnpinfo _HID=PNP0501 _UID=1 at handle=\_SB_.PCI0.SBRG.UAR1 acpi_sysresource2 pnpinfo _HID=PNP0C02 _UID=46 at handle=\_SB_.PCI0.SBRG.SIOR unknown pnpinfo _HID=PNP0103 _UID=0 at handle=\_SB_.PCI0.SBRG.HPET acpi_sysresource3 pnpinfo _HID=PNP0C01 _UID=1 at handle=\_SB_.RMEM acpi_button0 pnpinfo _HID=PNP0C0C _UID=170 at handle=\_SB_.PWRB pci_link0 pnpinfo _HID=PNP0C0F _UID=1 at handle=\_SB_.LNKA pci_link1 pnpinfo _HID=PNP0C0F _UID=2 at handle=\_SB_.LNKB pci_link2 pnpinfo _HID=PNP0C0F _UID=3 at handle=\_SB_.LNKC pci_link3 pnpinfo _HID=PNP0C0F _UID=4 at handle=\_SB_.LNKD pci_link4 pnpinfo _HID=PNP0C0F _UID=5 at handle=\_SB_.LNKE pci_link5 pnpinfo _HID=PNP0C0F _UID=6 at handle=\_SB_.LNKF pci_link6 pnpinfo _HID=PNP0C0F _UID=7 at handle=\_SB_.LNKG pci_link7 pnpinfo _HID=PNP0C0F _UID=8 at handle=\_SB_.LNKH unknown pnpinfo _HID=PNP0C0E _UID=0 at handle=\_SB_.SLPB acpi_timer0 pnpinfo unknown at unknown ACPI I/O ports: 0x808-0x80b From owner-freebsd-current@FreeBSD.ORG Thu Nov 14 23:26:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 453875BD for ; Thu, 14 Nov 2013 23:26:42 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B1E6C26E8 for ; Thu, 14 Nov 2013 23:26:41 +0000 (UTC) Received: from [157.181.98.186] ([157.181.98.186]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LjJCt-1V9PFI3jzj-00dTNW for ; Fri, 15 Nov 2013 00:26:40 +0100 Message-ID: <52855C0E.5040303@gmx.com> Date: Fri, 15 Nov 2013 00:26:06 +0100 From: dt71@gmx.com User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Firefox/24.0 SeaMonkey/2.21 MIME-Version: 1.0 To: Adrian Chadd , Daniel O'Connor Subject: Re: cron(8) improvement References: <52792B60.1030309@allanjude.com> <488180AE-5C23-402A-BAA4-E3263D8C52BF@kientzle.com> <1383788977.14448.44112617.6F0D61A0@webmail.messagingengine.com> <527AFAA1.1040001@allanjude.com> <527BCA55.2000207@allanjude.com> <527C5D52.7030508@allanjude.com> <047405A8-B6EB-427B-A2E4-6254DD1A077B@orthanc.ca> <3E6377FF-69FE-48E4-BFB1-E5095A7FA1BB@orthanc.ca> <527C6DEF.6020102@allanjude.com> <527E3EB3.6000301@FreeBSD.org> <8034B822-F903-43D1-8BF6-DFAD7C22F5B0@gsoft.com.au> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:U8urZg0iMxvHbFyqYqNe1eLihFkUhFOj6d8Xn0EQs7gH8elonFf VWfBIU6M8j8AWD/HbWxZIkelk7EY2hPYP7tKaA+hQT+CK4ALnwK+Xv6l/ujW1yL/a1VXFB7 vf0XfokYu6tUk4n2YEKT/imwXimnCUZj/QqNipCNz07sswbg/11ny0PRsqQQnPBRLWdRvcM mRAL1ECwtW+TAJengTdFw== Cc: FreeBSD Current , Matthew Seaman X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 23:26:42 -0000 Adrian Chadd wrote, On 11/10/2013 01:18: > I'm kinda fed up installing packages that don't enable themselves. There should be no package that needs activation, that is if you want a desktop computer, not a server. > 'pkg install xorg' is not enough to get a working xorg. You have to > enable hal and dbus and then restart (so things come up in the right > order; manually starting them doesn't work) in order to get X working. I use: hald_enable="NO" dbus_enable="NO" > Please install the cron scripts by default. Please then write up a > simple rc.conf style setup where the cron scripts can check a config > file to see if they should run. Provided that there will be - an option for every instance of a port wanting to install a cron.d script -- ie., port options plus a settable NO_CROND_SCRIPTS -- and - a fail-safe mechanism to disable all cron.d entries, ie. crond_enable="NO", I feel that installed scripts could be an option. From owner-freebsd-current@FreeBSD.ORG Fri Nov 15 02:01:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 558B26E9 for ; Fri, 15 Nov 2013 02:01:53 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DCB7C2ECC for ; Fri, 15 Nov 2013 02:01:52 +0000 (UTC) Received: from [157.181.98.186] ([157.181.98.186]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lrw2c-1VZyFS2aYo-013hUE for ; Fri, 15 Nov 2013 03:01:44 +0100 Message-ID: <52858067.2060200@gmx.com> Date: Fri, 15 Nov 2013 03:01:11 +0100 From: dt71@gmx.com User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Firefox/24.0 SeaMonkey/2.21 MIME-Version: 1.0 To: Tijl Coosemans , =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqQ==?= =?UTF-8?B?ZHJvbg==?= Subject: Re: new Xorg (KMS, etc.) for Radeon 9600 References: <527F95BE.7080908@gmx.com> <527FC05D.8080703@gmx.com> <5283E123.5000305@FreeBSD.org> <20131114113846.4dcb2037@kalimero.tijl.coosemans.org> In-Reply-To: <20131114113846.4dcb2037@kalimero.tijl.coosemans.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:/ZTQFHv6bCqHgEZSqmw0824WbHJnCNmtt2m0C0GYXSjOdnbRhn8 kv0P8z98JREqYzG/0yKtfEP0tlYWfa2y7gonKcLkoMmXSuaKdU4EyP6DG2k9HFxoSpI2GvU kvGdSUv+h2/5SHQ4XBReRdxokIitU9GXqeb0+1vaTuUGu/iTiG6rODiu3DR5RVegVicmfQS IRS6cFGRlz0BChEAshY7w== Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 02:01:53 -0000 Tijl Coosemans wrote, On 11/14/2013 11:38: > On Wed, 13 Nov 2013 21:29:23 +0100 Jean-Sébastien Pédron wrote: >> Le 10/11/2013 18:20, dt71@gmx.com a écrit : >>> drmn0: info: GTT: 0M 0xF0000000 - 0xEFFFFFFF >> >> Tijl Coosemans is right, the problem is this line. > > The attached patch should fix it, but I haven't been able to test it > yet. The ai_aperture_size field is in bytes. Doesn't help in practice (the program still should run faster), although now I get: drmn0: info: GTT: 128M 0xF0000000 - 0xF7FFFFFF From owner-freebsd-current@FreeBSD.ORG Fri Nov 15 03:14:00 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 215CCE5F for ; Fri, 15 Nov 2013 03:14:00 +0000 (UTC) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E7048234C for ; Fri, 15 Nov 2013 03:13:59 +0000 (UTC) Received: by mail-oa0-f53.google.com with SMTP id k1so3272204oag.40 for ; Thu, 14 Nov 2013 19:13:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=FxRKjPiGgvjRrDPARKdyr2h5eVU+T9AiH4TQPSAEFv0=; b=Lh9A55WSFHz1xKUiNCz5QXdOLBitFibC7I+UuOfjleaP4IeWZvH/a6E1e2IeMq6iGi XzDZO+HBo3xa50kKjireCVOnA3czET5QgwQ+c/u3hQx4u+pokzY/KPgEAhzFk2b1XaT/ 0anEb/hdYmyqHDL7aN2OvoE99mtFv0bfSArGqnWVg+JkK2Otk/bV2kjIW6xtQS2jEutt c/baWJoBz/On96mvHmzHh0HP77u2WSq6JRbaCPpurLHrEYDmsIlH+W7GSt1h0w881nmG ZLmHCqVLB8eldhcn+iypmtO7mSErxStrtwMza9TKfR7dfp9N3epcVTx7Q+U2Whi1Vxf+ VoXA== MIME-Version: 1.0 X-Received: by 10.60.58.166 with SMTP id s6mr4854372oeq.40.1384485238576; Thu, 14 Nov 2013 19:13:58 -0800 (PST) Received: by 10.76.70.164 with HTTP; Thu, 14 Nov 2013 19:13:58 -0800 (PST) Date: Thu, 14 Nov 2013 22:13:58 -0500 Message-ID: Subject: pkg install on CURRENT ? From: Outback Dingo To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 03:14:00 -0000 anyway to resolve this ??? id like to pkg install a few things or is my only option ports Checking integrity... done [1/16] Installing expat-2.0.1_2...pkg: wrong architecture: freebsd:10:x86:64 instead of freebsd:11:x86:64 From owner-freebsd-current@FreeBSD.ORG Fri Nov 15 08:12:16 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B4696E47 for ; Fri, 15 Nov 2013 08:12:16 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4E6D1260C for ; Fri, 15 Nov 2013 08:12:16 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id hi5so2111407wib.0 for ; Fri, 15 Nov 2013 00:12:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=vh6/Bc2CgfoMFEOZj/Qg8T3JBkmL90a+H5ZNPgjEItg=; b=lWCEy4ZREDVUSbZWRBxqO2HxCJKpqQNfTbe3tGLor3qZx5/qJ+grtOKFiQw5ORLk1e PHvl34RXXoy5nX0KVEuLolO5954/0gq3OvBupZGb26yLOsLjsbkM668R0ajeczhQc9d4 2b402Tv3OCg96U1/qD+hChjY6vXf9aSnOcm6gfjwYD2U9ZaAem9w6WknrEo/qpyH8eCn WRstCJ579ot1ck2dVGh+bjnWldvSTQ+VSZrbF0htEGHDYD0zRMPey1A8IsvGeDdkxL5Y SeXvpElrAyjFoeIVkC7AnI+RNMxCM4OiV8RM8ArszOf8Jh7YOwbgW95U9ny8AvA9wHCv us7A== X-Received: by 10.194.75.165 with SMTP id d5mr5739750wjw.18.1384503134673; Fri, 15 Nov 2013 00:12:14 -0800 (PST) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id ey4sm2574050wic.11.2013.11.15.00.12.13 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 15 Nov 2013 00:12:13 -0800 (PST) Sender: Baptiste Daroussin Date: Fri, 15 Nov 2013 09:12:11 +0100 From: Baptiste Daroussin To: Outback Dingo Subject: Re: pkg install on CURRENT ? Message-ID: <20131115081211.GP56153@ithaqua.etoilebsd.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="U+NfgObvpQT1Q9Yq" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 08:12:16 -0000 --U+NfgObvpQT1Q9Yq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 14, 2013 at 10:13:58PM -0500, Outback Dingo wrote: > anyway to resolve this ??? id like to pkg install a few things or is my > only option ports >=20 > Checking integrity... done > [1/16] Installing expat-2.0.1_2...pkg: wrong architecture: > freebsd:10:x86:64 instead of freebsd:11:x86:64 pkg -vv, uname -a and file /bin/sh please regards, Bapt --U+NfgObvpQT1Q9Yq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlKF11sACgkQ8kTtMUmk6EzxuwCbB5YhcN7EciiGhEWzjIBOay+B UAgAn0fYUNcwvv5o2sGZtTvGwfiuaOE5 =S6em -----END PGP SIGNATURE----- --U+NfgObvpQT1Q9Yq-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 15 08:58:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04D2CA14 for ; Fri, 15 Nov 2013 08:58:24 +0000 (UTC) Received: from nm16.bullet.mail.ir2.yahoo.com (nm16.bullet.mail.ir2.yahoo.com [212.82.96.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E223128AB for ; Fri, 15 Nov 2013 08:58:22 +0000 (UTC) Received: from [212.82.98.125] by nm16.bullet.mail.ir2.yahoo.com with NNFMP; 15 Nov 2013 08:58:14 -0000 Received: from [46.228.39.90] by tm18.bullet.mail.ir2.yahoo.com with NNFMP; 15 Nov 2013 08:58:14 -0000 Received: from [127.0.0.1] by smtp127.mail.ir2.yahoo.com with NNFMP; 15 Nov 2013 08:58:14 -0000 X-Yahoo-Newman-Id: 948437.93391.bm@smtp127.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 7YjmUiAVM1lxyjbtl0m9ymTaFTMnAwCzo1llK.i.hsfApDp 9jI4mRHa6o9azh.6MFq_tge8v2Hs2Pn3ZNHHnMRVIcIR7d33.rCwt1CTn_uk y_4nCwvYorraPQtTrpUx8JwrAlcN.cOObVly6.ght.ok2M32fiYMycJDRFWw 9m6BMtMRsPCiZ5HiPkZ3ac7c4laPNGxqIRSnnh9Ac_1MvB6omA13PuVtW0qD FaNfgQ.Xxhbhd2I.fxNyg_uUg3YkOXxpO2U3Ct1NuVDD963s5hX1pV.ZQCgs GVcOv9mABTwhMhXj6xGBZJaFto.Cpkl2RdF1tkt_9ja90azP..DUCaJiCu3G odLD8puj0TUi0Chnxosz.hthglXHJ8QTSkww7ezN0CKf1tO0lIT629rYp8ai gk0SidaRh88KsCLwDkPGNyK7QxqB1QZXeKJQPSg_rvg5Tdj.j3c57lQuwhRg lBTDWnmzsM.WuhwCWbwT4qXMm7iC92ZKZqYfWys4qlcEujr2Op3lZgH7rHeA dmU88RAuft5BA9cxyVoG6BQmLMFXimaaB X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. X-Rocket-Received: from [192.168.119.11] (se@84.154.100.25 with ) by smtp127.mail.ir2.yahoo.com with SMTP; 15 Nov 2013 08:58:14 +0000 UTC Message-ID: <5285E21D.6050701@freebsd.org> Date: Fri, 15 Nov 2013 09:58:05 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Defaults in 10.0 ZFS through bsdinstall References: <20131114173423.GA21761@blazingdot.com> <59A9B68B-4134-4217-83F3-B99759174EFE@fisglobal.com> <5285148E.6020903@allanjude.com> <3D3332FA-0ABF-4573-8E65-4E7FBB37100B@fisglobal.com> <1384462198.13183.47596065.6F8E7BCD@webmail.messagingengine.com> <0CBA81A49FFC447C9452C9A27BC2D017@multiplay.co.uk> <9A38EBE3-4012-4165-8655-03330277B04A@fisglobal.com> <55AA006F-E70E-4434-84EE-97049150AEDF@FreeBSD.org> In-Reply-To: <55AA006F-E70E-4434-84EE-97049150AEDF@FreeBSD.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 08:58:24 -0000 Am 15.11.2013 01:00, schrieb Mark Felder: > On Nov 14, 2013, at 15:04, Teske, Devin wrote: >> Sounds like a vote for enabling it where-needed by-default (e.g., /var as a whole >> or more selectively, /var/mail) > > I'd be OK with FreeBSD taking a stance and moving to noatime by default but we should be consistent across all filesystems that a user can install the OS on from our provided installation media. We should make it obvious to the end users as well. The cost of atime on UFS and ZFS is quite different. While I understand that consistency is a plus, I do think that there is good reason to have different defaults for UFS and ZFS. It would be good if there was a global parameter which let the user choose the atime setting for all file-systems where this setting is not overridden. Such a parameter could be OFF (noatime) for ZFS and ON for UFS by default, but with a short explanation about the consequences and a way to toggle this setting if desired. Regards, STefan From owner-freebsd-current@FreeBSD.ORG Fri Nov 15 09:24:09 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E16E3E8 for ; Fri, 15 Nov 2013 09:24:09 +0000 (UTC) Received: from nm14-vm9.bullet.mail.ir2.yahoo.com (nm14-vm9.bullet.mail.ir2.yahoo.com [212.82.96.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BD97D2A58 for ; Fri, 15 Nov 2013 09:24:08 +0000 (UTC) Received: from [212.82.98.56] by nm14.bullet.mail.ir2.yahoo.com with NNFMP; 15 Nov 2013 09:24:01 -0000 Received: from [46.228.39.97] by tm9.bullet.mail.ir2.yahoo.com with NNFMP; 15 Nov 2013 09:24:01 -0000 Received: from [127.0.0.1] by smtp134.mail.ir2.yahoo.com with NNFMP; 15 Nov 2013 09:24:01 -0000 X-Yahoo-Newman-Id: 455592.43865.bm@smtp134.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: vvlC8r4VM1mCfRWsvkZJWkydyqSonDsCVG6WamkDu9zhWeY VWmuToSlirQ0I9N1uxMnoHEaEEgAUdH7oahzQmDHwAAHy9FEktKQjJOuWHvk f6bvB_kpG5uBJvtCB7ppDN1Ah9PmLPx2ylaquK2hZzcHTzUDL1DNRJVOeNqa DlkXxBUX4iH.K2pXhWMPm41BV9vU5Bz6NlGHqYdDsiSgMgR2bU3X7GBuu4Dq De_AiZjC5CGMgDFEemBQsDJQ9hNnFppwEXIutuTQkmsgFOO5uCM4XuKhztUn yC011M1QVSMOsxfuGzQN0K03AlgEO8BfIXXW4yf8I_75iHJ8MjUXg3DceDdd rZYxLbIfIMJOeedYUk28bQ3FhMaFbazMz7ui9hzO6uVKtOR0oaLMeU9lw2Md Kiyzj9a92.c0iou3ZChIWiJUpA9_CESnP3Fqc.TpvRntmeLZP6P_mzckNOH8 4k25O_2qMAlvUScz1GokhtFyHeECQWUZUIO4wGNUYfthzxaQ.r7RBoFZNg76 dHpFY7JkFzC.TpU04LeysGGespxFyAg-- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. X-Rocket-Received: from [192.168.119.11] (se@84.154.100.25 with ) by smtp134.mail.ir2.yahoo.com with SMTP; 15 Nov 2013 09:24:01 +0000 UTC Message-ID: <5285E827.1090501@freebsd.org> Date: Fri, 15 Nov 2013 10:23:51 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Defaults in 10.0 ZFS through bsdinstall References: <20131114173423.GA21761@blazingdot.com> <59A9B68B-4134-4217-83F3-B99759174EFE@fisglobal.com> <5285148E.6020903@allanjude.com> <3D3332FA-0ABF-4573-8E65-4E7FBB37100B@fisglobal.com> <1384462198.13183.47596065.6F8E7BCD@webmail.messagingengine.com> <55232624-3B76-4781-91E0-0C2A6260144D@fisglobal.com> In-Reply-To: <55232624-3B76-4781-91E0-0C2A6260144D@fisglobal.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 09:24:09 -0000 Am 14.11.2013 22:02, schrieb Teske, Devin: > On Nov 14, 2013, at 12:49 PM, Mark Felder wrote: >> We don't even do installs on UFS with atime disabled by default in fstab >> so why should we so suddenly change course for ZFS? >> > > You've made a good point. There is major difference between UFS and ZFS: UFS allows in-place updates of i-node fields (like atime), while ZFS uses COW for all data, file contents and meta-data like the i-nodes. With atime ON on UFS you'll see a small number of writes on file-systems that are only read - we are used to accept that. On ZFS every update of atime causes a write of the meta-data to a free location on disk, then updates of all data structures that reference that meta-data up to the root of the tree (the uberblock). An update of a few bytes turns out to write tens of KB for each atime update (within the TXG sync interval, which defaults to 5 seconds on FreeBSD). If you create snapshots, then each snapshot will contain a copy of the metadata that was valid at the time of the snapshot (well, that's not so different from the situation with UFS snapshots, just that the data structures are much more complex and larger in the ZFS case). Due to the ease and speed of snapshot creation with ZFS there probably are a magnitude or more snapshots on a typical ZFS system than on one using UFS (I currently have a few hundred and have turned off periodic snapshot generation on many unimportant file-systems, already). I really hope that we get relatime (with minor variations that were discussed a few months ago) and that we make it the default in some future release ... Regards, STefan From owner-freebsd-current@FreeBSD.ORG Fri Nov 15 13:29:11 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F20E4E3; Fri, 15 Nov 2013 13:29:11 +0000 (UTC) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 60B4128D6; Fri, 15 Nov 2013 13:29:11 +0000 (UTC) Received: by mail-oa0-f44.google.com with SMTP id l6so3881694oag.17 for ; Fri, 15 Nov 2013 05:29:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1jOmKDnMcZfHmSCRtFr7XC3HqSWDVm9mL6S01rTnh/M=; b=a4OJg44bVJoepNeHLDBI2Za48c/+t8fggMm8c3YNt2v5RwAy6m2hf/rwNEi409Tqz7 2yiuBWK8aiXK7ScBbXsLVC4MfDweETgyU7mgLCNkWKBOP+3dNEAmFLw5T686repCcuWY 63sonKvnbo3sd8GTA97ZtEI9rnYVKaBhDvKn3sv8a+5fz8Lfw5951tk/ZQdogr9DmEGT LHWiyhg9O8yYB3RpJQf1u0xV0UP+4NRb724Su+1iQ71d++hKVMbYnr7X+i0NIVBCEGbX DogRz4mevsTG34AYGIrLgkaLVoit1cMVXVk0pfaJWEwCrpDrWRWtOO4F946hikUu2toQ ukjQ== MIME-Version: 1.0 X-Received: by 10.182.122.200 with SMTP id lu8mr558387obb.96.1384522150635; Fri, 15 Nov 2013 05:29:10 -0800 (PST) Received: by 10.76.99.210 with HTTP; Fri, 15 Nov 2013 05:29:10 -0800 (PST) In-Reply-To: <20131115081211.GP56153@ithaqua.etoilebsd.net> References: <20131115081211.GP56153@ithaqua.etoilebsd.net> Date: Fri, 15 Nov 2013 08:29:10 -0500 Message-ID: Subject: Re: pkg install on CURRENT ? From: Outback Dingo To: Baptiste Daroussin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 13:29:11 -0000 On Fri, Nov 15, 2013 at 3:12 AM, Baptiste Daroussin wrote: > On Thu, Nov 14, 2013 at 10:13:58PM -0500, Outback Dingo wrote: > > anyway to resolve this ??? id like to pkg install a few things or is my > > only option ports > > > > Checking integrity... done > > [1/16] Installing expat-2.0.1_2...pkg: wrong architecture: > > freebsd:10:x86:64 instead of freebsd:11:x86:64 > > pkg -vv, uname -a and file /bin/sh please > > regards, > Bapt > Nevermind I got it, needed to modify packagesite: http://pkg.FreeBSD.org/freebsd:11:x86:64/latest From owner-freebsd-current@FreeBSD.ORG Fri Nov 15 15:02:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 163E4E5A for ; Fri, 15 Nov 2013 15:02:18 +0000 (UTC) Received: from mail-ee0-x22b.google.com (mail-ee0-x22b.google.com [IPv6:2a00:1450:4013:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A363E2E6F for ; Fri, 15 Nov 2013 15:02:17 +0000 (UTC) Received: by mail-ee0-f43.google.com with SMTP id c13so481460eek.16 for ; Fri, 15 Nov 2013 07:02:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=kXUaTZL9SO4TO+YUmQ5uGxI5aYkeqf8codmR2+ojXkk=; b=cvCLxKvR28yAVZS7/jFo65QORKevK4LH2SzTSRxHPWafeqav/QnPN0aiS9CqP2Lx3W QEZfGXDf31HQO/4MR98w3N7vgFK6yxIABN2irSXQGy5auTyL0nMftWHwHgsVI2BuyM3D 8+6GRrcQa/VTGDdL3wfBM5Mc5OisVCPX2c/yzKckko03HVXf6q06aEEzVE7I9D70FS0b G498eRSfRfBLpDPU2V3hDjdHvqv0i47mZpXJPfeR3/5AzzR8SYj4GxMLUdCj91UT3CEc ALg3hZIVc3skleibT7gBpNSgjH9d7WQSHgVWrNGm7PNIoVD+HP75nIYBqelECnZJUc31 X9Pw== X-Received: by 10.15.50.195 with SMTP id l43mr3955798eew.30.1384527732855; Fri, 15 Nov 2013 07:02:12 -0800 (PST) Received: from laptop.minsk.domain ([178.125.203.241]) by mx.google.com with ESMTPSA id k7sm7142071eeg.13.2013.11.15.07.02.12 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Fri, 15 Nov 2013 07:02:12 -0800 (PST) Date: Fri, 15 Nov 2013 18:02:39 +0300 From: "Sergey V. Dyatko" To: freebsd-current@freebsd.org Subject: Re: pkg install on CURRENT ? Message-ID: <20131115180239.05e3575e@laptop.minsk.domain> In-Reply-To: References: <20131115081211.GP56153@ithaqua.etoilebsd.net> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 15:02:18 -0000 On Fri, 15 Nov 2013 08:29:10 -0500 Outback Dingo wrote: > On Fri, Nov 15, 2013 at 3:12 AM, Baptiste Daroussin > wrote: > > > On Thu, Nov 14, 2013 at 10:13:58PM -0500, Outback Dingo wrote: > > > anyway to resolve this ??? id like to pkg install a few things or > > > is my only option ports > > > > > > Checking integrity... done > > > [1/16] Installing expat-2.0.1_2...pkg: wrong architecture: > > > freebsd:10:x86:64 instead of freebsd:11:x86:64 > > > > pkg -vv, uname -a and file /bin/sh please > > > > regards, > > Bapt > > > > > Nevermind I got it, needed to modify packagesite: > http://pkg.FreeBSD.org/freebsd:11:x86:64/latest http://pkg.freebsd.org/${ABI}/latest -- wbr, tiger From owner-freebsd-current@FreeBSD.ORG Fri Nov 15 15:36:34 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 639D32B9 for ; Fri, 15 Nov 2013 15:36:34 +0000 (UTC) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 381CC213E for ; Fri, 15 Nov 2013 15:36:33 +0000 (UTC) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 7AEC02089D for ; Fri, 15 Nov 2013 10:36:31 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute5.internal (MEProxy); Fri, 15 Nov 2013 10:36:31 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=8Cs43nWT3ZzFaNnCb6WaySliAAg=; b=prk M9g51hSsMu4mgJw2M/mBJzJpsGtjHcTtomq1QUyN3gzY8cvZXJjrrssgS1jID50U d11nNj7btjaCs89NZF7mf+5GV6IIg5Q4PbTQQrpDwegUre1eNnvDFbgSINlZORh6 ICZSp12d2jKfqRWX90ki6cl/TZnYALO6vQGZHlQI= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 5A7FB103A66; Fri, 15 Nov 2013 10:36:31 -0500 (EST) Message-Id: <1384529791.7937.47924713.3321BFEF@webmail.messagingengine.com> X-Sasl-Enc: 7M4Me4UeU7kzOBKjub1IeC1aMOlmzIGWtZzTjZH0QkaX 1384529791 From: Mark Felder To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-d4893488 In-Reply-To: <5285E827.1090501@freebsd.org> References: <20131114173423.GA21761@blazingdot.com> <59A9B68B-4134-4217-83F3-B99759174EFE@fisglobal.com> <5285148E.6020903@allanjude.com> <3D3332FA-0ABF-4573-8E65-4E7FBB37100B@fisglobal.com> <1384462198.13183.47596065.6F8E7BCD@webmail.messagingengine.com> <55232624-3B76-4781-91E0-0C2A6260144D@fisglobal.com> <5285E827.1090501@freebsd.org> Subject: Re: Defaults in 10.0 ZFS through bsdinstall Date: Fri, 15 Nov 2013 09:36:31 -0600 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 15:36:34 -0000 On Fri, Nov 15, 2013, at 3:23, Stefan Esser wrote: > Am 14.11.2013 22:02, schrieb Teske, Devin: > > On Nov 14, 2013, at 12:49 PM, Mark Felder wrote: > >> We don't even do installs on UFS with atime disabled by default in fstab > >> so why should we so suddenly change course for ZFS? > >> > > > > You've made a good point. > > There is major difference between UFS and ZFS: UFS allows in-place > updates of i-node fields (like atime), while ZFS uses COW for all > data, file contents and meta-data like the i-nodes. > > With atime ON on UFS you'll see a small number of writes on > file-systems that are only read - we are used to accept that. > > On ZFS every update of atime causes a write of the meta-data to > a free location on disk, then updates of all data structures > that reference that meta-data up to the root of the tree (the > uberblock). An update of a few bytes turns out to write tens > of KB for each atime update (within the TXG sync interval, which > defaults to 5 seconds on FreeBSD). If you create snapshots, then > each snapshot will contain a copy of the metadata that was valid > at the time of the snapshot (well, that's not so different from > the situation with UFS snapshots, just that the data structures > are much more complex and larger in the ZFS case). Due to the > ease and speed of snapshot creation with ZFS there probably are > a magnitude or more snapshots on a typical ZFS system than on > one using UFS (I currently have a few hundred and have turned off > periodic snapshot generation on many unimportant file-systems, > already). > > I really hope that we get relatime (with minor variations that > were discussed a few months ago) and that we make it the default > in some future release ... > Thanks for this in-depth explanation. I wasn't aware that atime was quite so expensive on ZFS. From owner-freebsd-current@FreeBSD.ORG Fri Nov 15 16:10:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D09D4446; Fri, 15 Nov 2013 16:10:02 +0000 (UTC) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 942F92387; Fri, 15 Nov 2013 16:09:58 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.93,708,1378857600"; d="scan'208,223";a="74933389" Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP; 15 Nov 2013 16:09:49 +0000 Received: from [IPv6:::1] (10.80.16.47) by smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id 14.2.342.4; Fri, 15 Nov 2013 11:09:47 -0500 Message-ID: <52864749.1020308@citrix.com> Date: Fri, 15 Nov 2013 17:09:45 +0100 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "freebsd-xen@freebsd.org" Subject: Re: FreeBSD PVH guest support References: <526E6807.9030005@citrix.com> <527BD793.8010606@citrix.com> <527E24D8.4010403@citrix.com> In-Reply-To: <527E24D8.4010403@citrix.com> Content-Type: multipart/mixed; boundary="------------040406040602030408060208" X-DLP: MIA2 Cc: peter@FreeBSD.org, alc@FreeBSD.org, xen-devel , freebsd-current@freebsd.org, Konstantin Belousov , "Justin T. Gibbs" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 16:10:02 -0000 --------------040406040602030408060208 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit On 09/11/13 13:04, Roger Pau Monné wrote: > On 07/11/13 19:10, Roger Pau Monné wrote: >> On 28/10/13 14:35, Roger Pau Monné wrote: >>> Hello, >>> >>> The Xen community is working on a new virtualization mode (or maybe I >>> should say an extension of HVM) to be able to run PV guests inside HVM >>> containers without requiring a device-model (Qemu). One of the >>> advantages of this new virtualization mode is that now it is much more >>> easier to port guests to run under it (as compared to pure PV guests). >>> >>> Given that FreeBSD already supports PVHVM, adding PVH support is quite >>> easy, we only need some glue for the PV entry point and then support >>> for diverging some early init functions (like fetching the e820 map or >>> starting the APs). >>> >>> The attached patch contains all this changes, and allows a SMP FreeBSD >>> guest to fully boot (and AFAIK work) under this new PVH mode. The patch >>> can also be found on my git repo: >>> >>> git://xenbits.xen.org/people/royger/freebsd.git pvh_v2 >>> >>> The patch touches quite a lot of the early init, so I've Cced the >>> persons that maintain those areas, so they can review it. >>> >>> In order to test it, and since the PVH changes are not yet merged into >>> upstream Xen, the use of a patched Xen is necessary. I've collected the >>> patches for PVH guest support from George Dunlap (v13) and fixed some >>> bugs on top of them, the tree can be found at: >>> >>> git://xenbits.xen.org/people/royger/xen.git fix_pvh PVH DomU support has been committed to upstream Xen, and I've updated the patch to match the interface. The main change is that cr4 is not set to ctrlreg[4] by Xen, and the AP is launched without the PSE flag set, so we have to set it on init_secondary. Patch can be found here: http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=commit;h=8db6aa8cbc5b7a2a88f4e4fb51f99a166c128cec And attached on this email. Thanks for the review, Roger. --------------040406040602030408060208 Content-Type: text/plain; charset="UTF-8"; x-mac-type=0; x-mac-creator=0; name="0001-Xen-x86-DomU-PVH-support.patch" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="0001-Xen-x86-DomU-PVH-support.patch" >From c45d62c5c78aca948f652397cb70dd5720f46583 Mon Sep 17 00:00:00 2001 From: Roger Pau Monne Date: Thu, 7 Nov 2013 17:07:50 +0100 Subject: [PATCH] Xen x86 DomU PVH support PVH mode is basically a PV guest inside an HVM container, and shares a great amount of code with PVHVM. The main difference is the way the guest is started, PVH uses the PV start sequence, jumping directly into the kernel entry point in long mode and with page tables set. The main work of this patch consists in setting the environment as similar as possible to what native FreeBSD expects, and then adding hooks to the PV ops when necessary. sys/amd64/amd64/locore.S: * Add PV entry point, hypervisor_page and the necessary elfnotes. sys/amd64/amd64/machdep.c: * Add hooks to replace bare metal operations that should use a PV helper, this includes: - Preload metadata - i8254_init and i8254_delay - Fetching the e820 memory map - Reserve of the MP bootstrap region * Create a DELAY function that uses the PV hooks. * Introduce a new hammer_time_xen that sets the necessary stuff when running in PVH mode. sys/amd64/amd64/mp_machdep.c: * Introduce a hook to replace start_all_aps. * Introduce a lapic_disabled variable to prevent polluting the code with xen specific gates. sys/amd64/include/asmacros.h: * Copy the ELFNOTE macro from the i386 Xen PV port. sys/amd64/include/clock.h: sys/i386/include/clock.h: * Prototypes for the xen early delay initialization and usage. sys/amd64/include/cpu.h: * Introduce a new cpu hook to init APs. sys/amd64/include/sysarch.h: * Declare the init_ops structure. sys/amd64/include/xen/hypercall.h: sys/i386/include/xen/hypercall.h * Switch to the PV style hypercall mechanism for HVM also. sys/conf/files: * Make the PV console available on XENHVM also. sys/conf/files.amd64: * Include the new files for the PVH port. sys/dev/xen/console/console.c: sys/dev/xen/console/xencons_ring.c: * Remove the identify method and instead add the device from nexus_xen. * Use HYPERVISOR_start_info instead of xen_start_info. * Use HYPERVISOR_event_channel_op to kick the event channel before xen interrupts are setup. sys/dev/xen/control/control.c: * Use the PV shutdown on PVH. sys/dev/xen/timer/timer.c: * Pass a vcpu_info to xen_fetch_vcpu_time, this allows using this function at very early init, before per-cpu vcpu_info is set. * Remove critical_{enter/exit} from xen_fetch_vcpu_time so it can be used at early boot, instead place them on the callers. * Introduce two new functions, xen_delay_init and xen_delay that can be used at early boot to implement the generic DELAY function. * Remove the identify method that used to add the device, now it is manually added from either xenpci (HVM) or nexus_xen (PV). sys/i386/i386/locore.s: * Reserve space for the hypercall page. sys/i386/i386/machdep.c: * Create a generic DELAY function. sys/i386/xen/xen_machdep.c: * Set HYPERVISOR_start_info. sys/x86/isa/clock.c: * Rename the generic DELAY function to i8254_delay. sys/x86/x86/delay.c: * Put generic delay helpers here, get_tsc and delay_tc. sys/x86/x86/local_apic.c: * Prevent the local apic from attaching when running on PVH mode. sys/x86/xen/hvm.c: * Set the start_all_aps hook. * Fix the setting of the hypercall page now that we are using the same mechanism as the PV port. * Initialize Xen CPU hooks for the PVH port. * Introduce the xen_early_printf debug function, which prints directly to the hypervisor console. * Initialize APs before SI_SUB_SMP (SI_SUB_SMP-1). sys/x86/xen/mptable.c: * Create a dummy PV CPU enumerator for the PVH port. sys/x86/xen/pv.c: * Implement the PV functions for the early boot hooks, parse_preload_data and fetch_e820_map. * Implement the PV function for the start_all_aps hook. sys/x86/xen/pvcpu.c: * Dummy Xen PV CPU device, that we use to set the per-cpu pc_device. sys/xen/gnttab.c: * Allocate resume_frames for the PVH port. sys/xen/pv.h: * Header that exports the specific PV functions. sys/xen/xen-os.h: * Declare prototypes for the newly added functions. sys/xen/xenstore/xenstore.c: * Make the xenstore driver hang from both xenpci and the nexus when running XENHVM, this is because we don't have a xenpci device on the PVH port. * Remove the identify routine that added the device, instead add it from either xenpci (HVM) or nexus_xen (PV). sys/dev/xen/xenpci/xenpci.c: * Add the xenstore and xen_et devices on succesful attach. sys/i386/xen/mp_machdep.c: * Modify cpu_initialize_context to match the changes in the Xen interface. sys/x86/xen/xen_nexus.c: * Create a specific nexus for Xen PV guests that takes care of adding the top level Xen PV devices. --- sys/amd64/amd64/locore.S | 53 ++++++++ sys/amd64/amd64/machdep.c | 179 ++++++++++++++++++++++---- sys/amd64/amd64/mp_machdep.c | 33 +++-- sys/amd64/include/asmacros.h | 26 ++++ sys/amd64/include/clock.h | 6 + sys/amd64/include/cpu.h | 1 + sys/amd64/include/sysarch.h | 19 +++ sys/amd64/include/xen/hypercall.h | 7 - sys/conf/files | 4 +- sys/conf/files.amd64 | 5 + sys/conf/files.i386 | 2 + sys/dev/xen/console/console.c | 29 ++--- sys/dev/xen/console/xencons_ring.c | 15 ++- sys/dev/xen/control/control.c | 37 +++--- sys/dev/xen/timer/timer.c | 73 ++++++++---- sys/dev/xen/xenpci/xenpci.c | 8 ++ sys/i386/i386/locore.s | 9 ++ sys/i386/i386/machdep.c | 11 ++ sys/i386/include/clock.h | 6 + sys/i386/include/xen/hypercall.h | 7 - sys/i386/xen/mp_machdep.c | 6 +- sys/i386/xen/xen_machdep.c | 4 +- sys/x86/isa/clock.c | 53 +-------- sys/x86/isa/isa.c | 3 + sys/x86/x86/delay.c | 95 ++++++++++++++ sys/x86/x86/local_apic.c | 8 +- sys/x86/xen/hvm.c | 98 +++++++++++---- sys/x86/xen/mptable.c | 136 ++++++++++++++++++++ sys/x86/xen/pv.c | 246 ++++++++++++++++++++++++++++++++++++ sys/x86/xen/pvcpu.c | 77 +++++++++++ sys/x86/xen/xen_nexus.c | 99 +++++++++++++++ sys/xen/gnttab.c | 21 +++- sys/xen/pv.h | 29 +++++ sys/xen/xen-os.h | 8 ++ sys/xen/xenstore/xenstore.c | 24 ++-- 35 files changed, 1219 insertions(+), 218 deletions(-) create mode 100644 sys/x86/x86/delay.c create mode 100644 sys/x86/xen/mptable.c create mode 100644 sys/x86/xen/pv.c create mode 100644 sys/x86/xen/pvcpu.c create mode 100644 sys/x86/xen/xen_nexus.c create mode 100644 sys/xen/pv.h diff --git a/sys/amd64/amd64/locore.S b/sys/amd64/amd64/locore.S index 55cda3a..e04cc48 100644 --- a/sys/amd64/amd64/locore.S +++ b/sys/amd64/amd64/locore.S @@ -31,6 +31,12 @@ #include #include +#ifdef XENHVM +#include +#define __ASSEMBLY__ +#include +#endif + #include "assym.s" /* @@ -86,3 +92,50 @@ NON_GPROF_ENTRY(btext) ALIGN_DATA /* just to be sure */ .space 0x1000 /* space for bootstack - temporary stack */ bootstack: + +#ifdef XENHVM +/* Xen */ +.section __xen_guest + ELFNOTE(Xen, XEN_ELFNOTE_GUEST_OS, .asciz, "FreeBSD") + ELFNOTE(Xen, XEN_ELFNOTE_GUEST_VERSION, .asciz, "HEAD") + ELFNOTE(Xen, XEN_ELFNOTE_XEN_VERSION, .asciz, "xen-3.0") + ELFNOTE(Xen, XEN_ELFNOTE_VIRT_BASE, .quad, KERNBASE) + ELFNOTE(Xen, XEN_ELFNOTE_PADDR_OFFSET, .quad, KERNBASE) /* Xen honours elf->p_paddr; compensate for this */ + ELFNOTE(Xen, XEN_ELFNOTE_ENTRY, .quad, xen_start) + ELFNOTE(Xen, XEN_ELFNOTE_HYPERCALL_PAGE, .quad, hypercall_page) + ELFNOTE(Xen, XEN_ELFNOTE_HV_START_LOW, .quad, HYPERVISOR_VIRT_START) + ELFNOTE(Xen, XEN_ELFNOTE_FEATURES, .asciz, "writable_descriptor_tables|auto_translated_physmap|supervisor_mode_kernel|hvm_callback_vector") + ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE, .asciz, "yes") + ELFNOTE(Xen, XEN_ELFNOTE_L1_MFN_VALID, .long, PG_V, PG_V) + ELFNOTE(Xen, XEN_ELFNOTE_LOADER, .asciz, "generic") + ELFNOTE(Xen, XEN_ELFNOTE_SUSPEND_CANCEL, .long, 0) + ELFNOTE(Xen, XEN_ELFNOTE_BSD_SYMTAB, .asciz, "yes") + + .text +.p2align PAGE_SHIFT, 0x90 /* Hypercall_page needs to be PAGE aligned */ + +NON_GPROF_ENTRY(hypercall_page) + .skip 0x1000, 0x90 /* Fill with "nop"s */ + +NON_GPROF_ENTRY(xen_start) + /* Don't trust what the loader gives for rflags. */ + pushq $PSL_KERNEL + popfq + + /* Parameters for the xen init function */ + movq %rsi, %rdi /* shared_info (arg 1) */ + movq %rsp, %rsi /* xenstack (arg 2) */ + + /* Use our own stack */ + movq $bootstack,%rsp + xorl %ebp, %ebp + + /* u_int64_t hammer_time_xen(start_info_t *si, u_int64_t xenstack); */ + call hammer_time_xen + movq %rax, %rsp /* set up kstack for mi_startup() */ + call mi_startup /* autoconfiguration, mountroot etc */ + + /* NOTREACHED */ +0: hlt + jmp 0b +#endif diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c index 2b2e47f..b649def 100644 --- a/sys/amd64/amd64/machdep.c +++ b/sys/amd64/amd64/machdep.c @@ -127,6 +127,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #ifdef PERFMON #include #endif @@ -147,10 +148,20 @@ __FBSDID("$FreeBSD$"); #include #include +#ifdef XENHVM +/* Xen */ +#include +#include +#include +#endif + /* Sanity check for __curthread() */ CTASSERT(offsetof(struct pcpu, pc_curthread) == 0); extern u_int64_t hammer_time(u_int64_t, u_int64_t); +#ifdef XENHVM +extern u_int64_t hammer_time_xen(start_info_t *, u_int64_t); +#endif extern void printcpuinfo(void); /* XXX header file */ extern void identify_cpu(void); @@ -166,6 +177,23 @@ static int set_fpcontext(struct thread *td, const mcontext_t *mcp, char *xfpustate, size_t xfpustate_len); SYSINIT(cpu, SI_SUB_CPU, SI_ORDER_FIRST, cpu_startup, NULL); +/* Preload data parse function */ +static caddr_t native_parse_preload_data(u_int64_t); + +/* Native function to fetch the e820 map */ +static void native_fetch_e820_map(caddr_t, struct bios_smap **, u_int32_t *); + +/* Default init_ops implementation. */ +struct init_ops init_ops = { + .parse_preload_data = native_parse_preload_data, + .early_delay_init = i8254_init, + .early_delay = i8254_delay, + .fetch_e820_map = native_fetch_e820_map, +#ifdef SMP + .mp_bootaddress = mp_bootaddress, +#endif +}; + /* * The file "conf/ldscript.amd64" defines the symbol "kernphys". Its value is * the physical address at which the kernel is loaded. @@ -216,6 +244,15 @@ struct mem_range_softc mem_range_softc; struct mtx dt_lock; /* lock for GDT and LDT */ +void +DELAY(int n) +{ + if (delay_tc(n)) + return; + + init_ops.early_delay(n); +} + static void cpu_startup(dummy) void *dummy; @@ -1408,6 +1445,24 @@ add_smap_entry(struct bios_smap *smap, vm_paddr_t *physmap, int *physmap_idxp) return (1); } +static void +native_fetch_e820_map(caddr_t kmdp, struct bios_smap **smap, u_int32_t *size) +{ + /* + * get memory map from INT 15:E820, kindly supplied by the + * loader. + * + * subr_module.c says: + * "Consumer may safely assume that size value precedes data." + * ie: an int32_t immediately precedes smap. + */ + *smap = (struct bios_smap *)preload_search_info(kmdp, + MODINFO_METADATA | MODINFOMD_SMAP); + if (*smap == NULL) + panic("No BIOS smap info from loader!"); + *size = *((u_int32_t *)*smap - 1); +} + /* * Populate the (physmap) array with base/bound pairs describing the * available physical memory in the system, then test this memory and @@ -1433,19 +1488,8 @@ getmemsize(caddr_t kmdp, u_int64_t first) basemem = 0; physmap_idx = 0; - /* - * get memory map from INT 15:E820, kindly supplied by the loader. - * - * subr_module.c says: - * "Consumer may safely assume that size value precedes data." - * ie: an int32_t immediately precedes smap. - */ - smapbase = (struct bios_smap *)preload_search_info(kmdp, - MODINFO_METADATA | MODINFOMD_SMAP); - if (smapbase == NULL) - panic("No BIOS smap info from loader!"); + init_ops.fetch_e820_map(kmdp, &smapbase, &smapsize); - smapsize = *((u_int32_t *)smapbase - 1); smapend = (struct bios_smap *)((uintptr_t)smapbase + smapsize); for (smap = smapbase; smap < smapend; smap++) @@ -1467,7 +1511,8 @@ getmemsize(caddr_t kmdp, u_int64_t first) #ifdef SMP /* make hole for AP bootstrap code */ - physmap[1] = mp_bootaddress(physmap[1] / 1024); + if (init_ops.mp_bootaddress) + physmap[1] = init_ops.mp_bootaddress(physmap[1] / 1024); #endif /* @@ -1681,6 +1726,98 @@ do_next: msgbufp = (struct msgbuf *)PHYS_TO_DMAP(phys_avail[pa_indx]); } +static caddr_t +native_parse_preload_data(u_int64_t modulep) +{ + caddr_t kmdp; + + preload_metadata = (caddr_t)(uintptr_t)(modulep + KERNBASE); + preload_bootstrap_relocate(KERNBASE); + kmdp = preload_search_by_type("elf kernel"); + if (kmdp == NULL) + kmdp = preload_search_by_type("elf64 kernel"); + boothowto = MD_FETCH(kmdp, MODINFOMD_HOWTO, int); + kern_envp = MD_FETCH(kmdp, MODINFOMD_ENVP, char *) + KERNBASE; +#ifdef DDB + ksym_start = MD_FETCH(kmdp, MODINFOMD_SSYM, uintptr_t); + ksym_end = MD_FETCH(kmdp, MODINFOMD_ESYM, uintptr_t); +#endif + + return (kmdp); +} + +#ifdef XENHVM +/* + * First function called by the Xen PVH boot sequence. + * + * Set some Xen global variables and prepare the environment so it is + * as similar as possible to what native FreeBSD init function expects. + */ +u_int64_t +hammer_time_xen(start_info_t *si, u_int64_t xenstack) +{ + u_int64_t physfree; + u_int64_t *PT4 = (u_int64_t *)xenstack; + u_int64_t *PT3 = (u_int64_t *)(xenstack + PAGE_SIZE); + u_int64_t *PT2 = (u_int64_t *)(xenstack + 2 * PAGE_SIZE); + int i; + + KASSERT((si != NULL && xenstack != 0), + ("invalid start_info or xenstack")); + + xen_early_printf("FreeBSD PVH running on %s\n", si->magic); + + /* We use 3 pages of xen stack for the boot pagetables */ + physfree = xenstack + 3 * PAGE_SIZE - KERNBASE; + + /* Setup Xen global variables */ + HYPERVISOR_start_info = si; + HYPERVISOR_shared_info = + (shared_info_t *)(si->shared_info + KERNBASE); + + /* + * Setup some misc global variables for Xen devices + * + * XXX: devices that need this specific variables should + * be rewritten to fetch this info by themselves from the + * start_info page. + */ + console_page = + (char *)(ptoa(si->console.domU.mfn) + KERNBASE); + xen_store = (struct xenstore_domain_interface *) + (ptoa(si->store_mfn) + KERNBASE); + + xen_domain_type = XEN_PV_DOMAIN; + vm_guest = VM_GUEST_XEN; + + /* + * Use the stack Xen gives us to build the page tables + * as native FreeBSD expects to find them (created + * by the boot trampoline). + */ + for (i = 0; i < 512; i++) { + /* Each slot of the level 4 pages points to the same level 3 page */ + PT4[i] = ((u_int64_t)&PT3[0]) - KERNBASE; + PT4[i] |= PG_V | PG_RW | PG_U; + + /* Each slot of the level 3 pages points to the same level 2 page */ + PT3[i] = ((u_int64_t)&PT2[0]) - KERNBASE; + PT3[i] |= PG_V | PG_RW | PG_U; + + /* The level 2 page slots are mapped with 2MB pages for 1GB. */ + PT2[i] = i * (2 * 1024 * 1024); + PT2[i] |= PG_V | PG_RW | PG_PS | PG_U; + } + load_cr3(((u_int64_t)&PT4[0]) - KERNBASE); + + /* Set the hooks for early functions that diverge from bare metal */ + xen_pv_set_init_ops(); + + /* Now we can jump into the native init function */ + return hammer_time(0, physfree); +} +#endif + u_int64_t hammer_time(u_int64_t modulep, u_int64_t physfree) { @@ -1705,17 +1842,7 @@ hammer_time(u_int64_t modulep, u_int64_t physfree) */ proc_linkup0(&proc0, &thread0); - preload_metadata = (caddr_t)(uintptr_t)(modulep + KERNBASE); - preload_bootstrap_relocate(KERNBASE); - kmdp = preload_search_by_type("elf kernel"); - if (kmdp == NULL) - kmdp = preload_search_by_type("elf64 kernel"); - boothowto = MD_FETCH(kmdp, MODINFOMD_HOWTO, int); - kern_envp = MD_FETCH(kmdp, MODINFOMD_ENVP, char *) + KERNBASE; -#ifdef DDB - ksym_start = MD_FETCH(kmdp, MODINFOMD_SSYM, uintptr_t); - ksym_end = MD_FETCH(kmdp, MODINFOMD_ESYM, uintptr_t); -#endif + kmdp = init_ops.parse_preload_data(modulep); /* Init basic tunables, hz etc */ init_param1(); @@ -1799,10 +1926,10 @@ hammer_time(u_int64_t modulep, u_int64_t physfree) lidt(&r_idt); /* - * Initialize the i8254 before the console so that console + * Initialize the early delay before the console so that console * initialization can use DELAY(). */ - i8254_init(); + init_ops.early_delay_init(); /* * Initialize the console before we print anything out. diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c index 4ef4b3d..a751055 100644 --- a/sys/amd64/amd64/mp_machdep.c +++ b/sys/amd64/amd64/mp_machdep.c @@ -90,7 +90,8 @@ extern struct pcpu __pcpu[]; /* AP uses this during bootstrap. Do not staticize. */ char *bootSTK; -static int bootAP; +int bootAP; +bool lapic_disabled = false; /* Free these after use */ void *bootstacks[MAXCPU]; @@ -122,9 +123,12 @@ u_long *ipi_rendezvous_counts[MAXCPU]; static u_long *ipi_hardclock_counts[MAXCPU]; #endif +int native_start_all_aps(void); + /* Default cpu_ops implementation. */ struct cpu_ops cpu_ops = { - .ipi_vectored = lapic_ipi_vectored + .ipi_vectored = lapic_ipi_vectored, + .start_all_aps = native_start_all_aps, }; extern inthand_t IDTVEC(fast_syscall), IDTVEC(fast_syscall32); @@ -138,7 +142,7 @@ extern int pmap_pcid_enabled; static volatile cpuset_t ipi_nmi_pending; /* used to hold the AP's until we are ready to release them */ -static struct mtx ap_boot_mtx; +struct mtx ap_boot_mtx; /* Set to 1 once we're ready to let the APs out of the pen. */ static volatile int aps_ready = 0; @@ -165,7 +169,6 @@ static int cpu_cores; /* cores per package */ static void assign_cpu_ids(void); static void set_interrupt_apic_ids(void); -static int start_all_aps(void); static int start_ap(int apic_id); static void release_aps(void *dummy); @@ -569,7 +572,7 @@ cpu_mp_start(void) assign_cpu_ids(); /* Start each Application Processor */ - start_all_aps(); + cpu_ops.start_all_aps(); set_interrupt_apic_ids(); } @@ -707,7 +710,8 @@ init_secondary(void) wrmsr(MSR_SF_MASK, PSL_NT|PSL_T|PSL_I|PSL_C|PSL_D); /* Disable local APIC just to be sure. */ - lapic_disable(); + if (!lapic_disabled) + lapic_disable(); /* signal our startup to the BSP. */ mp_naps++; @@ -733,7 +737,7 @@ init_secondary(void) /* A quick check from sanity claus */ cpuid = PCPU_GET(cpuid); - if (PCPU_GET(apic_id) != lapic_id()) { + if (!lapic_disabled && PCPU_GET(apic_id) != lapic_id()) { printf("SMP: cpuid = %d\n", cpuid); printf("SMP: actual apic_id = %d\n", lapic_id()); printf("SMP: correct apic_id = %d\n", PCPU_GET(apic_id)); @@ -749,7 +753,8 @@ init_secondary(void) mtx_lock_spin(&ap_boot_mtx); /* Init local apic for irq's */ - lapic_setup(1); + if (!lapic_disabled) + lapic_setup(1); /* Set memory range attributes for this CPU to match the BSP */ mem_range_AP_init(); @@ -764,7 +769,7 @@ init_secondary(void) if (cpu_logical > 1 && PCPU_GET(apic_id) % cpu_logical != 0) CPU_SET(cpuid, &logical_cpus_mask); - if (bootverbose) + if (!lapic_disabled && bootverbose) lapic_dump("AP"); if (smp_cpus == mp_ncpus) { @@ -776,9 +781,13 @@ init_secondary(void) /* * Enable global pages TLB extension * This also implicitly flushes the TLB + * + * Also set PSE, because on Xen AP bringup + * it is not set, and it doesn't do any harm + * to set it again here on the bare-metal case. */ - load_cr4(rcr4() | CR4_PGE); + load_cr4(rcr4() | CR4_PGE | CR4_PSE); if (pmap_pcid_enabled) load_cr4(rcr4() | CR4_PCIDE); load_ds(_udatasel); @@ -908,8 +917,8 @@ assign_cpu_ids(void) /* * start each AP in our list */ -static int -start_all_aps(void) +int +native_start_all_aps(void) { vm_offset_t va = boot_address + KERNBASE; u_int64_t *pt4, *pt3, *pt2; diff --git a/sys/amd64/include/asmacros.h b/sys/amd64/include/asmacros.h index 1fb592a..ce8dce4 100644 --- a/sys/amd64/include/asmacros.h +++ b/sys/amd64/include/asmacros.h @@ -201,4 +201,30 @@ #endif /* LOCORE */ +#ifdef __STDC__ +#define ELFNOTE(name, type, desctype, descdata...) \ +.pushsection .note.name ; \ + .align 4 ; \ + .long 2f - 1f /* namesz */ ; \ + .long 4f - 3f /* descsz */ ; \ + .long type ; \ +1:.asciz #name ; \ +2:.align 4 ; \ +3:desctype descdata ; \ +4:.align 4 ; \ +.popsection +#else /* !__STDC__, i.e. -traditional */ +#define ELFNOTE(name, type, desctype, descdata) \ +.pushsection .note.name ; \ + .align 4 ; \ + .long 2f - 1f /* namesz */ ; \ + .long 4f - 3f /* descsz */ ; \ + .long type ; \ +1:.asciz "name" ; \ +2:.align 4 ; \ +3:desctype descdata ; \ +4:.align 4 ; \ +.popsection +#endif /* __STDC__ */ + #endif /* !_MACHINE_ASMACROS_H_ */ diff --git a/sys/amd64/include/clock.h b/sys/amd64/include/clock.h index d7f7d82..e7817ab 100644 --- a/sys/amd64/include/clock.h +++ b/sys/amd64/include/clock.h @@ -25,6 +25,12 @@ extern int smp_tsc; #endif void i8254_init(void); +void i8254_delay(int); +#ifdef XENHVM +void xen_delay_init(void); +void xen_delay(int); +#endif +int delay_tc(int); /* * Driver to clock driver interface. diff --git a/sys/amd64/include/cpu.h b/sys/amd64/include/cpu.h index 3d9ff531..ed9f1db 100644 --- a/sys/amd64/include/cpu.h +++ b/sys/amd64/include/cpu.h @@ -64,6 +64,7 @@ struct cpu_ops { void (*cpu_init)(void); void (*cpu_resume)(void); void (*ipi_vectored)(u_int, int); + int (*start_all_aps)(void); }; extern struct cpu_ops cpu_ops; diff --git a/sys/amd64/include/sysarch.h b/sys/amd64/include/sysarch.h index cd380d4..27fd3ba 100644 --- a/sys/amd64/include/sysarch.h +++ b/sys/amd64/include/sysarch.h @@ -4,3 +4,22 @@ /* $FreeBSD$ */ #include + +#include +/* + * Struct containing pointers to init functions whose + * implementation is run time selectable. Selection can be made, + * for example, based on detection of a BIOS variant or + * hypervisor environment. + */ +struct init_ops { + caddr_t (*parse_preload_data)(u_int64_t); + void (*early_delay_init)(void); + void (*early_delay)(int); + void (*fetch_e820_map)(caddr_t, struct bios_smap **, u_int32_t *); +#ifdef SMP + u_int (*mp_bootaddress)(u_int); +#endif +}; + +extern struct init_ops init_ops; diff --git a/sys/amd64/include/xen/hypercall.h b/sys/amd64/include/xen/hypercall.h index a1b2a5c..499fb4d 100644 --- a/sys/amd64/include/xen/hypercall.h +++ b/sys/amd64/include/xen/hypercall.h @@ -51,15 +51,8 @@ #define CONFIG_XEN_COMPAT 0x030002 #define __must_check -#ifdef XEN #define HYPERCALL_STR(name) \ "call hypercall_page + ("STR(__HYPERVISOR_##name)" * 32)" -#else -#define HYPERCALL_STR(name) \ - "mov $("STR(__HYPERVISOR_##name)" * 32),%%eax; "\ - "add hypercall_stubs(%%rip),%%rax; " \ - "call *%%rax" -#endif #define _hypercall0(type, name) \ ({ \ diff --git a/sys/conf/files b/sys/conf/files index 3c20141..e711ddf 100644 --- a/sys/conf/files +++ b/sys/conf/files @@ -2512,8 +2512,8 @@ dev/xe/if_xe_pccard.c optional xe pccard dev/xen/balloon/balloon.c optional xen | xenhvm dev/xen/blkfront/blkfront.c optional xen | xenhvm dev/xen/blkback/blkback.c optional xen | xenhvm -dev/xen/console/console.c optional xen -dev/xen/console/xencons_ring.c optional xen +dev/xen/console/console.c optional xen | xenhvm +dev/xen/console/xencons_ring.c optional xen | xenhvm dev/xen/control/control.c optional xen | xenhvm dev/xen/netback/netback.c optional xen | xenhvm dev/xen/netfront/netfront.c optional xen | xenhvm diff --git a/sys/conf/files.amd64 b/sys/conf/files.amd64 index 33c4297..d736d84 100644 --- a/sys/conf/files.amd64 +++ b/sys/conf/files.amd64 @@ -564,5 +564,10 @@ x86/x86/mptable_pci.c optional mptable pci x86/x86/msi.c optional pci x86/x86/nexus.c standard x86/x86/tsc.c standard +x86/x86/delay.c standard x86/xen/hvm.c optional xenhvm x86/xen/xen_intr.c optional xen | xenhvm +x86/xen/mptable.c optional xenhvm +x86/xen/pvcpu.c optional xenhvm +x86/xen/pv.c optional xenhvm +x86/xen/xen_nexus.c optional xenhvm diff --git a/sys/conf/files.i386 b/sys/conf/files.i386 index 696d4e7..10a4da8 100644 --- a/sys/conf/files.i386 +++ b/sys/conf/files.i386 @@ -587,5 +587,7 @@ x86/x86/mptable_pci.c optional apic native pci x86/x86/msi.c optional apic pci x86/x86/nexus.c standard x86/x86/tsc.c standard +x86/x86/delay.c standard x86/xen/hvm.c optional xenhvm x86/xen/xen_intr.c optional xen | xenhvm +x86/xen/xen_nexus.c optional xen | xenhvm diff --git a/sys/dev/xen/console/console.c b/sys/dev/xen/console/console.c index 23eaee2..33d7cce 100644 --- a/sys/dev/xen/console/console.c +++ b/sys/dev/xen/console/console.c @@ -69,11 +69,14 @@ struct mtx cn_mtx; static char wbuf[WBUF_SIZE]; static char rbuf[RBUF_SIZE]; static int rc, rp; -static unsigned int cnsl_evt_reg; +unsigned int cnsl_evt_reg; static unsigned int wc, wp; /* write_cons, write_prod */ xen_intr_handle_t xen_intr_handle; device_t xencons_dev; +/* Virt address of the shared console page */ +char *console_page; + #ifdef KDB static int xc_altbrk; #endif @@ -113,6 +116,9 @@ static struct ttydevsw xc_ttydevsw = { static void xc_cnprobe(struct consdev *cp) { + if (!xen_pv_domain()) + return; + cp->cn_pri = CN_REMOTE; sprintf(cp->cn_name, "%s0", driver_name); } @@ -175,7 +181,7 @@ static void xc_cnputc(struct consdev *dev, int c) { - if (xen_start_info->flags & SIF_INITDOMAIN) + if (HYPERVISOR_start_info->flags & SIF_INITDOMAIN) xc_cnputc_dom0(dev, c); else xc_cnputc_domu(dev, c); @@ -206,22 +212,12 @@ xcons_putc(int c) xcons_force_flush(); #endif } - if (cnsl_evt_reg) - __xencons_tx_flush(); + __xencons_tx_flush(); /* inform start path that we're pretty full */ return ((wp - wc) >= WBUF_SIZE - 100) ? TRUE : FALSE; } -static void -xc_identify(driver_t *driver, device_t parent) -{ - device_t child; - child = BUS_ADD_CHILD(parent, 0, driver_name, 0); - device_set_driver(child, driver); - device_set_desc(child, "Xen Console"); -} - static int xc_probe(device_t dev) { @@ -245,7 +241,7 @@ xc_attach(device_t dev) cnsl_evt_reg = 1; callout_reset(&xc_callout, XC_POLLTIME, xc_timeout, xccons); - if (xen_start_info->flags & SIF_INITDOMAIN) { + if (HYPERVISOR_start_info->flags & SIF_INITDOMAIN) { error = xen_intr_bind_virq(dev, VIRQ_CONSOLE, 0, NULL, xencons_priv_interrupt, NULL, INTR_TYPE_TTY, &xen_intr_handle); @@ -309,7 +305,7 @@ __xencons_tx_flush(void) sz = wp - wc; if (sz > (WBUF_SIZE - WBUF_MASK(wc))) sz = WBUF_SIZE - WBUF_MASK(wc); - if (xen_start_info->flags & SIF_INITDOMAIN) { + if (HYPERVISOR_start_info->flags & SIF_INITDOMAIN) { HYPERVISOR_console_io(CONSOLEIO_write, sz, &wbuf[WBUF_MASK(wc)]); wc += sz; } else { @@ -405,7 +401,6 @@ xc_timeout(void *v) } static device_method_t xc_methods[] = { - DEVMETHOD(device_identify, xc_identify), DEVMETHOD(device_probe, xc_probe), DEVMETHOD(device_attach, xc_attach), @@ -424,7 +419,7 @@ xcons_force_flush(void) { int sz; - if (xen_start_info->flags & SIF_INITDOMAIN) + if (HYPERVISOR_start_info->flags & SIF_INITDOMAIN) return; /* Spin until console data is flushed through to the domain controller. */ diff --git a/sys/dev/xen/console/xencons_ring.c b/sys/dev/xen/console/xencons_ring.c index 3701551..3046498 100644 --- a/sys/dev/xen/console/xencons_ring.c +++ b/sys/dev/xen/console/xencons_ring.c @@ -32,9 +32,9 @@ __FBSDID("$FreeBSD$"); #define console_evtchn console.domU.evtchn xen_intr_handle_t console_handle; -extern char *console_page; extern struct mtx cn_mtx; extern device_t xencons_dev; +extern int cnsl_evt_reg; static inline struct xencons_interface * xencons_interface(void) @@ -60,6 +60,7 @@ xencons_ring_send(const char *data, unsigned len) struct xencons_interface *intf; XENCONS_RING_IDX cons, prod; int sent; + struct evtchn_send send = { .port = HYPERVISOR_start_info->console.domU.evtchn }; intf = xencons_interface(); cons = intf->out_cons; @@ -76,7 +77,11 @@ xencons_ring_send(const char *data, unsigned len) wmb(); intf->out_prod = prod; - xen_intr_signal(console_handle); + if (cnsl_evt_reg) + xen_intr_signal(console_handle); + else + HYPERVISOR_event_channel_op(EVTCHNOP_send, &send); + return sent; @@ -125,11 +130,11 @@ xencons_ring_init(void) { int err; - if (!xen_start_info->console_evtchn) + if (!HYPERVISOR_start_info->console_evtchn) return 0; err = xen_intr_bind_local_port(xencons_dev, - xen_start_info->console_evtchn, NULL, xencons_handle_input, NULL, + HYPERVISOR_start_info->console_evtchn, NULL, xencons_handle_input, NULL, INTR_TYPE_MISC | INTR_MPSAFE, &console_handle); if (err) { return err; @@ -145,7 +150,7 @@ void xencons_suspend(void) { - if (!xen_start_info->console_evtchn) + if (!HYPERVISOR_start_info->console_evtchn) return; xen_intr_unbind(&console_handle); diff --git a/sys/dev/xen/control/control.c b/sys/dev/xen/control/control.c index a9f8d1b..35c923d 100644 --- a/sys/dev/xen/control/control.c +++ b/sys/dev/xen/control/control.c @@ -317,21 +317,6 @@ xctrl_suspend() EVENTHANDLER_INVOKE(power_resume); } -static void -xen_pv_shutdown_final(void *arg, int howto) -{ - /* - * Inform the hypervisor that shutdown is complete. - * This is not necessary in HVM domains since Xen - * emulates ACPI in that mode and FreeBSD's ACPI - * support will request this transition. - */ - if (howto & (RB_HALT | RB_POWEROFF)) - HYPERVISOR_shutdown(SHUTDOWN_poweroff); - else - HYPERVISOR_shutdown(SHUTDOWN_reboot); -} - #else /* HVM mode suspension. */ @@ -447,6 +432,21 @@ xctrl_halt() shutdown_nice(RB_HALT); } +static void +xen_pv_shutdown_final(void *arg, int howto) +{ + /* + * Inform the hypervisor that shutdown is complete. + * This is not necessary in HVM domains since Xen + * emulates ACPI in that mode and FreeBSD's ACPI + * support will request this transition. + */ + if (howto & (RB_HALT | RB_POWEROFF)) + HYPERVISOR_shutdown(SHUTDOWN_poweroff); + else + HYPERVISOR_shutdown(SHUTDOWN_reboot); +} + /*------------------------------ Event Reception -----------------------------*/ static void xctrl_on_watch_event(struct xs_watch *watch, const char **vec, unsigned int len) @@ -529,10 +529,9 @@ xctrl_attach(device_t dev) xctrl->xctrl_watch.callback_data = (uintptr_t)xctrl; xs_register_watch(&xctrl->xctrl_watch); -#ifndef XENHVM - EVENTHANDLER_REGISTER(shutdown_final, xen_pv_shutdown_final, NULL, - SHUTDOWN_PRI_LAST); -#endif + if (xen_pv_domain()) + EVENTHANDLER_REGISTER(shutdown_final, xen_pv_shutdown_final, NULL, + SHUTDOWN_PRI_LAST); return (0); } diff --git a/sys/dev/xen/timer/timer.c b/sys/dev/xen/timer/timer.c index 354085b..333f1b0 100644 --- a/sys/dev/xen/timer/timer.c +++ b/sys/dev/xen/timer/timer.c @@ -59,6 +59,9 @@ __FBSDID("$FreeBSD$"); #include #include +/* For the declaration of clock_lock */ +#include + #include "clock_if.h" static devclass_t xentimer_devclass; @@ -95,19 +98,6 @@ struct xentimer_softc { /* Last time; this guarantees a monotonically increasing clock. */ volatile uint64_t xen_timer_last_time = 0; -static void -xentimer_identify(driver_t *driver, device_t parent) -{ - if (!xen_domain()) - return; - - /* Handle all Xen PV timers in one device instance. */ - if (devclass_get_device(xentimer_devclass, 0)) - return; - - BUS_ADD_CHILD(parent, 0, "xen_et", 0); -} - static int xentimer_probe(device_t dev) { @@ -234,18 +224,16 @@ xen_fetch_vcpu_tinfo(struct vcpu_time_info *dst, struct vcpu_time_info *src) * it happens to be less than another CPU's previously determined value. */ static uint64_t -xen_fetch_vcpu_time(void) +xen_fetch_vcpu_time(struct vcpu_info *vcpu) { struct vcpu_time_info dst; struct vcpu_time_info *src; uint32_t pre_version; uint64_t now; volatile uint64_t last; - struct vcpu_info *vcpu = DPCPU_GET(vcpu_info); src = &vcpu->time; - critical_enter(); do { pre_version = xen_fetch_vcpu_tinfo(&dst, src); barrier(); @@ -266,16 +254,19 @@ xen_fetch_vcpu_time(void) } } while (!atomic_cmpset_64(&xen_timer_last_time, last, now)); - critical_exit(); - return (now); } static uint32_t xentimer_get_timecount(struct timecounter *tc) { + uint32_t xen_time; + + critical_enter(); + xen_time = (uint32_t)xen_fetch_vcpu_time(DPCPU_GET(vcpu_info)) & UINT_MAX; + critical_exit(); - return ((uint32_t)xen_fetch_vcpu_time() & UINT_MAX); + return xen_time; } /** @@ -305,7 +296,12 @@ xen_fetch_wallclock(struct timespec *ts) static void xen_fetch_uptime(struct timespec *ts) { - uint64_t uptime = xen_fetch_vcpu_time(); + uint64_t uptime; + + critical_enter(); + uptime = xen_fetch_vcpu_time(DPCPU_GET(vcpu_info)); + critical_exit(); + ts->tv_sec = uptime / NSEC_IN_SEC; ts->tv_nsec = uptime % NSEC_IN_SEC; } @@ -354,7 +350,7 @@ xentimer_intr(void *arg) struct xentimer_softc *sc = (struct xentimer_softc *)arg; struct xentimer_pcpu_data *pcpu = DPCPU_PTR(xentimer_pcpu); - pcpu->last_processed = xen_fetch_vcpu_time(); + pcpu->last_processed = xen_fetch_vcpu_time(DPCPU_GET(vcpu_info)); if (pcpu->timer != 0 && sc->et.et_active) sc->et.et_event_cb(&sc->et, sc->et.et_arg); @@ -415,7 +411,9 @@ xentimer_et_start(struct eventtimer *et, do { if (++i == 60) panic("can't schedule timer"); - next_time = xen_fetch_vcpu_time() + first_in_ns; + critical_enter(); + next_time = xen_fetch_vcpu_time(DPCPU_GET(vcpu_info)) + first_in_ns; + critical_exit(); error = xentimer_vcpu_start_timer(cpu, next_time); } while (error == -ETIME); @@ -573,8 +571,37 @@ xentimer_suspend(device_t dev) return (0); } +/* + * Xen delay early init + */ +void xen_delay_init(void) +{ + /* Init the clock lock */ + mtx_init(&clock_lock, "clk", NULL, MTX_SPIN | MTX_NOPROFILE); +} +/* + * Xen PV DELAY function + * + * When running on PVH mode we don't have an emulated i8524, so + * make use of the Xen time info in order to code a simple DELAY + * function that can be used during early boot. + */ +void xen_delay(int n) +{ + uint64_t end_ns; + uint64_t current; + + end_ns = xen_fetch_vcpu_time(&HYPERVISOR_shared_info->vcpu_info[0]); + end_ns += n * NSEC_IN_USEC; + + for (;;) { + current = xen_fetch_vcpu_time(&HYPERVISOR_shared_info->vcpu_info[0]); + if (current >= end_ns) + break; + } +} + static device_method_t xentimer_methods[] = { - DEVMETHOD(device_identify, xentimer_identify), DEVMETHOD(device_probe, xentimer_probe), DEVMETHOD(device_attach, xentimer_attach), DEVMETHOD(device_detach, xentimer_detach), diff --git a/sys/dev/xen/xenpci/xenpci.c b/sys/dev/xen/xenpci/xenpci.c index dd2ad92..a19ebcb 100644 --- a/sys/dev/xen/xenpci/xenpci.c +++ b/sys/dev/xen/xenpci/xenpci.c @@ -240,6 +240,7 @@ xenpci_attach(device_t dev) { struct xenpci_softc *scp = device_get_softc(dev); devclass_t dc; + device_t child; int error; /* @@ -270,6 +271,13 @@ xenpci_attach(device_t dev) goto errexit; } + if (BUS_ADD_CHILD(dev, 0, "xenstore", 0) == NULL) + panic("xenpci: unable to add xenstore device"); + child = BUS_ADD_CHILD(nexus, 0, "xen_et", 0); + if (child == NULL) + panic("xenpci: unable to add xen pv timer device"); + device_probe_and_attach(child); + return (bus_generic_attach(dev)); errexit: diff --git a/sys/i386/i386/locore.s b/sys/i386/i386/locore.s index 68cb430..bd136b1 100644 --- a/sys/i386/i386/locore.s +++ b/sys/i386/i386/locore.s @@ -898,3 +898,12 @@ done_pde: #endif ret + +#ifdef XENHVM +/* Xen Hypercall page */ + .text +.p2align PAGE_SHIFT, 0x90 /* Hypercall_page needs to be PAGE aligned */ + +NON_GPROF_ENTRY(hypercall_page) + .skip 0x1000, 0x90 /* Fill with "nop"s */ +#endif diff --git a/sys/i386/i386/machdep.c b/sys/i386/i386/machdep.c index c430316..af12b1d 100644 --- a/sys/i386/i386/machdep.c +++ b/sys/i386/i386/machdep.c @@ -254,6 +254,17 @@ struct mtx icu_lock; struct mem_range_softc mem_range_softc; +#ifndef XEN +void +DELAY(int n) +{ + if (delay_tc(n)) + return; + + i8254_delay(n); +} +#endif + static void cpu_startup(dummy) void *dummy; diff --git a/sys/i386/include/clock.h b/sys/i386/include/clock.h index d980ec7..287b2c8 100644 --- a/sys/i386/include/clock.h +++ b/sys/i386/include/clock.h @@ -22,6 +22,12 @@ extern int tsc_is_invariant; extern int tsc_perf_stat; void i8254_init(void); +void i8254_delay(int); +#ifdef XENHVM +void xen_delay_init(void); +void xen_delay(int); +#endif +int delay_tc(int); /* * Driver to clock driver interface. diff --git a/sys/i386/include/xen/hypercall.h b/sys/i386/include/xen/hypercall.h index edc13f4..1c15b0f 100644 --- a/sys/i386/include/xen/hypercall.h +++ b/sys/i386/include/xen/hypercall.h @@ -40,15 +40,8 @@ #define CONFIG_XEN_COMPAT 0x030002 -#if defined(XEN) #define HYPERCALL_STR(name) \ "call hypercall_page + ("STR(__HYPERVISOR_##name)" * 32)" -#else -#define HYPERCALL_STR(name) \ - "mov hypercall_stubs,%%eax; " \ - "add $("STR(__HYPERVISOR_##name)" * 32),%%eax; " \ - "call *%%eax" -#endif #define _hypercall0(type, name) \ ({ \ diff --git a/sys/i386/xen/mp_machdep.c b/sys/i386/xen/mp_machdep.c index c48fcb2..adf7627 100644 --- a/sys/i386/xen/mp_machdep.c +++ b/sys/i386/xen/mp_machdep.c @@ -928,9 +928,9 @@ cpu_initialize_context(unsigned int cpu) smp_trap_init(ctxt.trap_ctxt); ctxt.ldt_ents = 0; - ctxt.gdt_frames[0] = + ctxt.u.pv.gdt_frames[0] = (uint32_t)((uint64_t)vtomach(bootAPgdt) >> PAGE_SHIFT); - ctxt.gdt_ents = 512; + ctxt.u.pv.gdt_ents = 512; #ifdef __i386__ ctxt.user_regs.esp = boot_stack + PAGE_SIZE; @@ -959,7 +959,7 @@ cpu_initialize_context(unsigned int cpu) #endif printf("gdtpfn=%lx pdptpfn=%lx\n", - ctxt.gdt_frames[0], + ctxt.u.pv.gdt_frames[0], ctxt.ctrlreg[3] >> PAGE_SHIFT); PANIC_IF(HYPERVISOR_vcpu_op(VCPUOP_initialise, cpu, &ctxt)); diff --git a/sys/i386/xen/xen_machdep.c b/sys/i386/xen/xen_machdep.c index 7049be6..1b1c74d 100644 --- a/sys/i386/xen/xen_machdep.c +++ b/sys/i386/xen/xen_machdep.c @@ -89,6 +89,7 @@ IDTVEC(div), IDTVEC(dbg), IDTVEC(nmi), IDTVEC(bpt), IDTVEC(ofl), int xendebug_flags; start_info_t *xen_start_info; +start_info_t *HYPERVISOR_start_info; shared_info_t *HYPERVISOR_shared_info; xen_pfn_t *xen_machine_phys = machine_to_phys_mapping; xen_pfn_t *xen_phys_machine; @@ -744,7 +745,7 @@ void initvalues(start_info_t *startinfo); struct xenstore_domain_interface; extern struct xenstore_domain_interface *xen_store; -char *console_page; +extern char *console_page; void * bootmem_alloc(unsigned int size) @@ -927,6 +928,7 @@ initvalues(start_info_t *startinfo) HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_4gb_segments_notify); #endif xen_start_info = startinfo; + HYPERVISOR_start_info = startinfo; xen_phys_machine = (xen_pfn_t *)startinfo->mfn_list; IdlePTD = (pd_entry_t *)((uint8_t *)startinfo->pt_base + PAGE_SIZE); diff --git a/sys/x86/isa/clock.c b/sys/x86/isa/clock.c index a12e175..a5aed1c 100644 --- a/sys/x86/isa/clock.c +++ b/sys/x86/isa/clock.c @@ -247,61 +247,13 @@ getit(void) return ((high << 8) | low); } -#ifndef DELAYDEBUG -static u_int -get_tsc(__unused struct timecounter *tc) -{ - - return (rdtsc32()); -} - -static __inline int -delay_tc(int n) -{ - struct timecounter *tc; - timecounter_get_t *func; - uint64_t end, freq, now; - u_int last, mask, u; - - tc = timecounter; - freq = atomic_load_acq_64(&tsc_freq); - if (tsc_is_invariant && freq != 0) { - func = get_tsc; - mask = ~0u; - } else { - if (tc->tc_quality <= 0) - return (0); - func = tc->tc_get_timecount; - mask = tc->tc_counter_mask; - freq = tc->tc_frequency; - } - now = 0; - end = freq * n / 1000000; - if (func == get_tsc) - sched_pin(); - last = func(tc) & mask; - do { - cpu_spinwait(); - u = func(tc) & mask; - if (u < last) - now += mask - last + u + 1; - else - now += u - last; - last = u; - } while (now < end); - if (func == get_tsc) - sched_unpin(); - return (1); -} -#endif - /* * Wait "n" microseconds. * Relies on timer 1 counting down from (i8254_freq / hz) * Note: timer had better have been programmed before this is first used! */ void -DELAY(int n) +i8254_delay(int n) { int delta, prev_tick, tick, ticks_left; #ifdef DELAYDEBUG @@ -317,9 +269,6 @@ DELAY(int n) } if (state == 1) printf("DELAY(%d)...", n); -#else - if (delay_tc(n)) - return; #endif /* * Read the counter first, so that the rest of the setup overhead is diff --git a/sys/x86/isa/isa.c b/sys/x86/isa/isa.c index 1a57137..09d1ab7 100644 --- a/sys/x86/isa/isa.c +++ b/sys/x86/isa/isa.c @@ -241,3 +241,6 @@ isa_release_resource(device_t bus, device_t child, int type, int rid, * On this platform, isa can also attach to the legacy bus. */ DRIVER_MODULE(isa, legacy, isa_driver, isa_devclass, 0, 0); +#ifdef XENHVM +DRIVER_MODULE(isa, nexus, isa_driver, isa_devclass, 0, 0); +#endif diff --git a/sys/x86/x86/delay.c b/sys/x86/x86/delay.c new file mode 100644 index 0000000..7ea70b1 --- /dev/null +++ b/sys/x86/x86/delay.c @@ -0,0 +1,95 @@ +/*- + * Copyright (c) 1990 The Regents of the University of California. + * Copyright (c) 2010 Alexander Motin + * All rights reserved. + * + * This code is derived from software contributed to Berkeley by + * William Jolitz and Don Ahn. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 4. Neither the name of the University nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * from: @(#)clock.c 7.2 (Berkeley) 5/12/91 + */ + +#include +__FBSDID("$FreeBSD$"); + +/* Generic x86 routines to handle delay */ + +#include +#include +#include +#include +#include +#include + +#include +#include + +static u_int +get_tsc(__unused struct timecounter *tc) +{ + + return (rdtsc32()); +} + +int +delay_tc(int n) +{ + struct timecounter *tc; + timecounter_get_t *func; + uint64_t end, freq, now; + u_int last, mask, u; + + tc = timecounter; + freq = atomic_load_acq_64(&tsc_freq); + if (tsc_is_invariant && freq != 0) { + func = get_tsc; + mask = ~0u; + } else { + if (tc->tc_quality <= 0) + return (0); + func = tc->tc_get_timecount; + mask = tc->tc_counter_mask; + freq = tc->tc_frequency; + } + now = 0; + end = freq * n / 1000000; + if (func == get_tsc) + sched_pin(); + last = func(tc) & mask; + do { + cpu_spinwait(); + u = func(tc) & mask; + if (u < last) + now += mask - last + u + 1; + else + now += u - last; + last = u; + } while (now < end); + if (func == get_tsc) + sched_unpin(); + return (1); +} diff --git a/sys/x86/x86/local_apic.c b/sys/x86/x86/local_apic.c index 8c8eef6..d8d7701 100644 --- a/sys/x86/x86/local_apic.c +++ b/sys/x86/x86/local_apic.c @@ -1368,9 +1368,13 @@ apic_setup_io(void *dummy __unused) if (retval != 0) printf("%s: Failed to setup I/O APICs: returned %d\n", best_enum->apic_name, retval); -#ifdef XEN - return; + +#if defined(XEN) || defined(XENHVM) + /* There's no lapic on PV Xen */ + if (xen_pv_domain()) + return; #endif + /* * Finish setting up the local APIC on the BSP once we know how to * properly program the LINT pins. diff --git a/sys/x86/xen/hvm.c b/sys/x86/xen/hvm.c index 72811dc..dc8d9a2 100644 --- a/sys/x86/xen/hvm.c +++ b/sys/x86/xen/hvm.c @@ -35,15 +35,21 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include +#include +#include #include #include +#include +#include #include #include #include #include +#include #include @@ -52,6 +58,9 @@ __FBSDID("$FreeBSD$"); #include #include #include +#ifdef __amd64__ +#include +#endif #include #include @@ -97,6 +106,11 @@ extern void pmap_lazyfix_action(void); /* Variables used by mp_machdep to perform the bitmap IPI */ extern volatile u_int cpu_ipi_pending[MAXCPU]; +#ifdef __amd64__ +/* Native AP start used on PVHVM */ +extern int native_start_all_aps(void); +#endif + /*---------------------------------- Macros ----------------------------------*/ #define IPI_TO_IDX(ipi) ((ipi) - APIC_IPI_INTS) @@ -119,7 +133,10 @@ enum xen_domain_type xen_domain_type = XEN_NATIVE; struct cpu_ops xen_hvm_cpu_ops = { .ipi_vectored = lapic_ipi_vectored, .cpu_init = xen_hvm_cpu_init, - .cpu_resume = xen_hvm_cpu_resume + .cpu_resume = xen_hvm_cpu_resume, +#ifdef __amd64__ + .start_all_aps = native_start_all_aps, +#endif }; static MALLOC_DEFINE(M_XENHVM, "xen_hvm", "Xen HVM PV Support"); @@ -157,8 +174,9 @@ DPCPU_DEFINE(xen_intr_handle_t, ipi_handle[nitems(xen_ipis)]); /*------------------ Hypervisor Access Shared Memory Regions -----------------*/ /** Hypercall table accessed via HYPERVISOR_*_op() methods. */ -char *hypercall_stubs; +extern char *hypercall_page; shared_info_t *HYPERVISOR_shared_info; +start_info_t *HYPERVISOR_start_info; #ifdef SMP /*---------------------------- XEN PV IPI Handlers ---------------------------*/ @@ -522,7 +540,7 @@ xen_setup_cpus(void) { int i; - if (!xen_hvm_domain() || !xen_vector_callback_enabled) + if (!xen_vector_callback_enabled) return; #ifdef __amd64__ @@ -558,7 +576,7 @@ xen_hvm_cpuid_base(void) * Allocate and fill in the hypcall page. */ static int -xen_hvm_init_hypercall_stubs(void) +xen_hvm_init_hypercall_stubs(enum xen_hvm_init_type init_type) { uint32_t base, regs[4]; int i; @@ -567,7 +585,7 @@ xen_hvm_init_hypercall_stubs(void) if (base == 0) return (ENXIO); - if (hypercall_stubs == NULL) { + if (init_type == XEN_HVM_INIT_COLD) { do_cpuid(base + 1, regs); printf("XEN: Hypervisor version %d.%d detected.\n", regs[0] >> 16, regs[0] & 0xffff); @@ -577,18 +595,9 @@ xen_hvm_init_hypercall_stubs(void) * Find the hypercall pages. */ do_cpuid(base + 2, regs); - - if (hypercall_stubs == NULL) { - size_t call_region_size; - - call_region_size = regs[0] * PAGE_SIZE; - hypercall_stubs = malloc(call_region_size, M_XENHVM, M_NOWAIT); - if (hypercall_stubs == NULL) - panic("Unable to allocate Xen hypercall region"); - } for (i = 0; i < regs[0]; i++) - wrmsr(regs[1], vtophys(hypercall_stubs + i * PAGE_SIZE) + i); + wrmsr(regs[1], vtophys(&hypercall_page + i * PAGE_SIZE) + i); return (0); } @@ -677,8 +686,6 @@ xen_hvm_disable_emulated_devices(void) if (inw(XEN_MAGIC_IOPORT) != XMI_MAGIC) return; - if (bootverbose) - printf("XEN: Disabling emulated block and network devices\n"); outw(XEN_MAGIC_IOPORT, XMI_UNPLUG_IDE_DISKS|XMI_UNPLUG_NICS); } @@ -691,7 +698,12 @@ xen_hvm_init(enum xen_hvm_init_type init_type) if (init_type == XEN_HVM_INIT_CANCELLED_SUSPEND) return; - error = xen_hvm_init_hypercall_stubs(); + if (xen_pv_domain()) { + /* hypercall page is already set in the PV case */ + error = 0; + } else { + error = xen_hvm_init_hypercall_stubs(init_type); + } switch (init_type) { case XEN_HVM_INIT_COLD: @@ -701,6 +713,12 @@ xen_hvm_init(enum xen_hvm_init_type init_type) setup_xen_features(); cpu_ops = xen_hvm_cpu_ops; vm_guest = VM_GUEST_XEN; +#ifdef __amd64__ + if (xen_pv_domain()) + cpu_ops.start_all_aps = xen_pv_start_all_aps; + else +#endif + printf("XEN: Disabling emulated block and network devices\n"); break; case XEN_HVM_INIT_RESUME: if (error != 0) @@ -715,10 +733,13 @@ xen_hvm_init(enum xen_hvm_init_type init_type) } xen_vector_callback_enabled = 0; - xen_domain_type = XEN_HVM_DOMAIN; - xen_hvm_init_shared_info_page(); xen_hvm_set_callback(NULL); - xen_hvm_disable_emulated_devices(); + + if (!xen_pv_domain()) { + xen_domain_type = XEN_HVM_DOMAIN; + xen_hvm_init_shared_info_page(); + xen_hvm_disable_emulated_devices(); + } } void @@ -749,10 +770,14 @@ xen_set_vcpu_id(void) struct pcpu *pc; int i; - /* Set vcpu_id to acpi_id */ + if (!xen_domain()) + return; + + /* Set vcpu_id to acpi_id for PVHVM guests */ CPU_FOREACH(i) { pc = pcpu_find(i); - pc->pc_vcpu_id = pc->pc_acpi_id; + if (xen_hvm_domain()) + pc->pc_vcpu_id = pc->pc_acpi_id; if (bootverbose) printf("XEN: CPU %u has VCPU ID %u\n", i, pc->pc_vcpu_id); @@ -790,9 +815,34 @@ xen_hvm_cpu_init(void) DPCPU_SET(vcpu_info, vcpu_info); } +/*----------------------------- Debug functions ------------------------------*/ +#define PRINTK_BUFSIZE 1024 +static int +vprintk(const char *fmt, __va_list ap) +{ + int retval, len; + static char buf[PRINTK_BUFSIZE]; + + retval = vsnprintf(buf, PRINTK_BUFSIZE - 1, fmt, ap); + buf[retval] = 0; + len = strlen(buf); + retval = HYPERVISOR_console_io(CONSOLEIO_write, len, (char *)buf); + return retval; +} + +void +xen_early_printf(const char *fmt, ...) +{ + __va_list ap; + + va_start(ap, fmt); + vprintk(fmt, ap); + va_end(ap); +} + SYSINIT(xen_hvm_init, SI_SUB_HYPERVISOR, SI_ORDER_FIRST, xen_hvm_sysinit, NULL); #ifdef SMP -SYSINIT(xen_setup_cpus, SI_SUB_SMP, SI_ORDER_FIRST, xen_setup_cpus, NULL); +SYSINIT(xen_setup_cpus, SI_SUB_SMP-1, SI_ORDER_ANY, xen_setup_cpus, NULL); #endif SYSINIT(xen_hvm_cpu_init, SI_SUB_INTR, SI_ORDER_FIRST, xen_hvm_cpu_init, NULL); SYSINIT(xen_set_vcpu_id, SI_SUB_CPU, SI_ORDER_ANY, xen_set_vcpu_id, NULL); diff --git a/sys/x86/xen/mptable.c b/sys/x86/xen/mptable.c new file mode 100644 index 0000000..8916314 --- /dev/null +++ b/sys/x86/xen/mptable.c @@ -0,0 +1,136 @@ +/*- + * Copyright (c) 2003 John Baldwin + * Copyright (c) 2013 Roger Pau Monné + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. Neither the name of the author nor the names of any co-contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#include +#include + +#include +#include + +#include + +static int xenpv_probe(void); +static int xenpv_probe_cpus(void); +static int xenpv_setup_local(void); +static int xenpv_setup_io(void); + +static struct apic_enumerator xenpv_enumerator = { + "Xen PV", + xenpv_probe, + xenpv_probe_cpus, + xenpv_setup_local, + xenpv_setup_io +}; + +/* + * Look for an ACPI Multiple APIC Description Table ("APIC") + */ +static int +xenpv_probe(void) +{ + return (-100); +} + +/* + * Run through the MP table enumerating CPUs. + */ +static int +xenpv_probe_cpus(void) +{ + int i, ret; + + for (i = 0; i < MAXCPU; i++) { + ret = HYPERVISOR_vcpu_op(VCPUOP_is_up, i, NULL); + if (ret >= 0) + cpu_add((i * 2), (i == 0)); + } + + return (0); +} + +/* + * Initialize the local APIC on the BSP. + */ +static int +xenpv_setup_local(void) +{ + PCPU_SET(vcpu_id, 0); + return (0); +} + +/* + * Enumerate I/O APICs and setup interrupt sources. + */ +static int +xenpv_setup_io(void) +{ + return (0); +} + +static void +xenpv_register(void *dummy __unused) +{ + if (xen_pv_domain()) { + apic_register_enumerator(&xenpv_enumerator); + } +} +SYSINIT(xenpv_register, SI_SUB_TUNABLES - 1, SI_ORDER_FIRST, xenpv_register, NULL); + +/* + * Setup per-CPU ACPI IDs. + */ +static void +xenpv_set_ids(void *dummy) +{ + struct pcpu *pc; + int i; + + CPU_FOREACH(i) { + pc = pcpu_find(i); + pc->pc_vcpu_id = i; + } + return; +} +SYSINIT(xenpv_set_ids, SI_SUB_CPU, SI_ORDER_MIDDLE, xenpv_set_ids, NULL); diff --git a/sys/x86/xen/pv.c b/sys/x86/xen/pv.c new file mode 100644 index 0000000..ea1706f --- /dev/null +++ b/sys/x86/xen/pv.c @@ -0,0 +1,246 @@ +/* + * Copyright (c) 2004 Christian Limpach. + * Copyright (c) 2004-2006,2008 Kip Macy + * Copyright (c) 2013 Roger Pau Monné + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#include + +#include +#include +#include +#include +#include +#include + +#include + +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#define MAX_E820_ENTRIES 128 + +/*--------------------------- Forward Declarations ---------------------------*/ +static caddr_t xen_pv_parse_preload_data(u_int64_t); +static void xen_pv_fetch_e820_map(caddr_t, struct bios_smap **, u_int32_t *); + +/*---------------------------- Extern Declarations ---------------------------*/ +/* Variables used by amd64 mp_machdep to start APs */ +extern struct mtx ap_boot_mtx; +extern void *bootstacks[]; +extern char *doublefault_stack; +extern char *nmi_stack; +extern void *dpcpu; +extern int bootAP; +extern char *bootSTK; +extern bool lapic_disabled; + +/*-------------------------------- Global Data -------------------------------*/ +/* Xen init_ops implementation. */ +struct init_ops xen_init_ops = { + .parse_preload_data = xen_pv_parse_preload_data, + .early_delay_init = xen_delay_init, + .early_delay = xen_delay, + .fetch_e820_map = xen_pv_fetch_e820_map, +}; + +static struct +{ + const char *ev; + int mask; +} howto_names[] = { + {"boot_askname", RB_ASKNAME}, + {"boot_single", RB_SINGLE}, + {"boot_nosync", RB_NOSYNC}, + {"boot_halt", RB_ASKNAME}, + {"boot_serial", RB_SERIAL}, + {"boot_cdrom", RB_CDROM}, + {"boot_gdb", RB_GDB}, + {"boot_gdb_pause", RB_RESERVED1}, + {"boot_verbose", RB_VERBOSE}, + {"boot_multicons", RB_MULTIPLE}, + {NULL, 0} +}; + +static struct bios_smap xen_smap[MAX_E820_ENTRIES]; + +static int +start_xen_ap(int cpu) +{ + struct vcpu_guest_context *ctxt; + int ms, cpus = mp_naps; + + ctxt = malloc(sizeof(*ctxt), M_TEMP, M_NOWAIT | M_ZERO); + if (ctxt == NULL) + panic("unable to allocate memory"); + + ctxt->flags = VGCF_IN_KERNEL; + ctxt->user_regs.rip = (unsigned long) init_secondary; + ctxt->user_regs.rsp = (unsigned long) bootSTK; + + /* Set the CPU to use the same page tables and CR4 value */ + ctxt->ctrlreg[3] = KPML4phys; + + if (HYPERVISOR_vcpu_op(VCPUOP_initialise, cpu, ctxt)) + panic("unable to initialize CPU#%d\n", cpu); + + free(ctxt, M_TEMP); + + /* Launch the vCPU */ + if (HYPERVISOR_vcpu_op(VCPUOP_up, cpu, NULL)) + panic("unable to start AP#%d\n", cpu); + + /* Wait up to 5 seconds for it to start. */ + for (ms = 0; ms < 5000; ms++) { + if (mp_naps > cpus) + return 1; /* return SUCCESS */ + DELAY(1000); + } + + return 0; +} + +int +xen_pv_start_all_aps(void) +{ + int cpu; + + mtx_init(&ap_boot_mtx, "ap boot", NULL, MTX_SPIN); + lapic_disabled = true; + + for (cpu = 1; cpu < mp_ncpus; cpu++) { + + /* allocate and set up an idle stack data page */ + bootstacks[cpu] = (void *)kmem_malloc(kernel_arena, + KSTACK_PAGES * PAGE_SIZE, M_WAITOK | M_ZERO); + doublefault_stack = (char *)kmem_malloc(kernel_arena, + PAGE_SIZE, M_WAITOK | M_ZERO); + nmi_stack = (char *)kmem_malloc(kernel_arena, PAGE_SIZE, + M_WAITOK | M_ZERO); + dpcpu = (void *)kmem_malloc(kernel_arena, DPCPU_SIZE, + M_WAITOK | M_ZERO); + + bootSTK = (char *)bootstacks[cpu] + KSTACK_PAGES * PAGE_SIZE - 8; + bootAP = cpu; + + /* attempt to start the Application Processor */ + if (!start_xen_ap(cpu)) + panic("AP #%d failed to start!", cpu); + + CPU_SET(cpu, &all_cpus); /* record AP in CPU map */ + } + + return mp_naps; +} + +/* + * Functions to convert the "extra" parameters passed by Xen + * into FreeBSD boot options (from the i386 Xen port). + */ +static char * +xen_setbootenv(char *cmd_line) +{ + char *cmd_line_next; + + /* Skip leading spaces */ + for (; *cmd_line == ' '; cmd_line++); + + for (cmd_line_next = cmd_line; strsep(&cmd_line_next, ",") != NULL;); + return (cmd_line); +} + +static int +xen_boothowto(char *envp) +{ + int i, howto = 0; + + /* get equivalents from the environment */ + for (i = 0; howto_names[i].ev != NULL; i++) + if (getenv(howto_names[i].ev) != NULL) + howto |= howto_names[i].mask; + return (howto); +} + +static caddr_t +xen_pv_parse_preload_data(u_int64_t modulep) +{ + /* Parse the extra boot information given by Xen */ + if (HYPERVISOR_start_info->cmd_line) + kern_envp = xen_setbootenv(HYPERVISOR_start_info->cmd_line); + boothowto |= xen_boothowto(kern_envp); + + return (NULL); +} + +static void +xen_pv_fetch_e820_map(caddr_t kmdp, struct bios_smap **smap, u_int32_t *size) +{ + struct xen_memory_map memmap; + int rc; + + /* Fetch the E820 map from Xen */ + memmap.nr_entries = MAX_E820_ENTRIES; + set_xen_guest_handle(memmap.buffer, xen_smap); + rc = HYPERVISOR_memory_op(XENMEM_memory_map, &memmap); + if (rc) + panic("unable to fetch Xen E820 memory map"); + + *smap = xen_smap; + *size = memmap.nr_entries * sizeof(xen_smap[0]); +} + +void +xen_pv_set_init_ops(void) +{ + /* Init ops for Xen PV */ + init_ops = xen_init_ops; +} diff --git a/sys/x86/xen/pvcpu.c b/sys/x86/xen/pvcpu.c new file mode 100644 index 0000000..35d88148 --- /dev/null +++ b/sys/x86/xen/pvcpu.c @@ -0,0 +1,77 @@ +/* + * Copyright (c) 2013 Roger Pau Monné + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include +#include +#include +#include + +#include + +static int +xenpvcpu_probe(device_t dev) +{ + if (!xen_pv_domain()) + return (ENXIO); + + device_set_desc(dev, "Xen PV CPU"); + return (0); +} + +static int +xenpvcpu_attach(device_t dev) +{ + struct pcpu *pc; + int cpu; + + cpu = device_get_unit(dev); + pc = pcpu_find(cpu); + pc->pc_device = dev; + return (0); +} + +static device_method_t xenpvcpu_methods[] = { + DEVMETHOD(device_probe, xenpvcpu_probe), + DEVMETHOD(device_attach, xenpvcpu_attach), + DEVMETHOD_END +}; + +static driver_t xenpvcpu_driver = { + "pvcpu", + xenpvcpu_methods, + 0, +}; + +devclass_t xenpvcpu_devclass; + +DRIVER_MODULE(xenpvcpu, nexus, xenpvcpu_driver, xenpvcpu_devclass, 0, 0); +MODULE_DEPEND(xenpvcpu, nexus, 1, 1, 1); diff --git a/sys/x86/xen/xen_nexus.c b/sys/x86/xen/xen_nexus.c new file mode 100644 index 0000000..288e6b6 --- /dev/null +++ b/sys/x86/xen/xen_nexus.c @@ -0,0 +1,99 @@ +/* + * Copyright (c) 2013 Roger Pau Monné + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include +#include +#include +#include + +#include + +#include + +static const char *xen_devices[] = +{ + "xenstore", /* XenStore bus */ + "xen_et", /* Xen PV timer (provides: tc, et, clk) */ + "xc", /* Xen PV console */ + "isa", /* Dummy ISA bus for sc to attach */ +}; + +/* + * Xen nexus(4) driver. + */ +static int +nexus_xen_probe(device_t dev) +{ + if (!xen_pv_domain()) + return (ENXIO); + + return (BUS_PROBE_DEFAULT); +} + +static int +nexus_xen_attach(device_t dev) +{ + int i, error = 0; + + nexus_init_resources(); + bus_generic_probe(dev); + + /* + * Since we have no ACPI, we need to create a dummy CPU device + * in order to set pcpu->pc_device. + */ + CPU_FOREACH(i) + if (BUS_ADD_CHILD(dev, 0, "pvcpu", i) == NULL) + panic("unable to add pvcpu#%d device", i); + + for (i = 0; i < nitems(xen_devices); i++) { + if (BUS_ADD_CHILD(dev, 0, xen_devices[i], 0) == NULL) + panic("%s: could not add", xen_devices[i]); + } + + bus_generic_attach(dev); + + return (error); +} + +static device_method_t nexus_xen_methods[] = { + /* Device interface */ + DEVMETHOD(device_probe, nexus_xen_probe), + DEVMETHOD(device_attach, nexus_xen_attach), + + { 0, 0 } +}; + +DEFINE_CLASS_1(nexus, nexus_xen_driver, nexus_xen_methods, 1, nexus_driver); +static devclass_t nexus_devclass; + +DRIVER_MODULE(nexus_xen, root, nexus_xen_driver, nexus_devclass, 0, 0); diff --git a/sys/xen/gnttab.c b/sys/xen/gnttab.c index 03c32b7..909378a 100644 --- a/sys/xen/gnttab.c +++ b/sys/xen/gnttab.c @@ -25,6 +25,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include @@ -607,6 +608,7 @@ gnttab_resume(void) { int error; unsigned int max_nr_gframes, nr_gframes; + void *alloc_mem; nr_gframes = nr_grant_frames; max_nr_gframes = max_nr_grant_frames(); @@ -614,11 +616,20 @@ gnttab_resume(void) return (ENOSYS); if (!resume_frames) { - error = xenpci_alloc_space(PAGE_SIZE * max_nr_gframes, - &resume_frames); - if (error) { - printf("error mapping gnttab share frames\n"); - return (error); + if (xen_pv_domain()) { + alloc_mem = contigmalloc(max_nr_gframes * PAGE_SIZE, + M_DEVBUF, M_NOWAIT, 0, + ULONG_MAX, PAGE_SIZE, 0); + KASSERT((alloc_mem != NULL), + ("unable to alloc memory for gnttab")); + resume_frames = vtophys(alloc_mem); + } else { + error = xenpci_alloc_space(PAGE_SIZE * max_nr_gframes, + &resume_frames); + if (error) { + printf("error mapping gnttab share frames\n"); + return (error); + } } } diff --git a/sys/xen/pv.h b/sys/xen/pv.h new file mode 100644 index 0000000..bbb1048 --- /dev/null +++ b/sys/xen/pv.h @@ -0,0 +1,29 @@ +/* + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to + * deal in the Software without restriction, including without limitation the + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + * + * $FreeBSD$ + */ + +#ifndef __XEN_PV_H__ +#define __XEN_PV_H__ + +int xen_pv_start_all_aps(void); +void xen_pv_set_init_ops(void); + +#endif /* __XEN_PV_H__ */ \ No newline at end of file diff --git a/sys/xen/xen-os.h b/sys/xen/xen-os.h index 87644e9..70e4719 100644 --- a/sys/xen/xen-os.h +++ b/sys/xen/xen-os.h @@ -51,6 +51,11 @@ void force_evtchn_callback(void); extern shared_info_t *HYPERVISOR_shared_info; +extern start_info_t *HYPERVISOR_start_info; + +/* XXX: we need to get rid of this and use HYPERVISOR_start_info directly */ +extern struct xenstore_domain_interface *xen_store; +extern char *console_page; enum xen_domain_type { XEN_NATIVE, /* running on bare hardware */ @@ -78,6 +83,9 @@ xen_hvm_domain(void) return (xen_domain_type == XEN_HVM_DOMAIN); } +/* Debug function, prints directly to hypervisor console */ +void xen_early_printf(const char *, ...); + #ifndef xen_mb #define xen_mb() mb() #endif diff --git a/sys/xen/xenstore/xenstore.c b/sys/xen/xenstore/xenstore.c index d404862..a4ef369 100644 --- a/sys/xen/xenstore/xenstore.c +++ b/sys/xen/xenstore/xenstore.c @@ -1079,12 +1079,6 @@ xs_init_comms(void) } /*------------------ Private Device Attachment Functions --------------------*/ -static void -xs_identify(driver_t *driver, device_t parent) -{ - - BUS_ADD_CHILD(parent, 0, "xenstore", 0); -} /** * Probe for the existance of the XenStore. @@ -1148,11 +1142,17 @@ xs_attach(device_t dev) struct proc *p; #ifdef XENHVM - xs.evtchn = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN); - xs.gpfn = hvm_get_parameter(HVM_PARAM_STORE_PFN); - xen_store = pmap_mapdev(xs.gpfn * PAGE_SIZE, PAGE_SIZE); + if (xen_hvm_domain()) { + xs.evtchn = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN); + xs.gpfn = hvm_get_parameter(HVM_PARAM_STORE_PFN); + xen_store = pmap_mapdev(xs.gpfn * PAGE_SIZE, PAGE_SIZE); + } else if (xen_pv_domain()) { + xs.evtchn = HYPERVISOR_start_info->store_evtchn; + } else { + panic("Unknown domain type, cannot initialize xenstore\n"); + } #else - xs.evtchn = xen_start_info->store_evtchn; + xs.evtchn = HYPERVISOR_start_info->store_evtchn; #endif TAILQ_INIT(&xs.reply_list); @@ -1240,7 +1240,6 @@ xs_resume(device_t dev __unused) /*-------------------- Private Device Attachment Data -----------------------*/ static device_method_t xenstore_methods[] = { /* Device interface */ - DEVMETHOD(device_identify, xs_identify), DEVMETHOD(device_probe, xs_probe), DEVMETHOD(device_attach, xs_attach), DEVMETHOD(device_detach, bus_generic_detach), @@ -1263,9 +1262,8 @@ static devclass_t xenstore_devclass; #ifdef XENHVM DRIVER_MODULE(xenstore, xenpci, xenstore_driver, xenstore_devclass, 0, 0); -#else -DRIVER_MODULE(xenstore, nexus, xenstore_driver, xenstore_devclass, 0, 0); #endif +DRIVER_MODULE(xenstore, nexus, xenstore_driver, xenstore_devclass, 0, 0); /*------------------------------- Sysctl Data --------------------------------*/ /* XXX Shouldn't the node be somewhere else? */ -- 1.7.7.5 (Apple Git-26) --------------040406040602030408060208-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 15 16:15:09 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94B79603 for ; Fri, 15 Nov 2013 16:15:09 +0000 (UTC) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 570E823F1 for ; Fri, 15 Nov 2013 16:15:09 +0000 (UTC) Received: by mail-qc0-f170.google.com with SMTP id n9so2271529qcw.1 for ; Fri, 15 Nov 2013 08:15:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=MXnC7XgTkks5ty/M+WIxVPoKnS+K50EdOYdDUfHWK7k=; b=C8FgTYqVQ1B3aVcdV2/1JXjZcwJVMEsFZDncse83wfTGLG1vfxGBxpfFejReudAyF4 pul/pgw1hn/cWSRtldnrwr0gmAe2KgbirnJ5umKC70Vn/jlO75F6uTsT3Q4cIdUfg+m9 pGX1ewWTO5TjE3hOZU7/FudFxwqINn9UST6ui7vAdzBWF1Ls+JV6CxG7RmSDnuqUcNf7 7EWaIpQB6ZFllPlfoLELsQzo0+NIgnHs2o3P81t4NKyjcn0JizlyKPuF2Eoilha2x89n exYuuu2S7rH1M/mnQ5LLBu4b5WMdWSgLoFN0V7yMkAmYD8mlth7xYQ7+sDldxsAUL9Yu U1NA== MIME-Version: 1.0 X-Received: by 10.229.5.4 with SMTP id 4mr12086388qct.2.1384532108423; Fri, 15 Nov 2013 08:15:08 -0800 (PST) Received: by 10.96.180.233 with HTTP; Fri, 15 Nov 2013 08:15:08 -0800 (PST) In-Reply-To: <1384529791.7937.47924713.3321BFEF@webmail.messagingengine.com> References: <20131114173423.GA21761@blazingdot.com> <59A9B68B-4134-4217-83F3-B99759174EFE@fisglobal.com> <5285148E.6020903@allanjude.com> <3D3332FA-0ABF-4573-8E65-4E7FBB37100B@fisglobal.com> <1384462198.13183.47596065.6F8E7BCD@webmail.messagingengine.com> <55232624-3B76-4781-91E0-0C2A6260144D@fisglobal.com> <5285E827.1090501@freebsd.org> <1384529791.7937.47924713.3321BFEF@webmail.messagingengine.com> Date: Fri, 15 Nov 2013 18:15:08 +0200 Message-ID: Subject: Re: Defaults in 10.0 ZFS through bsdinstall From: Kimmo Paasiala To: FreeBSD current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 16:15:09 -0000 On Fri, Nov 15, 2013 at 5:36 PM, Mark Felder wrote: > > > On Fri, Nov 15, 2013, at 3:23, Stefan Esser wrote: >> Am 14.11.2013 22:02, schrieb Teske, Devin: >> > On Nov 14, 2013, at 12:49 PM, Mark Felder wrote: >> >> We don't even do installs on UFS with atime disabled by default in fstab >> >> so why should we so suddenly change course for ZFS? >> >> >> > >> > You've made a good point. >> >> There is major difference between UFS and ZFS: UFS allows in-place >> updates of i-node fields (like atime), while ZFS uses COW for all >> data, file contents and meta-data like the i-nodes. >> >> With atime ON on UFS you'll see a small number of writes on >> file-systems that are only read - we are used to accept that. >> >> On ZFS every update of atime causes a write of the meta-data to >> a free location on disk, then updates of all data structures >> that reference that meta-data up to the root of the tree (the >> uberblock). An update of a few bytes turns out to write tens >> of KB for each atime update (within the TXG sync interval, which >> defaults to 5 seconds on FreeBSD). If you create snapshots, then >> each snapshot will contain a copy of the metadata that was valid >> at the time of the snapshot (well, that's not so different from >> the situation with UFS snapshots, just that the data structures >> are much more complex and larger in the ZFS case). Due to the >> ease and speed of snapshot creation with ZFS there probably are >> a magnitude or more snapshots on a typical ZFS system than on >> one using UFS (I currently have a few hundred and have turned off >> periodic snapshot generation on many unimportant file-systems, >> already). >> >> I really hope that we get relatime (with minor variations that >> were discussed a few months ago) and that we make it the default >> in some future release ... >> > > Thanks for this in-depth explanation. I wasn't aware that atime was > quite so expensive on ZFS. What I did on my system when I was still using ZFS was that I set atime off by default but enabled it explicitly on /var/mail and /home datasets. The thought was that it's needed for mailboxes in /var/mail and if I then decide to move the inboxes to user's home directories I won't get any surprises. Would that be a suitable compromise here? -Kimmo From owner-freebsd-current@FreeBSD.ORG Fri Nov 15 16:46:09 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7392543A for ; Fri, 15 Nov 2013 16:46:09 +0000 (UTC) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3F69425E8 for ; Fri, 15 Nov 2013 16:46:09 +0000 (UTC) Received: by mail-ob0-f180.google.com with SMTP id vb8so4038396obc.25 for ; Fri, 15 Nov 2013 08:46:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dpF8Q50745rjfpJ1knm4PQ2BftQvWMaqNcJ7ljOzMFU=; b=WGY1Ve7oGl+xldMt7yMoazsoHhkCBLU5uY/RwtWGt0TffyLpfKzhW/b8ZqTnDdFfzm sjl/C8mu3QOu8boYOzCJnoP1OBrZHtT//9ZlnU9BZJsrw/FCTFsgJMOxfqMzsoTkW3Ko 5930m63dtD26w+kL/ZvHLESrA/S0+5iCpu7lPtOQoXToEWS7sV+HDpsRbIR9PkZfonam rdv7n+RN9axncCBNWtEsVOATYT5nSHz8Lk6UhLNnWWOtwm5nPZJtL94yysiODkWLwd7m 88a2Eg9/PIi9VYu5LK3gVu4LqLCGcWwuIznz3LMeXPJFSsYot5nXx2ziMrqsXOXjY0tv t85g== MIME-Version: 1.0 X-Received: by 10.182.24.69 with SMTP id s5mr7862274obf.35.1384533968150; Fri, 15 Nov 2013 08:46:08 -0800 (PST) Received: by 10.76.99.210 with HTTP; Fri, 15 Nov 2013 08:46:08 -0800 (PST) In-Reply-To: <20131115180239.05e3575e@laptop.minsk.domain> References: <20131115081211.GP56153@ithaqua.etoilebsd.net> <20131115180239.05e3575e@laptop.minsk.domain> Date: Fri, 15 Nov 2013 11:46:08 -0500 Message-ID: Subject: Re: pkg install on CURRENT ? From: Outback Dingo To: "Sergey V. Dyatko" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 16:46:09 -0000 On Fri, Nov 15, 2013 at 10:02 AM, Sergey V. Dyatko wrote: > On Fri, 15 Nov 2013 08:29:10 -0500 > Outback Dingo wrote: > > > On Fri, Nov 15, 2013 at 3:12 AM, Baptiste Daroussin > > wrote: > > > > > On Thu, Nov 14, 2013 at 10:13:58PM -0500, Outback Dingo wrote: > > > > anyway to resolve this ??? id like to pkg install a few things or > > > > is my only option ports > > > > > > > > Checking integrity... done > > > > [1/16] Installing expat-2.0.1_2...pkg: wrong architecture: > > > > freebsd:10:x86:64 instead of freebsd:11:x86:64 > > > > > > pkg -vv, uname -a and file /bin/sh please > > > > > > regards, > > > Bapt > > > > > > > > > Nevermind I got it, needed to modify packagesite: > > http://pkg.FreeBSD.org/freebsd:11:x86:64/latest > > http://pkg.freebsd.org/${ABI}/latest > > > thanks for that.... now im golden....... > > -- > wbr, tiger > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Fri Nov 15 17:05:31 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA51213C; Fri, 15 Nov 2013 17:05:31 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 810142742; Fri, 15 Nov 2013 17:05:31 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAFH5UKP002410; Fri, 15 Nov 2013 12:05:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAFH5U5u000952; Fri, 15 Nov 2013 17:05:30 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 15 Nov 2013 17:05:30 GMT Message-Id: <201311151705.rAFH5U5u000952@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 17:05:31 -0000 TB --- 2013-11-15 16:56:42 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-15 16:56:42 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-15 16:56:42 - starting HEAD tinderbox run for mips/mips TB --- 2013-11-15 16:56:42 - cleaning the object tree TB --- 2013-11-15 16:56:42 - /usr/local/bin/svn stat /src TB --- 2013-11-15 16:56:45 - At svn revision 258162 TB --- 2013-11-15 16:56:46 - building world TB --- 2013-11-15 16:56:46 - CROSS_BUILD_TESTING=YES TB --- 2013-11-15 16:56:46 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-15 16:56:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-15 16:56:46 - SRCCONF=/dev/null TB --- 2013-11-15 16:56:46 - TARGET=mips TB --- 2013-11-15 16:56:46 - TARGET_ARCH=mips TB --- 2013-11-15 16:56:46 - TZ=UTC TB --- 2013-11-15 16:56:46 - __MAKE_CONF=/dev/null TB --- 2013-11-15 16:56:46 - cd /src TB --- 2013-11-15 16:56:46 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Nov 15 16:56:53 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools [...] cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/mips.mips/src/tmp/usr\" -DCROSS_COMPILE -DMIPS_ABI_DEFAULT=ABI_32 -DMIPS_CPU_STRING_DEFAULT=\"mips3\" -I/obj/mips.mips/src/tmp/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcclibs/libdecnumber -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -std=gnu89 -I/obj/mips.mips/src/tmp/legacy/usr/include -c /src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/tree-mudflap.c cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/mips.mips/src/tmp/usr\" -DCROSS_COMPILE -DMIPS_ABI_DEFAULT=ABI_32 -DMIPS_CPU_STRING_DEFAULT=\"mips3\" -I/obj/mips.mips/src/tmp/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcclibs/libdecnumber -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -std=gnu89 -I/obj/mips.mips/src/tmp/legacy/usr/include -static -L/obj/mips.mips/src/tmp/legacy/usr/lib -o cc1plus-dummy main.o cp-lang.o c-opts.o call.o class.o cvt.o cxx-pretty-print.o decl.o decl2.o error.o except.o expr.o dump.o friend.o init.o lex.o mangle.o method.o name-lookup.o parser.o pt.o ptree.o repo.o rtti.o! search.o semantics.o tree.o typeck.o typeck2.o optimize.o cp-objcp-common.o cp-gimplify.o tree-mudflap.o /obj/mips.mips/src/tmp/src/gnu/usr.bin/cc/cc1plus/../cc_int/libbackend.a /obj/mips.mips/src/tmp/src/gnu/usr.bin/cc/cc1plus/../libcpp/libcpp.a /obj/mips.mips/src/tmp/src/gnu/usr.bin/cc/cc1plus/../libdecnumber/libdecnumber.a /obj/mips.mips/src/tmp/src/gnu/usr.bin/cc/cc1plus/../libiberty/libiberty.a -legacy typeck.o(.text+0x826c): In function `build_binary_op': : undefined reference to `TREE_OVERFLOW_P' typeck.o(.text+0x8282): In function `build_binary_op': : undefined reference to `TREE_OVERFLOW_P' typeck.o(.text+0x828e): In function `build_binary_op': : undefined reference to `TREE_OVERFLOW_P' *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/usr.bin/cc/cc1plus *** Error code 1 Stop. bmake[2]: stopped in /src/gnu/usr.bin/cc *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-15 17:05:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-15 17:05:25 - ERROR: failed to build world TB --- 2013-11-15 17:05:25 - 422.95 user 61.48 system 522.88 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 15 17:14:30 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 810DC459; Fri, 15 Nov 2013 17:14:30 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4969027E4; Fri, 15 Nov 2013 17:14:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAFHEQBE076267; Fri, 15 Nov 2013 12:14:26 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAFHEQVp076266; Fri, 15 Nov 2013 17:14:26 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 15 Nov 2013 17:14:26 GMT Message-Id: <201311151714.rAFHEQVp076266@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 17:14:30 -0000 TB --- 2013-11-15 17:05:30 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-15 17:05:30 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-15 17:05:30 - starting HEAD tinderbox run for mips64/mips TB --- 2013-11-15 17:05:30 - cleaning the object tree TB --- 2013-11-15 17:05:30 - /usr/local/bin/svn stat /src TB --- 2013-11-15 17:05:34 - At svn revision 258162 TB --- 2013-11-15 17:05:35 - building world TB --- 2013-11-15 17:05:35 - CROSS_BUILD_TESTING=YES TB --- 2013-11-15 17:05:35 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-15 17:05:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-15 17:05:35 - SRCCONF=/dev/null TB --- 2013-11-15 17:05:35 - TARGET=mips TB --- 2013-11-15 17:05:35 - TARGET_ARCH=mips64 TB --- 2013-11-15 17:05:35 - TZ=UTC TB --- 2013-11-15 17:05:35 - __MAKE_CONF=/dev/null TB --- 2013-11-15 17:05:35 - cd /src TB --- 2013-11-15 17:05:35 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Nov 15 17:05:41 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools [...] cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/mips.mips64/src/tmp/usr\" -DCROSS_COMPILE -DMIPS_ABI_DEFAULT=ABI_64 -I/obj/mips.mips64/src/tmp/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcclibs/libdecnumber -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -std=gnu89 -I/obj/mips.mips64/src/tmp/legacy/usr/include -c /src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/tree-mudflap.c cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/mips.mips64/src/tmp/usr\" -DCROSS_COMPILE -DMIPS_ABI_DEFAULT=ABI_64 -I/obj/mips.mips64/src/tmp/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcclibs/libdecnumber -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -std=gnu89 -I/obj/mips.mips64/src/tmp/legacy/usr/include -static -L/obj/mips.mips64/src/tmp/legacy/usr/lib -o cc1plus-dummy main.o cp-lang.o c-opts.o call.o class.o cvt.o cxx-pretty-print.o decl.o decl2.o error.o except.o expr.o dump.o friend.o init.o lex.o mangle.o method.o name-lookup.o parser.o pt.o ptree.o repo.o rtti.o search.o semantics.o tree.o! typeck.o typeck2.o optimize.o cp-objcp-common.o cp-gimplify.o tree-mudflap.o /obj/mips.mips64/src/tmp/src/gnu/usr.bin/cc/cc1plus/../cc_int/libbackend.a /obj/mips.mips64/src/tmp/src/gnu/usr.bin/cc/cc1plus/../libcpp/libcpp.a /obj/mips.mips64/src/tmp/src/gnu/usr.bin/cc/cc1plus/../libdecnumber/libdecnumber.a /obj/mips.mips64/src/tmp/src/gnu/usr.bin/cc/cc1plus/../libiberty/libiberty.a -legacy typeck.o(.text+0x826c): In function `build_binary_op': : undefined reference to `TREE_OVERFLOW_P' typeck.o(.text+0x8282): In function `build_binary_op': : undefined reference to `TREE_OVERFLOW_P' typeck.o(.text+0x828e): In function `build_binary_op': : undefined reference to `TREE_OVERFLOW_P' *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/usr.bin/cc/cc1plus *** Error code 1 Stop. bmake[2]: stopped in /src/gnu/usr.bin/cc *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-15 17:14:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-15 17:14:26 - ERROR: failed to build world TB --- 2013-11-15 17:14:26 - 422.86 user 76.12 system 535.53 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 15 17:16:12 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B0195CB; Fri, 15 Nov 2013 17:16:12 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 031942816; Fri, 15 Nov 2013 17:16:11 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAFGugN7053328; Fri, 15 Nov 2013 11:56:42 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAFGugqv053325; Fri, 15 Nov 2013 16:56:42 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 15 Nov 2013 16:56:42 GMT Message-Id: <201311151656.rAFGugqv053325@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 17:16:12 -0000 TB --- 2013-11-15 16:47:50 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-15 16:47:50 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-15 16:47:50 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-11-15 16:47:50 - cleaning the object tree TB --- 2013-11-15 16:47:50 - /usr/local/bin/svn stat /src TB --- 2013-11-15 16:47:54 - At svn revision 258162 TB --- 2013-11-15 16:47:55 - building world TB --- 2013-11-15 16:47:55 - CROSS_BUILD_TESTING=YES TB --- 2013-11-15 16:47:55 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-15 16:47:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-15 16:47:55 - SRCCONF=/dev/null TB --- 2013-11-15 16:47:55 - TARGET=ia64 TB --- 2013-11-15 16:47:55 - TARGET_ARCH=ia64 TB --- 2013-11-15 16:47:55 - TZ=UTC TB --- 2013-11-15 16:47:55 - __MAKE_CONF=/dev/null TB --- 2013-11-15 16:47:55 - cd /src TB --- 2013-11-15 16:47:55 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Nov 15 16:48:01 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools [...] cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/ia64.ia64/src/tmp/usr\" -DCROSS_COMPILE -I/obj/ia64.ia64/src/tmp/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcclibs/libdecnumber -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -std=gnu89 -I/obj/ia64.ia64/src/tmp/legacy/usr/include -c /src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/tree-mudflap.c cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/ia64.ia64/src/tmp/usr\" -DCROSS_COMPILE -I/obj/ia64.ia64/src/tmp/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcclibs/libdecnumber -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -std=gnu89 -I/obj/ia64.ia64/src/tmp/legacy/usr/include -static -L/obj/ia64.ia64/src/tmp/legacy/usr/lib -o cc1plus-dummy main.o cp-lang.o c-opts.o call.o class.o cvt.o cxx-pretty-print.o decl.o decl2.o error.o except.o expr.o dump.o friend.o init.o lex.o mangle.o method.o name-lookup.o parser.o pt.o ptree.o repo.o rtti.o search.o semantics.o tree.o typeck.o typeck2.o optimize.o cp-! objcp-common.o cp-gimplify.o tree-mudflap.o /obj/ia64.ia64/src/tmp/src/gnu/usr.bin/cc/cc1plus/../cc_int/libbackend.a /obj/ia64.ia64/src/tmp/src/gnu/usr.bin/cc/cc1plus/../libcpp/libcpp.a /obj/ia64.ia64/src/tmp/src/gnu/usr.bin/cc/cc1plus/../libdecnumber/libdecnumber.a /obj/ia64.ia64/src/tmp/src/gnu/usr.bin/cc/cc1plus/../libiberty/libiberty.a -legacy typeck.o(.text+0x821e): In function `build_binary_op': : undefined reference to `TREE_OVERFLOW_P' typeck.o(.text+0x8234): In function `build_binary_op': : undefined reference to `TREE_OVERFLOW_P' typeck.o(.text+0x8240): In function `build_binary_op': : undefined reference to `TREE_OVERFLOW_P' *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/usr.bin/cc/cc1plus *** Error code 1 Stop. bmake[2]: stopped in /src/gnu/usr.bin/cc *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-15 16:56:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-15 16:56:42 - ERROR: failed to build world TB --- 2013-11-15 16:56:42 - 427.78 user 59.34 system 531.62 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 15 17:26:47 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 613B0C90; Fri, 15 Nov 2013 17:26:47 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 29B6428B1; Fri, 15 Nov 2013 17:26:46 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAFHQknu019395; Fri, 15 Nov 2013 12:26:46 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAFHQkNi019394; Fri, 15 Nov 2013 17:26:46 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 15 Nov 2013 17:26:46 GMT Message-Id: <201311151726.rAFHQkNi019394@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 17:26:47 -0000 TB --- 2013-11-15 17:14:26 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-15 17:14:26 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-15 17:14:26 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-11-15 17:14:26 - cleaning the object tree TB --- 2013-11-15 17:14:26 - /usr/local/bin/svn stat /src TB --- 2013-11-15 17:14:30 - At svn revision 258162 TB --- 2013-11-15 17:14:31 - building world TB --- 2013-11-15 17:14:31 - CROSS_BUILD_TESTING=YES TB --- 2013-11-15 17:14:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-15 17:14:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-15 17:14:31 - SRCCONF=/dev/null TB --- 2013-11-15 17:14:31 - TARGET=powerpc TB --- 2013-11-15 17:14:31 - TARGET_ARCH=powerpc TB --- 2013-11-15 17:14:31 - TZ=UTC TB --- 2013-11-15 17:14:31 - __MAKE_CONF=/dev/null TB --- 2013-11-15 17:14:31 - cd /src TB --- 2013-11-15 17:14:31 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Nov 15 17:14:38 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools [...] /src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config/freebsd.h:77:1: warning: this is the location of the previous definition cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/powerpc.powerpc/src/tmp/usr\" -DCROSS_COMPILE -I/obj/powerpc.powerpc/src/tmp/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcclibs/libdecnumber -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -std=gnu89 -I/obj/powerpc.powerpc/src/tmp/legacy/usr/include -static -L/obj/powerpc.powerpc/src/tmp/legacy/usr/lib -o cc1plus-dummy main.o cp-lang.o c-opts.o call.o class.o cvt.o cxx-pretty-print.o decl.o decl2.o error.o except.o expr.o dump.o friend.o init.o lex.o mangle.o method.o name-lookup.o parser.o pt.o ptree.o repo.o rtti.o search.o semantics.o tree.o typeck.o ! typeck2.o optimize.o cp-objcp-common.o cp-gimplify.o tree-mudflap.o /obj/powerpc.powerpc/src/tmp/src/gnu/usr.bin/cc/cc1plus/../cc_int/libbackend.a /obj/powerpc.powerpc/src/tmp/src/gnu/usr.bin/cc/cc1plus/../libcpp/libcpp.a /obj/powerpc.powerpc/src/tmp/src/gnu/usr.bin/cc/cc1plus/../libdecnumber/libdecnumber.a /obj/powerpc.powerpc/src/tmp/src/gnu/usr.bin/cc/cc1plus/../libiberty/libiberty.a -legacy typeck.o(.text+0x821c): In function `build_binary_op': : undefined reference to `TREE_OVERFLOW_P' typeck.o(.text+0x8232): In function `build_binary_op': : undefined reference to `TREE_OVERFLOW_P' typeck.o(.text+0x823e): In function `build_binary_op': : undefined reference to `TREE_OVERFLOW_P' *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/usr.bin/cc/cc1plus *** Error code 1 Stop. bmake[2]: stopped in /src/gnu/usr.bin/cc *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-15 17:26:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-15 17:26:45 - ERROR: failed to build world TB --- 2013-11-15 17:26:45 - 617.94 user 79.35 system 739.57 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 15 17:40:11 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0AB83237; Fri, 15 Nov 2013 17:40:11 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C7B14299A; Fri, 15 Nov 2013 17:40:10 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAFHe9Bd013776; Fri, 15 Nov 2013 12:40:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAFHe9cD013774; Fri, 15 Nov 2013 17:40:09 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 15 Nov 2013 17:40:09 GMT Message-Id: <201311151740.rAFHe9cD013774@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 17:40:11 -0000 TB --- 2013-11-15 17:26:46 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-15 17:26:46 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-15 17:26:46 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-11-15 17:26:46 - cleaning the object tree TB --- 2013-11-15 17:26:46 - /usr/local/bin/svn stat /src TB --- 2013-11-15 17:26:49 - At svn revision 258162 TB --- 2013-11-15 17:26:50 - building world TB --- 2013-11-15 17:26:50 - CROSS_BUILD_TESTING=YES TB --- 2013-11-15 17:26:50 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-15 17:26:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-15 17:26:50 - SRCCONF=/dev/null TB --- 2013-11-15 17:26:50 - TARGET=powerpc TB --- 2013-11-15 17:26:50 - TARGET_ARCH=powerpc64 TB --- 2013-11-15 17:26:50 - TZ=UTC TB --- 2013-11-15 17:26:50 - __MAKE_CONF=/dev/null TB --- 2013-11-15 17:26:50 - cd /src TB --- 2013-11-15 17:26:50 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Nov 15 17:26:57 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools [...] /src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config/freebsd.h:77:1: warning: this is the location of the previous definition cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/powerpc.powerpc64/src/tmp/usr\" -DCROSS_COMPILE -I/obj/powerpc.powerpc64/src/tmp/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcclibs/libdecnumber -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -std=gnu89 -I/obj/powerpc.powerpc64/src/tmp/legacy/usr/include -static -L/obj/powerpc.powerpc64/src/tmp/legacy/usr/lib -o cc1plus-dummy main.o cp-lang.o c-opts.o call.o class.o cvt.o cxx-pretty-print.o decl.o decl2.o error.o except.o expr.o dump.o friend.o init.o lex.o mangle.o method.o name-lookup.o parser.o pt.o ptree.o repo.o rtti.o search.o semantics.o tree.o t! ypeck.o typeck2.o optimize.o cp-objcp-common.o cp-gimplify.o tree-mudflap.o /obj/powerpc.powerpc64/src/tmp/src/gnu/usr.bin/cc/cc1plus/../cc_int/libbackend.a /obj/powerpc.powerpc64/src/tmp/src/gnu/usr.bin/cc/cc1plus/../libcpp/libcpp.a /obj/powerpc.powerpc64/src/tmp/src/gnu/usr.bin/cc/cc1plus/../libdecnumber/libdecnumber.a /obj/powerpc.powerpc64/src/tmp/src/gnu/usr.bin/cc/cc1plus/../libiberty/libiberty.a -legacy typeck.o(.text+0x821c): In function `build_binary_op': : undefined reference to `TREE_OVERFLOW_P' typeck.o(.text+0x8232): In function `build_binary_op': : undefined reference to `TREE_OVERFLOW_P' typeck.o(.text+0x823e): In function `build_binary_op': : undefined reference to `TREE_OVERFLOW_P' *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/usr.bin/cc/cc1plus *** Error code 1 Stop. bmake[2]: stopped in /src/gnu/usr.bin/cc *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-15 17:40:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-15 17:40:09 - ERROR: failed to build world TB --- 2013-11-15 17:40:09 - 631.39 user 127.63 system 803.65 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 15 17:48:40 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D0BBB4B6; Fri, 15 Nov 2013 17:48:40 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 99F882A14; Fri, 15 Nov 2013 17:48:40 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAFHmdjA068826; Fri, 15 Nov 2013 12:48:39 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAFHmdeX068823; Fri, 15 Nov 2013 17:48:39 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 15 Nov 2013 17:48:39 GMT Message-Id: <201311151748.rAFHmdeX068823@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 17:48:40 -0000 TB --- 2013-11-15 17:40:10 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-15 17:40:10 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-15 17:40:10 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-11-15 17:40:10 - cleaning the object tree TB --- 2013-11-15 17:40:10 - /usr/local/bin/svn stat /src TB --- 2013-11-15 17:40:13 - At svn revision 258162 TB --- 2013-11-15 17:40:14 - building world TB --- 2013-11-15 17:40:14 - CROSS_BUILD_TESTING=YES TB --- 2013-11-15 17:40:14 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-15 17:40:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-15 17:40:14 - SRCCONF=/dev/null TB --- 2013-11-15 17:40:14 - TARGET=sparc64 TB --- 2013-11-15 17:40:14 - TARGET_ARCH=sparc64 TB --- 2013-11-15 17:40:14 - TZ=UTC TB --- 2013-11-15 17:40:14 - __MAKE_CONF=/dev/null TB --- 2013-11-15 17:40:14 - cd /src TB --- 2013-11-15 17:40:14 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Nov 15 17:40:22 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools [...] cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/sparc64.sparc64/src/tmp/usr\" -DCROSS_COMPILE -I/obj/sparc64.sparc64/src/tmp/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcclibs/libdecnumber -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -std=gnu89 -I/obj/sparc64.sparc64/src/tmp/legacy/usr/include -c /src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/tree-mudflap.c cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/sparc64.sparc64/src/tmp/usr\" -DCROSS_COMPILE -I/obj/sparc64.sparc64/src/tmp/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcclibs/libdecnumber -I/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -std=gnu89 -I/obj/sparc64.sparc64/src/tmp/legacy/usr/include -static -L/obj/sparc64.sparc64/src/tmp/legacy/usr/lib -o cc1plus-dummy main.o cp-lang.o c-opts.o call.o class.o cvt.o cxx-pretty-print.o decl.o decl2.o error.o except.o expr.o dump.o friend.o init.o lex.o mangle.o method.o name-lookup.o parser.o pt.o ptree.o repo.o rtti.o search.o semantics.o tree.o typeck.o ! typeck2.o optimize.o cp-objcp-common.o cp-gimplify.o tree-mudflap.o /obj/sparc64.sparc64/src/tmp/src/gnu/usr.bin/cc/cc1plus/../cc_int/libbackend.a /obj/sparc64.sparc64/src/tmp/src/gnu/usr.bin/cc/cc1plus/../libcpp/libcpp.a /obj/sparc64.sparc64/src/tmp/src/gnu/usr.bin/cc/cc1plus/../libdecnumber/libdecnumber.a /obj/sparc64.sparc64/src/tmp/src/gnu/usr.bin/cc/cc1plus/../libiberty/libiberty.a -legacy typeck.o(.text+0x8202): In function `build_binary_op': : undefined reference to `TREE_OVERFLOW_P' typeck.o(.text+0x8218): In function `build_binary_op': : undefined reference to `TREE_OVERFLOW_P' typeck.o(.text+0x8224): In function `build_binary_op': : undefined reference to `TREE_OVERFLOW_P' *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/usr.bin/cc/cc1plus *** Error code 1 Stop. bmake[2]: stopped in /src/gnu/usr.bin/cc *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-15 17:48:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-15 17:48:39 - ERROR: failed to build world TB --- 2013-11-15 17:48:39 - 384.95 user 83.78 system 509.52 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Nov 16 04:46:21 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D15BF5D0 for ; Sat, 16 Nov 2013 04:46:21 +0000 (UTC) Received: from mail.jrv.org (adsl-70-243-84-11.dsl.austtx.swbell.net [70.243.84.11]) by mx1.freebsd.org (Postfix) with ESMTP id AA3B52BA5 for ; Sat, 16 Nov 2013 04:46:20 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.jrv.org (Postfix) with ESMTP id DA1071CE002 for ; Fri, 15 Nov 2013 22:37:05 -0600 (CST) X-Virus-Scanned: amavisd-new at zimbra.housenet.jrv Received: from mail.jrv.org ([127.0.0.1]) by localhost (zimbra.housenet.jrv [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8VaxY8bcVPa for ; Fri, 15 Nov 2013 22:37:05 -0600 (CST) Received: from [10.0.2.15] (cielo.housenet.jrv [192.168.3.141]) by mail.jrv.org (Postfix) with ESMTPSA id 501971CE001 for ; Fri, 15 Nov 2013 22:37:05 -0600 (CST) Message-ID: <5286F670.2050305@jrv.org> Date: Fri, 15 Nov 2013 22:37:04 -0600 From: "James R. Van Artsdalen" User-Agent: Mozilla/5.0 (Windows NT 5.0; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: current@freebsd.org Subject: Slow boot with 256GB of RAM? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2013 04:46:21 -0000 Asus Z9PA-U8 motherboard, 256GB of RAM, 2.4 GHz Xeon E5-2695 v2, FreeBSD 11.0-CURRENT r258092 There is a two minute pause when booting, after the loader's SMAP display and the initial kernel output, Does anyone know what's going on here? Even that much RAM shouldn't take that much time to clear. From owner-freebsd-current@FreeBSD.ORG Sat Nov 16 04:48:43 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E9A846F8 for ; Sat, 16 Nov 2013 04:48:43 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id C70502BC2 for ; Sat, 16 Nov 2013 04:48:42 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.108.129]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 4000A1BE79 for ; Sat, 16 Nov 2013 04:48:36 +0000 (UTC) Message-ID: <5286F923.6060602@allanjude.com> Date: Fri, 15 Nov 2013 23:48:35 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Slow boot with 256GB of RAM? References: <5286F670.2050305@jrv.org> In-Reply-To: <5286F670.2050305@jrv.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="b6t2Mi8oJQR6L96e9Ml1elIWNhPx3LWnm" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2013 04:48:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --b6t2Mi8oJQR6L96e9Ml1elIWNhPx3LWnm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-11-15 23:37, James R. Van Artsdalen wrote: > Asus Z9PA-U8 motherboard, 256GB of RAM, 2.4 GHz Xeon E5-2695 v2, FreeBS= D > 11.0-CURRENT r258092 > > There is a two minute pause when booting, after the loader's SMAP > display and the initial kernel output, > > Does anyone know what's going on here? Even that much RAM shouldn't > take that much time to clear. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" It is a known issue (I have a few E5-2620s with 96 and 144gb of ram) There was talk at MeetBSD last year about making at least output a dot for each 1 or 8gb of something so you knew it was at least doing something, not sure whatever happened to that. It would be nice if it didn't that that long --=20 Allan Jude --b6t2Mi8oJQR6L96e9Ml1elIWNhPx3LWnm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJShvknAAoJEJrBFpNRJZKfhrgQALDhUPyUTUMHtnLfip7/2EeK VTVYnVQjmS2+/msNvtmeRJ1r7eFHV8JOJanojB5HPQ7aMp7+8pT1LHxpMdgfmLUk Ls4FUUFAD1uRj/40AQJL7DDb6OrNVUfy7xLu2kulYQwJH7yRmbZUI8dka+QwmCuT AzPl0K5kPxA3AmXcesSe1eIT18VhorTF4hRuW9Fhc3h/7K3uDws6RtwLTIocsMlr UdsLu8vMVb76z4RojbNbTPcD/7MkcVss5TmTqI2yNFqIrDLb6HkWzIzMDnKFiYVj DmDO4NUNwawQL9SGVKSeMZmp809kQRiznW0Z+mfwkxdhscbwj80sjx6H1jcMWsPa 0ynND2rZq01ptYGTPO8IjXNii3Nt2uuZEw3f5jC+EGKxmAEb/kIGT+f/o9bdAPw5 7ELdsuTrkUINny0ig78XY2wnrPoRChWu8Dscs1ip5/UMnhnOLyfvuEI5BwVX1LeZ JV7poft86i6QslequylCn0TA2nOa18FghAp1RiJcqugcDh0i7UAsG2sfg4rxGapi qDI6aaUFEE0HbMSNd8QqH1MtxzJJjxYJOgX13JK9Q+xyB97DjwiIKCZQMzsWMhKw cBMS/Drsl8Yyd6HayABpkLw2898VzqzkBQaqTZ3asiTwU8IiLYUA+3mOAGjhS0yX dpUw322d//0gvFP9GQGQ =l/G6 -----END PGP SIGNATURE----- --b6t2Mi8oJQR6L96e9Ml1elIWNhPx3LWnm-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 16 06:00:44 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A127FE for ; Sat, 16 Nov 2013 06:00:44 +0000 (UTC) Received: from mail.s1.d2ux.org (static.209.96.9.5.clients.your-server.de [5.9.96.209]) by mx1.freebsd.org (Postfix) with ESMTP id 1ADA82EA8 for ; Sat, 16 Nov 2013 06:00:43 +0000 (UTC) Received: from mail.s1.d2ux.org (mail [10.0.0.3]) by mail.s1.d2ux.org (Postfix) with ESMTP id 5B67984F260E; Sat, 16 Nov 2013 06:51:08 +0100 (CET) Received: from mail.s1.d2ux.org ([10.0.0.3]) by mail.s1.d2ux.org (mail.s1.d2ux.org [10.0.0.3]) (amavisd-new, port 10024) with ESMTP id tddEDsN54j-Y; Sat, 16 Nov 2013 06:51:06 +0100 (CET) Received: from workstation.local (p5DDA961D.dip0.t-ipconnect.de [93.218.150.29]) by mail.s1.d2ux.org (Postfix) with ESMTPSA id 58CC384F257E; Sat, 16 Nov 2013 06:51:06 +0100 (CET) Message-ID: <5287071B.3020209@petermann-it.de> Date: Sat, 16 Nov 2013 06:48:11 +0100 From: Matthias Petermann User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "James R. Van Artsdalen" Subject: Re: Slow boot with 256GB of RAM? References: <5286F670.2050305@jrv.org> In-Reply-To: <5286F670.2050305@jrv.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2013 06:00:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello James, Am 16.11.2013 05:37, schrieb James R. Van Artsdalen: > Asus Z9PA-U8 motherboard, 256GB of RAM, 2.4 GHz Xeon E5-2695 v2, > FreeBSD 11.0-CURRENT r258092 > > There is a two minute pause when booting, after the loader's SMAP > display and the initial kernel output, > > Does anyone know what's going on here? Even that much RAM > shouldn't take that much time to clear. in an earlier discussion at FreeBSD Forums[1] it looks like this is related to some early stage memory test which is performed. It can be disabled by adding hw.memtest.tests="0" to /boot/loader.conf. For my 32GB machine this helped. Best regards, Matthias [1] http://forums.freebsd.org/showthread.php?t=12705 - -- Matthias Petermann | www.petermann-it.de GnuPG: 0x5C3E6D75 | 5930 86EF 7965 2BBA 6572 C3D7 7B1D A3C3 5C3E 6D75 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJShwcbAAoJEHsdo8NcPm11kTMQAI3sxsltJ7Se/CaZ7QsMmkFy THULbdDLEAIJYBhfgfMh+wsK4DNu5uj+u8uL52hP2MjbV7MPOWX27xUYrGjbC1HZ /QIcz+sAXvxV3eclLhlLuNtdZIh8U2ORQ20VleT/wsoAw0UuP4Bu/+akiVRWiEyF /FfGfFolczMrcNQpt4Y3XbTaADTRVsx9ZmU7ZRDg+KKt+oRPGsngo75GwkCiiwVg Ew+nSjlUB4pXiPW5teaG6asg2tLIgArVilJE7PP8mPGsz0rBf/gArGCyw3OweYzv gmJ13nfVrOWAlz9ZYL8KFg1eON4qb2G3Trjl3g4rr/7vYoi2XXz19zevkxv/kDKi xJCtHzVGFW0Dh6QN0M8tHc5aqb3+kLsulxEbDPDcmWGw7DPeFfRXYx8VNXLGphJC +f1Br/WUa0K6BiRgn+yKHS9IX6P5s4aY2xyCMmcRoH7Q5YjCdKHOrdtqKwjMIPRm BL0n+Viwwcu2qWmpTYNfQpcIRhAhc3F1v6RPxa8t3WYopBopkllFb/z8AbtWr8fF kuCcEmw0PdKxSQgHHdTmy5UW2f+pDvCX3h5qX9inks8PMq1JWYwNz+7WTfDb4Bvn pHWLE3RM78DpTDGXRuyoiwZEqh/KzHbwIw7pqWApjgINc7nifaNCRoYbxKSYVJ2s TfnjxAn2tXfe5nLqA00E =ePIV -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sat Nov 16 06:21:47 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D51932D for ; Sat, 16 Nov 2013 06:21:47 +0000 (UTC) Received: from mail-ee0-x22e.google.com (mail-ee0-x22e.google.com [IPv6:2a00:1450:4013:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ECDE12F62 for ; Sat, 16 Nov 2013 06:21:46 +0000 (UTC) Received: by mail-ee0-f46.google.com with SMTP id c4so1463035eek.33 for ; Fri, 15 Nov 2013 22:21:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=Re5c+RWUOvg44o+BHZTGb61Uc+lTbEtMBEx0utDfITM=; b=FQgSIIw/8OaVts2XRRdfW1VwSbWIBUicVmjYB9GUolNpmfQ42SulJHAhRpXOcvI41W 6sCdjCkq8kEiFbnqkBGf0ONPIbEjFZFS4OvPZOIKOC6H2mjFiEH9O80sXC8I5V++5AEA ye83uoFTstOThgKD+YDWMWLiGubwECuAV8kQKXAFxRsCAxKykWjuYct7mylGqQnSLR5e FjQmgAIk8g4q0UX+BSTIjm0s92InvlNc1Ft9COmySRriuDc2sE8KWASvTnqbT6UDuSld Sd9zIHox1KJ8MfIhTF+k0oQn/a2+PgTHqxGmS5Dtc4OidZEhz0DgS5wGL71+LVscF6+G B7wQ== X-Received: by 10.14.6.73 with SMTP id 49mr2859144eem.117.1384582905216; Fri, 15 Nov 2013 22:21:45 -0800 (PST) Received: from laptop.minsk.domain ([178.125.203.241]) by mx.google.com with ESMTPSA id 44sm13495431eek.5.2013.11.15.22.21.44 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Fri, 15 Nov 2013 22:21:44 -0800 (PST) Date: Sat, 16 Nov 2013 09:22:11 +0300 From: "Sergey V. Dyatko" To: current@freebsd.org Subject: Re: Slow boot with 256GB of RAM? Message-ID: <20131116092211.3988d001@laptop.minsk.domain> In-Reply-To: <5287071B.3020209@petermann-it.de> References: <5286F670.2050305@jrv.org> <5287071B.3020209@petermann-it.de> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2013 06:21:47 -0000 On Sat, 16 Nov 2013 06:48:11 +0100 Matthias Petermann wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello James, > > Am 16.11.2013 05:37, schrieb James R. Van Artsdalen: > > Asus Z9PA-U8 motherboard, 256GB of RAM, 2.4 GHz Xeon E5-2695 v2, > > FreeBSD 11.0-CURRENT r258092 > > > > There is a two minute pause when booting, after the loader's SMAP > > display and the initial kernel output, > > > > Does anyone know what's going on here? Even that much RAM > > shouldn't take that much time to clear. > > in an earlier discussion at FreeBSD Forums[1] it looks like this is > related to some early stage memory test which is performed. > > It can be disabled by adding > > hw.memtest.tests="0" > > to /boot/loader.conf. For my 32GB machine this helped. +1. (box with 128GB ram) > > > Best regards, > Matthias > > > [1] http://forums.freebsd.org/showthread.php?t=12705 > > - -- > Matthias Petermann | www.petermann-it.de > GnuPG: 0x5C3E6D75 | 5930 86EF 7965 2BBA 6572 C3D7 7B1D A3C3 5C3E 6D75 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (FreeBSD) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJShwcbAAoJEHsdo8NcPm11kTMQAI3sxsltJ7Se/CaZ7QsMmkFy > THULbdDLEAIJYBhfgfMh+wsK4DNu5uj+u8uL52hP2MjbV7MPOWX27xUYrGjbC1HZ > /QIcz+sAXvxV3eclLhlLuNtdZIh8U2ORQ20VleT/wsoAw0UuP4Bu/+akiVRWiEyF > /FfGfFolczMrcNQpt4Y3XbTaADTRVsx9ZmU7ZRDg+KKt+oRPGsngo75GwkCiiwVg > Ew+nSjlUB4pXiPW5teaG6asg2tLIgArVilJE7PP8mPGsz0rBf/gArGCyw3OweYzv > gmJ13nfVrOWAlz9ZYL8KFg1eON4qb2G3Trjl3g4rr/7vYoi2XXz19zevkxv/kDKi > xJCtHzVGFW0Dh6QN0M8tHc5aqb3+kLsulxEbDPDcmWGw7DPeFfRXYx8VNXLGphJC > +f1Br/WUa0K6BiRgn+yKHS9IX6P5s4aY2xyCMmcRoH7Q5YjCdKHOrdtqKwjMIPRm > BL0n+Viwwcu2qWmpTYNfQpcIRhAhc3F1v6RPxa8t3WYopBopkllFb/z8AbtWr8fF > kuCcEmw0PdKxSQgHHdTmy5UW2f+pDvCX3h5qX9inks8PMq1JWYwNz+7WTfDb4Bvn > pHWLE3RM78DpTDGXRuyoiwZEqh/KzHbwIw7pqWApjgINc7nifaNCRoYbxKSYVJ2s > TfnjxAn2tXfe5nLqA00E > =ePIV > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" -- wbr, tiger From owner-freebsd-current@FreeBSD.ORG Sat Nov 16 08:31:11 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 684292DD for ; Sat, 16 Nov 2013 08:31:11 +0000 (UTC) Received: from yoshi.bluerosetech.com (yoshi.bluerosetech.com [IPv6:2607:f2f8:a450::66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 52C682406 for ; Sat, 16 Nov 2013 08:31:11 +0000 (UTC) Received: from chombo.houseloki.net (unknown [IPv6:2601:7:1680:365:21c:c0ff:fe7f:96ee]) by yoshi.bluerosetech.com (Postfix) with ESMTPSA id 9C23EE606C for ; Sat, 16 Nov 2013 00:31:10 -0800 (PST) Received: from [IPv6:2601:7:1680:365:6948:f8a5:e3c:7d9d] (unknown [IPv6:2601:7:1680:365:6948:f8a5:e3c:7d9d]) by chombo.houseloki.net (Postfix) with ESMTPSA id 328A4BD3 for ; Sat, 16 Nov 2013 00:31:09 -0800 (PST) Message-ID: <52872D4F.9020707@bluerosetech.com> Date: Sat, 16 Nov 2013 00:31:11 -0800 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: current@freebsd.org Subject: Re: Slow boot with 256GB of RAM? References: <5286F670.2050305@jrv.org> <5287071B.3020209@petermann-it.de> <20131116092211.3988d001@laptop.minsk.domain> In-Reply-To: <20131116092211.3988d001@laptop.minsk.domain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2013 08:31:11 -0000 At the risk of facetiousness, the nice thing about FreeBSD is that you have to deal with this problem only a few times per year. ;) From owner-freebsd-current@FreeBSD.ORG Sat Nov 16 12:58:23 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 637A14E8; Sat, 16 Nov 2013 12:58:23 +0000 (UTC) Received: from mailrelay002.isp.belgacom.be (mailrelay002.isp.belgacom.be [195.238.6.175]) by mx1.freebsd.org (Postfix) with ESMTP id CF2512FAE; Sat, 16 Nov 2013 12:58:22 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnYGAGprh1Jbs6sV/2dsb2JhbABYDoJ5vT6Ce4EeF3SCJQEBBTocIxALDgoJJQ8qHgYBiBcBwSOPaQeEMQOYD5IOgmlAOw Received: from 21.171-179-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.179.171.21]) by relay.skynet.be with ESMTP; 16 Nov 2013 13:58:14 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.7/8.14.7) with ESMTP id rAGCwCGH072336; Sat, 16 Nov 2013 13:58:13 +0100 (CET) (envelope-from tijl@coosemans.org) Date: Sat, 16 Nov 2013 13:58:11 +0100 From: Tijl Coosemans To: Steve Kargl , gerald@FreeBSD.org Subject: Re: Are clang++ and libc++ compatible? Message-ID: <20131116135811.23b00fa3@kalimero.tijl.coosemans.org> In-Reply-To: <20131112224042.GA5050@troutmask.apl.washington.edu> References: <20131112163219.GA2834@troutmask.apl.washington.edu> <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> <20131112175556.GA3319@troutmask.apl.washington.edu> <20131112201922.GA4330@troutmask.apl.washington.edu> <20131112221946.78602db0@kalimero.tijl.coosemans.org> <20131112224042.GA5050@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2013 12:58:23 -0000 On Tue, 12 Nov 2013 14:40:42 -0800 Steve Kargl wrote: > On Tue, Nov 12, 2013 at 10:19:46PM +0100, Tijl Coosemans wrote: >> On Tue, 12 Nov 2013 12:19:22 -0800 Steve Kargl wrote: >>> This can't be good. And, unfortunately, testing math/octave shows >>> no better :( >>> >>> % octave >>> Segmentation fault (core dumped) >>> % ldd /usr/local/bin/octave-3.6.4 | grep ++ >>> libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 (0x3c92ec000) >>> libc++.so.1 => /usr/lib/libc++.so.1 (0x3c9801000) >> >> This could be because you enabled the OPENMP option in math/fftw3. > > Unfortuantely, that's not it. Just rebuilt fftw3 and octave still > dies. ldd shows that /usr/local/lib/octave/3.6.4/liboctinterp.so.1 > is bringing in both libc++ and libstdc++, but it is also linked > to 52 other libraries. USE_FORTRAN=yes currently implies USE_GCC=yes so the C++ code in math/octave links with libstdc++ while dependencies link with libc++. Gerald, is it possible to separate USE_FORTRAN from USE_GCC? From owner-freebsd-current@FreeBSD.ORG Sat Nov 16 14:52:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC63FC6C for ; Sat, 16 Nov 2013 14:52:59 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 986ED24B4 for ; Sat, 16 Nov 2013 14:52:59 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.108.129]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 1AB8F1E12F for ; Sat, 16 Nov 2013 14:52:57 +0000 (UTC) Message-ID: <528786C9.9070409@allanjude.com> Date: Sat, 16 Nov 2013 09:52:57 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Slow boot with 256GB of RAM? References: <5286F670.2050305@jrv.org> <5287071B.3020209@petermann-it.de> In-Reply-To: <5287071B.3020209@petermann-it.de> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2WgUTJ5XGQAuieQtimKGgcpjjfV0cHRGq" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2013 14:52:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2WgUTJ5XGQAuieQtimKGgcpjjfV0cHRGq Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-11-16 00:48, Matthias Petermann wrote: > Hello James, > > Am 16.11.2013 05:37, schrieb James R. Van Artsdalen: > > Asus Z9PA-U8 motherboard, 256GB of RAM, 2.4 GHz Xeon E5-2695 v2, > > FreeBSD 11.0-CURRENT r258092 > > > There is a two minute pause when booting, after the loader's SMAP > > display and the initial kernel output, > > > Does anyone know what's going on here? Even that much RAM > > shouldn't take that much time to clear. > > in an earlier discussion at FreeBSD Forums[1] it looks like this is > related to some early stage memory test which is performed. > > It can be disabled by adding > > hw.memtest.tests=3D"0" > > to /boot/loader.conf. For my 32GB machine this helped. > > > Best regards, > Matthias > > > [1] http://forums.freebsd.org/showthread.php?t=3D12705 > I see this was in the release notes for 9.0 and 8.3, but other than that, I don't see how anyone was supposed to find out about this Maybe it would make sense to print 'Starting memory test, set hw.memtest.test=3D0 to disable' before that starts, so anyone stuck waiting will have a hint about what to do. --=20 Allan Jude --2WgUTJ5XGQAuieQtimKGgcpjjfV0cHRGq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSh4bNAAoJEJrBFpNRJZKfBLoP/AmlredbuFjy4gRmGQrDngHW aekMqZzAkjSFEbfxWEMcX29+PQJao/osIYX24db3G8VCcK8NES/FMAVfiZCRLi3j mDcnUpAbSxZ3HeDgZADT7K+swDFxTjVwXvLTcwVsiuBs6h+A6ur8QPxFy0K9NLaV TOSsmbG5WGPKdBho5lTg4Vfx5M3OZV/XzEI7mxtS/gc4bCIW+53lMdqh32U/ZJXo VJYyAweQjVNb6+jVNfqgSv3uHG1s1KacyIgcp6c6p5eP/fjPjmdbihhexpaLQYqP sGDoMxrnjqZvVFBYbVI9LLsZ515UqxZ1o6CQyKS2LimxrB6duMLaakYFvFeelcBR +7taAFnVE160WKXU2eU8hp3GXBG4696huXoeEZhuNgjpkd7CmD4dRXwnWkna90kN UqiIoM57rN6enX6AywWrHRDChwHTyHW4uNSfZE2ieuCxvHG6Rfk8XuuXF2kQZAew +qK4HdzOappHhcQ7lSzxhRZVB4RtcxKK6+Ye58jixaixuQThtJ7f4lnMIbWOt/ia L2OZy/Y45weFSE+NNiLezayX8LY1iOf5+U7IaI6wi4qyGgKPhK43BvxAhG5ayrNk Ohpl4jiA6aCyiyHD67JJFA6oojOAglqW72hpqK1ocUaRghWPhMe8YUuRRkPAGX2w CZeexHkb1FaEXbR/fbkQ =Thz7 -----END PGP SIGNATURE----- --2WgUTJ5XGQAuieQtimKGgcpjjfV0cHRGq-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 16 16:55:05 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1D30400; Sat, 16 Nov 2013 16:55:05 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9006829EB; Sat, 16 Nov 2013 16:55:05 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id rAGGsuEA037253; Sat, 16 Nov 2013 08:54:56 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id rAGGstL1037252; Sat, 16 Nov 2013 08:54:55 -0800 (PST) (envelope-from sgk) Date: Sat, 16 Nov 2013 08:54:55 -0800 From: Steve Kargl To: Tijl Coosemans Subject: Re: Are clang++ and libc++ compatible? Message-ID: <20131116165455.GA37237@troutmask.apl.washington.edu> References: <20131112163219.GA2834@troutmask.apl.washington.edu> <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> <20131112175556.GA3319@troutmask.apl.washington.edu> <20131112201922.GA4330@troutmask.apl.washington.edu> <20131112221946.78602db0@kalimero.tijl.coosemans.org> <20131112224042.GA5050@troutmask.apl.washington.edu> <20131116135811.23b00fa3@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131116135811.23b00fa3@kalimero.tijl.coosemans.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org, gerald@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2013 16:55:05 -0000 On Sat, Nov 16, 2013 at 01:58:11PM +0100, Tijl Coosemans wrote: > On Tue, 12 Nov 2013 14:40:42 -0800 Steve Kargl wrote: > > On Tue, Nov 12, 2013 at 10:19:46PM +0100, Tijl Coosemans wrote: > >> On Tue, 12 Nov 2013 12:19:22 -0800 Steve Kargl wrote: > >>> This can't be good. And, unfortunately, testing math/octave shows > >>> no better :( > >>> > >>> % octave > >>> Segmentation fault (core dumped) > >>> % ldd /usr/local/bin/octave-3.6.4 | grep ++ > >>> libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 (0x3c92ec000) > >>> libc++.so.1 => /usr/lib/libc++.so.1 (0x3c9801000) > >> > >> This could be because you enabled the OPENMP option in math/fftw3. > > > > Unfortuantely, that's not it. Just rebuilt fftw3 and octave still > > dies. ldd shows that /usr/local/lib/octave/3.6.4/liboctinterp.so.1 > > is bringing in both libc++ and libstdc++, but it is also linked > > to 52 other libraries. > > USE_FORTRAN=yes currently implies USE_GCC=yes so the C++ code in > math/octave links with libstdc++ while dependencies link with libc++. > Gerald, is it possible to separate USE_FORTRAN from USE_GCC? This isn't the problem. gfortran does not pull libstdc++.so into the build. As pointed out in another email, libGL, libGLU, fltk, and libgraphite2 all were linked to libc++ and libstdc++. Recompiling those ports with USE_GCC=any, fixed octave. -- Steve From owner-freebsd-current@FreeBSD.ORG Sat Nov 16 17:14:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 90E696B2; Sat, 16 Nov 2013 17:14:58 +0000 (UTC) Received: from mailrelay012.isp.belgacom.be (mailrelay012.isp.belgacom.be [195.238.6.179]) by mx1.freebsd.org (Postfix) with ESMTP id EC59F2AC9; Sat, 16 Nov 2013 17:14:57 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgQAISmh1Jbs6sV/2dsb2JhbABZDoFjBoEQvT+Ce4EeF3SCJQEBBTocIxALDgoJJQ8qHgaIGAHBHI4dEQGBOgeEMQOYD5IOgmlAO4E1 Received: from 21.171-179-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.179.171.21]) by relay.skynet.be with ESMTP; 16 Nov 2013 18:14:49 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.7/8.14.7) with ESMTP id rAGHEmAq076693; Sat, 16 Nov 2013 18:14:48 +0100 (CET) (envelope-from tijl@coosemans.org) Date: Sat, 16 Nov 2013 18:14:47 +0100 From: Tijl Coosemans To: Steve Kargl Subject: Re: Are clang++ and libc++ compatible? Message-ID: <20131116181447.5e9eada4@kalimero.tijl.coosemans.org> In-Reply-To: <20131116165455.GA37237@troutmask.apl.washington.edu> References: <20131112163219.GA2834@troutmask.apl.washington.edu> <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> <20131112175556.GA3319@troutmask.apl.washington.edu> <20131112201922.GA4330@troutmask.apl.washington.edu> <20131112221946.78602db0@kalimero.tijl.coosemans.org> <20131112224042.GA5050@troutmask.apl.washington.edu> <20131116135811.23b00fa3@kalimero.tijl.coosemans.org> <20131116165455.GA37237@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, gerald@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2013 17:14:58 -0000 On Sat, 16 Nov 2013 08:54:55 -0800 Steve Kargl wrote: > On Sat, Nov 16, 2013 at 01:58:11PM +0100, Tijl Coosemans wrote: >> On Tue, 12 Nov 2013 14:40:42 -0800 Steve Kargl wrote: >>> On Tue, Nov 12, 2013 at 10:19:46PM +0100, Tijl Coosemans wrote: >>>> On Tue, 12 Nov 2013 12:19:22 -0800 Steve Kargl wrote: >>>>> This can't be good. And, unfortunately, testing math/octave shows >>>>> no better :( >>>>> >>>>> % octave >>>>> Segmentation fault (core dumped) >>>>> % ldd /usr/local/bin/octave-3.6.4 | grep ++ >>>>> libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 (0x3c92ec000) >>>>> libc++.so.1 => /usr/lib/libc++.so.1 (0x3c9801000) >>>> >>>> This could be because you enabled the OPENMP option in math/fftw3. >>> >>> Unfortuantely, that's not it. Just rebuilt fftw3 and octave still >>> dies. ldd shows that /usr/local/lib/octave/3.6.4/liboctinterp.so.1 >>> is bringing in both libc++ and libstdc++, but it is also linked >>> to 52 other libraries. >> >> USE_FORTRAN=yes currently implies USE_GCC=yes so the C++ code in >> math/octave links with libstdc++ while dependencies link with libc++. >> Gerald, is it possible to separate USE_FORTRAN from USE_GCC? > > This isn't the problem. gfortran does not pull libstdc++.so into > the build. As pointed out in another email, libGL, libGLU, fltk, > and libgraphite2 all were linked to libc++ and libstdc++. Recompiling > those ports with USE_GCC=any, fixed octave. The math/octave Makefile has USE_FORTRAN=yes (FC=gfortran46). This currently implies USE_GCC=yes (CC=gcc46, CXX=g++46) which pulls in libstdc++. If this could be changed (i.e. FC=gfortran46, CC=cc, CXX=c++) you would not have to add USE_GCC to the dependencies. From owner-freebsd-current@FreeBSD.ORG Sat Nov 16 18:45:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 37878D53 for ; Sat, 16 Nov 2013 18:45:24 +0000 (UTC) Received: from mail.jrv.org (adsl-70-243-84-11.dsl.austtx.swbell.net [70.243.84.11]) by mx1.freebsd.org (Postfix) with ESMTP id 0B8322EF7 for ; Sat, 16 Nov 2013 18:45:23 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.jrv.org (Postfix) with ESMTP id 09AC012405B; Sat, 16 Nov 2013 12:37:08 -0600 (CST) X-Virus-Scanned: amavisd-new at zimbra.housenet.jrv Received: from mail.jrv.org ([127.0.0.1]) by localhost (zimbra.housenet.jrv [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qu0FGFGYlvMI; Sat, 16 Nov 2013 12:37:07 -0600 (CST) Received: from [10.0.2.15] (cielo.housenet.jrv [192.168.3.141]) by mail.jrv.org (Postfix) with ESMTPSA id 69B40124058; Sat, 16 Nov 2013 12:37:07 -0600 (CST) Message-ID: <5287BB44.4020104@jrv.org> Date: Sat, 16 Nov 2013 12:36:52 -0600 From: "James R. Van Artsdalen" User-Agent: Mozilla/5.0 (Windows NT 5.0; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Allan Jude Subject: Re: Slow boot with 256GB of RAM? References: <5286F670.2050305@jrv.org> <5287071B.3020209@petermann-it.de> <528786C9.9070409@allanjude.com> In-Reply-To: <528786C9.9070409@allanjude.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2013 18:45:24 -0000 On 11/16/2013 8:52 AM, Allan Jude wrote: > I see this was in the release notes for 9.0 and 8.3, but other than > that, I don't see how anyone was supposed to find out about this. > Maybe it would make sense to print 'Starting memory test, set > hw.memtest.test=0 to disable' before that starts, so anyone stuck > waiting will have a hint about what to do. It takes less effort to speed it up than to document that it is slow.. For now, in my sources, I've lengthened the testing stride to 64KB. A better fix would leave the cache on (don't fight the cache in a memory test - it is your friend! :-) and to group all writes and reads together in a larger chunk - say 16MB - so as to take advantage of write combining and cache line fetching. And add writes of address-specific values so address space aliasing can be detected. From owner-freebsd-current@FreeBSD.ORG Sat Nov 16 20:31:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A7D5E7B; Sat, 16 Nov 2013 20:31:51 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id CCAA12413; Sat, 16 Nov 2013 20:31:49 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.108.129]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id D904A1E447; Sat, 16 Nov 2013 20:31:44 +0000 (UTC) Message-ID: <5287D632.4010802@allanjude.com> Date: Sat, 16 Nov 2013 15:31:46 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-doc@FreeBSD.org Subject: Re: Slow boot with 256GB of RAM? References: <5286F670.2050305@jrv.org> <5287071B.3020209@petermann-it.de> <528786C9.9070409@allanjude.com> <5287BB44.4020104@jrv.org> In-Reply-To: <5287BB44.4020104@jrv.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2OV3aNrBgB8hMVDIugepxhdlE2rbebLNb" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2013 20:31:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2OV3aNrBgB8hMVDIugepxhdlE2rbebLNb Content-Type: multipart/mixed; boundary="------------090003010603070205020704" This is a multi-part message in MIME format. --------------090003010603070205020704 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-11-16 13:36, James R. Van Artsdalen wrote: > On 11/16/2013 8:52 AM, Allan Jude wrote: >> I see this was in the release notes for 9.0 and 8.3, but other than >> that, I don't see how anyone was supposed to find out about this.=20 >> Maybe it would make sense to print 'Starting memory test, set >> hw.memtest.test=3D0 to disable' before that starts, so anyone stuck >> waiting will have a hint about what to do.=20 A patch for the FAQ to add an entry about the hw.memtest.test=3D0 to spee= d up boot on machines with a lot of ram --=20 Allan Jude --------------090003010603070205020704 Content-Type: text/plain; charset=windows-1252; name="faq_memtest.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="faq_memtest.patch" Index: en_US.ISO8859-1/books/faq/book.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- en_US.ISO8859-1/books/faq/book.xml (revision 43198) +++ en_US.ISO8859-1/books/faq/book.xml (working copy) @@ -3669,6 +3669,26 @@ in &man.tunefs.8;. + + + + Why does &os; pause for a long time at boot when the + system has large amounts of ram? + + + + &os; does a short memory test early in the boot + process. This test usually only takes several seconds, + however if the system has many 10s or 100s of gigabytes + of memory it can take up to a few minutes. This test + can be disabled by setting the + hw.memtest.tests to + 0 in + /boot/loader.conf + + For more details, see &man.loader.conf.5;. + + =20 --------------090003010603070205020704-- --2OV3aNrBgB8hMVDIugepxhdlE2rbebLNb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSh9Y1AAoJEJrBFpNRJZKfQFEP/2ynL3EFHhS2mW8zQZf97LVy drVVobsQlnPiJLfPwvM762g34TAKhxVHbzjTKjDgbo+xPOXBP9WDgjgkA/xPuLpU IG7F3pGHq+F1WBkvxNJJG4bebkozkvUmiPPFMz2B+VUQpymzDOvoxepogK0MDQRj 4h+NCNLiIKD3Kt5CA47q1B27xiPSd+dDBYoBcvqnQ7iu8X7uX9p83gOA/6MU09XR fawGfS8FYCwcjM4RVuQMucH7B0aWg0yXRlnsbiH+2A1rzUcnhok0pgRPR5wLp/Q2 Q701bZYyzGe7ymHKse7/HbBDCCNVVfg4lD5rgcbXPaHniDOvHGjkwBAh5g6OCsP8 c+M8VSGHeOVGCR0TYUdr2Gs1eYu4A5PJn4prZPsMifaWDY/UnMF7CR70/vQaNZqg 6ipqsJonzwuAvlidqoyP6mXv7nW5cjYnypyOaX5rV+wRW+zn/kWDtsuG5gmu4mls c2+cGgzVIjJXBWWUZxXWW95WdbBPzea0dmg7N7zcI4fuv9R2v4pWtBP97PBBlVvP TNexmWoZAXqPGPh8EufsIepOIzPmL1of82oBLlJNAqe44qkVedI1IenQxiOJ+oEy CqeRSFrirU51+S/lIb1JD5Yhi0G0lAfzd2axjlnKYhpBRHHmcMy6XqjRPo50yaLE 8zAFv/XBnSav9c1r+Ns2 =8XJt -----END PGP SIGNATURE----- --2OV3aNrBgB8hMVDIugepxhdlE2rbebLNb-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 16 22:49:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4EA5D689 for ; Sat, 16 Nov 2013 22:49:38 +0000 (UTC) Received: from mail-qe0-x235.google.com (mail-qe0-x235.google.com [IPv6:2607:f8b0:400d:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0D71E290A for ; Sat, 16 Nov 2013 22:49:37 +0000 (UTC) Received: by mail-qe0-f53.google.com with SMTP id cy11so3202034qeb.12 for ; Sat, 16 Nov 2013 14:49:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GaxKsMcyvFmruKoVoPLRogrULasvOeEuq4cYammyq0Y=; b=t/iq+ExH6+FGizNJ1GW4YDgfLkfML4rB2IFzc/BS9WLbn+mcDqkPJ9019ir5f3H5eF Jr7qVhbTnihJUZSxjAENwVawbbMSByby9K9DXS8YKSYslb07JrszfjgwLfsWJEuGFsEQ 163rk5qzVRg/wgFDLdA15A46kry7u4JmND5XU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=GaxKsMcyvFmruKoVoPLRogrULasvOeEuq4cYammyq0Y=; b=CaWcjwH2v3zv3wmCZwYuGDw+I4/Jya1WmIc0hTnoHEHTkJCe7W9hvTp1IsOALjWg+V kFGdeZBfjr+hq1bIeCRmn04d633mujIpY0E2w0fb1I2ohP0Q5VqB/NhwuOJgus8jFN/m //XsUMxmwnGH+Kkrnnk5jUon08ihg1IHvSyTkhfw2/IRHRxw9ceN9iOh3qsTNHA4x6nG VaavlDBwGZjFyZt2lZHwiMA/+LMctpXyW+eOt1jC0/U2tI/iytmZMV11toN1WZB3uYk2 RO8hkc/uJjwgIiZ0DBX0pUWNmL+Wkk+cPXO5DHHVPeU9dFiMeIR1KxcwWl3CAPBL+41G X7Xg== X-Gm-Message-State: ALoCoQlyJ8MGufG5kASpQJDyAswZi1J4ecpuSREzj3LpaK+mwW//4UTobsLp8CzVf9hzehcwpHSG X-Received: by 10.49.109.194 with SMTP id hu2mr22227614qeb.13.1384642177086; Sat, 16 Nov 2013 14:49:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.63.101 with HTTP; Sat, 16 Nov 2013 14:49:07 -0800 (PST) In-Reply-To: References: <5286F670.2050305@jrv.org> <5287071B.3020209@petermann-it.de> <528786C9.9070409@allanjude.com> <5287BB44.4020104@jrv.org> <5287D632.4010802@allanjude.com> From: Eitan Adler Date: Sat, 16 Nov 2013 17:49:07 -0500 Message-ID: Subject: Re: Slow boot with 256GB of RAM? To: Zach Crum Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Docs , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2013 22:49:38 -0000 On Sat, Nov 16, 2013 at 4:12 PM, Zach Crum wrote: > This setting is not listed in /boot/defaults/loader.conf. Is it supposed to > be singular or plural? Plural. I will commit the patch. Does any know of cases where this memory test actually catches errors? How important is it? -- Eitan Adler