From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 17 06:39:24 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 604D6A30 for ; Sun, 17 Aug 2014 06:39:24 +0000 (UTC) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (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 EB81E2EC0 for ; Sun, 17 Aug 2014 06:39:23 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id q58so3767657wes.4 for ; Sat, 16 Aug 2014 23:39:22 -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=YwzeSE30UVFr8Igh0O1pXZu1AKj1PBD0MowURf+88MU=; b=cDCGNx7Mv2ZY7I+9WG+9iXpsI+VDGQXGueAGhVPGnsK33vlT0Fz7/Ik/MjFaFlRqMs 4tInlYUFwWQ8BDpuYaYwc3alRn0ekkQvc7B/H4df5LoxZmNwKelXcSlPiNvqYdDawZkm zrO+rPD1K/DVGUqJG1Rt+Ccfz+lBl2HFB8HLJ5v9ziz7pn0rwYYaBp3I4lHuEoZHMtS/ e0M6HeZjjjYaEdGBr3xRQAj+KwDhZXzjsa/oqxD1+7ZTRmawJdQsh1OUS+WEdu5Q1eNO ESPupVUGfvi8c3HDvfIjbiExg4Dk3lRAhQdQiAIwlqdgZhAQ/y3s1Ma1XEA+/RNr1AUI B/wg== MIME-Version: 1.0 X-Received: by 10.180.20.105 with SMTP id m9mr5294439wie.35.1408257562168; Sat, 16 Aug 2014 23:39:22 -0700 (PDT) Sender: cochard@gmail.com Received: by 10.194.90.2 with HTTP; Sat, 16 Aug 2014 23:39:22 -0700 (PDT) Received: by 10.194.90.2 with HTTP; Sat, 16 Aug 2014 23:39:22 -0700 (PDT) In-Reply-To: References: Date: Sun, 17 Aug 2014 08:39:22 +0200 X-Google-Sender-Auth: 1LpcPXOh1JoVhi8bn6RH9lmvHRM Message-ID: Subject: Re: routerboard/other hardware From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= To: Wojciech Puchar Content-Type: text/plain; charset=ISO-8859-1 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: Sun, 17 Aug 2014 06:39:24 -0000 Hi, We are using PC Engines APU (3 NIC, m-SATA port, dual core x86, etc...) and are very happy with. Le 16 ao=FBt 2014 09:44, "Wojciech Puchar" = a =E9crit : > what hardware with reasonable price is tested with FreeBSD so it runs > reliably, have 2 or more ethernet ports, small form factor and possibilit= y > 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, som= e > 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 Sun Aug 17 20:08:56 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 6409E27C; Sun, 17 Aug 2014 20:08:56 +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 1E58C2A0E; Sun, 17 Aug 2014 20:08:55 +0000 (UTC) Received: from fwd11.aul.t-online.de (fwd11.aul.t-online.de [172.20.27.152]) by mailout11.t-online.de (Postfix) with SMTP id 56643176A77; Sun, 17 Aug 2014 22:08:47 +0200 (CEST) Received: from [192.168.119.33] (S37LM+ZdYhZMACjHyBYxtjhQwc9J9Ih3He9YOoEONSNsJH3FE5jHgWeEJZUjmKEQjj@[84.154.101.219]) by fwd11.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XJ6kw-2E8KDg0; Sun, 17 Aug 2014 22:08:46 +0200 Message-ID: <53F10BCC.90801@freebsd.org> Date: Sun, 17 Aug 2014 22:08:44 +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: papowell@astart.com, 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> <53ED719E.6000706@astart.com> In-Reply-To: <53ED719E.6000706@astart.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ID: S37LM+ZdYhZMACjHyBYxtjhQwc9J9Ih3He9YOoEONSNsJH3FE5jHgWeEJZUjmKEQjj X-TOI-MSGID: 8050bc69-9319-40c9-ab71-b0ea92802dc7 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: Sun, 17 Aug 2014 20:08:56 -0000 Am 15.08.2014 um 04:34 schrieb Patrick Powell: > 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? No, I've found the answer: There are a few ISO language codes, that have been changed over time. "iw" really was used for Hebrew, but "he" is the "modern" ID. (Java apparently converts "he" back to "iw" for compatibility with old software ...) Anyway, the INDEX.keymap file used both "iw" and "he" in different sections of the file, but the keymap command only derives "he" from the locale, if it is set to "he_IL". I have been convinced to only use country codes for keymap file names (as far as possible) and thus the Hebrew keyboard is not named "il.kbd" (avoiding both "iw" and "he" ... ;-) ). Regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 17 20:09: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 0371A34E; Sun, 17 Aug 2014 20:09:01 +0000 (UTC) Received: from mailout01.t-online.de (mailout01.t-online.de [194.25.134.80]) (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 B14A82A10; Sun, 17 Aug 2014 20:09:00 +0000 (UTC) Received: from fwd14.aul.t-online.de (fwd14.aul.t-online.de [172.20.26.242]) by mailout01.t-online.de (Postfix) with SMTP id C8F824A59E7; Sun, 17 Aug 2014 22:08:51 +0200 (CEST) Received: from [192.168.119.33] (ZBm63cZbYh0Cgtr9Tg2NDjHOnPwcjhSRo3lG-A3-6hrbRfYYcEykeu5PF+MUAHmgYV@[84.154.101.219]) by fwd14.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XJ6kt-1U4uMi0; Sun, 17 Aug 2014 22:08:43 +0200 Message-ID: <53F10BC9.7070003@freebsd.org> Date: Sun, 17 Aug 2014 22:08:41 +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: Erik Cederstrand 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> <66E4EA3A-7737-4BCC-8E9E-4B68AAA9AC32@cederstrand.dk> In-Reply-To: <66E4EA3A-7737-4BCC-8E9E-4B68AAA9AC32@cederstrand.dk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ID: ZBm63cZbYh0Cgtr9Tg2NDjHOnPwcjhSRo3lG-A3-6hrbRfYYcEykeu5PF+MUAHmgYV X-TOI-MSGID: 5b1c2086-9a2f-4c37-9c78-2e160646bd15 Cc: "freebsd-hackers@freebsd.org" , Ed Maste 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: Sun, 17 Aug 2014 20:09:01 -0000 Am 15.08.2014 um 09:14 schrieb Erik Cederstrand: > Den 14/08/2014 kl. 23.40 skrev Stefan Esser : > >>> 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? > > Some years ago, I contributed a Danish Macbook keyboard layout which > is considerably different from the standard Danish PC keyboard > layout. I use it in Virtualbox VMs on my Danish Macbook. Your keymap is now available as "dk.macbook.kbd" (the ".kbd" can be ommitted in the keymap variable in "rc.conf"). Please test and report any regressions, if you have already switched over to NEWCONS. Regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 17 20:36:42 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 0ECE4A90; Sun, 17 Aug 2014 20:36:42 +0000 (UTC) Received: from mailout03.t-online.de (mailout03.t-online.de [194.25.134.81]) (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 C2FC22D20; Sun, 17 Aug 2014 20:36:41 +0000 (UTC) Received: from fwd15.aul.t-online.de (fwd15.aul.t-online.de [172.20.27.63]) by mailout03.t-online.de (Postfix) with SMTP id 667B655FDDE; Sun, 17 Aug 2014 22:36:33 +0200 (CEST) Received: from [192.168.119.33] (Gh4IbmZX8h6s8wuwvJMkyQPwFY4WkgzEt5IqAn8HzCHd0uy7EUJ6o09-sIZeeJmgrN@[84.154.101.219]) by fwd15.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XJ7Bi-1uqQWO0; Sun, 17 Aug 2014 22:36:26 +0200 Message-ID: <53F11248.4070305@freebsd.org> Date: Sun, 17 Aug 2014 22:36:24 +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: "freebsd-hackers@freebsd.org" , freebsd-stable stable Subject: TESTING required: keyboard maps for NEWCONS (committed to -CURRENT and available for -STABLE) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ID: Gh4IbmZX8h6s8wuwvJMkyQPwFY4WkgzEt5IqAn8HzCHd0uy7EUJ6o09-sIZeeJmgrN X-TOI-MSGID: def3f47d-1bcf-4e58-b25a-e824b96c48e1 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: Sun, 17 Aug 2014 20:36:42 -0000 I have just committed keymap definitions that are converted to work with NEWCONS. Since the new console expects a Unicode locale, all the different encodings are no longer needed - but all files had to be converted from their respective encodings to Unicode. Since the character encoding is no longer required in the file names, all names where converted to be named by ISO country code (plus ISO language code, where required) followed by modifiers (e.g. .acc for accent keys). It is likely, that I introduced regressions, even though I spent quite a few hours on the conversion process and the manual verification of the results. These files are currently only committed to -CURRENT and I plan to MFC to 10-STABLE as soon as possible (and permitted), which is in 3 days. If you are able to test the keymap files under -CURRENT, I'd love to receive your feedback and remarks. Please do not commit any fixes directly to -CURRENT, since I'm still working on these files (I'm afraid of merge conflicts and higher effort required for the MFC in a few days ...). If you are a (potential) NEWCONS user on -STABLE, you may want to extract the contents of http://people.freebsd.org/~se/vt-keymaps.tar.bz2 into /usr/share/vt/keymaps. (The Makefile is not required, if you directly extract to that directory, but it does no harm.) We really want to have verified keymaps for NEWCONS in 10-STABLE and the more "special" your language (i.e. the farther it is away from ISO8859-1 ;-) ) the bigger the risk that some specialty has been lost during the conversion. Please test and report your expected deadkeys vs. nodeadkeys experience, the combinations of Shift, Ctrl, Alt, Alt-Gr and all keys that you expect to support such modifiers, and the Caps Lock behavior (on keys that respect or ignore Caps Lock). I'll be reserving a few hours each day to get this into good shape for 10.1. Best regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 17 20:45: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 D12781DF; Sun, 17 Aug 2014 20:45:46 +0000 (UTC) Received: from mailout04.t-online.de (mailout04.t-online.de [194.25.134.18]) (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 8C629303D; Sun, 17 Aug 2014 20:45:46 +0000 (UTC) Received: from fwd07.aul.t-online.de (fwd07.aul.t-online.de [172.20.27.150]) by mailout04.t-online.de (Postfix) with SMTP id 7ECF0215F99; Sun, 17 Aug 2014 22:45:38 +0200 (CEST) Received: from [192.168.119.33] (ZkenbBZHohoUhFLR2kxvtV3ysvu+3Mgsff+KW5c1eUZ-LB1iekg9l3P+WysXMPpgcc@[84.154.101.219]) by fwd07.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XJ7KX-1Su2PA0; Sun, 17 Aug 2014 22:45:33 +0200 Message-ID: <53F1146B.8020906@freebsd.org> Date: Sun, 17 Aug 2014 22:45:31 +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-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: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ID: ZkenbBZHohoUhFLR2kxvtV3ysvu+3Mgsff+KW5c1eUZ-LB1iekg9l3P+WysXMPpgcc X-TOI-MSGID: 3e6c475a-ac2d-4838-b396-c63a3a3914b0 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: Sun, 17 Aug 2014 20:45:46 -0000 Am 15.08.2014 um 17:30 schrieb Ed Maste: 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 Ok, I've been convinced that this is the better scheme than the one based on locale names, which I used to prefer. And if fact, I've only needed one "complex" name: "ch-fr" (I chose "ch" instead of "ch-de", since that is the typical layout used in Switzerland - I've yet to see a Swiss-French keyboard in an actual system ...). Quite a number of keymaps are still waiting to be verified and committed. Many are derived from different encodings that should lead to the same Unicode characters, in an ideal world. I've spent all day on writing the converter scripts (for the INDEX.keymaps file and for the keymaps) and verified as many results as I could, but there's still a lot of work left ... Best regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 18 00: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 73855419 for ; Mon, 18 Aug 2014 00:54:30 +0000 (UTC) Received: from natasha.panasas.com (natasha.panasas.com [209.166.131.148]) by mx1.freebsd.org (Postfix) with ESMTP id 365083713 for ; Mon, 18 Aug 2014 00: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 s7HNVNKG023684 for ; Sun, 17 Aug 2014 19:31:24 -0400 Received: from SEABISCUIT.int.panasas.com ([172.17.132.204]) by seabiscuit ([172.17.132.204]) with mapi id 14.03.0181.006; Sun, 17 Aug 2014 16:31:23 -0700 From: "Pokala, Ravi" To: "freebsd-hackers@freebsd.org" Subject: Common storage of original MAC address Thread-Topic: Common storage of original MAC address Thread-Index: AQHPunNYUBEgYXTq+ky03AEN5pUz3Q== Date: Sun, 17 Aug 2014 23:31:19 +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: <0B749EF31FB9724A957E83DAF9DEEB13@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: Mon, 18 Aug 2014 00:54:30 -0000 Hi folks, At attach-time, the NIC drivers call ether_ifattach(), which stores the MAC address in the sockaddr_dl. If the MAC is subsequently changed (like by adding the interface to a lagg), if_setlladdr() changes the value in the sockaddr_dl. At least, that's the way I'm reading things - is that correct? If so, then we do not keep a copy of the original MAC address. For a couple of reasons (diagnostics, asset tracking and reporting), it would be very nice if the original MAC were kept somewhere, even after the working MAC was changed by if_setlladdr(). Up till now, Panasas has been saving the original MAC in the softc of specific network drivers that we use, and making it accessible via a sysctl. That's something we have to do on a per-driver basis, and something we have to keep track of on our own. We'd like to put that information in a structure all the NIC drivers already use, and get that code upstream. Storing it would require a simple change to ether_ifattach() to stash it in the new location in addition to in the sockaddr_dl, and adding some standard way (a new ioctl or sysctl?) to access it. Notably, it would not require changing all the individual drivers.=20 Are there any objections to this idea? Any suggestions as to where we might stash the original MAC? Thanks, Ravi From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 18 07:36:08 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 E8719D2E; Mon, 18 Aug 2014 07:36:08 +0000 (UTC) Received: from mailrelay007.isp.belgacom.be (mailrelay007.isp.belgacom.be [195.238.6.173]) by mx1.freebsd.org (Postfix) with ESMTP id 3A93135B8; Mon, 18 Aug 2014 07:36:07 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucKANSr8VNR8bzn/2dsb2JhbABYgw2BIIMGsQOdHoMcAYEXF3eEBAEFIzMjEAsOCgICBSECAg8qHgaIWQGsB5RuF4EsjiAHgnmBUwEEnEGMB4h9gheBSDuCfgEBAQ Received: from 231.188-241-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.241.188.231]) by relay.skynet.be with ESMTP; 18 Aug 2014 09:35:59 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.9/8.14.9) with ESMTP id s7I7Zw73001125; Mon, 18 Aug 2014 09:35:58 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Date: Mon, 18 Aug 2014 09:35:58 +0200 From: Tijl Coosemans To: Stefan Esser Subject: Re: TESTING required: keyboard maps for NEWCONS (committed to -CURRENT and available for -STABLE) Message-ID: <20140818093558.10312939@kalimero.tijl.coosemans.org> In-Reply-To: <53F11248.4070305@freebsd.org> References: <53F11248.4070305@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-hackers@freebsd.org" , freebsd-stable 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: Mon, 18 Aug 2014 07:36:09 -0000 On Sun, 17 Aug 2014 22:36:24 +0200 Stefan Esser wrote: > I have just committed keymap definitions that are converted to work with > NEWCONS. Since the new console expects a Unicode locale, all > the different encodings are no longer needed - but all files had to > be converted from their respective encodings to Unicode. Slovenian (si) and Kroatian (hr) are ISO-8859-2 or ISO-8859-16 but were converted as if they were ISO-8859-1. Alt+l should be =C5=82 for instance. From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 18 08:12: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 C9E3F814 for ; Mon, 18 Aug 2014 08:12:30 +0000 (UTC) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) by mx1.freebsd.org (Postfix) with ESMTP id A5268391B for ; Mon, 18 Aug 2014 08:12:30 +0000 (UTC) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 2F4675A9F24; Mon, 18 Aug 2014 08:12:23 +0000 (UTC) Date: Mon, 18 Aug 2014 08:12:23 +0000 From: Brooks Davis To: "Pokala, Ravi" Subject: Re: Common storage of original MAC address Message-ID: <20140818081223.GA6099@spindle.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline In-Reply-To: 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-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 08:12:30 -0000 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 17, 2014 at 11:31:19PM +0000, Pokala, Ravi wrote: > Hi folks, >=20 > At attach-time, the NIC drivers call ether_ifattach(), which stores the > MAC address in the sockaddr_dl. If the MAC is subsequently changed (like > by adding the interface to a lagg), if_setlladdr() changes the value in > the sockaddr_dl. At least, that's the way I'm reading things - is that > correct? >=20 > If so, then we do not keep a copy of the original MAC address. For a > couple of reasons (diagnostics, asset tracking and reporting), it would be > very nice if the original MAC were kept somewhere, even after the working > MAC was changed by if_setlladdr(). >=20 > Up till now, Panasas has been saving the original MAC in the softc of > specific network drivers that we use, and making it accessible via a > sysctl. That's something we have to do on a per-driver basis, and > something we have to keep track of on our own. We'd like to put that > information in a structure all the NIC drivers already use, and get that > code upstream. Storing it would require a simple change to > ether_ifattach() to stash it in the new location in addition to in the > sockaddr_dl, and adding some standard way (a new ioctl or sysctl?) to > access it. Notably, it would not require changing all the individual > drivers.=20 >=20 > Are there any objections to this idea? Any suggestions as to where we > might stash the original MAC? I think I'd store the original address in struct arpcom at attach time and publish it in the dev.. sysctl namespace. -- Brooks --W/nzBZO5zC0uMSeA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlPxtWYACgkQXY6L6fI4GtQTtACfdpNlVcX4CV6JhSUbDh8cUnLy iFoAoN5Kw0y7GF47JMWLjc8352ZNtj0S =qp// -----END PGP SIGNATURE----- --W/nzBZO5zC0uMSeA-- From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 18 16:36:36 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 CF4A894E; Mon, 18 Aug 2014 16:36:36 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 929053A3C; Mon, 18 Aug 2014 16:36:33 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [94.19.235.70]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id C3FF056401; Mon, 18 Aug 2014 20:36:32 +0400 (MSK) Date: Mon, 18 Aug 2014 20:36:30 +0400 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1155963691.20140818203630@serebryakov.spb.ru> To: hackers@freebsd.org, embedded@freebsd.org Subject: Build ARM ports on amd64 with qemu-arm-static and "native" cross-toolchain - how to? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Mon, 18 Aug 2014 16:36:36 -0000 Hello, Hackers. I'm trying to setup chroot environment to build ARMv6 ports on amd64 host. I'm using this instructions: https://wiki.freebsd.org/QemuUserModeHowTo. It works with fully-emulated environment. But when I try to add native cross-toolchain (according to "Cross Building Using the Host Cross Compiler (and other toolchain friends):" section) it fails to build anything with cc complaining about absent "crt0.o". Are these instructions up-to-date? What do I do wrong? -- // Black Lion AKA Lev Serebryakov From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 18 17: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 2A3B67B3; Mon, 18 Aug 2014 17:54:30 +0000 (UTC) Received: from natasha.panasas.com (natasha.panasas.com [209.166.131.148]) by mx1.freebsd.org (Postfix) with ESMTP id D5B303202; Mon, 18 Aug 2014 17: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 s7IFxSls018186; Mon, 18 Aug 2014 11:59:28 -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, 18 Aug 2014 08:59:27 -0700 From: "Pokala, Ravi" To: Brooks Davis Subject: Re: Common storage of original MAC address Thread-Topic: Common storage of original MAC address Thread-Index: AQHPunNYUBEgYXTq+ky03AEN5pUz3ZvWeLmAgAANIwA= Date: Mon, 18 Aug 2014 15:59:26 +0000 Message-ID: References: <20140818081223.GA6099@spindle.one-eyed-alien.net> In-Reply-To: <20140818081223.GA6099@spindle.one-eyed-alien.net> 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: <9CBE8B653AF6B14396904E107E276EEF@panasas.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Mon, 18 Aug 2014 17:54:30 -0000 -----Original Message----- From: Brooks Davis Date: Monday, August 18, 2014 at 1:12 AM To: Ravi Pokala Cc: "freebsd-hackers@freebsd.org" Subject: Re: Common storage of original MAC address >On Sun, Aug 17, 2014 at 11:31:19PM +0000, Pokala, Ravi wrote: >>... >>=20 >> Are there any objections to this idea? Any suggestions as to where we >> might stash the original MAC? > >I think I'd store the original address in struct arpcom at attach time >and publish it in the dev.. sysctl namespace. > >-- Brooks Thanks you Brooks. I'm not very familiar w/ the network stack, so I could use a little more guidance. The naive part of me says to just add char orig_mac_addr[18]; to arpcom, and do something like snprintf(IFP2AC(ifp)->orig_mac_addr, sizeof(IFP2AC(ifp)->orig_mac_addr), "%6D", lla, ":"); to populate it in ether_ifattach(). The slightly more knowledgeable part of me is aware that there are things other than ethernet out there, we might want to save the original address for those too at some point, and so a perfectly-sized char-array might not be the right thing here. With regards to using "dev.." - that's actually what we've been doing: SYSCTL_ADD_STRING(device_get_sysctl_ctx(dev), SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO, "orig_mac_addr", CTLFLAG_RD, sc->orig_mac_addr, 0, "Original MAC address"); The wrinkle is that we need the device_t to put stuff under the "dev" portion of the sysctl namespace, and we don't pass that into ether_ifattach() (nor should we). So, we'd have to do that in every NIC driver, which gets us back to having to modify the world. Thoughts? Thanks again, Ravi From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 18 18:14: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 366D12A3; Mon, 18 Aug 2014 18:14:59 +0000 (UTC) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::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 E94B03449; Mon, 18 Aug 2014 18:14:58 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n16so4308083oag.41 for ; Mon, 18 Aug 2014 11:14:58 -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=z2H2CKxbJ5SQwFGnnhohbyuBVtuHqQJzhvRnjbHGL9E=; b=nnmnuWuuZxw3Bxm2Ky9N0iARWHQQrSkE+Z8TL65iS+LH6unUjdTX1vS4wbLGPey3HJ Xcp2LZRYbVhEMv8Kk2VUJ+lgEFrJ+zgytMYi+fY/VtPnmnhOI3cY2Vqh/p2gxT4sK/U8 Daq4UGbwoEF8hhuPzX1jqKzoeuXP6fVAVJFITWlpU6WY1g4z+NfJJGgtBJCIiaDtgqEz fYwt9Rbu+LwY6L6bEaOP4Y1QLnwys1CT4e7jzk8ckEmXCJCqcI8RX84PuX1wjd/hqmgz 0tBYwr2DrGm7ApCC2//4G6PGEqqkCFfpIkWHUY3TaCLyI7cOITq+31sCmCwiNGUqBiw8 MiVA== MIME-Version: 1.0 X-Received: by 10.60.164.9 with SMTP id ym9mr38197192oeb.26.1408385698309; Mon, 18 Aug 2014 11:14:58 -0700 (PDT) Received: by 10.76.187.39 with HTTP; Mon, 18 Aug 2014 11:14:58 -0700 (PDT) In-Reply-To: References: <20140818081223.GA6099@spindle.one-eyed-alien.net> Date: Mon, 18 Aug 2014 14:14:58 -0400 Message-ID: Subject: Re: Common storage of original MAC address From: Ryan Stone To: "Pokala, Ravi" Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , Brooks Davis 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: Mon, 18 Aug 2014 18:14:59 -0000 On Mon, Aug 18, 2014 at 11:59 AM, Pokala, Ravi wrote: > Thanks you Brooks. > > I'm not very familiar w/ the network stack, so I could use a little more > guidance. The naive part of me says to just add > > char orig_mac_addr[18]; > > to arpcom, and do something like > > snprintf(IFP2AC(ifp)->orig_mac_addr, > sizeof(IFP2AC(ifp)->orig_mac_addr), "%6D", lla, ":"); > > to populate it in ether_ifattach(). > > The slightly more knowledgeable part of me is aware that there are things > other than ethernet out there, we might want to save the original address > for those too at some point, and so a perfectly-sized char-array might not > be the right thing here. > > With regards to using "dev.." - that's actually what we've > been doing: > > SYSCTL_ADD_STRING(device_get_sysctl_ctx(dev), > SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO, > "orig_mac_addr", CTLFLAG_RD, sc->orig_mac_addr, 0, > "Original MAC address"); > > > The wrinkle is that we need the device_t to put stuff under the "dev" > portion of the sysctl namespace, and we don't pass that into > ether_ifattach() (nor should we). So, we'd have to do that in every NIC > driver, which gets us back to having to modify the world. > > Thoughts? > > Thanks again, > > Ravi Personally I think that it would be better to save it in binary format and convert it to a string as needed. It would be useful to have the MAC address saved aside somewhere so that a "Restore MAC to HW default" ioctl could be implemented; this would be useful in the if_lagg driver to restore the MAC on a port after it has been removed from a lagg. From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 18 19:15:00 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 777C73FE for ; Mon, 18 Aug 2014 19:15:00 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 377E93A99 for ; Mon, 18 Aug 2014 19:14:59 +0000 (UTC) Received: from [192.168.1.2] (senat1-01.HML3.ScaleEngine.net [209.51.186.5]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id A4C1539FA1 for ; Mon, 18 Aug 2014 19:14:52 +0000 (UTC) Message-ID: <53F250BA.9010008@freebsd.org> Date: Mon, 18 Aug 2014 15:15:06 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Common storage of original MAC address References: <20140818081223.GA6099@spindle.one-eyed-alien.net> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WF2ebs9G0fDNBqqKgR5eXaR6HfKTOQIAM" 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: Mon, 18 Aug 2014 19:15:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WF2ebs9G0fDNBqqKgR5eXaR6HfKTOQIAM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-08-18 14:14, Ryan Stone wrote: > On Mon, Aug 18, 2014 at 11:59 AM, Pokala, Ravi wr= ote: >=20 >> Thanks you Brooks. >> >> I'm not very familiar w/ the network stack, so I could use a little mo= re >> guidance. The naive part of me says to just add >> >> char orig_mac_addr[18]; >> >> to arpcom, and do something like >> >> snprintf(IFP2AC(ifp)->orig_mac_addr, >> sizeof(IFP2AC(ifp)->orig_mac_addr), "%6D", lla, ":"); >> >> to populate it in ether_ifattach(). >> >> The slightly more knowledgeable part of me is aware that there are thi= ngs >> other than ethernet out there, we might want to save the original addr= ess >> for those too at some point, and so a perfectly-sized char-array might= not >> be the right thing here. >> >> With regards to using "dev.." - that's actually what we'= ve >> been doing: >> >> SYSCTL_ADD_STRING(device_get_sysctl_ctx(dev), >> SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO, >> "orig_mac_addr", CTLFLAG_RD, sc->orig_mac_addr, 0, >> "Original MAC address"); >> >> >> The wrinkle is that we need the device_t to put stuff under the "dev" >> portion of the sysctl namespace, and we don't pass that into >> ether_ifattach() (nor should we). So, we'd have to do that in every NI= C >> driver, which gets us back to having to modify the world. >> >> Thoughts? >> >> Thanks again, >> >> Ravi >=20 > Personally I think that it would be better to save it in binary format > and convert it to a string as needed. It would be useful to have the > MAC address saved aside somewhere so that a "Restore MAC to HW > default" ioctl could be implemented; this would be useful in the > if_lagg driver to restore the MAC on a port after it has been removed > from a lagg. >=20 +1 for restoring the MAC after removing a device from a lagg(4) or bridge= (4) --=20 Allan Jude --WF2ebs9G0fDNBqqKgR5eXaR6HfKTOQIAM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJT8lDAAAoJEJrBFpNRJZKfss4P/2c+z+VQbOSGCv5vTnbJ+MvM ScJBYFnE9JbeGHnt9zRwOAVrKc4LEltxLlfPXf7nYpCDT1VY3C3cURgxqPmGHFWX UH7qnTkdRF97NfXItfCiXOL+OvSDnm/xHEfuD1XlZQXkQ3WIKNwpmrtsIeZq64nu b4WWlYXNu4Zf5ZSbXRw2Nrjk5VnScodzp8XZrHrbrEOQp3jOh2Q2PWM5OWkUC3r4 WWT5nqVIF14y8TdqqxOquaGg2dW19Sz4BAZuYIcAX0iEhttvy/W2lOxJJ0Q6xp1P RdxwRFpAIoGMB8ZUABPCTSdPQa+EHpI+rxFYdTe0LUCDgRhWSnYFShAuMa+8Rhl9 4+XA1AKNVMEfxDP2AufEWMG/cPCHOGd3KV76wCq72dyB8UGv6HWj9MVX5JyuqXRb Z3NcmaY714/cUjtth+LDVfDmeUGtWhKUX2JBC+xLCFXTZbA9cBHTdCh+9VXK0R3Q 5d8n7nuU5S3J9m7oDWgfJXGWNozAWkkQvcP9wtrRJsPPak3Y4a13vsBvyhUUtzLu p0A0DqqMdVelWtl3D6f/3LGo6UCAtqYFZ6z2fGZfIrVi8IQ38EX/kN90b2BCsH4P QGkjha31jS6vFh2UH/ofgScl1skRorDdkzoSl0efx/YkIIsIBOGStYMqkcqV+POc tNOdUrH9etP3x8G6ZEaH =liAp -----END PGP SIGNATURE----- --WF2ebs9G0fDNBqqKgR5eXaR6HfKTOQIAM-- From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 19 05:19:13 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 4D76F39C; Tue, 19 Aug 2014 05:19:13 +0000 (UTC) Received: from natasha.panasas.com (natasha.panasas.com [209.166.131.148]) by mx1.freebsd.org (Postfix) with ESMTP id 0AA483F64; Tue, 19 Aug 2014 05:19:12 +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 s7J5J4YM014661; Tue, 19 Aug 2014 01:19:04 -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, 18 Aug 2014 22:19:03 -0700 From: "Pokala, Ravi" To: Ryan Stone Subject: Re: Common storage of original MAC address Thread-Topic: Common storage of original MAC address Thread-Index: AQHPunNYUBEgYXTq+ky03AEN5pUz3ZvWeLmAgAANIwCAAJs5AIAARC4A Date: Tue, 19 Aug 2014 05:19:02 +0000 Message-ID: References: <20140818081223.GA6099@spindle.one-eyed-alien.net> In-Reply-To: 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: <198BD3F5B0958446932BD7D2913C3BD2@panasas.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-hackers@freebsd.org" , Brooks Davis 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, 19 Aug 2014 05:19:13 -0000 -----Original Message----- From: Ryan Stone Date: Monday, August 18, 2014 at 11:14 AM To: Ravi Pokala Cc: Brooks Davis , "freebsd-hackers@freebsd.org" Subject: Re: Common storage of original MAC address >On Mon, Aug 18, 2014 at 11:59 AM, Pokala, Ravi >wrote: > >>... > >Personally I think that it would be better to save it in binary format >and convert it to a string as needed. I'm fine with that too; the reason I suggested a string is because that's what's already getting passed to ether_ifattach(). I suppose it's easy enough to run the string through ether_aton() to get the binary version. But again, not everything is Ethernet, so we might need to have different binary representations; if we're doing that, we might as well just use the string version, and let the caller decide how to parse the string. (I'm specifically thinking about IP-over-Infiniband - while I'm sure IB cards must have some type of hardware address, it's probably not the same format as an Ethernet MAC address.) >It would be useful to have the MAC address saved aside somewhere so that >a "Restore MAC to HW default" ioctl could be implemented; this would be >useful in the if_lagg driver to restore the MAC on a port after it has >been removed from a lagg. Or how about an ioctl to get the original MAC (rather than a sysctl). Then the "restore to default" code would be a two-step process - get the original MAC with the new ioctl (say "SIOCGHWLLADDR" for "Get Hardware LLADDR"?), and then set the working MAC to that value w/ the existing ioctl (SIOCSIFLLADDR). I actually like this idea more than the sysctl, because it could be done in one place (probably in net/if.c, next to if_setlladdr() (which is what implements the guts of SIOCSIFLLADDR)). Does that sound like a plan? Thanks, Ravi From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 19 08:28:01 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 EF2327FF; Tue, 19 Aug 2014 08:28:01 +0000 (UTC) Received: from mailout04.t-online.de (mailout04.t-online.de [194.25.134.18]) (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 B29DD3F1A; Tue, 19 Aug 2014 08:28:01 +0000 (UTC) Received: from fwd23.aul.t-online.de (fwd23.aul.t-online.de [172.20.26.128]) by mailout04.t-online.de (Postfix) with SMTP id AAA034CF6AD; Tue, 19 Aug 2014 10:27:53 +0200 (CEST) Received: from [192.168.119.33] (bdQ70BZXwhNaqXRtkKkizbk0kgCi-rTf20WyjAHJeW+PfPM82RcMk8CMlVyq8QZgbf@[84.154.101.219]) by fwd23.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XJeli-0vTDk00; Tue, 19 Aug 2014 10:27:50 +0200 Message-ID: <53F30A81.9090302@freebsd.org> Date: Tue, 19 Aug 2014 10:27:45 +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: "freebsd-hackers@freebsd.org" Subject: Opinions thought regarding: NEWCONS, rc.conf and rc.d/syscons Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ID: bdQ70BZXwhNaqXRtkKkizbk0kgCi-rTf20WyjAHJeW+PfPM82RcMk8CMlVyq8QZgbf X-TOI-MSGID: 092e91f1-6af2-4cd4-9e92-2bfa06e4a29b 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, 19 Aug 2014 08:28:02 -0000 As you all probably know, 10.1 will ship with both SYSCONS and NEWCONS. I'm working keymap files for NEWCONS (translated from those in SYSCONS), and they'll need to be named differently than before. The SYSCONF keymap names in rc.conf will not work for NEWCONS. They include an encoding scheme in their name, while NEWCONS universally uses Unicode. There are a few points that still need to be considered for 10.1: a) Is rc.d/syscons still an appropriate name when using NEWCONS? (I'd leave it unchanged, but I thought I'd ask ...) b) Do we need to identify NEWCONS vs. SYSCONS in the messages printed by that rc script? (I guess this might be a good idea.) c) Do we expect to warn the user when he has a SYSCONS keymap name specified in the rc.conf "keymap" variable, while using NEWCONS? (This might be a good idea, at least when the default is to use NEWCONS and the user might not be aware of the change.) d) Do we want to provide the user with an information regarding the name of the SYSCONS keymap configured, to ease the transition? (Could be done ...) e) Do we want the rc script to translate the SYSCONS keymap name to its new form? (This might be good for people using foreign keyboards, if their password uses characters located at other positions than on the default keymap, that will be used if no valid "keymap" is specified.) f) It might be good to introduce "keymap_sc" (and/or "keymap_vt") as a value used in preference to "keymap" if defined and the corresponding console driver is detected. (An alternativ to e) that is easier to implement and still allows to have one rc.conf file that covers both SYSCONS and NEWCONS.) I'd appreciate opinios and ideas how to proceed with these questions. Regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 19 17:25: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 30249502 for ; Tue, 19 Aug 2014 17:25:46 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (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 0319C3974 for ; Tue, 19 Aug 2014 17:25:45 +0000 (UTC) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.5/8.14.5) with ESMTP id s7JHQJQg087278 for ; Tue, 19 Aug 2014 10:26:25 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimatedns.net (8.14.5/8.14.5/Submit) id s7JHQE0K087277; Tue, 19 Aug 2014 10:26:14 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Tue, 19 Aug 2014 10:26:14 -0700 (PDT) Message-ID: <111a1d7ff95c133065cef9eb8fcdf153.authenticated@ultimatedns.net> Date: Tue, 19 Aug 2014 10:26:14 -0700 (PDT) Subject: How to explicitly disable use of clang in ports Makefile? From: "Chris H" To: "freebsd hackers" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal 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, 19 Aug 2014 17:25:46 -0000 Greetings, I'm on RELENG_8, and RELENG_9, so don't have access to recent versions of clang. I'm maintaing several ports, and I'm currently dealing with one that fails with the use of clang. While I plan to update one of my "dev boxes" to 11, and start working with clang. Until then, where clang is concerned, I'm guessing, at best. So can anyone tell me how to ensure that clang is never considered for making my port? my CXX = g++. My port builds, and installs flawlessly on anything <=9. But because anything >=10 uses clang, by default. I'm failing on those. I've had a look at /usr/ports/MK/Uses/compiler.mk. But can't seem to unwind the conditional(s) for my use needs. Thank you for all your time, and consideration. --Chris From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 19 19:21: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 CA89E9D7 for ; Tue, 19 Aug 2014 19:21:59 +0000 (UTC) Received: from mail-ie0-x242.google.com (mail-ie0-x242.google.com [IPv6:2607:f8b0:4001:c03::242]) (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 9E0833647 for ; Tue, 19 Aug 2014 19:21:59 +0000 (UTC) Received: by mail-ie0-f194.google.com with SMTP id rl12so376425iec.5 for ; Tue, 19 Aug 2014 12:21:59 -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=8LcAllXKG7Kp5rFJkY6hQ3LU02H8j9ggMED1lMIHyZ8=; b=Mr/MoGA17Y7VFdFUjNplg1Wa5/KptlokRJ7YAINqKTGpGabhSV+SXgr6NGba1jW1NZ yWoLlIPsRikToLbc/BvRxy6DRdHV74ZApoo8SWZzb+uyTRnSvFtnF16MA+wjN8VbtU6q dMBY4Fh0VLpSzhMlrWFBXgXv+3p0SmwLSF98x8AmSQ+PdTR8PygmpkAqkHj9qwWLZKhi 0r9xa76979rWqfSsk6oKLu4khCvk8Bwg6cSqgtHdUuOTm0LhD6U50ssGmxyCFDefBhJT FROgPT2pDnljZhJAI5RmT6ImCyfRkc0v3AyiPn7aE0fNZYzLtXdwExlZ54etSh1n5eKV /rXg== MIME-Version: 1.0 X-Received: by 10.50.50.198 with SMTP id e6mr7874183igo.1.1408476119005; Tue, 19 Aug 2014 12:21:59 -0700 (PDT) Received: by 10.64.26.130 with HTTP; Tue, 19 Aug 2014 12:21:58 -0700 (PDT) Date: Tue, 19 Aug 2014 12:21:58 -0700 Message-ID: Subject: stopped processes using cpu? From: Dieter BSD To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-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: Tue, 19 Aug 2014 19:21:59 -0000 8.2 on amd64 Top(1) with no arguments reports that some firefox processes are using cpu dispite being stopped (via kill -stop pid) for at least several hours. Adding -C doesn't change the numbers. Ps(1) reports the same. Interestingly, a firefox that isn't stopped is (correctly?) reported as using 0 cpu. The 100% idle should be correct, but who knows. last pid: 51932; load averages: 0.07, 0.99, 1.42 up 14+19:02:56 08:48:28 267 processes: 1 running, 138 sleeping, 128 stopped CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 1665M Active, 653M Inact, 240M Wired, 95M Cache, 372M Buf, 815M Free Swap: 8965M Total, 560K Used, 8965M Free PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 44188 a 9 44 0 303M 187M STOP 113:19 13.43% firefox-bin 92986 b 11 44 0 164M 62848K STOP 0:18 5.03% firefox-bin 16507 c 11 44 0 189M 88976K STOP 0:13 0.24% firefox-bin 2265 root 1 44 0 248M 193M select 625:38 0.00% Xorg 51271 d 10 44 0 233M 128M ucond 12:12 0.00% firefox-bin From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 19 19:28: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 DA2F3C41 for ; Tue, 19 Aug 2014 19:28:14 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id B2EFD36AB for ; Tue, 19 Aug 2014 19:28:14 +0000 (UTC) Received: from [192.168.1.2] (senat1-01.HML3.ScaleEngine.net [209.51.186.5]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 008173A0FC for ; Tue, 19 Aug 2014 19:28:13 +0000 (UTC) Message-ID: <53F3A564.8070202@freebsd.org> Date: Tue, 19 Aug 2014 15:28:36 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: stopped processes using cpu? References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LdRWu2V8oeX8hrP86qOFPGCkvE87uPsMJ" 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, 19 Aug 2014 19:28:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LdRWu2V8oeX8hrP86qOFPGCkvE87uPsMJ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-08-19 15:21, Dieter BSD wrote: > 8.2 on amd64 > Top(1) with no arguments reports that some firefox processes are using = cpu > dispite being stopped (via kill -stop pid) for at least several hours. > Adding -C doesn't change the numbers. Ps(1) reports the same. > Interestingly, a firefox that isn't stopped is (correctly?) reported as= > using 0 cpu. The 100% idle should be correct, but who knows. >=20 > last pid: 51932; load averages: 0.07, 0.99, 1.42 up 14+19:02:56 08:4= 8:28 > 267 processes: 1 running, 138 sleeping, 128 stopped > CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > Mem: 1665M Active, 653M Inact, 240M Wired, 95M Cache, 372M Buf, 815M Fr= ee > Swap: 8965M Total, 560K Used, 8965M Free >=20 > PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND= > 44188 a 9 44 0 303M 187M STOP 113:19 13.43% firefox= -bin > 92986 b 11 44 0 164M 62848K STOP 0:18 5.03% firefox= -bin > 16507 c 11 44 0 189M 88976K STOP 0:13 0.24% firefox= -bin > 2265 root 1 44 0 248M 193M select 625:38 0.00% Xorg > 51271 d 10 44 0 233M 128M ucond 12:12 0.00% firefox= -bin > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 I wonder if jhb@'s new top code solves this. He adjusted the way CPU usage is tracked to be more responsive, and not based on averages --=20 Allan Jude --LdRWu2V8oeX8hrP86qOFPGCkvE87uPsMJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJT86VnAAoJEJrBFpNRJZKfbNYP/3Ebs/0uWT8uZF4IC/9qIafO S3U2GDpt9QH7BLhfn3LLa8zDRF7cBdy01uPNPtjAo9zOWByt5QFs6b9BliMq1HLM f8swamTFHuHJFFHGu2qyLA6AwsMkZtE/jdkBT7eYzQD9iip/A2GvLzpR/H6onkyQ Bj8EP4piMD8RC5ntXPTJ9Fj72PJQozwtX7Ikjh8PdrEFXgW66fRIJz1fXf1JjmsH t4vABZWe4XGvqE391pGXyFR/l/5J94+OOOgZkcU30oh0aohrso1LgdwMMmjzb5MY O25b8yJ8yqwawFDge+dkTPCNB05o5UNCpa/ENnev+vXQLmgbSHhwHhrqrRQam65i QhUeB8kRGz+CB9RajxF3x1bKYZzbY1sgIflmuUIV+b9sBBMaFZ5YjZFKKOamTr+M sU10vd2JRxEkdZ6MI0k45cOfaVvtL+goMypbNfpsA7WcDzXiUBZfhTVVRlunqvbR gZWYKNrSd9GIWaEbyekko7LvXGg+fS1ul4TUGXK3kNSOBu79w7bIqh3DfNYx59hW zNhxGsR8+o6LJZEQGOUVEdgBPgV11udAneoEWkskYi49QnzjxurfRzpor6Sfs6rQ vBE6ZXjpj4ou+1ZbB8wWkjrYNGqv48qw3Q/mVb1jHYOsmpMI1tjHAUtnY7kD6117 fbIiXZ9YHtTCUpOIeLzM =oiZv -----END PGP SIGNATURE----- --LdRWu2V8oeX8hrP86qOFPGCkvE87uPsMJ-- From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 20 02:15: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 85B492F6 for ; Wed, 20 Aug 2014 02:15:14 +0000 (UTC) Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 582253A6C for ; Wed, 20 Aug 2014 02:15:14 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id y10so10909449pdj.14 for ; Tue, 19 Aug 2014 19:15:13 -0700 (PDT) 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=iai3TdlRO0hRSxdawKb1bj3VqsnjwuzKWk3fyssSGjI=; b=BtaRzve2osA5wKqUBF0eQe62rnQU2VIWMrG1kVUZpqt6pGGQLxfBfLNo+unPa2dWhc fPoYA7R2BlHnYt/DT0fd9BXeqtBOFqmDWU6lk/ba4I63XIcOfj4NR1qdq0AFUTuER1zt J1DeSO/4J5SNz1ePgBD5oEJjZVboKmQ+dV3q81lREWnzzRJUFiOBE322C7FX8VnReD5q etfSfW5rA3c42+0NLQRLBGGAJi3oxBaIwzYrbpZyGlAG3xAcT5vwTEFUmzjx2nM874FM +YY0VA1YVZ2NjWBc9RNejPRxnUdrY8Q1I2EUC/bdW+iJwX+ul3BN5AsQu21F/SJHTZ7C QDUA== X-Gm-Message-State: ALoCoQn1ophYKpWJx+Z08glMOkfLvszPeXgZOT3w6MA+/m8v7JOZGF0tXq9uQcDmVraFOdEnhViK X-Received: by 10.70.93.8 with SMTP id cq8mr13940837pdb.160.1408499123547; Tue, 19 Aug 2014 18:45:23 -0700 (PDT) Received: from [192.168.1.100] (c-24-6-220-224.hsd1.ca.comcast.net. [24.6.220.224]) by mx.google.com with ESMTPSA id gi8sm20626279pbc.16.2014.08.19.18.45.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 18:45:23 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: stopped processes using cpu? From: Tim Kientzle In-Reply-To: <53F3A564.8070202@freebsd.org> Date: Tue, 19 Aug 2014 18:45:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <10AEB4BC-B1B3-4312-A36C-ECE33EC56805@kientzle.com> References: <53F3A564.8070202@freebsd.org> To: Allan Jude X-Mailer: Apple Mail (2.1878.6) 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, 20 Aug 2014 02:15:14 -0000 On Aug 19, 2014, at 12:28 PM, Allan Jude wrote: > On 2014-08-19 15:21, Dieter BSD wrote: >> 8.2 on amd64 >> Top(1) with no arguments reports that some firefox processes are = using cpu >> dispite being stopped (via kill -stop pid) for at least several = hours. >> Adding -C doesn't change the numbers. Ps(1) reports the same. >> Interestingly, a firefox that isn't stopped is (correctly?) reported = as >> using 0 cpu. The 100% idle should be correct, but who knows. >>=20 >> last pid: 51932; load averages: 0.07, 0.99, 1.42 up 14+19:02:56 = 08:48:28 >> 267 processes: 1 running, 138 sleeping, 128 stopped >> CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% = idle >> Mem: 1665M Active, 653M Inact, 240M Wired, 95M Cache, 372M Buf, 815M = Free >> Swap: 8965M Total, 560K Used, 8965M Free >>=20 >> PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU = COMMAND >> 44188 a 9 44 0 303M 187M STOP 113:19 13.43% = firefox-bin >> 92986 b 11 44 0 164M 62848K STOP 0:18 5.03% = firefox-bin >> 16507 c 11 44 0 189M 88976K STOP 0:13 0.24% = firefox-bin >> 2265 root 1 44 0 248M 193M select 625:38 0.00% Xorg >> 51271 d 10 44 0 233M 128M ucond 12:12 0.00% = firefox-bin >> _______________________________________________ >> 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" >>=20 >=20 > I wonder if jhb@'s new top code solves this. He adjusted the way CPU > usage is tracked to be more responsive, and not based on averages I wonder if jhb@=92s new top code fixes the whacky WCPU values we=92ve = been seeing on FreeBSD/ARM. (1713% CPU is a little hard to believe on a = single-core board ;-). Tim From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 20 05:12:42 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 EF54EDE2; Wed, 20 Aug 2014 05:12:41 +0000 (UTC) Received: from pps05.cites.illinois.edu (pps05.cites.illinois.edu [192.17.82.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 ABF853A91; Wed, 20 Aug 2014 05:12:41 +0000 (UTC) Received: from citesht3.cites.illinois.edu (citesht3.cites.illinois.edu [128.174.34.208]) by pps05.cites.illinois.edu (8.14.5/8.14.5) with ESMTP id s7K55ISw004780 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Aug 2014 00:05:18 -0500 Received: from CHIMBX1.ad.uillinois.edu ([169.254.6.58]) by CITESHT3.ad.uillinois.edu ([128.174.34.208]) with mapi id 14.03.0195.001; Wed, 20 Aug 2014 00:05:17 -0500 From: "Dautenhahn, Nathan Daniel" To: Tim Kientzle Subject: Re: stopped processes using cpu? Thread-Topic: stopped processes using cpu? Thread-Index: AQHPu+Lb9wz5zxFPpUS8b4mine3BSpvYo5YAgABpQ4D//+QLWg== Date: Wed, 20 Aug 2014 05:05:16 +0000 Message-ID: <118A3B64-21C0-4FB9-84AD-837C037AAFD3@illinois.edu> References: <53F3A564.8070202@freebsd.org>, <10AEB4BC-B1B3-4312-A36C-ECE33EC56805@kientzle.com> In-Reply-To: <10AEB4BC-B1B3-4312-A36C-ECE33EC56805@kientzle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0 X-Spam-Details: rule=cautious_plus_nq_notspam policy=cautious_plus_nq score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1408200044 X-Spam-OrigSender: dautenh1@illinois.edu X-Spam-Bar: Cc: "freebsd-hackers@freebsd.org" , Allan Jude 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, 20 Aug 2014 05:12:42 -0000 > On Aug 19, 2014, at 9:15 PM, "Tim Kientzle" wrote: >=20 >=20 >> On Aug 19, 2014, at 12:28 PM, Allan Jude wrote: >>=20 >>> On 2014-08-19 15:21, Dieter BSD wrote: >>> 8.2 on amd64 >>> Top(1) with no arguments reports that some firefox processes are using = cpu >>> dispite being stopped (via kill -stop pid) for at least several hours. >>> Adding -C doesn't change the numbers. Ps(1) reports the same. >>> Interestingly, a firefox that isn't stopped is (correctly?) reported as >>> using 0 cpu. The 100% idle should be correct, but who knows. >>>=20 >>> last pid: 51932; load averages: 0.07, 0.99, 1.42 up 14+19:02:56 08:4= 8:28 >>> 267 processes: 1 running, 138 sleeping, 128 stopped >>> CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle >>> Mem: 1665M Active, 653M Inact, 240M Wired, 95M Cache, 372M Buf, 815M Fr= ee >>> Swap: 8965M Total, 560K Used, 8965M Free >>>=20 >>> PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND >>> 44188 a 9 44 0 303M 187M STOP 113:19 13.43% firefox= -bin >>> 92986 b 11 44 0 164M 62848K STOP 0:18 5.03% firefox= -bin >>> 16507 c 11 44 0 189M 88976K STOP 0:13 0.24% firefox= -bin >>> 2265 root 1 44 0 248M 193M select 625:38 0.00% Xorg >>> 51271 d 10 44 0 233M 128M ucond 12:12 0.00% firefox= -bin >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >>=20 >> I wonder if jhb@'s new top code solves this. He adjusted the way CPU >> usage is tracked to be more responsive, and not based on averages >=20 > I wonder if jhb@=92s new top code fixes the whacky WCPU values we=92ve be= en seeing on FreeBSD/ARM. (1713% CPU is a little hard to believe on a sing= le-core board ;-). It could be a bit of an odd suggestion, and I really have no experience on = whether or not the existing code is good or bad, but I wonder of there migh= t be some type of rootkit running on the system? Possibly lying about perfo= rmance to hide processes? In the Firefox case, a rootkit could be labeling a malicious process with F= irefox to hide the processes existence.=20 How long has the system been operating? Is it possible for that to be happe= ning in this case?=20 ::Nathan:: >=20 > Tim >=20 > _______________________________________________ > 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 Wed Aug 20 07:29:26 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 660C4F4F; Wed, 20 Aug 2014 07:29:26 +0000 (UTC) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::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 0C37F3843; Wed, 20 Aug 2014 07:29:25 +0000 (UTC) Received: by mail-oa0-f50.google.com with SMTP id g18so6060113oah.23 for ; Wed, 20 Aug 2014 00:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=NyX5iGkKUgfUtP9KH26Epu5lSbczfhEJziJZAwh0NcQ=; b=Tn9FYdJ17VMYNumUgSVbAq1WdLEynJD7U1XfNgKbFZQ+0nc77N2H756Me49mPlOz8W NcpaoP0igVGtw0tMNYWvp7baJmElHqZAPeIFDtabbm1JUzSL1vbzHKzqFrLBuNdEjzTW eqQSC1+N15DXzcmovMxeo6gmR6NlxoRRYlqow8/EXTavOCWThipnM5JDOmRhl5nEjrBk FYmKLKzUH62OVay9AXGUCcRrb2Rc/6a7lvdEzgNqQCzUo9wB0AoqpvdXIRBlknjnKLdL AyIblzvT20c4ukBvAvsrXhqTAeLJAq4/+L7JnITXE+ivT74jAp5mEkNPx1cwQw+fCRei MMHQ== MIME-Version: 1.0 X-Received: by 10.60.159.232 with SMTP id xf8mr47653573oeb.16.1408519765328; Wed, 20 Aug 2014 00:29:25 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.202.75.15 with HTTP; Wed, 20 Aug 2014 00:29:25 -0700 (PDT) Date: Wed, 20 Aug 2014 09:29:25 +0200 X-Google-Sender-Auth: jGS1P7nTglhcfVyN040rtbvaPRQ Message-ID: Subject: FBSD 10.0 USB Memstick Loader hangs on HP EliteBook 2740p From: CeDeROM To: FreeBSD Questions Mailing List , freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org, freebsd-sysinstall@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: Wed, 20 Aug 2014 07:29:26 -0000 Hello :-) Loader of the FreeBSD 10.0-RELEASE AMD64 hangs on load in random moments when booting FreeBSD-10.0-RELEASE-amd64-memstick.img on HP EliteBook 2740p. There is no problem on other machines, the problem does not allow kernel to load and boot, I have tried other USB sticks, BIOS update does not change anything. I have booted 64bit both Win7 and Linux from USB drive with success. There is no optical drive, so the only alternative would be to use pxe install, I will try the loader and let you know back if this is anything USB related or rather Loader/Hardware problem.. How the loader problem can be traced back? I can enter boot command prompt :-) Any hints appreciated :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 20 13:17: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 91B7D8DD; Wed, 20 Aug 2014 13:17:15 +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 618703DB0; Wed, 20 Aug 2014 13:17:14 +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 1XK5lE-000I98-Dn; Wed, 20 Aug 2014 13:17:08 +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 s7KDH7h4053503; Wed, 20 Aug 2014 07:17:07 -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: U2FsdGVkX19g1IZOVMaGxv5RGbStKm0W X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: stopped processes using cpu? From: Ian Lepore To: Tim Kientzle In-Reply-To: <10AEB4BC-B1B3-4312-A36C-ECE33EC56805@kientzle.com> References: <53F3A564.8070202@freebsd.org> <10AEB4BC-B1B3-4312-A36C-ECE33EC56805@kientzle.com> Content-Type: text/plain; charset="iso-8859-7" Date: Wed, 20 Aug 2014 07:17:06 -0600 Message-ID: <1408540626.1150.1.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id s7KDH7h4053503 Cc: freebsd-hackers@freebsd.org, Allan Jude 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, 20 Aug 2014 13:17:15 -0000 On Tue, 2014-08-19 at 18:45 -0700, Tim Kientzle wrote: > On Aug 19, 2014, at 12:28 PM, Allan Jude wrote: >=20 > > On 2014-08-19 15:21, Dieter BSD wrote: > >> 8.2 on amd64 > >> Top(1) with no arguments reports that some firefox processes are usi= ng cpu > >> dispite being stopped (via kill -stop pid) for at least several hour= s. > >> Adding -C doesn't change the numbers. Ps(1) reports the same. > >> Interestingly, a firefox that isn't stopped is (correctly?) reported= as > >> using 0 cpu. The 100% idle should be correct, but who knows. > >>=20 > >> last pid: 51932; load averages: 0.07, 0.99, 1.42 up 14+19:02:56 0= 8:48:28 > >> 267 processes: 1 running, 138 sleeping, 128 stopped > >> CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% id= le > >> Mem: 1665M Active, 653M Inact, 240M Wired, 95M Cache, 372M Buf, 815M= Free > >> Swap: 8965M Total, 560K Used, 8965M Free > >>=20 > >> PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMA= ND > >> 44188 a 9 44 0 303M 187M STOP 113:19 13.43% fire= fox-bin > >> 92986 b 11 44 0 164M 62848K STOP 0:18 5.03% fire= fox-bin > >> 16507 c 11 44 0 189M 88976K STOP 0:13 0.24% fire= fox-bin > >> 2265 root 1 44 0 248M 193M select 625:38 0.00% Xorg > >> 51271 d 10 44 0 233M 128M ucond 12:12 0.00% fire= fox-bin > >> _______________________________________________ > >> freebsd-hackers@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebs= d.org" > >>=20 > >=20 > > I wonder if jhb@'s new top code solves this. He adjusted the way CPU > > usage is tracked to be more responsive, and not based on averages >=20 > I wonder if jhb@=A2s new top code fixes the whacky WCPU values we=A2ve = been seeing on FreeBSD/ARM. (1713% CPU is a little hard to believe on a = single-core board ;-). >=20 > Tim >=20 *Fixes* it? I've been under the impression those changes caused it. I certainly never saw 1000%+ numbers in top until very recently. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 20 16:00: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 CE787789; Wed, 20 Aug 2014 16:00:46 +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 A63C93084; Wed, 20 Aug 2014 16:00:46 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8951AB9D0; Wed, 20 Aug 2014 12:00:45 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: Common storage of original MAC address Date: Wed, 20 Aug 2014 11:41:47 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <20140818081223.GA6099@spindle.one-eyed-alien.net> In-Reply-To: <20140818081223.GA6099@spindle.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201408201141.47933.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 20 Aug 2014 12:00:45 -0400 (EDT) Cc: Brooks Davis , "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: Wed, 20 Aug 2014 16:00:46 -0000 On Monday, August 18, 2014 4:12:23 am Brooks Davis wrote: > On Sun, Aug 17, 2014 at 11:31:19PM +0000, Pokala, Ravi wrote: > > Hi folks, > > > > At attach-time, the NIC drivers call ether_ifattach(), which stores the > > MAC address in the sockaddr_dl. If the MAC is subsequently changed (like > > by adding the interface to a lagg), if_setlladdr() changes the value in > > the sockaddr_dl. At least, that's the way I'm reading things - is that > > correct? > > > > If so, then we do not keep a copy of the original MAC address. For a > > couple of reasons (diagnostics, asset tracking and reporting), it would be > > very nice if the original MAC were kept somewhere, even after the working > > MAC was changed by if_setlladdr(). > > > > Up till now, Panasas has been saving the original MAC in the softc of > > specific network drivers that we use, and making it accessible via a > > sysctl. That's something we have to do on a per-driver basis, and > > something we have to keep track of on our own. We'd like to put that > > information in a structure all the NIC drivers already use, and get that > > code upstream. Storing it would require a simple change to > > ether_ifattach() to stash it in the new location in addition to in the > > sockaddr_dl, and adding some standard way (a new ioctl or sysctl?) to > > access it. Notably, it would not require changing all the individual > > drivers. > > > > Are there any objections to this idea? Any suggestions as to where we > > might stash the original MAC? > > I think I'd store the original address in struct arpcom at attach time > and publish it in the dev.. sysctl namespace. ifnets and device_t's aren't necessarily 1:1 (some multiport NIC drivers might only create a device_t for the adapter). -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 20 16:00: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 A1387725; Wed, 20 Aug 2014 16:00:44 +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 72A303083; Wed, 20 Aug 2014 16:00:44 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 457E8B9CF; Wed, 20 Aug 2014 12:00:43 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: stopped processes using cpu? Date: Wed, 20 Aug 2014 11:38:40 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <10AEB4BC-B1B3-4312-A36C-ECE33EC56805@kientzle.com> <1408540626.1150.1.camel@revolution.hippie.lan> In-Reply-To: <1408540626.1150.1.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Message-Id: <201408201138.40228.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 20 Aug 2014 12:00:43 -0400 (EDT) Cc: Allan Jude , Ian Lepore 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, 20 Aug 2014 16:00:44 -0000 On Wednesday, August 20, 2014 9:17:06 am Ian Lepore wrote: > On Tue, 2014-08-19 at 18:45 -0700, Tim Kientzle wrote: > > On Aug 19, 2014, at 12:28 PM, Allan Jude wrote: > >=20 > > > On 2014-08-19 15:21, Dieter BSD wrote: > > >> 8.2 on amd64 > > >> Top(1) with no arguments reports that some firefox processes are usi= ng=20 cpu > > >> dispite being stopped (via kill -stop pid) for at least several hour= s. > > >> Adding -C doesn't change the numbers. Ps(1) reports the same. > > >> Interestingly, a firefox that isn't stopped is (correctly?) reported= as > > >> using 0 cpu. The 100% idle should be correct, but who knows. > > >>=20 > > >> last pid: 51932; load averages: 0.07, 0.99, 1.42 up 14+19:02:56 =20 08:48:28 > > >> 267 processes: 1 running, 138 sleeping, 128 stopped > > >> CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% id= le > > >> Mem: 1665M Active, 653M Inact, 240M Wired, 95M Cache, 372M Buf, 815M= =20 =46ree > > >> Swap: 8965M Total, 560K Used, 8965M Free > > >>=20 > > >> PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMA= ND > > >> 44188 a 9 44 0 303M 187M STOP 113:19 13.43%=20 firefox-bin > > >> 92986 b 11 44 0 164M 62848K STOP 0:18 5.03%=20 firefox-bin > > >> 16507 c 11 44 0 189M 88976K STOP 0:13 0.24%=20 firefox-bin > > >> 2265 root 1 44 0 248M 193M select 625:38 0.00% Xorg > > >> 51271 d 10 44 0 233M 128M ucond 12:12 0.00%=20 firefox-bin > > >> _______________________________________________ > > >> 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" > > >>=20 > > >=20 > > > I wonder if jhb@'s new top code solves this. He adjusted the way CPU > > > usage is tracked to be more responsive, and not based on averages > >=20 > > I wonder if jhb@=A2s new top code fixes the whacky WCPU values we=A2ve = been=20 seeing on FreeBSD/ARM. (1713% CPU is a little hard to believe on a single- core board ;-). > >=20 > > Tim > >=20 >=20 > *Fixes* it? I've been under the impression those changes caused it. I > certainly never saw 1000%+ numbers in top until very recently. Yes, if it's a recent change then mine are to blame. In both cases the=20 numbers are imprecise. The older code still in stable@ (as in the OP), takes a long time to ramp up and down. So in this case the processes are stopped (no, there's no rootkit), but the scheduler takes a long time to factor that into its decayed %CPU computation. In the "new" code, the problem is that fetching the kinfo_proc and the current timestamp for that kinfo_proc is not atomic. I have thought about "fixing" that by embedding a new timeval in kinfo_proc that is stamped with the time the individual kinfo_proc is generated. This would (I believe) alleviate the noise in the new code as the delta in walltime at the "bottom" of the ratio would then correspond to the delta in runtime on the "top". However, trying to store a timeval in kinfo_proc is quite tricky as all the available fields are things like ints and longs. I could perhaps split it up into two longs which is kind of fugly. Another option would be to just= =20 generate a single long that holds raw nanoseconds uptime and store that (wrapping would be ok since I would only care about deltas). =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 20 16:00:49 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 22D4C8A9; Wed, 20 Aug 2014 16:00:49 +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 EE3B73085; Wed, 20 Aug 2014 16:00:48 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D1478B9D3; Wed, 20 Aug 2014 12:00:47 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: Common storage of original MAC address Date: Wed, 20 Aug 2014 11:43:04 -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: <201408201143.04150.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 20 Aug 2014 12:00:47 -0400 (EDT) Cc: "Pokala, Ravi" , Ryan Stone , Brooks Davis 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, 20 Aug 2014 16:00:49 -0000 On Tuesday, August 19, 2014 1:19:02 am Pokala, Ravi wrote: > Or how about an ioctl to get the original MAC (rather than a sysctl). Then > the "restore to default" code would be a two-step process - get the > original MAC with the new ioctl (say "SIOCGHWLLADDR" for "Get Hardware > LLADDR"?), and then set the working MAC to that value w/ the existing > ioctl (SIOCSIFLLADDR). > > I actually like this idea more than the sysctl, because it could be done > in one place (probably in net/if.c, next to if_setlladdr() (which is what > implements the guts of SIOCSIFLLADDR)). > > Does that sound like a plan? I prefer this approach as it preserves the original lladdr as an lladdr rather than a string. You could add something to ifconfig to display the hardware address (perhaps have ifconfig display it by default if it differs from the currently configured MAC) -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 20 16:00: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 4762D989 for ; Wed, 20 Aug 2014 16:00:51 +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 205473087 for ; Wed, 20 Aug 2014 16:00:51 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 04F4CB9D0; Wed, 20 Aug 2014 12:00:50 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: BTX halted on Proliant DL320 Gen8 v2's - fakeRAID support? Date: Wed, 20 Aug 2014 11:59:44 -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: <201408201159.44910.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 20 Aug 2014 12:00:50 -0400 (EDT) Cc: Karl Pielorz 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, 20 Aug 2014 16:00:51 -0000 On Thursday, August 14, 2014 9:59:28 am Karl Pielorz wrote: > > 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 Looks like the BIOS is mangling the stack somehow. cs holds the value of 'eflags', eip holds the value for 'cs', etc. 'efl' holds the value for 'esp', 'esp' holds 'ss', and 'ss' is set to 0. What is odd is that you didn't fault in boot2, only in the loader. Could you instrument the BIOS calls in sys/boot/i386/libi386/biosdisk.c to see which BIOS call is made that triggers the problem? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 20 16:09:20 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 9D87B88D; Wed, 20 Aug 2014 16:09:20 +0000 (UTC) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 29E7A3227; Wed, 20 Aug 2014 16:09:20 +0000 (UTC) Received: by mail-qc0-f181.google.com with SMTP id x13so7897371qcv.26 for ; Wed, 20 Aug 2014 09:09: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=ki2mw30V+fGcVo8XEMAMLTE76pajhtDHSI3T7Dgy+3M=; b=yKGXT7dyU6dYlwWAl+kp0ZTVX+ecSarktcmaq1GddP73ex96xWvMwtImQIO0hcpAPG YqetkE8cOY7Wd02cDBWNVuoS4uESAbAOS2bxLDkScaYCljUCeGuuEk7fqBq5Hs/AtceN oKFIetWBBo7XM5yXZRY7guPeMQvY8ye2oiSnEVY0Xgsp9oY1zKwM2ALIt1JnrecZZ64c GGxBqtpfgemrPUeYvr0q/ckERszQyi8syRYnHVIIOz28k8W1Aa/luU4UQOFx7c6oAQio 6FaflOGI0U+Jp+jwySK6Y2VSCZBESBNfR/3/SYv1aeLeUzO4XdmGvXKGvsCk6d6NV4LJ sQ3Q== MIME-Version: 1.0 X-Received: by 10.224.36.130 with SMTP id t2mr24677878qad.45.1408550959162; Wed, 20 Aug 2014 09:09:19 -0700 (PDT) Sender: hiren.panchasara@gmail.com Received: by 10.96.170.230 with HTTP; Wed, 20 Aug 2014 09:09:19 -0700 (PDT) In-Reply-To: References: Date: Wed, 20 Aug 2014 09:09:19 -0700 X-Google-Sender-Auth: hzKwrz1jv73fD5lg5Us_DMoxC3Q Message-ID: Subject: Re: FBSD 10.0 USB Memstick Loader hangs on HP EliteBook 2740p From: hiren panchasara To: CeDeROM Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , freebsd-sysinstall@freebsd.org, FreeBSD Questions Mailing List , freebsd-hardware@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, 20 Aug 2014 16:09:20 -0000 On Wed, Aug 20, 2014 at 12:29 AM, CeDeROM wrote: > Hello :-) > > Loader of the FreeBSD 10.0-RELEASE AMD64 hangs on load in random > moments when booting FreeBSD-10.0-RELEASE-amd64-memstick.img on HP > EliteBook 2740p. There is no problem on other machines, the problem > does not allow kernel to load and boot, I have tried other USB sticks, > BIOS update does not change anything. I have booted 64bit both Win7 > and Linux from USB drive with success. There is no optical drive, so > the only alternative would be to use pxe install, I will try the > loader and let you know back if this is anything USB related or rather > Loader/Hardware problem.. > > How the loader problem can be traced back? I can enter boot command prompt :-) > > Any hints appreciated :-) I am curious, are you trying legacy bios or uefi? and did you ever have freebsd successfully installed/running on this laptop? Trying to figure out of this is a regression. cheers, Hiren From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 20 16:13: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 DC339BB8; Wed, 20 Aug 2014 16:13:14 +0000 (UTC) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::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 73F643316; Wed, 20 Aug 2014 16:13:14 +0000 (UTC) Received: by mail-ob0-f172.google.com with SMTP id wn1so6456259obc.17 for ; Wed, 20 Aug 2014 09:13:13 -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=8fUlbypsNT1uPH+Ii0zmgrFEIc83ZvGNg5/+BJpZj0A=; b=pCC8DsBS6N4h7Bt5dzCj1f72RPLN1KPCQ1dB5GRl7+cM6kOoyGfPvgFOutzITvZ4M4 CIFds6G22btBNCD67NxDbk7JZ1rBqe56PLRdMvsPpLkALCYADMP808WWJcaQdYP34TqR /yhV57hGXgy43ICm1YECurC5b0XqYaJPVUWYkUuJSHWC6LVx3tFZZb+eX8OekZu9aAee GGxItrXSDK/WyUS7PXfyF/xsCD230feAvcS2Nq5KH2q1Wc5EFcrHqcICRML4nnEX5TG5 XfOZZAsDYtA66HVxlvcesAfD5A681nYdIm3kD2Cz/y6k/Qg11pvH1KRX+Jpm+CKgd7OX gIJQ== MIME-Version: 1.0 X-Received: by 10.182.68.104 with SMTP id v8mr50403712obt.26.1408551193753; Wed, 20 Aug 2014 09:13:13 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.202.75.15 with HTTP; Wed, 20 Aug 2014 09:13:13 -0700 (PDT) In-Reply-To: References: Date: Wed, 20 Aug 2014 18:13:13 +0200 X-Google-Sender-Auth: EsJl0Rhj_T9tlRn-n-BrY6cr2dU Message-ID: Subject: Re: FBSD 10.0 USB Memstick Loader hangs on HP EliteBook 2740p From: CeDeROM To: hiren panchasara Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , freebsd-sysinstall@freebsd.org, FreeBSD Questions Mailing List , freebsd-hardware@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, 20 Aug 2014 16:13:15 -0000 On Wed, Aug 20, 2014 at 6:09 PM, hiren panchasara wrote: > I am curious, are you trying legacy bios or uefi? and did you ever > have freebsd successfully installed/running on this laptop? Trying to > figure out of this is a regression. This is my new machine so never FreeBSD on it before, I know Win7 and Kali Linux 64bit works fine. I use Legacy BIOS boot. Should I try UEFI? I will try pxe boot and report back :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 20 17:29:23 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 A9E3AA42 for ; Wed, 20 Aug 2014 17:29:23 +0000 (UTC) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::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 34E2F3ADF for ; Wed, 20 Aug 2014 17:29:23 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id pi18so7514128lab.23 for ; Wed, 20 Aug 2014 10:29:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=tFVArgnPjsxJH5gGLMDve6wjDVFc04afUg5lS38fZLQ=; b=QeCVPh+wF6MWZ7JmZ4CfA97y06Sba/thp1BkdTZJ88et/wScFe/f5C09YN+S97MAXC TKQWFL4ov9/X6tFs2x86TO/eX+q/GKu5rn7mrmfzrSQ5ibGm8GFIKqgiIQSH/V3AppYA 85jVy/7FjoQUYjXAs+NUSAAoNK0653zoLYy5B8WtcKsOwMsMKByBIxQF6wCalXjElpaX LZm7o4aLHaB+yP+IH1PTyEVAHAJJKWhr20nyojNyAdWo7Q9Cj6yn5f7nhfQYPqXs5Ubd Qf3yffeoN2jKz9rv/W65o0Hq0x3TXiOx5V3S/acAP5UzpjrZsuPhDf2M38Ckb/u368JH 6Amg== X-Received: by 10.152.44.230 with SMTP id h6mr43801372lam.51.1408555760890; Wed, 20 Aug 2014 10:29:20 -0700 (PDT) MIME-Version: 1.0 Sender: argiopeweb@gmail.com Received: by 10.112.145.193 with HTTP; Wed, 20 Aug 2014 10:29:00 -0700 (PDT) From: Elliot Robinson Date: Wed, 20 Aug 2014 13:29:00 -0400 X-Google-Sender-Auth: b442-tYacosPIkVxYVzMsWwC8Ro Message-ID: Subject: root-on-ZFS - gptzfsboot fails to find pool To: freebsd-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, 20 Aug 2014 17:29:23 -0000 G'day all, A fresh root-on-ZFS install using bsdinstall's ZFS option on FreeBSD 10 fails to boot on my Dell Studio XPS 1640. Output at boot is gptzfsboot: error 1 lba 48 gptzfsboot: error 1 lba 1 gptzfsboot: No ZFS pools located, can't boot Things I've tried: * ZFS with GPT - Fails with error above * ZFS with MBR - Fails with no output (doesn't find 2nd stage?) * UFS with GPT - Works * Different HDD/SDD - No change, fails with error above * USB thumb drive on VirtualBox with ZFS/GPT - Works This system has not had FreeBSD on it before, though the guided partitioning UFS/GPT install seems to work as expected. I'm about at the point where I have to sprinkle printf's all through zfsboot.c and trace what's going on, so any help is appreciated. --- Elliot Robinson PGP Key: 9FEDE59A From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 20 17:30:02 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 55B65B30; Wed, 20 Aug 2014 17:30:02 +0000 (UTC) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::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 D62BC3AF4; Wed, 20 Aug 2014 17:30:01 +0000 (UTC) Received: by mail-qg0-f53.google.com with SMTP id z60so4215508qgd.40 for ; Wed, 20 Aug 2014 10:30:00 -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=ULXiMuX4K2q2Wqn97VzI+8jOf0ADOLkyW0puu69K5OE=; b=kUr4bpSF+clAc6XKp1NBLXLC9qJqr9wO1duy+T4l2OTppN4dx5dnOG/7Cu4hj+9rUW IgiRczHxu2KmiKcLPCgkcfKbtYjbn3h73/M6jUL25Bt6bGsu/g923n2fHIItEjlKKnwc cs2THr9+elTuiaX+CXjtZjHjOdaUUBq0nljDzpd+7ODgProTzMy63ufI53T3m2H9ZeTE xLgO/I9IQp4fdgG6B1LczuuL0qEHsaHA+84KFr0t/FZzAl/Sks5vCMY5qfAhzVFU5E3r a5W+twQEit633pn6SWX3azOH/XCbrv01h3oCPD+qlA6UfheQCzRxbdy0Su0gPWSRsexr GhGA== MIME-Version: 1.0 X-Received: by 10.229.229.135 with SMTP id ji7mr79975259qcb.15.1408555800827; Wed, 20 Aug 2014 10:30:00 -0700 (PDT) Sender: hiren.panchasara@gmail.com Received: by 10.96.170.230 with HTTP; Wed, 20 Aug 2014 10:30:00 -0700 (PDT) In-Reply-To: References: Date: Wed, 20 Aug 2014 10:30:00 -0700 X-Google-Sender-Auth: Nv7aI3JkhWcSAsUfUnsWi7wFogs Message-ID: Subject: Re: FBSD 10.0 USB Memstick Loader hangs on HP EliteBook 2740p From: hiren panchasara To: CeDeROM Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , freebsd-sysinstall , FreeBSD Questions Mailing List , freebsd-hardware 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, 20 Aug 2014 17:30:02 -0000 On Wed, Aug 20, 2014 at 9:13 AM, CeDeROM wrote: > On Wed, Aug 20, 2014 at 6:09 PM, hiren panchasara wrote: >> I am curious, are you trying legacy bios or uefi? and did you ever >> have freebsd successfully installed/running on this laptop? Trying to >> figure out of this is a regression. > > This is my new machine so never FreeBSD on it before, I know Win7 and > Kali Linux 64bit works fine. I use Legacy BIOS boot. Should I try > UEFI? I will try pxe boot and report back :-) Yeah, just for the hack of it, try UEFI and see. Fwiw, I have a HP folio 9470m laptop that I cannot boot with -CURRENT. In legacy bios, I see loader spinner and screen goes blank, laptop reboots itself. And sometimes it resets itself even before the spinner. In UEFI, I see other failures. More details at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192655 cheers, Hiren From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 20 17:33:25 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 436C1F49 for ; Wed, 20 Aug 2014 17:33:25 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 1C5893BA8 for ; Wed, 20 Aug 2014 17:33:24 +0000 (UTC) Received: from [192.168.1.2] (senat1-01.HML3.ScaleEngine.net [209.51.186.5]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 5720236D78 for ; Wed, 20 Aug 2014 17:33:23 +0000 (UTC) Message-ID: <53F4DBFC.2020604@freebsd.org> Date: Wed, 20 Aug 2014 13:33:48 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: root-on-ZFS - gptzfsboot fails to find pool References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9Dq7eb7MGos9LLF38ffV6VnfBKtPWHPbD" 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, 20 Aug 2014 17:33:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9Dq7eb7MGos9LLF38ffV6VnfBKtPWHPbD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-08-20 13:29, Elliot Robinson wrote: > G'day all, > A fresh root-on-ZFS install using bsdinstall's ZFS option on FreeBSD 10= > fails to boot on my Dell Studio XPS 1640. Output at boot is >=20 > gptzfsboot: error 1 lba 48 > gptzfsboot: error 1 lba 1 > gptzfsboot: No ZFS pools located, can't boot >=20 > Things I've tried: > * ZFS with GPT - Fails with error above > * ZFS with MBR - Fails with no output (doesn't find 2nd stage?) > * UFS with GPT - Works > * Different HDD/SDD - No change, fails with error above > * USB thumb drive on VirtualBox with ZFS/GPT - Works >=20 > This system has not had FreeBSD on it before, though the guided > partitioning UFS/GPT install seems to work as expected. >=20 > I'm about at the point where I have to sprinkle printf's all through > zfsboot.c and trace what's going on, so any help is appreciated. >=20 > --- > Elliot Robinson > PGP Key: 9FEDE59A > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 Boot off of the install cd again, and drop to a shell zpool import what does it say? --=20 Allan Jude --9Dq7eb7MGos9LLF38ffV6VnfBKtPWHPbD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJT9NwBAAoJEJrBFpNRJZKfgZ0P/R+OpAR44HyqPsxu6O2dGGQu NRzac420M58xzOtpvWqETclqtNyJ+TUxVzfSQHpZ+BXsv9bf2NfNiS/zfTsJpRt/ QxpKdcx9rZeA/KGKLqtUho2jlg2NalL1DhnhR+Oa/7jrZDDVval4kpUzDG6kh6VL vYohU6rJ8ifqtGYYVz8BMzBAhEwMyPXJTmrVTZVnkTArKa/vqHFQSfmlWNt2XamC u2Whols1KF3YMUNSv+0O2WBOCqRdFrIyCf9N1df2OVedByfYMZ46CQFAQJIqaTSO RGkaw4GBwSYIpkIUM/EYXHjcRqbv4PmqvrJzeRqLIoOFsyEGtJj8zASCpHcRCfmQ qTOW5mkIoDkZFXlOzgoirY1ZljjyBwgSKvGgtYlTcB2uh60hp/mlNxZWT3mFYdpR X25paG+0A8YPeBIgP2M8Bjsut7MEDH+g+pF62AVwMOAZYrxj+FEOziqkha/bpbco Lm+38Ro0tH/5mVfXkhc8OljhkU5jwTB3HqZhVO3evJsrTGQdRWUu3M0t98bOI4BA 3jxSUKZvpPIvenHxkfPvIi/KnmrsaHjXZ773m7c0/18toqE5PewXbQLv7UOvn1US mtqpdCP/WjjS4nTSerWgR1HrSmhUUbuIdnsmFqRxTF8E6/yaTYxIomJES8CiBNno oIUBK7wz90Rhxv16JC2A =YcwR -----END PGP SIGNATURE----- --9Dq7eb7MGos9LLF38ffV6VnfBKtPWHPbD-- From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 20 19:52: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 7FBBC80C for ; Wed, 20 Aug 2014 19:52:20 +0000 (UTC) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010: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 E686F3F90 for ; Wed, 20 Aug 2014 19:52:19 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id hz20so7863881lab.27 for ; Wed, 20 Aug 2014 12:52:17 -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:content-type; bh=Aw0bxnAq9FEXAXZakkkiwkoiKbDAyXROLCRGr67wnQ4=; b=be14IChPny9ab1Zp4/CjK28FSLq9uisYv4gAebscooSLj/HQnGRjOofGWnMBr8q5Wf 4x9TG/pcoQbcf+Y5mcqTGyupkEeZu+ZjSn0oZ55wQ6xRY/7iON+e3MzrCMLYih/dzFoN UgGDg9eLRF2++N9U29suH0K51+ETvS7H2lbT983amiXix7tCBb4c2z3xB8QjOf3ngPz9 BQ3/O9Ncb0Qdp5PgPUSp8tuUHTvYAS2ovArER5NjA1P21lOZGU7bDcw3uwzGzjBPcSBZ WRRZwZxmElUx7Ha/P+c3jd4IUBHjlqM5juEx+c3SjC9RbBJMKd4aOTDIHJ56tpxs7c9e 6raw== X-Received: by 10.112.156.10 with SMTP id wa10mr33355804lbb.68.1408564337794; Wed, 20 Aug 2014 12:52:17 -0700 (PDT) MIME-Version: 1.0 Sender: argiopeweb@gmail.com Received: by 10.112.145.193 with HTTP; Wed, 20 Aug 2014 12:51:57 -0700 (PDT) In-Reply-To: <53F4DBFC.2020604@freebsd.org> References: <53F4DBFC.2020604@freebsd.org> From: Elliot Robinson Date: Wed, 20 Aug 2014 15:51:57 -0400 X-Google-Sender-Auth: Vfnt2BqquzvZ0-xly6K1kcU9w7s Message-ID: Subject: Re: root-on-ZFS - gptzfsboot fails to find pool To: freebsd-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, 20 Aug 2014 19:52:20 -0000 On Wed, Aug 20, 2014 at 1:33 PM, Allan Jude wrote: > On 2014-08-20 13:29, Elliot Robinson wrote: > > G'day all, > > A fresh root-on-ZFS install using bsdinstall's ZFS option on FreeBSD 10 > > fails to boot on my Dell Studio XPS 1640. Output at boot is > > > > gptzfsboot: error 1 lba 48 > > gptzfsboot: error 1 lba 1 > > gptzfsboot: No ZFS pools located, can't boot > > > > Things I've tried: > > * ZFS with GPT - Fails with error above > > * ZFS with MBR - Fails with no output (doesn't find 2nd stage?) > > * UFS with GPT - Works > > * Different HDD/SDD - No change, fails with error above > > * USB thumb drive on VirtualBox with ZFS/GPT - Works > > > > This system has not had FreeBSD on it before, though the guided > > partitioning UFS/GPT install seems to work as expected. > > > > I'm about at the point where I have to sprinkle printf's all through > > zfsboot.c and trace what's going on, so any help is appreciated. > > > > --- > > Elliot Robinson > > PGP Key: 9FEDE59A > > _______________________________________________ > > 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" > > > > Boot off of the install cd again, and drop to a shell > > zpool import > > what does it say? > > -- > Allan Jude > > Apparently Linux doesn't like talking to UFS. Tried to pipe to a file on the USB drive and read from Linux, but I got inode errors... Then I tried to abuse dd to write to an empty sector from the shell and it complained about /dev/da0 being an invalid device. Just can't win... Find the output transcribed from a screenshot below. pool: zroot id: 4288135752309264711 state: ONLINE action: The pool can be imported using its name or numeric identifier zroot ONLINE gptid/6b458a8a-27dd-11e4-9075-002219ec1b41 ONLINE --- Elliot Robinson PGP Key: 9FEDE59A From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 20 20:52:42 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 5CB0FB65 for ; Wed, 20 Aug 2014 20:52:42 +0000 (UTC) Received: from mail-ig0-x244.google.com (mail-ig0-x244.google.com [IPv6:2607:f8b0:4001:c05::244]) (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 2FD2F3527 for ; Wed, 20 Aug 2014 20:52:42 +0000 (UTC) Received: by mail-ig0-f196.google.com with SMTP id l13so3564771iga.7 for ; Wed, 20 Aug 2014 13:52:41 -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=Ba5RfBC1i2MHqqxggIRi8ISzEUIo5aksG4gvtrBhnRo=; b=Gb9rRSns19F/FWNeGMXIenLQfxD3+Y7cgnwZ61Z6OGJhE7I/mGsys+7DoKC52e3toa zvy2kUqV7aFIV8LKahy+m/KHI01pWCsUzFYp5akxJxQZQgkLfYQ2NEBe26fXlR3t76LQ KKPhnWTMbdZz1nUyBOFZh8QOGnKxTYwLAwRkzPcNl2lEiUK/RgYfRGLI2fPw9x8cSWrY bO6wLdy0IUKo3BTiziiRH7g9ppB9bBOPrbsJ5NWnKXaTOAnHWkMpGkeux6ve7hwOVTDT hVdBL6dho9+BEulyFXc/9oHv75/izK9tF8zIYUcWK2IrTPMXPsRmGO9CPSLQg3oIzkph +pxQ== MIME-Version: 1.0 X-Received: by 10.42.83.81 with SMTP id g17mr49662525icl.45.1408567961690; Wed, 20 Aug 2014 13:52:41 -0700 (PDT) Received: by 10.64.26.130 with HTTP; Wed, 20 Aug 2014 13:52:41 -0700 (PDT) Date: Wed, 20 Aug 2014 13:52:41 -0700 Message-ID: Subject: Re: stopped processes using cpu? From: Dieter BSD To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-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, 20 Aug 2014 20:52:42 -0000 > whether or not the existing code is good or bad It has been awhile since I've looked at the code for firefox, but that code was OBSCENELY bad. :-( I fixed hundreds and hundreds and hundreds of bugs (yes, that many!) and it still didn't work (at all). The firefox idiots didn't believe my bug report. Code quality of top/ps/kernel? Look at the code and/or see how many open PRs there are. Firefox runs in a chroot, executables in a read-only partition. /etc/profile has ulimit -S -m 400000 ulimit -S -v 600000 after an incident where an "idle" firefox grew without bound kicking everything else out of memory including a small program running at rtprio logging true real-time data resulting in the loss of data. (the data buffer was mlocked, but the code wasn't. Silly me thinking that the kernel wouldn't page out a small loop that is constantly running.) Firefox is usually stopped when not being actively used. No plugins. Other web browsers (smaller, faster, more secure, less buggy, ...) are used whenever possible. Rootkit? Perhaps possible in theory, but very highly unlikely. CPU% decays as expected when processes are stopped (except for firefox). Firefox CPU% does not decay as expected, either running or stopped. I tried running a cpu-bound process in the same chroot as firefox, it decayed as expected when stopped. So firefox seems to be the only thing that this shows up on. And also seems to be the only thing with THR > 1. So try the -H option: PID UID PRI NICE SIZE RES STATE TIME WCPU COMMAND 92986 941 54 0 167M 63524K STOP 0:00 5.03% {firefox-bin} 92986 941 4 0 167M 63524K STOP 0:25 0.00% {initial thread} 92986 941 44 0 167M 63524K STOP 0:01 0.00% {firefox-bin} 92986 941 44 0 167M 63524K STOP 0:00 0.00% {firefox-bin} 92986 941 44 0 167M 63524K STOP 0:00 0.00% {firefox-bin} 92986 941 44 0 167M 63524K STOP 0:00 0.00% {firefox-bin} 92986 941 44 0 167M 63524K STOP 0:00 0.00% {firefox-bin} 33796 941 44 0 5248K 1200K ttyin 0:00 0.00% bash 92986 941 44 0 167M 63524K STOP 0:00 0.00% {firefox-bin} 92986 941 44 0 167M 63524K STOP 0:00 0.00% {firefox-bin} 92979 941 48 0 6184K 632K STOP 0:00 0.00% sh 92983 941 62 0 6208K 660K STOP 0:00 0.00% sh 92978 941 44 0 8296K 1372K STOP 0:00 0.00% sh PID UID PRI NICE SIZE RES STATE TIME WCPU COMMAND 44188 937 4 0 303M 187M STOP 104:11 12.65% {initial thread} 44188 937 44 0 303M 187M STOP 0:45 0.49% {firefox-bin} 44188 937 44 0 303M 187M STOP 8:19 0.29% {firefox-bin} 44188 937 44 0 303M 187M STOP 0:02 0.00% {firefox-bin} 44188 937 44 0 303M 187M STOP 0:01 0.00% {firefox-bin} 44188 937 44 0 303M 187M STOP 0:01 0.00% {firefox-bin} 44188 937 44 0 303M 187M STOP 0:00 0.00% {firefox-bin} 44188 937 44 0 303M 187M STOP 0:00 0.00% {firefox-bin} 44167 937 44 0 5248K 804K ttyin 0:00 0.00% bash 44181 937 76 0 6184K 632K STOP 0:00 0.00% sh 44185 937 76 0 6208K 664K STOP 0:00 0.00% sh 44188 937 60 0 303M 187M STOP 0:00 0.00% {firefox-bin} Any clues there? From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 20 20:57: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 C541CDE5 for ; Wed, 20 Aug 2014 20:57:13 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7524B3574 for ; Wed, 20 Aug 2014 20:57:13 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id s7KKv7wm099293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 20 Aug 2014 14:57:07 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id s7KKv7mS099286; Wed, 20 Aug 2014 14:57:07 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Wed, 20 Aug 2014 14:57:07 -0600 (MDT) From: Warren Block To: Elliot Robinson Subject: Re: root-on-ZFS - gptzfsboot fails to find pool In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Wed, 20 Aug 2014 14:57:07 -0600 (MDT) 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, 20 Aug 2014 20:57:13 -0000 On Wed, 20 Aug 2014, Elliot Robinson wrote: > G'day all, > A fresh root-on-ZFS install using bsdinstall's ZFS option on FreeBSD 10 > fails to boot on my Dell Studio XPS 1640. Output at boot is > > gptzfsboot: error 1 lba 48 > gptzfsboot: error 1 lba 1 > gptzfsboot: No ZFS pools located, can't boot This has come up in a few places lately. Could it be due to upgrading the pool but not updating the bootcode? From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 20 21:46:32 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 D13AA2B7 for ; Wed, 20 Aug 2014 21:46:32 +0000 (UTC) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::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 571163A28 for ; Wed, 20 Aug 2014 21:46:32 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id v6so7136640lbi.24 for ; Wed, 20 Aug 2014 14:46:30 -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:content-type; bh=k1q/6wv+gPJ4mFqGCdd81QCSY4hAGIFr0Rrj4zIKYCI=; b=t5FjhcCOzu60tm3SLXnMNFT4m5zIXIYmclDfzCxvel8U1KpIcvJCfVjUbiGm85jEip e1QmlzkJhikg0C9Ocz+8eRvUII4CtTbimpeWUFuKCZMyeIbczGmDDZ9j8Ddu3LXezgmD gVld0QnBKlPN5AbYzjFGDkYzm2+v9hEofeZPanTsEu9LZW1kPstI5U/0B/51GwjKsYIN EqrZ05yUpFBo2XO2PzxcIPB9fHBWfGF/RWSUh0BY6sBcjCoKqjmSfnOBLeQ/khlgN8P2 lAKZSAs/i9bv88eRWsLmgxSweqLW1hajCk75+QrxFXrU8OhR+f7dyQ6Ot9IcXCORRKqr CxeQ== X-Received: by 10.152.10.169 with SMTP id j9mr45515496lab.69.1408571190032; Wed, 20 Aug 2014 14:46:30 -0700 (PDT) MIME-Version: 1.0 Sender: argiopeweb@gmail.com Received: by 10.112.145.193 with HTTP; Wed, 20 Aug 2014 14:46:09 -0700 (PDT) In-Reply-To: References: From: Elliot Robinson Date: Wed, 20 Aug 2014 17:46:09 -0400 X-Google-Sender-Auth: QiEWbSHxW5BuARCHVsGKmDqX4vw Message-ID: Subject: Re: root-on-ZFS - gptzfsboot fails to find pool To: freebsd-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, 20 Aug 2014 21:46:33 -0000 On Wed, Aug 20, 2014 at 4:57 PM, Warren Block wrote: > On Wed, 20 Aug 2014, Elliot Robinson wrote: > > G'day all, >> A fresh root-on-ZFS install using bsdinstall's ZFS option on FreeBSD 10 >> fails to boot on my Dell Studio XPS 1640. Output at boot is >> >> gptzfsboot: error 1 lba 48 >> gptzfsboot: error 1 lba 1 >> gptzfsboot: No ZFS pools located, can't boot >> > > This has come up in a few places lately. Could it be due to upgrading the > pool but not updating the bootcode? > Possibly in some cases, but this is a fresh install of 10 from FreeBSD-10.0-RELEASE-amd64-memstick.img. I've recompiled/reinstalled the stage 2 bootcode from installed source (boot with the install media, `make` in zroot/usr/src/sys/boot). The generated gptzfsboot is identical according to cmp. Possible it's a regression from 9.2... Ah, I should mention. In the list of "Things I've Tried", we can also include "Install from 9.3 media", which failed with the same error. --- Elliot Robinson PGP Key: 9FEDE59A From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 20 23:09:33 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 68F696BB for ; Wed, 20 Aug 2014 23:09:33 +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 DCC033125 for ; Wed, 20 Aug 2014 23:09:32 +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 s7KN8qIO071687 for ; Thu, 21 Aug 2014 01:08:52 +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 s7KN8qBb071684 for ; Thu, 21 Aug 2014 01:08:52 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 21 Aug 2014 01:08:52 +0200 (CEST) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: syslog receiving data by UDP from windows with nxlog 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]); Thu, 21 Aug 2014 01:08:52 +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: Wed, 20 Aug 2014 23:09:33 -0000 i configured nxlog on windows machine to send logs to FreeBSD. checked with tcpdump windows actually send logs like this: 2014-08-21 00:50:17 winserver1 INFO 7036 Usluga nxlog weszla w stan uruchomienia. this way: 00:50:27.995832 IP 10.100.100.241.54774 > 10.100.100.1.514: [|syslog] syslogd is run this way /usr/sbin/syslogd -vn -b 10.100.100.1 -a 10.0.0.0/8 and syslog.conf is like this +* *.* -/var/log/messages nothing is logged. to test things - i configured syslog from other FreeBSD computer to send logs to 10.100.100.1 - works fine. what is wrong? From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 20 23:20:40 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 5559396A for ; Wed, 20 Aug 2014 23:20:40 +0000 (UTC) Received: from tds-solutions.net (tds-solutions.net [192.99.32.153]) by mx1.freebsd.org (Postfix) with ESMTP id 2ECA03232 for ; Wed, 20 Aug 2014 23:20:39 +0000 (UTC) Received: from tds-solutions.net (localhost [127.0.0.1]) by tds-solutions.net (Postfix) with ESMTP id 117063B099 for ; Wed, 20 Aug 2014 19:20:36 -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 u-K_4IC7blVy for ; Wed, 20 Aug 2014 19:20:25 -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 B5BE43B097 for ; Wed, 20 Aug 2014 19:20:25 -0400 (EDT) Message-ID: <53F52D45.7070405@tysdomain.com> Date: Wed, 20 Aug 2014 19:20:37 -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: hackers@freebsd.org Subject: Making this Makefile work on FreeBSD 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: Wed, 20 Aug 2014 23:20:40 -0000 Hello all: I'd really like to be able to say that this compiles with FreeBSD. when I use make, there are some issues; would anyone be able to look at this perhaps and provide some pointers for making this compile both on Linux and FreeBSD? Thanks, https://github.com/sorressean/Aspen/blob/master/src/Makefile -- 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 Wed Aug 20 23:21:48 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 8A08EA4B for ; Wed, 20 Aug 2014 23:21:48 +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 C3DD432BA for ; Wed, 20 Aug 2014 23:21:45 +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 s7KNLCu2071738 for ; Thu, 21 Aug 2014 01:21:12 +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 s7KNLCng071735 for ; Thu, 21 Aug 2014 01:21:12 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 21 Aug 2014 01:21:12 +0200 (CEST) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: Re: syslog receiving data by UDP from windows with nxlog In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (wojtek.tensor.gdynia.pl [127.0.0.1]); Thu, 21 Aug 2014 01:21:12 +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: Wed, 20 Aug 2014 23:21:48 -0000 fix. after adding bsd module to nxlog it outputs like <14>Aug 21 01:19:49 winserver1 Service_Control_Manager[460]: Us#<82>uga nxlog wesz#<82>a w stan zatrzymania. STILL syslogd writes nothing any ideas? On Thu, 21 Aug 2014, Wojciech Puchar wrote: > i configured nxlog on windows machine to send logs to FreeBSD. > > checked with tcpdump windows actually send logs like this: > > 2014-08-21 00:50:17 winserver1 INFO 7036 Usluga nxlog weszla w stan > uruchomienia. > > this way: > > 00:50:27.995832 IP 10.100.100.241.54774 > 10.100.100.1.514: [|syslog] > > syslogd is run this way > /usr/sbin/syslogd -vn -b 10.100.100.1 -a 10.0.0.0/8 > > and syslog.conf is like this > > > +* > *.* -/var/log/messages > > > nothing is logged. > > to test things - i configured syslog from other FreeBSD computer to send logs > to 10.100.100.1 - works fine. > > > what is wrong? > _______________________________________________ > 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 Wed Aug 20 23:22: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 7A582B6D for ; Wed, 20 Aug 2014 23:22:34 +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 4E76F32F1 for ; Wed, 20 Aug 2014 23:22:34 +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 1XKFD6-000DkQ-Lw; Wed, 20 Aug 2014 23:22:32 +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 s7KNMVWI054538; Wed, 20 Aug 2014 17:22:31 -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: U2FsdGVkX190SLZBjPXFYFVoxQah9dFB X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: syslog receiving data by UDP from windows with nxlog From: Ian Lepore To: Wojciech Puchar In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 Aug 2014 17:22:30 -0600 Message-ID: <1408576950.1150.16.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit 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, 20 Aug 2014 23:22:34 -0000 On Thu, 2014-08-21 at 01:08 +0200, Wojciech Puchar wrote: > i configured nxlog on windows machine to send logs to FreeBSD. > > checked with tcpdump windows actually send logs like this: > > 2014-08-21 00:50:17 winserver1 INFO 7036 Usluga nxlog weszla w stan uruchomienia. > > this way: > > 00:50:27.995832 IP 10.100.100.241.54774 > 10.100.100.1.514: [|syslog] > > syslogd is run this way > /usr/sbin/syslogd -vn -b 10.100.100.1 -a 10.0.0.0/8 > > and syslog.conf is like this > > > +* > *.* -/var/log/messages > > > nothing is logged. > > to test things - i configured syslog from other FreeBSD computer to send > logs to 10.100.100.1 - works fine. > > > what is wrong? > _______________________________________________ > 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" In /etc/defaults/rc.conf is 'syslogd_flags="-s"' which prevents connections from other machines (so that your syslogd doesn't become a remote disk-filling service). The syslogd(8) manpage will show you what you need to set instead to allow packets from that other machine. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 20 23:24: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 EFC70C6A; Wed, 20 Aug 2014 23:24:30 +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 97BC13306; Wed, 20 Aug 2014 23:24:27 +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 s7KNNohL071783; Thu, 21 Aug 2014 01:23:50 +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 s7KNNo5R071780; Thu, 21 Aug 2014 01:23:50 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 21 Aug 2014 01:23:50 +0200 (CEST) From: Wojciech Puchar To: Ian Lepore Subject: Re: syslog receiving data by UDP from windows with nxlog In-Reply-To: <1408576950.1150.16.camel@revolution.hippie.lan> Message-ID: References: <1408576950.1150.16.camel@revolution.hippie.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (wojtek.tensor.gdynia.pl [127.0.0.1]); Thu, 21 Aug 2014 01:23:50 +0200 (CEST) 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, 20 Aug 2014 23:24:31 -0000 >> +* >> *.* -/var/log/messages >> >> >> nothing is logged. >> >> to test things - i configured syslog from other FreeBSD computer to send >> logs to 10.100.100.1 - works fine. >> >> >> what is wrong? >> _______________________________________________ >> 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" > > In /etc/defaults/rc.conf is 'syslogd_flags="-s"' which prevents > connections from other machines (so that your syslogd doesn't become a > remote disk-filling service). The syslogd(8) manpage will show you what > you need to set instead to allow packets from that other machine. this is already done syslogd_enable="YES" # Run syslog daemon (or NO). syslogd_flags="-vn -b 10.100.100.1 -a 10.0.0.0/8" # Flags to syslogd (if enabled). From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 21 00:08:19 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 D30A014B for ; Thu, 21 Aug 2014 00:08:19 +0000 (UTC) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (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 6302536E7 for ; Thu, 21 Aug 2014 00:08:19 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id a1so8326302wgh.11 for ; Wed, 20 Aug 2014 17:08:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=uWUZfdIoMzfZewz4ca67pGhrlov16ZwO5j+MYCnfXU8=; b=O8WR36BWMuSC+KeMVHZDoKTiqla7W1cKSKcTxubA96/pF8OzjwYD6vLMTRrio61cGe HJqJ9xDrhpS28u66hoC+qDmgHCGftp/tMBem2A23K38lOwHzdyTcuDc7edGQpPiG11B/ VJPHhWcu55MRcgkDm8J7lm1Onpngjj8fYMQqWowpN8RtixkOauKJtZ6FNxvqFLpoxal6 SegvwNDZ+Pc6OvNRZ5aFkWlDk5qcPn1JSdnfDtJL6BgtTE1jh+LRHsOwi9XWHlJT/G9K sejDjpkyiPPjS6p/cQ5gYp+Lsg8Tta6pJlgdOYTNiiMDKWPX8wIhAt2Way9naK3OdicT chWQ== X-Gm-Message-State: ALoCoQmh9GBldbgLBmn4yDstL6bNHh9GnKFF8OuFmDdcBnPmQq3+fLSLv6yGDkSsqpg1AZwPQuia X-Received: by 10.194.186.178 with SMTP id fl18mr52160909wjc.8.1408573183583; Wed, 20 Aug 2014 15:19:43 -0700 (PDT) Received: from raynote.ddteam.net (70-77-133-95.pool.ukrtel.net. [95.133.77.70]) by mx.google.com with ESMTPSA id ex2sm61689253wjd.30.2014.08.20.15.19.41 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Aug 2014 15:19:42 -0700 (PDT) Date: Thu, 21 Aug 2014 01:17:29 +0300 From: Aleksandr Rybalko To: Stefan Esser Subject: Re: Keymap definitions for VT / NEWCONS Message-Id: <20140821011729.164752be8fa135baf35ebf9d@ddteam.net> In-Reply-To: <53F1146B.8020906@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> <53F1146B.8020906@freebsd.org> X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , Ed Maste 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, 21 Aug 2014 00:08:20 -0000 On Sun, 17 Aug 2014 22:45:31 +0200 Stefan Esser wrote: > Am 15.08.2014 um 17:30 schrieb Ed Maste: > 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 > > Ok, I've been convinced that this is the better scheme than > the one based on locale names, which I used to prefer. > > And if fact, I've only needed one "complex" name: "ch-fr" > (I chose "ch" instead of "ch-de", since that is the typical > layout used in Switzerland - I've yet to see a Swiss-French > keyboard in an actual system ...). > > Quite a number of keymaps are still waiting to be verified > and committed. Many are derived from different encodings that > should lead to the same Unicode characters, in an ideal world. > > I've spent all day on writing the converter scripts (for the > INDEX.keymaps file and for the keymaps) and verified as many > results as I could, but there's still a lot of work left ... > > Best regards, STefan > _______________________________________________ > 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" Hi guys! My very late $0.02. We all, who use locale different from 'C' or maybe 'en_US' very long time know name of our prefered locale (from Xorg apps, from browser charset/locale settings). And now pair of lang_COUNTRY don't looks something unfamiliar to almost all ppls, so scheme lang_COUNTRY indeed best. We should just provide good description for this code on selection - 'en_US (English, USA)'. Thanks! WBW -- Aleksandr Rybalko From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 21 01:49: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 80656BC5 for ; Thu, 21 Aug 2014 01:49:33 +0000 (UTC) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (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 42EEF3089 for ; Thu, 21 Aug 2014 01:49:33 +0000 (UTC) Received: by mail-qg0-f45.google.com with SMTP id f51so8211730qge.32 for ; Wed, 20 Aug 2014 18:49:32 -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=TiJOTEhrDDYtJ53ZG7G8b5CPT5jLGBHfG7lKc4+xfG4=; b=Sd3Thlaexaf8LBMpUtTdjPWWO4ro1lVo8JUKqpGxYKUaf1m/A2YwXV5gGDG+DOoDoJ h9/8WiWVKyjPauZCe3JggOAsfiMcSIO6BamRqr6103ceRHPE5TqwOz3HsKmiIjS7b3km IjWRsvnqFoJX7eGlnds4HseTrluF32Y4UvuOcqn/mhGDKllZBfPhoGXGqjlOdohkjvi6 ptuuY6umfZLCYbVnvpnpjWqNmRpEX8pKEE+CKO7cWHr1iddbinoXRu8vFoMH+dJptv00 rNwQzLQz/MFpumMpNy6Q3UFu/XCFhziChyj1va2q09Sb1r3nuikPkG66v/yjkcTcI7l/ ponw== MIME-Version: 1.0 X-Received: by 10.224.36.4 with SMTP id r4mr13574864qad.69.1408585772312; Wed, 20 Aug 2014 18:49:32 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.39.139 with HTTP; Wed, 20 Aug 2014 18:49:32 -0700 (PDT) In-Reply-To: <53F52D45.7070405@tysdomain.com> References: <53F52D45.7070405@tysdomain.com> Date: Wed, 20 Aug 2014 18:49:32 -0700 X-Google-Sender-Auth: uOULOQKfQSf_iiJuk0tQlPDqb-U Message-ID: Subject: Re: Making this Makefile work on FreeBSD From: Adrian Chadd To: tyler@tysdomain.com 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: Thu, 21 Aug 2014 01:49:33 -0000 It's a gmake file. Just install / run gmake. -a On 20 August 2014 16:20, Littlefield, Tyler wrote: > Hello all: > I'd really like to be able to say that this compiles with FreeBSD. when I > use make, there are some issues; would anyone be able to look at this > perhaps > and provide some pointers for making this compile both on Linux and FreeBSD? > Thanks, > https://github.com/sorressean/Aspen/blob/master/src/Makefile > > -- > 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. > > _______________________________________________ > 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 Thu Aug 21 07:13:05 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 332FB3AE; Thu, 21 Aug 2014 07:13:05 +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 8BD773FD6; Thu, 21 Aug 2014 07:13:04 +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 s7L7CWG3073219; Thu, 21 Aug 2014 09:12:32 +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 s7L7CWhp073216; Thu, 21 Aug 2014 09:12:32 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 21 Aug 2014 09:12:32 +0200 (CEST) From: Wojciech Puchar To: Ian Lepore Subject: Re: syslog receiving data by UDP from windows with nxlog In-Reply-To: Message-ID: References: <1408576950.1150.16.camel@revolution.hippie.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (wojtek.tensor.gdynia.pl [127.0.0.1]); Thu, 21 Aug 2014 09:12:32 +0200 (CEST) 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: Thu, 21 Aug 2014 07:13:05 -0000 what is the difference when logging this <38>Aug 21 09:09:09 login: login from 10.100.101.110 on pts/0 as root which is properly logged over UDP (from other unix host) and this <14>Aug 21 01:43:44 winserver1 Microsoft-Windows-GroupPolicy[936]: Okresowe przetwarzanie zasad dla u##ytkownika winserver1\ostrowska zosta#<82>o uko#<84>czone w czasie 0 s. which is not? what syslog is refusing and why? is there any syslog option to check it why? On Thu, 21 Aug 2014, Wojciech Puchar wrote: >>> +* >>> *.* -/var/log/messages >>> >>> >>> nothing is logged. >>> >>> to test things - i configured syslog from other FreeBSD computer to send >>> logs to 10.100.100.1 - works fine. >>> >>> >>> what is wrong? >>> _______________________________________________ >>> 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" >> >> In /etc/defaults/rc.conf is 'syslogd_flags="-s"' which prevents >> connections from other machines (so that your syslogd doesn't become a >> remote disk-filling service). The syslogd(8) manpage will show you what >> you need to set instead to allow packets from that other machine. > > this is already done > > syslogd_enable="YES" # Run syslog daemon (or NO). > syslogd_flags="-vn -b 10.100.100.1 -a 10.0.0.0/8" # Flags to > syslogd (if enabled). > > _______________________________________________ > 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 Thu Aug 21 07:29: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 DF9A6713; Thu, 21 Aug 2014 07:29:57 +0000 (UTC) Received: from mailout10.t-online.de (mailout10.t-online.de [194.25.134.21]) (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 6093F30F0; Thu, 21 Aug 2014 07:29:56 +0000 (UTC) Received: from fwd30.aul.t-online.de (fwd30.aul.t-online.de [172.20.26.135]) by mailout10.t-online.de (Postfix) with SMTP id 934C8185131; Thu, 21 Aug 2014 09:29:48 +0200 (CEST) Received: from [192.168.119.33] (G-bQkgZO8hpSqvHp05rVeVo5ue+jSdmYt+LZbYJOTvtT9ozn8GsZS5I8gHakmFZQHm@[84.154.101.219]) by fwd30.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XKMoe-1vP4gS0; Thu, 21 Aug 2014 09:29:48 +0200 Message-ID: <53F59FE3.7030802@freebsd.org> Date: Thu, 21 Aug 2014 09:29:39 +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: "freebsd-hackers@freebsd.org" , freebsd-doc@freebsd.org Subject: [PATCH] Missing references to vt(4) "NEWCONS" in man-pages Content-Type: multipart/mixed; boundary="------------040809060603010803070603" X-ID: G-bQkgZO8hpSqvHp05rVeVo5ue+jSdmYt+LZbYJOTvtT9ozn8GsZS5I8gHakmFZQHm X-TOI-MSGID: f6474afb-bf5f-4d12-aaff-a6f6ab7d06fb 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, 21 Aug 2014 07:29:58 -0000 This is a multi-part message in MIME format. --------------040809060603010803070603 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, the attached patch, also available from http://people.freebsd.org/~se/MAN-VT.diff contains changes to man pages that reference syscons(4), but so far do not mention vt(4). This should be fixed for 10.1, where vt(4) is in the GENERIC kernel. The following man-pages have been identified to contain references to syscons(4): share/man/man4/atkbd.4 share/man/man4/kbdmux.4 share/man/man4/splash.4 share/man/man4/terasic_mtl.4 (does this driver work with vt???) share/man/man4/ukbd.4 share/man/man4/vga.4 share/man/man4/vkbd.4 share/man/man4/vt.4 share/man/man5/rc.conf.5 share/man/man7/hier.7 share/man/man8/nanobsd.8 sbin/conscontrol/conscontrol.8 usr.bin/lock/lock.1 usr.sbin/bsdconfig/bsdconfig.8 usr.sbin/bsdinstall/bsdinstall.8 usr.sbin/kbdcontrol/kbdcontrol.1 usr.sbin/kbdcontrol/kbdmap.5 usr.sbin/kbdmap/kbdmap.1 usr.sbin/vidcontrol/vidcontrol.1 (Some of the diffs describe changes that are in -STABLE and will be committed to 10-STABLE in time for 10.1, to 9-STABLE after the release of 10.1.) The patch adds "or vt(4)" or mentions changed file paths or conventions. Please review and report any problems with the patch. The diff to bsdconfig is not complete, it does just mention places that need fixing. But in the case of bsdconfig, it does not suffice to fix the man-page, since that utility embeds knowledge about details of the system (e.g. the available fonts) and needs major adjustments. Please send any remarks also to my address, since I'm not subscribed to the freebsd-doc list. I'm including Tim Kienzle (for bsdconfig) and Robert Watson (because of the question whether terasic_mtl supports vt) in the CC list. Best regards, STefan --------------040809060603010803070603 Content-Type: text/plain; charset=windows-1252; name="MAN-VT.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="MAN-VT.diff" SW5kZXg6IHNoYXJlL21hbi9tYW40L2F0a2JkLjQKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2hhcmUv bWFuL21hbjQvYXRrYmQuNAkocmV2aXNpb24gMjcwMjQ0KQorKysgc2hhcmUvbWFuL21hbjQv YXRrYmQuNAkod29ya2luZyBjb3B5KQpAQCAtNTEsNyArNTEsOSBAQAogd2hpY2ggaXMgY29u bmVjdGVkIHRvIHRoZSBBVCBrZXlib2FyZCBjb250cm9sbGVyLgogLlBwCiBUaGlzIGRyaXZl ciBpcyByZXF1aXJlZCBmb3IgdGhlIGNvbnNvbGUgZHJpdmVyCi0uWHIgc3lzY29ucyA0IC4K Ky5YciBzeXNjb25zIDQgCitvciAKKy5YciB2dCA0IC4KIC5QcAogVGhlcmUgY2FuIGJlIG9u bHkgb25lCiAuTm0KQEAgLTIxMSw2ICsyMTMsNyBAQAogLlhyIGF0a2JkYyA0ICwKIC5YciBw c20gNCAsCiAuWHIgc3lzY29ucyA0ICwKKy5YciB2dCA0ICwKIC5YciBrYmRtYXAgNSAsCiAu WHIgbG9hZGVyIDgKIC5TaCBISVNUT1JZCkluZGV4OiBzaGFyZS9tYW4vbWFuNC9rYmRtdXgu NAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ci0tLSBzaGFyZS9tYW4vbWFuNC9rYmRtdXguNAkocmV2aXNpb24g MjcwMjQ0KQorKysgc2hhcmUvbWFuL21hbjQva2JkbXV4LjQJKHdvcmtpbmcgY29weSkKQEAg LTM1LDYgKzM1LDcgQEAKIC5YciBhdGtiZCA0ICwKIC5YciBzeXNjb25zIDQgLAogLlhyIHVr YmQgNAorLlhyIHZ0IDQgLAogLlNoIEhJU1RPUlkKIFRoZQogLk5tCkluZGV4OiBzaGFyZS9t YW4vbWFuNC9zcGxhc2guNAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzaGFyZS9tYW4vbWFuNC9zcGxh c2guNAkocmV2aXNpb24gMjcwMjQ0KQorKysgc2hhcmUvbWFuL21hbjQvc3BsYXNoLjQJKHdv cmtpbmcgY29weSkKQEAgLTI0NSw2ICsyNDUsNyBAQAogLlhyIHZpZGNvbnRyb2wgMSAsCiAu WHIgc3lzY29ucyA0ICwKIC5YciB2Z2EgNCAsCisuXCIgLlhyIHZ0IDQgLAogLlhyIGxvYWRl ci5jb25mIDUgLAogLlhyIHJjLmNvbmYgNSAsCiAuWHIga2xkbG9hZCA4ICwKQEAgLTI4NSw2 ICsyODYsOCBAQAogLlNoIENBVkVBVFMKIEJvdGggdGhlIHNwbGFzaCBzY3JlZW4gYW5kIHRo ZSBzY3JlZW4gc2F2ZXIgd29yayB3aXRoCiAuWHIgc3lzY29ucyA0CisuXCIgb3IKKy5cIiAu WHIgdnQgNAogb25seS4KIC5TaCBCVUdTCiBJZiB5b3UgbG9hZCBhIHNjcmVlbiBzYXZlciB3 aGlsZSBhbm90aGVyIHNjcmVlbiBzYXZlciBoYXMgYWxyZWFkeQpJbmRleDogc2hhcmUvbWFu L21hbjQvdGVyYXNpY19tdGwuNAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzaGFyZS9tYW4vbWFuNC90 ZXJhc2ljX210bC40CShyZXZpc2lvbiAyNzAyNDQpCisrKyBzaGFyZS9tYW4vbWFuNC90ZXJh c2ljX210bC40CSh3b3JraW5nIGNvcHkpCkBAIC02Niw2ICs2Niw4IEBACiAuTm0KIGRldmlj ZXMgYXJlIGFsc28gYXR0YWNoZWQgdG8gdGhlCiAuWHIgc3lzY29ucyA0CisuXCIgb3IKKy5c IiAuWHIgdnQgNAogZnJhbWV3b3JrLCB3aGljaCBpbXBsZW1lbnRzIGEgVlQtY29tcGF0aWJs ZSB0ZXJtaW5hbCBjb25uZWN0ZWQgdG8gdGhlCiAuWHIgdHR5IDQKIGZyYW1ld29yay4KQEAg LTkxLDYgKzkzLDcgQEAKIC5YciB3cml0ZSAyICwKIC5YciBzeXNjb25zIDQgLAogLlhyIHR0 eSA0ICwKKy5cIiAuWHIgdnQgNCAsCiAuWHIgdHR5cyA1CiAuU2ggSElTVE9SWQogVGhlCkBA IC0xMTEsNiArMTE0LDcgQEAKIC5TaCBCVUdTCiBUaGUKIC5YciBzeXNjb25zIDQKKy5cIiB3 aGF0IGFib3V0IE5FV0NPTlM/Pz8gLlhyIHZ0IDQKIGF0dGFjaG1lbnQgZG9lcyBub3Qgc3Vw cG9ydCB0aGUgaGFyZHdhcmUgY3Vyc29yIGZlYXR1cmUuCiAuUHAKIEEgbW9yZSBzdHJ1Y3R1 cmVkIGludGVyZmFjZSB0byBjb250cm9sIHJlZ2lzdGVycyB1c2luZyB0aGUKSW5kZXg6IHNo YXJlL21hbi9tYW40L3VrYmQuNAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzaGFyZS9tYW4vbWFuNC91 a2JkLjQJKHJldmlzaW9uIDI3MDI0NCkKKysrIHNoYXJlL21hbi9tYW40L3VrYmQuNAkod29y a2luZyBjb3B5KQpAQCAtMTI3LDcgKzEyNyw5IEBACiBUaGUgYWJvdmUgbGluZXMgd2lsbCBw dXQgdGhlIEZyZW5jaCBJU08ga2V5bWFwIGluIHRoZSB1a2JkIGRyaXZlci4KIFlvdSBjYW4g c3BlY2lmeSBhbnkga2V5bWFwIGluCiAuUGEgL3Vzci9zaGFyZS9zeXNjb25zL2tleW1hcHMK LXdpdGggdGhpcyBvcHRpb24uCitvcgorLlBhIC91c3Ivc2hhcmUvdnQva2V5bWFwcworKGRl cGVuZGluZyBvbiB0aGUgY29uc29sZSBkcml2ZXIgYmVpbmcgdXNlZCkgd2l0aCB0aGlzIG9w dGlvbi4KIC5QcAogLkQxIENkICJvcHRpb25zIEtCRF9ESVNBQkxFX0tFWU1BUF9MT0FESU5H IgogLlBwCkBAIC0xNTEsNiArMTUzLDcgQEAKIC5YciBzeXNjb25zIDQgLAogLlhyIHVoY2kg NCAsCiAuWHIgdXNiIDQgLAorLlhyIHZ0IDQgLAogLlhyIGNvbmZpZyA4CiAuU2ggQVVUSE9S UwogLkFuIC1ub3NwbGl0CkluZGV4OiBzaGFyZS9tYW4vbWFuNC92Z2EuNAo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09Ci0tLSBzaGFyZS9tYW4vbWFuNC92Z2EuNAkocmV2aXNpb24gMjcwMjQ0KQorKysgc2hh cmUvbWFuL21hbjQvdmdhLjQJKHdvcmtpbmcgY29weSkKQEAgLTUxLDcgKzUxLDkgQEAKIGRy aXZlciBpcyBhIGdlbmVyaWMgdmlkZW8gY2FyZCBkcml2ZXIgd2hpY2ggcHJvdmlkZXMgYWNj ZXNzIHRvCiB2aWRlbyBjYXJkcy4KIFRoaXMgZHJpdmVyIGlzIHJlcXVpcmVkIGZvciB0aGUg Y29uc29sZSBkcml2ZXIKLS5YciBzeXNjb25zIDQgLgorLlhyIHN5c2NvbnMgNAorb3IKKy5Y ciB2dCA0IC4KIFRoZSBjb25zb2xlIGRyaXZlciB3aWxsIGNhbGwgdGhlCiAuTm0KIGRyaXZl ciB0byBtYW5pcHVsYXRlIHZpZGVvIGhhcmR3YXJlIChjaGFuZ2luZyB2aWRlbyBtb2Rlcywg bG9hZGluZyBmb250LCBldGMpLgpAQCAtMTI0LDcgKzEyNiw5IEBACiAuRHYgU0NfQUxUX01P VVNFX0lNQUdFCiBvcHRpb24uCiBTZWUKLS5YciBzeXNjb25zIDQgLgorLlhyIHN5c2NvbnMg NCAKK29yCisuWHIgdnQgNCAuCiAuSXQgRHYgVkdBX05PX01PREVfQ0hBTkdFCiBUaGlzIG9w dGlvbiBwcmV2ZW50cyB0aGUgZHJpdmVyIGZyb20gY2hhbmdpbmcgdmlkZW8gbW9kZXMuCiAu RWwKQEAgLTE2MCw2ICsxNjQsNyBAQAogLlNoIFNFRSBBTFNPCiAuWHIgdmdsIDMgLAogLlhy IHN5c2NvbnMgNCAsCisuWHIgdnQgNCAsCiAuWHIgY29uZmlnIDggLAogLlhyIGtsZGxvYWQg OCAsCiAuWHIga2xkdW5sb2FkIDgKSW5kZXg6IHNoYXJlL21hbi9tYW40L3ZrYmQuNAo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09Ci0tLSBzaGFyZS9tYW4vbWFuNC92a2JkLjQJKHJldmlzaW9uIDI3MDI0NCkK KysrIHNoYXJlL21hbi9tYW40L3ZrYmQuNAkod29ya2luZyBjb3B5KQpAQCAtMTI5LDcgKzEy OSw4IEBACiAuWHIga2JkY29udHJvbCAxICwKIC5YciBhdGtiZGMgNCAsCiAuWHIgcHNtIDQg LAotLlhyIHN5c2NvbnMgNAorLlhyIHN5c2NvbnMgNCAsCisuWHIgdnQgNAogLlNoIEhJU1RP UlkKIFRoZQogLk5tCkluZGV4OiBzaGFyZS9tYW4vbWFuNC92dC40Cj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K LS0tIHNoYXJlL21hbi9tYW40L3Z0LjQJKHJldmlzaW9uIDI3MDI0NCkKKysrIHNoYXJlL21h bi9tYW40L3Z0LjQJKHdvcmtpbmcgY29weSkKQEAgLTIxMSw3ICsyMTEsNyBAQAogRGVmYXVs dCBpcyAxNSwgYWxsIGVuYWJsZWQuCiAuRWwKIC5TaCBGSUxFUwotLkJsIC10YWcgLXdpZHRo IC91c3Ivc2hhcmUvc3lzY29ucy9rZXltYXBzLyogLWNvbXBhY3QKKy5CbCAtdGFnIC13aWR0 aCAvdXNyL3NoYXJlL3Z0L2tleW1hcHMvKiAtY29tcGFjdAogLkl0IFBhIC9kZXYvY29uc29s ZQogLkl0IFBhIC9kZXYvY29uc29sZWN0bAogLkl0IFBhIC9kZXYvdHR5dioKSW5kZXg6IHNo YXJlL21hbi9tYW41L3JjLmNvbmYuNQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzaGFyZS9tYW4vbWFu NS9yYy5jb25mLjUJKHJldmlzaW9uIDI3MDI0NCkKKysrIHNoYXJlL21hbi9tYW41L3JjLmNv bmYuNQkod29ya2luZyBjb3B5KQpAQCAtMzExMSw4ICszMTExLDEzIEBACiBJZiBzZXQgdG8K IC5EcSBMaSBOTyAsCiBubyBrZXltYXAgaXMgaW5zdGFsbGVkLCBvdGhlcndpc2UgdGhlIHZh bHVlIGlzIHVzZWQgdG8gaW5zdGFsbAotdGhlIGtleW1hcCBmaWxlIGluCi0uUGEgL3Vzci9z aGFyZS9zeXNjb25zL2tleW1hcHMvIE5zIEFvIEFyIHZhbHVlIEFjIE5zIFBhIC5rYmQgLgor dGhlIGtleW1hcCBmaWxlIGZvdW5kIGluCisuUGEgL3Vzci9zaGFyZS9zeXNjb25zL2tleW1h cHMvIE5zIEFvIEFyIHZhbHVlIEFjIE5zIFBhIC5rYmQgCisoaWYgdXNpbmcgCisuWHIgc3lz Y29ucyA0ICkgb3IKKy5QYSAvdXNyL3NoYXJlL3Z0L2tleW1hcHMvIE5zIEFvIEFyIHZhbHVl IEFjIE5zIFBhIC5rYmQgCisoaWYgdXNpbmcKKy5YciB2dCA0ICkgLgogLkl0IFZhIGtleXJh dGUKIC5QcSBWdCBzdHIKIFRoZSBrZXlib2FyZCByZXBlYXQgc3BlZWQuCkBAIC0zMTQ3LDYg KzMxNTIsOSBAQAogbm8gc2NyZWVuIG1hcCBpcyBpbnN0YWxsZWQsIG90aGVyd2lzZSB0aGUg dmFsdWUgaXMgdXNlZCB0byBpbnN0YWxsCiB0aGUgc2NyZWVuIG1hcCBmaWxlIGluCiAuUGEg L3Vzci9zaGFyZS9zeXNjb25zL3Njcm5tYXBzLyBOcyBBcSBBciB2YWx1ZSAuCitUaGlzIHBh cmFtZXRlciBpcyBpZ25vcmVkIHdoZW4gdXNpbmcgCisuWHIgdnQgNCAKK2FzIHRoZSBjb25z b2xlIGRyaXZlci4KIC5JdCBWYSBmb250OHgxNgogLlBxIFZ0IHN0cgogSWYgc2V0IHRvCkBA IC0zMTU0LDcgKzMxNjIsOSBAQAogdGhlIGRlZmF1bHQgOHgxNiBmb250IHZhbHVlIGlzIHVz ZWQgZm9yIHNjcmVlbiBzaXplIHJlcXVlc3RzLCBvdGhlcndpc2UKIHRoZSB2YWx1ZSBpbgog LlBhIC91c3Ivc2hhcmUvc3lzY29ucy9mb250cy8gTnMgQXEgQXIgdmFsdWUKLWlzIHVzZWQu CitvciAKKy5QYSAvdXNyL3NoYXJlL3Z0L2ZvbnRzLyBOcyBBcSBBciB2YWx1ZQoraXMgdXNl ZCAoZGVwZW5kaW5nIG9uIHRoZSBjb25zb2xlIGRyaXZlciBiZWluZyB1c2VkKS4KIC5JdCBW YSBmb250OHgxNAogLlBxIFZ0IHN0cgogSWYgc2V0IHRvCkBAIC0zMTYyLDcgKzMxNzIsOSBA QAogdGhlIGRlZmF1bHQgOHgxNCBmb250IHZhbHVlIGlzIHVzZWQgZm9yIHNjcmVlbiBzaXpl IHJlcXVlc3RzLCBvdGhlcndpc2UKIHRoZSB2YWx1ZSBpbgogLlBhIC91c3Ivc2hhcmUvc3lz Y29ucy9mb250cy8gTnMgQXEgQXIgdmFsdWUKLWlzIHVzZWQuCitvciAKKy5QYSAvdXNyL3No YXJlL3Z0L2ZvbnRzLyBOcyBBcSBBciB2YWx1ZQoraXMgdXNlZCAoZGVwZW5kaW5nIG9uIHRo ZSBjb25zb2xlIGRyaXZlciBiZWluZyB1c2VkKS4KIC5JdCBWYSBmb250OHg4CiAuUHEgVnQg c3RyCiBJZiBzZXQgdG8KQEAgLTMxNzAsNyArMzE4Miw5IEBACiB0aGUgZGVmYXVsdCA4eDgg Zm9udCB2YWx1ZSBpcyB1c2VkIGZvciBzY3JlZW4gc2l6ZSByZXF1ZXN0cywgb3RoZXJ3aXNl CiB0aGUgdmFsdWUgaW4KIC5QYSAvdXNyL3NoYXJlL3N5c2NvbnMvZm9udHMvIE5zIEFxIEFy IHZhbHVlCi1pcyB1c2VkLgorb3IgCisuUGEgL3Vzci9zaGFyZS92dC9mb250cy8gTnMgQXEg QXIgdmFsdWUKK2lzIHVzZWQgKGRlcGVuZGluZyBvbiB0aGUgY29uc29sZSBkcml2ZXIgYmVp bmcgdXNlZCkuCiAuSXQgVmEgYmxhbmt0aW1lCiAuUHEgVnQgaW50CiBJZiBzZXQgdG8KQEAg LTMzNzcsNiArMzM5MSw4IEBACiAuRHEgRmwgaCBMaSAyMDAKIHdpbGwgc2V0IHRoZQogLlhy IHN5c2NvbnMgNAorb3IKKy5YciB2dCA0CiBzY3JvbGxiYWNrIChoaXN0b3J5KSBidWZmZXIg dG8gMjAwIGxpbmVzLgogLkl0IFZhIGNyb25fZW5hYmxlCiAuUHEgVnQgYm9vbApJbmRleDog c2hhcmUvbWFuL21hbjcvaGllci43Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHNoYXJlL21hbi9tYW43 L2hpZXIuNwkocmV2aXNpb24gMjcwMjQ0KQorKysgc2hhcmUvbWFuL21hbjcvaGllci43CSh3 b3JraW5nIGNvcHkpCkBAIC02MzMsNiArNjMzLDI2IEBACiBzZWUKIC5YciB0emZpbGUgNQog LkVsCisuSXQgUGEgdnQvCitmaWxlcyB1c2VkIGJ5IHZ0Oworc2VlCisuWHIgdnQgNAorLkJs IC10YWcgLXdpZHRoICIuUGEgc2Nybm1hcHMvIiAtY29tcGFjdAorLkl0IFBhIGZvbnRzLwor Y29uc29sZSBmb250czsKK3NlZQorLlhyIHZpZGNvbnRyb2wgMQorYW5kCisuWHIgdmlkZm9u dCAxCisuSXQgUGEga2V5bWFwcy8KK2NvbnNvbGUga2V5Ym9hcmQgbWFwczsKK3NlZQorLlhy IGtiZGNvbnRyb2wgMQorYW5kCisuWHIga2JkbWFwIDEKKy5cIiAuSXQgUGEgc2Nybm1hcHMv CisuXCIgY29uc29sZSBzY3JlZW4gbWFwcworLkVsCiAuSXQgUGEgc3JjLwogLkJ4ICwKIHRo aXJkLXBhcnR5LCBhbmQvb3IgbG9jYWwgc291cmNlIGZpbGVzCkluZGV4OiBzaGFyZS9tYW4v bWFuOC9uYW5vYnNkLjgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2hhcmUvbWFuL21hbjgvbmFub2Jz ZC44CShyZXZpc2lvbiAyNzAyNDQpCisrKyBzaGFyZS9tYW4vbWFuOC9uYW5vYnNkLjgJKHdv cmtpbmcgY29weSkKQEAgLTI3Nyw2ICsyNzcsOCBAQAogLlhyIGdldHR5IDgKIG9uIHRoZSB2 aXJ0dWFsCiAuWHIgc3lzY29ucyA0CitvcgorLlhyIHZ0IDQKIHRlcm1pbmFscwogLlBxIFBh IC9kZXYvdHR5dioKIGFuZCBlbmFibGVzIHRoZSB1c2Ugb2YgdGhlIGZpcnN0IHNlcmlhbCBw b3J0IGFzIHRoZSBzeXN0ZW0KSW5kZXg6IHVzci5zYmluL2tiZGNvbnRyb2wva2JkY29udHJv bC4xCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0KLS0tIHVzci5zYmluL2tiZGNvbnRyb2wva2JkY29udHJvbC4x CShyZXZpc2lvbiAyNzAyNDQpCisrKyB1c3Iuc2Jpbi9rYmRjb250cm9sL2tiZGNvbnRyb2wu MQkod29ya2luZyBjb3B5KQpAQCAtMSw1ICsxLDUgQEAKIC5cIgotLlwiIGtiZGNvbnRyb2wg LSBhIHV0aWxpdHkgZm9yIG1hbmlwdWxhdGluZyB0aGUgc3lzY29ucyBrZXlib2FyZCBkcml2 ZXIgc2VjdGlvbgorLlwiIGtiZGNvbnRyb2wgLSBhIHV0aWxpdHkgZm9yIG1hbmlwdWxhdGlu ZyB0aGUgc3lzY29ucyBvciB2dCBrZXlib2FyZCBkcml2ZXIgc2VjdGlvbgogLlwiCiAuXCIg UmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0 aCBvciB3aXRob3V0CiAuXCIgbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVk IHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCkBAIC00MSw2ICs0MSw4IEBACiAuTm0K IGNvbW1hbmQgaXMgdXNlZCB0byBzZXQgdmFyaW91cyBrZXlib2FyZCByZWxhdGVkIG9wdGlv bnMgZm9yIHRoZQogLlhyIHN5c2NvbnMgNAorb3IKKy5YciB2dCA0CiBjb25zb2xlIGRyaXZl ciBhbmQgdGhlIGtleWJvYXJkIGRyaXZlcnMsCiBzdWNoIGFzIGtleSBtYXAsIGtleWJvYXJk IHJlcGVhdCBhbmQgZGVsYXkgcmF0ZXMsIGJlbGwKIGNoYXJhY3RlcmlzdGljcyBldGMuCkBA IC0yMTMsNiArMjE1LDcgQEAKIC5TaCBGSUxFUwogLkJsIC10YWcgLXdpZHRoIC91c3Ivc2hh cmUvc3lzY29ucy9rZXltYXBzL2Zvb19iYXIgLWNvbXBhY3QKIC5JdCBQYSAvdXNyL3NoYXJl L3N5c2NvbnMva2V5bWFwcy8qCisuSXQgUGEgL3Vzci9zaGFyZS92dC9rZXltYXBzLyoKIGtl eWJvYXJkIG1hcCBmaWxlcwogLkVsCiAuU2ggRVhBTVBMRVMKQEAgLTIyMiw5ICsyMjUsMjEg QEAKIC5EbCBrYmRjb250cm9sIC1sIC91c3Ivc2hhcmUvc3lzY29ucy9rZXltYXBzL3J1Lmtv aTgtci5rYmQKIC5QcAogU28gbG9uZyBhcyB0aGUga2V5Ym9hcmQgbWFwIGZpbGUgcmVzaWRl cyBpbgotLlBhIC91c3Ivc2hhcmUvc3lzY29ucy9rZXltYXBzICwKKy5QYSAvdXNyL3NoYXJl L3N5c2NvbnMva2V5bWFwcworKGlmIHVzaW5nCisuWHIgc3lzY29ucyA0CispIG9yCisuUGEg L3Vzci9zaGFyZS92dC9rZXltYXBzCisoaWYgdXNpbmcKKy5YciB2dCA0IHZ0CispICwKIHlv dSBtYXkgYWJicmV2aWF0ZSB0aGUgZmlsZSBuYW1lIGFzCiAuUGEgcnUua29pOC1yIC4KK1Np bmNlCisuWHIgdnQgNAordXNlcyBVbmljb2RlLCB0aGUgY29ycmVzcG9uZGluZyBrZXlib2Fy ZCBmaWxlIG5hbWVzIG9taXQgdGhlIGVuY29kaW5nCithbmQgdHlwaWNhbGx5IGFyZSBqdXN0 IGEgY291bnRyeSBjb2RlLCBlLmcuCisuUGEgcnUgLgogLlBwCiAuRGwga2JkY29udHJvbCAt bCBydS5rb2k4LXIKIC5QcApAQCAtMjY4LDYgKzI4Myw3IEBACiAuWHIgc2NyZWVuIDQgLAog LlhyIHN5c2NvbnMgNCAsCiAuWHIgdWtiZCA0ICwKKy5YciB2dCA0ICwKIC5YciBrYmRtYXAg NSAsCiAuWHIgcmMuY29uZiA1CiAuU2ggQVVUSE9SUwpJbmRleDogdXNyLnNiaW4va2JkbWFw L2tiZG1hcC4xCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHVzci5zYmluL2tiZG1hcC9rYmRtYXAuMQko cmV2aXNpb24gMjcwMjQ0KQorKysgdXNyLnNiaW4va2JkbWFwL2tiZG1hcC4xCSh3b3JraW5n IGNvcHkpCkBAIC0yOSw3ICsyOSw3IEBACiAuU2ggTkFNRQogLk5tIGtiZG1hcCAsCiAuTm0g dmlkZm9udAotLk5kIGZyb250IGVuZCBmb3Igc3lzY29ucworLk5kIGZyb250IGVuZCBmb3Ig c3lzY29ucyBhbmQgdnQKIC5TaCBTWU5PUFNJUwogLk5tCiAuT3AgRmwgSwpAQCAtMTA2LDgg KzEwNiwxMCBAQAogLlNoIEZJTEVTCiAuQmwgLXRhZyAtd2lkdGggIi5QYSAvdXNyL3NoYXJl L3N5c2NvbnMva2V5bWFwcy9JTkRFWC5rZXltYXBzIiAtY29tcGFjdAogLkl0IFBhIC91c3Iv c2hhcmUvc3lzY29ucy9rZXltYXBzL0lOREVYLmtleW1hcHMKKy5JdCBQYSAvdXNyL3NoYXJl L3Z0L2tleW1hcHMvSU5ERVgua2V5bWFwcwogZGF0YWJhc2UgZm9yIGtleW1hcHMKIC5JdCBQ YSAvdXNyL3NoYXJlL3N5c2NvbnMvZm9udHMvSU5ERVguZm9udHMKKy5JdCBQYSAvdXNyL3No YXJlL3Z0L2ZvbnRzL0lOREVYLmZvbnRzCiBkYXRhYmFzZSBmb3IgZm9udHMKIC5JdCBQYSAv ZXRjL3JjLmNvbmYKIGRlZmF1bHQgZm9udApAQCAtMTIwLDYgKzEyMiw4IEBACiAuWHIgZGlh bG9nIDEgLAogLlhyIGtiZGNvbnRyb2wgMSAsCiAuWHIgdmlkY29udHJvbCAxICwKKy5YciBz eXNjb25zIDQgLAorLlhyIHZ0IDQgLAogLlhyIGtiZG1hcCA1ICwKIC5YciByYy5jb25mIDUK IC5TaCBISVNUT1JZCkluZGV4OiB1c3IuYmluL2xvY2svbG9jay4xCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K LS0tIHVzci5iaW4vbG9jay9sb2NrLjEJKHJldmlzaW9uIDI3MDI0NCkKKysrIHVzci5iaW4v bG9jay9sb2NrLjEJKHdvcmtpbmcgY29weSkKQEAgLTY5LDExICs2OSwxNCBAQAogYW5kIHRo dXMgaGFzIHRoZSBzYW1lIHJlc3RyaWN0aW9ucy4KIEl0IGlzIG9ubHkgYXZhaWxhYmxlIGlm IHRoZSB0ZXJtaW5hbCBpbiBxdWVzdGlvbiBpcyBhCiAuWHIgc3lzY29ucyA0CitvcgorLlhy IHZ0IDQKIHZpcnR1YWwgdGVybWluYWwuCiAuRWwKIC5TaCBTRUUgQUxTTwogLlhyIHZpZGNv bnRyb2wgMSAsCiAuWHIgc3lzY29ucyA0CisuWHIgdnQgNAogLlNoIEhJU1RPUlkKIFRoZQog Lk5tCkluZGV4OiB1c3Iuc2Jpbi92aWRjb250cm9sL3ZpZGNvbnRyb2wuMQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09Ci0tLSB1c3Iuc2Jpbi92aWRjb250cm9sL3ZpZGNvbnRyb2wuMQkocmV2aXNpb24gMjcw MjQ0KQorKysgdXNyLnNiaW4vdmlkY29udHJvbC92aWRjb250cm9sLjEJKHdvcmtpbmcgY29w eSkKQEAgLTEsNSArMSw1IEBACiAuXCIKLS5cIiB2aWRjb250cm9sIC0gYSB1dGlsaXR5IGZv ciBtYW5pcHVsYXRpbmcgdGhlIHN5c2NvbnMgdmlkZW8gZHJpdmVyCisuXCIgdmlkY29udHJv bCAtIGEgdXRpbGl0eSBmb3IgbWFuaXB1bGF0aW5nIHRoZSBzeXNjb25zIG9yIHZ0IHZpZGVv IGRyaXZlcgogLlwiCiAuXCIgUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5k IGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CiAuXCIgbW9kaWZpY2F0aW9uLCBhcmUg cGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCkBAIC00 OCw2ICs0OCw4IEBACiAuTm0KIHV0aWxpdHkgaXMgdXNlZCB0byBzZXQgdmFyaW91cyBvcHRp b25zIGZvciB0aGUKIC5YciBzeXNjb25zIDQKK29yCisuWHIgdnQgNAogY29uc29sZSBkcml2 ZXIsCiBzdWNoIGFzIHZpZGVvIG1vZGUsIGNvbG9ycywgY3Vyc29yIHNoYXBlLCBzY3JlZW4g b3V0cHV0IG1hcCwgZm9udCBhbmQgc2NyZWVuCiBzYXZlciB0aW1lb3V0LgpAQCAtMTU4LDgg KzE2MCwxMSBAQAogLlN4IFZpZGVvIE1vZGUgU3VwcG9ydAogYW5kCiAuU3ggRVhBTVBMRVMK LWJlbG93IGFuZCB0aGUgbWFuIHBhZ2UgZm9yCi0uWHIgc3lzY29ucyA0IC4KK2JlbG93IGFu ZCB0aGUgbWFuIHBhZ2UgZm9yIGVpdGhlcgorLlhyIHN5c2NvbnMgNAorb3IKKy5YciB2dCA0 CisoZGVwZW5kaW5nIG9uIHdoaWNoIGRyaXZlciB5b3UgdXNlKS4KIC5JdCBGbCBnIEFyIGdl b21ldHJ5CiBTZXQgdGhlCiAuQXIgZ2VvbWV0cnkKQEAgLTE4NSw3ICsxOTAsMTAgQEAKIElu c3RhbGwgc2NyZWVuIG91dHB1dCBtYXAgZmlsZSBmcm9tCiAuQXIgc2NyZWVuX21hcCAuCiBT ZWUgYWxzbwotLlhyIHN5c2NvbnMgNCAuCisuWHIgc3lzY29ucyA0CitvcgorLlhyIHZ0IDQK KyhkZXBlbmRpbmcgb24gd2hpY2ggZHJpdmVyIHlvdSB1c2UpLgogLkl0IEZsIEwKIEluc3Rh bGwgZGVmYXVsdCBzY3JlZW4gb3V0cHV0IG1hcC4KIC5JdCBGbCBNIEFyIGNoYXIKQEAgLTMw Nyw2ICszMTUsOSBAQAogb3B0aW9uLgogU2VlCiAuWHIgc3lzY29ucyA0CitvcgorLlhyIHZ0 IDQKKyhkZXBlbmRpbmcgb24gd2hpY2ggZHJpdmVyIHlvdSB1c2UpCiBmb3IgbW9yZSBkZXRh aWxzIG9uIHRoaXMga2VybmVsIG9wdGlvbi4KIC5TcyBGb3JtYXQgb2YgVmlkZW8gQnVmZmVy IER1bXAKIFRoZQpAQCAtMzEzLDYgKzMyNCw5IEBACiAuTm0KIHV0aWxpdHkgdXNlcyB0aGUK IC5YciBzeXNjb25zIDQKKy5cIiBpcyBpdCBzdXBwb3J0ZWQgb24gdnQoNCk/Pz8KK29yCisu WHIgdnQgNAogLkR2IENPTlNfU0NSU0hPVAogLlhyIGlvY3RsIDIKIHRvIGNhcHR1cmUgdGhl IGN1cnJlbnQgY29udGVudHMgb2YgdGhlIHZpZGVvIGJ1ZmZlci4KQEAgLTQ1Myw5ICs0Njcs MTIgQEAKIC5TaCBGSUxFUwogLkJsIC10YWcgLXdpZHRoIC91c3Ivc2hhcmUvc3lzY29ucy9z Y3JubWFwcy9mb28tYmFyIC1jb21wYWN0CiAuSXQgUGEgL3Vzci9zaGFyZS9zeXNjb25zL2Zv bnRzLyoKKy5JdCBQYSAvdXNyL3NoYXJlL3Z0L2ZvbnRzLyoKIGZvbnQgZmlsZXMuCiAuSXQg UGEgL3Vzci9zaGFyZS9zeXNjb25zL3Njcm5tYXBzLyoKLXNjcmVlbiBvdXRwdXQgbWFwIGZp bGVzLgorc2NyZWVuIG91dHB1dCBtYXAgZmlsZXMgKHJlbGV2YW50IGZvcgorLlhyIHN5c2Nv bnMgNAorb25seSkuCiAuRWwKIC5TaCBFWEFNUExFUwogSWYgeW91IHdhbnQgdG8gbG9hZApA QCAtNDY3LDcgKzQ4NCwxMCBAQAogLkRsIHZpZGNvbnRyb2wgLWYgOHgxNiAvdXNyL3NoYXJl L3N5c2NvbnMvZm9udHMvaXNvLTh4MTYuZm50CiAuUHAKIFNvIGxvbmcgYXMgdGhlIGZvbnQg ZmlsZSBpcyBpbgotLlBhIC91c3Ivc2hhcmUvc3lzY29ucy9mb250cyAsCisuUGEgL3Vzci9z aGFyZS9zeXNjb25zL2ZvbnRzCisoaWYgdXNpbmcgc3lzY29ucykgb3IKKy5QYSAvdXNyL3No YXJlL3Z0L2ZvbnRzCisoaWYgdXNpbmcgdnQpLAogeW91IG1heSBhYmJyZXZpYXRlIHRoZSBm aWxlIG5hbWUgYXMKIC5QYSBpc28tOHgxNiA6CiAuUHAKQEAgLTUyMSw2ICs1NDEsNyBAQAog LlhyIHNjcmVlbiA0ICwKIC5YciBzeXNjb25zIDQgLAogLlhyIHZnYSA0ICwKKy5YciB2dCA0 ICwKIC5YciByYy5jb25mIDUgLAogLlhyIGtsZGxvYWQgOCAsCiAuWHIgbW91c2VkIDggLApJ bmRleDogdXNyLnNiaW4va2JkY29udHJvbC9rYmRtYXAuNQo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB1 c3Iuc2Jpbi9rYmRjb250cm9sL2tiZG1hcC41CShyZXZpc2lvbiAyNzAyNDQpCisrKyB1c3Iu c2Jpbi9rYmRjb250cm9sL2tiZG1hcC41CSh3b3JraW5nIGNvcHkpCkBAIC0zMTMsNiArMzEz LDcgQEAKIC5TaCBGSUxFUwogLkJsIC10YWcgLXdpZHRoIC91c3Ivc2hhcmUvc3lzY29ucy9r ZXltYXBzLyogLWNvbXBhY3QKIC5JdCBQYSAvdXNyL3NoYXJlL3N5c2NvbnMva2V5bWFwcy8q CisuSXQgUGEgL3Vzci9zaGFyZS92dC9rZXltYXBzLyoKIHN0YW5kYXJkIGtleWJvYXJkIG1h cCBmaWxlcwogLkVsCiAuU2ggU0VFIEFMU08KQEAgLTMyMCw2ICszMjEsNyBAQAogLlhyIGti ZG1hcCAxICwKIC5YciBrZXlib2FyZCA0ICwKIC5YciBzeXNjb25zIDQgLAorLlhyIHZ0IDQg LAogLlhyIGFzY2lpIDcKIC5TaCBISVNUT1JZCiBUaGlzIG1hbnVhbCBwYWdlIGZpcnN0IGFw cGVhcmVkIGluCkluZGV4OiB1c3Iuc2Jpbi9ic2Rjb25maWcvYnNkY29uZmlnLjgKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQotLS0gdXNyLnNiaW4vYnNkY29uZmlnL2JzZGNvbmZpZy44CShyZXZpc2lvbiAy NzAyNDQpCisrKyB1c3Iuc2Jpbi9ic2Rjb25maWcvYnNkY29uZmlnLjgJKHdvcmtpbmcgY29w eSkKQEAgLTE3MiwxNiArMTcyLDI3IEBACiAoc3RhcnR1cF9yY2NvbmYpIG9mIHN0YXJ0dXAu CiAuSXQgQ20gc3RhcnR1cF9yY3ZhcgogU2hvcnRjdXQgdG8gdGhlIFRvZ2dsZSBTdGFydHVw IFNlcnZpY2VzIG1lbnUgdW5kZXIgc3RhcnR1cC4KKy5cIiB1c2UgbmV1dHJhbCBuYW1lLCBl LmcuIGNvbnNvbGVfa2V5bWFwIGluc3RlYWQgb2Ygc3lzY29uc19rZXltYXA/CisuXCIgZm9u dCAoZW5jb2RpbmcpIHNlbGVjdGlvbiBub3QgYXBwbGljYWJsZSB0byB2dCg0KSEKIC5JdCBD bSBzeXNjb25zX2ZvbnQKIFNob3J0Y3V0IHRvIHRoZSBGb250IG1lbnUgdW5kZXIgY29uc29s ZS4KKy5cIiAuSXQgQ20gY29uc29sZV9rZXltYXAKKy5cIiBTaG9ydGN1dCB0byB0aGUgS2V5 bWFwIG1lbnUgdW5kZXIgY29uc29sZS4KIC5JdCBDbSBzeXNjb25zX2tleW1hcAogU2hvcnRj dXQgdG8gdGhlIEtleW1hcCBtZW51IHVuZGVyIGNvbnNvbGUuCisuXCIgLkl0IENtIHZ0X3Jl cGVhdAorLlwiIFNob3J0Y3V0IHRvIHRoZSBSZXBlYXQgbWVudSB1bmRlciBjb25zb2xlLgog Lkl0IENtIHN5c2NvbnNfcmVwZWF0CiBTaG9ydGN1dCB0byB0aGUgUmVwZWF0IG1lbnUgdW5k ZXIgY29uc29sZS4KKy5cIiAuSXQgQ20gdnRfc2F2ZXIKKy5cIiBTaG9ydGN1dCB0byB0aGUg U2F2ZXIgbWVudSB1bmRlciBjb25zb2xlLgogLkl0IENtIHN5c2NvbnNfc2F2ZXIKIFNob3J0 Y3V0IHRvIHRoZSBTYXZlciBtZW51IHVuZGVyIGNvbnNvbGUuCisuXCIgc2NyZWVubWFwIChl bmNvZGluZykgc2VsZWN0aW9uIG5vdCBhcHBsaWNhYmxlIHRvIHZ0KDQpIQogLkl0IENtIHN5 c2NvbnNfc2NyZWVubWFwCiBTaG9ydGN1dCB0byB0aGUgU2NyZWVubWFwIG1lbnUgdW5kZXIg Y29uc29sZS4KKy5cIiAuSXQgQ20gdnRfc3lzY29uc190dHlzCisuXCIgU2hvcnRjdXQgdG8g dGhlIFR0eXMgbWVudSB1bmRlciBjb25zb2xlLgogLkl0IENtIHN5c2NvbnNfdHR5cwogU2hv cnRjdXQgdG8gdGhlIFR0eXMgbWVudSB1bmRlciBjb25zb2xlLgogLkl0IENtIHRpbWV6b25l CkluZGV4OiB1c3Iuc2Jpbi9ic2RpbnN0YWxsL2JzZGluc3RhbGwuOAo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 Ci0tLSB1c3Iuc2Jpbi9ic2RpbnN0YWxsL2JzZGluc3RhbGwuOAkocmV2aXNpb24gMjcwMjQ0 KQorKysgdXNyLnNiaW4vYnNkaW5zdGFsbC9ic2RpbnN0YWxsLjgJKHdvcmtpbmcgY29weSkK QEAgLTk1LDYgKzk1LDggQEAKIC5JdCBDbSBrZXltYXAKIElmIHRoZSBjdXJyZW50IGNvbnRy b2xsaW5nIFRUWSBpcyBhCiAuWHIgc3lzY29ucyA0CitvcgorLlhyIHZ0IDQKIGNvbnNvbGUs IGFza3MgdGhlIHVzZXIgdG8gc2V0IHRoZSBjdXJyZW50IGtleW1hcCwgYW5kIHNhdmVzIHRo ZSByZXN1bHQgdG8gdGhlCiBuZXcgc3lzdGVtJ3MKIC5QYSByYy5jb25mIC4K --------------040809060603010803070603-- From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 21 08:16:16 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 88449466; Thu, 21 Aug 2014 08:16:16 +0000 (UTC) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 4591B3567; Thu, 21 Aug 2014 08:16:16 +0000 (UTC) Received: from terran (unknown [192.168.99.1]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 44CB3C4927; Thu, 21 Aug 2014 11:08:45 +0300 (EEST) Date: Thu, 21 Aug 2014 11:09:20 +0300 From: Aleksandr Rybalko To: Stefan Esser Subject: Re: Opinions thought regarding: NEWCONS, rc.conf and rc.d/syscons Message-Id: <20140821110920.fecb365dda2129e5d21c351b@ddteam.net> In-Reply-To: <53F30A81.9090302@freebsd.org> References: <53F30A81.9090302@freebsd.org> X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.22; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Thu, 21 Aug 2014 08:16:16 -0000 Hello Stefan! There is my opinion. On Tue, 19 Aug 2014 10:27:45 +0200 Stefan Esser wrote: > As you all probably know, 10.1 will ship with both SYSCONS and NEWCONS. > > I'm working keymap files for NEWCONS (translated from those in SYSCONS), > and they'll need to be named differently than before. > > The SYSCONF keymap names in rc.conf will not work for NEWCONS. They > include an encoding scheme in their name, while NEWCONS universally > uses Unicode. > > There are a few points that still need to be considered for 10.1: > > a) Is rc.d/syscons still an appropriate name when using NEWCONS? > (I'd leave it unchanged, but I thought I'd ask ...) It should follow same rules as other parts. So if we support syscons(4) kernel config options for compatibility, we should make it compatible too. (Then remove it all with syscons(4) removal) > > b) Do we need to identify NEWCONS vs. SYSCONS in the messages printed > by that rc script? (I guess this might be a good idea.) vt(4) print information about its attachment, so no requirement to do same once again. But will be nice to warn user on use syscons(4) rc variables with vt(4). > > c) Do we expect to warn the user when he has a SYSCONS keymap name > specified in the rc.conf "keymap" variable, while using NEWCONS? > (This might be a good idea, at least when the default is to use > NEWCONS and the user might not be aware of the change.) Yes. User have to know - "something can work incorrect". But I think with your great work on keymaps translation it will not have a place. :) > > d) Do we want to provide the user with an information regarding the > name of the SYSCONS keymap configured, to ease the transition? > (Could be done ...) IMO - yes > > e) Do we want the rc script to translate the SYSCONS keymap name > to its new form? (This might be good for people using foreign > keyboards, if their password uses characters located at other > positions than on the default keymap, that will be used if no > valid "keymap" is specified.) dunno > > f) It might be good to introduce "keymap_sc" (and/or "keymap_vt") > as a value used in preference to "keymap" if defined and the > corresponding console driver is detected. (An alternativ to > e) that is easier to implement and still allows to have one > rc.conf file that covers both SYSCONS and NEWCONS.) IMO good idea to name default one as 'keymap' + both version with suffixes. > > I'd appreciate opinios and ideas how to proceed with these > questions. Thank you very much for that work!!! > > Regards, STefan > _______________________________________________ > 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" WBW -- Aleksandr Rybalko From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 21 08:55:48 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 3148E675; Thu, 21 Aug 2014 08:55:48 +0000 (UTC) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::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 4572639DD; Thu, 21 Aug 2014 08:55:47 +0000 (UTC) Received: by mail-lb0-f180.google.com with SMTP id v6so7673495lbi.25 for ; Thu, 21 Aug 2014 01:55:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=JOmilmiaA3Ubf7Fg8wWyCWc7XLbmjjpdOn3UVOq4g70=; b=ge4ikf3+w8naFrKUTH9Mwd8zqwReG88bFTIMMMKAHI2TUILHnTnl5k8VEhDBTi673i AcjRK1xDj8Q1uvKQBENpEOCL+nmqz5dCpMpu0Cf+f/vznBtbwxvR0c/IRoMMvjgq2sC1 y8dC9/Nu2gPnxDDzaPh4Vn/SpYe4TkEwACxXyJbQG/VvN9yOoqeBFufowf4EkoxAgMfW xZIGH9YSzAGB3DZ5Y+6ynKQ1gDx/N6u+zWa4be8Eqjcs1w30T4IDBS9Djfic4RcP6pCv 9zzmoY/eX/jvrXjlHoxBLpPMJlRaOWd2wttVS3PKaNMTZAP6cl0FNYfY8sLFXC8wN1Bi ohlQ== X-Received: by 10.112.221.37 with SMTP id qb5mr44699169lbc.69.1408611345059; Thu, 21 Aug 2014 01:55:45 -0700 (PDT) Received: from omg (pluknet-1-pt.tunnel.tserv11.ams1.ipv6.he.net. [2001:470:1f14:4d0::2]) by mx.google.com with ESMTPSA id j1sm1862146laa.4.2014.08.21.01.55.43 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Aug 2014 01:55:44 -0700 (PDT) Sender: Sergey Kandaurov Date: Thu, 21 Aug 2014 12:55:40 +0400 From: Sergey Kandaurov To: Stefan Esser Subject: Re: [PATCH] Missing references to vt(4) "NEWCONS" in man-pages Message-ID: <20140821085540.GA9402@omg> References: <53F59FE3.7030802@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V" Content-Disposition: inline In-Reply-To: <53F59FE3.7030802@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-hackers@freebsd.org" , freebsd-doc@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, 21 Aug 2014 08:55:48 -0000 --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 21, 2014 at 09:29:39AM +0200, Stefan Esser wrote: > Hi, >=20 a couple of nits inline > Index: share/man/man4/kbdmux.4 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- share/man/man4/kbdmux.4 (revision 270244) > +++ share/man/man4/kbdmux.4 (working copy) > @@ -35,6 +35,7 @@ > .Xr atkbd 4 , > .Xr syscons 4 , > .Xr ukbd 4 > +.Xr vt 4 , misplaced comma > .Sh HISTORY > The > .Nm > Index: share/man/man4/splash.4 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- share/man/man4/splash.4 (revision 270244) > +++ share/man/man4/splash.4 (working copy) > @@ -245,6 +245,7 @@ > .Xr vidcontrol 1 , > .Xr syscons 4 , > .Xr vga 4 , > +.\" .Xr vt 4 , why is it commented out? > .Xr loader.conf 5 , > .Xr rc.conf 5 , > .Xr kldload 8 , > @@ -285,6 +286,8 @@ > .Sh CAVEATS > Both the splash screen and the screen saver work with > .Xr syscons 4 > +.\" or > +.\" .Xr vt 4 > only. > .Sh BUGS > If you load a screen saver while another screen saver has already > Index: share/man/man4/terasic_mtl.4 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- share/man/man4/terasic_mtl.4 (revision 270244) > +++ share/man/man4/terasic_mtl.4 (working copy) > @@ -66,6 +66,8 @@ > .Nm > devices are also attached to the > .Xr syscons 4 > +.\" or > +.\" .Xr vt 4 > framework, which implements a VT-compatible terminal connected to the > .Xr tty 4 > framework. > @@ -91,6 +93,7 @@ > .Xr write 2 , > .Xr syscons 4 , > .Xr tty 4 , > +.\" .Xr vt 4 , > .Xr ttys 5 > .Sh HISTORY > The > @@ -111,6 +114,7 @@ > .Sh BUGS > The > .Xr syscons 4 > +.\" what about NEWCONS??? .Xr vt 4 > attachment does not support the hardware cursor feature. > .Pp > A more structured interface to control registers using the [...] > Index: share/man/man4/vt.4 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- share/man/man4/vt.4 (revision 270244) > +++ share/man/man4/vt.4 (working copy) > @@ -211,7 +211,7 @@ > Default is 15, all enabled. > .El > .Sh FILES > -.Bl -tag -width /usr/share/syscons/keymaps/* -compact > +.Bl -tag -width /usr/share/vt/keymaps/* -compact > .It Pa /dev/console > .It Pa /dev/consolectl > .It Pa /dev/ttyv* this section still misses description for paths to fonts and key maps. --xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJT9bQMAAoJED9Ol7oQYHQZLjQH/0XHsNP3ifTRggav5oxDQN+3 Ewe0MA72DgVPrgv703B/acpof3aR8znyXX0bvJWkYD9k0cMeKpkQi7fEIKWBrJqz wXCMsdvZ+3Bg93stAJMA6hEM7PT6AZvB26ZOqrSKPuqMgsUhVORt/JVm+8uaQKxb U1Jiio7mjjXu5ujeyEaXX1uXmHBPQqzkc30x0lizotAUBpF7OtQH1zkKRL+5a5Mq Oq24dr1Hth8kuDJorYLMwpKV/sVfjxDSAiL74ER5j7psKIys10EVCbWervxlo7Ww /HRrfl0XD0Pomwdp/rLaL+p+Ctu+UqVj0xUSb9dBdgDLZ4DyNwWNyRAAbHOFiHE= =7KZi -----END PGP SIGNATURE----- --xHFwDpU9dbj6ez1V-- From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 21 11:06: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 760E1EA; Thu, 21 Aug 2014 11:06:57 +0000 (UTC) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::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 0CF7D3747; Thu, 21 Aug 2014 11:06:57 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n16so7351942oag.41 for ; Thu, 21 Aug 2014 04:06:56 -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=j9iF3gCJznzER+9r+n/eL+QZlSCfruG3MeXPNKoBX7o=; b=iyIMLn6wqFBFX4rh4/Y0qhpFsbqjpePaq691jt3yVrV7r+ZcKA5S0XdmYuWKGaQ1Eh c9uM8DoCgoLeMrJ4GXFQvE5eUgzBw5p4nZOGUg8iGVr5Wk8jWsnJRq2GLEUhfQiDdcIL ZhHytX61wjVo/P9QkkX2qg1zZJ9bsMiDzcb8JyOvKfOAnVo2iAHJcXcyh+OlCdaFg4eK jTjN8NO+VWcRTbzfhdFSHOtMkPMVmZqkEHyb3k+R+5nG6GJCa/7Bn/eQGWqbGFJIW0lp kGsndvg7sLkonNum6qV1pl4pXUnnGiM/dpqMyxPL8ODi5haaGndlKFpThwc8yz9fMjpq 7dVw== MIME-Version: 1.0 X-Received: by 10.182.197.165 with SMTP id iv5mr54836375obc.55.1408619216265; Thu, 21 Aug 2014 04:06:56 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.202.75.15 with HTTP; Thu, 21 Aug 2014 04:06:56 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 Aug 2014 13:06:56 +0200 X-Google-Sender-Auth: R6b_Hg3tgXp88J_U-l8Ylq6fUhc Message-ID: Subject: Re: FBSD 10.0 USB Memstick Loader hangs on HP EliteBook 2740p From: CeDeROM To: hiren panchasara Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , freebsd-sysinstall@freebsd.org, FreeBSD Questions Mailing List , freebsd-hardware@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, 21 Aug 2014 11:06:57 -0000 On Wed, Aug 20, 2014 at 6:13 PM, CeDeROM wrote: > On Wed, Aug 20, 2014 at 6:09 PM, hiren panchasara wrote: >> I am curious, are you trying legacy bios or uefi? and did you ever >> have freebsd successfully installed/running on this laptop? Trying to >> figure out of this is a regression. > > This is my new machine so never FreeBSD on it before, I know Win7 and > Kali Linux 64bit works fine. I use Legacy BIOS boot. Should I try > UEFI? I will try pxe boot and report back :-) I have made it to run PXE Install and the installed system works fine. There must be something wrong with the USB Loader...? -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 21 16:52:36 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 2A939649; Thu, 21 Aug 2014 16:52:36 +0000 (UTC) Received: from mailout06.t-online.de (mailout06.t-online.de [194.25.134.19]) (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 C9DE63C32; Thu, 21 Aug 2014 16:52:35 +0000 (UTC) Received: from fwd02.aul.t-online.de (fwd02.aul.t-online.de [172.20.26.148]) by mailout06.t-online.de (Postfix) with SMTP id 459FF127B0A; Thu, 21 Aug 2014 18:52:27 +0200 (CEST) Received: from [192.168.119.33] (ZqdmxBZXohCo9hQmaJppKQG2z2nn+LYt8DyHmcYDU-JSJSbCeOoJ3gvcUnaRWoDQen@[84.154.101.219]) by fwd02.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XKVb2-1sVEhM0; Thu, 21 Aug 2014 18:52:20 +0200 Message-ID: <53F623BB.3010806@freebsd.org> Date: Thu, 21 Aug 2014 18:52:11 +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: 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> <53F1146B.8020906@freebsd.org> <20140821011729.164752be8fa135baf35ebf9d@ddteam.net> In-Reply-To: <20140821011729.164752be8fa135baf35ebf9d@ddteam.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ID: ZqdmxBZXohCo9hQmaJppKQG2z2nn+LYt8DyHmcYDU-JSJSbCeOoJ3gvcUnaRWoDQen X-TOI-MSGID: 78631a85-2a9a-4eb5-aa9a-9e7dcd4b8712 Cc: "freebsd-hackers@freebsd.org" , Ed Maste 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, 21 Aug 2014 16:52:36 -0000 Am 21.08.2014 um 00:17 schrieb Aleksandr Rybalko: > On Sun, 17 Aug 2014 22:45:31 +0200 > Stefan Esser wrote: > >> Am 15.08.2014 um 17:30 schrieb Ed Maste: >> 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 >> >> Ok, I've been convinced that this is the better scheme than >> the one based on locale names, which I used to prefer. >> >> And if fact, I've only needed one "complex" name: "ch-fr" >> (I chose "ch" instead of "ch-de", since that is the typical >> layout used in Switzerland - I've yet to see a Swiss-French >> keyboard in an actual system ...). >> >> Quite a number of keymaps are still waiting to be verified >> and committed. Many are derived from different encodings that >> should lead to the same Unicode characters, in an ideal world. >> >> I've spent all day on writing the converter scripts (for the >> INDEX.keymaps file and for the keymaps) and verified as many >> results as I could, but there's still a lot of work left ... >> >> Best regards, STefan >> _______________________________________________ >> 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" > > Hi guys! > > My very late $0.02. > > We all, who use locale different from 'C' or maybe 'en_US' very long time know > name of our prefered locale (from Xorg apps, from browser charset/locale settings). > And now pair of lang_COUNTRY don't looks something unfamiliar to almost all ppls, > so scheme lang_COUNTRY indeed best. We should just provide good description for > this code on selection - 'en_US (English, USA)'. Hi Aleksandr, you are repeating my arguments for the use of locale names as file names for the keymaps. But as explained in the quoted text above, I have accepted Ed's reasoning, that the keymaps are normally not defined for some language, but by a national standards committee or just history in some country. Therefore, it works to select keyboards by country, and we can all remember country codes (since they are used as top-level domain name parts). ISO language codes, on the other hand are often not obvious and often just slightly different from the corresponding country code. If we were to enforce keymaps that are easily identified with the corresponding locales, I'd still want to have the country first. If I'm a user in e.g. Switzerland, I can just as well work with a Swiss-German layout as with the Swiss-French (just a few keys for accented characters have the shifted and unshifted characters exchanged). Therefore it is useful to have all keymaps for Swiss keyoards starting with the letters "ch" and to have them grouped this way. If I'm looking for a Swiss-Italian keyboard (the locale it_SW exists), then I'll easily see that there is no ch-it, but that I can use the (identical) ch-fr.kbd, or if I have in fact got a Swiss-German layout, that there is a ch.kbd for that case. If you look at the new keymap names, then it is obvious that there are only very few cases where more than one language must be supported (because of language specific layout variants). There are ch.kbd vs. ch-fr.kbd and ca.kbd vs. ca-fr.kbd, only. And it is so much easier to use the country code that you most probably know from your mail or web address, than the locale code, which many users never get to see. If you are using a menu to select your locale, then the keymap can often be guessed from character positions 4 and 5 in the locale name (i.e. locale "ll_CC" --> keymap name: "CC.kbd"). I had been in support of locales for keymap names, myself. But then a number of locales will have no keymap under the name, or we have to provide keymaps under all locale names, that are supported (at least as links to some generic keymap). All in all and after thinking hard for 2 days and nights ;-) the suggestion to use just the country was just too convincing, and renamed all my work files from locale based keymap names tp the country based names, that I have committed to -CURRENT and want to commit to -STABLE real soon now. It is possible to map from locale to country and to suggest the correct keymap for a user, if the locale is known. And when manually configuring the keymap, I do not want to enter the locale, if the 2 letter country code suffices. BTW: I've seen both country and locale based schemes in different operating systems. Seems, that Linux for example uses countries, while Windows uses locale names (DOS had keyboard layout numbers, IIRC, and languages where needed for localized system messages and for the spell checker - both having the language code as the first and most important selector). But keyboards are really more dependent on country standards, than on languages. Multilingual countries (Switzerland, Belgium) use very similar or identical layouts for each language. For example the Belgian-Dutch keyboard (nl_BE) is identical to the Belgian-French keyboard (fr_BE). And de_CH and fr_CH differ just in whether "äöü" or "éàè" are in the unshifted/shifted position. So, I hope you can live with the 2-letter country code names ... Best regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 21 18:39: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 25B9C8A1 for ; Thu, 21 Aug 2014 18:39:20 +0000 (UTC) Received: from mail-ie0-x244.google.com (mail-ie0-x244.google.com [IPv6:2607:f8b0:4001:c03::244]) (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 ED67637FD for ; Thu, 21 Aug 2014 18:39:19 +0000 (UTC) Received: by mail-ie0-f196.google.com with SMTP id rp18so1168305iec.11 for ; Thu, 21 Aug 2014 11:39:19 -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=DwUpANODZd3CVEXnkxLakK/oaju7GohGj469HAUA1Pk=; b=pjKddUCrEpkfT9NWKi9lAAXh0kefqalAYmXGBq+c19aiAmGhzSgDyKhkCipAyrFQfY Kafx38ZgbAKOARjDLhq4hn4rHwOr3aTyFgg6J8jhYjEseYNV+KX3otIRLKxeJEe2eV3d 4Rbsh3+M6Q5vEboTNjN4apQdaY6/QASKuXqiRN+mDswNPjExZbkK8LFLCbSybZLfcixv Wexze3lPF77FGL0TvD4sap61DYVmfS6xhzjGQbgGNxfZnvMFNcyNiJebXqNuLG1meLeC GTo+quaUrWWKl+JqlJPBFK7WNdyR8gd8KnqMV+lq6QUVq71fPAIcwcYWp8JFo5J7M7DB +SoQ== MIME-Version: 1.0 X-Received: by 10.42.63.129 with SMTP id c1mr2464551ici.82.1408646359495; Thu, 21 Aug 2014 11:39:19 -0700 (PDT) Received: by 10.64.26.130 with HTTP; Thu, 21 Aug 2014 11:39:19 -0700 (PDT) Date: Thu, 21 Aug 2014 11:39:19 -0700 Message-ID: Subject: Re: Keymap definitions for VT / NEWCONS From: Dieter BSD To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-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: Thu, 21 Aug 2014 18:39:20 -0000 > And it is so much easier to use the country code that you most > probably know from your mail or web address Where do I apply for my .com passport? > than the locale code, which many users never get to see. Most users have never heard of a "locale" in a computer context. How often do most people have to deal with the filename for their keyboard? Almost never. Nice filenames are a good thing, but these filenames are not the most important ones in the universe. Just make them logical, extensible, and not excessively long (e.g. ipv6 addresses). The important part is to make it easy to find out what file you need to use. A plain text file containing a list of filenames and the corresponding languages, countries, and whatever else will do the job. Make it easy to find the index file by including its pathname in the documentation. If you want to hurt yourself, then write a little utility to help find the filename. If you must worry about names, "NEWCONS" could use improvement. What will the next system be called" NEWNEWCONS? VERYNEWCONS, followed by ULTRANEWCONS, followed by UeBERNEWCONS? The more important problem is, does this "NEWCONS" thingy provide a way to correct errors? For example, I am using a proper Unix keyboard, but for some reason both the firmware and FreeBSD think it is a horrid pee-cee style keyboard. ~/.xmodmap can fix this up, but only for X. Does this "NEWCONS" thingy provide xmodmap type functionality? > And de_CH and fr_CH differ just in whether " Another problem is that whatever characters those are do not display properly in an xterm window. And pasting them into emacs doesn't work either. From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 21 19:12: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 39D5D16B for ; Thu, 21 Aug 2014 19:12:14 +0000 (UTC) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::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 884493B82 for ; Thu, 21 Aug 2014 19:12:13 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id b17so8863748lan.25 for ; Thu, 21 Aug 2014 12:12:11 -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:content-type; bh=w02WhHoo5P/xsUGdEMZhhgbeYi+0Zl9cJhjXlj+Kj2U=; b=Ef/0B79ga7mXS3s6DtunewHLeHE5Tcry70k5giUtaD87PWdsmmifJ2IQqp9IASVVzK 7wqilFQdZXG4SNaw9W+/IIQjzfFFBWg2q+8aPKfhtX1vW5RiaJu1S80oy9Z4KQKBUnyM 7V4yVwhjmM8UlivUbDwl4/+82RB6fIWDZ+kHTeB0NSq0E9MrlLd1Z9nUrNYV3xAa/zfr 7lLmItwL1QRl2SXBS4I2U9qUMlxr6XpIrDWIJ1mjj8y3NqPBJm9CbzYuDUzNTXsjmu2J sEVQsE6r1eESIXXwe4oqx30TOMtDZu51OF9h6lM6aChD70X88p2CKOtN7NeQEzvcq+Fs ox1A== X-Received: by 10.112.204.164 with SMTP id kz4mr398832lbc.15.1408648331460; Thu, 21 Aug 2014 12:12:11 -0700 (PDT) MIME-Version: 1.0 Sender: argiopeweb@gmail.com Received: by 10.112.145.193 with HTTP; Thu, 21 Aug 2014 12:11:51 -0700 (PDT) In-Reply-To: References: From: Elliot Robinson Date: Thu, 21 Aug 2014 15:11:51 -0400 X-Google-Sender-Auth: ctp-w0NutrsG6K9XGFhGtPuVGIA Message-ID: Subject: Re: root-on-ZFS - gptzfsboot fails to find pool To: freebsd-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: Thu, 21 Aug 2014 19:12:14 -0000 On Wed, Aug 20, 2014 at 5:46 PM, Elliot Robinson < elliot.robinson@argiopetech.com> wrote: > On Wed, Aug 20, 2014 at 4:57 PM, Warren Block wrote: > >> On Wed, 20 Aug 2014, Elliot Robinson wrote: >> >> G'day all, >>> A fresh root-on-ZFS install using bsdinstall's ZFS option on FreeBSD 10 >>> fails to boot on my Dell Studio XPS 1640. Output at boot is >>> >>> gptzfsboot: error 1 lba 48 >>> gptzfsboot: error 1 lba 1 >>> gptzfsboot: No ZFS pools located, can't boot >>> >> >> This has come up in a few places lately. Could it be due to upgrading >> the pool but not updating the bootcode? >> > > Possibly in some cases, but this is a fresh install of 10 from > FreeBSD-10.0-RELEASE-amd64-memstick.img. I've recompiled/reinstalled the > stage 2 bootcode from installed source (boot with the install media, `make` > in zroot/usr/src/sys/boot). The generated gptzfsboot is identical according > to cmp. Possible it's a regression from 9.2... > > Ah, I should mention. In the list of "Things I've Tried", we can also > include "Install from 9.3 media", which failed with the same error. > > > --- > Elliot Robinson > PGP Key: 9FEDE59A > > Digging around the bug tracker, I found this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=144234 Appears this has been going on since at least 9.0-CURRENT, and might be associated with Dell machines running Core 2 Duo-era hardware. I'm going to see if I can track down the change to zfsboot.c mentioned in the bug report and try booting with a modified gptzfsboot. --- Elliot Robinson PGP Key: 9FEDE59A From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 21 20:42:39 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 56272C8F; Thu, 21 Aug 2014 20:42:39 +0000 (UTC) Received: from mailout06.t-online.de (mailout06.t-online.de [194.25.134.19]) (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 F3967354F; Thu, 21 Aug 2014 20:42:38 +0000 (UTC) Received: from fwd02.aul.t-online.de (fwd02.aul.t-online.de [172.20.26.148]) by mailout06.t-online.de (Postfix) with SMTP id A381515C876; Thu, 21 Aug 2014 22:42:36 +0200 (CEST) Received: from [192.168.119.26] (Z2Yi8+ZFohyBu3zAsvyp4erIYQOfn6AN73iHZd6W3kHaFgJ6pjivkGgkXiRvV5lwNc@[84.154.101.219]) by fwd02.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XKZBq-24QfD60; Thu, 21 Aug 2014 22:42:34 +0200 Message-ID: <53F659B0.1010602@freebsd.org> Date: Thu, 21 Aug 2014 22:42:24 +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: Re: Opinions thought regarding: NEWCONS, rc.conf and rc.d/syscons References: <53F30A81.9090302@freebsd.org> <20140821110920.fecb365dda2129e5d21c351b@ddteam.net> In-Reply-To: <20140821110920.fecb365dda2129e5d21c351b@ddteam.net> Content-Type: multipart/mixed; boundary="------------050408030606020803030900" X-ID: Z2Yi8+ZFohyBu3zAsvyp4erIYQOfn6AN73iHZd6W3kHaFgJ6pjivkGgkXiRvV5lwNc X-TOI-MSGID: 9372b3d9-bddd-49d1-96e2-b7cd658be5b2 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: Thu, 21 Aug 2014 20:42:39 -0000 This is a multi-part message in MIME format. --------------050408030606020803030900 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Am 21.08.2014 um 10:09 schrieb Aleksandr Rybalko: > Hello Stefan! > > There is my opinion. hi Aleksandr, thank you for taking the time to comment on my long list of questions! > On Tue, 19 Aug 2014 10:27:45 +0200 > Stefan Esser wrote: > >> As you all probably know, 10.1 will ship with both SYSCONS and NEWCONS. >> >> I'm working keymap files for NEWCONS (translated from those in SYSCONS), >> and they'll need to be named differently than before. >> >> The SYSCONF keymap names in rc.conf will not work for NEWCONS. They >> include an encoding scheme in their name, while NEWCONS universally >> uses Unicode. >> >> There are a few points that still need to be considered for 10.1: >> >> a) Is rc.d/syscons still an appropriate name when using NEWCONS? >> (I'd leave it unchanged, but I thought I'd ask ...) > > It should follow same rules as other parts. So if we support > syscons(4) kernel config options for compatibility, we should make it > compatible too. (Then remove it all with syscons(4) removal) I'm not sure that I fully understand your reply. Since vt has been made compatible with syscons to a certain degree, vt can still be configured with the rc.d file originally developed for syscons. We could make rc.d/syscons just exit if a system uses vt, and have a rc.d/vt (initially copied from rc.d/syscons, will probably diverge over time). Of course, rc.d/vt will also just exit on a system using syscons. But I think there are good reasons to have just one startup file with a generic name, e.g. rc.d/console (only in -CURRENT, keeping the file name in 10 as is seems to be wise). >> b) Do we need to identify NEWCONS vs. SYSCONS in the messages printed >> by that rc script? (I guess this might be a good idea.) > > vt(4) print information about its attachment, so no requirement to do > same once again. But will be nice to warn user on use syscons(4) rc > variables with vt(4). I agree, that the vt(4) attach message should be sufficient. >> c) Do we expect to warn the user when he has a SYSCONS keymap name >> specified in the rc.conf "keymap" variable, while using NEWCONS? >> (This might be a good idea, at least when the default is to use >> NEWCONS and the user might not be aware of the change.) > > Yes. User have to know - "something can work incorrect". > But I think with your great work on keymaps translation it will not > have a place. :) Well, if a system is upgraded from 9 to another release that defaults to vt (or even has syscons removed), then the keymap will not be found under its old name. There probably will a suitable keymap for use with vt, and that leads to questions d) and e). >> d) Do we want to provide the user with an information regarding the >> name of the SYSCONS keymap configured, to ease the transition? >> (Could be done ...) > > IMO - yes I guess we could have a conversion map from SYSCONS keymap files to NEWCONS files. The names of the SYSCONS keymaps are static and thus can just be embedded in a map command, which I'll propose shortly. This can be an optional part of the common startup file (i.e. a modification to rc.d/syscons, that is only invoked for systems that use vt), or it could be the first change to a copy of rc.d/syscons to rc.d/vt ... >> e) Do we want the rc script to translate the SYSCONS keymap name >> to its new form? (This might be good for people using foreign >> keyboards, if their password uses characters located at other >> positions than on the default keymap, that will be used if no >> valid "keymap" is specified.) With the approach described above (lookup of the vt keymap name based on the syscons name, in case the keymap cannot be found in vt/keymaps), it is easy to just activate the correct keyboard. The user should probably get rc.conf fixed, before this convenience code is removed, some time (one release?) after a release that has SYSCONS removed. >> f) It might be good to introduce "keymap_sc" (and/or "keymap_vt") >> as a value used in preference to "keymap" if defined and the >> corresponding console driver is detected. (An alternativ to >> e) that is easier to implement and still allows to have one >> rc.conf file that covers both SYSCONS and NEWCONS.) > > IMO good idea to name default one as 'keymap' + both version with > suffixes. With the mapping approach described above (either a sed command, or a shell case statement, but I'd prefer to use sed), this will not be necessary. All keymap file names are either unchanged (e.g. us.emacs.kbd) or exist only in one directory. In the latter case, it is easy to derive a vt keymap name from the syscons keymap name. The opposite could be possible, if a locale has been selected and the encoding to use can be derived from it. But I do not think that a mapping to SYSCONS names will be of much use. If you just want to try vt, you'll be glad to see that a matching NEWCONS keyboard is found, even though you still have the SYSCONS keymap configured. Once you edit rc.conf, you'll probably not want to go back to SYSCONS ... I have attached a shell script containing the sed commands that is able to translate all file names in syscons/keymaps to the names used for vt. The sed commands from this files could be imported into rc.d/vt (as copied from rc.d/syscons), or it could be imported into rc.d/syscons (if that script is meant to support both syscons and vt). What do you think about this approach? Best regards, STefan --------------050408030606020803030900 Content-Type: text/plain; charset=windows-1252; name="conv-name.sh" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="conv-name.sh" #!/bin/sh keymap=$1; shift SC_DIR=/usr/share/syscons/keymaps VT_DIR=/usr/share/vt/keymaps keymap=`basename "$keymap" .kbd`.kbd if [ -r $VT_DIR/$keymap ] then echo $keymap exists in vt/keymaps else if [ -r $SC_DIR/$keymap ] then keymap=$(echo $keymap | sed -e " s/\.koi8-[ur]\././ s/\.106\././ s/\.us101\./.101./ s/\.ctrlcaps\././ s/\.106x\./.capsctrl./ s/\.pc-ctrl\./.ctrl./ s/\.cp850-ctrl\./.capsctrl./ s/\.iso-ctrl\./.capsctrl./ s/\.iso[0-9]*\././ s/\.q\././ s/\.latin[0-9]\././ s/\hy\.armscii-8\./am./ s/\.ISO8859-[0-9]*\././ s/\.pt154\././ s/\.\([1-9][0-9]*\)keys\./.\1./ s/\.101keys\./.101./ s/\.macbook\.acc\./.macbook./ s/\.cp[0-9][0-9]*\././ s/^eee_nordic\./nordic.asus-eee./ s/^spanish\./es./ s/^norwegian\./es./ s/^belgian\./be./ s/^swissgerman\./ch./ s/^swissfrench\./ch-fr./ s/^ch\.macbook\./ch.macbook.acc./ s/^fr_CA\.acc\./ca-fr./ s/^br275\.acc\./br./ s/^br275\./br.noacc./ s/^colemac\.acc\./colemac./ s/^estonian\./ee./ s/^swedish\./se./ s/^finnish\./fi./ s/^danish\./dk./ s/^dutch\.acc\./nl./ s/^icelandic\./is./ s/^german\./de./ s/^pl_PL\./pl./ s/^el\./gr./ s/^iw\./il./ s/^kk\./kz./ s/^cs\.qwertz\./cz./ s/^ce\./centraleuropean./ ") if [ -r $VT_DIR/$keymap ] then echo "$keymap exists in vt/keymaps (after conversion)" else echo "$keymap not found (after conversion)" fi else echo "$keymap is not a valid syscons keymap" fi fi --------------050408030606020803030900-- From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 23 02:03:52 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 41FBBBB8 for ; Sat, 23 Aug 2014 02:03:52 +0000 (UTC) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::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 1012F3CE6 for ; Sat, 23 Aug 2014 02:03:52 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id rp18so7450287iec.33 for ; Fri, 22 Aug 2014 19:03:51 -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=a11gz41jv1dSN0JPaoMBGIaDI5ifpvquvlylFOC1+jk=; b=aI+XuigPvWCy4W2sKWPTqLpvsBu4d1nKcXkzc41yTFv76ZgRGrSdNSTzof6At2Ku4p QW0qFyDXMHpFPNGn1sytJp05g8S1jUrWFpnLxNSH2poCfpFibwIWkBGSMzh0q8pkO/Bw vIBt6+1257rNvZCMWQt9MDium4DTPPfLTRvuG6CzsNTQxtTPah53hL8l1D0ANWjNpmIy hUmd6x99Jqu+ypP+tu5ZikhAED4CiNRqlsXvC0dpdvN9CCMTe2sX0zjhUp53Thhpsroi dZLvMEjKEIiHaNtHSk+UaNCITDEzfi5OYMnMmdXlHKESp3kwK4kLyI2kIJZy8vilokeW X+Ug== X-Received: by 10.50.73.198 with SMTP id n6mr2171626igv.11.1408759431417; Fri, 22 Aug 2014 19:03:51 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.131.38 with HTTP; Fri, 22 Aug 2014 19:03:31 -0700 (PDT) In-Reply-To: References: From: Ed Maste Date: Fri, 22 Aug 2014 22:03:31 -0400 X-Google-Sender-Auth: 4WiGYXoYWkBV_Xte9u0jIpKQEco Message-ID: Subject: Re: Keymap definitions for VT / NEWCONS To: Dieter BSD Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Sat, 23 Aug 2014 02:03:52 -0000 On 21 August 2014 14:39, Dieter BSD wrote: > > If you must worry about names, "NEWCONS" could use improvement. It's called vt(4). Newcons is a nickname used during development, but is not official. You won't see it in the man page or documentation. > The more important problem is, does this "NEWCONS" thingy provide > a way to correct errors? For example, I am using a proper Unix > keyboard, but for some reason both the firmware and FreeBSD think > it is a horrid pee-cee style keyboard. ~/.xmodmap can fix this up, > but only for X. Does this "NEWCONS" thingy provide xmodmap type > functionality? This functionality has existed for two decades in FreeBSD - this is provided by the keymap files discussed in this thread. See kbdmap(5) if you need information to create your own keymap (if an existing one is not available for your keyboard configuration). >> And de_CH and fr_CH differ just in whether "=C3=A4=C3=B6=C3=BC" or "=C3= =A9=C3=A0=C3=A8" ... > > Another problem is that whatever characters those are do not > display properly in an xterm window. And pasting them into > emacs doesn't work either. They work fine here in an xterm and in a vt(4) console, assuming the locale is set appropriately (e.g., en_CA.UTF-8 in my case). From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 23 02:16: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 70FAFDB5; Sat, 23 Aug 2014 02:16:20 +0000 (UTC) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001: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 2E2DD3DC2; Sat, 23 Aug 2014 02:16:20 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id rl12so7445410iec.15 for ; Fri, 22 Aug 2014 19:16: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=c9R1O2HUOD8gMQyR/a2NuRdftmfQ6T5qxG8Bt/dbMuI=; b=uUd2Pq8QnaAGzfpDOZjYX6DxPBUtygZZSmPmUnAInEA306vTv9ya9c5g9vpSS25Dbn AT9uZv/XXTkYGXvGPsXaqRP4ohTHQLFiI89NaqAUeL6l6SpqKs9y6aLvFO3p7NZK41la a+6r3jLC1Xsd51qIRXbejYdoXXtKxqljFppoyxh+Q4geKnzaGJwzHhl98EdxH0seBLee RvPha6xZH+UCSUPQiBXGKSyGWgL4vkiaZV8enwBJ7gyq2j59b3lh0kk2pF4gTh4gx4e9 21DijgfFLBp0Ncxk9A91nqlxXGmHcFmj7KtDe1CvG9cLZioLRc248oqToY1uc0bWsXnW McZQ== X-Received: by 10.50.28.75 with SMTP id z11mr2206687igg.11.1408760179527; Fri, 22 Aug 2014 19:16:19 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.131.38 with HTTP; Fri, 22 Aug 2014 19:15:59 -0700 (PDT) In-Reply-To: <53F59FE3.7030802@freebsd.org> References: <53F59FE3.7030802@freebsd.org> From: Ed Maste Date: Fri, 22 Aug 2014 22:15:59 -0400 X-Google-Sender-Auth: a3IrtFcjeVBpphmJKOy5BMNaRwo Message-ID: Subject: Re: [PATCH] Missing references to vt(4) "NEWCONS" in man-pages To: Stefan Esser Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , freebsd-doc@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, 23 Aug 2014 02:16:20 -0000 Notes on two of the man pages: On 21 August 2014 03:29, Stefan Esser wrote: > share/man/man4/terasic_mtl.4 (does this driver work with vt???) Not yet. I have a patch in another tree to add support. > share/man/man4/vga.4 This one is syscons-specific. We pondered having a vt_vga(4) page, but the content was so minimal that it's just been put in vt(4) instead. Specifically, the vga(4) driver is _not_ used by vt(4). From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 23 16:31:48 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 7FE842DD for ; Sat, 23 Aug 2014 16:31:48 +0000 (UTC) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::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 02E143443 for ; Sat, 23 Aug 2014 16:31:47 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id s7so10661206lbd.14 for ; Sat, 23 Aug 2014 09:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=gnwk13jLQxurlpvODMfFu25zAS0ftroVuDy5iZkw638=; b=oKo382lzKUXmgR5gpC/titc9WgYLMzJKCVWum7UbyrdNkBqQprzijofj6F+KJ9Sj3K edS3QlTMVUJqVGZdEexscDr0G7u8oln302DvpTLPcCwx4Q6D+YGMPeuUhBuVy9jyRnZD hphbMw9603MI/tjSY+RN4NtH1TsAITZEbDo4sam8GErbW822HL34WdFC0zjvP3ZCEaWK W46e/DHwKZiQq/loVIsRFg5QYicDJkcUNNUYYKTSpQOFZrp8xn68usL9BDtuaddZeOi9 +Lh7vXRq1DdaNX14qqCcyQwKcC4RPf/Xl6Agj1/B4RmuITwwdseIikfuhgbDwZVYp5gJ AN6A== X-Received: by 10.112.56.148 with SMTP id a20mr2944497lbq.72.1408811505849; Sat, 23 Aug 2014 09:31:45 -0700 (PDT) Received: from [10.0.0.140] (148.217.broadband9.iol.cz. [90.176.217.148]) by mx.google.com with ESMTPSA id kv3sm52877461lbc.37.2014.08.23.09.31.44 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Aug 2014 09:31:45 -0700 (PDT) Message-ID: <53F8C1EF.8060703@gmail.com> Date: Sat, 23 Aug 2014 18:31:43 +0200 From: =?windows-1252?Q?V=E1clav_Zeman?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Opinions thought regarding: NEWCONS, rc.conf and rc.d/syscons References: <53F30A81.9090302@freebsd.org> <20140821110920.fecb365dda2129e5d21c351b@ddteam.net> <53F659B0.1010602@freebsd.org> In-Reply-To: <53F659B0.1010602@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oWCPDkiJ8JVrGHk347lQ1tCUfdS2H92hG" 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, 23 Aug 2014 16:31:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oWCPDkiJ8JVrGHk347lQ1tCUfdS2H92hG Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 21.8.2014 22:42, Stefan Esser wrote: >[...] > s/^eee_nordic\./nordic.asus-eee./ > s/^spanish\./es./ > s/^norwegian\./es./ This line above looks wrong. Should there something else than "es."? > s/^belgian\./be./ >[...] --oWCPDkiJ8JVrGHk347lQ1tCUfdS2H92hG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREKAAYFAlP4we8ACgkQonnuNA9W3VL/vgD9HOLyyP2oHayRvlfufDP7gngq UNlo30sBXHNSNqWl0dMA+wfsk7+uumTXq1EcQexceEo3SJ6UEx7nBTWwByvWZOPu =mpEr -----END PGP SIGNATURE----- --oWCPDkiJ8JVrGHk347lQ1tCUfdS2H92hG--