From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 10 03:03:52 2014 Return-Path: Delivered-To: freebsd-hackers@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 CAFC4D70 for ; Sun, 10 Aug 2014 03:03:52 +0000 (UTC) Received: from tds-solutions.net (tds-solutions.net [192.99.32.153]) by mx1.freebsd.org (Postfix) with ESMTP id A3E0D2A0D for ; Sun, 10 Aug 2014 03:03:52 +0000 (UTC) Received: from tds-solutions.net (localhost [127.0.0.1]) by tds-solutions.net (Postfix) with ESMTP id 3709B3B6FB for ; Sat, 9 Aug 2014 22:56:49 -0400 (EDT) X-Virus-Scanned: amavisd-new at tds-solutions.net Received: from tds-solutions.net ([127.0.0.1]) by tds-solutions.net (tds-solutions.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfbFqYtQPQWy for ; Sat, 9 Aug 2014 22:56:37 -0400 (EDT) Received: from [192.168.1.35] (24-177-51-95.dhcp.oxfr.ma.charter.com [24.177.51.95]) (Authenticated sender: sorressean) by tds-solutions.net (Postfix) with ESMTPSA id CB5893B69A for ; Sat, 9 Aug 2014 22:56:37 -0400 (EDT) Message-ID: <53E6DFA0.1080308@tysdomain.com> Date: Sat, 09 Aug 2014 22:57:36 -0400 From: "Littlefield, Tyler" Reply-To: tyler@tysdomain.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "freebsd-hackers@freebsd.org" Subject: [patch] make port net-mgmt/ipcalc comply with portlint Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 03:03:52 -0000 Hello: Here is the patch to the Makefile. I hope I've done everything correctly here. Thanks, 13,15d12 < LICENSE= GPLv1 < LICENSE_FILE= ${WRKSRC}/License < -- Take care, Ty http://tds-solutions.net He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave. From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 10 07:30:15 2014 Return-Path: Delivered-To: freebsd-hackers@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 A2952AB4 for ; Sun, 10 Aug 2014 07:30:15 +0000 (UTC) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "ca.infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 34AEA2173 for ; Sun, 10 Aug 2014 07:30:15 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.2.117.99]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.9/8.14.9) with ESMTP id s7A7U74e062082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 10 Aug 2014 08:30:08 +0100 (BST) (envelope-from matthew@FreeBSD.org) Authentication-Results: lucid-nonsense.infracaninophile.co.uk; dmarc=none header.from=FreeBSD.org DKIM-Filter: OpenDKIM Filter v2.9.2 smtp.infracaninophile.co.uk s7A7U74e062082 Authentication-Results: smtp.infracaninophile.co.uk/s7A7U74e062082; dkim=none reason="no signature"; dkim-adsp=none; dkim-atps=neutral Message-ID: <53E71F7C.6090004@FreeBSD.org> Date: Sun, 10 Aug 2014 08:30:04 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tyler@tysdomain.com Subject: Re: [patch] make port net-mgmt/ipcalc comply with portlint References: <53E6DFA0.1080308@tysdomain.com> In-Reply-To: <53E6DFA0.1080308@tysdomain.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="AlE5rrE4uveVPUw9gHMUvcVMdRkSv7bU7" X-Virus-Scanned: clamav-milter 0.98.4 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lucid-nonsense.infracaninophile.co.uk Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 07:30:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AlE5rrE4uveVPUw9gHMUvcVMdRkSv7bU7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 10/08/2014 03:57, Littlefield, Tyler wrote: > Hello: > Here is the patch to the Makefile. I hope I've done everything correctl= y > here. > Thanks, >=20 > 13,15d12 > < LICENSE=3D GPLv1 > < LICENSE_FILE=3D ${WRKSRC}/License > < >=20 Thank you very much for your contribution. Alas, the freebsd-hackers@... list is not the most appropriate channel of communication for this. Can you open a PR in Bugzilla please? https://bugs.freebsd.org/bugzilla/enter_bug.cgi If you can upload the diff as an attachment that would be super. We usually use the 'diff -u' format. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --AlE5rrE4uveVPUw9gHMUvcVMdRkSv7bU7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJT5x9/XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATU+MP/0GpgXDTAQcsrp81CMbSTEp7 N1S/ZGbV3d38F6dpkCEmm25AmA3YJGCGhT3xnZ/p1CLvNZuB+0yho/cThRUF0/Cx isQaaTtM3hcb7e5JvL6V99mhHZ+aOrXmCLTr/f37kucJezwuqknq42xLcC+5nweF Fr8Rgy5Xnt5lItHeshtTp1hlL28xBzUCHOxi5iviokZgEO/OPaesvO5ph+tY49II TNc3Xzy6M3ZmhE1IFCDdvBIj8hrScJLgveZuzvmGs3cIqKhQaOBGz+DrJry9RKu9 hlXCuwttMoENsDj7VgSLRthsEHoXzIzrW8f5h6fkcnJNa3Bmz4dSOo+zN7WMgJQt zKSM57mVfqEBZrsGtfVuHUjahOd/f+u9e/bVAc8RY0QojFIsXC3yB/uVWxprXEkC cpvvd6JcTMtgvbhM6Cmu3ZAXwwXa9S4RtQ12xkZ65UEt2M1uV18VCq70qffN/oUh 1hU6VK1yx3bbmniaaO8VEiUlkdIs5z7Qu29g5bCnw4Ja2qbnPpDKyU48THVmyss2 XdoNdjX0KYTsu0TaO6acHM+cpg24ePnV+Cr4Bby1aPZEtSGwZuEfjO/9iWjYylDN ylE/WchqFrpYJ/0UqHnMYLJfefKaqq+Kfpg0Mn56CjycuRCErFWJmdTIUhv52LLj zykMC3BJNePS1zNj5ZU9 =GuSZ -----END PGP SIGNATURE----- --AlE5rrE4uveVPUw9gHMUvcVMdRkSv7bU7-- From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 10 16:00:29 2014 Return-Path: Delivered-To: hackers@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 94A67915 for ; Sun, 10 Aug 2014 16:00:29 +0000 (UTC) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "asuka.mahoroba.org", Issuer "ca.mahoroba.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 34DE721DB for ; Sun, 10 Aug 2014 16:00:29 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:7258:12ff:fe22:d94b]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.14.9/8.14.9) with ESMTP/inet6 id s7AG0LIO031311 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 11 Aug 2014 01:00:22 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Mon, 11 Aug 2014 01:00:26 +0900 Message-ID: From: Hajimu UMEMOTO To: hackers@FreeBSD.org Subject: symbol version for newly added functions in libc User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.3 Mule/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 9.3-STABLE X-PGP-Key: http://www.mahoroba.org/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Mon, 11 Aug 2014 01:00:22 +0900 (JST) X-Virus-Scanned: clamav-milter 0.98.4 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on asuka.mahoroba.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 16:00:29 -0000 Hi, I'm working on update our stub resolver in libc to the final version of libbind. This update adds some new functions. I see that FBSD_1.4 should be used for 11.0-CURRENT. However, I have a plan to do MFC into 10 and 9. In this case, which symbol version should be used for new functions FBSD_1.2, FBSD_1.3 or FBSD_1.4? Sincerely, -- Hajimu UMEMOTO ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.mahoroba.org/~ume/ From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 10 16:32:46 2014 Return-Path: Delivered-To: hackers@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 436A3C63; Sun, 10 Aug 2014 16:32:46 +0000 (UTC) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B3CB2523; Sun, 10 Aug 2014 16:32:45 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 3D463B8060; Sun, 10 Aug 2014 18:32:44 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 258EA28494; Sun, 10 Aug 2014 18:32:44 +0200 (CEST) Date: Sun, 10 Aug 2014 18:32:44 +0200 From: Jilles Tjoelker To: Hajimu UMEMOTO Subject: Re: symbol version for newly added functions in libc Message-ID: <20140810163243.GB59401@stack.nl> References: 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: hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 16:32:46 -0000 On Mon, Aug 11, 2014 at 01:00:26AM +0900, Hajimu UMEMOTO wrote: > I'm working on update our stub resolver in libc to the final version > of libbind. > This update adds some new functions. > I see that FBSD_1.4 should be used for 11.0-CURRENT. However, I have > a plan to do MFC into 10 and 9. In this case, which symbol version > should be used for new functions FBSD_1.2, FBSD_1.3 or FBSD_1.4? The symbol version used for the new functions in the stable branches should be the same as in -current. This ensures that an executable built on a stable branch will work on -current. It is currently an accepted side effect that symbol versioning will usually accept an executable from a newer version of FreeBSD, only failing if and when an unimplemented symbol is needed. -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 10 18:11:01 2014 Return-Path: Delivered-To: hackers@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 2E10293D for ; Sun, 10 Aug 2014 18:11:01 +0000 (UTC) Received: from mout.gmx.com (mout.gmx.com [74.208.4.201]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 09D052EB6 for ; Sun, 10 Aug 2014 18:11:01 +0000 (UTC) Received: from dutch.freebsd.net ([172.15.184.248]) by mail.gmx.com (mrgmxus002) with ESMTPSA (Nemesis) id 0LaWy1-1WYeRY1N9j-00mL2S for ; Sun, 10 Aug 2014 20:10:59 +0200 Date: Sun, 10 Aug 2014 14:10:58 -0400 From: Dutch Ingraham To: hackers@FreeBSD.org Subject: FFMPEG Build/Configure Failure Message-Id: <20140810141058.84bafe8adfe31927354993f3@gmx.us> X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Lwv6TIjyV8gz0n/kpChSrpye+I69FGZRkrgMm7RxTGW4TfqR73q L7OQw5Tm/DatQT3ytYbjmNzm6czfVUa03rDvmzW58Z8Bk5HPvd8hChFMUl9y3JaQVfeiY/4 buB8LBTd/MmAvj+plbDPxRNTDpN1qru00n+wQcjLgGGfWCA/rRNqOXN7/L8v/l0du2ZKZhq 0sSYfUkoOJzhWg0yofrgA== X-UI-Out-Filterresults: notjunk:1; X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 18:11:01 -0000 Hello: I'm having trouble upgrading gnutls by way of , which shows an upgrade needed. (I did report this, as instructed in the error message below, to multimedia@FreeBSD.org. I'm not sure if I should expect a response or not, but haven't received one either way.) Here is the : FreeBSD dutch.freebsd.net 10.0-RELEASE-p7 FreeBSD 10.0-RELEASE-p7 #0: Tue Jul 8 06:37:44 UTC 2014 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 Here are the last few messages from the build: "===> ffmpeg-2.2.4_4,1 depends on shared library: libx264.so - found (/usr/local/lib/libx264.so.136) - found (/usr/local/lib/libx264.so.136) ===> ffmpeg-2.2.4_4,1 depends on shared library: libxvidcore.so - found (/usr/local/lib/libxvidcore.so.4) - found (/usr/local/lib/libxvidcore.so.4) ===> ffmpeg-2.2.4_4,1 depends on shared library: libSDL.so - found (/usr/local/lib/libSDL-1.2.so.11) - found (/usr/local/lib/libSDL-1.2.so.11) ===> Configuring for ffmpeg-2.2.4_4,1 ===> FreeBSD 10 autotools fix applied to /usr/ports/multimedia/ffmpeg/work/ffmpeg-2.2.4/configure ERROR: gnutls not found If you think configure made a mistake, make sure you are using the latest version from Git. If the latest version fails, report the problem to the ffmpeg-user@ffmpeg.org mailing list or IRC #ffmpeg on irc.freenode.net. Include the log file "config.log" produced by configure as this will help solving the problem. ===> Script "configure" failed unexpectedly. Please report the problem to multimedia@FreeBSD.org [maintainer] and attach the "/usr/ports/multimedia/ffmpeg/work/ffmpeg-2.2.4/config.err" including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. a /usr/local/sbin/pkg-static info -g -Ea). *** Error code 1 Stop. make[1]: stopped in /usr/ports/multimedia/ffmpeg *** Error code 1 Stop. make: stopped in /usr/ports/multimedia/ffmpeg ===>>> make build failed for multimedia/ffmpeg ===>>> Aborting update" There was no /usr/ports/multimedia/ffmpeg/work/ffmpeg-2.2.4/config.err file. Most importantly, the ERROR states gnutls is not found. Here is the output from : gnutls-3.2.16_3 Name : gnutls Version : 3.2.16_3 Installed on : Thu Jul 31 13:21:39 EDT 2014 Origin : security/gnutls Architecture : freebsd:10:x86:64 Prefix : /usr/local Categories : security net Licenses : LGPL21 and GPLv3 Maintainer : bdrewery@FreeBSD.org WWW : http://www.gnutls.org/ Comment : GNU Transport Layer Security library Options : CRYWRAP : on EXAMPLES : on LIBDANE : off NLS : on P11KIT : on TPM : on ZLIB : on Shared Libs required: libtspi.so.1 libtasn1.so.6 libp11-kit.so.0 libnettle.so.4 libintl.so.9 libhogweed.so.2 libgnutls.so.28 libgmp.so.10 Shared Libs provided: libgnutlsxx.so.28 libgnutls.so.28 libgnutls-xssl.so.0 libgnutls-openssl.so.27 Flat size : 8.24MiB Description : GnuTLS is a secure communications library implementing the SSL, TLS and DTLS protocols and technologies around them. It provides a simple C language application programming interface (API) to access the secure communications protocols as well as APIs to parse and write X.509, PKCS #12, OpenPGP and other required structures. It is aimed to be portable and efficient with focus on security and interoperability WWW: http://www.gnutls.org/ I have tried rebuilding gnutls, but that failed and actually removed the package. I then installed with , which was successful. A further attempt to upgrade ffmpeg thereafter resulted in the same errors as above. Any help you can provide is appreciated. From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 10 19:34:38 2014 Return-Path: Delivered-To: hackers@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 A3383DC2 for ; Sun, 10 Aug 2014 19:34:38 +0000 (UTC) Received: from mout.gmx.com (mout.gmx.com [74.208.4.201]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7B69F26C1 for ; Sun, 10 Aug 2014 19:34:38 +0000 (UTC) Received: from dutch.freebsd.net ([172.15.184.248]) by mail.gmx.com (mrgmxus002) with ESMTPSA (Nemesis) id 0LjIOP-1WhUyw0hWZ-00dZmF; Sun, 10 Aug 2014 21:34:37 +0200 Date: Sun, 10 Aug 2014 15:34:33 -0400 From: Dutch Ingraham To: Dutch Ingraham Subject: Re: FFMPEG Build/Configure Failure Message-Id: <20140810153433.36ca5494689773b571068592@gmx.us> In-Reply-To: <20140810141058.84bafe8adfe31927354993f3@gmx.us> References: <20140810141058.84bafe8adfe31927354993f3@gmx.us> X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:CK/l3RHR0Y9ZPERmqO2Wt0V7ja71RJbSTibrgEV5trhUh81XRWe A3TbMpmNXsLvxwQCLVQYd/lTZeb/M+AU+9wSigd+BtWbe1RR0kAzqGBpwvYvWk+HllKf/ho nGRR+5NCvtJNLzgrBn2LWypb5/Jwh+90LVx5CracCBu3EO8HnBiSkfl4sZ6IJxTr6LHLEDD XEXsC8Dpjh08b2wPZspaQ== X-UI-Out-Filterresults: notjunk:1; Cc: hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 19:34:38 -0000 Sorry - the below should state trouble upgrading "ffmpeg" not "gnutls." On Sun, 10 Aug 2014 14:10:58 -0400 Dutch Ingraham wrote: > > > Hello: > > I'm having trouble upgrading gnutls by way of , which > shows an upgrade needed. (I did report this, as instructed in the error > message below, to multimedia@FreeBSD.org. I'm not sure if I should expect > a response or not, but haven't received one either way.) > > Here is the : > > FreeBSD dutch.freebsd.net 10.0-RELEASE-p7 FreeBSD 10.0-RELEASE-p7 #0: > Tue Jul 8 06:37:44 UTC 2014 > root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 > > Here are the last few messages from the build: > > "===> ffmpeg-2.2.4_4,1 depends on shared library: libx264.so - found > (/usr/local/lib/libx264.so.136) - found (/usr/local/lib/libx264.so.136) > ===> ffmpeg-2.2.4_4,1 depends on shared library: libxvidcore.so - > found (/usr/local/lib/libxvidcore.so.4) - found > (/usr/local/lib/libxvidcore.so.4) > ===> ffmpeg-2.2.4_4,1 depends on shared library: libSDL.so - found > (/usr/local/lib/libSDL-1.2.so.11) - found > (/usr/local/lib/libSDL-1.2.so.11) > ===> Configuring for ffmpeg-2.2.4_4,1 > ===> FreeBSD 10 autotools fix applied to > /usr/ports/multimedia/ffmpeg/work/ffmpeg-2.2.4/configure > ERROR: gnutls not found > > If you think configure made a mistake, make sure you are using the > latest version from Git. If the latest version fails, report the problem to > the ffmpeg-user@ffmpeg.org mailing list or IRC #ffmpeg on irc.freenode.net. > Include the log file "config.log" produced by configure as this will > help solving the problem. > ===> Script "configure" failed unexpectedly. > Please report the problem to multimedia@FreeBSD.org [maintainer] and > attach the "/usr/ports/multimedia/ffmpeg/work/ffmpeg-2.2.4/config.err" > including the output of the failure of your make command. Also, it might be a good > idea to provide an overview of all packages installed on your system (e.g. a > /usr/local/sbin/pkg-static info -g -Ea). > *** Error code 1 > > Stop. > make[1]: stopped in /usr/ports/multimedia/ffmpeg > *** Error code 1 > > Stop. > make: stopped in /usr/ports/multimedia/ffmpeg > > ===>>> make build failed for multimedia/ffmpeg > ===>>> Aborting update" > > > There was no /usr/ports/multimedia/ffmpeg/work/ffmpeg-2.2.4/config.err > file. > > Most importantly, the ERROR states gnutls is not found. Here is the > output from : > > gnutls-3.2.16_3 > Name : gnutls > Version : 3.2.16_3 > Installed on : Thu Jul 31 13:21:39 EDT 2014 > Origin : security/gnutls > Architecture : freebsd:10:x86:64 > Prefix : /usr/local > Categories : security net > Licenses : LGPL21 and GPLv3 > Maintainer : bdrewery@FreeBSD.org > WWW : http://www.gnutls.org/ > Comment : GNU Transport Layer Security library > Options : > CRYWRAP : on > EXAMPLES : on > LIBDANE : off > NLS : on > P11KIT : on > TPM : on > ZLIB : on > Shared Libs required: > libtspi.so.1 > libtasn1.so.6 > libp11-kit.so.0 > libnettle.so.4 > libintl.so.9 > libhogweed.so.2 > libgnutls.so.28 > libgmp.so.10 > Shared Libs provided: > libgnutlsxx.so.28 > libgnutls.so.28 > libgnutls-xssl.so.0 > libgnutls-openssl.so.27 > Flat size : 8.24MiB > Description : > GnuTLS is a secure communications library implementing the SSL, TLS and DTLS > protocols and technologies around them. It provides a simple C language > application programming interface (API) to access the secure communications > protocols as well as APIs to parse and write X.509, PKCS #12, OpenPGP and > other required structures. It is aimed to be portable and efficient with > focus on security and interoperability > WWW: http://www.gnutls.org/ > > I have tried rebuilding gnutls, but that failed and actually removed > the package. I then installed with , which > was successful. A further attempt to upgrade ffmpeg thereafter > resulted in the same errors as above. > > Any help you can provide is appreciated. > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Dutch Ingraham From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 10 19:01:09 2014 Return-Path: Delivered-To: freebsd-hackers@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 16F2575B; Sun, 10 Aug 2014 19:01:09 +0000 (UTC) Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net [50.73.42.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E0BE32496; Sun, 10 Aug 2014 19:01:08 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.5/8.14.5) with ESMTP id s7AJ1780006441; Sun, 10 Aug 2014 13:01:07 -0600 (MDT) (envelope-from torek@elf.torek.net) Received: (from torek@localhost) by elf.torek.net (8.14.5/8.14.5/Submit) id s7AJ17Lu006439; Sun, 10 Aug 2014 13:01:07 -0600 (MDT) (envelope-from torek) Date: Sun, 10 Aug 2014 13:01:07 -0600 (MDT) From: Chris Torek Message-Id: <201408101901.s7AJ17Lu006439@elf.torek.net> To: adrian@freebsd.org Subject: Re: crash in bpf catchpacket() code In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.torek.net [127.0.0.1]); Sun, 10 Aug 2014 13:01:07 -0600 (MDT) X-Mailman-Approved-At: Sun, 10 Aug 2014 19:47:56 +0000 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 19:01:09 -0000 >Would you mind submitting a PR for this? You've done all the great >work needed to chase this down; I'd hate for it to be forgotten! Sent. I expanded a bit more on some thoughts about the other mtx_sleep case in the code (in the zero copy stuff); the patch I gave may leave a bug there, and is probably sub-optimal (I was going for a minimal change that would keep our system from crashing :-) ). (Although a "goto restart" after mtx_sleep'ing would also be not exactly optimal, as we'd redo a bunch of effectively constant work. Anyway the root of the bug appears to be that mtx_sleep drops our bpf_d descriptor lock and the code assumes we hold it throughout.) Chris From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 11 08:35:27 2014 Return-Path: Delivered-To: freebsd-hackers@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 CF25D435 for ; Mon, 11 Aug 2014 08:35:27 +0000 (UTC) Received: from smtp.bsdes.net (115.Red-81-47-160.staticIP.rima-tde.net [81.47.160.115]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smtp.bsdes.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8FA4B21F9 for ; Mon, 11 Aug 2014 08:35:27 +0000 (UTC) Received: by smtp.bsdes.net (Postfix, from userid 1001) id 366ED22849; Mon, 11 Aug 2014 10:26:10 +0200 (CEST) Date: Mon, 11 Aug 2014 10:26:10 +0200 From: Victor Balada Diaz To: Sushanth Rai Subject: Re: Support for zero copy sockets Message-ID: <20140811082610.GF7828@equilibrium.bsdes.net> References: <1407171616.44440.YahooMailBasic@web181702.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1407171616.44440.YahooMailBasic@web181702.mail.ne1.yahoo.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 08:35:27 -0000 On Mon, Aug 04, 2014 at 10:00:16AM -0700, Sushanth Rai via freebsd-hackers wrote: > Hello, > > FreeBSD 10 release sources doesn't seem to have zero copy socket code anymore. What's is alternative to do zero_copy ? > > Thanks, > Sushanth You need to use sendfile(2). In the man page is stated that the implementation in FreeBSD is zero copy. You can also check: http://svnweb.freebsd.org/base?view=revision&revision=255608 -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 11 11:35:15 2014 Return-Path: Delivered-To: hackers@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 BEB92FE9 for ; Mon, 11 Aug 2014 11:35:15 +0000 (UTC) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "asuka.mahoroba.org", Issuer "ca.mahoroba.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 39438285F for ; Mon, 11 Aug 2014 11:35:14 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:7258:12ff:fe22:d94b]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.14.9/8.14.9) with ESMTP/inet6 id s7BBYthD034245 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Mon, 11 Aug 2014 20:35:02 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Mon, 11 Aug 2014 20:34:32 +0900 Message-ID: From: Hajimu UMEMOTO To: Jilles Tjoelker Subject: Re: symbol version for newly added functions in libc In-Reply-To: <20140810163243.GB59401@stack.nl> References: <20140810163243.GB59401@stack.nl> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) Emacs/24.3 Mule/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 9.3-STABLE X-PGP-Key: http://www.mahoroba.org/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Mon, 11 Aug 2014 20:35:02 +0900 (JST) X-Virus-Scanned: clamav-milter 0.98.4 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on asuka.mahoroba.org Cc: hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 11:35:15 -0000 Hi, >>>>> On Sun, 10 Aug 2014 18:32:44 +0200 >>>>> Jilles Tjoelker said: jilles> The symbol version used for the new functions in the stable branches jilles> should be the same as in -current. This ensures that an executable built jilles> on a stable branch will work on -current. jilles> It is currently an accepted side effect that symbol versioning will jilles> usually accept an executable from a newer version of FreeBSD, only jilles> failing if and when an unimplemented symbol is needed. Okay, Thank you for clarification. Sincerely, -- Hajimu UMEMOTO ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.mahoroba.org/~ume/ From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 11 11:58:50 2014 Return-Path: Delivered-To: hackers@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 07C8C871 for ; Mon, 11 Aug 2014 11:58:50 +0000 (UTC) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx12.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BFEF32AE8 for ; Mon, 11 Aug 2014 11:58:49 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.01,841,1400050800"; d="asc'?scan'208";a="181243509" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx12-out.netapp.com with ESMTP; 11 Aug 2014 04:58:50 -0700 Received: from HIOEXCMBX01-PRD.hq.netapp.com (10.122.105.34) by vmwexceht02-prd.hq.netapp.com (10.106.76.240) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 11 Aug 2014 04:58:22 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 11 Aug 2014 04:58:21 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::f0de:b572:dd26:36b5%21]) with mapi id 15.00.0913.011; Mon, 11 Aug 2014 04:58:21 -0700 From: "Eggert, Lars" To: "hackers@freebsd.org" Subject: nscd not caching Thread-Topic: nscd not caching Thread-Index: AQHPtVuLYaAik14OAEOAejvgb8mhtA== Date: Mon, 11 Aug 2014 11:58:21 +0000 Message-ID: <9F8FBD79-2825-4B22-BD14-EACF65A7DD50@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_A11AFBBE-B33C-4780-A4A8-DA70BFBF9564"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 11 Aug 2014 12:11:27 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 11:58:50 -0000 --Apple-Mail=_A11AFBBE-B33C-4780-A4A8-DA70BFBF9564 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, anyone have an idea why nscd would not be caching NIS lookups on = 10-RELEASE? My nsswitch.conf looks as follows: group: cache files nis #group_compat: nis hosts: cache files dns networks: files passwd: cache files nis #passwd_compat: nis shells: files services: cache files nis #services_compat: nis protocols: files rpc: files nisdomain is set and ypbind is started, and I see lots of NIS traffic = going in and out. But nothing is cached; running nscd -nst just prints this and then sits = there: root@laurel:~ # nscd -nst M1 from main: request agents registered successfully M2 from cache: cache was successfully initialized M2 from runtime environment: using socket /var/run/nscd M2 from runtime environment: successfully initialized M1 from main: working in single-threaded mode Lars --Apple-Mail=_A11AFBBE-B33C-4780-A4A8-DA70BFBF9564 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----- iQCVAwUBU+iv99ZcnpRveo1xAQK2FAP+NUpt0VBJpfd7SIRW2dTHsPdnVMExTUPM b9ZFI43D7kxvDQVIjPfYtHQvtxNAo6F47zSfitDjdEI7/EYy/n+4wuXgQj2XE7+7 gY6i24SVNcFf6rOERC0yyN1PtGsFA0aASOyhfPInkr+sKQ+2cgnIfedHhSpI/MFj ry3E7yjSV/Y= =Pa61 -----END PGP SIGNATURE----- --Apple-Mail=_A11AFBBE-B33C-4780-A4A8-DA70BFBF9564-- From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 11 17:28:06 2014 Return-Path: Delivered-To: freebsd-hackers@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 A9B4A20E for ; Mon, 11 Aug 2014 17:28:06 +0000 (UTC) Received: from sdf.lonestar.org (mx.sdf.org [192.94.73.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx.sdf.org", Issuer "SDF.ORG" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E29E2783 for ; Mon, 11 Aug 2014 17:28:05 +0000 (UTC) Received: from sdf.org (IDENT:cary@sdf.lonestar.org [192.94.73.15]) by sdf.lonestar.org (8.14.8/8.14.5) with ESMTP id s7BHRteg018132 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits) verified NO) for ; Mon, 11 Aug 2014 17:27:55 GMT Received: (from cary@localhost) by sdf.org (8.14.8/8.12.8/Submit) id s7BHRtsk004994 for freebsd-hackers@freebsd.org; Mon, 11 Aug 2014 17:27:55 GMT Date: Mon, 11 Aug 2014 17:27:55 +0000 From: Cary To: "freebsd-hackers@freebsd.org" Subject: Re: nscd not caching Message-ID: <20140811172755.GA1414@SDF.ORG> Mail-Followup-To: "freebsd-hackers@freebsd.org" References: <9F8FBD79-2825-4B22-BD14-EACF65A7DD50@netapp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9F8FBD79-2825-4B22-BD14-EACF65A7DD50@netapp.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 17:28:06 -0000 On Mon, Aug 11, 2014 at 11:58:21AM +0000, Eggert, Lars wrote: > Hi, > > anyone have an idea why nscd would not be caching NIS lookups on 10-RELEASE? > > My nsswitch.conf looks as follows: > > group: cache files nis > #group_compat: nis > hosts: cache files dns > networks: files > passwd: cache files nis > #passwd_compat: nis > shells: files > services: cache files nis > #services_compat: nis > protocols: files > rpc: files > > nisdomain is set and ypbind is started, and I see lots of NIS traffic going in and out. > > But nothing is cached; running nscd -nst just prints this and then sits there: > > root@laurel:~ # nscd -nst > M1 from main: request agents registered successfully > M2 from cache: cache was successfully initialized > M2 from runtime environment: using socket /var/run/nscd > M2 from runtime environment: successfully initialized > M1 from main: working in single-threaded mode > > Lars > Disabling nscd(8) was the only choice for me. When I tried using the daemon other things would break, specifically mozilla. Cary -- cary@sdf.org SDF Public Access UNIX System - http://sdf.org From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 11 18:04:20 2014 Return-Path: Delivered-To: freebsd-hackers@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 CE36BEDF for ; Mon, 11 Aug 2014 18:04:20 +0000 (UTC) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F1FB2BA1 for ; Mon, 11 Aug 2014 18:04:20 +0000 (UTC) Received: by mail-qg0-f49.google.com with SMTP id j107so8720275qga.22 for ; Mon, 11 Aug 2014 11:04:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=RMau9ToBIh0n0TtSs2hnemOGmyZLzLmBLb8EqqTSlWA=; b=AAqfapP+2hgiUMm1TLUlUS4n6LAoIBCsTMHzlrW+DDSlHXMDimtYBLbkDobw/HI/iQ CWrnr8M2fOY4AdPdrPMlH6bYhcyGYzIpG6hlSTndsvo/lv9mv3bAbT9Yrfjy9quD1zHx D6qzUv+FmCIDEXdw1fiAyhYXVuTlYyo3VUPVkHvANZNvb/v+3KL8rN3/ZHmQsN74WyLZ w3AKLF5BDa6BkSO4cEnl2Gv94XBRSWA7u7iibyebr9utQjIDhvQ1Ys/Igq074/noXRQX sNO3bmSgU0L2nw+a3r/apa750GKjhQo9DN/huBVrq+KhWxN3pd25qYpIhWbVgBI4P2dU CKBw== MIME-Version: 1.0 X-Received: by 10.224.71.198 with SMTP id i6mr67911737qaj.76.1407780259662; Mon, 11 Aug 2014 11:04:19 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.41.6 with HTTP; Mon, 11 Aug 2014 11:04:19 -0700 (PDT) In-Reply-To: <20140811082610.GF7828@equilibrium.bsdes.net> References: <1407171616.44440.YahooMailBasic@web181702.mail.ne1.yahoo.com> <20140811082610.GF7828@equilibrium.bsdes.net> Date: Mon, 11 Aug 2014 11:04:19 -0700 X-Google-Sender-Auth: 5rmN6imqkj3SXIM-CGzCPwXmMsQ Message-ID: Subject: Re: Support for zero copy sockets From: Adrian Chadd To: Victor Balada Diaz Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , Sushanth Rai X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 18:04:20 -0000 On 11 August 2014 01:26, Victor Balada Diaz wrote: > On Mon, Aug 04, 2014 at 10:00:16AM -0700, Sushanth Rai via freebsd-hackers wrote: >> Hello, >> >> FreeBSD 10 release sources doesn't seem to have zero copy socket code anymore. What's is alternative to do zero_copy ? >> >> Thanks, >> Sushanth > > You need to use sendfile(2). In the man page is stated that the implementation in FreeBSD > is zero copy. > > You can also check: > > http://svnweb.freebsd.org/base?view=revision&revision=255608 > I'd like to reintroduce a zero copy socket IO method for at least write that doesn't rely on sendfile. The zero-copy socket page flipping thing was interesting because IIRC tried to work for both sending and receiving socket data. Doing that via an API would be nicer. So, if people have an idea for how it could be done / what the API looks like then I'm all ears. -a From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 11 18:21:16 2014 Return-Path: Delivered-To: freebsd-hackers@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 5C70165F for ; Mon, 11 Aug 2014 18:21:16 +0000 (UTC) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1CD792EA6 for ; Mon, 11 Aug 2014 18:21:15 +0000 (UTC) Received: by mail-ig0-f174.google.com with SMTP id c1so4718692igq.13 for ; Mon, 11 Aug 2014 11:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dragondata.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=02MATqofKNBt/bct2hWLpXqqOoF+1SBkwhKYF3c3ofQ=; b=o69fwZokJ1Sgqq0Ma/Gdb4/Qj7qLr6iXOEsfHpRNqs16ubpTg3F5EhN21Ntg5YxVqz xS726K/YX8FtJsVT4OyNy5ciAL0khkBKyDADyd9rN9bFZLcNPSkKCmICmGn6hm4lJ2S6 r5KpihWWy9SDb7VhEVIinlbxkePQm+oS9Xp1w= 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=02MATqofKNBt/bct2hWLpXqqOoF+1SBkwhKYF3c3ofQ=; b=IPAcZWBEZ+ws3Xg3wA6uxps+AXIMCDzUPRS7aDFr2g7FWaWG9prc7s1bfodhb4zbZe Gv92kFSDfvFekpO5Ejl38HxgxStpwhPQH0ZBJ0oecYRzc1wf5BphZNl4/Ps4tJg6I5tf +P6XDndtvc7DEkLtH/dIGTyFUBA8UOaQ4nyybrBpiS34RviZ4Zf8OASV6zw3seZKqtGh fj5FcQC37cx5JeqCiMUrMwWm1OhaYsaMYqz7DGvNZJjSbe0ZmGHCqrjB9EYletBFg63O h1vVd9J0RZ4NRxsdEK/RGlJQLqad3iPUXV3IlBowhBUXb8MDSWqBr22U9NB0FnrpEfPe Uo9w== X-Gm-Message-State: ALoCoQnHY+HFiRCnYfmhr0uAjn4EStvH5NP0rgLJTUv9da8Rp9VnX/o+hM+5F5q3Mq03pvRPagJ6 X-Received: by 10.42.91.200 with SMTP id q8mr32897083icm.63.1407781275281; Mon, 11 Aug 2014 11:21:15 -0700 (PDT) Received: from vpn132.rw1.your.org (vpn132.rw1.your.org. [204.9.51.132]) by mx.google.com with ESMTPSA id om5sm51035980igb.19.2014.08.11.11.21.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Aug 2014 11:21:14 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Support for zero copy sockets From: Kevin Day In-Reply-To: Date: Mon, 11 Aug 2014 13:21:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4F4BB4BC-B916-4808-A267-4002FFB8932B@dragondata.com> References: <1407171616.44440.YahooMailBasic@web181702.mail.ne1.yahoo.com> <20140811082610.GF7828@equilibrium.bsdes.net> To: Adrian Chadd X-Mailer: Apple Mail (2.1878.6) Cc: Victor Balada Diaz , Sushanth Rai , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 18:21:16 -0000 >=20 > I'd like to reintroduce a zero copy socket IO method for at least > write that doesn't rely on sendfile. >=20 > The zero-copy socket page flipping thing was interesting because IIRC > tried to work for both sending and receiving socket data. Doing that > via an API would be nicer. >=20 > So, if people have an idea for how it could be done / what the API > looks like then I'm all ears. >=20 If FreeBSD could be API compatible with Linux=92s splice(2) and/or = tee(2), that would probably make a lot of people happy. http://linux.die.net/man/2/splice (I know that=92s not exactly what you=92re talking about, but while = we=92re on the subject) From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 11 18:33:47 2014 Return-Path: Delivered-To: freebsd-hackers@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 AE463EE7; Mon, 11 Aug 2014 18:33:47 +0000 (UTC) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E9DC720E9; Mon, 11 Aug 2014 18:33:46 +0000 (UTC) Received: by mail-la0-f44.google.com with SMTP id el20so6050066lab.31 for ; Mon, 11 Aug 2014 11:33:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4/5zt2GTbKbVuKLODqs4Bv2l3caFYJ5EN42s6rgMN+o=; b=slwQ+8v2nLX0e7+wMxiSn8HukEcKv9iHdiYaOju7fSMMFdJ/LRoH4LgFSJu4TbY91U sX07QZx4DfygjiX6lk7HD7Vyvza6vY5UQHSLFwg6RrYX9et1xKxETTbb3D66OEsUEcRa ImaX0oZ/wRCXPBKACYJ7TZr6oUCBEK2aX000r7NSkKp8hYZofdEJh4KKx/gyPpm0Fqr9 AZLCkxUfIAAX8kEzJHhP37ARvzuDw+98J82hse3pnaqRy4zpDYt3Ba2YVTMWjZEk5zPS uTtR8PpCsppcizIz9UeBGqDS8/OqjfXfGNaGSDxoil9jH47T/sOO7JQwPphXSqV3AypM Zk5g== MIME-Version: 1.0 X-Received: by 10.152.4.97 with SMTP id j1mr40456799laj.10.1407782024772; Mon, 11 Aug 2014 11:33:44 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.244.2 with HTTP; Mon, 11 Aug 2014 11:33:44 -0700 (PDT) In-Reply-To: References: <1407171616.44440.YahooMailBasic@web181702.mail.ne1.yahoo.com> <20140811082610.GF7828@equilibrium.bsdes.net> Date: Mon, 11 Aug 2014 20:33:44 +0200 X-Google-Sender-Auth: tcqBeofrz_JgCIzznU1_ysS2IRw Message-ID: Subject: Re: Support for zero copy sockets From: Luigi Rizzo To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Victor Balada Diaz , Sushanth Rai , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 18:33:47 -0000 On Monday, August 11, 2014, Adrian Chadd wrote: > On 11 August 2014 01:26, Victor Balada Diaz > wrote: > > On Mon, Aug 04, 2014 at 10:00:16AM -0700, Sushanth Rai via > freebsd-hackers wrote: > >> Hello, > >> > >> FreeBSD 10 release sources doesn't seem to have zero copy socket code > anymore. What's is alternative to do zero_copy ? > >> > >> Thanks, > >> Sushanth > > > > You need to use sendfile(2). In the man page is stated that the > implementation in FreeBSD > > is zero copy. > > > > You can also check: > > > > http://svnweb.freebsd.org/base?view=revision&revision=255608 > > > > I'd like to reintroduce a zero copy socket IO method for at least > write that doesn't rely on sendfile. > > The zero-copy socket page flipping thing was interesting because IIRC > tried to work for both sending and receiving socket data. Doing that > via an API would be nicer. > > So, if people have an idea for how it could be done / what the API > looks like then I'm all ears. > > What concerns me is how expensive it is to do the page flipping and tlb invalidation. Not saying that it cannot work, but isn't there a large set of constraints to make it worthwhile ? Cheers Luigi > > > -a > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org > " > -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 11 18:34:37 2014 Return-Path: Delivered-To: freebsd-hackers@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 B92B4F6; Mon, 11 Aug 2014 18:34:37 +0000 (UTC) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7984C20F8; Mon, 11 Aug 2014 18:34:37 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id rd18so10487246iec.28 for ; Mon, 11 Aug 2014 11:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=hqkOnNKr3RAdTdokn/2VS7jsiaf2dhI0CqeR4DdVNAE=; b=gD0rybZ8oh4eX2TNM3OdUQJyI+hNf2Yg+7KgoIgR/JZeJyD2Zm2Vt8uz6QPgyKwLjO yURW6iqfdI3PCsWchS9i9CChyfHZ3siNh37mHuusKb5KtpgAU3mzb4cotXzvnpAk6h3x u+dUFbteR6j5H6fmBtlsrq/13UDOHk0ycFUazJ+Z3mz2ogsoNWTBhjrhIF15k9an67kw LQSQDSAw1tOY1uJusw/yU9LKXfWCcT2zlbGKtglnv7HCCI4uBje3PuisWrJMeMXyZRsN uCoMvA1WZ84PnWN1kViVgTBMj8KOfhFXDOHnb+wIXx9KKk4VqF9Hy28deYQ79nZF3EZy 2HUg== MIME-Version: 1.0 X-Received: by 10.50.66.197 with SMTP id h5mr32950757igt.34.1407782076742; Mon, 11 Aug 2014 11:34:36 -0700 (PDT) Received: by 10.43.17.196 with HTTP; Mon, 11 Aug 2014 11:34:36 -0700 (PDT) Reply-To: alc@freebsd.org In-Reply-To: References: <1407171616.44440.YahooMailBasic@web181702.mail.ne1.yahoo.com> <20140811082610.GF7828@equilibrium.bsdes.net> Date: Mon, 11 Aug 2014 13:34:36 -0500 Message-ID: Subject: Re: Support for zero copy sockets From: Alan Cox To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Victor Balada Diaz , Sushanth Rai , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 18:34:37 -0000 The send path used an ad hoc copy-on-write mechanism, i.e., it was not the mechanism used by fork, etc. This mechanism was broken (and as I'll argue in a few sentences not worth fixing). The receive path used page flipping and required support from the NIC. Neither copy-on-write nor page flipping are viable approaches on today's multicore machines because their implementation entails interprocessor TLB shootdowns. Let them rest in peace. On Mon, Aug 11, 2014 at 1:04 PM, Adrian Chadd wrote: > On 11 August 2014 01:26, Victor Balada Diaz wrote: > > On Mon, Aug 04, 2014 at 10:00:16AM -0700, Sushanth Rai via > freebsd-hackers wrote: > >> Hello, > >> > >> FreeBSD 10 release sources doesn't seem to have zero copy socket code > anymore. What's is alternative to do zero_copy ? > >> > >> Thanks, > >> Sushanth > > > > You need to use sendfile(2). In the man page is stated that the > implementation in FreeBSD > > is zero copy. > > > > You can also check: > > > > http://svnweb.freebsd.org/base?view=revision&revision=255608 > > > > I'd like to reintroduce a zero copy socket IO method for at least > write that doesn't rely on sendfile. > > The zero-copy socket page flipping thing was interesting because IIRC > tried to work for both sending and receiving socket data. Doing that > via an API would be nicer. > > So, if people have an idea for how it could be done / what the API > looks like then I'm all ears. > > > > -a > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 11 19:11:54 2014 Return-Path: Delivered-To: freebsd-hackers@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 8F91AC1A; Mon, 11 Aug 2014 19:11:54 +0000 (UTC) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 54FBF25DF; Mon, 11 Aug 2014 19:11:54 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id lf10so11661478pab.1 for ; Mon, 11 Aug 2014 12:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=K9Deh/BJOzWHt/lejmly+350EqYV3dFNq9eHOgdQ9p0=; b=kNNtI5e4jxyjJzAoK162ML6AapY+hma5T53YZ9xozJ7gCV9IfQC+XscEEoZOgPB4CW kX9RhzvViEREbncaE1adlaf3mak5OBz83bWrbicimnOt8V8eG9EigaE6zy7+6G3R3yO/ LYKdNUkpN8CfhIQiG4FnRHQ00Bm/WMw1oPuBJGxLVjyI0NTbuVuYNC1mDtq7Et5wGMj6 9nOv7Rx4lRB+uI5qGUqvUDyG1+7HyF/sRbt6HnmlX4cwi+au2jCOVUuFaUkncA6ORC/l aqplVjg/urw2sUDUC/9drwho630NITxJfU44FYOmIHoGMmSaHBtiBZuY7jKnCE41npEB joKw== X-Received: by 10.68.164.4 with SMTP id ym4mr43778434pbb.53.1407784313998; Mon, 11 Aug 2014 12:11:53 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPSA id qt2sm12198434pbb.29.2014.08.11.12.11.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Aug 2014 12:11:53 -0700 (PDT) Sender: Navdeep Parhar Message-ID: <53E91578.3060209@FreeBSD.org> Date: Mon, 11 Aug 2014 12:11:52 -0700 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: alc@freebsd.org, Adrian Chadd Subject: Re: Support for zero copy sockets References: <1407171616.44440.YahooMailBasic@web181702.mail.ne1.yahoo.com> <20140811082610.GF7828@equilibrium.bsdes.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Victor Balada Diaz , Sushanth Rai , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 19:11:54 -0000 There is zero copy receive (aka Direct Data Placement -- DDP) in the TOE driver that accompanies cxgbe(4). I have a tx zero copy implementation for it as well (this is not in -current right now). But all this code is chip specific and applies only to TCP connections that are handled by the TOE driver. It doesn't rely on COW or page flipping. The reason I'm mentioning all of this here is that if anyone is thinking of working on proper zero copy awareness (and APIs) at the socket layer then count me in as an interested party. Regards, Navdeep On 08/11/14 11:34, Alan Cox wrote: > The send path used an ad hoc copy-on-write mechanism, i.e., it was not the > mechanism used by fork, etc. This mechanism was broken (and as I'll argue > in a few sentences not worth fixing). The receive path used page flipping > and required support from the NIC. Neither copy-on-write nor page flipping > are viable approaches on today's multicore machines because their > implementation entails interprocessor TLB shootdowns. Let them rest in > peace. > > > > > On Mon, Aug 11, 2014 at 1:04 PM, Adrian Chadd wrote: > >> On 11 August 2014 01:26, Victor Balada Diaz wrote: >>> On Mon, Aug 04, 2014 at 10:00:16AM -0700, Sushanth Rai via >> freebsd-hackers wrote: >>>> Hello, >>>> >>>> FreeBSD 10 release sources doesn't seem to have zero copy socket code >> anymore. What's is alternative to do zero_copy ? >>>> >>>> Thanks, >>>> Sushanth >>> >>> You need to use sendfile(2). In the man page is stated that the >> implementation in FreeBSD >>> is zero copy. >>> >>> You can also check: >>> >>> http://svnweb.freebsd.org/base?view=revision&revision=255608 >>> >> >> I'd like to reintroduce a zero copy socket IO method for at least >> write that doesn't rely on sendfile. >> >> The zero-copy socket page flipping thing was interesting because IIRC >> tried to work for both sending and receiving socket data. Doing that >> via an API would be nicer. >> >> So, if people have an idea for how it could be done / what the API >> looks like then I'm all ears. >> >> >> >> -a >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 11 19:35:50 2014 Return-Path: Delivered-To: freebsd-hackers@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 785B4C38 for ; Mon, 11 Aug 2014 19:35:50 +0000 (UTC) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx11.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FAF728B6 for ; Mon, 11 Aug 2014 19:35:50 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.01,843,1400050800"; d="asc'?scan'208";a="139550855" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx11-out.netapp.com with ESMTP; 11 Aug 2014 12:35:38 -0700 Received: from HIOEXCMBX04-PRD.hq.netapp.com (10.122.105.37) by vmwexceht06-prd.hq.netapp.com (10.106.77.104) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 11 Aug 2014 12:35:09 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx04-prd.hq.netapp.com (10.122.105.37) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 11 Aug 2014 12:35:08 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::f0de:b572:dd26:36b5%21]) with mapi id 15.00.0913.011; Mon, 11 Aug 2014 12:35:08 -0700 From: "Eggert, Lars" To: Cary Subject: Re: nscd not caching Thread-Topic: nscd not caching Thread-Index: AQHPtVuLYaAik14OAEOAejvgb8mhtJvMHc2AgAAjqwA= Date: Mon, 11 Aug 2014 19:35:07 +0000 Message-ID: <8068C863-0F02-45CF-AF15-C4230BE65255@netapp.com> References: <9F8FBD79-2825-4B22-BD14-EACF65A7DD50@netapp.com> <20140811172755.GA1414@SDF.ORG> In-Reply-To: <20140811172755.GA1414@SDF.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.120.60.36] Content-Type: multipart/signed; boundary="Apple-Mail=_83DFC463-1031-4683-8AEC-454DEB05FEE5"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 19:35:50 -0000 --Apple-Mail=_83DFC463-1031-4683-8AEC-454DEB05FEE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2014-8-11, at 19:27, Cary wrote: > Disabling nscd(8) was the only choice for me.=20 I need to authenticate against a remote NIS server, so disabling it = isn't really an option. I can't seem to *en*able it. Lars --Apple-Mail=_83DFC463-1031-4683-8AEC-454DEB05FEE5 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----- iQCVAwUBU+kbB9ZcnpRveo1xAQLmmQP/VDYlo76YHyw1l+1NzxXYRKvRNegFrV/J RjIvM2zcYrRGV3EB3hEjNDRlb9d4803wV258vcsSFPR8J1RQj430y27xcM8sFSRp MGUgBWsGC3SiBtlm8/FKtCr8ABfpqEc04i5YfwsBDxywBqR8i79iZSg2DTrh3CxJ BHEzS66wiyU= =JYyX -----END PGP SIGNATURE----- --Apple-Mail=_83DFC463-1031-4683-8AEC-454DEB05FEE5-- From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 12 00:42:28 2014 Return-Path: Delivered-To: freebsd-hackers@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 53F26767; Tue, 12 Aug 2014 00:42:28 +0000 (UTC) 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)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E69D12AE0; Tue, 12 Aug 2014 00:42:27 +0000 (UTC) Received: by mail-qc0-f179.google.com with SMTP id m20so2215634qcx.24 for ; Mon, 11 Aug 2014 17:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Lbkl6j84Y6Bn+dANLjsyYDW9oh15wo4oCj8VA7pdfHw=; b=nEaSareS4K9oqL2hpBP0GsDs3FRYmmyRYnV0SOqOujRd/lujF9cWwfVpQf3BswAPBK we3xJUTkg0VDfbkmW46waAqNfTnFKCSCV9LHd7TQvvxV51u54vfgxzOVyPX7DQvQ+wkp tIBKnv2JYQ3i+Re1LOMF6xjOr5lcrnQ6EtgumWnKQEAhHAOUosZNEVUT84FzDNrPZ30q bF8kNoUX/jmdLOPAj21fGxGDAS2hOFEwIORFZ8rivh/P3qCmk1ZJIfGFCi/UVs9FU52a OVUo5htpGZxg0C6yOyG7KgYy9oYe8c8CKEQpY8saRHDQMjKeGzGm2wWcbgQojled8kIY V0bA== MIME-Version: 1.0 X-Received: by 10.224.3.67 with SMTP id 3mr1404127qam.26.1407804147115; Mon, 11 Aug 2014 17:42:27 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.41.6 with HTTP; Mon, 11 Aug 2014 17:42:27 -0700 (PDT) In-Reply-To: <53E91578.3060209@FreeBSD.org> References: <1407171616.44440.YahooMailBasic@web181702.mail.ne1.yahoo.com> <20140811082610.GF7828@equilibrium.bsdes.net> <53E91578.3060209@FreeBSD.org> Date: Mon, 11 Aug 2014 17:42:27 -0700 X-Google-Sender-Auth: Md-XY1XvlhR4FuRMM_BQKBgHkiQ Message-ID: Subject: Re: Support for zero copy sockets From: Adrian Chadd To: Navdeep Parhar Content-Type: text/plain; charset=UTF-8 Cc: Alan Cox , Victor Balada Diaz , Sushanth Rai , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 00:42:28 -0000 On 11 August 2014 12:11, Navdeep Parhar wrote: > There is zero copy receive (aka Direct Data Placement -- DDP) in the TOE > driver that accompanies cxgbe(4). I have a tx zero copy implementation > for it as well (this is not in -current right now). But all this code > is chip specific and applies only to TCP connections that are handled > by the TOE driver. It doesn't rely on COW or page flipping. > > The reason I'm mentioning all of this here is that if anyone is thinking > of working on proper zero copy awareness (and APIs) at the socket layer > then count me in as an interested party. I'm not going to get into it just for now, as I have enough on my FreeBSD plate to do already. However, the thing that always irked me about the hardware based solutions is that they're great for a subset of problems - typically small sets of sockets. The real interesting problem for me is how to make it work for say, 500,000 or more concurrent TCP sessions. I can see a method of doing zero-copy writes to the network stack - look at what the AIO code does in the physical IO path for doing writes. It wires down the memory and stuffs it into the buffer. The thing I haven't yet sorted out is what to do about mappings in case kernel code wants to peek at the socket data payload for whatever reason. (And yes, reads are still a problem.) -a From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 12 01:52:40 2014 Return-Path: Delivered-To: freebsd-hackers@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 1F9F03AC; Tue, 12 Aug 2014 01:52:40 +0000 (UTC) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D86D721E8; Tue, 12 Aug 2014 01:52:39 +0000 (UTC) Received: by mail-pd0-f179.google.com with SMTP id v10so5732184pde.24 for ; Mon, 11 Aug 2014 18:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=w8A+F6vYNVcN5wnSyxQvNxjjn47bh3vBPICM8MPx520=; b=d3QrfY9JhYRGc7ly2emQZMM4/Jni5L6Pzo7DxcJSapkMq4h5w0iNvuEd/lnCDN2yx2 c+Fd2uN0Mo5lAysopoRZyac7ubkCJdUDhP5JayUXa/nS7zaRK1tAkEq+Zmdicjq6cCtR gvdyPHEdZ1aKKbgyCbnQjdKkgiPbDJu0UKAbAm4uGGTLGXkHwix9aO12zyQt3bBiS0sK av7ZPo6cO+u8sHB07+N+gISMBnk6zZuw6LWesA1OMO63LdKco7DMzVI737EBQBxOUxyz 0TQKYL2rR1ng9s+qzyYcmlyebUWdWrdjGEx6o9GDHxy6BfPRpRo8vYsJszDqbNtRav4L qppQ== X-Received: by 10.70.89.76 with SMTP id bm12mr1439355pdb.40.1407808359462; Mon, 11 Aug 2014 18:52:39 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPSA id f12sm7471604pat.19.2014.08.11.18.52.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Aug 2014 18:52:38 -0700 (PDT) Sender: Navdeep Parhar Message-ID: <53E97365.6040405@FreeBSD.org> Date: Mon, 11 Aug 2014 18:52:37 -0700 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Support for zero copy sockets References: <1407171616.44440.YahooMailBasic@web181702.mail.ne1.yahoo.com> <20140811082610.GF7828@equilibrium.bsdes.net> <53E91578.3060209@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Alan Cox , Victor Balada Diaz , Sushanth Rai , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 01:52:40 -0000 On 08/11/14 17:42, Adrian Chadd wrote: > On 11 August 2014 12:11, Navdeep Parhar wrote: >> There is zero copy receive (aka Direct Data Placement -- DDP) in the TOE >> driver that accompanies cxgbe(4). I have a tx zero copy implementation >> for it as well (this is not in -current right now). But all this code >> is chip specific and applies only to TCP connections that are handled >> by the TOE driver. It doesn't rely on COW or page flipping. >> >> The reason I'm mentioning all of this here is that if anyone is thinking >> of working on proper zero copy awareness (and APIs) at the socket layer >> then count me in as an interested party. > > I'm not going to get into it just for now, as I have enough on my > FreeBSD plate to do already. I'm in the same situation. > > However, the thing that always irked me about the hardware based > solutions is that they're great for a subset of problems - typically > small sets of sockets. The real interesting problem for me is how to > make it work for say, 500,000 or more concurrent TCP sessions. The hardware based solutions that I'm familiar with can handle tens of thousands of TCP sockets concurrently. The protocol processing is entirely on the chip and when DDP is active the chip can DMA the payload straight to its final destination -- typically a userspace buffer. The only VM operation involved is wiring and then unwiring the uio. The complication is that the driver (cxgbe's t4_tom in this case) has absolutely no idea what an application does (blocking read vs. poll/select+read vs. aio_read vs. ...) so it makes some safe but suboptimal choices. It would be nice if there were an API (very vaguely along the lines of madvise but for sockets, or maybe a sockopt knob) that an application could use to provide hints about its behavior. We could also do with separate zero-copy flavors of the sosend/soreceive usrreqs. And more hints (per read/write operation) that might let us avoid even the wire/unwire operation. Anyway, let's save this discussion for later, when either of us has the time to come up with a specific set of proposals for -net and -arch. Regards, Navdeep > > I can see a method of doing zero-copy writes to the network stack - > look at what the AIO code does in the physical IO path for doing > writes. It wires down the memory and stuffs it into the buffer. > > The thing I haven't yet sorted out is what to do about mappings in > case kernel code wants to peek at the socket data payload for whatever > reason. > > (And yes, reads are still a problem.) > > > > -a > From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 12 08:19:13 2014 Return-Path: Delivered-To: freebsd-hackers@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 3F26B115 for ; Tue, 12 Aug 2014 08:19:13 +0000 (UTC) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.226]) by mx1.freebsd.org (Postfix) with ESMTP id 04620284E for ; Tue, 12 Aug 2014 08:19:12 +0000 (UTC) Received: from [72.132.160.201] ([72.132.160.201:55568] helo=bsdfull.Belkin) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 5B/DC-00396-6BDC9E35; Tue, 12 Aug 2014 08:18:00 +0000 Message-ID: <53E9CDA7.2020600@SDF.org> Date: Tue, 12 Aug 2014 01:17:43 -0700 From: Cary User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 To: "Eggert, Lars" Subject: Re: nscd not caching References: <9F8FBD79-2825-4B22-BD14-EACF65A7DD50@netapp.com> <20140811172755.GA1414@SDF.ORG> <8068C863-0F02-45CF-AF15-C4230BE65255@netapp.com> In-Reply-To: <8068C863-0F02-45CF-AF15-C4230BE65255@netapp.com> X-Enigmail-Version: 1.6.1_pre20140112 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 08:19:13 -0000 Eggert, Lars wrote: > On 2014-8-11, at 19:27, Cary wrote: >> Disabling nscd(8) was the only choice for me. > > I need to authenticate against a remote NIS server, so disabling it isn't > really an option. I can't seem to *en*able it. > > Lars > perform-actual-lookups services yes perform-actual-lookups passwd yes perform-actual-lookups group yes In /etc/nscd.conf you might add the lines above. That would configure nscd to do more than cache. It may also give you some sign whether it's doing anything at all. Cary -- cary@sdf.org SDF Public Access UNIX System - http://sdf.org ------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 12 08:33:34 2014 Return-Path: Delivered-To: freebsd-hackers@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 08F025A4 for ; Tue, 12 Aug 2014 08:33:34 +0000 (UTC) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx11.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D59A52A11 for ; Tue, 12 Aug 2014 08:33:33 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.01,847,1400050800"; d="asc'?scan'208";a="139652072" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx11-out.netapp.com with ESMTP; 12 Aug 2014 01:33:32 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by vmwexceht06-prd.hq.netapp.com (10.106.77.104) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 12 Aug 2014 01:33:03 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 12 Aug 2014 01:33:02 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::f0de:b572:dd26:36b5%21]) with mapi id 15.00.0913.011; Tue, 12 Aug 2014 01:33:02 -0700 From: "Eggert, Lars" To: Cary Subject: Re: nscd not caching Thread-Topic: nscd not caching Thread-Index: AQHPtVuLYaAik14OAEOAejvgb8mhtJvMHc2AgAAjqwCAANTxgIAABGyA Date: Tue, 12 Aug 2014 08:33:02 +0000 Message-ID: <6FDCA8B5-AD2D-4A8F-A6AC-95AD69C8E227@netapp.com> References: <9F8FBD79-2825-4B22-BD14-EACF65A7DD50@netapp.com> <20140811172755.GA1414@SDF.ORG> <8068C863-0F02-45CF-AF15-C4230BE65255@netapp.com> <53E9CDA7.2020600@SDF.org> In-Reply-To: <53E9CDA7.2020600@SDF.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_D3AE0375-1454-4889-8460-5417E9005DA2"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 08:33:34 -0000 --Apple-Mail=_D3AE0375-1454-4889-8460-5417E9005DA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2014-8-12, at 10:17, Cary wrote: > perform-actual-lookups services yes > perform-actual-lookups passwd yes > perform-actual-lookups group yes >=20 > In /etc/nscd.conf you might add the lines above. That would configure = nscd to > do more than cache. It may also give you some sign whether it's = doing > anything at all. If I do that, I get messages in the nscd trace such as : E2 from write_request: entry 'group' performs lookups by itself: can't = write to it E2 from write_request: entry 'passwd' performs lookups by itself: can't = write to it At first I thought it was because of + lines in /etc/group and = /etc/passwd, but even if I take those out I get these messages. Lookup speed still slow, cache doesn't seem to be used. Lars --Apple-Mail=_D3AE0375-1454-4889-8460-5417E9005DA2 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----- iQCVAwUBU+nRXdZcnpRveo1xAQIrygP/X28RWXKmMhuES9BYQK3Sy/Fg+cGmlqU6 3S6juTLBFBUeIi+Ev1NKrROEmunKPAd9Ayrc9g08c3/2RejhBgYroZ8hfXAE5Nsk KrLakU75mE1LhZonZXhu9JIPrWC+XY2izMj6jofMRIgG/A2IRBOZF/HjnHXYkRQe zX9PLhecPUI= =XqhO -----END PGP SIGNATURE----- --Apple-Mail=_D3AE0375-1454-4889-8460-5417E9005DA2-- From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 12 09:11:44 2014 Return-Path: Delivered-To: freebsd-hackers@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 4D97562D for ; Tue, 12 Aug 2014 09:11:44 +0000 (UTC) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.228]) by mx1.freebsd.org (Postfix) with ESMTP id 119972FD8 for ; Tue, 12 Aug 2014 09:11:43 +0000 (UTC) Received: from [72.132.160.201] ([72.132.160.201:40452] helo=bsdfull.Belkin) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id A5/56-00396-889D9E35; Tue, 12 Aug 2014 09:08:25 +0000 Message-ID: <53E9D986.8000605@SDF.org> Date: Tue, 12 Aug 2014 02:08:22 -0700 From: Cary User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 To: "Eggert, Lars" Subject: Re: nscd not caching References: <9F8FBD79-2825-4B22-BD14-EACF65A7DD50@netapp.com> <20140811172755.GA1414@SDF.ORG> <8068C863-0F02-45CF-AF15-C4230BE65255@netapp.com> <53E9CDA7.2020600@SDF.org> <6FDCA8B5-AD2D-4A8F-A6AC-95AD69C8E227@netapp.com> In-Reply-To: <6FDCA8B5-AD2D-4A8F-A6AC-95AD69C8E227@netapp.com> X-Enigmail-Version: 1.6.1_pre20140112 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 09:11:44 -0000 Eggert, Lars wrote: > Hi, > > On 2014-8-12, at 10:17, Cary wrote: >> perform-actual-lookups services yes perform-actual-lookups passwd yes >> perform-actual-lookups group yes >> >> In /etc/nscd.conf you might add the lines above. That would configure >> nscd to do more than cache. It may also give you some sign whether it's >> doing anything at all. > > If I do that, I get messages in the nscd trace such as : > > E2 from write_request: entry 'group' performs lookups by itself: can't > write to it E2 from write_request: entry 'passwd' performs lookups by > itself: can't write to it > > At first I thought it was because of + lines in /etc/group and /etc/passwd, > but even if I take those out I get these messages. > > Lookup speed still slow, cache doesn't seem to be used. > > Lars > I've only been using nscd attempting to cache hosts. Using it again, I'm not having the problems I had before, but the trace does not show any activity either. The issue before was that getting rss messages would lock up the browser or make it segfault. There was a domain that would not resolve at that time because the server for the feed was down for several days. When I stopped running nscd there were no more segfaults or lockups. Cary -- cary@sdf.org SDF Public Access UNIX System - http://sdf.org ------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 12 09:54:30 2014 Return-Path: Delivered-To: freebsd-hackers@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 017132F9 for ; Tue, 12 Aug 2014 09:54:30 +0000 (UTC) Received: from natasha.panasas.com (natasha.panasas.com [209.166.131.148]) by mx1.freebsd.org (Postfix) with ESMTP id A4C7424ED for ; Tue, 12 Aug 2014 09:54:29 +0000 (UTC) Received: from seabiscuit.panasas.com (seabiscuit.panasas.com [172.17.132.204]) by natasha.panasas.com (8.13.1/8.13.1) with ESMTP id s7C6uRm6001788 for ; Tue, 12 Aug 2014 02:56:27 -0400 Received: from SEABISCUIT.int.panasas.com ([172.17.132.204]) by seabiscuit ([172.17.132.204]) with mapi id 14.03.0181.006; Mon, 11 Aug 2014 23:56:26 -0700 From: "Pokala, Ravi" To: "freebsd-hackers@freebsd.org" Subject: IO chunking Thread-Topic: IO chunking Thread-Index: AQHPtfqI63Kw96jg+06V8le/JTT3Wg== Date: Tue, 12 Aug 2014 06:56:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [172.17.28.63] Content-Type: text/plain; charset="us-ascii" Content-ID: <5E483D88CA179944B0C3C8525A9DF361@panasas.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 09:54:30 -0000 Hi folks, I'm doing moderately-large block IO (16KB - 1MB) directly against drive devices (i.e. /dev/adaX), and I see that `iostat -d adaX' reports a transaction size of at most 128KB. I believe this is because transactions are limited to at most MAXPHYS bytes (128KB), and requests larger than that are broken into smaller chunks; is that correct? If so, where does that chunking happen? In low-level GEOM code (geom_io.c, geom_dev.c)? In CAM? In the drive device driver? In VFS? The context here is that I'm doing some testing in multiples of the drive's logical sector size. At low LBAs, SATA allows up to 256 sectors per command; (256 sectors) * (512B / sector) =3D 128KB =3D=3D MAXPHYS, so w= e can reach maximum sector counts w/o chunking on 512n or AF-512e drives. However, on AF-4Kn drives, (128KB / txn) * (sector / 4KB) =3D (32 sectors / txn), so chunking happens well before maxing out the SATA command (256 sectors). Any pointers? Thanks, Ravi From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 12 12:55:46 2014 Return-Path: Delivered-To: freebsd-hackers@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 EA78C6B6; Tue, 12 Aug 2014 12:55:46 +0000 (UTC) Received: from mailout07.t-online.de (mailout07.t-online.de [194.25.134.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ADAE72A80; Tue, 12 Aug 2014 12:55:46 +0000 (UTC) Received: from fwd11.aul.t-online.de (fwd11.aul.t-online.de [172.20.27.152]) by mailout07.t-online.de (Postfix) with SMTP id 3E17B3DAD63; Tue, 12 Aug 2014 14:55:38 +0200 (CEST) Received: from [192.168.119.33] (Xje78OZbohuGYZbsSVs0prcYnTBoZFBTwLo0kDYy5oN6MTvQd6uYdumtL5wYfIoweD@[84.154.101.219]) by fwd11.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XHBbz-0xFULw0; Tue, 12 Aug 2014 14:55:35 +0200 Message-ID: <53EA0EC2.2070601@freebsd.org> Date: Tue, 12 Aug 2014 14:55:30 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Aleksandr Rybalko Subject: Keymap definitions for VT / NEWCONS Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ID: Xje78OZbohuGYZbsSVs0prcYnTBoZFBTwLo0kDYy5oN6MTvQd6uYdumtL5wYfIoweD X-TOI-MSGID: 2d312942-e45f-4730-9afe-b4113dbfa7b1 Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 12:55:47 -0000 Hi Aleksandr, I have converted quite a number of the SYSCONS keymaps to NEWCONS format, using your script (uakbd2ukbd.pl). Many conversions lead to identical files for NEWCONS, some had a just a few replaced characters (e.g. Turkish or Brasilian keymaps). I verified quite a number of single characters using web resources (e.g. http://www.decodeunicode.org/ and keyboard layout images at http://http://ascii-table.com/keyboard.php/275 - replace number at the end for other locales). When there were different source encodings (e.g. German ISO8859-1 and CP850), I compared those too - the results should have been identical. In fact, there were minor changes and the version that had been converted from ISO was better than the one from CP850, with the exception of a single shifted key. I want to commit the conversion results to share/vt/keymaps, if you don't mind. In a first step, I want to commit those keymaps that I think are correct (either because they are identical to the SYSCONS keymaps, or because I checked them against web resources). I did not know how to deal with Dvorak keymaps (especially since they are not named according to the encoding used for SYSCONS), they can come later. These keymaps should be committed in time for 10.1, since NEWCONS is in GENERIC and people will expect them. When these maps are committed to -CURRENT, I can remove the hack that made kbdcontrol lookup keymaps under share/syscons/keymaps as a fall-back. This hack will not be merged to 10-STABLE ... One minor point: I want to commit the keymaps under names that just consist of the country code and ".kbd" (e.g. "us.kbd"), since only Unicode encoding is supported/required. Keyboards with accented characters will be named like "us.acc.kbd". I'm planning to commit the keymap files that I have on Thursday, if there are no objections. Regards, STefan PS: I have the keymaps that are ready to commit uploaded to: http://people.freebsd.org/~se/vt-keymaps.tar.bz2 (This file includes the 3 sample keymaps that already are in SVN since I did not exclude them when tarring ...) From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 12 14:03:05 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E9F9AAA; Tue, 12 Aug 2014 14:03:05 +0000 (UTC) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 4F62F1FE6; Tue, 12 Aug 2014 14:03:04 +0000 (UTC) Message-ID: <53EA1E5A.5020707@FreeBSD.org> Date: Tue, 12 Aug 2014 18:02:02 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Stefan Esser , Aleksandr Rybalko Subject: Re: Keymap definitions for VT / NEWCONS References: <53EA0EC2.2070601@freebsd.org> In-Reply-To: <53EA0EC2.2070601@freebsd.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 14:03:05 -0000 On 12.08.2014 16:55, Stefan Esser wrote: > I'm planning to commit the keymap files that I have on Thursday, > if there are no objections. > > Regards, STefan > > PS: I have the keymaps that are ready to commit uploaded to: > http://people.freebsd.org/~se/vt-keymaps.tar.bz2 > (This file includes the 3 sample keymaps that already are > in SVN since I did not exclude them when tarring ...) Hi, I tried converted keymap from ru.koi8-r.win.kbd, seems work as expected. -- WBR, Andrey V. Elsukov From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 12 15:04:41 2014 Return-Path: Delivered-To: freebsd-hackers@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 AF621338; Tue, 12 Aug 2014 15:04:41 +0000 (UTC) Received: from mailout11.t-online.de (mailout11.t-online.de [194.25.134.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F5F32BAD; Tue, 12 Aug 2014 15:04:40 +0000 (UTC) Received: from fwd01.aul.t-online.de (fwd01.aul.t-online.de [172.20.27.147]) by mailout11.t-online.de (Postfix) with SMTP id 1F4FD5C0147; Tue, 12 Aug 2014 17:04:39 +0200 (CEST) Received: from [192.168.119.33] (E6MSReZC8hyzJ04PpNvzXgZj2EZoaLSWjnYwYGawTuKYuVQE7KZE0hXrQCaOWxWZOl@[84.154.101.219]) by fwd01.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XHDcr-2mFlSq0; Tue, 12 Aug 2014 17:04:37 +0200 Message-ID: <53EA2D00.7010307@freebsd.org> Date: Tue, 12 Aug 2014 17:04:32 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Andrey V. Elsukov" Subject: Re: Keymap definitions for VT / NEWCONS References: <53EA0EC2.2070601@freebsd.org> <53EA1E5A.5020707@FreeBSD.org> In-Reply-To: <53EA1E5A.5020707@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ID: E6MSReZC8hyzJ04PpNvzXgZj2EZoaLSWjnYwYGawTuKYuVQE7KZE0hXrQCaOWxWZOl X-TOI-MSGID: 77786e49-8656-43bb-80d9-4dea12a803c1 Cc: freebsd-hackers@freebsd.org, Aleksandr Rybalko , freebsd-stable@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 15:04:41 -0000 Am 12.08.2014 um 16:02 schrieb Andrey V. Elsukov: > On 12.08.2014 16:55, Stefan Esser wrote: >> I'm planning to commit the keymap files that I have on Thursday, >> if there are no objections. >> >> Regards, STefan >> >> PS: I have the keymaps that are ready to commit uploaded to: >> http://people.freebsd.org/~se/vt-keymaps.tar.bz2 >> (This file includes the 3 sample keymaps that already are >> in SVN since I did not exclude them when tarring ...) > > Hi, > > I tried converted keymap from ru.koi8-r.win.kbd, seems work as expected. The KOI8-R and KOI8-U keymaps are among those that I tried to convert. But I do not know which of the 5 variants are relevant: - ru.cp866.kbd - ru.iso5.kbd - ru.koi8-r.kbd - ru.koi8-r.shift.kbd - ru.koi8-r.win.kbd For example "ru.koi8-r.kbd" and "ru.koi8-r.shift.kbd" differ only in that the ".shift" version has the digits on shifted key positions. The ".shift" and ".win" keymaps are quite similar, except for Shift-3, Shift-5..7 and a few control and function keys. I guess there will be 3 converted maps, that are actually needed, all derived from KOI8-R encoded files: - ru.kbd - ru.win.kbd - ru.shift.kbd This is my list of converted keymaps I'm ready to commit: be.acc.kbd be.kbd br275.acc.kbd br275.kbd by.kbd ce.kbd colemak.acc.kbd danish.acc.kbd danish.kbd danish.macbook.kbd dutch.acc.kbd estonian.kbd finnish.kbd fr.acc.kbd fr.kbd fr_CA.acc.kbd german.acc.kbd german.kbd hr.kbd icelandic.acc.kbd icelandic.kbd it.kbd jp.pc98.kbd latinamerican.acc.kbd lt.kbd norwegian.kbd pt.acc.kbd pt.kbd si.kbd spanish.acc.kbd spanish.kbd swedish.kbd swissfrench.acc.kbd swissfrench.kbd swissgerman.acc.kbd swissgerman.kbd tr.kbd uk.kbd us.acc.kbd us.kbd Regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 12 18:05:27 2014 Return-Path: Delivered-To: freebsd-hackers@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 1425F86F; Tue, 12 Aug 2014 18:05:27 +0000 (UTC) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D08D63730; Tue, 12 Aug 2014 17:57:49 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id wp18so7437408obc.20 for ; Tue, 12 Aug 2014 10:57:49 -0700 (PDT) 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=+fjcuq4XFfTX/Opx4ENC9IBsSVr7afzPqjnlTilKLcs=; b=W/3a5iFrnCkgb4TRL/UtTA+FVa/3gDlhZ0Uh2nw27wI0nlMLVzhGXE4XWwwelcxltJ f6TlykxZUpy5awf5V2AXUfe34y+uui/fA4e7/+lKkHAYAn2Lr4lBnzY90aKIapNRLKqT FZzmGV2544OSIHNN67uxkkNsLNH180tof3eIPJBBGUIsdMqxCCekhg3zAzhlpP/V6rqt SbC2wOEezr7JK3DyVVLbWTzz0g+zs1y2ez5MZ5HvcxA8Kabl0jp3SjB2f7TRJnWTicWj 8ogBLxCipJILKZthmt5WbzdTEVzQsd+CfxYmRlRgl/TQzdDKFO7+k779K/pysvH/sVa9 fSiA== MIME-Version: 1.0 X-Received: by 10.60.161.49 with SMTP id xp17mr6752847oeb.18.1407866269052; Tue, 12 Aug 2014 10:57:49 -0700 (PDT) Received: by 10.182.216.200 with HTTP; Tue, 12 Aug 2014 10:57:49 -0700 (PDT) In-Reply-To: <53EA2D00.7010307@freebsd.org> References: <53EA0EC2.2070601@freebsd.org> <53EA1E5A.5020707@FreeBSD.org> <53EA2D00.7010307@freebsd.org> Date: Tue, 12 Aug 2014 19:57:49 +0200 Message-ID: Subject: Re: Keymap definitions for VT / NEWCONS From: Oliver Pinter To: Stefan Esser Content-Type: text/plain; charset=ISO-8859-1 Cc: "Andrey V. Elsukov" , Aleksandr Rybalko , freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 18:05:27 -0000 On 8/12/14, Stefan Esser wrote: > Am 12.08.2014 um 16:02 schrieb Andrey V. Elsukov: >> On 12.08.2014 16:55, Stefan Esser wrote: >>> I'm planning to commit the keymap files that I have on Thursday, >>> if there are no objections. >>> >>> Regards, STefan >>> >>> PS: I have the keymaps that are ready to commit uploaded to: >>> http://people.freebsd.org/~se/vt-keymaps.tar.bz2 >>> (This file includes the 3 sample keymaps that already are >>> in SVN since I did not exclude them when tarring ...) >> >> Hi, >> >> I tried converted keymap from ru.koi8-r.win.kbd, seems work as expected. > > The KOI8-R and KOI8-U keymaps are among those that I tried > to convert. > > But I do not know which of the 5 variants are relevant: > > - ru.cp866.kbd > - ru.iso5.kbd > - ru.koi8-r.kbd > - ru.koi8-r.shift.kbd > - ru.koi8-r.win.kbd > > For example "ru.koi8-r.kbd" and "ru.koi8-r.shift.kbd" differ > only in that the ".shift" version has the digits on shifted > key positions. The ".shift" and ".win" keymaps are quite > similar, except for Shift-3, Shift-5..7 and a few control > and function keys. > > I guess there will be 3 converted maps, that are actually > needed, all derived from KOI8-R encoded files: > > - ru.kbd > - ru.win.kbd > - ru.shift.kbd > > This is my list of converted keymaps I'm ready to commit: > > be.acc.kbd > be.kbd > br275.acc.kbd > br275.kbd > by.kbd > ce.kbd > colemak.acc.kbd > danish.acc.kbd > danish.kbd > danish.macbook.kbd > dutch.acc.kbd > estonian.kbd > finnish.kbd > fr.acc.kbd > fr.kbd > fr_CA.acc.kbd > german.acc.kbd > german.kbd > hr.kbd > icelandic.acc.kbd > icelandic.kbd > it.kbd > jp.pc98.kbd > latinamerican.acc.kbd > lt.kbd > norwegian.kbd > pt.acc.kbd > pt.kbd > si.kbd > spanish.acc.kbd > spanish.kbd > swedish.kbd > swissfrench.acc.kbd > swissfrench.kbd > swissgerman.acc.kbd > swissgerman.kbd > tr.kbd > uk.kbd > us.acc.kbd > us.kbd > > Regards, STefan Hi! I like to see the us.pc-crtrl.kbd too in this list. How can I convert this in fastest way? > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 12 18:07:49 2014 Return-Path: Delivered-To: freebsd-hackers@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 7665AEEC for ; Tue, 12 Aug 2014 18:07:49 +0000 (UTC) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3C9E139B5 for ; Tue, 12 Aug 2014 18:07:49 +0000 (UTC) Received: by mail-qc0-f175.google.com with SMTP id w7so3157327qcr.6 for ; Tue, 12 Aug 2014 11:07:48 -0700 (PDT) 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=9CdFc5XvMU2ICY9dWyF5as+cjd+74hANGL/IigzleGA=; b=Qk3F7mxq8x+zHXJqWyYbG04NKhrPxU5HZpphYB4DGkLiIRTWLlcJiVwRbpPigmDglm S/eum2739BqLqgAD+kDn9lTd4oHwqWoGzX45s+ww3emdMWx+VHMifn67b+PEACwpFOCN csSWepZqDr3Bq87fn4OkQCbsJOrUX3v23DtvIwF+yBhhsfHrishetxVMJKqXAuXid9Ps oM3Ngx9nUrpi/kWo9frrLjQJnf8L8CMi9VdoQLUvcnCysG1k9eVhPREjIxHEWVtTkHbc CjyLfwn5UqHpmsgLsNkrkuDCckCg0WWSIRrhvXpvL+bDHVpwuxYmpLzYwkvucXsCK/fK byxA== MIME-Version: 1.0 X-Received: by 10.229.38.3 with SMTP id z3mr9233538qcd.17.1407866868358; Tue, 12 Aug 2014 11:07:48 -0700 (PDT) Received: by 10.140.94.42 with HTTP; Tue, 12 Aug 2014 11:07:48 -0700 (PDT) Date: Tue, 12 Aug 2014 15:07:48 -0300 Message-ID: Subject: The use of C language is avoided in FreeBSD development? From: =?UTF-8?Q?fran=C3=A7ai_s?= To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 18:07:49 -0000 The use of C language is avoided in FreeBSD development? I ask this because second Eric Raymond in 'How To Become A Hacker', actually, the more you can avoid programming in C the more productive you will be. reference:http://www.catb.org/~esr/faqs/hacker-howto.html From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 12 18:12:04 2014 Return-Path: Delivered-To: freebsd-hackers@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 243BBBF8; Tue, 12 Aug 2014 18:12:04 +0000 (UTC) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A348F3414; Tue, 12 Aug 2014 17:40:57 +0000 (UTC) Received: by mail-ig0-f181.google.com with SMTP id h3so7455917igd.2 for ; Tue, 12 Aug 2014 10:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=x6Qs4X/SPePJIGliBQul8yyQNJ1JgANQLUyrP9/N6W0=; b=ZhyqG944eMzfUiZTnGq7thUaayy5gfMQiiEW3JykpbUmqy8lPOE4dl5tzhUk0NoxCV gEh8ZBC71VdATdWci78T0UsZ86DvSeIC7tWIw6STIMg7dY/Cl8kNa+3iJLb8vIGQAsZl vwdoq2DaFyezWQXoFADh6eWfr1/rRM7wLDuTllJofTtbdQx4sWUMkb+rbV41a/ShLnsK cjLfahPyHdXsV3cc6C2swAM7pFUmda25lS71WdAmXJwOgqa4LgCnSNcPzrdXd0QW0L3s TfZECN5o1hCGAmyZqbjBT6mZW2pVCtr+V6movnakAbQUh2gXqHibg94I7ds2OuiGeSV0 yFQQ== X-Received: by 10.42.83.131 with SMTP id h3mr38196icl.77.1407865257125; Tue, 12 Aug 2014 10:40:57 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.131.38 with HTTP; Tue, 12 Aug 2014 10:40:36 -0700 (PDT) In-Reply-To: <53EA2D00.7010307@freebsd.org> References: <53EA0EC2.2070601@freebsd.org> <53EA1E5A.5020707@FreeBSD.org> <53EA2D00.7010307@freebsd.org> From: Ed Maste Date: Tue, 12 Aug 2014 13:40:36 -0400 X-Google-Sender-Auth: boTxfKxnkjw9Qm2Ra3DCbvJekJA Message-ID: Subject: Re: Keymap definitions for VT / NEWCONS To: Stefan Esser Content-Type: text/plain; charset=UTF-8 Cc: "Andrey V. Elsukov" , Aleksandr Rybalko , freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 18:12:04 -0000 On 12 August 2014 11:04, Stefan Esser wrote: > This is my list of converted keymaps I'm ready to commit: ... > danish.acc.kbd > danish.kbd I wonder if we should use this opportunity to rationalize the keyboard layout names, using two letter codes consistently (so dk.kbd). This would also bring consistency with the X11 keyboard layout codes. We'll already have some churn in rc.conf settings related to screen maps / fonts, so this may not be too much of a burden. From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 12 18:26:33 2014 Return-Path: Delivered-To: freebsd-hackers@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 7BAAB210 for ; Tue, 12 Aug 2014 18:26:33 +0000 (UTC) Received: from smtp125.ord1c.emailsrvr.com (smtp125.ord1c.emailsrvr.com [108.166.43.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FB8A3CD8 for ; Tue, 12 Aug 2014 18:26:33 +0000 (UTC) Received: from smtp16.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp16.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id A725838032F for ; Tue, 12 Aug 2014 14:20:40 -0400 (EDT) X-SMTPDoctor-Processed: csmtpprox 2.7.1 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp16.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id A46CD38094C for ; Tue, 12 Aug 2014 14:20:40 -0400 (EDT) X-Virus-Scanned: OK Received: from smtp192.mex05.mlsrvr.com (unknown [184.106.31.85]) by smtp16.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTPS id 93AF038032F for ; Tue, 12 Aug 2014 14:20:40 -0400 (EDT) Received: from ORD2MBX06A.mex05.mlsrvr.com ([fe80::a036:9fff:fe1e:ecd8]) by ORD2HUB26.mex05.mlsrvr.com ([fe80::be30:5bff:fef4:9240%15]) with mapi id 14.03.0169.001; Tue, 12 Aug 2014 13:20:40 -0500 From: Gerry Weaver To: "freebsd-hackers@freebsd.org" Subject: RE: The use of C language is avoided in FreeBSD development? Thread-Topic: The use of C language is avoided in FreeBSD development? Thread-Index: AQHPtlhX+nIPWMFhYE2FPiqAy8ExUJvNR0TA Date: Tue, 12 Aug 2014 18:20:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.252.2.26] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 18:26:33 -0000 Hi, That would seem to rather difficult considering the fact that the entire OS= is written in it. If you want to hack on FreeBSD, you should learn and use= C. If you're new to programming in general, you should also learn C. Your = code will thank you for it regardless of the language(s) you ultimately end= up using. Another added bonus is that you won't spend the rest of your day= s trying to justify the fact that you didn't learn it ;) Thanks, -G -----Original Message----- From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd-hackers@freeb= sd.org] On Behalf Of fran=E7ai s Sent: Tuesday, August 12, 2014 1:08 PM To: freebsd-hackers@freebsd.org Subject: The use of C language is avoided in FreeBSD development? The use of C language is avoided in FreeBSD development? I ask this because= second Eric Raymond in 'How To Become A Hacker', actually, the more you ca= n avoid programming in C the more productive you will be. reference:http://www.catb.org/~esr/faqs/hacker-howto.html _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/l= istinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 12 19:12:59 2014 Return-Path: Delivered-To: freebsd-hackers@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 372B41AD for ; Tue, 12 Aug 2014 19:12:59 +0000 (UTC) Received: from um-tip2-missouri-out.um.umsystem.edu (um-tip2-missouri-out.um.umsystem.edu [198.209.49.149]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "um-tip1.um.umsystem.edu", Issuer "InCommon Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E264A2269 for ; Tue, 12 Aug 2014 19:12:58 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFABxm6lPPoJ7S/2dsb2JhbABaFoJ3UlcEzS+HSAGBFBZ3hAQBBWgFCxECAQgYCRYPCQMCAQIBICUCBAEMCAEBBYg5DbctiQ+EbBeJf4UaNQWETAWRHaAag1xsAYFH X-IPAS-Result: AhoFABxm6lPPoJ7S/2dsb2JhbABaFoJ3UlcEzS+HSAGBFBZ3hAQBBWgFCxECAQgYCRYPCQMCAQIBICUCBAEMCAEBBYg5DbctiQ+EbBeJf4UaNQWETAWRHaAag1xsAYFH Received: from um-ncas5.um.umsystem.edu ([207.160.158.210]) by um-tip2-exch-relay.um.umsystem.edu with ESMTP; 12 Aug 2014 14:11:47 -0500 Received: from UM-MBX-N02.um.umsystem.edu ([169.254.5.145]) by UM-NCAS5.um.umsystem.edu ([207.160.158.210]) with mapi id 14.03.0181.006; Tue, 12 Aug 2014 14:11:47 -0500 From: "Montgomery-Smith, Stephen" To: =?Windows-1252?Q?fran=E7ai_s?= , "freebsd-hackers@freebsd.org" Subject: Re: The use of C language is avoided in FreeBSD development? Thread-Topic: The use of C language is avoided in FreeBSD development? Thread-Index: AQHPtlrNMuqW+YKTIUiiFfka1y5fmJvNqZ+A Date: Tue, 12 Aug 2014 19:11:47 +0000 Message-ID: <53EA66F1.3060609@missouri.edu> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0 x-originating-ip: [207.160.158.194] Content-Type: text/plain; charset="Windows-1252" Content-ID: <81ABE26245A924448169AA43087354FB@missouri.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 19:12:59 -0000 On 08/12/2014 01:07 PM, fran=E7ai s wrote: > The use of C language is avoided in FreeBSD development? I ask this > because second Eric Raymond in 'How To Become A Hacker', actually, the > more you can avoid programming in C the more productive you will be. > reference:http://www.catb.org/~esr/faqs/hacker-howto.html I think Eric has a good point. First, this particular quote is part of a much longer essay which is well thought out and nuanced. He is definitely not saying you should avoid programming in C. Rather he is saying that if the task at hand is handled well by a different language, go ahead and use that instead. Let me say what I think Eric is trying to say, and back it up with lessons I learned. I learned programming in the 1970s and 1980s. I started with BASIC, then PASCAL, but then I settled on C. This is just the way things happened for me. I had my first unix computer in 1989 - it was a Sun workstation. I loved it. And my experience with C really helped me a lot. And in some ways, I have to say that I really began to appreciate how good a language C really is. But also, because I knew C, and nothing else (like awk, shell script, grep, etc), I got into the habit of doing every job using C. For example, I had these files which were padded with zeros at the end that made the file hundreds of times bigger, and the program that handled them a lot slower. So I wrote a C program that removed the trailing zeros. I another example, I helped organize a conference. I wrote software that processed the emails we received, and extracted information like the first name, last name, title of talk, abstract, etc. And it put all this information into a large TeX file that became the conference abstracts. And because the form they filled in was badly designed, the text was embedded into the emails in all kinds of awkward ways, so the program had to handle the many inconsistencies with how the forms had been filled out. And I wrote this whole program in C! Then someone recommended I learn PERL. I suddenly realized I had been using the wrong tool. PERL was tailor made for the conference task. And learning about regular expressions inspired me to learn at least a little bit about awk, grep and shell script. I now realize I was using C all the time for tasks for which it was completely inappropriate. I do very much appreciate the knowledge of C I have. And it is probably the language I know the best. But Eric is right. If there is a better language for the job, use that other language. Avoid C whenever it can be avoided. Don't avoid C when it cannot be avoided. Learn C, and learn it well. But Eric is completely correct. Stephen= From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 12 19:16:04 2014 Return-Path: Delivered-To: freebsd-hackers@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 95E6C2FF; Tue, 12 Aug 2014 19:16:04 +0000 (UTC) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47A48229E; Tue, 12 Aug 2014 19:16:04 +0000 (UTC) Received: by mail-ig0-f182.google.com with SMTP id c1so7728398igq.15 for ; Tue, 12 Aug 2014 12:16:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=1lLtCSPKjx3y7PZ/DNJsbO6OguQuYOPfn8N573OXDCY=; b=nLv42WWFYWzFgQRDoHlS24BvacNr7gbDGgXHelF6I8kRo+PQ/LsRd1yqnR+wIL6L0x KddIZXCkM7Ga1vuM49cP7qE+728brn2tlS8nXI0JjXGCwB9Q5e4lXzZJoQu0KWKG1Mpt dVd6vF6kj7X1OmQCGID2lcei29HmIWFWUXfDlQAqTQqtNhOlhytukB/+02BbNtLBGGl1 CNw8XCgrairvg/8Ag3YKCvZMQlSNqwfuqcxY65NYcYneggVzI0w4Vkym9IBNoPJ3e7e9 EuTTydZPs8E/KlubIkk1fdApbAD6a/qW+Kk+8ES9t2BlJvCd6Ow7RAM9m5iz6Hgn/iA1 bGuA== X-Received: by 10.43.136.134 with SMTP id ik6mr966157icc.6.1407870963621; Tue, 12 Aug 2014 12:16:03 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.131.38 with HTTP; Tue, 12 Aug 2014 12:15:43 -0700 (PDT) In-Reply-To: References: <53EA0EC2.2070601@freebsd.org> <53EA1E5A.5020707@FreeBSD.org> <53EA2D00.7010307@freebsd.org> From: Ed Maste Date: Tue, 12 Aug 2014 15:15:43 -0400 X-Google-Sender-Auth: ofBoHUG-1es8OCNbol1TJwBXh-E Message-ID: Subject: Re: Keymap definitions for VT / NEWCONS To: Oliver Pinter Content-Type: text/plain; charset=UTF-8 Cc: "Andrey V. Elsukov" , Aleksandr Rybalko , freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 19:16:04 -0000 On 12 August 2014 13:57, Oliver Pinter wrote: > > Hi! > > I like to see the us.pc-crtrl.kbd too in this list. How can I convert > this in fastest way? It doesn't have any code points >= 128 so no conversion is necessary - it should work as-is. From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 12 19:37:10 2014 Return-Path: Delivered-To: freebsd-hackers@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 C8D50DA6 for ; Tue, 12 Aug 2014 19:37:10 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A3F7A25CD for ; Tue, 12 Aug 2014 19:37:10 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 982AAB95B; Tue, 12 Aug 2014 15:37:09 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: IO chunking Date: Tue, 12 Aug 2014 12:57:18 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201408121257.18814.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 12 Aug 2014 15:37:09 -0400 (EDT) Cc: "Pokala, Ravi" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 19:37:10 -0000 On Tuesday, August 12, 2014 2:56:26 am Pokala, Ravi wrote: > Hi folks, > > I'm doing moderately-large block IO (16KB - 1MB) directly against drive > devices (i.e. /dev/adaX), and I see that `iostat -d adaX' reports a > transaction size of at most 128KB. I believe this is because transactions > are limited to at most MAXPHYS bytes (128KB), and requests larger than > that are broken into smaller chunks; is that correct? If so, where does > that chunking happen? In low-level GEOM code (geom_io.c, geom_dev.c)? In > CAM? In the drive device driver? In VFS? Note that you can increase MAXPHYS (though you will want to ensure your storage controller drivers correctly report their maximum supported size and don't just hardcode MAXPHYS). The limit appears to be throughout the stack, though largely enforced at the top (e.g. in physio() before entering GEOM or the b_pages[] array in struct buf). Certainly I've seen folks run with MAXPHYS of 512k, but check your drivers. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 12 19:03:01 2014 Return-Path: Delivered-To: freebsd-hackers@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 D0AB27B for ; Tue, 12 Aug 2014 19:03:01 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 959732171 for ; Tue, 12 Aug 2014 19:03:01 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id EFACC1578; Tue, 12 Aug 2014 19:02:53 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id s7CJ2rO3065936; Tue, 12 Aug 2014 19:02:53 GMT (envelope-from phk@phk.freebsd.dk) To: =?UTF-8?Q?fran=C3=A7ai_s?= Subject: Re: The use of C language is avoided in FreeBSD development? In-reply-to: From: "Poul-Henning Kamp" References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <65934.1407870173.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Aug 2014 19:02:53 +0000 Message-ID: <65935.1407870173@critter.freebsd.dk> X-Mailman-Approved-At: Tue, 12 Aug 2014 20:47:39 +0000 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 19:03:01 -0000 -------- In message , =3D?UTF-8?Q?fran=3DC3=3DA7ai_s?=3D writes: >The use of C language is avoided in FreeBSD development? = Don't feed the silly troll. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 12 22:36:55 2014 Return-Path: Delivered-To: freebsd-hackers@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 800BF6D4; Tue, 12 Aug 2014 22:36:55 +0000 (UTC) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 189E02FEC; Tue, 12 Aug 2014 22:36:55 +0000 (UTC) Received: by mail-oi0-f42.google.com with SMTP id a3so7047608oib.15 for ; Tue, 12 Aug 2014 15:36:54 -0700 (PDT) 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=PApfHuLls90reNErRQO9EZBWP6KEXu5Vm7YO3mycWLk=; b=lfPTHrWNet6oFBTtI1daQg3Vl5crCU3ewbEc05tLiDOG7+M5wWjTKdxVTMtFdjKCXH iBDOIz/sKMBn2RT8G7nMRY6awEc9q4+bWTydbBdM4WeVijH5rcwMo1TUIXx5WSyZ6KM5 R3G3r4QHOGpoOSEq4DDHKwEBxW6eJfl9YBL0ntRqx1BVHUA+DdgEAT3zKriF2PYSjVLJ pVvZnI57W4Dl9I9LOfNPAwvl8hhRb0sOtOptajcpdS5t2SgjdvGFnwDGyWqUiyutPGTx 1GO0EvzsKxiOq4IWK8kSJ9R8X6yr+vBZiCPkwF1uJOsQ/7JkTmVPLY8TFqYZpZPBfCmW UnDQ== MIME-Version: 1.0 X-Received: by 10.182.60.4 with SMTP id d4mr961209obr.4.1407883014457; Tue, 12 Aug 2014 15:36:54 -0700 (PDT) Received: by 10.182.216.200 with HTTP; Tue, 12 Aug 2014 15:36:54 -0700 (PDT) In-Reply-To: References: <53EA0EC2.2070601@freebsd.org> <53EA1E5A.5020707@FreeBSD.org> <53EA2D00.7010307@freebsd.org> Date: Wed, 13 Aug 2014 00:36:54 +0200 Message-ID: Subject: Re: Keymap definitions for VT / NEWCONS From: Oliver Pinter To: Ed Maste Content-Type: text/plain; charset=ISO-8859-1 Cc: Aleksandr Rybalko , freebsd-stable@freebsd.org, "Andrey V. Elsukov" , freebsd-hackers@freebsd.org, Kevin Oberman X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 22:36:55 -0000 On 8/12/14, Ed Maste wrote: > On 12 August 2014 13:57, Oliver Pinter wrote: >> >> Hi! >> >> I like to see the us.pc-crtrl.kbd too in this list. How can I convert >> this in fastest way? > > It doesn't have any code points >= 128 so no conversion is necessary - > it should work as-is. > Okay! Thanks the quick answer. From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 12 22:54:30 2014 Return-Path: Delivered-To: freebsd-hackers@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 8363AE5C; Tue, 12 Aug 2014 22:54:30 +0000 (UTC) Received: from natasha.panasas.com (natasha.panasas.com [209.166.131.148]) by mx1.freebsd.org (Postfix) with ESMTP id 45B1021DE; Tue, 12 Aug 2014 22:54:29 +0000 (UTC) Received: from seabiscuit.panasas.com (seabiscuit.panasas.com [172.17.132.204]) by natasha.panasas.com (8.13.1/8.13.1) with ESMTP id s7CKxwdw029520; Tue, 12 Aug 2014 16:59:58 -0400 Received: from SEABISCUIT.int.panasas.com ([172.17.132.204]) by seabiscuit ([172.17.132.204]) with mapi id 14.03.0181.006; Tue, 12 Aug 2014 13:59:58 -0700 From: "Pokala, Ravi" To: John Baldwin , "freebsd-hackers@freebsd.org" Subject: Re: IO chunking Thread-Topic: IO chunking Thread-Index: AQHPtfqI63Kw96jg+06V8le/JTT3WpvNplYA///OawA= Date: Tue, 12 Aug 2014 20:59:57 +0000 Message-ID: References: <201408121257.18814.jhb@freebsd.org> In-Reply-To: <201408121257.18814.jhb@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [172.17.28.63] Content-Type: text/plain; charset="us-ascii" Content-ID: <8892E5E66959E64F81083D29360EF412@panasas.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 22:54:30 -0000 -----Original Message----- From: John Baldwin Date: Tuesday, August 12, 2014 at 9:57 AM To: "freebsd-hackers@freebsd.org" Cc: Ravi Pokala Subject: Re: IO chunking >On Tuesday, August 12, 2014 2:56:26 am Pokala, Ravi wrote: >> Hi folks, >>=20 >> I'm doing moderately-large block IO (16KB - 1MB) directly against drive >> devices (i.e. /dev/adaX), and I see that `iostat -d adaX' reports a >> transaction size of at most 128KB. I believe this is because >>transactions >> are limited to at most MAXPHYS bytes (128KB), and requests larger than >> that are broken into smaller chunks; is that correct? If so, where does >> that chunking happen? In low-level GEOM code (geom_io.c, geom_dev.c)? In >> CAM? In the drive device driver? In VFS? > >Note that you can increase MAXPHYS (though you will want to ensure your >storage controller drivers correctly report their maximum supported size >and don't just hardcode MAXPHYS). Yeah. For a semi-related issue, we're planning on upping MAXPHYS to 256KB. That still artificially limits the transaction size, but it's a bit better. >The limit appears to be throughout the stack, though largely enforced >at the top (e.g. in physio() before entering GEOM or the b_pages[] array >in struct buf). Looking... sys/kern/kern_physio.c: 101 /* Don't exceed drivers iosize limit */ 102 if (bp->b_bcount > dev->si_iosize_max) 103 bp->b_bcount =3D dev->si_iosize_max; Yeah, that's probably what it is. It looks like geom_dev.c::g_dev_taste() sets si_iosize_max to MAXPHYS, and nothing in the ATA layer changes it. >Certainly I've seen folks run with MAXPHYS of 512k, but check your >drivers. Yeah. We've been running w/ 256KB in another branch for a while, so it looks like everything we use is okay. Thanks, Ravi >--=20 >John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 12 23:28:24 2014 Return-Path: Delivered-To: freebsd-hackers@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 B4CF0572 for ; Tue, 12 Aug 2014 23:28:24 +0000 (UTC) Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net [50.73.42.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7516025ED for ; Tue, 12 Aug 2014 23:28:23 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.5/8.14.5) with ESMTP id s7CNSGoC077640 for ; Tue, 12 Aug 2014 17:28:16 -0600 (MDT) (envelope-from torek@torek.net) Message-Id: <201408122328.s7CNSGoC077640@elf.torek.net> From: Chris Torek To: freebsd-hackers@freebsd.org Subject: PCIe AER MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <77638.1407886096.1@elf.torek.net> Date: Tue, 12 Aug 2014 17:28:16 -0600 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.torek.net [127.0.0.1]); Tue, 12 Aug 2014 17:28:16 -0600 (MDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 23:28:24 -0000 Is there any sort of overall plan for advanced error reporting on PCIe? I may need to implement something along these lines soon, at least for detection (not necessarily correction just yet). Chris From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 12 23:33:09 2014 Return-Path: Delivered-To: freebsd-hackers@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 4BDEF6AE for ; Tue, 12 Aug 2014 23:33:09 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 3A25C268F for ; Tue, 12 Aug 2014 23:33:08 +0000 (UTC) Received: from u10-2-16-021.office.norse-data.com (unknown [50.204.88.51]) by elvis.mu.org (Postfix) with ESMTPSA id 497BD346DE14 for ; Tue, 12 Aug 2014 16:33:08 -0700 (PDT) Message-ID: <53EAA48E.8030506@mu.org> Date: Tue, 12 Aug 2014 16:34:38 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: The use of C language is avoided in FreeBSD development? References: <65935.1407870173@critter.freebsd.dk> In-Reply-To: <65935.1407870173@critter.freebsd.dk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 23:33:09 -0000 On 8/12/14 12:02 PM, Poul-Henning Kamp wrote: > -------- > In message > , =?UTF-8?Q?fran=C3=A7ai_s?= writes: > >> The use of C language is avoided in FreeBSD development? > Don't feed the silly troll. > Truly a question for the ages: "Is unix better than C?" (From a #freebsd irc troll circa 1999) -Alfred From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 13 01:34:20 2014 Return-Path: Delivered-To: hackers@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 16E1BB07 for ; Wed, 13 Aug 2014 01:34:20 +0000 (UTC) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D3F98247E for ; Wed, 13 Aug 2014 01:34:19 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id i7so7964335oag.30 for ; Tue, 12 Aug 2014 18:34:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=/5YEMkN6eo7SNuf0VAUdtMQoYcBM1+nypjgWm2jY+gY=; b=KuxOBCyphtmQqkKyeJTq5xDtoFSnI8LHXKoaAD8jml+UJ10eKJc0YE0sea7kLp+xyh ngX05H7apSV5YKTpAfk4yMcIBAXsRZ9lzijRZKLaqbYgxeds/wZXI0OgEYqwdBg7Ex82 cIWKfrqio9HPB8UpxolfepYHsQ7ni2ftMrMybtHytnJKA12K7q3s9lc8AJX3Mgso8l1P drqk50V8u43ooynKjBaMD5GHTROPyIih+xrQqbsk1njsFwgbBehx0SOSJ3Jnepsc7DW9 5/OLpWDGcO499rPrg7fYoOHEDavOZhwt5V4XTST7bs1o2zPpNJgApsl8k5xOJL5x1hi7 EeGg== X-Gm-Message-State: ALoCoQkUpJ5lKuqXjxHzxQJ8Xdq/m+qgwYEtzl7EXKrFt2isrl+ruvlS5Qdkk/w/5s8AFl/0+MCh X-Received: by 10.182.204.102 with SMTP id kx6mr1483483obc.16.1407891920603; Tue, 12 Aug 2014 18:05:20 -0700 (PDT) Received: from ?IPv6:2610:160:11:33:3db1:1ebf:4c17:e012? ([2610:160:11:33:3db1:1ebf:4c17:e012]) by mx.google.com with ESMTPSA id ii12sm463079obd.5.2014.08.12.18.05.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Aug 2014 18:05:20 -0700 (PDT) From: Jim Thompson Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: death of the Internet predicted. Film at 11. Message-Id: Date: Tue, 12 Aug 2014 20:05:15 -0500 To: hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1972.3\)) X-Mailer: Apple Mail (2.1972.3) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 01:34:20 -0000 bzs wants to talk mainframes=E2=80=A6 meh. How about some networking = rant for dinner? Today someone announced some more IPv4 routes on the Internet. Nothing = new really, but this meant the global routing table has exceeded 500k = entries (501,525 as we speak). This has caused a lot of popular Cisco router models to go tits up = because their default value for the IPv4 table size is 512k which in = this case was not enough to hold the global table. Theoretically the table should hold up to 512k entries, but the memory = is not exclusively used for it, some of it goes to IPv6, some to = maintaining various sessions, MPLS etc, so it crapped out at around 500k.=20 As discussed on NANOG from a few months ago: http://markmail.org/message/n32fmeb2dmtnbsff Now, 512K routes isn't necessarily a hardware limitation, it's the = default TCAM allocation for IPv4 in a Cisco. = http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-sw= itches/116132-problem-catalyst6500-00.html But... don=E2=80=99t reload your Cisco... http://www.cisco.com/web/about/doing_business/memory.html Talk about "damned if you do, and damned if you don=E2=80=99t." I find the economics of the routing table to be fascinating. When = someone announces a route, it makes use of a constrained (and often = expensive, TCAM-based) resource on routers all over the world. This totals to, by some measures, $6200/route/year.: = http://bill.herrin.us/network/bgpcost.html Now boys & girls, $6,200 * 501,525 is $3,109,455,000/year, and growing. =20= But back to reboots. Despite the above, woe be to anyone who tries to = get Cisco to replace their grey-market way-beyond-deprecated = almost-definitely-not-covered-by-SmartNet Sup720 linecards in 2014. It's very odd that "grey market" equipment is considered the standard = way to refer to genuine Cisco equipment when sold by a company other = than a Cisco partner. I understand keeping out counterfeits, but given the first-sale = doctrine, how is a resold piece of equipment anything other than = completely legitimate? If you think about it, and get past the "it's just industry standard" = mentality, it=E2=80=99s a bit insane that Cisco uses (and gets away = with) these pseudo-monopoly tactics. In the old days, (say with maintenance on IBM Selectric typewriters), = such schemes were called "bundling" and "tying," and the DOJ would = pursue the companies for anti-trust violations. But that was yesterday. Today the DOJ arrests people based upon = nebulous complaints from Cisco's general counsel. See e.g. = http://abovethelaw.com/2011/07/sue-a-giant-corporation-get-rewarded-with-a= udacious-criminal-charges/#more-84911 wherein a British citizen was arrested in Canada for starting a company = that competed with Cisco maintenance. The Canadian court quashed the request for extradition after the DOJ's = request trapped him in a foreign country for years. Today, he remains = under indictment in the US, despite the Canadian judge stating that the = DOJ's case was a fairly transparent copy of Cisco's civil suit. The = ruling was incendiary, stating that "The extradition process to bring = the applicant before United States Courts=E2=80=A6 involved innuendo, = half truths and complete falsehoods." The judge concluded: "The only reasonable inference I can draw from the facts is that the = criminal process was used to pressure (unsuccessfully) the applicant = into abandoning his antitrust suit against Cisco=E2=80=A6. Any = well-informed person acquainted with the truth would conclude that the = collective result of the mistreatment of Mr. Adekeye offended = fundamental notions of justice." Are all Cisco execs fugly and unethical? http://www.businessinsider.com/cisco-exec-vows-to-hunt-down-leak-2012-11 Jim From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 13 04:56:56 2014 Return-Path: Delivered-To: hackers@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 CC45FB2F for ; Wed, 13 Aug 2014 04:56:56 +0000 (UTC) Received: from fun.ee.lbl.gov (fun.ee.lbl.gov [IPv6:2620:83:8000:102::ca]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "fun.ee.lbl.gov", Issuer "ACS 2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B61602930 for ; Wed, 13 Aug 2014 04:56:56 +0000 (UTC) Received: from ice.ee.lbl.gov (ice.ee.lbl.gov [131.243.2.213]) (authenticated bits=0) by fun.ee.lbl.gov (8.14.9/8.14.9) with ESMTP id s7D4uuWB030375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 12 Aug 2014 21:56:56 -0700 (PDT) Message-ID: <53EAF018.4020604@ee.lbl.gov> Date: Tue, 12 Aug 2014 21:56:56 -0700 From: Craig Leres User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: hackers@freebsd.org Subject: Re: death of the Internet predicted. Film at 11. References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 04:56:56 -0000 I was impacted by this this morning. I had ssh and imaps sessions from my comcast address at home to a vps at arpnetworks.com and they all died overnight. But it was a very strange failure. icmp and udp still worked but tcp couldn't make the round trip. And this was true for several different cidr's arpnetworks.com has. But everything worked fine from other locations like from lbl. TCAM is pretty bizarre; I believe access lists use them and one time Bro installed too many and overran the TCAM. This was not straight forward to recover from (e.g. just removing a bunch of ACLs did not unfrob the router). Craig From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 13 06:10:43 2014 Return-Path: Delivered-To: freebsd-hackers@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 87A9589F for ; Wed, 13 Aug 2014 06:10:43 +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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0C32A21CF for ; Wed, 13 Aug 2014 06:10:42 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s7D6AZC5063385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2014 09:10:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s7D6AZC5063385 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s7D6AZFE063372; Wed, 13 Aug 2014 09:10:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 13 Aug 2014 09:10:35 +0300 From: Konstantin Belousov To: Chris Torek Subject: Re: PCIe AER Message-ID: <20140813061035.GF2737@kib.kiev.ua> References: <201408122328.s7CNSGoC077640@elf.torek.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w3uUfsyyY1Pqa/ej" Content-Disposition: inline In-Reply-To: <201408122328.s7CNSGoC077640@elf.torek.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 06:10:43 -0000 --w3uUfsyyY1Pqa/ej Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 12, 2014 at 05:28:16PM -0600, Chris Torek wrote: > Is there any sort of overall plan for advanced error reporting > on PCIe? I do not think so. >=20 > I may need to implement something along these lines soon, at least > for detection (not necessarily correction just yet). I used the following ddb hack to get access to the AER info, when I debugged something related. It relied on the AER constants which I already committed. I even did not tried to attach to PCIe bridge interrupts. diff --git a/sys/dev/pci/pci.c b/sys/dev/pci/pci.c index 9733841..b5b71f4 100644 --- a/sys/dev/pci/pci.c +++ b/sys/dev/pci/pci.c @@ -3511,13 +3511,85 @@ pci_add_children(device_t dev, int domain, int busn= o, size_t dinfo_size) void pci_add_child(device_t bus, struct pci_devinfo *dinfo) { - dinfo->cfg.dev =3D device_add_child(bus, NULL, -1); - device_set_ivars(dinfo->cfg.dev, dinfo); + device_t dev; + int aer; + uint32_t r; + uint16_t r2; + + dinfo->cfg.dev =3D dev =3D device_add_child(bus, NULL, -1); + device_set_ivars(dev, dinfo); resource_list_init(&dinfo->resources); - pci_cfg_save(dinfo->cfg.dev, dinfo, 0); - pci_cfg_restore(dinfo->cfg.dev, dinfo); + pci_cfg_save(dev, dinfo, 0); + pci_cfg_restore(dev, dinfo); pci_print_verbose(dinfo); - pci_add_resources(bus, dinfo->cfg.dev, 0, 0); + pci_add_resources(bus, dev, 0, 0); + + if (dinfo->cfg.pcie.pcie_location !=3D 0 && + dinfo->cfg.pcie.pcie_type =3D=3D PCIEM_TYPE_ROOT_PORT) { + r2 =3D pci_read_config(dev, dinfo->cfg.pcie.pcie_location + + PCIER_ROOT_CTL, 2); + r2 &=3D ~(PCIEM_ROOT_CTL_SERR_CORR | + PCIEM_ROOT_CTL_SERR_NONFATAL | PCIEM_ROOT_CTL_SERR_FATAL); + pci_write_config(dev, dinfo->cfg.pcie.pcie_location + + PCIER_ROOT_CTL, r2, 2); + } + if (pci_find_extcap(dev, PCIZ_AER, &aer) =3D=3D 0) { + r =3D pci_read_config(dev, aer + PCIR_AER_UC_STATUS, 4); + pci_write_config(dev, aer + PCIR_AER_UC_STATUS, r, 4); + if (r !=3D 0 && bootverbose) { + pci_printf(&dinfo->cfg, + "clearing AER UC 0x%08x -> 0x%08x\n", + r, pci_read_config(dev, aer + PCIR_AER_UC_STATUS, + 4)); + } + + r =3D pci_read_config(dev, aer + PCIR_AER_UC_MASK, 4); + r &=3D ~(PCIM_AER_UC_TRAINING_ERROR | + PCIM_AER_UC_DL_PROTOCOL_ERROR | + PCIM_AER_UC_SURPRISE_LINK_DOWN | + PCIM_AER_UC_POISONED_TLP | + PCIM_AER_UC_FC_PROTOCOL_ERROR | + PCIM_AER_UC_COMPLETION_TIMEOUT | + PCIM_AER_UC_COMPLETER_ABORT | + PCIM_AER_UC_UNEXPECTED_COMPLETION | + PCIM_AER_UC_RECEIVER_OVERFLOW | + PCIM_AER_UC_MALFORMED_TLP | + PCIM_AER_UC_ECRC_ERROR | + PCIM_AER_UC_UNSUPPORTED_REQUEST | + PCIM_AER_UC_ACS_VIOLATION | + PCIM_AER_UC_INTERNAL_ERROR | + PCIM_AER_UC_MC_BLOCKED_TLP | + PCIM_AER_UC_ATOMIC_EGRESS_BLK | + PCIM_AER_UC_TLP_PREFIX_BLOCKED); + pci_write_config(dev, aer + PCIR_AER_UC_MASK, r, 4); + + r =3D pci_read_config(dev, aer + PCIR_AER_COR_STATUS, 4); + pci_write_config(dev, aer + PCIR_AER_COR_STATUS, r, 4); + if (r !=3D 0 && bootverbose) { + pci_printf(&dinfo->cfg, + "clearing AER COR 0x%08x -> 0x%08x\n", + r, pci_read_config(dev, aer + PCIR_AER_COR_STATUS, + 4)); + } + + r =3D pci_read_config(dev, aer + PCIR_AER_COR_MASK, 4); + r &=3D ~(PCIM_AER_COR_RECEIVER_ERROR | + PCIM_AER_COR_BAD_TLP | + PCIM_AER_COR_BAD_DLLP | + PCIM_AER_COR_REPLAY_ROLLOVER | + PCIM_AER_COR_REPLAY_TIMEOUT | + PCIM_AER_COR_ADVISORY_NF_ERROR | + PCIM_AER_COR_INTERNAL_ERROR | + PCIM_AER_COR_HEADER_LOG_OVFLOW); + pci_write_config(dev, aer + PCIR_AER_COR_MASK, r, 4); + + r =3D pci_read_config(dev, dinfo->cfg.pcie.pcie_location + + PCIER_DEVICE_CTL, 2); + r |=3D PCIEM_CTL_COR_ENABLE | PCIEM_CTL_NFER_ENABLE | + PCIEM_CTL_FER_ENABLE | PCIEM_CTL_URR_ENABLE; + pci_write_config(dev, dinfo->cfg.pcie.pcie_location + + PCIER_DEVICE_CTL, r, 2); + } } =20 static int @@ -5095,3 +5167,128 @@ pci_get_rid_method(device_t dev, device_t child) =20 return (PCIB_GET_RID(device_get_parent(dev), child)); } + +static void +pci_print_faulted_dev_name(const struct pci_devinfo *dinfo) +{ + const char *dev_name; + device_t dev; + + dev =3D dinfo->cfg.dev; + printf("pci%d:%d:%d:%d", dinfo->cfg.domain, dinfo->cfg.bus, + dinfo->cfg.slot, dinfo->cfg.func); + dev_name =3D device_get_name(dev); + if (dev_name !=3D NULL) + printf(" (%s%d)", dev_name, device_get_unit(dev)); +} + +void +pci_print_faulted_dev(void) +{ + struct pci_devinfo *dinfo; + device_t dev; + int aer, i; + uint32_t r1, r2; + uint16_t status; + + STAILQ_FOREACH(dinfo, &pci_devq, pci_links) { + dev =3D dinfo->cfg.dev; + status =3D pci_read_config(dev, PCIR_STATUS, 2); + status &=3D PCIM_STATUS_MDPERR | PCIM_STATUS_STABORT | + PCIM_STATUS_RTABORT | PCIM_STATUS_RMABORT | + PCIM_STATUS_SERR | PCIM_STATUS_PERR; + if (status !=3D 0) { + pci_print_faulted_dev_name(dinfo); + printf(" error 0x%04x\n", status); + } + if (dinfo->cfg.pcie.pcie_location !=3D 0) { + status =3D pci_read_config(dev, + dinfo->cfg.pcie.pcie_location + + PCIER_DEVICE_STA, 2); + if ((status & (PCIEM_STA_CORRECTABLE_ERROR | + PCIEM_STA_NON_FATAL_ERROR | PCIEM_STA_FATAL_ERROR | + PCIEM_STA_UNSUPPORTED_REQ)) !=3D 0) { + pci_print_faulted_dev_name(dinfo); + printf(" PCIe DEVCTL 0x%04x DEVSTA 0x%04x\n", + pci_read_config(dev, + dinfo->cfg.pcie.pcie_location + + PCIER_DEVICE_CTL, 2), + status); + } + } + if (pci_find_extcap(dev, PCIZ_AER, &aer) =3D=3D 0) { + r1 =3D pci_read_config(dev, aer + PCIR_AER_UC_STATUS, 4); + r2 =3D pci_read_config(dev, aer + PCIR_AER_COR_STATUS, 4); + if (r1 !=3D 0 || r2 !=3D 0) { + pci_print_faulted_dev_name(dinfo); + printf(" AER UC 0x%08x Mask 0x%08x Svr 0x%08x\n" + " COR 0x%08x Mask 0x%08x Ctl 0x%08x\n", + r1, pci_read_config(dev, aer + + PCIR_AER_UC_MASK, 4), + pci_read_config(dev, aer + + PCIR_AER_UC_SEVERITY, 4), + r2, pci_read_config(dev, aer + + PCIR_AER_COR_MASK, 4), + pci_read_config(dev, aer + + PCIR_AER_CAP_CONTROL, 4)); + for (i =3D 0; i < 4; i++) { + r1 =3D pci_read_config(dev, aer + + PCIR_AER_HEADER_LOG + i * 4, 4); + printf(" HL%d: 0x%08x\n", i, r1); + } + } + } + } +} + +#ifdef DDB +DB_SHOW_COMMAND(pcierr, pci_print_faulted_dev_db) +{ + + pci_print_faulted_dev(); +} + +static void +db_clear_pcie_errors(const struct pci_devinfo *dinfo) +{ + device_t dev; + int aer; + uint32_t r; + + dev =3D dinfo->cfg.dev; + r =3D pci_read_config(dev, dinfo->cfg.pcie.pcie_location + + PCIER_DEVICE_STA, 2); + pci_write_config(dev, dinfo->cfg.pcie.pcie_location + + PCIER_DEVICE_STA, r, 2); + + if (pci_find_extcap(dev, PCIZ_AER, &aer) !=3D 0) + return; + r =3D pci_read_config(dev, aer + PCIR_AER_UC_STATUS, 4); + if (r !=3D 0) + pci_write_config(dev, aer + PCIR_AER_UC_STATUS, r, 4); + r =3D pci_read_config(dev, aer + PCIR_AER_COR_STATUS, 4); + if (r !=3D 0) + pci_write_config(dev, aer + PCIR_AER_COR_STATUS, r, 4); +} + +DB_COMMAND(pci_clearerr, db_pci_clearerr) +{ + struct pci_devinfo *dinfo; + device_t dev; + uint16_t status, status1; + + STAILQ_FOREACH(dinfo, &pci_devq, pci_links) { + dev =3D dinfo->cfg.dev; + status1 =3D status =3D pci_read_config(dev, PCIR_STATUS, 2); + status1 &=3D PCIM_STATUS_MDPERR | PCIM_STATUS_STABORT | + PCIM_STATUS_RTABORT | PCIM_STATUS_RMABORT | + PCIM_STATUS_SERR | PCIM_STATUS_PERR; + if (status1 !=3D 0) { + status &=3D ~status1; + pci_write_config(dev, PCIR_STATUS, status, 2); + } + if (dinfo->cfg.pcie.pcie_location !=3D 0) + db_clear_pcie_errors(dinfo); + } +} +#endif diff --git a/sys/dev/pci/pcivar.h b/sys/dev/pci/pcivar.h index 0157ee7..51defff 100644 --- a/sys/dev/pci/pcivar.h +++ b/sys/dev/pci/pcivar.h @@ -506,6 +506,7 @@ void pci_restore_state(device_t dev); void pci_save_state(device_t dev); int pci_set_max_read_req(device_t dev, int size); =20 +void pci_print_faulted_dev(void); =20 #ifdef BUS_SPACE_MAXADDR #if (BUS_SPACE_MAXADDR > 0xFFFFFFFF) --w3uUfsyyY1Pqa/ej Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT6wFaAAoJEJDCuSvBvK1BLKMP/i6R3SH1y60Jmn1F7+TJiKQg lvPvQPTmM2vMLUswKAIpsJ3zbchtWjrkKDJaE3Sp0CDtnMTubvqYtBefILlnWDg3 YJOKgTIKPsQfoNMVV85uJ9PI7Lh0x8FeniYQfL99UrBaYQzrybgsoiv78Rep+B3U tP6FWQyLdcjUO/2WxNqXA1gBXEBJ6A4ODXP8G0YiBF2IOMhvVNDk013h/VvzYwm7 OOZq6PxoyIM7KZqfJ/TRFr6pc6SoTKynuEEMHvW4Q4p3lvYRmmQiZawjbHJk+mz6 LDqx0m/VadidX0EeNUkidjM9hm4ch/QKRqUhemr6Tt5tPonMwzhXmi0QYgUIpgpi Ehw0HAiVWUIs/GUEwa0uPmKIuiC7zV8/sGn+dd0UOKjToXQQzLfcjVNftuWCdOlB ZiROxuKr1E/tb09SEo0DZW6Gwlk3khsXSWUSsbVo8WBzIpiljVzBzzmNcljFdHai e7lzgpflPgKkrtg0b3WZ4Iufj9RoU9ojK1OHgVmYzP10pDhq/edb/9+ZzuBOeqXQ klx36sFDGjk0/zdN4py5/9u1FcUpstS2J3P3q5ktRfxFn92YigrCd51Keyumftmx VUYQrc1b5aJJz9BNQ7vtA/tDwZWWfq2jE3j0Sz6ov64pnqvO0bwOI/yA3N4gTZvg E7qImBdTybniF4Gw502P =zfrK -----END PGP SIGNATURE----- --w3uUfsyyY1Pqa/ej-- From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 13 06:16:51 2014 Return-Path: Delivered-To: hackers@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 2E356C30 for ; Wed, 13 Aug 2014 06:16:51 +0000 (UTC) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E56BF22DE for ; Wed, 13 Aug 2014 06:16:50 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id i13so9705398qae.6 for ; Tue, 12 Aug 2014 23:16:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=mjW4cosYYHAgsFFRQf0Xi9hEIdMYOaMhBiqW5CCRNNA=; b=pIWgmFHFZdS0Yen+ENUOoDnaS4B5IbOxMw6b84V0yFnRW1JjpI2YQ2AR5LutIljFfQ kyRUHXHT6aQVJFRlS/uf2I55itBBDWzXQ5nRQlxqCEE2uLlQAsPnTNxVBLyIKPMmEdn2 fWK+QbPTocDwRJakOwVmiR+RShNjdREH/FadE6hfAQdZUYBqlH7uzEtipJgVEL3pAu8O 9A7vtObGh6k/mTXyw4kR6ZaM1f8ApXYwfDMNVcQt5G7ZiZGhrtX1FXzyYdup2sfOUZt7 9g4sk8oM3dxSsbrK2wnE8LuRibqCNJIutwN8aGR2BrMlpkzvNfwxuBYLdXJxOwIHQGei kVrA== MIME-Version: 1.0 X-Received: by 10.140.23.37 with SMTP id 34mr3530251qgo.2.1407910610068; Tue, 12 Aug 2014 23:16:50 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.39.139 with HTTP; Tue, 12 Aug 2014 23:16:50 -0700 (PDT) In-Reply-To: <53EAF018.4020604@ee.lbl.gov> References: <53EAF018.4020604@ee.lbl.gov> Date: Tue, 12 Aug 2014 23:16:50 -0700 X-Google-Sender-Auth: ycvLfJtqpjbGoIcYfab7dRRfmac Message-ID: Subject: Re: death of the Internet predicted. Film at 11. From: Adrian Chadd To: Craig Leres Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 06:16:51 -0000 On 12 August 2014 21:56, Craig Leres wrote: > I was impacted by this this morning. I had ssh and imaps sessions from > my comcast address at home to a vps at arpnetworks.com and they all died > overnight. But it was a very strange failure. icmp and udp still worked > but tcp couldn't make the round trip. And this was true for several > different cidr's arpnetworks.com has. But everything worked fine from > other locations like from lbl. > > TCAM is pretty bizarre; I believe access lists use them and one time Bro > installed too many and overran the TCAM. This was not straight forward > to recover from (e.g. just removing a bunch of ACLs did not unfrob the > router). TCAM isn't bizarre. all the weird, complicated ways it is managed and programmed is what's bizarre. Some platforms may just decide "nope, overflowed, bye". Some platforms may decide that the best thing to do is CPU punt, but then you have to sort what you put into TCAM so when you CPU punt you're not doing it incorrectly. With that comes .. bugs. -a From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 13 07:03:14 2014 Return-Path: Delivered-To: freebsd-hackers@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 28D0EB0A; Wed, 13 Aug 2014 07:03:14 +0000 (UTC) Received: from mailout12.t-online.de (mailout12.t-online.de [194.25.134.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B234D2984; Wed, 13 Aug 2014 07:03:13 +0000 (UTC) Received: from fwd08.aul.t-online.de (fwd08.aul.t-online.de [172.20.26.151]) by mailout12.t-online.de (Postfix) with SMTP id 8D5261EDBCB; Wed, 13 Aug 2014 09:03:10 +0200 (CEST) Received: from [192.168.119.33] (XHkYL6ZvwheDLvXYmXzpRcxMn0kDuawVMFVqiopGobp-XYV5WHJuH3sCNAJGGqbgMs@[84.154.101.219]) by fwd08.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XHSaN-10FvVo0; Wed, 13 Aug 2014 09:03:03 +0200 Message-ID: <53EB0DA0.5000305@freebsd.org> Date: Wed, 13 Aug 2014 09:02:56 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Ed Maste Subject: Re: Keymap definitions for VT / NEWCONS References: <53EA0EC2.2070601@freebsd.org> <53EA1E5A.5020707@FreeBSD.org> <53EA2D00.7010307@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ID: XHkYL6ZvwheDLvXYmXzpRcxMn0kDuawVMFVqiopGobp-XYV5WHJuH3sCNAJGGqbgMs X-TOI-MSGID: 2f4b4f7c-490c-49af-8b3c-0f2820e4ac36 Cc: "Andrey V. Elsukov" , Aleksandr Rybalko , freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 07:03:14 -0000 Am 12.08.2014 um 19:40 schrieb Ed Maste: > On 12 August 2014 11:04, Stefan Esser wrote: >> This is my list of converted keymaps I'm ready to commit: > ... >> danish.acc.kbd >> danish.kbd > > I wonder if we should use this opportunity to rationalize the keyboard > layout names, using two letter codes consistently (so dk.kbd). This > would also bring consistency with the X11 keyboard layout codes. Yes, one of the reasons that I did not commit the converted keymaps as they currently are is naming. I left the old names (without .iso.) to simplify comparisons, but wanted to normalize them before commit. I have renamed the files to 2-character ISO country code names, and have used the form "fr_CH.kbd" (instead of "swisscfrench.iso.kbd") where there are several locales within a country. Unresolved: - Shall keymap names for countries where language and country are identical (e.g. "pt.kbd") be converted to "pt_PT.kbd"? (I'd say yes ...) - In the example of Switzerland, "swissgerman.kbd" becomes "de_CH.kbd". * Do we want to add "ch.kbd", too? * Should it be a symlink to one of the other keymap files (the majority of the Swiss population would use de_CH, I guess) * What in the case of "pt_PT.kbd" above - shall there also be a symlink named "pt.kbd"? - What shall we do with keymaps like "latinamerican.kbd"? We could install it under one name and symlink (or link) all the other relevant locale names to this name. I could use the list of supported locales under share/locale (sans the encoding suffix) as a minimum list of keyboards to support. That would imply, that for every locale selected by a user, there is a matching default keyboard. What do you think about this? (I'm going to upload a new TAR file with the modified names, after some further changes have been performed: The comments in the keymap files often refer to encodings, that have no meaning after the conversion to Unicode ...) And after all these normalizations have been performed: - How do we deal with accented versions of keymaps? (Those with ".acc." in their names ...) - Do we keep all those variants that only differe in the handling of the Caps-Lock key (which often is mapped to an additional Control key)? > We'll already have some churn in rc.conf settings related to screen > maps / fonts, so this may not be too much of a burden. Since the names will change anyway (because of the removal of the encoding, in case NEWCONS is selected), this will not really hurt us. I could imagine a mapping file or script, which converts the name of the keymap from a SYSCONS name to a NEWCONS name. That script could be used to advise the user to modify rc.conf, or it could (for the lifetime of 10.x) be invoked from the keymap set script in rc.d when kbdcontrol failed to set a keymap based on the "old" name. Opinions? Regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 13 09:51:31 2014 Return-Path: Delivered-To: freebsd-hackers@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 30032F0D; Wed, 13 Aug 2014 09:51:31 +0000 (UTC) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CD6282C7E; Wed, 13 Aug 2014 09:51:30 +0000 (UTC) Received: by mail-ig0-f169.google.com with SMTP id r2so10657920igi.4 for ; Wed, 13 Aug 2014 02:51:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UAkhc1NEV6cpG8oAB6WW7MTw7jhGGmx2Eb1pu5QvOoM=; b=dRgF2wwQ/sM7AK+Qn9ukSwEbyCVbOUGdM/6InhCa85Oi5P+mFD+M87R0iU4GRWOXsO 5yKMVCGCo3IKg8xOblZm+pVuE8rKXjlwcszlHnWzcxdbDVeuR+aRIHtoqbqoWv4QVhqw a9sE0YTHHGhXl2c9lSjVYMvE22+AiO9/kxIHcBLC0uSJHqJJHEkbgRGe0T/BHyawKSQ1 76Gk6rzoxn00m9yycEU1LxEDww/X0btKohmyajAJ+ZLRRgLUOFaV2NwNoYkZ26IEQ/To cveFvxVn2QZZMKZOKRtWKMc2HgBW58knsMpE/F85Jb4aedlb9BczmMz+IYdg3NaSZgCj wMUQ== MIME-Version: 1.0 X-Received: by 10.50.122.99 with SMTP id lr3mr46928370igb.10.1407923489893; Wed, 13 Aug 2014 02:51:29 -0700 (PDT) Received: by 10.107.1.19 with HTTP; Wed, 13 Aug 2014 02:51:29 -0700 (PDT) In-Reply-To: <53EB0DA0.5000305@freebsd.org> References: <53EA0EC2.2070601@freebsd.org> <53EA1E5A.5020707@FreeBSD.org> <53EA2D00.7010307@freebsd.org> <53EB0DA0.5000305@freebsd.org> Date: Wed, 13 Aug 2014 10:51:29 +0100 Message-ID: Subject: Re: Keymap definitions for VT / NEWCONS From: Tom Evans To: Stefan Esser Content-Type: text/plain; charset=UTF-8 Cc: "Andrey V. Elsukov" , Aleksandr Rybalko , Ed Maste , FreeBSD Stable , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 09:51:31 -0000 On Wed, Aug 13, 2014 at 8:02 AM, Stefan Esser wrote: > - What shall we do with keymaps like "latinamerican.kbd"? > We could install it under one name and symlink (or link) all > the other relevant locale names to this name. > Thank you for doing this work Stefan! Facebook (and a few others from what I can tell) are using es_LA for Latin America (it should be Laos Spanish really) and ar_AR for a generic Arabic. Cheers Tom From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 13 12:45:59 2014 Return-Path: Delivered-To: freebsd-hackers@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 CA2DA953; Wed, 13 Aug 2014 12:45:59 +0000 (UTC) Received: from mailout08.t-online.de (mailout08.t-online.de [194.25.134.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 867682292; Wed, 13 Aug 2014 12:45:59 +0000 (UTC) Received: from fwd37.aul.t-online.de (fwd37.aul.t-online.de [172.20.27.137]) by mailout08.t-online.de (Postfix) with SMTP id 5F79241917B; Wed, 13 Aug 2014 14:40:19 +0200 (CEST) Received: from [192.168.119.33] (bHpLe8ZXrhJo+tbM6ny1l+je6mB1dqR7DSwP9UIQ6YbgzoAIh0tXUu4L7A3MdqTw8P@[84.154.101.219]) by fwd37.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XHXqj-0clLRw0; Wed, 13 Aug 2014 14:40:17 +0200 Message-ID: <53EB5CA9.5@freebsd.org> Date: Wed, 13 Aug 2014 14:40:09 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Tom Evans Subject: Re: Keymap definitions for VT / NEWCONS References: <53EA0EC2.2070601@freebsd.org> <53EA1E5A.5020707@FreeBSD.org> <53EA2D00.7010307@freebsd.org> <53EB0DA0.5000305@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ID: bHpLe8ZXrhJo+tbM6ny1l+je6mB1dqR7DSwP9UIQ6YbgzoAIh0tXUu4L7A3MdqTw8P X-TOI-MSGID: f2e2b01a-3e80-4f94-85af-8e2153211de0 Cc: "Andrey V. Elsukov" , Aleksandr Rybalko , Ed Maste , FreeBSD Stable , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 12:45:59 -0000 Am 13.08.2014 um 11:51 schrieb Tom Evans: > On Wed, Aug 13, 2014 at 8:02 AM, Stefan Esser wrote: >> - What shall we do with keymaps like "latinamerican.kbd"? >> We could install it under one name and symlink (or link) all >> the other relevant locale names to this name. > > Thank you for doing this work Stefan! > > Facebook (and a few others from what I can tell) are using es_LA for > Latin America (it should be Laos Spanish really) and ar_AR for a > generic Arabic. Really? Seems we do not have any support for Arabic locales, neither in "/usr/share/locale", nor in the form of a keymap file ... So, we have no use for "ar_AR". But "es_LA" might really be a good name for the many Spanish speaking South American countries. I propose to rename "latinamerican.kbd" to "es_LA.kbd" using that convention, then. Thank you for bringing these points to my attention! If we can agree on locale-based keymap names as the rule (with exceptions, as required), then I'd like to commit the first round of keymap files to vt/keymaps tomorrow. This commit will not include accented versions or other special cases (Ctrl <-> Caps-Lock), since I think we ought to think about naming conventions or a general concept for these variations of default keymaps. If a locale defaults to "deadkeys", then the default keymap should follow suit. These keymaps are currently named with ".acc" attached to the name. But it will take too long to converge to an optimal keymap for each affected locale ... I guess we should follow what other systems do (MacOS or Windows), since this is what the majority of users will expect, anyway. But I'm open to suggestions ... ;-) Best regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 13 13:47:57 2014 Return-Path: Delivered-To: freebsd-hackers@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 5BD9CBFC; Wed, 13 Aug 2014 13:47:57 +0000 (UTC) Received: from csmtp2.one.com (csmtp2.one.com [91.198.169.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 18CAA2986; Wed, 13 Aug 2014 13:47:56 +0000 (UTC) Received: from [192.168.212.253] (213083164002.static.sonofon.dk [213.83.164.2]) by csmtp2.one.com (Postfix) with ESMTPA id F287240014974; Wed, 13 Aug 2014 13:47:53 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Keymap definitions for VT / NEWCONS From: Erik Cederstrand In-Reply-To: <53EB5CA9.5@freebsd.org> Date: Wed, 13 Aug 2014 15:47:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <26160DA3-2BCA-434A-B3E3-F522490A70DF@cederstrand.dk> References: <53EA0EC2.2070601@freebsd.org> <53EA1E5A.5020707@FreeBSD.org> <53EA2D00.7010307@freebsd.org> <53EB0DA0.5000305@freebsd.org> <53EB5CA9.5@freebsd.org> To: Stefan Esser X-Mailer: Apple Mail (2.1878.6) Cc: Tom Evans , Aleksandr Rybalko , Ed Maste , "freebsd-hackers@freebsd.org" , "Andrey V. Elsukov" , FreeBSD Stable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 13:47:57 -0000 Den 12/08/2014 kl. 19.40 skrev Ed Maste : > On 12 August 2014 11:04, Stefan Esser wrote: >> This is my list of converted keymaps I'm ready to commit: > ... >> danish.acc.kbd >> danish.kbd >=20 > I wonder if we should use this opportunity to rationalize the keyboard > layout names, using two letter codes consistently (so dk.kbd). Sounds like a good idea. Just provide some kind of translation file = instead of bailing and using a default keymap. Trying to desperately = remember the default US layout just to edit rc.conf and reboot is a = pain. Preferably as a warning at boot time like 'keymap "danish.iso.kbd" = is deprecated. The new name is "da_DK.kbd". Please edit /etc/rc.conf'. Thanks, Erik= From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 13 17:00:33 2014 Return-Path: Delivered-To: hackers@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 8B5DA553 for ; Wed, 13 Aug 2014 17:00:33 +0000 (UTC) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4EBD82193 for ; Wed, 13 Aug 2014 17:00:33 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id hy4so31281vcb.13 for ; Wed, 13 Aug 2014 10:00:32 -0700 (PDT) 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=LhwtF7o3b9lqD+jpwrnt/8tL4WRqV13E95MoRkpKB2k=; b=OX0pf+GujvCbUt0D7SKHSY2KrvD8b+LlHcXvrUC56Khjwi62aU9beEXjyEwVCwf7xU A4BzMklKHdkzHeyS57AQoSj7OoX6qf6I1s++c9DDHe+PapCt6h2Zb/hfT0drpBIsg2ZX ZvF0pci47SGxhkt6AEoxPh0FDYNL3CAxIJCQPq1vvc09KcjiBbDCrrNMejND5LbQuWcv crMIaqEGK8PuVTjBnvqw8Fm3jB1Hwwbn567j1QWuNyd4q2dgvRfUEP0RpQkU/dkJxWM4 U/vb8zahEP0pkVOo1jocjNu8qtStvPAzEVSR0WqGZnGVzVjzJsZwtFTSpso6/YDqTGQ8 MYyw== MIME-Version: 1.0 X-Received: by 10.220.190.134 with SMTP id di6mr2480193vcb.43.1407949232285; Wed, 13 Aug 2014 10:00:32 -0700 (PDT) Received: by 10.221.18.133 with HTTP; Wed, 13 Aug 2014 10:00:32 -0700 (PDT) Date: Wed, 13 Aug 2014 12:00:32 -0500 Message-ID: Subject: sysctl(3) question From: "Sam Fourman Jr." To: hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 17:00:33 -0000 Hello Hackers, the following command gives me the disks in a system sysctl kern.disks kern.disks: cd0 ada0 my question is, what paramaters and values do I have to pass sysctl(3) to give me those disks? I have tried and I cant get HW_DISKNAMES from to work #include #include #include #include #include int main(void) { int mib[2]; size_t len; char *p; mib[0] = CTL_HW; mib[1] = HW_DISKNAMES; /* Determine how much space to allocate. */ if (sysctl(mib, 2, NULL, &len, NULL, 0) == -1) err(1, "sysctl"); if ((p = (char *)malloc(len)) == NULL) err(1, NULL); /* Populate the allocated area with the string returned * * by sysctl. * */ if (sysctl(mib, 2, p, &len, NULL, 0) == -1) err(1, "sysctl"); printf("%s\n", p); return 0; } Sam Fourman Jr. From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 13 17:14:14 2014 Return-Path: Delivered-To: hackers@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 59AC9AEB for ; Wed, 13 Aug 2014 17:14:14 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2F2FF245E for ; Wed, 13 Aug 2014 17:14:13 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XHc7j-0006l1-8s; Wed, 13 Aug 2014 17:14:07 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s7DHE6pW035287; Wed, 13 Aug 2014 11:14:06 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/4mOcJcQnNUcOkFwKFUsNi X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: sysctl(3) question From: Ian Lepore To: "Sam Fourman Jr." In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Wed, 13 Aug 2014 11:14:06 -0600 Message-ID: <1407950046.56408.513.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 17:14:14 -0000 On Wed, 2014-08-13 at 12:00 -0500, Sam Fourman Jr. wrote: > Hello Hackers, > > the following command gives me the disks in a system > sysctl kern.disks > kern.disks: cd0 ada0 > > > my question is, what paramaters and values do I have to pass sysctl(3) to > give me those disks? > > > > I have tried and I cant get HW_DISKNAMES from to work > > > #include > #include > #include > #include > #include > > int main(void) { > > int mib[2]; > size_t len; > char *p; > > mib[0] = CTL_HW; > mib[1] = HW_DISKNAMES; > > /* Determine how much space to allocate. */ > if (sysctl(mib, 2, NULL, &len, NULL, 0) == -1) > err(1, "sysctl"); > > if ((p = (char *)malloc(len)) == NULL) > err(1, NULL); > > /* Populate the allocated area with the string returned > * * by sysctl. > * */ > if (sysctl(mib, 2, p, &len, NULL, 0) == -1) > err(1, "sysctl"); > > printf("%s\n", p); > > return 0; > } > > Sam Fourman Jr. It looks like the HW_DISKNAMES oid is obsolete and the docs and header file never got updated to reflect that. The new disks list uses OID_AUTO rather than a fixed number, so use sysctlbyname(3) to access it. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 13 18:29:25 2014 Return-Path: Delivered-To: hackers@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 A5E53950 for ; Wed, 13 Aug 2014 18:29:25 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 61AC52B97 for ; Wed, 13 Aug 2014 18:29:25 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 940816A6005; Wed, 13 Aug 2014 20:29:21 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id s7DITLgo025748; Wed, 13 Aug 2014 20:29:21 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id s7DITLbq024690; Wed, 13 Aug 2014 20:29:21 +0200 (CEST) (envelope-from lars) Date: Wed, 13 Aug 2014 20:29:21 +0200 From: Lars Engels To: "Sam Fourman Jr." Subject: Re: sysctl(3) question Message-ID: <20140813182921.GG98029@e-new.0x20.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="zGQnqpIoxlsbsOfg" Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p4 User-Agent: Mutt/1.5.23 (2014-03-12) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 18:29:25 -0000 --zGQnqpIoxlsbsOfg Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 13, 2014 at 12:00:32PM -0500, Sam Fourman Jr. wrote: > Hello Hackers, >=20 > the following command gives me the disks in a system > sysctl kern.disks > kern.disks: cd0 ada0 >=20 >=20 > my question is, what paramaters and values do I have to pass sysctl(3) to > give me those disks? >=20 >=20 >=20 > I have tried and I cant get HW_DISKNAMES from to work >=20 >=20 > #include > #include > #include > #include > #include >=20 > int main(void) { >=20 > int mib[2]; > size_t len; > char *p; >=20 > mib[0] =3D CTL_HW; > mib[1] =3D HW_DISKNAMES; >=20 > /* Determine how much space to allocate. */ > if (sysctl(mib, 2, NULL, &len, NULL, 0) =3D=3D -1) > err(1, "sysctl"); >=20 > if ((p =3D (char *)malloc(len)) =3D=3D NULL) > err(1, NULL); >=20 > /* Populate the allocated area with the string returned > * * by sysctl. > * */ > if (sysctl(mib, 2, p, &len, NULL, 0) =3D=3D -1) > err(1, "sysctl"); >=20 > printf("%s\n", p); >=20 > return 0; > } Try sysctlbyname(): #include #include #include #include #include int main(void) { size_t len; char *p; /* Determine how much space to allocate. */ if (sysctlbyname("kern.disks", NULL, &len, NULL, 0) =3D=3D -1) err(1, "sysctl"); if ((p =3D (char *)malloc(len)) =3D=3D NULL) err(1, NULL); if (sysctlbyname("kern.disks", p, &len, NULL, 0) =3D=3D -1) err(1, "sysctl"); printf("%s\n", p); return 0; } --zGQnqpIoxlsbsOfg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJT666AXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1t480H/AojYkkRGlYGimypyiyz1yYs 2BCM2dM9uw1jmtEV6I6lryQGg7If2qgqwK7DNKud9b4cpIJ4dBnz4O9I+K+gYRkn +UfWDE8v8s7T/dSs/jIcNnztZzvFDxAzQsJAGs5CUWq6oIErDR5EzcM2tARQ9PVc s1yD7x/7oh1YrS+Ekg76S8I44PWwpSMt9AktwaZGDdZfVJIFPqytck1Bztbk5SOv f4vL/usotSbYVl1DHTdfA8RlxR2hA58hnhTf9YO1q2i6rnO0k8RgwujP7AONPOIy r/Pdu6uRfLgh4rTmo5qi+KQ4Mluut9dc0CJw5H21gwlvVxsskKj7iqV9BXinhjY= =ovRq -----END PGP SIGNATURE----- --zGQnqpIoxlsbsOfg-- From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 13 20:31:41 2014 Return-Path: Delivered-To: freebsd-hackers@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 0C692243; Wed, 13 Aug 2014 20:31:41 +0000 (UTC) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BBEA42AE2; Wed, 13 Aug 2014 20:31:40 +0000 (UTC) Received: by mail-ig0-f181.google.com with SMTP id h3so2967348igd.8 for ; Wed, 13 Aug 2014 13:31:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=iFLP8dFNRnAxAoUa0S2w1ivaM6KIB61lt8uckOyGvzM=; b=KuN9w5ND57htgPK540ub3/L3wSvkQvPMBO3kcAQvw+UAD35WM8KRtFH6T3l+Q6bS/e Tf7xIVT/MOq/J6AxnUSs6ElcuRVuo8a+Jxit2tqiFCKYxcLq5ZNQJPKQJIV8khHgIaVW C4kkfcFPxuzS1ztwT9s9WjylLzr0TPvHyusy39wUlpW+3LUz1nmLIoDtbk4FWrd8kQ7v WDLw4wkOzbTwDuqRHD6tTrnnlPC5a+YHoSoZAkVALV4Z1XaCfFkz1ag1AKkKk80tmJzM jTstqE4AEUQyS3HvjRF/TfULmHlRgu7DxpFxx48680b8zdneyHNMB5Q/mtfQp8GSH2lG /FOQ== X-Received: by 10.50.6.77 with SMTP id y13mr10892497igy.21.1407961900141; Wed, 13 Aug 2014 13:31:40 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.131.38 with HTTP; Wed, 13 Aug 2014 13:31:20 -0700 (PDT) In-Reply-To: <53EB0DA0.5000305@freebsd.org> References: <53EA0EC2.2070601@freebsd.org> <53EA1E5A.5020707@FreeBSD.org> <53EA2D00.7010307@freebsd.org> <53EB0DA0.5000305@freebsd.org> From: Ed Maste Date: Wed, 13 Aug 2014 16:31:20 -0400 X-Google-Sender-Auth: ZnuYBixi2mhUJWHsyvQIBTae2NM Message-ID: Subject: Re: Keymap definitions for VT / NEWCONS To: Stefan Esser Content-Type: text/plain; charset=UTF-8 Cc: "Andrey V. Elsukov" , Aleksandr Rybalko , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 20:31:41 -0000 On 13 August 2014 03:02, Stefan Esser wrote: > > I have renamed the files to 2-character ISO country code names, and > have used the form "fr_CH.kbd" (instead of "swisscfrench.iso.kbd") > where there are several locales within a country. This sounds good to me. > Unresolved: > > - Shall keymap names for countries where language and country are > identical (e.g. "pt.kbd") be converted to "pt_PT.kbd"? > (I'd say yes ...) We already had ua.kbd and pl.kbd and I just now brought over the ??.iso.kbd files before catching up on this thread. It seems reasonable to me to use only the language code unless we need to be more specific. > - In the example of Switzerland, "swissgerman.kbd" becomes "de_CH.kbd". Sounds good to me. > * Do we want to add "ch.kbd", too? > * Should it be a symlink to one of the other keymap files (the > majority of the Swiss population would use de_CH, I guess) ... > That would imply, that for every locale selected by a user, there > is a matching default keyboard. I wouldn't worry about this unless there's a precedent in X11 or the Linux console. > And after all these normalizations have been performed: > > - How do we deal with accented versions of keymaps? > (Those with ".acc." in their names ...) I think we can just bring them over as ??.acc.kbd once we've verified they work as expected. > - Do we keep all those variants that only differe in the handling > of the Caps-Lock key (which often is mapped to an additional > Control key)? I don't see why not. Oh, one other point: I'll add a stripped-down share/vt/INDEX.keymaps shortly, and we can add new entries there as we bring the keymaps over. We'll also need UTF-8 encoded translations of the names. -Ed From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 13 21:14:47 2014 Return-Path: Delivered-To: freebsd-hackers@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 E0C82FC5; Wed, 13 Aug 2014 21:14:47 +0000 (UTC) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A11E9208D; Wed, 13 Aug 2014 21:14:47 +0000 (UTC) Received: by mail-ig0-f174.google.com with SMTP id c1so11613026igq.1 for ; Wed, 13 Aug 2014 14:14:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=II7wkC2e97kFLCPZSwYa6ClChks58mIgEDwLebKaing=; b=E+PJNN4gMS6sQF6A0hYZTq+A79byFoTX2W6gvGzDnIoE+ljK2cMI61/EwnzJPfVC+u 2Rojq7DNIqGVjsCO4PjsW0fScjpQ/5zcss3n8zcx0Oa8K61DOUJlSZT0dOsrdbM5vsX4 qcAe8DGzhd/Dv7u9Y5v1VpjoLyUWTkcvzZS8bApA++wn3hCSydMEXJ/5DL41VpqlUHlW wBoEc+7Typ/c1KvnfbSmz2omky6E/rt50SQrycn3hX/dqPxLj556FYDNGmH2AAXj0NkR MefHl1kJ3c0WP2hlkN5WjkTEwXGKA9kIUx+NM6Fq6oxm+LGyw1yZo3trgDEM8+rrXlBj EHpA== X-Received: by 10.50.2.42 with SMTP id 10mr11013395igr.33.1407964487148; Wed, 13 Aug 2014 14:14:47 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.131.38 with HTTP; Wed, 13 Aug 2014 14:14:26 -0700 (PDT) In-Reply-To: <26160DA3-2BCA-434A-B3E3-F522490A70DF@cederstrand.dk> References: <53EA0EC2.2070601@freebsd.org> <53EA1E5A.5020707@FreeBSD.org> <53EA2D00.7010307@freebsd.org> <53EB0DA0.5000305@freebsd.org> <53EB5CA9.5@freebsd.org> <26160DA3-2BCA-434A-B3E3-F522490A70DF@cederstrand.dk> From: Ed Maste Date: Wed, 13 Aug 2014 17:14:26 -0400 X-Google-Sender-Auth: vNtnmX4SHPXZX5UourbY-GRbo78 Message-ID: Subject: Re: Keymap definitions for VT / NEWCONS To: Erik Cederstrand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-hackers@freebsd.org" , Aleksandr Rybalko X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 21:14:48 -0000 On 13 August 2014 09:47, Erik Cederstrand wrote= : >> >> I wonder if we should use this opportunity to rationalize the keyboard >> layout names, using two letter codes consistently (so dk.kbd). > > Sounds like a good idea. Just provide some kind of translation file inste= ad of bailing and using a default keymap. Trying to desperately remember th= e default US layout just to edit rc.conf and reboot is a pain. Preferably a= s a warning at boot time like 'keymap "danish.iso.kbd" is deprecated. The n= ew name is "da_DK.kbd". Please edit /etc/rc.conf'. Yeah, that's important. It should be straightforward for us to identify an old keymap variable (test that sysctl kern.vty=3Dvt and that /usr/share/vt/keymaps/${keymap} does not exist), and then just have a big switch statement of old and new names. From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 13 22:59:39 2014 Return-Path: Delivered-To: freebsd-hackers@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 C5D964B5; Wed, 13 Aug 2014 22:59:39 +0000 (UTC) Received: from mailout07.t-online.de (mailout07.t-online.de [194.25.134.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5A4062B71; Wed, 13 Aug 2014 22:59:39 +0000 (UTC) Received: from fwd28.aul.t-online.de (fwd28.aul.t-online.de [172.20.26.133]) by mailout07.t-online.de (Postfix) with SMTP id 9378A10EA24; Thu, 14 Aug 2014 00:59:31 +0200 (CEST) Received: from [192.168.119.33] (TJydViZTghsynjqH2ztbO+PYY+ehKwkEuzaBAfM88FjpfimvOi6VPIL69ewMZA+QQo@[84.154.101.219]) by fwd28.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XHhVv-0f8jfE0; Thu, 14 Aug 2014 00:59:27 +0200 Message-ID: <53EBEDC8.3080303@freebsd.org> Date: Thu, 14 Aug 2014 00:59:20 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Ed Maste Subject: Re: Keymap definitions for VT / NEWCONS References: <53EA0EC2.2070601@freebsd.org> <53EA1E5A.5020707@FreeBSD.org> <53EA2D00.7010307@freebsd.org> <53EB0DA0.5000305@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ID: TJydViZTghsynjqH2ztbO+PYY+ehKwkEuzaBAfM88FjpfimvOi6VPIL69ewMZA+QQo X-TOI-MSGID: 102f1587-32e1-4b6b-9880-e2d06dd295e6 Cc: "Andrey V. Elsukov" , Aleksandr Rybalko , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 22:59:39 -0000 Am 13.08.2014 um 22:31 schrieb Ed Maste: > On 13 August 2014 03:02, Stefan Esser wrote: >> >> I have renamed the files to 2-character ISO country code names, and >> have used the form "fr_CH.kbd" (instead of "swisscfrench.iso.kbd") >> where there are several locales within a country. > > This sounds good to me. > >> Unresolved: >> >> - Shall keymap names for countries where language and country are >> identical (e.g. "pt.kbd") be converted to "pt_PT.kbd"? >> (I'd say yes ...) > > We already had ua.kbd and pl.kbd and I just now brought over the > ??.iso.kbd files before catching up on this thread. It seems :( :( I had announced that I was waiting for feedback until Thursday before I wanted to commit what I have prepared. I have spent many hours converting keymaps (not only the trivial ones, which are identical in ISO8859-1 and UTF-8), and I'm really annoyed! > reasonable to me to use only the language code unless we need to be > more specific. I wanted to have consensus on this before we start committing keymap files. And I think it is better to use locale names in any case. The selection logic has to be there for locales, why complicate matters by introducing 2-letter names, which in fact match the 2nd half of a locale name when country code and language code don't match (as in "en_US.kbd" vs "us.kbd"). I think we should provide keymap files under the same names as the locale names (less the encoding). We'll need a mapping file (like "INDEX.keymaps" for syscons), I assume. But I'm not sure about all these points ... >> - In the example of Switzerland, "swissgerman.kbd" becomes "de_CH.kbd". > > Sounds good to me. > >> * Do we want to add "ch.kbd", too? >> * Should it be a symlink to one of the other keymap files (the >> majority of the Swiss population would use de_CH, I guess) > ... >> That would imply, that for every locale selected by a user, there >> is a matching default keyboard. > > I wouldn't worry about this unless there's a precedent in X11 or the > Linux console. Well, I do not think that a locale is complete without a keymap, even though these are completely independent parts of the system (locale handling vs. keymaps). But I'd expect that a keymap exists, if a locale is supported and vice versa. >> And after all these normalizations have been performed: >> >> - How do we deal with accented versions of keymaps? >> (Those with ".acc." in their names ...) > > I think we can just bring them over as ??.acc.kbd once we've verified > they work as expected. The keymap names are not consistent, as it is now. If we agree, that names without ".acc." are "nodeadkey" variants and with ".acc." have dead keys for accents and the like, then for some locales the ".acc." version will be "normal" and expected by users, while its the plain version for other locales. That's why I suggested to follow some other system (e.g. Windows) use of accent keys / dead keys. Users in the respective locales will know and expect the keyboard to behave just this way. Special keyboards (e.g. Dvorak layouts) do obviously need special keymap files (with .dvorak. inserted). But for the typical PC keyboard used today, I'd hope for the same behaviour as under Windows (not claiming that it is correct, just that it is expected). >> - Do we keep all those variants that only differe in the handling >> of the Caps-Lock key (which often is mapped to an additional >> Control key)? > > I don't see why not. > > Oh, one other point: I'll add a stripped-down share/vt/INDEX.keymaps > shortly, and we can add new entries there as we bring the keymaps > over. We'll also need UTF-8 encoded translations of the names. I really want to have a concept on what the keymap names shall be and how they are selected (in rc.conf and in the installer). And it is really annoying to see my efforts wasted! :( STefan From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 14 03:15:20 2014 Return-Path: Delivered-To: freebsd-hackers@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 E21F3EF5; Thu, 14 Aug 2014 03:15:19 +0000 (UTC) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9CE10264B; Thu, 14 Aug 2014 03:15:19 +0000 (UTC) Received: by mail-ig0-f178.google.com with SMTP id uq10so3748236igb.5 for ; Wed, 13 Aug 2014 20:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=z/HCRRVXvOY7ebc+Qq17PL75dwnVAJkQaoSEVY8l4LU=; b=rUWSftvrctvjLxvL/n3zzuXtIw9+deVrna/8413dg4tPymhv7U6jOr2dUMVnc72ld+ 2eyr4rQMdBAdjliT7UzAwIzjD/w8lsUbt+ZeZAc7VpUyFetKozmR8WYWzBctxNldc2yD AThcSV4e03qHGktWoix4iCMhLH2kP3Rl1XFHOKgt7Wgfj0MDRUy0TTcbMyETX8J8cGn+ xOmb+JvqQ08W+6YbcXWzxNVwMlwkUBQAl2oLGXWWr/30k4jqvI9NouqUTFVABHMjThgo 2CNQciAQvNE/9rroH60h6dMeNDt8vOUGgE/vzYa54jHTtCKn7ZyPKf9uaZM/eabvNvUM 3tCw== X-Received: by 10.50.32.2 with SMTP id e2mr53609214igi.33.1407986118975; Wed, 13 Aug 2014 20:15:18 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.131.38 with HTTP; Wed, 13 Aug 2014 20:14:58 -0700 (PDT) In-Reply-To: <53EBEDC8.3080303@freebsd.org> References: <53EA0EC2.2070601@freebsd.org> <53EA1E5A.5020707@FreeBSD.org> <53EA2D00.7010307@freebsd.org> <53EB0DA0.5000305@freebsd.org> <53EBEDC8.3080303@freebsd.org> From: Ed Maste Date: Wed, 13 Aug 2014 23:14:58 -0400 X-Google-Sender-Auth: 0mmyUijrjKdptikutEztl4K2fao Message-ID: Subject: Re: Keymap definitions for VT / NEWCONS To: Stefan Esser Content-Type: text/plain; charset=UTF-8 Cc: "Andrey V. Elsukov" , Aleksandr Rybalko , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 03:15:20 -0000 On 13 August 2014 18:59, Stefan Esser wrote: > > And I think it is better to use locale names in any case. The > selection logic has to be there for locales, why complicate > matters by introducing 2-letter names, which in fact match > the 2nd half of a locale name when country code and language > code don't match (as in "en_US.kbd" vs "us.kbd"). > > I think we should provide keymap files under the same names > as the locale names (less the encoding). But there isn't a 1:1 mapping between locales and keyboard maps, since we have to deal with some special cases (like dvorak). We should let the end user independently choose the language (for interacting with the installer), keymap, and locale anyway, even though in most cases there is a straightforward mapping between them. So I don't think it makes much difference if we have a keymap called fr.kbd for example, or a different name. > We'll need a mapping file (like "INDEX.keymaps" for syscons), > I assume. I wouldn't necessarily call INDEX.keymaps a mapping file; it's just used for the menu-driven keymap selection. I think we can use the exact same scheme and file format for vt(4). > The keymap names are not consistent, as it is now. If we agree, > that names without ".acc." are "nodeadkey" variants and with > ".acc." have dead keys for accents and the like, then for some > locales the ".acc." version will be "normal" and expected by > users, while its the plain version for other locales. Are you proposing that we have a combination of *.kbd, *.acc.kbd, and *.nodeadkey.kbd variants, depending on which type is the common / expected case for various layouts? > That's why I suggested to follow some other system (e.g. Windows) > use of accent keys / dead keys. Users in the respective locales > will know and expect the keyboard to behave just this way. I think it's important to make a distinction between the way the user selects a keymap, and the filename. In the common case I think users will choose a layout from a menu, and won't necessarily see or care about the filename. I'm not sure what contemporary Windows versions do with respect to keyboard selection - can you describe the process it uses? > And it is really annoying to see my efforts wasted! :( I don't think any of your effort is wasted -- my commit was just an svn copy of the 8 trivial kbd files, as I thought you were working only on the keymap files needing conversion for Unicode. Anyhow, changing the naming scheme (if we want to do that) isn't a big deal. We'd have to deal with pl.kbd and ua.kbd already. -Ed From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 14 12:28:45 2014 Return-Path: Delivered-To: freebsd-hackers@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 73A94AC5; Thu, 14 Aug 2014 12:28:45 +0000 (UTC) Received: from mailout05.t-online.de (mailout05.t-online.de [194.25.134.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 214542EEB; Thu, 14 Aug 2014 12:28:44 +0000 (UTC) Received: from fwd06.aul.t-online.de (fwd06.aul.t-online.de [172.20.26.150]) by mailout05.t-online.de (Postfix) with SMTP id 121D23C404E; Thu, 14 Aug 2014 14:21:47 +0200 (CEST) Received: from [192.168.119.33] (X7Fk+ZZJgh49SMOJ8ambL4TSIJHDu3Jo8Dq6ErcXlrWOQ6iJB5Ipqnaqc7tsxqvZvc@[84.154.101.219]) by fwd06.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XHu2J-2exh3o0; Thu, 14 Aug 2014 14:21:43 +0200 Message-ID: <53ECA9CE.3070106@freebsd.org> Date: Thu, 14 Aug 2014 14:21:34 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Ed Maste Subject: Re: Keymap definitions for VT / NEWCONS References: <53EA0EC2.2070601@freebsd.org> <53EA1E5A.5020707@FreeBSD.org> <53EA2D00.7010307@freebsd.org> <53EB0DA0.5000305@freebsd.org> <53EBEDC8.3080303@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ID: X7Fk+ZZJgh49SMOJ8ambL4TSIJHDu3Jo8Dq6ErcXlrWOQ6iJB5Ipqnaqc7tsxqvZvc X-TOI-MSGID: 18053e4a-8484-4542-8069-c59e96545eec Cc: "Andrey V. Elsukov" , Aleksandr Rybalko , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 12:28:45 -0000 Am 14.08.2014 um 05:14 schrieb Ed Maste: > On 13 August 2014 18:59, Stefan Esser wrote: >> >> And I think it is better to use locale names in any case. The >> selection logic has to be there for locales, why complicate >> matters by introducing 2-letter names, which in fact match >> the 2nd half of a locale name when country code and language >> code don't match (as in "en_US.kbd" vs "us.kbd"). >> >> I think we should provide keymap files under the same names >> as the locale names (less the encoding). > > But there isn't a 1:1 mapping between locales and keyboard maps, since > we have to deal with some special cases (like dvorak). We should let > the end user independently choose the language (for interacting with > the installer), keymap, and locale anyway, even though in most cases > there is a straightforward mapping between them. So I don't think it > makes much difference if we have a keymap called fr.kbd for example, > or a different name. There probably won't be a 1:1 mapping for all cases, but I think that there is value in going for a regular naming scheme. We can use "fr.kbd" as a short form of "fr_FR.kbd", but there will be a "fr_CH.kbd" and possibly a "fr_CA.kbd". The "fr" in the short form will correspond to the "FR" in "fr_FR.kbd", which is hidden by the fact, that both parts read "fr". But look at "uk_UA.kbd", which will be short-named as "ua.kbd", or "be_BY.kbd" mapped to "by.kbd" versus "nl_BE.kbd" mapped to "be.kbd". For some language/country combinations, the short form ends up in a distant location to the long form names. And will there be a "ch.kbd" for "de_CH.kbd" (the majority of Swiss users will use that keymap), or will they all be of the form "??_CH.kbd" ... ??? For all these reasons I think the short form serves no real purpose. If you want to support it, you could symlink a short name to the locale based name (to allow the use of just the country code, if people edit rc.conf by hand, while I'd expect the installer to use the locale based keyboard names). >> We'll need a mapping file (like "INDEX.keymaps" for syscons), >> I assume. > > I wouldn't necessarily call INDEX.keymaps a mapping file; it's just > used for the menu-driven keymap selection. I think we can use the > exact same scheme and file format for vt(4). Yes, I know its purpose and I agree, that the format should be usable for NEWCONS keymaps, too. We'd just need to teach it about the two supported drivers and make it select the correct path for SYSCONS vs. NEWCONS (based on the sysctl). I think this should be implemented in time for 10.1, if at all possible. Changes required are: - Selection of NEWCONS/SYSCONS pathes and defaults: * DEFAULT_KEYMAP_DIR * DEFAULT_FONT_DIR * DEFAULT_FONT * DEFAULT_LANG We may want to introduce a new rc.conf variable for NEWCONS, since the format has changed (e.g. no ".iso." in names). That way, a mapping script could suggest a suitable keymap for NEWCONS, if running under NEWCONS and only a SYSCONS keymap has been defined. And that way, you could reboot into SYSCONS in case of problems with NEWCONS and still have your SYSCONS keymap defined (under the old rc.conf variable name). >> The keymap names are not consistent, as it is now. If we agree, >> that names without ".acc." are "nodeadkey" variants and with >> ".acc." have dead keys for accents and the like, then for some >> locales the ".acc." version will be "normal" and expected by >> users, while its the plain version for other locales. > > Are you proposing that we have a combination of *.kbd, *.acc.kbd, and > *.nodeadkey.kbd variants, depending on which type is the common / > expected case for various layouts? I'd think it was best, if we had a common keymap under the name of the locale (e.g. "en_US.kbd"). This keymap should work as expected by users, which in case of e.g. the German keyboard means, that a few accents are deadkeys, while most keys are of the "nodeadkeys" variant. E.g. ^ on my keyboard is used as an accent and needs a blank typed after it to appear on its own, while ~ is not considered an accent, but a "normal" character. (And ´ and ` are accents, while ° and ' are characters.) On the Swiss-German keymap, other characters are expected to work as accents or just as characters. A nodeadkeys variant makes no sense in Switzerland, while it might be of use in Germany (where the accents are only used to write foreign names and the like). >> That's why I suggested to follow some other system (e.g. Windows) >> use of accent keys / dead keys. Users in the respective locales >> will know and expect the keyboard to behave just this way. > > I think it's important to make a distinction between the way the user > selects a keymap, and the filename. In the common case I think users > will choose a layout from a menu, and won't necessarily see or care > about the filename. I'm not sure what contemporary Windows versions > do with respect to keyboard selection - can you describe the process > it uses? The selection is automatic when you install windows. You'll be asked for the language and the country, and while not being displayed, the selection of the keyboard follows the locale selection. You can switch keyboards, e.g. on a Swiss notebook between de_CH and fr_CH. But the keyboard selection tool does not show the locale in that form, instead it only shows the language part (assuming that the country is known). Staying with the example of the Swiss notebook, I get the choice between "DE" and "FR" keyboards. Only if I select the option to also display text labels, these two variants are named "DE Deutsch (Schweiz)" and "FR Französisch (Schweiz)" (the output locale is "German" in both cases, leading to the display of "Französisch" instead of a locale description in French). If you want to add an alternate keyboard layout, your choices are sorted by language, not by country. E.g. on above mentioned Swiss notebook, invoking the "Add Language" option of the keyboard selection utility places me in the scroll area on "Deutsch (Schweiz)" with "Deutsch (Östereich)" above and "Divehi (Malediven)" below ... I'd have thought, that the sorting by country and then by language was more reasonable, but the list is sorted in the same way as in the MS-Office language option for the spell- checker, for example. This Windows tool provides a similar function our language selection tool. After selecting a locale (language,country), a button list is displayed, which allows to select between one or more layouts for that locale. In the case of "English (USA)" the layouts start with "English (USA, Dvorak, left-handed)" and "English (USA, Dvorak, right-handed)" and continue to "English (USA, international)" and "US". There is no choice of deadkeys vs. nodeadkeys variant for any of the keymaps I looked at, but there appear to be variants with regard to "Shift-Lock" or "Caps-Lock" for a few locales. And there are further specialties, like "Spanish" which exists in "international" and "traditional" layouts. This all looks very similar to a tuple of language and country (while locales are country_LANGUAGE) with optional modifiers for specific layouts (like our ".dvorak." in keymap names). >> And it is really annoying to see my efforts wasted! :( > > I don't think any of your effort is wasted -- my commit was just an > svn copy of the 8 trivial kbd files, as I thought you were working > only on the keymap files needing conversion for Unicode. Anyhow, > changing the naming scheme (if we want to do that) isn't a big deal. > We'd have to deal with pl.kbd and ua.kbd already. Sorry, it was late at night and I really have spent quite some time on the conversion of keymap files. Your commits do no harm, although I had prefered to have agreement on the naming of keymap files. And I still strongly prefer names that are identical to locale names, wherever possible. Most users will either use the installer (and will thus never see the locale IDs), or they'll manually edit rc.conf and will know their way. And then it's easier to mechanically put the locale ID in to the keyboard selection variable, instead of thinking about (or looking up) whether this is a country that does not need the full locale ID to select a keymap. In Europe, you'll often need the locale name, not only the country. If you really think that the 2-character ISO country codes should be available as a short-hand, than I'd really want to install the keymap under the locale name and only add a symlink from the country name. Regarding the files you committed: I had edited all files, including those that do not generate different codes when converted to Unicode, at least in so far as I have removed misleading comments (e.g. claiming that the encoding was ISO5589-*, when Unicode is now universally used). I really think we'll regret using anything but locale names for keymaps, and I'd want to rename those that you committed under 2-letter ISO names. Is that acceptable to you? Regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 14 13:59:37 2014 Return-Path: Delivered-To: freebsd-hackers@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 4CC0FBB1 for ; Thu, 14 Aug 2014 13:59:37 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id EA22429A4 for ; Thu, 14 Aug 2014 13:59:36 +0000 (UTC) Received: from Mail-PC.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s7EDxSE3066123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 14 Aug 2014 14:59:29 +0100 (BST) Date: Thu, 14 Aug 2014 14:59:28 +0100 From: Karl Pielorz To: freebsd-hackers@freebsd.org Subject: BTX halted on Proliant DL320 Gen8 v2's - fakeRAID support? Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 13:59:37 -0000 Hi, On our HP DL320 Gen8 v2's - BTX halts if we try to boot with the onboard SATA controller set to 'B120i RAID' mode, and have drives present (output from BTX is below). If you boot with *no drives* present - it works, and does show from pciconf -lv: ahci0@pci0:0:31:2: class=0x010400 card=0x00841590 chip=0x8c048086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = 'Lynx Point SATA Controller 1 [RAID mode]' subclass = RAID But with drives present BTX dies on 9.x, 10.x and a recent 11.x snapshot. Is this controller supported in 'raid' mode? - i.e. if it got past BTX would it be usable? -Karl BTX output (from 10.0-R-amd64 boot) " Loading /boot/defaults/loader.conf \ int=00000008 err=0001681b efl=0007b7a0 eip=0000002b eax=adadf9a8 ebx=adaf5630 ecx=adae3da4 edx=adaf5a38 esi=0007b7b8 edi=00000000 ebp=0007b9a0 esp=00000033 cs=0202 ds=0033 es=0033 fs=0033 gs=0033 ss=0000 cs:eip=00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ss:esp=f0 d0 9b 00 f0 08 ef 00-f0 6c 50 24 8b 50 0b 00 c0 4d f8 00 f0 05 ec 00-f0 f3 05 00 e8 8a 5e 00 BTX halted " From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 14 16:11:41 2014 Return-Path: Delivered-To: freebsd-hackers@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 065B6B0E for ; Thu, 14 Aug 2014 16:11:41 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BA3DC2A56 for ; Thu, 14 Aug 2014 16:11:40 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C42A6B977; Thu, 14 Aug 2014 12:11:39 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: PCIe AER Date: Thu, 14 Aug 2014 12:08:30 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <201408122328.s7CNSGoC077640@elf.torek.net> In-Reply-To: <201408122328.s7CNSGoC077640@elf.torek.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201408141208.30208.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 14 Aug 2014 12:11:39 -0400 (EDT) Cc: Chris Torek X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 16:11:41 -0000 On Tuesday, August 12, 2014 7:28:16 pm Chris Torek wrote: > Is there any sort of overall plan for advanced error reporting > on PCIe? > > I may need to implement something along these lines soon, at least > for detection (not necessarily correction just yet). As Konstantin noted, there is nothing planned. There is the '-e' flag for pciconf, and I have a hack to allow pciconf to clear errors via a '-C' flag. I believe at least NetApp has their own internal AER support, but my understanding is that it is very grotty and not really suitable for upstreaming. Index: err.c =================================================================== --- err.c (revision 270540) +++ err.c (working copy) @@ -171,3 +171,36 @@ mask = read_config(fd, &p->pc_sel, aer + PCIR_AER_COR_STATUS, 4); print_bits("Corrected", aer_cor, mask); } + +void +clear_errors(int fd, struct pci_conf *p) +{ + uint16_t sta, aer; + uint8_t pcie; + + /* Clear standard PCI errors. */ + sta = read_config(fd, &p->pc_sel, PCIR_STATUS, 2); + if ((sta & PCI_ERRORS) != 0) + write_config(fd, &p->pc_sel, PCIR_STATUS, 2, + sta & ~PCI_ERRORS); + + /* See if this is a PCI-express device. */ + pcie = pci_find_cap(fd, p, PCIY_EXPRESS); + if (pcie == 0) + return; + + /* Clear PCI-e errors. */ + sta = read_config(fd, &p->pc_sel, pcie + PCIER_DEVICE_STA, 2); + if ((sta & PCIE_ERRORS) != 0) + write_config(fd, &p->pc_sel, pcie + PCIER_DEVICE_STA, 2, + sta & PCIE_ERRORS); + + /* See if this device supports AER. */ + aer = pcie_find_cap(fd, p, PCIZ_AER); + if (aer == 0) + return; + + /* Clear AER errors. */ + write_config(fd, &p->pc_sel, aer + PCIR_AER_UC_STATUS, 4, 0xffffffff); + write_config(fd, &p->pc_sel, aer + PCIR_AER_COR_STATUS, 4, 0xffffffff); +} Index: pciconf.c =================================================================== --- pciconf.c (revision 270540) +++ pciconf.c (working copy) @@ -80,6 +81,7 @@ static void readit(const char *, const char *, int); static void writeit(const char *, const char *, const char *, int); static void chkattached(const char *); +static void clearerrs(const char *); static int exitstatus = 0; @@ -88,7 +90,8 @@ { fprintf(stderr, "%s\n%s\n%s\n%s\n", "usage: pciconf -l [-bcevV] [device]", " pciconf -a device", + " pciconf -C device", " pciconf -r [-b | -h] device addr[:addr2]", " pciconf -w [-b | -h] device addr value"); exit (1); @@ -98,14 +102,14 @@ main(int argc, char **argv) { int c; - int listmode, readmode, writemode, attachedmode; + int listmode, readmode, writemode, attachedmode, clearmode; int bars, caps, errors, verbose, vpd; int byte, isshort; - listmode = readmode = writemode = attachedmode = 0; + listmode = readmode = writemode = attachedmode = clearmode = 0; bars = caps = errors = verbose = vpd = byte = isshort = 0; - while ((c = getopt(argc, argv, "abcehlrwvV")) != -1) { + while ((c = getopt(argc, argv, "abcCehlrwvV")) != -1) { switch(c) { case 'a': attachedmode = 1; @@ -116,6 +120,10 @@ byte = 1; break; + case 'C': + clearmode = 1; + break; + case 'c': caps = 1; break; @@ -160,6 +172,7 @@ if ((listmode && optind >= argc + 1) || (writemode && optind + 3 != argc) || (readmode && optind + 2 != argc) + || (clearmode && optind + 1 != argc) || (attachedmode && optind + 1 != argc)) usage(); @@ -174,6 +188,8 @@ } else if (writemode) { writeit(argv[optind], argv[optind + 1], argv[optind + 2], byte ? 1 : isshort ? 2 : 4); + } else if (clearmode) { + clearerrs(argv[optind]); } else { usage(); } @@ -642,6 +663,20 @@ return (pi.pi_data); } +void +write_config(int fd, struct pcisel *sel, long reg, int width, uint32_t value) +{ + struct pci_io pi; + + pi.pi_sel = *sel; + pi.pi_reg = reg; + pi.pi_width = width; + pi.pi_data = value; + + if (ioctl(fd, PCIOCWRITE, &pi) < 0) + err(1, "ioctl(PCIOCWRITE)"); +} + static struct pcisel getdevice(const char *name) { @@ -792,19 +827,18 @@ writeit(const char *name, const char *reg, const char *data, int width) { int fd; - struct pci_io pi; + struct pcisel sel; + u_long r, value; - pi.pi_sel = getsel(name); - pi.pi_reg = strtoul(reg, (char **)0, 0); /* XXX error check */ - pi.pi_width = width; - pi.pi_data = strtoul(data, (char **)0, 0); /* XXX error check */ + sel = getsel(name); + r = strtoul(reg, (char **)0, 0); /* XXX error check */ + value = strtoul(data, (char **)0, 0); /* XXX error check */ fd = open(_PATH_DEVPCI, O_RDWR, 0); if (fd < 0) err(1, "%s", _PATH_DEVPCI); - if (ioctl(fd, PCIOCWRITE, &pi) < 0) - err(1, "ioctl(PCIOCWRITE)"); + write_config(fd, &sel, r, width, value); } static void @@ -825,3 +859,33 @@ exitstatus = pi.pi_data ? 0 : 2; /* exit(2), if NOT attached */ printf("%s: %s%s\n", name, pi.pi_data == 0 ? "not " : "", "attached"); } + +static void +clearerrs(const char *name) +{ + int fd; + struct pci_conf_io pc; + struct pci_conf conf[1]; + struct pci_match_conf patterns[1]; + + fd = open(_PATH_DEVPCI, O_RDWR, 0); + if (fd < 0) + err(1, "%s", _PATH_DEVPCI); + + bzero(&pc, sizeof(struct pci_conf_io)); + pc.match_buf_len = sizeof(conf); + pc.matches = conf; + bzero(&patterns, sizeof(patterns)); + patterns[0].pc_sel = getsel(name); + patterns[0].flags = PCI_GETCONF_MATCH_DOMAIN | PCI_GETCONF_MATCH_BUS | + PCI_GETCONF_MATCH_DEV | PCI_GETCONF_MATCH_FUNC; + pc.num_patterns = 1; + pc.pat_buf_len = sizeof(patterns); + pc.patterns = patterns; + + if (ioctl(fd, PCIOCGETCONF, &pc) == -1) + err(1, "ioctl(PCIOCGETCONF)"); + + clear_errors(fd, conf); + close(fd); +} Index: pciconf.h =================================================================== --- pciconf.h (revision 270540) +++ pciconf.h (working copy) @@ -33,11 +33,14 @@ #ifndef __PCICONF_H__ #define __PCICONF_H__ +void clear_errors(int fd, struct pci_conf *p); void list_caps(int fd, struct pci_conf *p); void list_errors(int fd, struct pci_conf *p); void list_slot(struct pci_conf *p); uint8_t pci_find_cap(int fd, struct pci_conf *p, uint8_t id); uint16_t pcie_find_cap(int fd, struct pci_conf *p, uint16_t id); uint32_t read_config(int fd, struct pcisel *sel, long reg, int width); +void write_config(int fd, struct pcisel *sel, long reg, int width, + uint32_t value); #endif -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 14 17:13:46 2014 Return-Path: Delivered-To: freebsd-hackers@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 EE6BD75D; Thu, 14 Aug 2014 17:13:46 +0000 (UTC) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A3D0822AE; Thu, 14 Aug 2014 17:13:46 +0000 (UTC) Received: by mail-ig0-f178.google.com with SMTP id uq10so5650030igb.5 for ; Thu, 14 Aug 2014 10:13:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=CxxfUA6+wi6ivXDY3dJY9RnliCz/lRH/KO+/aNJjEA0=; b=d0Tp6SVm7izYv3uRMLMLS1+0n7QjR9i23oeX+H8Wq/BWq3xN7la1qrC10+B3vvUm/5 UJa1rZZyIeNi9fISm3gkHlppsq3HEuoVj9fjXgAWMta/S8upbn8GT0Fvmy/7Mh27qG69 udiJJCE4NeYKHk+B7WdyLbbRipYLEWeEiJfWQsKV2dEC8eQ8KBgV/od0a5eUdYbDNJhY V9YIKP/EjeSmHMeU7FZ8j5AOwwz8hzWS8b5JeDKq14Q0yRkwj5wZIEAdS6zCCYjHPLoY ijwG9J3icsFl6KpS5hD6kAIjGoie+DdiCpwdsVoAypnInfoP4xSs3XI0P0Zq1x8ljmv8 hpAw== X-Received: by 10.50.73.198 with SMTP id n6mr19010097igv.11.1408036426049; Thu, 14 Aug 2014 10:13:46 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.131.38 with HTTP; Thu, 14 Aug 2014 10:13:25 -0700 (PDT) In-Reply-To: <53ECA9CE.3070106@freebsd.org> References: <53EA0EC2.2070601@freebsd.org> <53EA1E5A.5020707@FreeBSD.org> <53EA2D00.7010307@freebsd.org> <53EB0DA0.5000305@freebsd.org> <53EBEDC8.3080303@freebsd.org> <53ECA9CE.3070106@freebsd.org> From: Ed Maste Date: Thu, 14 Aug 2014 13:13:25 -0400 X-Google-Sender-Auth: sTicM9JUp0YE0YVLpJkElVCH8V0 Message-ID: Subject: Re: Keymap definitions for VT / NEWCONS To: Stefan Esser Content-Type: text/plain; charset=UTF-8 Cc: "Andrey V. Elsukov" , Aleksandr Rybalko , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 17:13:47 -0000 On 14 August 2014 08:21, Stefan Esser wrote: > There probably won't be a 1:1 mapping for all cases, but I think > that there is value in going for a regular naming scheme. > > We can use "fr.kbd" as a short form of "fr_FR.kbd", but there > will be a "fr_CH.kbd" and possibly a "fr_CA.kbd". The "fr" in > the short form will correspond to the "FR" in "fr_FR.kbd", > which is hidden by the fact, that both parts read "fr". I agree that consistency is a useful overall goal, and I don't have a very strong preference for the short names, it just seems to me to map well to what it seems users actually call the keyboard layouts. French, Swiss French, and French Canadian keyboard layouts in these three cases. Also, Linux console setting seems to generally use 2-letter names as far as I can tell. Would every locale we support have either a file or symlink? Or only a subset, roughly equivalent to what's provided by the syscons keymaps today? > But look at "uk_UA.kbd", which will be short-named as "ua.kbd", > or "be_BY.kbd" mapped to "by.kbd" versus "nl_BE.kbd" mapped to > "be.kbd". > > For some language/country combinations, the short form ends up > in a distant location to the long form names. But I expect most users would choose from a menu without seeing the underlying keymap filename anyway, so I don't think this matters much. > And will there be a "ch.kbd" for "de_CH.kbd" (the majority of > Swiss users will use that keymap), or will they all be of the > form "??_CH.kbd" ... ??? I would assume ??_CH.kbd since I suspect users would generally not refer to a "Swiss" keyboard layout, but rather a "Swiss German" or "Swiss French" layout. (I'm happy to be corrected if wrong.) > For all these reasons I think the short form serves no real > purpose. If you want to support it, you could symlink a short > name to the locale based name (to allow the use of just the > country code, if people edit rc.conf by hand, while I'd expect > the installer to use the locale based keyboard names). If we do end up with locale names I don't think there's much value in having short name symlinks. It's just another level of indirection that needs to be kept up to date. > I think this should be implemented in time for 10.1, if at > all possible. Indeed, that is exactly why I wanted to move ahead with the "trivial" cases, even if they turned out not to be so. I'm sorry for the conflict that caused with your work in progress. > Most users will either use the installer (and will thus > never see the locale IDs) I think we agree that for these users it makes very little difference what the keymap name actually is, since they won't see it. > or they'll manually edit rc.conf and will know their way. And in this case I think the country codes are often the way these users think of a layout, with a few cases where more specific names are needed. For example, I wouldn't think of a US English keyboard, but just a US keyboard, and similarly for a French keyboard. I would not expect to look for a Canadian English keyboard, but would look for a Canadian French or Canadian Bilingual keyboard. > And then it's easier to mechanically > put the locale ID in to the keyboard selection variable, > instead of thinking about (or looking up) whether this is > a country that does not need the full locale ID to select > a keymap. But then we either need to provide symlinks for all locale names, or the user needs to determine if their locale is one which has a keymap or not. And there may be ambiguities in the "default" symlink mapping; for instance, there are arguments to be made to symlink en_CA to either en_US or fr_CA. > In Europe, you'll often need the locale name, > not only the country. We don't seem to have many cases of this in the existing syscons keymaps, but you certainly understand this better than I do; perhaps this will be an issue when adding more keymaps. > I really think we'll regret using anything but locale names > for keymaps, and I'd want to rename those that you committed > under 2-letter ISO names. Is that acceptable to you? The worry I have with using locale names is that it implies there is a 1:1 mapping, which is sometimes true and sometimes not. From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 14 22:00:20 2014 Return-Path: Delivered-To: freebsd-hackers@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 608302FD; Thu, 14 Aug 2014 22:00:20 +0000 (UTC) Received: from mailout12.t-online.de (mailout12.t-online.de [194.25.134.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D48874246; Thu, 14 Aug 2014 21:40:49 +0000 (UTC) Received: from fwd27.aul.t-online.de (fwd27.aul.t-online.de [172.20.26.132]) by mailout12.t-online.de (Postfix) with SMTP id 7830E168F76; Thu, 14 Aug 2014 23:40:40 +0200 (CEST) Received: from [192.168.119.33] (JT3mrqZpoh3vDvvQ46QiA29ARFiSraII1jbmLaoytVgLZ-5M+avOQkIcnJht1RlZBX@[84.154.101.219]) by fwd27.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XI2lE-3SmqUC0; Thu, 14 Aug 2014 23:40:40 +0200 Message-ID: <53ED2CCE.2030103@freebsd.org> Date: Thu, 14 Aug 2014 23:40:30 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Ed Maste , freebsd-stable stable Subject: Re: Keymap definitions for VT / NEWCONS References: <53EA0EC2.2070601@freebsd.org> <53EA1E5A.5020707@FreeBSD.org> <53EA2D00.7010307@freebsd.org> <53EB0DA0.5000305@freebsd.org> <53EBEDC8.3080303@freebsd.org> <53ECA9CE.3070106@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ID: JT3mrqZpoh3vDvvQ46QiA29ARFiSraII1jbmLaoytVgLZ-5M+avOQkIcnJht1RlZBX X-TOI-MSGID: 820f0dcc-8905-4c47-9332-1a3a9eef5b3c Cc: "Andrey V. Elsukov" , Aleksandr Rybalko , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 22:00:20 -0000 Am 14.08.2014 um 19:13 schrieb Ed Maste: > On 14 August 2014 08:21, Stefan Esser wrote: >> There probably won't be a 1:1 mapping for all cases, but I think >> that there is value in going for a regular naming scheme. >> >> We can use "fr.kbd" as a short form of "fr_FR.kbd", but there >> will be a "fr_CH.kbd" and possibly a "fr_CA.kbd". The "fr" in >> the short form will correspond to the "FR" in "fr_FR.kbd", >> which is hidden by the fact, that both parts read "fr". > > I agree that consistency is a useful overall goal, and I don't have a > very strong preference for the short names, it just seems to me to map > well to what it seems users actually call the keyboard layouts. > French, Swiss French, and French Canadian keyboard layouts in these > three cases. Also, Linux console setting seems to generally use > 2-letter names as far as I can tell. The existing 2-letter names are inconsistent: most are country codes, but in a few cases the language code was used. I do not know why "iw" is used for he_IL (hebrew / Israel), since "iw" does match neither "he" nor "il" ... You can download and check my not-yet committed working files from: http://people.freebsd.org/~se/vt-keymaps.tar.bz2 That TAR file contains a draft version of INDEX.keymaps, which uses keymap files named after locales. I have removed the now obsolete encoding from the explanation for each keymap file. What's missing is the conversion of the localized texts to Unicode (from some ISO8859 variant or CPxxx or koi8-[ru]). I only fixed the English and German texts, so far. > Would every locale we support have either a file or symlink? Or only > a subset, roughly equivalent to what's provided by the syscons keymaps > today? I think we should try to have at least one default keymap file per locale. A special case is es_LA (which Tom Evans mentioned to be used as a pseudo-locale for spanish speaking latin-american countries by e.g. Facebook). But we could link or symlink other locale names to the generic file, for these cases. >> But look at "uk_UA.kbd", which will be short-named as "ua.kbd", >> or "be_BY.kbd" mapped to "by.kbd" versus "nl_BE.kbd" mapped to >> "be.kbd". >> >> For some language/country combinations, the short form ends up >> in a distant location to the long form names. > > But I expect most users would choose from a menu without seeing the > underlying keymap filename anyway, so I don't think this matters much. Well, if you already have a locale set by the user, then you could prefer keymap files that start with the locale name (sans encoding). I have committed an initial fix to kbdmap/vidfont to make it use share/vt instead of share/syscons if started on a system using NEWCONS. But I guess the selection logic is not correct or at least not optimal. There ought to be sufficient time to fix this for 10.1, though. >> And will there be a "ch.kbd" for "de_CH.kbd" (the majority of >> Swiss users will use that keymap), or will they all be of the >> form "??_CH.kbd" ... ??? > > I would assume ??_CH.kbd since I suspect users would generally not > refer to a "Swiss" keyboard layout, but rather a "Swiss German" or > "Swiss French" layout. (I'm happy to be corrected if wrong.) The selection in Windows is (AFAICR, it's been quite some time since I last installed Windows from DVD) to first choose a language (which changes the messages displayed for the following selections). Then you choose a country to complete the selection of a locale. E.g. first selection is "German" or "French", next selection is the country from a list where this language is spoken (which would offer e.g. Germany, Switzerland, Austria for "German" and Belgium, France, Switzerland for "French"). I really should start the Windows installer to check whether this actually is what Windows does ... ;-) >> For all these reasons I think the short form serves no real >> purpose. If you want to support it, you could symlink a short >> name to the locale based name (to allow the use of just the >> country code, if people edit rc.conf by hand, while I'd expect >> the installer to use the locale based keyboard names). > > If we do end up with locale names I don't think there's much value in > having short name symlinks. It's just another level of indirection > that needs to be kept up to date. Yes, I agree. If the selection of the language (and country, where required) is from a menu, the locale names are as good as any other ID. >> I think this should be implemented in time for 10.1, if at >> all possible. > > Indeed, that is exactly why I wanted to move ahead with the "trivial" > cases, even if they turned out not to be so. I'm sorry for the > conflict that caused with your work in progress. Well, nothing has been lost ;-) I had wanted to commit the keymaps named after locales, today, but held back the commit to wait for your reply and further comments. It's already near midnight, here - so I'll do the commits tomorrow, to avoid making silly mistakes (and it has been shown to be bad practice to go to bed immediately after a commit ;-) >> Most users will either use the installer (and will thus >> never see the locale IDs) > > I think we agree that for these users it makes very little difference > what the keymap name actually is, since they won't see it. > >> or they'll manually edit rc.conf and will know their way. > > And in this case I think the country codes are often the way these > users think of a layout, with a few cases where more specific names > are needed. For example, I wouldn't think of a US English keyboard, > but just a US keyboard, and similarly for a French keyboard. I would > not expect to look for a Canadian English keyboard, but would look for > a Canadian French or Canadian Bilingual keyboard. Please look at the TAR file I prepared. I rank the symmetry in the format of the names higher than the shorter names. And in fact, keyboard layouts are often specific to a country, and not to a language. The 2-letter names hide the difference for the simple case ("fr" is really sufficient if "fr_FR" is meant), but if you look at syscons/keymaps there are examples of keymap files named after the language code and others named after the country code. >> And then it's easier to mechanically >> put the locale ID in to the keyboard selection variable, >> instead of thinking about (or looking up) whether this is >> a country that does not need the full locale ID to select >> a keymap. > > But then we either need to provide symlinks for all locale names, or > the user needs to determine if their locale is one which has a keymap > or not. And there may be ambiguities in the "default" symlink mapping; > for instance, there are arguments to be made to symlink en_CA to > either en_US or fr_CA. Well, I do not have an easy answer to this. But being explicit in the names allows to provide easily identified correct keymaps. >> In Europe, you'll often need the locale name, >> not only the country. > > We don't seem to have many cases of this in the existing syscons > keymaps, but you certainly understand this better than I do; perhaps > this will be an issue when adding more keymaps. Look at the locale names in share/locales. There are quite a number that are of the form "xx_XX" with no other locale sharing the country or locale part. But there are quite a number where languages and countries are in a n:m relation and some where the language and country IDs are different (e.g. "da_DK"). We are used to identify countries with ISO country codes (most probably because of their use in DNS addresses), but as I said, not all 2-letter keymap names where derived from the country code and I can see how that happened. Using locale names adds a few characters to the ID, but makes it really clear what is meant. >> I really think we'll regret using anything but locale names >> for keymaps, and I'd want to rename those that you committed >> under 2-letter ISO names. Is that acceptable to you? > > The worry I have with using locale names is that it implies there is a > 1:1 mapping, which is sometimes true and sometimes not. Do you know about cases where this is the case? I've seen locales where a "Traditional" and "modern" layout exist, but that's easily added (like the .acc." marker) to the keymap name. The keymap named after the locale should be a good first try for a freshly installed system (I hope ...). Regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 14 22:29:51 2014 Return-Path: Delivered-To: freebsd-hackers@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 D789DC89; Thu, 14 Aug 2014 22:29:50 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CAC3D4AD7; Thu, 14 Aug 2014 22:29:49 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id n3so134345wiv.7 for ; Thu, 14 Aug 2014 15:29:48 -0700 (PDT) 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=V1gtltE0QJS+pdidL4YkC/LManSMVTxCWpfbGadyIuk=; b=bx483LpZivAoGJ3g8U9jG4j8au5gE5euLJmWT6gX1UTTQt0HWcNwirlLsxYKB3fgON GeDU7h+qCTW+0BdQUEL9CjoZiM4JaGjgNd3zyO5eX64q8fG99BrhTMPEDIRAoBssIYHQ NaDmGAWV5CbzVVbtEfrwfgdrOz6g8IXelnEuAwW8cD5tnrsW141pviPBXSzbauC6KXsY 9Ed5KrUeP1xIp18qwgDAuXkTvczQFvdspLEIs515hPthZBrJu93d2zruKBV4tG6LH6/e r3UvIU0s9FQDS+pRmgVArvYajITxggMuJlmVbkNR5HbpdNXqm3TlHrt6WPx7Z3I+u8G7 KjDQ== MIME-Version: 1.0 X-Received: by 10.194.71.11 with SMTP id q11mr15439028wju.33.1408055387969; Thu, 14 Aug 2014 15:29:47 -0700 (PDT) Received: by 10.216.176.200 with HTTP; Thu, 14 Aug 2014 15:29:47 -0700 (PDT) In-Reply-To: <53ED2CCE.2030103@freebsd.org> References: <53EA0EC2.2070601@freebsd.org> <53EA1E5A.5020707@FreeBSD.org> <53EA2D00.7010307@freebsd.org> <53EB0DA0.5000305@freebsd.org> <53EBEDC8.3080303@freebsd.org> <53ECA9CE.3070106@freebsd.org> <53ED2CCE.2030103@freebsd.org> Date: Thu, 14 Aug 2014 18:29:47 -0400 Message-ID: Subject: Re: Keymap definitions for VT / NEWCONS From: Brandon Allbery To: Stefan Esser X-Mailman-Approved-At: Thu, 14 Aug 2014 22:33:26 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-stable stable , Aleksandr Rybalko , Ed Maste , "freebsd-hackers@freebsd.org" , "Andrey V. Elsukov" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 22:29:51 -0000 On Thu, Aug 14, 2014 at 5:40 PM, Stefan Esser wrote: > codes, but in a few cases the language code was used. I do not > know why "iw" is used for he_IL (hebrew / Israel), since "iw" > does match neither "he" nor "il" ... > Sounds like a questionable transliteration of the language name (ivrit)... the questionable part being that it's vet, not vav. (Sort of the reverse of Svenska == sv ~~ Swedish.) -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 15 02:34:14 2014 Return-Path: Delivered-To: freebsd-hackers@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 25466174 for ; Fri, 15 Aug 2014 02:34:14 +0000 (UTC) Received: from astart2.astart.com (108-248-95-193.lightspeed.sndgca.sbcglobal.net [108.248.95.193]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ECE1C227F for ; Fri, 15 Aug 2014 02:34:13 +0000 (UTC) Received: from laptop_93.private (localhost [127.0.0.1]) by astart2.astart.com (8.14.4/8.14.4) with ESMTP id s7F2Y67g096117 for ; Thu, 14 Aug 2014 19:34:06 -0700 (PDT) (envelope-from papowell@astart.com) Message-ID: <53ED719E.6000706@astart.com> Date: Thu, 14 Aug 2014 19:34:06 -0700 From: Patrick Powell Reply-To: papowell@astart.com Organization: Astart Technologies User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Keymap definitions for VT / NEWCONS References: <53EA0EC2.2070601@freebsd.org> <53EA1E5A.5020707@FreeBSD.org> <53EA2D00.7010307@freebsd.org> <53EB0DA0.5000305@freebsd.org> <53EBEDC8.3080303@freebsd.org> <53ECA9CE.3070106@freebsd.org> <53ED2CCE.2030103@freebsd.org> In-Reply-To: <53ED2CCE.2030103@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 02:34:14 -0000 On 08/14/14 14:40, Stefan Esser wrote: > The existing 2-letter names are inconsistent: most are country codes, > but in a few cases the language code was used. I do not know why "iw" > is used for he_IL (hebrew / Israel), since "iw" does match neither > "he" nor "il" ... Somebody with a bad sense of humor and who loved making puns? iw == IbreW? From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 15 10:56:21 2014 Return-Path: Delivered-To: hackers@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 ECE4918A for ; Fri, 15 Aug 2014 10:56:21 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A20CF2BC8 for ; Fri, 15 Aug 2014 10:56:21 +0000 (UTC) Received: from th-04.cs.huji.ac.il ([132.65.80.125]) by kabab.cs.huji.ac.il with esmtp id 1XIFB6-000AUc-JS for hackers@freebsd.org; Fri, 15 Aug 2014 13:56:12 +0300 From: Daniel Braniss Subject: Mellanox 10gb driver? Message-Id: <5FA0CF8C-2C93-4639-AA6C-40D3C278FE0F@cs.huji.ac.il> Date: Fri, 15 Aug 2014 13:55:42 +0300 To: hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 10:56:22 -0000 hi all, any idea if there is/will be a driver for: none3@pci0:5:0:0: class=3D0x020000 card=3D0x005515b3 = chip=3D0x100315b3 rev=3D0x00 hdr=3D0x00 vendor =3D 'Mellanox Technologies' device =3D 'MT27500 Family [ConnectX-3]' class =3D network subclass =3D ethernet From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 15 11:38:27 2014 Return-Path: Delivered-To: hackers@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 C7E6DD19 for ; Fri, 15 Aug 2014 11:38:27 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 876B62146 for ; Fri, 15 Aug 2014 11:38:27 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 936C51FE027; Fri, 15 Aug 2014 13:38:18 +0200 (CEST) Message-ID: <53EDF13D.5050206@selasky.org> Date: Fri, 15 Aug 2014 13:38:37 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Daniel Braniss , hackers@freebsd.org Subject: Re: Mellanox 10gb driver? References: <5FA0CF8C-2C93-4639-AA6C-40D3C278FE0F@cs.huji.ac.il> In-Reply-To: <5FA0CF8C-2C93-4639-AA6C-40D3C278FE0F@cs.huji.ac.il> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 11:38:27 -0000 On 08/15/14 12:55, Daniel Braniss wrote: > hi all, > any idea if there is/will be a driver for: > > none3@pci0:5:0:0: class=0x020000 card=0x005515b3 chip=0x100315b3 rev=0x00 hdr=0x00 > vendor = 'Mellanox Technologies' > device = 'MT27500 Family [ConnectX-3]' > class = network > subclass = ethernet > Hi, If you build the kernel using MK_OFED=yes, your hardware is supported by the following modules: .if ${MK_OFED} != "no" || defined(ALL_MODULES) _mlx4= mlx4 _mlx4ib= mlx4ib _mlxen= mlxen _mthca= mthca .endif You need to run latest -stable due to some compile issues which have been fixed. --HPS From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 15 15:30:50 2014 Return-Path: Delivered-To: freebsd-hackers@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 E159BEA1; Fri, 15 Aug 2014 15:30:49 +0000 (UTC) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D7472E7B; Fri, 15 Aug 2014 15:30:49 +0000 (UTC) Received: by mail-ig0-f177.google.com with SMTP id hn18so2112840igb.10 for ; Fri, 15 Aug 2014 08:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=9ZMQ3XhT0oDwONBrsoW3Dz/+rHS1cCRiO3v0GON1iPM=; b=URtD/WQ1L8eAQ+o+wNNbDKh71o1DLE/lRqzFJcSlET8tGkJuEDS4ulstORaE6mLdMm 9DnGGTshkKzoeoKobUJaYuZNIx4Em3YUOxvNayplJsugzbKdIiZk2uxnSEH8rarpVpQY ObOm0aoJt9Xhd/HBygWa6ZUYApUMTGR7J5ulkxTWO5BWuyh0ZZh74s5kmwLKE977SdoS EEbZOnIVstRSEPOLuLRonHOb5Ief0LctDHDErtt0MzKq43KcdW2DXsCZkfufKIP8zTX5 dEsrOEtmNpA4BfuBeNxPzyCo0GlaDhHMAdpF0yWU1XuuV+7lpwD0/3JcqSURjvaTTZ+d s6JA== X-Received: by 10.50.28.75 with SMTP id z11mr67499905igg.11.1408116648464; Fri, 15 Aug 2014 08:30:48 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.131.38 with HTTP; Fri, 15 Aug 2014 08:30:28 -0700 (PDT) In-Reply-To: <53ED2CCE.2030103@freebsd.org> References: <53EA0EC2.2070601@freebsd.org> <53EA1E5A.5020707@FreeBSD.org> <53EA2D00.7010307@freebsd.org> <53EB0DA0.5000305@freebsd.org> <53EBEDC8.3080303@freebsd.org> <53ECA9CE.3070106@freebsd.org> <53ED2CCE.2030103@freebsd.org> From: Ed Maste Date: Fri, 15 Aug 2014 11:30:28 -0400 X-Google-Sender-Auth: uw5YGn3YLo8jwS1obPdwI1QVG8Q Message-ID: Subject: Re: Keymap definitions for VT / NEWCONS To: Stefan Esser Content-Type: text/plain; charset=UTF-8 Cc: "Andrey V. Elsukov" , Aleksandr Rybalko , freebsd-stable stable , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 15:30:50 -0000 On 14 August 2014 17:40, Stefan Esser wrote: > > Please look at the TAR file I prepared. I rank the symmetry > in the format of the names higher than the shorter names. > And in fact, keyboard layouts are often specific to a country, > and not to a language. The 2-letter names hide the difference > for the simple case ("fr" is really sufficient if "fr_FR" is > meant), but if you look at syscons/keymaps there are examples > of keymap files named after the language code and others named > after the country code. I've been thinking about it some more, and I think this point is precisely why I'm not a fan of using the locale name. You're correct that keyboard layouts are mainly correlated with location, not strictly language, and I think the names should reflect that. Most keymaps don't require a specific language part, but the locale scheme puts it first. We should be able to offer an appropriate default layout based on a user's locale. I don't think it follows though that the keyboard should be named the same as the locale. Using the locale name implies a relationship between the locale and keymap that just doesn't exist. You brought up Latin America (es_LA) as one exception so far, and the Canadian Multilingual keyboard has a similar issue - what would we call it? Why is the Belgian keyboard fr_BE and not nl_BE? Presumably because it's AZERTY, but naming it fr_BE seems to imply there should be a separate Dutch Belgian layout. Other than consistency for its own sake, what do we gain by requiring the ab_CD naming? For comparison, I looked at the list of keymaps in Debian/Ubuntu. They generally use the country code, with some non-ISO 3166 2-letter short forms (e.g. "cf" for Canadian French). For the two examples above they use the names la-latin1 and ca-multi. I won't suggest we follow their names in all cases since there's a lot of inconsistency (e.g. "sg" for Swiss German, but fr_CH for Swiss French). But as an overall scheme I like starting with the ISO 3166 country code, and adding more specific parts where necessary. This could give us, as examples: be Belgian ca-multi Canadian Multilingual ca-fr French Canadian ch-fr Swiss French ch-de Swiss German us US For layouts not specific to a single country (Latin America, Central Europe) we could just use longer names as today. From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 15 21:20:59 2014 Return-Path: Delivered-To: freebsd-hackers@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 A7B80E6D; Fri, 15 Aug 2014 21:20:59 +0000 (UTC) Received: from mailout09.t-online.de (mailout09.t-online.de [194.25.134.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 52AD52B62; Fri, 15 Aug 2014 21:20:59 +0000 (UTC) Received: from fwd36.aul.t-online.de (fwd36.aul.t-online.de [172.20.26.137]) by mailout09.t-online.de (Postfix) with SMTP id 316933F4517; Fri, 15 Aug 2014 23:14:02 +0200 (CEST) Received: from [192.168.119.26] (XHPJZgZ-Qhq08X6SnHVIoT7zw+H+dkPP9dkRfCyCGGnRMJHgMlC5ciT-8LYzWiPQVe@[84.154.101.219]) by fwd36.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XIOox-2FCJxQ0; Fri, 15 Aug 2014 23:13:59 +0200 Message-ID: <53EE780C.2060402@freebsd.org> Date: Fri, 15 Aug 2014 23:13:48 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Ed Maste Subject: Re: Keymap definitions for VT / NEWCONS References: <53EA0EC2.2070601@freebsd.org> <53EA1E5A.5020707@FreeBSD.org> <53EA2D00.7010307@freebsd.org> <53EB0DA0.5000305@freebsd.org> <53EBEDC8.3080303@freebsd.org> <53ECA9CE.3070106@freebsd.org> <53ED2CCE.2030103@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ID: XHPJZgZ-Qhq08X6SnHVIoT7zw+H+dkPP9dkRfCyCGGnRMJHgMlC5ciT-8LYzWiPQVe X-TOI-MSGID: cbc7b38b-8c36-493c-9193-f7e77e328f13 Cc: "Andrey V. Elsukov" , Aleksandr Rybalko , freebsd-stable stable , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 21:20:59 -0000 Am 15.08.2014 um 17:30 schrieb Ed Maste: > On 14 August 2014 17:40, Stefan Esser wrote: >> >> Please look at the TAR file I prepared. I rank the symmetry >> in the format of the names higher than the shorter names. >> And in fact, keyboard layouts are often specific to a country, >> and not to a language. The 2-letter names hide the difference >> for the simple case ("fr" is really sufficient if "fr_FR" is >> meant), but if you look at syscons/keymaps there are examples >> of keymap files named after the language code and others named >> after the country code. > > I've been thinking about it some more, and I think this point is > precisely why I'm not a fan of using the locale name. You're correct > that keyboard layouts are mainly correlated with location, not > strictly language, and I think the names should reflect that. Most > keymaps don't require a specific language part, but the locale scheme > puts it first. I see your point and I agree, that the locale names are not really pretty. But I still think that it is better to use a scheme that is well known and established (the locale IDs) for this purpose, since it will give some structure to the file names. > We should be able to offer an appropriate default layout based on a > user's locale. I don't think it follows though that the keyboard > should be named the same as the locale. Using the locale name implies > a relationship between the locale and keymap that just doesn't exist. I agree, that we could have a different naming scheme and still derive a suggested keymap from the locale name. > You brought up Latin America (es_LA) as one exception so far, and the > Canadian Multilingual keyboard has a similar issue - what would we > call it? Why is the Belgian keyboard fr_BE and not nl_BE? Presumably > because it's AZERTY, but naming it fr_BE seems to imply there should > be a separate Dutch Belgian layout. Other than consistency for its own > sake, what do we gain by requiring the ab_CD naming? Well, looking at the existing names, I think there is lack of a system for naming the keymap files. I agree, that there may be cases where a noational standard supports multiple languages with the same keyboard layout (haven't looked at the Canadian keyboard). In the case of the Belgian keyboard, we could support both names (and link them to the same file, with the option to support different preferences with regard to the Accents handling for either language by later having separate files for each one). > For comparison, I looked at the list of keymaps in Debian/Ubuntu. They > generally use the country code, with some non-ISO 3166 2-letter short > forms (e.g. "cf" for Canadian French). For the two examples above they > use the names la-latin1 and ca-multi. I won't suggest we follow their > names in all cases since there's a lot of inconsistency (e.g. "sg" for > Swiss German, but fr_CH for Swiss French). But as an overall scheme I > like starting with the ISO 3166 country code, and adding more specific > parts where necessary. Well, but apparently they also use locale names as in the example of fr_CH, at least in some cases. I really wound want to have a clear system, and I think that the locale names are the best system at hand. > This could give us, as examples: > > be Belgian > ca-multi Canadian Multilingual > ca-fr French Canadian > ch-fr Swiss French > ch-de Swiss German > us US Yes, this is also a system that could work. ISO country codes are well known from their use in domain names, and the mapping would be to use the country name allone for all cases where there is only one language in a country and possibly also for the case where both country and language are the same characters, e.g.: ch-fr Swiss French (fr_CH) ch-de Swiss German (de_CH) de German (de_DE) it Italian (it_IT) gk Greek (el_GK) Would this naming scheme make sense and it is easy to follow when new definitions are added? > For layouts not specific to a single country (Latin America, Central > Europe) we could just use longer names as today. Hmm, I'll think about this and will hold back the commits I planned for another day or two. I'm currently working on the INDEX.keymaps file, which uses a number of different encodings (as typically used in for the supported languages, ranging from ISO8859-x over CPxxx to KOI-R/U and PT154). I've written a script that should translate the descriptions in the INDEX.keymaps file to UTF, based on the country code in the second column. But I have to verify that the conversion result makes sense, when viewed on a Unicode terminal with support for all the languages (e.g. by pasting some of the result strings into Google translate for the respective language ...). And I found, that the kbdmap command has not been correctly translated from Perl to C. The selection logic in find_token() does not implement the regular expression matching that used to be in the Perl version. This may not cause any problems, since in fact only the comparison with "lang_abk" is relevant (other cases are not used in INDEX.keymaps), but I'll have to verify this assumption. And it would be good to place the cursor on a list item that is likely to match the locale selected, instead of placing the cursor into the first line of the list. Regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 16 06:48:20 2014 Return-Path: Delivered-To: hackers@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 B24A5CDB for ; Sat, 16 Aug 2014 06:48:20 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6709C24FE for ; Sat, 16 Aug 2014 06:48:19 +0000 (UTC) Received: from latte.bs.cs.huji.ac.il ([132.65.179.20] helo=mbpro2.bs.cs.huji.ac.il) by kabab.cs.huji.ac.il with esmtp id 1XIXmh-000KbE-4K; Sat, 16 Aug 2014 09:48:15 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Mellanox 10gb driver? From: Daniel Braniss In-Reply-To: <53EDF13D.5050206@selasky.org> Date: Sat, 16 Aug 2014 09:53:51 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0E7861FF-AB45-421F-8BA0-0EAD02B85AF0@cs.huji.ac.il> References: <5FA0CF8C-2C93-4639-AA6C-40D3C278FE0F@cs.huji.ac.il> <53EDF13D.5050206@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1878.6) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 06:48:20 -0000 On Aug 15, 2014, at 2:38 PM, Hans Petter Selasky = wrote: > On 08/15/14 12:55, Daniel Braniss wrote: >> hi all, >> any idea if there is/will be a driver for: >>=20 >> none3@pci0:5:0:0: class=3D0x020000 card=3D0x005515b3 = chip=3D0x100315b3 rev=3D0x00 hdr=3D0x00 >> vendor =3D 'Mellanox Technologies' >> device =3D 'MT27500 Family [ConnectX-3]' >> class =3D network >> subclass =3D ethernet >>=20 >=20 > Hi, >=20 > If you build the kernel using MK_OFED=3Dyes, your hardware is = supported by the following modules: >=20 > .if ${MK_OFED} !=3D "no" || defined(ALL_MODULES) > _mlx4=3D mlx4 > _mlx4ib=3D mlx4ib > _mlxen=3D mlxen > _mthca=3D mthca > .endif >=20 > You need to run latest -stable due to some compile issues which have = been fixed. >=20 > =97HPS hi, I added WITH_MK_OFED=3Dyes to the latest stable but no joy, it=92s sill = reported as none. is there some magic that i=92m missing? thanks, danny From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 16 06:57:23 2014 Return-Path: Delivered-To: hackers@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 BBFD9F79 for ; Sat, 16 Aug 2014 06:57:23 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6F40225D5 for ; Sat, 16 Aug 2014 06:57:23 +0000 (UTC) Received: from latte.bs.cs.huji.ac.il ([132.65.179.20] helo=mbpro2.bs.cs.huji.ac.il) by kabab.cs.huji.ac.il with esmtp id 1XIXvU-000Kg7-Qi; Sat, 16 Aug 2014 09:57:20 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Mellanox 10gb driver? From: Daniel Braniss In-Reply-To: <0E7861FF-AB45-421F-8BA0-0EAD02B85AF0@cs.huji.ac.il> Date: Sat, 16 Aug 2014 10:02:57 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3E7F3970-0541-402F-B855-EDA299B5BBC1@cs.huji.ac.il> References: <5FA0CF8C-2C93-4639-AA6C-40D3C278FE0F@cs.huji.ac.il> <53EDF13D.5050206@selasky.org> <0E7861FF-AB45-421F-8BA0-0EAD02B85AF0@cs.huji.ac.il> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1878.6) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 06:57:23 -0000 On Aug 16, 2014, at 9:53 AM, Daniel Braniss wrote: >=20 > On Aug 15, 2014, at 2:38 PM, Hans Petter Selasky = wrote: >=20 >> On 08/15/14 12:55, Daniel Braniss wrote: >>> hi all, >>> any idea if there is/will be a driver for: >>>=20 >>> none3@pci0:5:0:0: class=3D0x020000 card=3D0x005515b3 = chip=3D0x100315b3 rev=3D0x00 hdr=3D0x00 >>> vendor =3D 'Mellanox Technologies' >>> device =3D 'MT27500 Family [ConnectX-3]' >>> class =3D network >>> subclass =3D ethernet >>>=20 >>=20 >> Hi, >>=20 >> If you build the kernel using MK_OFED=3Dyes, your hardware is = supported by the following modules: >>=20 >> .if ${MK_OFED} !=3D "no" || defined(ALL_MODULES) >> _mlx4=3D mlx4 >> _mlx4ib=3D mlx4ib >> _mlxen=3D mlxen >> _mthca=3D mthca >> .endif >>=20 >> You need to run latest -stable due to some compile issues which have = been fixed. >>=20 >> =97HPS >=20 > hi, >=20 > I added WITH_MK_OFED=3Dyes to the latest stable but no joy, it=92s = sill reported as none. > is there some magic that i=92m missing? > thanks, > danny some more info, if it helps: pcib5: at device 6.0 on pci0 pcib0: allocated type 3 (0xdf200000-0xdf3fffff) for rid 20 of pcib5 pcib0: allocated type 3 (0xd5000000-0xd57fffff) for rid 24 of pcib5 pcib5: domain 0 pcib5: secondary bus 5 pcib5: subordinate bus 5 pcib5: memory decode 0xdf200000-0xdf3fffff pcib5: prefetched decode 0xd5000000-0xd57fffff pcib5: special decode ISA pci5: on pcib5 pci5: domain=3D0, physical bus=3D5 found-> vendor=3D0x15b3, dev=3D0x1003, revid=3D0x00 domain=3D0, bus=3D5, slot=3D0, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Da, irq=3D15 powerspec 3 supports D0 D3 current D0 MSI-X supports 128 messages in map 0x10 map[10]: type Memory, range 64, base 0xdf300000, size 20, = enabled pcib5: allocated memory range (0xdf300000-0xdf3fffff) for rid 10 of = pci0:5:0:0 map[18]: type Prefetchable Memory, range 64, base 0xd5000000, = size 23, enabled pcib5: allocated prefetch range (0xd5000000-0xd57fffff) for rid 18 of = pci0:5:0:0 pcib5: matched entry for 5.0.INTA pcib5: slot 0 INTA hardwired to IRQ 35 pci5: at device 0.0 (no driver attached) From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 16 07:03:44 2014 Return-Path: Delivered-To: hackers@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 98615243 for ; Sat, 16 Aug 2014 07:03:44 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5A3892689 for ; Sat, 16 Aug 2014 07:03:44 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 0E8B21FE027; Sat, 16 Aug 2014 09:03:41 +0200 (CEST) Message-ID: <53EF0260.9030806@selasky.org> Date: Sat, 16 Aug 2014 09:04:00 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Daniel Braniss Subject: Re: Mellanox 10gb driver? References: <5FA0CF8C-2C93-4639-AA6C-40D3C278FE0F@cs.huji.ac.il> <53EDF13D.5050206@selasky.org> <0E7861FF-AB45-421F-8BA0-0EAD02B85AF0@cs.huji.ac.il> <3E7F3970-0541-402F-B855-EDA299B5BBC1@cs.huji.ac.il> In-Reply-To: <3E7F3970-0541-402F-B855-EDA299B5BBC1@cs.huji.ac.il> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 07:03:44 -0000 On 08/16/14 09:02, Daniel Braniss wrote: > > On Aug 16, 2014, at 9:53 AM, Daniel Braniss wrote: > >> >> On Aug 15, 2014, at 2:38 PM, Hans Petter Selasky wrote: >> >>> On 08/15/14 12:55, Daniel Braniss wrote: >>>> hi all, >>>> any idea if there is/will be a driver for: >>>> >>>> none3@pci0:5:0:0: class=0x020000 card=0x005515b3 chip=0x100315b3 rev=0x00 hdr=0x00 >>>> vendor = 'Mellanox Technologies' >>>> device = 'MT27500 Family [ConnectX-3]' >>>> class = network >>>> subclass = ethernet >>>> >>> >>> Hi, >>> >>> If you build the kernel using MK_OFED=yes, your hardware is supported by the following modules: >>> >>> .if ${MK_OFED} != "no" || defined(ALL_MODULES) >>> _mlx4= mlx4 >>> _mlx4ib= mlx4ib >>> _mlxen= mlxen >>> _mthca= mthca >>> .endif >>> >>> You need to run latest -stable due to some compile issues which have been fixed. >>> >>> —HPS >> >> hi, >> >> I added WITH_MK_OFED=yes to the latest stable but no joy, it’s sill reported as none. >> is there some magic that i’m missing? >> thanks, >> danny > > some more info, if it helps: > > pcib5: at device 6.0 on pci0 > pcib0: allocated type 3 (0xdf200000-0xdf3fffff) for rid 20 of pcib5 > pcib0: allocated type 3 (0xd5000000-0xd57fffff) for rid 24 of pcib5 > pcib5: domain 0 > pcib5: secondary bus 5 > pcib5: subordinate bus 5 > pcib5: memory decode 0xdf200000-0xdf3fffff > pcib5: prefetched decode 0xd5000000-0xd57fffff > pcib5: special decode ISA > pci5: on pcib5 > pci5: domain=0, physical bus=5 > found-> vendor=0x15b3, dev=0x1003, revid=0x00 > domain=0, bus=5, slot=0, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=15 > powerspec 3 supports D0 D3 current D0 > MSI-X supports 128 messages in map 0x10 > map[10]: type Memory, range 64, base 0xdf300000, size 20, enabled > pcib5: allocated memory range (0xdf300000-0xdf3fffff) for rid 10 of pci0:5:0:0 > map[18]: type Prefetchable Memory, range 64, base 0xd5000000, size 23, enabled > pcib5: allocated prefetch range (0xd5000000-0xd57fffff) for rid 18 of pci0:5:0:0 > pcib5: matched entry for 5.0.INTA > pcib5: slot 0 INTA hardwired to IRQ 35 > pci5: at device 0.0 (no driver attached) Hi, Did you "kldload mlxen" ? --HPS From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 16 07:26:27 2014 Return-Path: Delivered-To: hackers@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 E09158C4 for ; Sat, 16 Aug 2014 07:26:27 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 90503285F for ; Sat, 16 Aug 2014 07:26:27 +0000 (UTC) Received: from latte.bs.cs.huji.ac.il ([132.65.179.20] helo=mbpro2.bs.cs.huji.ac.il) by kabab.cs.huji.ac.il with esmtp id 1XIYNd-000KtP-5E; Sat, 16 Aug 2014 10:26:25 +0300 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Mellanox 10gb driver? From: Daniel Braniss In-Reply-To: <53EF0260.9030806@selasky.org> Date: Sat, 16 Aug 2014 10:32:02 +0300 Message-Id: References: <5FA0CF8C-2C93-4639-AA6C-40D3C278FE0F@cs.huji.ac.il> <53EDF13D.5050206@selasky.org> <0E7861FF-AB45-421F-8BA0-0EAD02B85AF0@cs.huji.ac.il> <3E7F3970-0541-402F-B855-EDA299B5BBC1@cs.huji.ac.il> <53EF0260.9030806@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 07:26:28 -0000 On Aug 16, 2014, at 10:04 AM, Hans Petter Selasky = wrote: > On 08/16/14 09:02, Daniel Braniss wrote: >>=20 >> On Aug 16, 2014, at 9:53 AM, Daniel Braniss = wrote: >>=20 >>>=20 >>> On Aug 15, 2014, at 2:38 PM, Hans Petter Selasky = wrote: >>>=20 >>>> On 08/15/14 12:55, Daniel Braniss wrote: >>>>> hi all, >>>>> any idea if there is/will be a driver for: >>>>>=20 >>>>> none3@pci0:5:0:0: class=3D0x020000 card=3D0x005515b3 = chip=3D0x100315b3 rev=3D0x00 hdr=3D0x00 >>>>> vendor =3D 'Mellanox Technologies' >>>>> device =3D 'MT27500 Family [ConnectX-3]' >>>>> class =3D network >>>>> subclass =3D ethernet >>>>>=20 >>>>=20 >>>> Hi, >>>>=20 >>>> If you build the kernel using MK_OFED=3Dyes, your hardware is = supported by the following modules: >>>>=20 >>>> .if ${MK_OFED} !=3D "no" || defined(ALL_MODULES) >>>> _mlx4=3D mlx4 >>>> _mlx4ib=3D mlx4ib >>>> _mlxen=3D mlxen >>>> _mthca=3D mthca >>>> .endif >>>>=20 >>>> You need to run latest -stable due to some compile issues which = have been fixed. >>>>=20 >>>> =97HPS >>>=20 >>> hi, >>>=20 >>> I added WITH_MK_OFED=3Dyes to the latest stable but no joy, it=92s = sill reported as none. >>> is there some magic that i=92m missing? >>> thanks, >>> danny >>=20 >> some more info, if it helps: >>=20 >> pcib5: at device 6.0 on pci0 >> pcib0: allocated type 3 (0xdf200000-0xdf3fffff) for rid 20 of pcib5 >> pcib0: allocated type 3 (0xd5000000-0xd57fffff) for rid 24 of pcib5 >> pcib5: domain 0 >> pcib5: secondary bus 5 >> pcib5: subordinate bus 5 >> pcib5: memory decode 0xdf200000-0xdf3fffff >> pcib5: prefetched decode 0xd5000000-0xd57fffff >> pcib5: special decode ISA >> pci5: on pcib5 >> pci5: domain=3D0, physical bus=3D5 >> found-> vendor=3D0x15b3, dev=3D0x1003, revid=3D0x00 >> domain=3D0, bus=3D5, slot=3D0, func=3D0 >> class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 >> cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D16 (dwords) >> lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) >> intpin=3Da, irq=3D15 >> powerspec 3 supports D0 D3 current D0 >> MSI-X supports 128 messages in map 0x10 >> map[10]: type Memory, range 64, base 0xdf300000, size 20, = enabled >> pcib5: allocated memory range (0xdf300000-0xdf3fffff) for rid 10 of = pci0:5:0:0 >> map[18]: type Prefetchable Memory, range 64, base 0xd5000000, = size 23, enabled >> pcib5: allocated prefetch range (0xd5000000-0xd57fffff) for rid 18 of = pci0:5:0:0 >> pcib5: matched entry for 5.0.INTA >> pcib5: slot 0 INTA hardwired to IRQ 35 >> pci5: at device 0.0 (no driver attached) >=20 > Hi, >=20 > Did you "kldload mlxen=94 ? I can=92t find anything that looks like mlxen danny From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 16 07:27:23 2014 Return-Path: Delivered-To: hackers@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 CCE0199E for ; Sat, 16 Aug 2014 07:27:23 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7F9492866 for ; Sat, 16 Aug 2014 07:27:23 +0000 (UTC) Received: from latte.bs.cs.huji.ac.il ([132.65.179.20] helo=mbpro2.bs.cs.huji.ac.il) by kabab.cs.huji.ac.il with esmtp id 1XIYOX-000KtP-Ah; Sat, 16 Aug 2014 10:27:21 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Mellanox 10gb driver? From: Daniel Braniss In-Reply-To: <53EF0260.9030806@selasky.org> Date: Sat, 16 Aug 2014 10:32:58 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7D49FD54-AA37-4F04-952E-5A07754762E5@cs.huji.ac.il> References: <5FA0CF8C-2C93-4639-AA6C-40D3C278FE0F@cs.huji.ac.il> <53EDF13D.5050206@selasky.org> <0E7861FF-AB45-421F-8BA0-0EAD02B85AF0@cs.huji.ac.il> <3E7F3970-0541-402F-B855-EDA299B5BBC1@cs.huji.ac.il> <53EF0260.9030806@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1878.6) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 07:27:24 -0000 On Aug 16, 2014, at 10:04 AM, Hans Petter Selasky = wrote: > On 08/16/14 09:02, Daniel Braniss wrote: >>=20 >> On Aug 16, 2014, at 9:53 AM, Daniel Braniss = wrote: >>=20 >>>=20 >>> On Aug 15, 2014, at 2:38 PM, Hans Petter Selasky = wrote: >>>=20 >>>> On 08/15/14 12:55, Daniel Braniss wrote: >>>>> hi all, >>>>> any idea if there is/will be a driver for: >>>>>=20 >>>>> none3@pci0:5:0:0: class=3D0x020000 card=3D0x005515b3 = chip=3D0x100315b3 rev=3D0x00 hdr=3D0x00 >>>>> vendor =3D 'Mellanox Technologies' >>>>> device =3D 'MT27500 Family [ConnectX-3]' >>>>> class =3D network >>>>> subclass =3D ethernet >>>>>=20 >>>>=20 >>>> Hi, >>>>=20 >>>> If you build the kernel using MK_OFED=3Dyes, your hardware is = supported by the following modules: >>>>=20 >>>> .if ${MK_OFED} !=3D "no" || defined(ALL_MODULES) >>>> _mlx4=3D mlx4 >>>> _mlx4ib=3D mlx4ib >>>> _mlxen=3D mlxen >>>> _mthca=3D mthca >>>> .endif >>>>=20 >>>> You need to run latest -stable due to some compile issues which = have been fixed. >>>>=20 >>>> =97HPS >>>=20 >>> hi, >>>=20 >>> I added WITH_MK_OFED=3Dyes to the latest stable but no joy, it=92s = sill reported as none. >>> is there some magic that i=92m missing? >>> thanks, >>> danny >>=20 >> some more info, if it helps: >>=20 >> pcib5: at device 6.0 on pci0 >> pcib0: allocated type 3 (0xdf200000-0xdf3fffff) for rid 20 of pcib5 >> pcib0: allocated type 3 (0xd5000000-0xd57fffff) for rid 24 of pcib5 >> pcib5: domain 0 >> pcib5: secondary bus 5 >> pcib5: subordinate bus 5 >> pcib5: memory decode 0xdf200000-0xdf3fffff >> pcib5: prefetched decode 0xd5000000-0xd57fffff >> pcib5: special decode ISA >> pci5: on pcib5 >> pci5: domain=3D0, physical bus=3D5 >> found-> vendor=3D0x15b3, dev=3D0x1003, revid=3D0x00 >> domain=3D0, bus=3D5, slot=3D0, func=3D0 >> class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 >> cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D16 (dwords) >> lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) >> intpin=3Da, irq=3D15 >> powerspec 3 supports D0 D3 current D0 >> MSI-X supports 128 messages in map 0x10 >> map[10]: type Memory, range 64, base 0xdf300000, size 20, = enabled >> pcib5: allocated memory range (0xdf300000-0xdf3fffff) for rid 10 of = pci0:5:0:0 >> map[18]: type Prefetchable Memory, range 64, base 0xd5000000, = size 23, enabled >> pcib5: allocated prefetch range (0xd5000000-0xd57fffff) for rid 18 of = pci0:5:0:0 >> pcib5: matched entry for 5.0.INTA >> pcib5: slot 0 INTA hardwired to IRQ 35 >> pci5: at device 0.0 (no driver attached) >=20 > Hi, >=20 > Did you "kldload mlxen" ? >=20 > --HPS >=20 im running 9.3 stable, is this for 10? From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 16 07:35:39 2014 Return-Path: Delivered-To: hackers@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 D3451ADF for ; Sat, 16 Aug 2014 07:35:39 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 642412914 for ; Sat, 16 Aug 2014 07:35:39 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 937B31FE027; Sat, 16 Aug 2014 09:35:37 +0200 (CEST) Message-ID: <53EF09DC.60601@selasky.org> Date: Sat, 16 Aug 2014 09:35:56 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Daniel Braniss Subject: Re: Mellanox 10gb driver? References: <5FA0CF8C-2C93-4639-AA6C-40D3C278FE0F@cs.huji.ac.il> <53EDF13D.5050206@selasky.org> <0E7861FF-AB45-421F-8BA0-0EAD02B85AF0@cs.huji.ac.il> <3E7F3970-0541-402F-B855-EDA299B5BBC1@cs.huji.ac.il> <53EF0260.9030806@selasky.org> <7D49FD54-AA37-4F04-952E-5A07754762E5@cs.huji.ac.il> In-Reply-To: <7D49FD54-AA37-4F04-952E-5A07754762E5@cs.huji.ac.il> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 07:35:40 -0000 On 08/16/14 09:32, Daniel Braniss wrote: > > On Aug 16, 2014, at 10:04 AM, Hans Petter Selasky wrote: > >> On 08/16/14 09:02, Daniel Braniss wrote: >>> >>> On Aug 16, 2014, at 9:53 AM, Daniel Braniss wrote: >>> >>>> >>>> On Aug 15, 2014, at 2:38 PM, Hans Petter Selasky wrote: >>>> >>>>> On 08/15/14 12:55, Daniel Braniss wrote: >>>>>> hi all, >>>>>> any idea if there is/will be a driver for: >>>>>> >>>>>> none3@pci0:5:0:0: class=0x020000 card=0x005515b3 chip=0x100315b3 rev=0x00 hdr=0x00 >>>>>> vendor = 'Mellanox Technologies' >>>>>> device = 'MT27500 Family [ConnectX-3]' >>>>>> class = network >>>>>> subclass = ethernet >>>>>> >>>>> >>>>> Hi, >>>>> >>>>> If you build the kernel using MK_OFED=yes, your hardware is supported by the following modules: >>>>> >>>>> .if ${MK_OFED} != "no" || defined(ALL_MODULES) >>>>> _mlx4= mlx4 >>>>> _mlx4ib= mlx4ib >>>>> _mlxen= mlxen >>>>> _mthca= mthca >>>>> .endif >>>>> >>>>> You need to run latest -stable due to some compile issues which have been fixed. >>>>> >>>>> —HPS >>>> >>>> hi, >>>> >>>> I added WITH_MK_OFED=yes to the latest stable but no joy, it’s sill reported as none. >>>> is there some magic that i’m missing? >>>> thanks, >>>> danny >>> >>> some more info, if it helps: >>> >>> pcib5: at device 6.0 on pci0 >>> pcib0: allocated type 3 (0xdf200000-0xdf3fffff) for rid 20 of pcib5 >>> pcib0: allocated type 3 (0xd5000000-0xd57fffff) for rid 24 of pcib5 >>> pcib5: domain 0 >>> pcib5: secondary bus 5 >>> pcib5: subordinate bus 5 >>> pcib5: memory decode 0xdf200000-0xdf3fffff >>> pcib5: prefetched decode 0xd5000000-0xd57fffff >>> pcib5: special decode ISA >>> pci5: on pcib5 >>> pci5: domain=0, physical bus=5 >>> found-> vendor=0x15b3, dev=0x1003, revid=0x00 >>> domain=0, bus=5, slot=0, func=0 >>> class=02-00-00, hdrtype=0x00, mfdev=0 >>> cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) >>> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>> intpin=a, irq=15 >>> powerspec 3 supports D0 D3 current D0 >>> MSI-X supports 128 messages in map 0x10 >>> map[10]: type Memory, range 64, base 0xdf300000, size 20, enabled >>> pcib5: allocated memory range (0xdf300000-0xdf3fffff) for rid 10 of pci0:5:0:0 >>> map[18]: type Prefetchable Memory, range 64, base 0xd5000000, size 23, enabled >>> pcib5: allocated prefetch range (0xd5000000-0xd57fffff) for rid 18 of pci0:5:0:0 >>> pcib5: matched entry for 5.0.INTA >>> pcib5: slot 0 INTA hardwired to IRQ 35 >>> pci5: at device 0.0 (no driver attached) >> >> Hi, >> >> Did you "kldload mlxen" ? >> >> --HPS >> > > im running 9.3 stable, is this for 10? No, look in: sys/modules/mlxen --HPS From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 16 07:44:39 2014 Return-Path: Delivered-To: hackers@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 AA82BCBC for ; Sat, 16 Aug 2014 07:44:39 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2C4E929EC for ; Sat, 16 Aug 2014 07:44:38 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.7/8.14.7) with ESMTP id s7G7MHML007450 for ; Sat, 16 Aug 2014 09:22:17 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.7/8.14.7/Submit) with ESMTP id s7G7MFwj007447 for ; Sat, 16 Aug 2014 09:22:15 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sat, 16 Aug 2014 09:22:15 +0200 (CEST) From: Wojciech Puchar To: hackers@freebsd.org Subject: routerboard/other hardware Message-ID: 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 passed SPF test, not delayed by milter-greylist-4.4.3 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sat, 16 Aug 2014 09:22:17 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 07:44:39 -0000 what hardware with reasonable price is tested with FreeBSD so it runs reliably, have 2 or more ethernet ports, small form factor and possibility of adding few gigabytes of storage in form of SD card/compact flash? There are many kinds of routerboard with MIPS or PPC CPU for example, some runs freebsd. anyone have practice with this or other hardware? From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 16 08:30:43 2014 Return-Path: Delivered-To: hackers@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 49CC6370 for ; Sat, 16 Aug 2014 08:30:43 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EC6182E7B for ; Sat, 16 Aug 2014 08:30:42 +0000 (UTC) Received: from latte.bs.cs.huji.ac.il ([132.65.179.20] helo=mbpro2.bs.cs.huji.ac.il) by kabab.cs.huji.ac.il with esmtp id 1XIZNm-000LNn-So; Sat, 16 Aug 2014 11:30:39 +0300 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Mellanox 10gb driver? From: Daniel Braniss In-Reply-To: <53EF09DC.60601@selasky.org> Date: Sat, 16 Aug 2014 11:36:15 +0300 Message-Id: <8FD6967F-E130-4FBC-B93B-D5D508279E11@cs.huji.ac.il> References: <5FA0CF8C-2C93-4639-AA6C-40D3C278FE0F@cs.huji.ac.il> <53EDF13D.5050206@selasky.org> <0E7861FF-AB45-421F-8BA0-0EAD02B85AF0@cs.huji.ac.il> <3E7F3970-0541-402F-B855-EDA299B5BBC1@cs.huji.ac.il> <53EF0260.9030806@selasky.org> <7D49FD54-AA37-4F04-952E-5A07754762E5@cs.huji.ac.il> <53EF09DC.60601@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 08:30:43 -0000 On Aug 16, 2014, at 10:35 AM, Hans Petter Selasky = wrote: > On 08/16/14 09:32, Daniel Braniss wrote: >>=20 >> On Aug 16, 2014, at 10:04 AM, Hans Petter Selasky = wrote: >>=20 >>> On 08/16/14 09:02, Daniel Braniss wrote: >>>>=20 >>>> On Aug 16, 2014, at 9:53 AM, Daniel Braniss = wrote: >>>>=20 >>>>>=20 >>>>> On Aug 15, 2014, at 2:38 PM, Hans Petter Selasky = wrote: >>>>>=20 >>>>>> On 08/15/14 12:55, Daniel Braniss wrote: >>>>>>> hi all, >>>>>>> any idea if there is/will be a driver for: >>>>>>>=20 >>>>>>> none3@pci0:5:0:0: class=3D0x020000 card=3D0x005515b3 = chip=3D0x100315b3 rev=3D0x00 hdr=3D0x00 >>>>>>> vendor =3D 'Mellanox Technologies' >>>>>>> device =3D 'MT27500 Family [ConnectX-3]' >>>>>>> class =3D network >>>>>>> subclass =3D ethernet >>>>>>>=20 >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> If you build the kernel using MK_OFED=3Dyes, your hardware is = supported by the following modules: >>>>>>=20 >>>>>> .if ${MK_OFED} !=3D "no" || defined(ALL_MODULES) >>>>>> _mlx4=3D mlx4 >>>>>> _mlx4ib=3D mlx4ib >>>>>> _mlxen=3D mlxen >>>>>> _mthca=3D mthca >>>>>> .endif >>>>>>=20 >>>>>> You need to run latest -stable due to some compile issues which = have been fixed. >>>>>>=20 >>>>>> =97HPS >>>>>=20 >>>>> hi, >>>>>=20 >>>>> I added WITH_MK_OFED=3Dyes to the latest stable but no joy, it=92s = sill reported as none. >>>>> is there some magic that i=92m missing? >>>>> thanks, >>>>> danny >>>>=20 >>>> some more info, if it helps: >>>>=20 >>>> pcib5: at device 6.0 on pci0 >>>> pcib0: allocated type 3 (0xdf200000-0xdf3fffff) for rid 20 of pcib5 >>>> pcib0: allocated type 3 (0xd5000000-0xd57fffff) for rid 24 of pcib5 >>>> pcib5: domain 0 >>>> pcib5: secondary bus 5 >>>> pcib5: subordinate bus 5 >>>> pcib5: memory decode 0xdf200000-0xdf3fffff >>>> pcib5: prefetched decode 0xd5000000-0xd57fffff >>>> pcib5: special decode ISA >>>> pci5: on pcib5 >>>> pci5: domain=3D0, physical bus=3D5 >>>> found-> vendor=3D0x15b3, dev=3D0x1003, revid=3D0x00 >>>> domain=3D0, bus=3D5, slot=3D0, func=3D0 >>>> class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 >>>> cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D16 (dwords) >>>> lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) >>>> intpin=3Da, irq=3D15 >>>> powerspec 3 supports D0 D3 current D0 >>>> MSI-X supports 128 messages in map 0x10 >>>> map[10]: type Memory, range 64, base 0xdf300000, size 20, = enabled >>>> pcib5: allocated memory range (0xdf300000-0xdf3fffff) for rid 10 of = pci0:5:0:0 >>>> map[18]: type Prefetchable Memory, range 64, base = 0xd5000000, size 23, enabled >>>> pcib5: allocated prefetch range (0xd5000000-0xd57fffff) for rid 18 = of pci0:5:0:0 >>>> pcib5: matched entry for 5.0.INTA >>>> pcib5: slot 0 INTA hardwired to IRQ 35 >>>> pci5: at device 0.0 (no driver attached) >>>=20 >>> Hi, >>>=20 >>> Did you "kldload mlxen" ? >>>=20 >>> --HPS >>>=20 >>=20 >> im running 9.3 stable, is this for 10? >=20 > No, look in: >=20 > sys/modules/mlxen >=20 I solved the puzzle! added options OFED device mlxen device mlx4ib device mthca to my kernel config and that did it - not sure the last 2 are needed. now to connect and check, but that will have to wait till tomorrow. thanks, danny > --HPS From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 16 18:25:18 2014 Return-Path: Delivered-To: freebsd-hackers@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 85FEC28E for ; Sat, 16 Aug 2014 18:25:18 +0000 (UTC) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 53DFF284F for ; Sat, 16 Aug 2014 18:25:18 +0000 (UTC) Received: by mail-ig0-f177.google.com with SMTP id hn18so4475900igb.16 for ; Sat, 16 Aug 2014 11:25:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Wl9WAMfb282By6nZPfzGc84Ng6s/AEyan3tO3Y2dUk8=; b=eX03udALy+uD09aRgDhDEv+HVPpsK98q2IlMCWiNFuADImAqgKPi+W9z4z4NwSKHLR +10QWVT16Ol0lrhXMBKbMXW6j8NLBh3+IzqDirplPkW42Io+MS+2v9xNmAYAFKj3UKtU eideHU6sSItrmTvYIuGs3YlLgDdaMH3BQEuWpV6thMHDomJlMYij8YjYDz1vW9yh+hSw lTwKZ6nLf0zgYz7TfHAr0iB7CWjr94tSnsVT3kbFcMBLYb8/Tff26uKrB2TiBzrlzHoS K+kK1DHSSTuJtYcBciYqaMW+8IDIYSL0EGKL9zbe5xvheoujPiXzBEuTWBlNeUHovoUG E0NA== X-Received: by 10.43.129.74 with SMTP id hh10mr26598153icc.48.1408213517776; Sat, 16 Aug 2014 11:25:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.39.145 with HTTP; Sat, 16 Aug 2014 11:24:47 -0700 (PDT) In-Reply-To: <53ADEE4C.2080804@blach.pl> References: <53A95016.3090901@blach.pl> <20140624205420.GZ93733@kib.kiev.ua> <53ADEE4C.2080804@blach.pl> From: arrowdodger <6yearold@gmail.com> Date: Sat, 16 Aug 2014 22:24:47 +0400 Message-ID: Subject: Re: Crash probably in libthr To: Grzegorz Blach Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 18:25:18 -0000 On Sat, Jun 28, 2014 at 2:21 AM, Grzegorz Blach wrote: > On 06/24/14 22:54, Konstantin Belousov wrote: > > On Tue, Jun 24, 2014 at 12:16:54PM +0200, Grzegorz Blach wrote: > >> On https://phab.enlightenment.org/T1330 I reported a crash in > >> Enlightenment. After analyzing backtraces from valgrind and gdb we think > >> this might be a bug in libthr. > > And how did you come to this conclusion ? > > > >> Backtrace from valgrind: > >> > https://phab.enlightenment.org/file/data/wlcvu7kmb5blxmgtnk2p/PHID-FILE-dimurhxlz4tvytoxnfup/valgrind2.log > >> Backtrace from gdb: > >> > https://phab.enlightenment.org/file/data/zvbelqzjt4h3ppates6a/PHID-FILE-dsnaw3golsozpzlb7uqe/gdb2.log > >> > >> Have any one known what > >> /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 does? > > The gdb backtrace you posted reports that the SIGSEGV occured in the > > thread with lwp id 100363. According to the same log, innermost > > frame for the thread is in _op_blend_p_dp_mmx(), which is line 11 > > in the file src/lib/evas/common/./evas_op_blend/op_blend_pixel_i386.c. > > > > umtx_op is the syscall which typically parks thread in the kernel while > > waiting for unblock. It appeared in the log because your process is > > multithreaded and that other thread slept waiting for an event. > > Backtrace from valgrind is completely different than backtrace from gdb. > How do you think that backtrace is more appropriate? > > Also I posted your reply on https://phab.enlightenment.org/T1330 this is > an answer: > > "As I stated before the gdb trace is at least messed up, especially as > the caller to the _op_blend_p_dp_mmx report a lot of impossible > information (all the parameter that int are marked variable: Cannot access memory at address 0x0> or ). I > fail to see how we could believe that nothing is messed up at that point > and that gdb report the problem at the right time." > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > So, what's the status of this? I could lend a hand with debugging/testing this, although my gdb skills are far from expert. From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 16 19:44:05 2014 Return-Path: Delivered-To: freebsd-hackers@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 1F2C97E0 for ; Sat, 16 Aug 2014 19:44:05 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 05D1920E3 for ; Sat, 16 Aug 2014 19:44:04 +0000 (UTC) Received: from zeppelin.tachypleus.net ([128.54.110.145]) (authenticated bits=0) by d.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s7GJi2MH018692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 16 Aug 2014 12:44:03 -0700 Message-ID: <53EFB481.40204@freebsd.org> Date: Sat, 16 Aug 2014 12:44:01 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, wojtek@wojtek.tensor.gdynia.pl Subject: Re: routerboard/other hardware References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVaQrVp5cBtTxoWj4eBwa8561N1qj4ELKwMd9N/RGne2poKH/FmKr0YTO7blk/vxIF4+L5p404wpuIQFvNjltGWHFFelAmYh5HM= X-Sonic-ID: C;iHRarH0l5BGZEM2354E5FQ== M;dJWTrH0l5BGZEM2354E5FQ== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 19:44:05 -0000 I have a PPC RB800 that runs FreeBSD quite well. The CF slot is not currently supported, but I'm planning to fix that within the next week or two. The MIPS Ubiquiti RouterStation Pro is also a very nice board but I think EOL. -Nathan On 08/16/14 00:22, Wojciech Puchar wrote: > what hardware with reasonable price is tested with FreeBSD so it runs > reliably, have 2 or more ethernet ports, small form factor and > possibility of adding few gigabytes of storage in form of SD > card/compact flash? > > There are many kinds of routerboard with MIPS or PPC CPU for example, > some runs freebsd. > > anyone have practice with this or other hardware? > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 16 22:25:19 2014 Return-Path: Delivered-To: hackers@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 F3776738; Sat, 16 Aug 2014 22:25:18 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B87782409; Sat, 16 Aug 2014 22:25:18 +0000 (UTC) Received: from v6.mpls.in ([2a02:978:2::5] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XIiRv-0008r2-WA; Sat, 16 Aug 2014 22:11:32 +0400 Message-ID: <53EFDA3C.3010008@FreeBSD.org> Date: Sun, 17 Aug 2014 02:25:00 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: hackers@freebsd.org, "net@freebsd.org" Subject: SIOCGI2C ioctl for NIC drivers X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: George Neville-Neil , Navdeep Parhar X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 22:25:19 -0000 Hello list. It seems that networking is evolving quite rapidly, so 10g nics are quite common: we have Intel, Chelsio, Mellanox, Emulex, Solarflare and Myricom drivers in our tree (maybe some others). 40G are also here: (Chelsio, Mellanox, Intel). Things like 25G NICs are also getting more interest. Most of them uses SFP+/QSPF+ (either for short range optics or passive/active twinax cabling) and we can improve diagnostics here by providing standard way to request i2c data (like vendor info and signal levels) from transceivers. Chelsio and Intel drivers already provide methods to retrieve those info, but in a different way. I'd like to add SIOCGI2C as standard ioctl for that, picking value like 61, if there are no objections.